通俗的说，任何分支策略都可以在一个团队中执行下去，无非使起来好用或不好用。什么好的策略呢？我认为，好的策略有以下几个特点：
- 保证代码安全；
- 版本管理有序；
-
程序员无感知；
前两点往往是我们所追求的核心目标，通过分支管理，将生产代码和开发代码甚至测试阶段的代码区别开，保证各个环境的应用独立。至于程序员无感知，只能说是一个美好的愿望，意思是分支管理清晰，操作简洁。其实一个团队的分支策略会随着团队业务、规模而变化，这里介绍几种分支策略，读者可根据实际情况运用。
主干分支策略
所谓主干分支策略，指的是所有开发人员共享同一个trunk进行开发，当需要发布的时候，可以基于现有的trunk拉出一个新的release分支，进行测试和发布。当然这里会有一个问题，共享分支开发的前提下，拉取分支可能导致无需上线的代码被拉到release分支，所以这个时候，可能需要通过cherry-pick从主干上挑取需要上线的commit。
主干分支策略
这样做的优点很明显，分支结构简洁，但是一旦要上线的时候，就需要相关的开发人员更加仔细，避免多余代码带上生产环境。这里多说一句，网上其他文章有提到“主干分支策略会减少冲突的发生”，我认为可以这么说，解释一下，这里我也拉出一个分支说说冲突发生的原因：不同的提交对同一文件的同一部分（我理解为同一行）进行了不同的修改，则会产生冲突。如果同一文件的不同部分修改了，或者同一文件同一部分修改的内容一样，也不会产生冲突。
文件冲突
拿上图为例，分支1、分支2拉取的base file的第一行都是"aaa"，然而它们各自进行了修改且内容不同（"ddd"，"eee"）这样一来，branch 1如果先提交，它是正常的，而branch 2 提交时，会产生冲突，因为它本以为改的是"aaa"->"eee"，却发现它将要改的是"ddd"->"eee"，故而产生冲突。主干分支策略，天然的决定了trunk上的代码是当前能拿到的相对最新的代码，就像上文提到的branch 1的变更，虽然没上线，但是可能已经上了trunck分支，这样用户如果从master上拉base file改造成branch 2就会造成冲突，而拉取trunk的话就不会。
git flow（最常见的分支策略）
网络上有文章介绍了常见的git flow／github flow／gitlab flow等分支策略，其中github flow多适用于组织性不强的开源项目开发。git flow和gitlab flow可以整在一起讲讲。其实这种git flow方式应该是市面上最具共识的开发方式，扒一张优秀的图：
git flow
朋友先别慌，这图很好理解，最上面分了5个分支，其中两粗三细，意味着develop和master是两个常备分支，而feature branch，release branch和hotfixes是协助分支，也就是说，粗的是一直都在的，而且不会变来变去，细的可能因为场景、开发人数、线上bug数而增多或减少。
开发人员的feature branch来自于develop branch，每当develop branch达到某个稳定时期，或者团队的迭代周期一到，develop上的代码会发布到release branch进行测试，一旦测出有问题，可以直接在release branch做bug fix，当然规范起见，也可以在相应的feature branch上修改了，一层层传递到release branch。当一切测试通过，release branch发布到master。
当然这个过程中会有一些变通，我们可以把develop和release branch都看做测试分支，也就是说，当我们开发完，会经历两个环境的测试，然后上线。这样一说是不是跟实际联系的更紧了。无论怎么变换，这种方式的特点在于：
- feature branch由developer产生，保证了开发人员的基础版本是当前最新的版本（developer上的代码往往是已经提测的代码），最大程度的避免冲突，上文已解释。
-
代码在分支之间一层层的merge，直到发布，这要做的好处是通过机制，减少了误操作，我们当然会对线上安全格外看中，release branch测试通过的代码merge到master，操作简便，不易出错。
是不是怎么看怎么好？git flow的弊端也正是由这两个特点产生的。对于团队迭代严格掌握，各个项目节点严格遵守的团队，这样的策略是没有问题的，但是现实当中也不免有很多小快灵的团队。
git拉取代码
这个图表达的意思是小王和小李都从develop分支拉取代码，小王先拉，也先提交；小李在小王提交后拉取，开发完成之后，小李也提交到develop。这时候测试人员宣布，小李的可以上线，小王的得等等。可这时候，小李的提交可以直接merge到release分支么？不行！小李的提交中带有小王还未通过测试的提交。粗暴的上线不可以，只有cherry-pick，可怕的是，如果小李用到了小王的部分代码，单纯的cherry-pick可能还不能解决问题。所以从develop上拉取feature branch和层层merge对于小快灵或者严格迭代制度的团队不一定适用。
基于feature branch的策略
其实也就是针对上述策略的不足之处，进行针对性的改良，分支结构没什么变化，特别之处两点：
- feature branch来自于master而非develop，这样一来，都是基于当前的生产版本进行的开发，并行开发的分支互补影响上线；
- 所有发布分支（develop, release, master）的部署都和feature branch进行合并，而非层层递进合并；这样做的好处在于，代码发布指哪打哪，不会混带着无关代码。
当然，这样做也有相应的弊端，代码冲突出现的机率比git flow要大，另外由于分支不是层层递进的发布，相当于人的权利更大（因为都是合各自的feature branch），发布安全需要人员的素质和自觉。
以上三种分支策略已经介绍完毕，还是那句话，没有分支策略适用于所有项目或者一个项目的所有阶段。所以我建议的分支策略是：酌情考虑，不行就换。
网友评论