Git分支管理规范

基本原则

1. 分支命名不能包含中文，英文不行就用全拼，不要在乎长度。（中文在某些操作系统会乱码，而且对命令行操作、自动化脚本都不友好。）
2. 不同渠道或不同语种的版本，应该通过工程配置来区分打包，用架构设计来消灭“不同版本使用不同分支”的做法。
3. 分支既然叫“分支”，就是要被“修剪”的。达成目的后的分支都该删除，由tag来记录里程碑，否则就像僵尸代码。减少信息量是大型项目和团队提高效率的重要手段之一。
4. 本原则对“多人并行开发，每周发一版”的迭代节奏最有指导作用。如果人少，大可不必用牛刀杀鸡。

命名格式总览

分支类型	命名格式，大括号表示可变	示例
master（主干）	master	master
版本分支	version/{version-code-without-build-code}	version/1.2.3
需求分支	feature/{feature-name}	feature/push-notification feature/login
个人分支	person/{developer-fullname}/{what-for}	person/gongbenwuzang/network-cache person/jimgreen/bugfix-12345-crash
tag	{version-code}/{timestamp}	1.2.3.456/1712031723
特殊分支	special/{what-for}	special/blind-apple special/temp/version/1.0.2

master（主干）

master上肯定是最近一个发布版本的代码。每个版本发布后，从版本分支合并或变基（rebase）而来。

版本分支

在版本立项后开出。需注意分支名中的版本号中不包括构建号（build code），打tag时才包括。 因为有些hotfix或灰度发布并不会修改版本号，只改动构建号。这样的hotfix应继续在该版本分支上开发，并在打tag时用构建号区分。

在版本提测前，所有在此版本发布的需求分支都要合并过来。

正在开发的版本分支可在下个版本发布后删除。例如1.0.0分支应在1.0.1发布后删除，或在1.0.2开出时删除。要找回该版本的代码，应从Tag里面找。实际操作中不删除也可以。

一些公司会习惯把版本分支命名为release/x.x.x。其实这是SVN时代的习惯。统一就好，直接叫version会更明确含义。

需求分支

在快速迭代的开发过程中，需求确立时未必就确定了在哪个版本，所以需求分支名不包括版本号。需求分支可从任何节点开出，为了减少后续合并麻烦，一般基于版本分支开出，或在开发过程中做变基操作。

如果公司的资源足够多，需求分支可在做完本需求的测试后再合入版本分支。

合入版本分支后，此需求分支应删除，在log中体现该需求。

如何优雅地合并分支？

1. 如果当前所在分支有多人参与提交，那么每次拉代码应使用git pull --rebase命令，避免产生很多merge log造成review困难。
2. 在合并回原分支前，先在你的分支对原分支做变基。git rebase original_branch。变基后解决完冲突再push。
3. 切换到原分支，然后git rebase your_branch，这时是应该没有任何冲突，直接push即可。

个人分支

一个需求如果由多个人完成且代码修改范围交集较小，则每个人可以从需求分支开出个人分支做开发，完成后合并回需求分支。合并后，个人分支应删除。

解bug也在个人分支中进行。完成验证后，合并到版本分支并删除。

个人分支也可以用作研究和试验用途。有结论后应把有意义的试验代码通过文档来体现，然后删除此个人分支，否则可能过一段时间后也没人知道这是干嘛的了。

Tag

需注意：tag名包含构建号（如果公司没有灰度发布机制，也可以不要）；时间戳精确到分钟，年不要20前缀。保证信息充足的前提下尽量简短。

tag应该都是从版本分支打出，需求独立提测也可以在需求分支打出。提测或者发布版本时都要打tag。通过时间戳来看哪个是最后一版。

发布后，没用作发布的tag都应该删除。

特殊分支

各种莫(shen)名(jing)其(bing)妙的需求都有，特殊分支还是有存在的必要的，例如做个马甲版。一般特殊分支也是要发布的，但不会多次迭代。如果也迭代了几个版本，那么也可以参考主版本有多级结构。例如special/majia/version/1.0.1。