git分支管理策略

0. 分支合并的本质

其实，分支的合并并没有方向性。即，A分支往B分支上合并和B分支往A分支上合并，最终的分支物理结构是一样的，两个分支最后回合在一个交点上。只是，这个交点的所有权归属不一样。A分支往B分支上合并时，A分支不变，B分支拥有交点的所有权，将指针指向交点，并添加message。

1. 常见分支及作用

1.1 长期分支

这些分支长期存在。

1.1.1 master

主分支，用于发布。

1. 可以切出以下分支：
   develop：在一开始建立时切出
   hotfix：在遇到线上bug时切出
2. 可以合并以下分支：
   hotfix：解决线上bug后合并
   release：一次新版本的发布，通过测试后合并

1.1.2 develop

开发分支，用于整合一段时间内开发的所有新功能。

1. 可以切出以下分支：
   feature：在有新的功能需要开发时切出
2. 可以合并以下分支：
   hotfix：解决线上bug后合并
   release：一次新版本的发布，通过测试后合并（实际上主要合并的是在测试过程中用于修复bug的代码）

注：除了一开始在还没有进行开发之前develop分支是从master分支切出来的，此后develop分支与master分支并没有直接交互。发布时，是通过release分支进行的。

1.2 短期分支

这些分支会存在一段时间，在合并过后会被删除。

1.2.1 develop-xxx

独立开发分支。当要开发一个比较完整的、比较独立的、新的功能时，为了不影响develop分支的日常开发，从develop分支切出一个独立的分支进行修改。

1. 可以根据需要，比如多人开发，再切出新的分支，但都应该以feature开头；
2. 只能从develop分支切出，再被合并到develop分支。

1.2.2 feature-xxx

功能分支，用于开发一个新的功能，每个新功能都应该新开一个feature分支。

1. 可以根据需要，比如多人开发，再切出新的分支，但都应该以feature开头；
2. 可以从开发分支或独立开发分支切出，再被合并到起始分支。

注：除了feature分支还可以根据需要定义一些并列分支前缀，如新功能开发可以以feature开头；完成某个任务（比如，修改配置文件，对文件做一些调整等）可以以task开头；做一些优化可以以optimize开头；解决冲突合并分支可以以merge开头。

1.2.3 release-xxx

发布分支，实际上真正的发布并不会在本分支进行，而是在该分支合并到master分支并打过tag之后，才会进行发布。本分支主要用于测试本次发版的所有功能。

1. 只能从develop分支切出，在通过测试之后，会被合并到develop分支和master分支；
2. 如果在测试的过程中发现了bug，需要从本分支切出bugfix分支进行修改，修改完毕后再合并到本分支。原则上，bugfix分支是不需要合并到develop分支的，但是如果有特殊需求也可以进行合并。

1.3 临时分支

这些分支一般用于修复bug，临时切出，在合并过后会被删除。

1.3.1 hotfix-xxx

用于修复线上发现的bug。

1. 从master分支切出，需要合并到master分支和develop分支。

1.3.2 bugfix-xxx

用于修复测试环境中发现的bug。

1. 从release分支切出，需要合并到release分支。

1.3.3 develop中的bug

1. 在开发过程中发现的bug，不叫bug，属于开发未完成，应该继续切出feature分支进行修改。

2. tag的作用

发版或修复线上问题的时候，需要打tag，tag都打在master分支上。

1. tag一般比api的版本号多一位，多出来的这位表示是这个api的第几次升级。

3. git分支管理的不同流派

常见的分支管理流派有：Gitflow、GitHub Flow、Gitlab Flow三类，它们的区别与论战如下。

1. Git 工作流程
2. GitHub Flow 及 Git Flow 流程使用時機
3. GitHub Flow & Git Flow 基于Git 的两种协作开发模式
4. Gitflow有害论
5. 深入理解 GitHub Flow
6. Gitlab 项目分支管理的一种策略

4. 常见问题

工作中正确的分支处理流程：

1. 从develop分支切出feature分支
2. 在feature分支上进行开发
3. 完成开发以后，push feature分支，提交merge_request到develop分支
4. 如果遇到了冲突，要在本地解决冲突的话，应该先checkout出develop分支，把feature分支手动merge到develop分支，然后把develop分支push到feature分支。
5. 再请管理者处理merge_request。

错误处理一般发生在第4步：
在本地解决冲突的时候，直接把develop分支合并到feature分支，然后再次push feature分支。

这两种处理的代码结果是一样的，但是最终的合并路线图会不一样。

出现错误处理的原因：
处理冲突的人一般是feature分支的开发人员，而不是维护develop分支的管理者。对于开发feature分支的人来说，他们本地打开的是feature分支，错误处理显然更简洁。（如果是由管理develop分支的人处理冲突就不会有这样的问题了，然而位卑言轻的开发者瑟瑟发抖ヽ(`Д´)ノ）

如果由管理develop分支的人处理冲突：
在本地解决冲突的时候，他们本地打开的就是develop分支，直接把feature分支合并到develop分支，然后再push develop分支就可以了。

5. 经验

只要有新功能就及时开新分支，分支不怕多，只要注意两点：

1. 哪个分支上有哪些代码，这个分支最后是要做什么（是要合并到下个迭代，还是给测试加了点日志，最后要不要合并到master）
2. 自己当前是在哪个分支上开发

更好的进行分支管理，需要注意两点：

1. 不用的分支及时清理（已经合并的分支、已经部署的分支、废弃不用的代码）
2. 注意分支命名规则