git分支管理策略_Git分支策略

git分支管理策略

在此博客文章中，我们将讨论在SDLC期间可以采用的各种分支策略。 您的组织针对不同的情况存在不同的策略，应该根据可用的信息和团队中的情况来做出有启发性的决定。

主线分支策略

对于中小型团队来说，干线分支策略是最简单但最有效的策略。 团队中的开发人员不断将他们的工作提交到一个中央分支中，该分支始终处于可部署状态。 换句话说，项目的主要分支应该只包含经过测试和质量的工作，并且绝不应该被破坏。

每个工作单元（或sprint ）都可能对分支数量产生手风琴效果。 起初，开发人员都在自己工作，分支的数量也在扩大。 然后，当每个开发人员完成他或她的工作并将其与其他开发人员集成在一起时，手风琴会再次向下压缩。 此策略可以用于满足特定团队的愿望。

用Git来讲，团队中的每个开发人员都会有自己的本地分支。 例如，如果团队正在研究一项功能：实施环境服务，而任务之一是实施环境Serv API，则开发人员可以从主服务器创建本地分支（例如env-serv-api）。 请记住，在Sprint /发布计划期间，将任务分解为一个工作单元变得很重要，因为Scrum主/产品负责人要确保每个工作单元都是独立的代码。

因此，在下图中，分支A，分支B和分支C对应于开发人员工作站上的Git本地分支。

简化分支策略可确保您不会花费不必要的时间进行手动合并。

大规模地，具有单个工作分支的这种方法被使用自动化构建过程的团队所采用。

优点

• 项目中没有很多分支机构，这可以简化团队的工作流程，并减少对变更可能消失的地方的混淆。
• 提交到代码库中的提交相对较小且快速。 如果有问题，应该相对较快地消除错误。
• 紧急修复程序较少，因为任何保存到主分支中的代码都可以部署。 部署通常会对开发人员造成压力，因为开发人员在代码投入生产时会屏住呼吸，并等待代码用户的回音。 只需进行很少的频繁更新，就可以实践此过程，并最终实现自动化，以至最终用户几乎看不见它。

缺点

• 假设主分支包含准备就绪的代码。 如果团队没有测试基础架构，则冒着冒风险的风险，即假设新代码不会破坏任何内容，尤其是随着项目随着时间的推移变得越来越复杂。
• 部署的概念更适合自动加载到用户设备（例如网站）上的代码。 它不适用于必须下载和安装的软件。 尽管可以解决问题的更新受到欢迎，但频繁进行更新会使所有希望与该应用程序一起使用的人感到烦恼。
• 开发人员可以在生产中验证代码的一种方法是将功能隐藏在标志或脚蹼后面。 有传言称Facebook，Flickr和Etsy都在使用这种技术。 这里的潜在风险是，代码可能会被抛弃，从而导致代码被隐藏的巨大风险，导致无法删除代码。

每个功能的分支部署策略

在此策略中，每个功能都维护一个分支。 一旦团队/开发人员确信功能可以正常工作并经过测试，功能分支将合并到集成分支，这也是主分支的分支，其主要目的是不让损坏的提交传播到主部署。科。 理想情况下，master分支中的任何内容都应处于可部署状态。 有了这种方法，可以灵活地选择在主部署中应使用哪些功能。 通常，这是一个手动步骤，因此会阻碍自动部署的总体目标。

使用此策略，在实际部署之前需要暂停一下。 Github Flow使用此策略。 它依赖于请求请求的概念。 一旦功能的团队/开发人员认为该功能已完成，就将拉取请求发送到Integration Branch。 然后，此“拉取请求”将以手动方式进行调解，审核，并清除（如果已清除）则合并到主数据库中。 在此，主服务器始终处于可部署状态。 因此，一旦合并发生，就可以部署主服务器。

