我们从指导DevOps团队的Git分支策略中学到了什么

版本控制是DevOps的基础，因此使用它成为DevOps团队的第二天性。但是，团队在设置其工作流程时做出的选择以及做出选择的原因会被遗忘，并且很少重新讨论。

Gearset在一个生态系统中运行，许多开发团队仍在采用DevOps。因此，我们花费了大量时间来帮助团队从手动部署和缓慢发布节奏过渡到成熟的DevOps流程。即使它们的优先事项和挑战各不相同，但小型创业公司和大型企业中的团队都在寻找相同的东西：DevOps带来的敏捷性。

采用版本控制是这些团队的第一步，我们将在此过程中为他们提供指导。通常，此过程中最涉及的部分是有关Git分支策略的讨论。我们认为，我们提出的建议对于希望修改或实施自己的Git分支策略的任何团队都是正确的。

一次迈出一步

一次朝着DevOps成熟迈进一步的团队往往会看到最大的成功。进行渐进式改进可以使这些团队看到每次更改的好处，在继续进行下一步之前先掌握新的工具和流程。试图立即实施所有任务的团队所付出的代价超出了他们的咀嚼能力，这常常使他们面临如此巨大的变革。

解决今天的问题是为明天做准备的最好方法。考虑到将来会遇到的挑战是一个好主意，但跳过前进并不是成功过渡到由DevOps驱动的工作流程的最佳方法。采用或修订Git分支策略是DevOps成熟的第一步。最好单独进行，而不是将其作为现有工作流程的整体修订的一部分。

质疑您当前的流程

如果跳过改进DevOps的工作是一种危险，那么惯性同样是个问题。团队中令人发指的行为不应决定您使用的流程，包括您的Git分支策略。

出现Git分支策略的整个问题是因为可以在有效选项之间做出选择。团队通常根据团队规模，团队结构，目标发布节奏以及当前工作流程进行选择。所有这些都是重要的考虑因素。但是我们建议团队不要仅仅因为当前流程的修订版而感到满意，因为这可能不是最佳选择。

实施新策略代表着重塑工作流程的机会，团队应借此机会评估其当前流程是否正确。一些团队可以简化他们的工作流程并提高发布速度。其他人可能需要Git分支策略，以支持在各种环境下日益复杂的工作流程。

我们要求团队确定其目标，能力和当前流程中的症结。对于团队来说，在他们自己的过程中确定关键点可能会很困难-许多团队发现，在确定什么是坏的以及其他可能的选择时，外部视角非常重要。一旦所有这些都清楚了，团队就准备好选择他们的Git分支策略。

采用最简单的Git分支策略

团队的形态和规模各不相同，因此，有些团队发现采用新的Git分支策略比其他团队更容易。大型企业有时会具有复杂的工作流程，因此需要使用复杂的Git分支策略来进行匹配。就是说，根据我们的经验，团队通常认为他们的特殊要求一个独特的复杂过程，而实际上，较简单的选择对于新手和技术含量较低的团队成员而言将更合适并且更容易获得。

最重要的是，在团队工作流程限制内最简单的Git分支策略通常是正确的选择。我们建议团队在可能的情况下采用基于功能分支模型的策略，并在短期分支中开发新功能，这些分支从主分支创建并合并回主分支。

对于希望维持每周或每两周发布周期的团队，我们通常考虑采用Gitflow模型。在这种模型中，团队将新功能合并到一个永久的“开发”分支中。然后，从“ develop”分支创建各个发行分支，并合并到main分支中。发布仍然是周期性的，但是当功能合并到dev分支时（而不是在发布期间）会处理所有棘手的合并冲突。

没有团队的支持，不要强加新策略

尽管新的Git分支策略可能是正确的选择，但对于团队负责人来说，在没有先获得整个团队认可的情况下快速实施新策略是一个错误。如果团队成员对新流程感到困惑，并且对应该如何使用分支机构抱有不同的期望，那么不久就会出现困惑和沮丧。

对于团队来说，流程变更的好处需要迅速显现出来。不论是第一次采用版本控制还是调整设置，为更改而进行的更改都不会吸引任何人。

获得正确的平衡

尽管团队经常在寻求敏捷性和加速发布节奏，但速度不应该付出任何代价。团队必须在速度与组织需求和自身能力之间取得平衡，建立强大的工作流程以高效地交付价值。