如何基于 Git 设计合理的多人开发模式？

一个企业级项目是由多人合作完成的，不同开发者在本地开发完代码之后，可能提交到同一个代码仓库，同一个开发者也可能同时开发几个功能特性。这种多人合作开发、多功能并行开发的特性如果处理不好，就会带来诸如丢失代码、合错代码、代码冲突等问题。

所以，在编码之前，我们需要设计一个合理的开发模式。又因为目前开发者基本都是基于 Git 进行开发的，所以本节课，我会教你怎么基于 Git 设计出一个合理的开发模式。

那么如何设计工作流呢？你可以根据需要，自己设计工作流，也可以采用业界沉淀下来的、设计好的、受欢迎的工作流。一方面，这些工作流经过长时间的实践，被证明是合理的；另一方面，采用一种被大家熟知且业界通用的工作流，会减少团队内部磨合的时间。在这一讲中，我会为你介绍 4 种受欢迎的工作流，你可以选择其中一种作为你的工作流设计。

在使用 Git 开发时，有 4 种常用的工作流，也叫开发模式，按演进顺序分为集中式工作流、功能分支工作流、Git Flow 工作流和 Forking 工作流。接下来，我会按演进顺序分别介绍这 4 种工作流。

集中式工作流

我们先来看看集中式工作流，它是最简单的一种开发方式。集中式工作流的工作模式如下图所示：

A、B、C 为 3 位开发者，每位开发者都在本地有一份远程仓库的拷贝：本地仓库。A、B、C 在本地的 master 分支开发完代码之后，将修改后的代码 commit 到远程仓库，如果有冲突就先解决本地的冲突再提交。在进行了一段时间的开发之后，远程仓库 master 分支的日志可能如下图所示：

集中式工作流是最简单的开发模式，但它的缺点也很明显：不同开发人员的提交日志混杂在一起，难以定位问题。如果同时开发多个功能，不同功能同时往 master 分支合并，代码之间也会相互影响，从而产生代码冲突。

和其他工作流相比，集中式工作流程的代码管理较混乱，容易出问题，因此适合用在团队人数少、开发不频繁、不需要同时维护多个版本的小项目中。当我们想要并行开发多个功能时，这种工作流就不适用了，这时候怎么办呢？我们接下来看功能分支工作流。

功能分支工作流

功能分支工作流基于集中式工作流演进而来。在开发新功能时，基于 master 分支新建一个功能分支，在功能分支上进行开发，而不是直接在本地的 master 分支开发，开发完成之后合并到 master 分支，如下图所示：

相较于集中式工作流，这种工作流让不同功能在不同的分支进行开发，只在最后一步合并到 master 分支，不仅可以避免不同功能之间的相互影响，还可以使提交历史看起来更加简洁。

还有，在合并到 master 分支时，需要提交 PR（pull request），而不是直接将代码 merge 到 master 分支。PR 流程不仅可以把分支代码提供给团队其他开发人员进行 CR（Code Review），还可以在 PR 页面讨论代码。通过 CR ，我们可以确保合并到 master 的代码是健壮的；通过 PR 页面的讨论，可以使开发者充分参与到代码的讨论中，有助于提高代码的质量，并且提供了一个代码变更的历史回顾途径。

那么，功能分支工作流具体的开发流程是什么呢？我们一起来看下。

1.基于 master 分支新建一个功能分支，功能分支可以取一些有意义的名字，便于理解，例如 feature/rate-limiting。

$ git checkout -b feature/rate-limiting

2.在功能分支上进行代码开发，开发完成后 commit 到功能分支。

$ git add limit.go
$ git commit -m "add rate limiting"

3.将本地功能分支代码 push 到远程仓库。

$ git push origin feature/rate-limiting

4.在远程仓库上创建 PR（例如：GitHub）

进入 GitHub 平台上的项目主页，点击 Compare & pull request 提交 PR，如下图所示。

5.代码管理员收到 PR 后，可以 CR 代码，CR 通过后，再点击 Merge pull request 将 PR 合并到 master，如下图所示。

图中的“Merge pull request” 提供了 3 种 merge 方法：

• Create a merge commit：GitHub 的底层操作是 git merge --no-ff。feature 分支上所有的 commit 都会加到 master 分支上，并且会生成一个 merge commit。这种方式可以让我们清晰地知道是谁做了提交，做了哪些提交，回溯历史的时候也会更加方便。

