如何高效实用 Git SlowGO

场景

假设有一个项目，要开发下一代的 Facebook，你就是这个项目的技术 leader，你的团队有3个开发人员：

Alice：1年开发经验
Bob：1年开发经验
John：3年开发经验
You：这个项目的技术 leader
Git 中的开发过程
Master branch 主分支
1）主分支始终包含线上产品的代码。

2）任何人，包括技术 leader，都不允许直接修改主分支上的代码，因为主分支是线上代码的拷贝。

3）代码的开发是在其他分支上做的。

Release branch 发布分支
1）项目启动后，首先要为项目创建一个 Release branch，是从 Master branch 创建出来的。

2）关于项目的所有代码都会在这个 Release branch 中，这个 Release branch 也只是一个普通的分支，只是以 “release/” 开头。

3）例如把我们这个项目的 Release branch 命名为 “release/fb”。

4）可能同时会有多个项目在开发，所以，为每个项目创建一个独立的 Release branch，例如现在还有一个项目叫 “release/messenger”。

5）使用 Release branch 的目的就是多个项目间不影响。

Feature branch 特征分支
1）开发每个功能时都创建一个 Feature branch，确保这个功能是单独开发的。

2）Feature branch 是以 “feature/” 为前缀名的普通分支。

3）你作为技术leader，现在让 Alice 去开发登录功能，所以 Alice 创建了一个新的 Feature branch，叫做 “feature/login”，然后在这个分支中开发登录功能。

4）Feature branch 通常是从 Release branch 中创建出来的。

5）你让 Bob 开发加好友的功能，Bob 就创建了一个 Feature branch，命名为 “feature/friendrequest”。

6）John 的任务是创建新闻 feed 流，他创建了 “feature/newsfeed”。

7）每个程序员都在自己的 Feature branch 中进行开发。

8）现在，Alice 的登录功能开发完了，需要把自己 feature/login 分支中的代码发到 release/fb 中，可以通过 pull request。

pull request
首先，不要把 pull request 和 git pull 混淆了。

开发人员不能直接把自己分支中的代码推到 release branch 中。

技术 leader 先要做个 review，检查一下代码。

这就是通过 pull request 做的。

例如 GitHub 中的操作流程：

image
点击 “New pull request” 后：

image
compare 是 Alice 自己的 feature/login 开发分支。
base 是项目的 release/fb 发布分支。
之后，Alice 输入一个标题和描述，最后点击 “Create Pull Request”。

Alice 需要为这个 pull request 分配一个 reviewer，就是你。

然后你就可以对 pull request 的代码进行 review 了，没问题后就可以把 feature/login 合并到 release/fb 了，此时 Alice 这个功能的代码就算成功提交了。

代码冲突
1）Bob 开发完了，也发起了一个 pull request，从 feature/friendrequest 到 release/fb。

2）因为 release branch 已经有了 Alice 提交的登录代码，所以代码冲突就发生了。你作为技术leader，有责任去解决冲突，然后合并分支。

3）现在 John 开发完了，因为 John 开发经验比 Alice 和 Bob 都丰富，John 自己处理了代码冲突。John 从 release/fb 拿到最新的代码放到自己的 feature/newsfeed （通过 git pull 或 git merge），并处理了所有的冲突。

4）John 发起了一个 pull request，这时你就省心了，不用你来解决代码冲突了。

所以，解决代码冲突的2个途径：

负责 pull request review 的人来处理。
开发人员自己处理，把最新的 release branch 合并到自己的 feature branch，解决掉所有代码冲突。
回到 Master branch
项目开发完成后，release 分支合并回 master 分支。