本文主要是介绍git管理历险记，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本篇文章主要是记录一下公司内git管理策略的变更，又如何因地制宜的磨合出适合团队的方法论，以便未来的职业生涯遇到类似的问题可以稍微触类旁通下。
传统git策略
dev -> test -> pre -> main
这也是比较经典的一个环境对应一个分支，许多没有并行开发需求的公司都会使用这个。
但是开始并行开发多个需求就遇到了问题：
所有代码都在环境分支上开发，可能导致dev、test分支修改过多堆积，真要上pre或生产时总要花费很多精力去整理或解决冲突。
并且，如果原本说好一起上的多个需求，有某个需要先上则会需要再单独切分支处理，测试的时候环境也需要单独切到这个分支使用，非常麻烦。
解决方案：
- 每个功能都有单独的分支
- 在test可以替换为feature-join分支 *
- 收回随意修改部署环境分支的权限
*: feature-join为集成测试分支，用于多个需求同时测试但是不同时上线的情况。
最终流程为：
基于main签出新的功能分支 -> test/feature-join -> pre -> main
更适应变化的策略
经过调整冲突比之前少了，但是只是少了dev的部分冲突，在test和pre上还是会存在分支环境不同导致的合并问题。正好公司在推行敏捷开发，以迭代形式上新功能及修复，正好以另一种方式改动策略。
如下图：
前提：目前我司只有两个环境供使用、实行敏捷开发有极多并行开发的合并操作、有许多提前上线需求、需求不清晰
基于这些前提，我们能确定是一定要能够尽可能不影响单独功能上线以及解决并行开发冲突
先来解释下图中各个步骤：
第一，也是最核心的一点，从main签出一条publishable分支，使用这个分支当防腐层的作用，只有确定上线的需求才会合到这个分支。
第二，从刚签出的publishable分支签出一条迭代分支，在敏捷开发的一个版本迭代功能需求，全部都会合到这个分支里。
第三，从刚签出的迭代分支，签出自己开发的功能分支，功能分支开发完成后合到迭代分支上面一起上环境测。
如果有紧急的生产bug需要处理，则是从publishable拉hotfix新分支修改，然后hotfix合到预生产测试。
如果要上生产，则是先将对应分支先合到pubulishable，再确认，然后publishable再合到main。
其实跟dev-pre-main-release这种有共通之处，只不过充当防腐层的分支换了个名字，毕竟在分支管理的策略上其实来来回回也就那么几个操作。但是还有种上家使用的分支策略可以推荐给大家
较严谨的策略
这种策略就是维护一个长期分支 release，流程大概为：
从release拉出新分支，基于上一个已打出的版本，判断更新重要性增加版本，如：2.0.1 -> 2.0.2/2.1.0 等，使用三段式版本，大家都在这个版本分支上开发。
测试预生产和生产也都使用版本分支上环境，上生产时会合一份进release。
因为这种策略基本只是用一个分支，所以对于团队对每个迭代的工作量把控要求很高、不能有很多需求变化，但也最大程度避免了合并的问题，即使有冲突也会第一时间解决，合并出了问题每次上环境都会极快暴露并修复。
总结
那么可以稍微比较一下：
如果团队较小，项目不大，那么直接传统策略就好了，一般也碰不上冲突。就开发工期长变化大的时候开分支都行。
如果团队较大，对于项目开发的需求不明确，时常有部分需求先上或不上的情况，那么就用适应变化的敏捷策略。
如果对项目开发需求很清晰，工期也把控的准，对外交付可以版本迭代的形式，那么更推荐严谨的敏捷策略。
这篇关于git管理历险记的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
