git分支管理规范

git分支管理规范

公司团队特点：

以下特点是有部分是假设性，部分是实际的：

• 一个功能的开发大概在1到3人，或者4到5人之间。
• 大部分人对git的熟练程度不高，缺少Git分支管理知识培训或者不希望在Git分支管理上花费太多时间培训。
• 弱化Git分支管理标准的作用，以灵活应对各种需求。（减少规范而引发纷争从而影响开发进度，毕竟Git是很强大的工具，依赖工具，而不依赖文字约定）
• 需要提供几种场景的Git分支管理场景

约束

这里的约束是指无论哪一种场景，以及开发规模大小都必须要遵守的一些Git分支管理规则：

• Master分支必须时刻保持与线上分支一致。
• 合并Master上的代码必须要经过评审。

场景一 - 1到2人开发

只需要一个Master分支，然后各自创建自己的分支名为：dev-拼音简写-feature（FixBug）名称 ,如: dev-zhang3-userreg,双发约定好评审方式和Merge规则就好，然后在开发完成后Merge and push 到主分支即可。理论上建议开发好的代码不要直接合并到master分支，而是应该先合并到dev分支，自测通过后，再合并到Master,确保master分支每次改动都伴随一次发布操作，这样线上代码就可以和master分支永远保持一致了。这一点只是建议。

场景二 - 4到5人以上开发

这种适合采用复杂分支管理策略，具体需要创建如下分支：

分支划分如下：

master：与线上版本保持绝对一致；
develop：开发分支，由下文提到的release、feature、hotfix分支合并过后的代码；
feature：实际功能点开发分支，建议每个功能新建一个feature， 具有关联关系的功能公用一个feature分支；（如果不存在多个需求功能同时开发，即，每次开发只由一个单一的需求，那么该分支可以不需要出现，而是直接再develop分支上checkout出来开发就好。如果觉得该分支管理复杂，建议不要引入这个概念。）
release：每一次开发完成之后，从develop创建出来的分支，以此分支为基准，进行测试；（该分支可以不需要，直接将develop分支部署到测试服务器上测试）
hotfix：该分支主要用于修复线上bug；（该分支可以从master,develop,feature等任意分支checkout出来，并快速修复BUG后合并回去源分支）

commit时的注释：

commit的注释不能不填，建议简单扼要的描述别人能看得懂的注释即可。

关于分支的删除

原则上应该勤劳的删除不必要的分支，以免保留奇奇怪怪的分支给同事造成困扰。

关于换行符

避免在合并代码评审时造成困扰，建议开发前调整好代码编辑器的换行符，建议统一为Linux标准的换行符即LF（而不是CRLF,也不是CR）。

结语：

总体上来说，master分支和develop分支是相对来说比较有必要存在的，可以应付80%的开发场景。也是我比较推崇的，其他概念按需要灵活和开发小组自行约定就好。

警示语：

不要执行你不懂的Git命令