Git 的分支策略及工作流

每一个Git仓库都包含一个提交库，这些提交通过元数据（实际上文件对象由其它实体存储，节点上只是存储指向文件对象的指针）相互连接，每个提交包含一个指向自身父提交的引用（指针）。对于合并提交而言，它可能会引用不止一个父提交。Git中的分支实际上是一个指向某个特定提交的命名指针。

简单说Git的每个新版本其实只是维护变动和指向变动前版本的指针。简图如下：

        每一个依赖链组成一条支，刚开始的第一条支叫做主分支（一般默认叫master），从主分支可以分别分出枝干，也就是分分支，但一般会取上一个特定的分支名称。

        分支的策略有很多，可以根据功能分，根据状态分等方式。但同样都是为了更好的管理代码和协同开发。比如下图：

分支命令常用的有：

1. 创建分支： git branch 分支名称

2. 切换分支： git checkout 分支名称

3. 合并分支（可能冲突）： git merge 被合并的分支名称

4. 查看分支：git branch

5. 删除分支： git branch -d 分支名称

实践例子：

下面通过实例演示上面分支图2 所示的过程。 首先在branchDemo中新建文件

 提交V1版本：

 执行“git branch” 命令查看当前分支情况， 发现当前只有master分支（主支）：

 修改功能A， 新增功能B：

 提交V2版本：

 修改功能B， 版本是V3：

 提交版本V3：

上面的开发没有考虑分支策略， 这种情况会存在问题：前面功能A和功能C时分开文件的。但假如接下来在代码整体中开发功能C（这里用同一文件表示），当功能C还没开发完成时，上线的功能B出现bug，需要紧急修复，这时功能C开发到一半，将功能C开发的内容回滚又不好，线上bug又等不了功能C完成。那该怎么办？

此时分支策略就起作用了：在功能C开发之前，先基于master主分支拉个分支（比如分支名称为dev），再在dev分支上开发功能C，线上功能B出现bug时，基于master主分支上拉个分支（比如分支名称为bug），在bug上修复，修复完bug后再合并到master，dev不受影响可以继续开发，等功能C开发完后，再将dev合并到master。

接着上面例子，实践如下：

先从master中拉出dev分支，因为现在只有master，所以直接新建dev分支就可以：

 当前在master 分支，切换到dev分支：

开发功能C，开发到一半：

 

 此时线上功能B出现bug，也就是要基于V3版本修改bug。 此时提交未完成功能C，是版本V4：

 切换回master主支，master出于V3版本，也就是不包括功能C的内容：

 查看master上的文件内容：

基于当前的master新建bug分支用于修复bug：

 

 修复bug：

修复后提交版本V5，此时还在dev分支上：

 合并dev分支到master，即是把修复合并到主分支：

注意：要把dev分支合并到master分支，首先要切换回master分支，然后把dev分支拉到master分支进行合并。（这个顺序很重要）

当前在master分支，可以看一下修复的版本V5是否存在master：

bug修复完后，bug分支已经没有用了， 可以删除bug分支，执行“git branch -d bug” 删除：

 可以检测master上的bug被修复了：

接下来切换回dev分支继续开发尚未完成的功能C：

 继续开发尚未完成的功能C：

 功能C开发完成：

提交功能C，即版本V6：

接下来合并功能C到master分支，即切换回master分支，将dev分支拉到master分支进行合并：

 在合并dev分支时，发现冲突“conflict”，那是因为修复bug的代码和功能C的代码修改了在同一行，Git不知道怎么处理，所以抛出了冲突，接下来就要手动解决分支：

打开上面的冲突文件，手动修改里面的内容如下：

 

修改好后提交解决冲突后的内容：

提交成功。

分支实践完成，模拟了如下分支场景：