• Squash and merge：GitHub 的底层操作是 git merge --squash。Squash and merge 会使该 pull request 上的所有 commit 都合并成一个 commit ，然后加到 master 分支上，但原来的 commit 历史会丢失。如果开发人员在 feature 分支上提交的 commit 非常随意，没有规范，那么我们可以选择这种方法来丢弃无意义的 commit。但是在大型项目中，每个开发人员都应该是遵循 commit 规范的，因此我不建议你在团队开发中使用 Squash and merge。

• Rebase and merge：GitHub 的底层操作是 git rebase。这种方式会将 pull request 上的所有提交历史按照原有顺序依次添加到 master 分支的头部（HEAD）。因为 git rebase 有风险，在你不完全熟悉 Git 工作流时，我不建议 merge 时选择这个。

通过分析每个方法的优缺点，在实际的项目开发中，我比较推荐你使用 Create a merge commit 方式。

从刚才讲完的具体开发流程中，我们可以感受到，功能分支工作流上手比较简单，不仅能使你并行开发多个功能，还可以添加 code review，从而保障代码质量。当然它也有缺点，就是无法给分支分配明确的目的，不利于团队配合。它适合用在开发团队相对固定、规模较小的项目中。接下来我们要讲的 Git Flow 工作流以功能分支工作流为基础，较好地解决了上述问题。

Git Flow 工作流

Git Flow工作流是一个非常成熟的方案，也是非开源项目中最常用到的工作流。它定义了一个围绕项目发布的严格分支模型，通过为代码开发、发布和维护分配独立的分支来让项目的迭代流程更加顺畅，比较适合大型的项目或者迭代速度快的项目。接下来，我会通过介绍 Git Flow 的 5 种分支和工作流程，来给你讲解 GIt Flow 是如何工作的。

Git Flow 的 5 种分支

Git Flow 中定义了 5 种分支，分别是 master、develop、feature、release 和 hotfix。其中，master 和 develop 为常驻分支，其他为非常驻分支，不同的研发阶段会用到不同的分支。

这 5 种分支的详细介绍见下表：

Git Flow 开发流程

这里我们用一个实际的例子来演示下 Git Flow 的开发流程。场景如下：

a. 当前版本为：0.9.0。

b. 需要新开发一个功能，使程序执行时向标准输出输出“hello world”字符串。

c. 在开发阶段，线上代码有 Bug 需要紧急修复。

假设我们的 Git 项目名为 gitflow-demo，项目目录下有 2 个文件，分别是 README.md 和 main.go，内容如下。

package main
import "fmt"
func main() {
  fmt.Println("callmainfunction")
}

具体的开发流程有 12 步，你可以跟着以下步骤操作练习。

1.创建一个常驻的分支：develop。

$ git checkout -b develop master

2.基于 develop 分支，新建一个功能分支：feature/print-hello-world

$ git checkout -b feature/print-hello-world develop

3.feature/print-hello-world 分支中，在 main.go 文件中添加一行代码fmt.Println("Hello")，添加后的代码如下。

package main
import "fmt"
func main() {
  fmt.Println("callmainfunction")
  fmt.Println("Hello")
}

4.紧急修复 Bug。

我们正处在新功能的开发中（只完成了 fmt.Println("Hello")而非 fmt.Println("Hello World")）突然线上代码发现了一个 Bug，我们要立即停止手上的工作，修复线上的 Bug，步骤如下。

$ git stash # 1. 开发工作只完成了一半，还不想提交，可以临时保存修改至堆栈区
$ git checkout -b hotfix/print-error master # 2. 从 master 建立 hotfix 分支
$ vi main.go # 3. 修复 bug，callmainfunction -> call main function
$ git commit -a -m 'fix print message error bug' # 4. 提交修复
$ git checkout develop # 5. 切换到 develop 分支
$ git merge --no-ff hotfix/print-error # 6. 把 hotfix 分支合并到 develop 分支
$ git checkout master # 7. 切换到 master 分支
$ git merge --no-ff hotfix/print-error # 8. 把 hotfix 分支合并到 master
$ git tag -a v0.9.1 -m "fix log bug" # 9. master 分支打 tag
$ go build -v . # 10. 编译代码，并将编译好的二进制更新到生产环境
$ git branch -d hotfix/print-error # 11. 修复好后，删除 hotfix/xxx 分支
$ git checkout feature/print-hello-world # 12. 切换到开发分支下
$ git merge --no-ff develop # 13. 因为 develop 有更新，这里最好同步更新下
$ git stash pop # 14. 恢复到修复前的工作状态

