如何基于 Git 设计合理的多人开发模式？（建议收藏）

发表于 2年以前 | 总阅读数：336 次

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

所以，在编码之前，我们需要设计一个合理的开发模式。又因为目前开发者基本都是基于 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 页面的讨论，可以使开发者充分参与到代码的讨论中，有助于提高代码的质量，并且提供了一个代码变更的历史回顾途径。

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

基于 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 步，你可以跟着以下步骤操作练习。

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

  $ git checkout -b develop master

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

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

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），你可以跟着以下步骤操作练习。

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)

创建功能分支。

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

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

然后，创建功能分支。

  $ git checkout -b feature/add-function

提交 commit。

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

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

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

  $ git rebase -i origin/master

第 5 讲已经介绍过了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

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

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

  $ git push -f origin feature/add-function

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

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

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

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

但 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 工作流基础上，解耦了个人远端仓库和项目远端仓库。

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