最近，团队招募了一些新的小伙伴。在开发过程中，他们问我Git分支是如何管理的，如何提交代码？粗略的说了一些规则，但是仔细想想，好像还没有形成一个清晰规范的流程。于是查了一些资料，总结了下面这篇文章，分享给大家。在这种模式下，Gitflow主要维护两类分支：主分支（Themainbranch）masterdevelop辅助分支（Supportingbranch）特性分支（functionbranch）发布分支（pre-releasebranch）hotfix分支（hotfixbranch）master首先，代码库应该只有一个master分支。master分支的代码始终稳定，可以随时发布到生产环境。developdevelop分支用于日常开发，保存开发过程中的最新代码。当develop分支上的代码稳定并准备发布时，您需要将develop代码合并到master中并标记发布版本号。创建develop分支：gitcheckout-bdevelopmaster合并develop为master：#切换到master分支gitcheckoutmaster#合并develop分支gitmerge--no-ffdevelop--no-ff参数的作用是使当前的合并操作总是创建一个新的提交对象，即使合并是作为快进合并执行的。这样可以避免丢失功能分支的历史记录，并将该功能的所有提交汇集在一起??。这个解释不是很容易理解。对比下图更明显：featurebranchsource:develop合并到branch:developbranch命名约定：feature-*functionbranch，开发新功能时，从develop分支分离，开发完成后，它被合并回开发分支。特性分支通常只存在于开发者的本地仓库中，不包含在远程仓库中。创建特性分支：gitcheckout-bfeature-xdevelop开发完成后，将特性分支合并到develop分支中：gitcheckoutdevelopgitmerge--no-fffeature-x删除特性分支：gitbranch-dfeature-xreleasebranchsource:develop合并成branch:develop,master分支命名约定：release-*pre-releasebranch，指正式版发布前的预发布版本，我们可能需要有预发布版本测试，我们可以对其进行一些小错误修复。预发布分支与开发分支分开。预发布结束后，必须合并到develop和master分支。创建预发布分支：gitcheckout-brelease-1.2develop确认没有问题后，合并到master分支：gitcheckoutmastergitmerge--no-ffrelease-1.2#为合并生成的新节点，打个标签gittag-a1.2然后合并到develop分支：gitcheckoutdevelopgitmerge--no-ffrelease-1.2最后删除预发布分支：gitbranch-drelease-1.2hotfixbranchsource:master合并到分支：develop、master分支命名约定：hotfix-*最后是bugfix分支。软件正式发布后，难免会出现bug。这时候就需要创建一个分支来修复bug。bugfix分支是从master分支派生出来的。修复完成后会合并到master和develop分支。创建bug修复分支：gitcheckout-bhotfix-0.1master修复完成后合并到master分支：gitcheckoutmastergitmerge--no-ffhotfix-0.1gittag-a0.1.1然后合并到develop分支：gitcheckoutdevelopgitmerge--no-ffhotfix-0.1最后删除并修复bug分支：gitbranch-dhotfix-0.1总结优点：各分支权责分明，清晰可控，是一种启蒙许多分支机构管理策略的模型。缺点：合并冲突：可能同时存在多个长期存在的分支：master、develop、release、hotfix，以及几个并行的特性分支。任何两者之间都可能发生冲突。频繁的手动冲突解决不仅增加了工作量，也增加了出错的风险。功能分离：功能并行开发时，合并后的功能不能在合并分支前进行测试，合并后可能会相互影响。无法持续交付：Gitflow更倾向于按计划发布。一个特性需要经过很多步骤才能发布到正式环境，很难满足持续交付的要求。无法持续集成：持续集成鼓励更频繁的代码集成和交互，尽早解决冲突，而Gitflow的分支策略隔离代码并尽可能延迟代码集成。GithubflowGithubflow是一个轻量级的基于分支的工作流。它由GitHub于2011年创建。分支是Git中的一个核心概念，GitHub工作流中的一切都基于它。它只有一个long-termbranchmaster，在其上创建其他分支。使用过程如下：根据需求，从master拉取一个新的分支，不区分功能分支和修复分支，但需要给出描述性的名称。本地更改直接提交到该分支，该分支会定期推送到远程存储库上的同名分支。新分支开发完成后，或者需要讨论时，向master发起PullRequest（简称PR）。PullRequest不仅仅是一个让别人注意到你的请求的通知，更是一个大家共同审阅和讨论你的代码的对话机制。在对话过程中，您还可以不断提交代码。你的PullRequest被接受，合并到master，重新部署后，你原来拉出的分支被删除。总结：优点：降低了分支管理的复杂度，更适合小型团队，或者维护单一版本的项目开发。工作流对持续交付和持续集成简单友好。缺点：无法支持多版本代码部署。Gitlabflow是Gitflow和Githubflow的结合。吸收了两者的优点，既具有适应不同开发环境的灵活性，又具有单一主干的简单方便。Gitlabflow和Githubflow最大的区别在于Gitlabflow支持环境分支。Gitlab流程最大的原则叫做“上游优先”，即master分支只有一个master，是所有其他分支的“上游”。只有上游分支采用的代码更改才能应用到其他分支。Gitlab流程分为两种情况，以应对不同的开发流程：持续发布版本发布持续发布对于持续发布的项目，建议除了master分支之外，还要建立不同的环境分支，每个环境都有对应的分支。比如开发环境的分支是master，预发布环境的分支是pre-production，生产环境的分支是production。开发分支master用于发布到测试环境，是一个受保护的分支。预发布分支pre-production用于发布到预发布环境，上游分支为master。官方分支生产用于发布到官方环境，上游分支用于预生产。如果生产环境（production）出现错误，需要新建一个分支，修改后合并到最上游的开发分支（master）中。这个时候是（Upstreamfirst），测试完之后，继续合并到pre-production。只有测试没有问题，才能合并到生产环境中。版本发布对于版本发布项目，推荐的做法是从master分支中拉取每个稳定版本的分支，比如2-3-stable、2-4-stable等，出现bug后，创建一个基于repair的分支在相应的发布分支上。修复工作完成后，必须按照上游优化的原则，先合并到master分支，经过测试后再合并到release分支。这时候小版本就必须更新Number了。总结优点：可以区分不同的环境部署。对持续交付和持续集成友好。缺点：分支多，流程管理复杂。TrunkBasedTrunkBasedDevelopment，又称主干开发。开发者同意将代码提交到指定为主干的分支，通常为master，以抵御长期存在的多分支带来的开发压力。这避免了分支合并的麻烦，并确保您随时拥有可发布的版本。使用主干进行开发后，只有一个master分支，所有新功能都提交到master分支，保证master分支每次提交后都准备好发布。没有了分支的代码隔离，测试和冲突解决变得更容易，持续集成也稳定了很多，但也存在以下问题：发布时如何避免引入未完成的特性，如何进行在线bug修复，如何避免发布时引入的未完成功能的答案是：FeatureToggle。由于代码必须保持随时可发布，而我们只需要一个代码来支持持续集成，那么在代码库中添加一个功能开关，随时打开和关闭新功能是最容易想到的，当然还有最有问题的解决方案。FeatureToggle是有成本的，无论是添加Toggle时的代码设计，还是移除Toggle时的人工成本和风险，都需要衡量其带来的价值。事实上，当我们做一个大的前端功能变更时，我们确实采用了一个独立的功能分支，因为没有办法切换它。我们认为，即使我们为这个分支做一个单独的流水线，也比前端的各种样式要好。在两者之间添加和删除Toggles很容易。但与此同时，团队协商决定在每次提交前将master分支合并到feature分支中，避免分支隔离久了再合并的痛苦。如何进行在线bugfix并在release上打上releasetag。一旦发现这个版本有问题，如果此时master分支上没有其他提交，可以直接在master分支上热修复。如果master分支已经有一个提交，你需要做以下四件事：从一个release标签创建一个release分支。在master上提交错误修复。提交错误修复以挑选发布分支。在发布分支上制作另一个版本。在线修复通常很紧急。看完这个稍微繁琐的bug修复流程，你可能会问为什么不直接在release分支修复，然后合并到master分支呢？这样做确实更直观，但事实是，如果你在release分支上做一个修复，你可能会忘记将它合并回master。想象一下，半夜两点，你修完了bug，终于成功上线了。这时候你的第一反应就是“终于可以下班了，什么，合并回master？明天再来。”到了第二天，你已经忘记了这件事。二清。问题要等到下一次发射时才会暴露。一旦被发现，而此时发布上一个版本的人不在身边，无疑会增加很多工作量。综上所述，以上四种是目前比较主流的网点管理策略，但都不是万能的。所以无论选择哪一种，都需要考虑团队的实际情况和项目的具体业务需求，适合自己的才是最好的。最后再分享三点建议：临时分支不要存在太久，每个分支尽量保持精简，用后删除的流程尽量简单，方便回滚的流程符合我们的项目发布计划