5.在 main.go 中加入 fmt.Println("Hello World")。

6.提交代码到 feature/print-hello-world 分支。

$ git commit -a -m "print 'hello world'"

7.在 feature/print-hello-world 分支上做 code review。

首先，我们需要将 feature/print-hello-world push 到代码托管平台，例如 GitHub 上。

$ git push origin feature/print-hello-world

然后，我们在 GitHub 上，基于 feature/print-hello-world 创建 pull request，如下图所示。

创建完 pull request 之后，我们就可以指定 Reviewers 进行 code review，如下图所示。

8.code review 通过后，由代码仓库 matainer 将功能分支合并到 develop 分支。

$ git checkout develop
$ git merge --no-ff feature/print-hello-world

9.基于 develop 分支，创建 release 分支，测试代码。

$ git checkout -b release/1.0.0 develop
$ go build -v . # 构建后，部署二进制文件，并测试

10.测试失败，因为我们要求打印“hello world”，但打印的是“Hello World”，修复的时候，我们直接在 release/1.0.0 分支修改代码，修改完成后，提交并编译部署。

$ git commit -a -m "fix bug"
$ go build -v .

11.测试通过后，将功能分支合并到 master 分支和 develop 分支。

$ git checkout develop
$ git merge --no-ff release/1.0.0
$ git checkout master
$ git merge --no-ff release/1.0.0
$ git tag -a v1.0.0 -m "add print hello world" # master 分支打 tag

12.删除 feature/print-hello-world 分支，也可以选择性删除 release/1.0.0 分支。

$ git branch -d feature/print-hello-world

亲自操作一遍之后，你应该会更了解这种模式的优缺点。它的缺点，就是你刚才已经体会到的，它有一定的上手难度。不过 Git Flow 工作流还是有很多优点的：Git Flow 工作流的每个分支分工明确，这可以最大程度减少它们之间的相互影响。因为可以创建多个分支，所以也可以并行开发多个功能。另外，和功能分支工作流一样，它也可以添加 code review，保障代码质量。

因此，Git Flow 工作流比较适合开发团队相对固定，规模较大的项目。

Forking 工作流

上面讲的 Git Flow 是非开源项目中最常用的，而在开源项目中，最常用到的是 Forking 工作流，例如 Kubernetes、Docker 等项目用的就是这种工作流。这里，我们先来了解下 fork 操作。

fork 操作是在个人远程仓库新建一份目标远程仓库的副本，比如在 GitHub 上操作时，在项目的主页点击 fork 按钮（页面右上角），即可拷贝该目标远程仓库。Forking 工作流的流程如下图所示。

假设开发者 A 拥有一个远程仓库，如果开发者 B 也想参与 A 项目的开发，B 可以 fork 一份 A 的远程仓库到自己的 GitHub 账号下。后续 B 可以在自己的项目进行开发，开发完成后，B 可以给 A 提交一个 PR。这时候 A 会收到通知，得知有新的 PR 被提交，A 会去查看 PR 并 code review。如果有问题，A 会直接在 PR 页面提交评论，B 看到评论后会做进一步的修改。最后 A 通过 B 的 PR 请求，将代码合并进了 A 的仓库。这样就完成了 A 代码仓库新特性的开发。如果有其他开发者想给 A 贡献代码，也会执行相同的操作。

GitHub 中的 Forking 工作流详细步骤共有 6 步（假设目标仓库为 gitflow-demo），你可以跟着以下步骤操作练习。

1.Fork 远程仓库到自己的账号下。

访问https://github.com/marmotedu/gitflow-demo ，点击 fork 按钮。fork 后的仓库地址为：https://github.com/colin404fork/gitflow-demo 。

2.克隆 fork 的仓库到本地。

$ git clone https://github.com/colin404fork/gitflow-demo
$ cd gitflow-demo
$ git remote add upstream https://github.com/marmotedu/gitflow-demo
$ git remote set-url --push upstream no_push # Never push to upstream master
$ git remote -v # Confirm that your remotes make sense
origin  https://github.com/colin404fork/gitflow-demo (fetch)
origin  https://github.com/colin404fork/gitflow-demo (push)
upstream  https://github.com/marmotedu/gitflow-demo (fetch)
upstream  https://github.com/marmotedu/gitflow-demo (push)

