大白话 git 教程-12-多人协作开发和 PR 模型

由于 git 的分支非常的方便，因为 git 互相协作的方式也比较多，但是典型分支协作模型如下图，很多都是它的变种，所以需要理解下面的这张图，这张图的信息如下:

1. 对于分支的规划:

a) feature 分支，可发新功能的分支，通常是从 develop 分支签出来的

b) develop 分支，集合了所有的开发功能的分支，大部分时间它上面的代码是不稳定的

c) release 分支，经过测试了可以发布部署的分支代码

d) hotfix 分支，用于修复线上 bug 的分支，从 master 分支签出来

2) 几个典型的事件:

a) 最开始的时候没有 develop 分支，这时候从 master 分支签出了 develop 分支，develop 包含了目前所有的功能代码

b) 从 develop 分支签出的 feature 分支都合并会 develop 分支，开发到一定程度的时候，签出 release 分支

c) 如果 release 分支创建了，它之后只承担修复 bug 的作用，不再开发新功能，并且修复的 bug 也会合并回 develop 分支，防止 develop 分支以后的代码重现 bug

d) 当 release 分支测试稳定后，就合并到 master 分支并打上 tag 标签

e) 处于 master 的分支通常足够稳定，但是出现了 bug 就会签出 hotfix 分支来修复bug，重点是修复完成后 hotfix 分支必须同时合并到 master 和 develop 分支

针对上面的分支模型，抽象除了 git-flow 工具链，安装参考 https://github.com/nvie/gitflow/wiki/Installation。

开发的大致使用流程如下:

1. git flow init 初始化一个仓库，一般使用默认的分支名称比较清晰 (会创建 master 和 develop)

2. git flow feature start abc 开始开发一个 abc 功能的分支 (会基于 develop 创建 feature/abc)

3. git flow feature finish abc 提交开发完成的 abc 功能 (会把 feature/abc 合并到 develop 并删除 feature/abc)

4. git flow release start v1.0 创建一个预发布的分支 (会从 develop 创建 release/v1.0)

5. git flow release finish v1.0 创建正式的发布分支和 tag 标签 (会把 release/v1.0 合并到 master 并打上标签 v1.0，还会删除 release/v1.0)

修复 bug 的大致流程如下:

1. git flow hotfix start abc 从 master 创建修复 bug 的分支 (会创建 hotfix/abc 分支)

2. git flow hotfix finish abc 完成了 bug 的修复 (会把 hotfix/abc 合并到 master 递增 tag，还会合并到 develop 并删除 hotfix/abc 分支)

实际使用中还有一种特殊情况:

如果线上 bug 出现，创建 hotfix 的时候 release 分支处于预发布状态，根据实际情况考虑是在当前发布版本修复(hotfix 同时合并到 develop、release 分支)还是以后修复(只需合并到 develop 分支)

这个分支模型非常适用于基于版本的发布，如果要使用的话，团队里的成员都要使用，否则可能把分支搞乱。

最后，你可能经常听到 PR，PR 是 pull request 的简写，他是一种参与开源项目协作的方式。

如果你对一个仓库有权限提交，那么就可以直接发起 PR 或者直接合并代码，否则你需要 fork 仓库，clone 到本地，因为你只有对自己仓库的操作权限，你提交修复代码到分支，并推送到自己的仓库，然后去原仓库地址在线创建一个合并请求，选择你提交的分支，然后可以基于这个 PR 做讨论、测试、改进，直到你的提交被认可，可以主动去邀请一些人来 review 你的提交，最后被合并进主干分支。