Git分支及版本管理规范
<h3>版本记录</h3>
<table>
<thead>
<tr>
<th>版本号</th>
<th>版本说明</th>
<th>作者</th>
<th>日期</th>
<th>备注</th>
</tr>
</thead>
<tbody>
<tr>
<td>V1.0</td>
<td>Git分支及版本管理规范</td>
<td>Meeler</td>
<td>2018-08-22</td>
<td>修订版</td>
</tr>
<tr>
<td>------------</td>
<td>------------</td>
<td>------------</td>
<td>------------</td>
<td>------------</td>
</tr>
</tbody>
</table>
<hr />
<h2>目的</h2>
<p>规范Git代码库的分支管理和版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。</p>
<h2>Git 分支管理</h2>
<p> 通常每个产品或应用将包括 master、develop、release、hotfix、feature分支，release、hotfix 分支的命名规则分别为：release-<em>，hotfix-</em>。feature分支的命名可以使用develop-v1.1。
![Git各分支关系图](<a href="https://www.showdoc.cc/server/api/common/visitfile/sign/c4e130084f6dccb96f02b775aa9722cf?showdoc=.jpg">https://www.showdoc.cc/server/api/common/visitfile/sign/c4e130084f6dccb96f02b775aa9722cf?showdoc=.jpg</a> "Git各分支关系图")</p>
<p> <strong>master分支</strong>
1.主分支，为整个项目发布代码时使用，会在此分支上打tag。
2.master分支上存放的是随时可供在生产环境中部署的代码（Production Ready state）。
3.master为保护分支，不直接在该分支上进行代码修改和提交；master分支只允许hotfix分支和release分支并入。
4.此分支每次代码更新，都有对应的版本号标签（TAG）。</p>
<p> <strong>develop分支</strong>
1.开发分支，是整个项目开发用的合并代码的总分支，保存当前最新开发成果。
2.一般情况下，如果不存在多版本同时开发的情况，则此分支与feature branches等价。若存在多版本同时开发的情况，则应拉出feature branches进行开发，而不是直接使用develop分支。
3.发布代码前（通过测试且代码足够稳定），需要将develop分支合并入release/master分支。</p>
<p> <strong>release分支</strong>
1.release分支为发布新的产品版本而设计。
2.release分支只允许做小的缺陷修正及维护待发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。
3.release分支仅从develop分支或master分支派生，最后必须合并回develop分支和master分支。
4.develop分支上功能完善且通过测试，可以创建release分支并赋予版本号。</p>
<p> <strong>hotfix分支</strong>
1.热修复代码分支，属于计划外的创建，用于线上紧急代码bug修复使用。
2.hotfix分支从master分支中派生，修复代码bug后，必须分别合并入develop分支和master分支。
3.hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的tag版本派生hotfix分支来组织代码的紧急修复工作。</p>
<p> <strong>feature分支</strong>
1.也被称为topic分，支通常是开发一个特定版本时的开发分支。。
2.从develop分支派生，开发完成后合并回develop分支。例如V1.11的开发分支，用于开发该版本的开发者合并测试使用。确认版本已发布（合并入master分支）后可删除该分支。</p>
<p> <strong>personal分支</strong>
1.开发者私人分支，用于开发者开发时使用，开发完成后合并入feature分支。
2.personal分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。</p>
<p> <strong>bugfix分支</strong>
1.bug修复分支，通常为不紧急的代码bug修复使用。。
2.通常从develop分支拉出，然后修复代码bug后，合并入develop分支。确认bug已修复并且相关代码已合并入develop分支后，可删除该分支。</p>
<p><font color="red"><strong>FBI Warning</strong>：</font>
<font color="blue">所有改动进入feature branches、develop、master分支时，应在gitlab上发起Merge Request，由他人review且没问题后才可合并。</font></p>
<p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/47659ee1881b2eae28c101a45b42b8bd" alt="" /></p>
<h2>版本号管理</h2>
<p> <strong>版本号规则（Tag）</strong></p>
<ul>
<li>
<p><strong>格式</strong> v<主版本号>.<副版本号>.<发布号></p>
</li>
<li>
<p><strong>初始值</strong> v1.0.0</p>
</li>
<li>
<p><strong>大版本变动</strong>
主版本号增加，副版本号和发布号为0，如 v2.0.0</p>
</li>
<li>
<p><strong>新功能开发</strong>
主版本号不变，副版本号增加，发布号为0，如 v1.1.0</p>
</li>
<li><strong>BUG修改</strong>
主版本号不变，副版本号不变，发布号增加，如 v1.0.1</li>
</ul>
<h2>容易冲突的场景梳理及规避</h2>
<p>代码冲突的原因只有一个，同一个文件相同位置的代码有不同的版本提交记录，系统无法自动识别有效的代码记录，所以会提示代码合并冲突，需要人工干预解决冲突。</p>
<h3>1.涉及公共文件的修改，尽量避免直接在头部或尾部代码更新，减少冲突概率</h3>
<ul>
<li>基础配置文件</li>
<li>公共样式文件</li>
<li>i8n文件</li>
<li>枚举类文件</li>
<li>常量类文件</li>
<li>通用接口类文件</li>
<li>工具类文件</li>
<li>统一封装类文件</li>
</ul>
<h3>2. 不同批次需求，针对同一个业务模块不同功能点的迭代</h3>
<p>根据需求，人工比对处理</p>
<h3>3. 公共分支，代码回退，其他人解决代码冲突时将原先回退的代码同步到</h3>
<p>不同的需求使用不同的分支，测试环境分支和生产环境分支隔离</p>
<h3>4. 新的文件命名不规范导致的冲突</h3>
<ul>
<li>同一个目录文件命名一致，但内部内容可能不同，例如 DateUtils</li>
</ul>