Git--分支管理策略(Git flow)

说明:
      场景：我们公司的开发阶段主要分为 开发—>自测—>提测—>灰度—>上线 这5个阶段，同时在开发阶段会有多个功能同时开发或一些简单需求的插入。在其他阶段也会涉及到线上bug的修复或紧急发版。

遇到问题：以前团队人数较多，经历两年的积累，Git上遗留了大量的个人分支和版本分支，至今大约有300多个，作为新人的我着实有点慌乱（老员工：“我就问你感动不感动？”。我：“不敢动，不敢动”）。虽然经历了一番调整，目前在用分支数保持在3个左右，但是由于没有成体系的分支管理策略，还是会在一定场景下遇到代码遗漏，分支杂乱，难以定位版本和修改记录的现象。

因此特意参考了几篇文章，针对公司项目开发实践，对Git flow分支管理方式进行实践和总结。如有更佳实践方案，欢迎留言讨论！

简介：
    Gitflow工作流程围绕项目发布定义了严格的分支模型。其特色在于，它为不同的分支分配了非常明确的角色，并且定义了使用场景和用法。除了用于功能开发的分支，它还使用独立的分支进行发布前的准备、记录以及后期维护。（此段为摘抄内容，不再赘述）参考《git flow的使用》

Git flow分支结构图
分支角色说明：
        Git flow中每个分支担任不同的角色，有着不同的功能，以下将结合使用场景，从功能和生命周期两方面进行说明。

master分支

功能：master分支为主干分支，是所有分支的源头。Gitflow中master分支只有一个作用，即记录已发布的版本节点。如需追踪某个线上版本的代码，只需切换到对应标签（tag）即可。

生命周期：master是仓库创建时Git提供的默认分支，随仓库的创建而创建，随仓库的消亡而消亡。当然，可以自行创建master分支取代默认分支，但主分支应贯穿仓库的整个生命周期。

master分支
develop分支

功能： develop分支记录了开发阶段所有的历史提交，用来汇总所有新功能的内容。

生命周期：develop是从master分支上分离出来的分支，可以一直存在，但必须在每次发版完成后，合并master分支上发版的所有内容，或删除develop分支重新创建，总之要保持新的开发版本要以最新发布的上线版本为起点，以保持功能的完整性。

develop分支

feature分支

功能： feature为功能开发的分支。若多人协作开发同一个功能，可以使用同一个feature分支。若有多个不同的功能模块则需建立多个feature进行开发，保证各自功能独立且不受影响。一个模块开发完成后则合并至develop分支，进行功能汇总。

生命周期：当一个新功能开始开发时从develop分支创建feature分支，当功能开发完成后，将开发内容合并至develop，若进入测试阶段有功能遗漏，在该分支修改完成后同步至develop，然后同步至release。待该功能测试完成或顺利发版后，删除该分支，进入下一个开发周期。

feature分支
release分支

功能：release分支为部分或所有功能开发完成后的提测分支，提供测试人员进行自动化打包，开发人员在此分支修复测试期间的bug，该分支创建前需对新功能进行冒烟测试，保证提测质量，尽量做到在release分支上只进行bug修改而非缺失功能开发。若有多个功能需要分批提测，则在develop分支上合并好每个功能后同步至release分支。测试完成后用该分支进行发版，并分别合并至master和develop分支。总结来说该分支有三个功能：1.提测 2.修改bug 3.发版

生命周期：该分支在功能提测阶段从develop分支上创建，经历了 创建—>测试—>灰度—>发版4个阶段，之后将发版的节点打上标签合并至master进行记录。使命即完成，删除该分支即可。

release分支
hotfix分支

功能：hotfix分支主要功能是在新功能开发阶段紧急修复线上bug并进行发版。若非紧急bug则可以直接在develop上进行修复，若对他人模块有影响，则应新建本地分支，修复完成后合并至develop分支，防止遗漏。

生命周期：hotfix分支由master上对应的版本节点创建，修复发版后合并至master，打下tag生成新的版本记录，并将修改内容同步至develop，随后删除该分支。

hotfix分支
注意：
        1.分支管理的策略要根据项目复杂程度、功能并发数、协作开发人数等实际情况进行合理调整，寻找适合自己团队开发的合理策略。做到分支不混乱，代码不遗漏，定位不麻烦即可。

2.分支需要在一定阶段进行合并和清理才能保证分支结构的清晰度以及功能的同步。

3.tag定好格式，提交写清备注才能更好的进行定位和回归。