中心化的工作流

优势

  • 首先它让每个开发者都有自己的本地的完整项目副本。隔离的环境使得每个开发都的工作独立于项目的其它修改 —— 他们可以在自己的本地仓库中添加提交,完全无视上游的开发,直到需要的时候。
  • 其次,它让你接触到了 Git 分支和合并模型。Git 分支被设计为故障安全的机制,用来在仓库之间整合代码和共享更改。

如何工作

  • 中心化的工作将中央仓库作为项目中所有修改的唯一入口。默认的开发分支叫做 master,所有的更改都被提交到这个分支。这种工作流不需要 master 之外的其它分支。
  • 开发者将中央仓库克隆到本地后开始工作。在他们的本地项目副本中,他们可以像 SVN 一样修改文件和提交更改;不过这些新的提交被保存在本地 —— 它们和中央仓库完全隔离。这使得开发者可以将和上游的同步推迟到他们方便的时候。
  • 为了向官方项目发布修改,开发者将他们本地 master 分支“推送”到中央仓库。这一步等同于 svn commit,除了 Git 添加的是所有不在中央 master 分支上的提交。

管理冲突

  • 中央仓库代码官方项目,因此它的提交历史应该被视为不可更改的。如果开发者的本地提交和中央仓库分叉了,Git 会拒绝将它们的修改推送上去,因为这会覆盖官方提交。

  • 在开发在提交功能之前,需要 fetch 更新中央提交,在它们之上 rebase 自己的更改。
  • 如果本地修改和上游提交的冲突时,Git 会暂停 rebase 流程,给你机会手工解决这些冲突。Git 很赞的一点是,它将 git status 和 git add 命令同时用来生成提交和解决合并冲突。这使得开发能够轻而易举的管理他们的合并。另外,如果他们改错了什么,Git 能让他们轻易的退出 rebase 过程,然后重试。

例子

  • 项目管理员生成一个空的版本库

    ssh user@host git init --bare /path/to/repo.git
  • 三个人 A, B, C 同时编写同一个项目,需要先在本地创建一个完整的项目副本。

    git clone ssh://user@host/path/to/repo.git

此时,Git 自动添加了一个名为 origin 的运程连接,指向中央仓库,以方便提交。
A 可以使用标准 Git 提交流程开发功能:编辑、缓存、提交。

git status git add <some file> git commit

同时,B 也在本地进行自己的开发工作。

  • A 发布了他们修改

    git push origin master

此时中央仓库会将 master -> origin/master

  • B 试图发布修改

    git push origin master

但是因为 A 已经提交了功能到中央仓库,导致 B 的本地历史和中央仓库分叉,Git 会拒绝本次提交。

  • B 如果想提交,必须要先 rebase 本地仓库

可以使用 git pull 来拉取并修改,

git pull --rebase origin master
  • --rebase 命令告诉 Git,在同步中央仓库的修改之后,将 B 的所有提交移到 master 分支的顶端。

  • 如果没有冲突的文件,B 就可以直接进行提交了,但是如果存在冲突,可以根据提示查找冲突的文件,修改之后,可以继续 rebase 操作。

    git add <some-file> git rebase --continue

同样的,如果此时不知道自己做了什么,可以回滚一次操作。

git rebase --abort
  • 然后再进行 push 就可以提交到中央版本库了。

基于功能人分支的工作流

Feature 分支工作流

  • 掌握了中心化工作流的使用姿势,在你的开发流程中添加功能分支是一个简单的方式,来促进协作和开发者之间的交流。这种封装使得多个开发专注自己的功能,而不会打扰主代码库。它还能保证 master 分支永远不会包含损坏的代码,给持续集成环境带来了很大的好处。
  • 封装功能的开发使得 pull request 的使用成为可能,用来启动围绕一个分支的讨论。它给了其他开发者在功能并入主项目之前参与决策的机会。或者,如果你开发功能时卡在一半,可以发起一个 pull request,向同事寻求建议。重点是:pull request 使得团队在评论其他人的工作时,变得非常简单。

如何工作

  • Feature 分支工作流同样使用中央仓库,master 同样代码官方的项目历史。但是与其直接提交在本地的 master 分支,开发者每次进行新的工作时创建一个新的分支。Feature 分支应该包含描述性的名称,比如 animated-menu-items(菜单项动画)或 issue-*1061。每个分支都应该有一个清晰、高度集中的目的。
  • Git 在技术上无法区别 master 和功能分支,所以开发者可以在 feature 分支上编辑、缓存、提交,就和中心化工作流中一样。
  • 此外,feature 分支可以被推送到中央仓库。这使得你和其他开发者共享这个功能,而又不改变官方代码。既然 master 只是一个“特殊”的分支,在中央仓库中储存多个 feature 分支不会引出什么问题。当然,这也是备份每个开发者本地提交的好办法。

Pull Request

  • 除了隔离功能开发之外,分支使得通过 pull request 讨论修改成为可能。一旦有人完成了一个功能,他们不会立即将它并入 master。他们将 feature 分支推送到中央服务器上,发布一个 pull request,请求将他们的修改并入 master。这给了其他开发者在修改并入主代码库之前审查的机会。
  • 代码审查是 pull request 的主要好处,但他们事实上被设计成为讨论代码的一般场所。你可以把 pull request 看作是专注某个分支的讨论版。也就是说他们可以用于开发流程之前。比如,一个开发者在某个功能上需要帮助,他只需要发起一个 pull request。感兴趣的小伙伴会自动收到通知,看到相关提交中的问题。
  • 一旦 pull request 被接受了,发布功能的行为和中心化的工作流是一样的。首先,确定你本地的 master 和上游的 master 已经同步。然后,将 feature 分支并入 master 已经同步。然后可以将 feature 分支并入 master,将更新的 master 推送回中央仓库。

Gitflow 工作流

  • GitFlow 工作流围绕项目发布定义了一个严格的分支模型。有些地方比功能分支工作流更复杂,为管理大型项目提供了框架。
  • 和功能分支工作流相比,这种工作流没有增加任何新的概念或命令。它给不同的分支指定了特定的角色,定义它们应该如何、什么时候交流。除了功能分支之外,它还为准备发布、维护发布、记录发布分别使用了单独的分支。当然,还能享受到功能分支工作流带来的所有好处:pull request、隔离实验和更高效的协作。

如何工作