1. Git 的分支策略

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

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

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

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

分支命令常用的有：

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

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

3. 合并分支： git merge

4. 查看分支：git branch

实践例子：

下面通过实例演示上面分支图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分支就可以：