现代软件开发过程中要完结高效的团队协作，需求运用代码分支办理工具完结代码的同享、追溯、回滚及保护等功用。现在盛行的代码办理工具，包括CVS，SVN，Git，Mercurial等。
比较CVS和SVN的会集办理，Git具有十分明显的优势，例如：去中心化的代码办理方法削减了开发者对中心服务器的依靠，每个成员在本地都有一个完好的代码库，在不联网的状况下也能提交代码；不同于SVN中的每个分支具有独立的代码，Git中的每一个分支仅仅指向当前版别的一个指针，Git的分支战略使创立和兼并分支变得快捷灵敏。
从百度指数，也能够看到Git的优势被越来越多的人所认可。
Git的优势
- Git 能够在本地进行提交以支撑离线作业；
- Git 能够在本地创立分支而且没有命名空间冲突的问题；
- Git 能够让提交经过 Pull Request 的方法进行，不需求全部的开发者都有主库房的写权限；
- Git 在优化功用时挑选了兼并分支作为首要的功用衡量指标，将兼并分支变成了成本十分低的操作以鼓励分支的运用；
- Git 经过 SHA-1 哈希来确保库房中数据的可靠性，经过 SHA-1 就能够对数据进行校验，抵挡了来自攻击者的歹意篡改；
Git作为分布式的代码办理工具，越来越多的团队开端运用它并逐渐替代会集式的SVN 或 TFVC，一起也面对新的应战。
版别办理的应战
我们作业在同一个库房上，那么彼此的代码协作必定带来许多问题和应战，如下：
- 怎么开端一个Feature的开发，而不影响别的Feature？
- 由于很简略创立新分支，分支多了怎么办理，时刻久了，怎么知道每个分支是干什么的？
- 哪些分支现已兼并回了骨干？
- 怎么进行Release的办理？开端一个Release的时分怎么冻住Feature, 怎么在Prepare Release的时分，开发人员能够继续开发新的功用？
- 线上代码出Bug了，怎么快速修正？而且修正的代码要包含到开发人员的分支以及下一个Release?
大部分开发人员现在运用Git就仅仅用三个乃至两个分支，一个是Master, 一个是Develop, 还有一个是依据Develop打得各种分支。这个在小项目规划的时分还勉强能够支撑，由于许多人做项目就只要一个Release, 可是人员一多，而且项目周期一长就会呈现各种问题。
Git代码分支模型
在运用Git办理代码以及多人协作的开发模式下，一个团队乃至一个公司对Git的运用有一致标准的作业流程尤为重要。
开发团队遵从一致的规则履行功用开发，问题修正，分支兼并，版别迭代及发布等操作，能够使团队协作变得滑润顺利，项目有序向前推动，我们把安排内这样的作业流程（workflow）称为Git代码分支办理模型
主流的git代码分支办理模型：
- Git flow
- GitHub flow
- GitLab flow
- TBD flow
1. Git flow
Git flow存在两个长时刻的独立分支：主分支master和开发分支develop，
- 主分支: 用于版别发布，主分支的每个版别都是质量安稳和功用完全的发布版。
- 开发分支: 用于日常开发作业，存放最新的开发版代码。当开发分支的代码到达安稳状态并能够发布版别时，代码需求被兼并到 master 分支，然后标记上对应的版别标签（tag）。
假如需求开发新的功用或许处理代码中的问题，则创立辅佐分支来处理问题，辅佐分支常用于：
- 功用开发（Feature），
- 版别发布（Release），
- 问题修正（Hotfix），
在辅佐分支上的作业完结后，辅佐分支将被删去。
Feature分支
意图是开发新模块或新功用以满意客户需求，从develop分支创立，开发结束后只需求兼并回develop分支，并不需求兼并回master主分支。
Release分支
是用于预备发布的版别分支，从develop分支创立，创立时现已包含了发布所需求的全部功用，所以在这个分支上不再开发新功用，仅对这个预发布版别进行修正问题，创立文档及其他与发布相关的作业，全部安排妥当后将Release分支兼并回master主分支并打上相应的版别号标签（Tag），一起也兼并回develop分支。
创立独自的Release分支能够防止在不同发布版别上的作业彼此受影响，例如团队A预备发布版别1.0的一起，团队B正在进行版别1.1的功用开发，二者彼此独立，不会彼此影响。
Hotfix分支
一般用于紧迫修正当前发布的版别中呈现的严峻问题，从发布版别的标签或master主分支创立，问题修正后兼并回master主分支并打上新的版别号标签（Tag），一起也兼并回develop分支或许正在进行中的Release分支。
创立独自的Hotfix分支能够防止打断正在进行中的各项开发作业，客户也不需求比及下一个发布周期才干拿到修正。
长处&缺点
Git flow需求一起保护两个乃至更多分支，Hotfix分支从master创立，Release和Feature分支从develop创立，作业完结后又需求将代码兼并回 develop 和 master。
在实际使用中，许多开发者会忘掉兼并回 develop 或许 master，而且各辅佐分支之间彼此独立，假如从master上pull代码不行及时，一方面或许形成某个分支长时刻运用现已过期或许错误的代码，另一方面假如与master相隔较远，兼并分支时或许会有大量代码冲突，往往需求花费许多时刻来消除代码冲突，而且十分简略出错，影响项意图继续集成。
Git flow的长处在于流程清晰，分支办理严格，适用于发布周期比较长的“版别发布”，发布周期或许是几周，几个月，乃至更长时刻。
由于保持两个长时刻分支同步的开支较大，所以Git flow并不适用于快速的“继续发布”，ThoughtWorks还专门将Git flow列为不被引荐的技能，建议彻底停止运用。
综合考虑了开发、测验、新功用开发、暂时需求、热修正，理想很饱满，现实很骨干，这一套运行起来实在是太杂乱了
2. GitHub flow
GitHub flow是由Scott Chacon于2011年提出的代码分支办理模型，这是GitHub官方引荐的开发流程，以快速布置为方针，现在大部分开源项目都遵从这一流程。
Github flow最大的特色是只要一个长时刻分支，即主分支master，且主分支始终保持可发布状态。
从master上创立新分支进行功用开发、问题修正等，这些分支经过pull request将代码兼并到master。为了确保主分支的代码质量，master的权限只开放给一部分人。
Pull request是恳求他人pull你的代码库（repository），也便是把开发分支的代码经过代码评定并经过测验后，让有权限的办理员兼并回master。
不过在实际状况中，代码评定不或许检查出提交的代码中的全部问题，所以对于每次提交的代码进行自动化测验，
主分支代码的自动化布置特别重要，自动化测验能在产品布置前及时发现一部分问题，假如产品布置之后发现严峻问题，自动化布置能够在最短时刻内把产品回滚到上一个版别。
长处&缺点
Github flow的长处在于流程简略灵敏，不需求考虑及办理太多的分支，适用于需求快速集成及“继续发布”的项目，这类项目或许需求每天发布一个版别，乃至一天发布多个版别。可是对于使用场景比较杂乱的状况，例如：多个环境下的产品布置，多个版别的发布或问题修正，只要一个master便会显得力不从心。
github flow这种方法，要确保高质量，对于贡献者的素质要求很高，换句话说，假如代码贡献者素质不那么高，质量就无法得到确保。
3. Gitlab flow
GitLab flow是由GitLab 的 CEO Sytse Sijbrandij 于 2014 年正式发布的代码分支办理模型，归于GitHub flow的演进版别。
与GitHub相同之处是也存在一个长时刻主分支master，从master上创立新分支进行功用开发、问题修正等，结束后兼并回master。
与GitHub不同之处是GitLab flow又考虑多环境布置等现实要素，添加production产品分支用于在不同的环境下布置产品，或许从master的安稳版别创立release发布分支用于发布软件。
假如在产品分支或许发布分支发现问题，就从对应版别分支创立修正分支，修正完结之后，GitLab flow遵从 “上游优先” 的兼并战略，也便是将代码先兼并到 master，再兼并到下游的production或release分支。
和Github flow类似，master的修改权限只开放给部分人，开发分支的作业完结后，代码经过merge request（类似于GitHub flow中的pull request）恳求有权限的办理员把代码兼并（merge）回主分支
4. TBD flow
TBD (Trunk-based Development) flow是由Paul Hammant于2013年提出的模型。
TBD flow最大的特色是全部开发都依据骨干trunk，不再有长时刻的开发分支，要求全部的提交赶快回到骨干，这样能够同享最新的代码，而且能尽或许地削减兼并冲突。假如需求发布版别，能够依据trunk直接生成新的分支用于发布。
TBD flow没有pull或许push request，要求开发人员赶快把代码提交到骨干分支，可是TBD flow缺乏严格的流程来确保每一份提交代码的质量，假如一些项目开发人员很多且水平纷歧，一起作业在主分支上或许会在产品发布时才发现不行预知的问题，
所以TBD flow更适用于需求快速迭代的产品，假如在骨干分支上发现问题，能够快速进行修正再兼并回骨干分支。
5. TBD++ flow
TBD++ flow以灵敏开发为核心，一起吸收了以上几个主流模型的长处，首要特色如下
1. 依据功用的主分支
只存在一个长时刻的独立分支，即主分支master，主分支上功用完全，经过自动测验确保基本功用运行正常，由于自动测验掩盖不全面或许手动测验不及时，所以无法确保主分支的每个版别都是质量安稳的发布版，可是能够依据功用的完结程度直接从主分支上创立迭代版别用于针对不同客户或许纷歧起期的功用演示。依据master开发功用或许修正问题需求用到以下两个辅佐分支：
- Feature分支：为了开发新模块或新功用以满意客户需求，从主分支上创立Feature分支，可是并不要求Feature分支上全部的提交赶快回到主分支，开发完结而且经过代码评定及功用测验后才干兼并回master主分支。为了共用主分支上的最新代码以及防止兼并代码时处理代码冲突引起的额外开支，在功用开发过程中Feature分支需求始终与master保持同步。
- Bugfix分支：依据主分支创立Bugfix分支修正主分支上发现的问题，修正完结而且经过代码评定后代码兼并回master主分支。
依据主分支的Feature分支和Bugfix分支完结后，开发者直接将代码兼并回主分支master，不需求像GitLab或GitHub那样依靠于少数几个有权限的办理员，这是由于假如一个项目中开发人员比较多的话，办理员没办法做到对每部分代码都了解或掌握，所以代码质量交由代码评定和功用测验来掌控，兼并代码回主分支的操作由开发者自己完结。
主分支上的新代码有时分或许由于评定或测验不全面而带来新问题，例如损坏其他功用模块，乃至影响全体功用。为了能尽早发现问题，主分支上的每次提交都会触发体系级自动化测验，而且周期性地对主分支进行人工测验。一旦发现问题，主分支的专职装备办理员（Software Configuration Manager，SCM）将依据问题的严峻性和紧迫性决议是否需求直接回退引起问题的提交，或许依据master创立bugfix分支进行问题修正。
2. 依据发布的Release分支
Release分支担任对外发布软件产品，每个Release分支也会装备专职版别装备办理员SCM，SCM具有对Release分支的最高办理权限。当master上现已包含了某个发布所需求的全部功用，而且没有已知的严峻问题，此刻由SCM从主分支上创立Release分支预备体系集成测验，和Git flow相同，在此分支上不再进行新功用的开发，仅在这个分支上进行修正问题，创立文档，客户参数装备及其他与发布相关的作业，这些代码一起也需求兼并回master以确保主分支功用的完好性。
在每个Release分支正式发布前或许还需求将主分支上的一部分关键问题的修正挑选性地同步（Cherry-pick）到Release分支，这个操作也是由SCM完结。
Release分支上的作业全部安排妥当并经过体系集成测验后，SCM在Release分支上打上相应的版别号标签（Tag）进行发布，这点和Git flow在主分支上进行发布不同。
软件产品发布之后，假如发现紧迫或许严峻的问题，此刻需求依据版别发布时的Release分支标签创立Hotfix分支来修正此类问题，问题修正后兼并回该Release分支以及其他相同需求此修正的Release分支，并打上新的版别号标签（Tag）用于发布，一起代码也需求兼并回master以确保主分支的健壮性。
挑选适宜的分支模型
Git代码分支办理模型各具特色，流程仅仅一个辅佐工具，没有最好，只要最适宜。
- 假如开发团队规划较小又比较分散，产品发布周期较短(例如:草创公司，或许开发的是一个网站或 Web 使用程序，在一天内或许需求发布多个版别)，能够挑选GitHub flow或许GitLab flow；
- 假如开发团队规划较大，产品发布周期较长(例如:团队超越20人，采用了月度或季度发布周期，而且由一个团队担任并行开发多个项目)，能够挑选Git flow，发布周期较短能够挑选TBD flow；
- 假如开发团队规划大，产品发布周期长，一起对灵敏的要求比较高，能够考虑TBD++ flow。每个安排依据产品、项目、人员的特色找到最适宜的模型才是共同的方针。对于某个长时刻产品的开发和客户版别保护场景，这种分支是笔者比较引荐的。
以上这些分支战略，仅仅是作为我们实践的参阅，不同的开发模式和发布节奏，以及团队的人员水平，基础设施水平等都是挑选分支模型的参阅要素。
参阅
- 无需分支依据骨干的开发是团队健康的重要标志www.infoq.cn/article/tFw…
- 别再引荐 Git Flow 了：www.infoq.cn/article/i7m…
- 一个成功的Git分支模型(译文)：segmentfault.com/a/119000001…
本文正在参与「金石方案」