最初，GitHub Flow首先将Feature分支与母版合并，然后部署母版。 现在，它首先部署功能分支，如果功能正常，则将其与母版合并。 这意味着，如果功能分支存在问题，则可以立即重新部署母版，因为事实证明它处于工作状态。

优点

• 就像主线开发一样，重点是代码的快速部署。
• 与主线开发不同，有一个可选的构建步骤。 使用构建步骤时，可以选择将哪些功能合并到master分支中进行部署。

缺点

• 如果代码保留在功能分支上，但没有立即发布到master上 ，则开发人员需要额外的维护要求，这些开发人员需要等待更新到部署的分支时保持其功能最新。
• 分支的语义命名可以帮助熟悉系统的人员，但是它也代表一种内部语言，如果有很多开放功能，则内部语言可能使入职更加困难。
• 现在，对于开发人员，在将旧的分支滚动到主分支中时，有一个内务要求。 这不是一个很大的负担，但是它比从单个master分支中进行工作所需要的更多。

基于环境的分支策略

假设您有一个暂存环境，一个预生产环境和一个生产环境。 在这种情况下，主分支将部署在暂存中。 当某人想要部署到预生产时，他们会创建一个从master分支到预生产分支的合并请求。 通过将预生产分支合并到生产分支中，可以使代码生效。 此工作流仅在一个方向上进行提交，以确保在所有环境中都对所有内容进行了测试。

通过分支命名约定，上述策略可以清楚地说明在什么环境中要使用什么代码，因此在合并提交之前可能需要满足什么条件。 例如，您显然不会将未经测试的代码合并到名为production的分支中。

Git使用的上述分支策略的变体

Git使用4个不同的分支，并为其命名以使其团队了解每个分支的用途。 另外，遵循约定，提交只能传播到堆栈中的下一个分支。 因此，T他分行的工作就像一个金字塔堆叠。 每个“较低”分支都包含在“较高”分支中不存在的提交。 如下图所示， 维护的提交次数最少， 建议的更新提交的次数最多。 一旦代码通过了审核过程，它将被合并到下一个集成分支中，越来越接近被合并到正式版本中。

• 维护：此分支包含来自最新的Git稳定发行版的代码，以及针对点发行版的其他提交（ 维护 ）。
• master：此分支包含应提交到下一发行版的提交。
• next：该分支旨在测试主分支中出于稳定性考虑的主题。
• 建议的更新： 建议的更新分支包含尚未准备好包含的提交。

发布分支策略

仅在需要将软件发布到外界的情况下，才需要使用发布分支。 在这种情况下，每个分支都包含一个次要版本。 稳定分支以master为起点，并尽可能晚地创建。 通过尽可能晚的分支，可以最大程度地减少将错误修复应用于多个分支的时间。 宣布发行分支后，发行分支仅包含严重的错误修复。 如果可能，这些错误修复程序将首先合并到master中，然后精选到release分支中。 这样，您就不会忘记将它们精挑细选，并在后续发行版中遇到相同的错误。 这就是所谓的“上游优先”政策， Google和Red Hat也采用这种政策。 每当发行分支中包含错误修复程序时，都会通过设置新标签来提高补丁版本（以符合语义版本控制 ）。 一些项目还具有一个稳定的分支，该分支指向与最新发布的分支相同的提交。 在此流程中，通常不具有生产分支（或git flow master分支）。

资源资源

• https://about.gitlab.com/2014/09/29/gitlab-flow/
• https://www.safaribooksonline.com/library/view/git-for-teams/9781491911204/ch07.html#ch07
• https://www.safaribooksonline.com/library/view/git-for-teams/9781491911204/ch03.html
• https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow
• http://blogs.atlassian.com/2014/01/simple-git-workflow-simple/
• 分支策略的实际工作流程– https://gist.github.com/jbenet/ee6c9ac48068889b0912

翻译自: https://www.javacodegeeks.com/2015/11/git-branching-strategies.html

git分支管理策略