3.创建功能分支。

首先，要同步本地仓库的 master 分支为最新的状态（跟 upstream master 分支一致）。

$ git fetch upstream
$ git checkout master
$ git rebase upstream/master

然后，创建功能分支。

$ git checkout -b feature/add-function

提交 commit。

4.在 feature/add-function 分支上开发代码，开发完代码后，提交 commit。

$ git fetch upstream # commit 前需要再次同步 feature 跟 upstream/master
$ git rebase upstream/master
$ git add <file>
$ git status
$ git commit

5.分支开发完成后，可能会有一堆 commit，但是合并到主干时，我们往往希望只有一个（或最多两三个）commit，这可以使功能修改都放在一个或几个 commit 中，便于后面的阅读和维护。这个时候，我们可以用 git rebase 来合并和修改我们的 commit，操作如下：

$ git rebase -i origin/master

前面已经介绍过了git rebase -i 的使用方法 ，如果你有疑问可以再去看看，这里不再说明。还有另外一种合并 commit 的简便方法，就是先撤销过去 5 个 commit，然后再建一个新的：

$ git reset HEAD~5
$ git add .
$ git commit -am "Here's the bug fix that closes #28"
$ git push --force

squash 和 fixup 命令，还可以当作命令行参数使用，自动合并 commit。

$ git commit --fixup
$ git rebase -i --autosquash

6.push 功能分支到个人远程仓库。

在完成了开发，并 commit 后，需要将功能分支 push 到个人远程代码仓库，代码如下：

$ git push -f origin feature/add-function

7.在个人远程仓库页面创建 pull request。

提交到远程仓库以后，我们就可以创建 pull request，然后请求 reviewers 进行代码 review，确认后合并到 master。这里要注意，创建 pull request 时，base 通常选择目标远程仓库的 master 分支。

我们已经讲完了 Forking 工作流的具体步骤，你觉得它有什么优缺点呢？

结合操作特点，我们来看看它的优点：Forking 工作流中，项目远程仓库和开发者远程仓库完全独立，开发者通过提交 Pull Request 的方式给远程仓库贡献代码，项目维护者选择性地接受任何开发者的提交，通过这种方式，可以避免授予开发者项目远程仓库的权限，从而提高项目远程仓库的安全性，这也使得任意开发者都可以参与项目的开发。

8.但 Forking 工作流也有局限性，就是对于职能分工明确且不对外开源的项目优势不大。

Forking 工作流比较适用于以下三种场景：

     （1）开源项目中；

     （2）开发者有衍生出自己的衍生版的需求；

     （3）开发者不固定，可能是任意一个能访问到项目的开发者。

总结

这一讲中，我基于 Git 向你介绍了 4 种开发模式，现在跟我回顾一下吧。

• 集中式工作流：开发者直接在本地 master 分支开发代码，开发完成后 push 到远端仓库 master 分支。

• 功能分支工作流：开发者基于 master 分支创建一个新分支，在新分支进行开发，开发完成后合并到远端仓库 master 分支。

• Git Flow 工作流：Git Flow 工作流为不同的分支分配一个明确的角色，并定义分支之间什么时候、如何进行交互，比较适合大型项目的开发。

• Forking 工作流：开发者先 fork 项目到个人仓库，在个人仓库完成开发后，提交 pull request 到目标远程仓库，远程仓库 review 后，合并 pull request 到 master 分支。

集中式工作流是最早的 Git 工作流，功能分支工作流以集中式工作流为基础，Git Flow 工作流又是以功能分支工作流为基础，Forking 工作流在 Git Flow 工作流基础上，解耦了个人远端仓库和项目远端仓库。

每种开发模式各有优缺点，适用于不同的场景，我总结在下表中：

总的来说，在选择工作流时，我的推荐如下：

• 非开源项目采用 Git Flow 工作流。

• 开源项目采用 Forking 工作流。

来源：极客时间

作者：孔令飞

原文链接：https://time.geekbang.org/column/article/382342

版权声明，内容来源网络，仅供分享学习，版权归原创作者所有，除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除表示歉意。谢谢！

相关阅读：