共计 4949 个字符，预计需要花费 13 分钟才能阅读完成。
简介：团队研发的实质并不是团队规模越大，研发的效率就越高。咱们认为团队规模越大，研发效率就会越高，能够做越多的货色，然而咱们发现团队规模大到肯定水平，整个研发效率是会降落的，甚至降得十分快。为什么团队的规模越来越大，咱们的公布反而越来越慢了？
策动 & 编辑|雅纯
团队研发的实质
咱们已经接触到一家企业，它一开始只有 8 集体，那个时候每个月都能够发一两个版本进来，客户都能够用到，因为他们是做医院的信息管理 HIS 零碎。他们感觉做得还不错。起初团队倒退比拟快，规模到了 80 人左右，却半年没发一个版本。这导致施行团队没脸见客户，因为客户说半年前提的需要怎么还发不进去。
这个时候悖论就来了：咱们认为团队规模越大，研发效率就会越高，能够做越多的货色，然而咱们发现团队规模大到肯定水平，整个研发效率是会降落的，甚至降得十分快。
站在团队的角度来说，因为人多，合作越来越慢，合作的老本也越来越高。咱们发现团队的研发模式，人越多越会有问题，因为抵触更多，期待更多。这里抵触是指代码集成公布过程中的抵触，而期待也是集成和开发过程中代码彼此的期待。
以下是两个具体的场景。
假如有两个程序员 A 和 B 一起工作，A 一开始每次提交都把工作逐步胜利提交到线下来，而后 B 提交了一个版本，导致编译失败了。这时，A 就无奈提交，因为提交就会挂，要期待 B 修复问题能力提交，这时 A 的提交和 B 的工作就产生了抵触。
第二种状况，多个分支往同一个分支合并，FeatureA 先合进骨干，FeatureB 晚了一点后果发现无奈合并，因为基线不一样了，这时候必须先解决掉代码抵触能力合进去。
如上图，假如当初有 3 集体，A、B 和测试 C，每个人的点代表它做的工作，比方 A 始终在做本人的事件，每实现一个事件就开始做下一个事件，做完第三个事件的时候他感觉须要去找 B 联调一下，就给 B 发了一个 ping，然而 B 有本人的节奏，在忙他本人的工作，所以并未马上响应 A 的申请。他发现有一个工作能够提测了，他就通知了 C，C 发现有问题就马上 Pong 了回去，然而这时 B 在忙另外一个工作，没有响应。C 发现 B 无响应，又发了一次 Pong，这时 B 看到了 A 和 C 的音讯，他先解决了 A 的事件，给 A 回复了一个 Pong 的音讯。
咱们发现，程序员和程序员，测试人员和开发人员之间，在整个的开发合作中其实是异步的、提早合作的过程。每个人并不是收到一个申请就马上回复，马上合作，往往都是有本人的步调和本人的动作，可能会产生提早。所以当产品更简单，合作更多，团队更简单，团队的人多了当前，合作老本就会疾速回升。
在这样一个异步的、提早合作的过程中，程序员面对日常开发的工作，须要有一套相应的研发模式，来保障在合作过程中可能继续地把信息同步掉，并疾速地响应掉。
软件交付过程，实质是开发者围绕代码库的合作过程。无论是产品代码、配置、环境和公布流程，都能够通过代码来形容，并保留到代码库里。
因而，研发模式的目标就是束缚咱们在围绕代码库工作时的行为，实质是一种围绕代码库的行为束缚。
研发模式咱们广义地了解为分支模式，蕴含一系列的行为束缚，比方分支类型及其标识、分支的生命周期、Commit 在分支间的流转形式，以及流转的约束条件，还有分支和代码之间的对应关系等。接下来咱们会一一探讨。
研发模式是一系列研发行为的束缚，指标是防止抵触、缩小期待。在合作的过程中，人多了之后带来的最大的问题就是抵触变多、期待变多，所以好的研发模式应该尽可能的防止抵触，尽可能的缩小期待。
首先看一下研发模式和研发行为之间的对应关系。
这些研发行为和代码库行为有一个 Mapping（映射）关系。开始新的个性开发时，咱们会创立一个新的个性分支。做一次代码的提交集成，其实就是一次 Commit 和 Push，实现之后进入集成验证，就做了一次分支的 Merge。
同样地，集成完进入待发布也是在做 Merge，而实现公布意味着打一个 Tag。代码库里的操作记录了咱们的研发行为，所以研发行为和代码库的操作能够做到一一映射。
要防止抵触，惟一的办法是大家彼此隔离，离开就没有抵触。在代码库外面，很多时候通过分支的形式，来做工作之间的隔离，防止抵触。
要缩小期待，而期待是信息不同步造成的，尽可能地做到信息同步，就不必期待。在代码外面的期待，是代码之间基线的同步，比如说频繁地提交。所以其实分支是用来防止抵触和做工作隔离，而频繁地提交合并是为了做信息同步，缩小期待。
Q: 如果是一个人做软件开发，用什么样的分支模式？一个人会不会有抵触？
一个人做软件开发的时候是不会有抵触的，一个人工作的时候不须要很多分支，一个分支就足够。一个人做开发，也不必期待信息，因而能够一条骨干走到底。然而如果人数扩张到 10 人、100 人，彼此之间就会有工作的隔离，彼此之间也会存在着抵触，也存在着期待。所以在这个过程中，随着合作的人数越来越多，分支的模式会一直地发生变化。
4 种常见分支模式解析
骨干开发
团队人很少（比方 1~2 集体）的时候，最常见的研发模式是 Trunk—BasedDevelopment，也叫骨干开发方式。
骨干开发方式一条骨干分支走到底，开发的过程中不会有太多的抵触，要求代码继续集成到骨干下来，所以在开发过程中不须要做相应工作的隔离。开发的过程中，所有的开发者在骨干下面频繁地提交，频繁地集成。这种分支模式下，惟一的分叉呈现在公布的时候，为了可能把公布版本隔离进去，有了公布分支。
这种模式下，不须要做分支隔离，信息同步通过继续频繁地提交来保障。在人数比拟少，并且整个工程能力比拟强的时候，这是咱们举荐的研发模式。
然而当参加开发的人数越来越多时，骨干开发的抵触几率就大大增加了，对工程能力的要求也越来越高。
所以说骨干开发不是万能药，骨干上的人越多，代码提交的抵触机率就越大，而且解决抵触的危险也越大。如果两个人的时候，即使有抵触我晓得只是和另外一个人有抵触，如果是 10 集体，这两头就会产生很多的问题。
另外在骨干开发外面，要放弃信息地同步，须要做频繁继续地提交，而且每次提交的力度要很小，这针对有一些个性来说，可能只做了一半，这时须要将它提交下来，须要通过个性开关等形式来进行隔离。比如说这个是还未实现的个性，提前把它的开关制成 Off，再做相应的提交，然而个性开关实质上也是一个分支。
个性开关只是用代码的模式拉了一个分支，然而这个分支只有关上的时候能力跑到，实质上还是一个分支。如果个性开关比拟多，它在肯定水平上会把代码变得很软弱，保护起来比拟麻烦。
骨干开发当很多人同时参加时，代码抵触的机率很大，而且个性开发的时候也有很多的危险，大家彼此之间须要隔离。
Git-Flow
Git—Flow 的根本准则是须要什么分支就给什么分支，任何事都有很明确的分支。比如说要集成，就有 develop 分支，要开发就有 feature 分支，要公布有 release 分支，每个都是不同的分支。每种类型的分支都有确定的用处。
比如说 feature 分支，是很多个 feature 并行开发的时候用来去做工作隔离，防止彼此之间有抵触。而 release 分支是用来做公布的隔离，使得公布之间不会有抵触。
咱们发现这种模式很好地做了隔离，然而在信息同步的过程中，它须要基于 develop 频繁地集成去做同步，并且在各个分支两头做相应的 cherry-pick 或者是 rebase 这样的形式来做的。
这个时候，咱们就会发现分支太多，而且一个 commit 从 feature 开发到最终公布要经验好几个分支，其中分支的流转和 merge 规定十分麻烦。
所以 Git—Flow 也不是仙丹，过多的分支减少了分支治理的复杂度。还有如果 Feature 分支的生命周期特地长，它的合并耗时也会变得很长。而且 Develop 分支和 Master 分支同时存在，如同 Develop 分支的意义不是特地大。另外辨别 Feature 分支和 hotfix 如同意义也不是特地大。
所以 Git—Flow 尽管减少了很多的分支，让各种工作尽可能地隔离开来，然而它信息同步是很麻烦的，而且它治理这些分支的难度也特地大。
GitHub-Flow
GitHub 引入了一个分支模式叫 GitHub—Flow, 显著比 Git—Flow 简略很多。没有 Develop，没有 hotfix，也没有 Release，当须要开发的时候拉一个 Feature 分支，开发完就合并 Master 做公布。
这个过程中，它的隔离只产生在开发过程中，它的信息同步通过继续地往 Master 去做集成，和频繁从 Master 外面 Pull 代码来实现。它的公布过程是基于骨干 Master 分支做的，因而没有在公布的过程中做相应地隔离。
这时候又会带来一个问题，就是 Master 分支须要做继续集成，这个分支既是集成的中央也是公布的中央。一旦集成后呈现问题，它会把所有的工作梗塞掉，无奈公布也无奈合并。
所以 GitHub—Flow 很简略，能够做相应地隔离，然而如果说自身基础设施或工程能力比拟弱，它会限度你集成和公布的频率。
GitLab-Flow
GitLab—Flow 和 GitHub—Flow 区别是在公布过程中有了 Pre-production 分支和 Production 分支，基于开发、集成和公布过程中不同的环境调配了相应的分支。
实现集成当前是在 Master 分支上，上面一步将会切换到预发分支上。对应 Commit 的版本曾经达到了预发的条件，在预发上做完验证当前再将其同步到 Production 分支，阐明它曾经达到了公布的条件，所以它是逐级 Promotion（升级）的过程。逐渐从集成的环境 Promotion 到预发环境，再 Promotion 到生产环境。
咱们简略地介绍了一些常见的分支模式，上面咱们再来比拟一下他们之间的优劣。
常见分支模式优劣比照
TBD 分支少，施行简略，做起来不须要太多的了解老本。然而它对团队合作的成熟度和纪律都有很高的要求，一旦有人不遵守纪律，那骨干就会成为你的梦魇，这时就很难很好地去做继续地集成和公布了。一旦它呈现问题，所有人都被 Block，这是骨干形式的优缺点。
Git—Flow 个性之间能够并行开发，规定很欠缺，每个分支的职责特地明确，再大的团队合作基本上也不会有太多的问题，然而它分支太多，规定太简单，而且分支生命周期长，合并抵触会比拟频繁。尤其是 Develop，Master 是长期存在的。
对于 GitHub—Flow，Git—Flow 能反对的基本上它也能反对，然而这外面有一个问题，它的集成只有在 Master 分支去做，因而对集成纪律有很高的要求，而且集成和公布在一个分支上，一旦集成分支中断，无论是集成还是公布都会被中断。
Gitlab—Flow 也是并行开发，然而开发分支还是会有生命周期长的问题，有合并抵触的危险。另外，公布分支之间是有耦合的，比如说 Prodution 和 Pre—Prodution 之间，是基于 Promotion 来耦合，所以彼此之间也是一种中断阻塞的形式，而且很多的开发分支，Prodution 和 Pre—Prodution，也减少了分支治理的复杂性。
因而，咱们发现没有哪个分支模式是相对好的，也没有哪个是相对差的。
对于分支有一个简略的准则，即管制分支数目，小批量频繁集成。管制分支的数目也就是做到工作隔离，然而又减少太多治理老本。而小批量频繁集成能够减速信息同步。
所以一个简略的准则就是，从最大化生产力和最小化危险的角度，尽可能地管制分支的数目和小批量频繁集成。
最大化生产力：所有人工作在公共区域内。除了一条长期的，不被中断的开发骨干外，没有任何分支。也并无其余规定，代码的提交过程相当简略。然而，每一次的代码提交，都有可能毁坏整个我的项目的集成，进而导致我的项目进度的中断。
最小化危险：所有人都工作本人的分支上。每个人的工作是互相独立的，没人能够打断其他人的工作，这样，缩小了开发被打断的危险。然而，这种做法却减少了额定的流程累赘，同时，合作变得十分艰难，所有人都不得不谨小慎微地合并本人的代码，即使是整个零碎中十分小的一部分，也是如此。
那么怎么设计或抉择适宜本人的分支模式？下一篇文章，咱们将持续分享，不同的团队如何抉择适宜本人的研发模式。
[
原文链接 ](http://click.aliyun.com/m/100…)
本文为阿里云原创内容，未经容许不得转载。
