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。
因为这种策略根本只是用一个分支，所以对于团队对每个迭代的工作量把控要求很高、不能有很多需求厘革，但也最大水平制止了归并的问题，即使有冲突也会第一时间解决，归并出了问题每次上环境都会极快暴露并修复。
总结

那么可以轻微比力一下：
如果团队较小，项目不大，那么直接传统策略就好了，一般也碰不上冲突。就开发工期长厘革大的时间开分支都行。
如果团队较大，对于项目开发的需求不明确，时常有部分需求先上或不上的环境，那么就用顺应厘革的灵敏策略。
如果对项目开发需求很清晰，工期也把控的准，对外交付可以版本迭代的形式，那么更推荐严谨的灵敏策略。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。