Git--分⽀管理策略（Gitflow）
说明:
场景：我们公司的开发阶段主要分为 开发—>⾃测—>提测—>灰度—>上线 这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定好格式，提交写清备注才能更好的进⾏定位和回归。
