团队合作不混乱：理解 Git 中的分支策略

介绍

Git 已成为软件创建中版本控制事实上的行业标准。要了解 git 是什么以及如何开始，请首先阅读我关于它的文章。你读过吗？太好了，让我们继续吧！ 不管你喜欢与否，Linus Towalds 创造的工具不会退役。因此，讨论分布式团队如何在 git 中工作以及为此选择什么分支策略是有意义的。这根本不是一个无聊的问题。通常，在组建一个由彼此不合作的新开发人员团队组成的情况下，分支策略是首先需要决定的事情之一。并且会有人会口吐白沫来证明一种策略比另一种更好。因此，我想向您传达有关它们的一般信息。

是否需要分支策略？

但它们是需要的，而且仍然是需要的。因为如果你不同意团队中的某些事情，结果每个人都会做他们想做的事：

• 在他想要的部门工作；
• 合并到他想要的其他分支；
• 删除一些分支；
• 创造新的；
• 等等——每个团队成员都处于不受控制的流动中。

因此，以下是三种策略。去！

GitHub Flow 策略

分支策略，无论多么奇怪，在 GitHub 中都是首选:) 附加的是一组需要遵循的 规则：

1. master 分支中的代码必须完整无缺并准备好随时部署（也就是说，您不能将阻止您构建项目并将其部署到服务器上的代码放在那里）。
2. 当您计划开发新功能时，您需要基于 master 分支创建一个新分支（功能分支）并为其指定一个有意义的名称。在本地提交代码并定期将更改推送到远程存储库中的同一分支。
3. 当明显感觉到工作已经准备好并且可以合并到 master 分支时（或者如果您不确定，但想要获得反馈），请打开 Pull-Request（您可以在此处阅读 Pull-request 是什么）完成的工作）。
4. 拉取请求中的新功能获得批准后，可以将其合并到主分支中。
5. 当更改合并到主分支时，需要立即将它们部署到服务器。

根据 GitHub Flow 的说法，事实证明，在开始开发新内容之前，无论是修复还是新功能，您需要基于 master 创建一个新分支并为其指定合适的名称。接下来，开始实施工作。您需要不断地将提交推送到具有相同名称的远程服务器。当您了解一切准备就绪后，您需要在 master 分支中创建拉取请求。然后，至少应该由一个人（最好是两个人）查看此代码并单击“批准”。通常，项目的团队领导和其他人必须查看它，然后您才能完成拉取请求。GitHub Flow 还因推动项目的持续交付 (CD)而闻名。因为当对 master 分支进行更改时，必须立即将其部署到服务器上。

GitFlow 策略

之前的策略（GitHub Flow）本质上并不是很复杂。有两种类型的分支：主分支和功能分支。但GitFlow更严重。至少从上图你可以明白这一点）那么，这个策略是如何运作的呢？一般来说，GitFlow 由两个永久分支和几种类型的临时分支组成（在 GitHub Flow 的上下文中，master 分支是永久分支，其他分支是临时分支）。 常设分支机构：

• 主人：任何人都不能碰这个树枝或往那里推任何东西。在此策略中，master 显示生产中（即真实服务器上）使用的最新稳定版本；
• 发展是发展的分支。它可能不稳定。

使用三个辅助临时分支进行开发：

1. 功能分支 - 用于开发新功能。
2. 发布分支 - 准备发布项目的新版本。
3. 修补程序分支是针对真实用户在真实服务器上已发现的缺陷的快速解决方案。

特色分支

功能分支是由开发人员为新功能创建的。它们应该始终基于开发分支创建。完成新功能的工作后，您需要在开发分支中创建拉取请求。很明显，在大型团队中，一次可以有多个功能分支。再次注意GitFlow策略描述开头的图片。

发布分支

当开发分支准备好所需数量的新功能后，就可以准备发布产品的新版本了。发布分支将帮助我们做到这一点。它是基于开发分支创建的。在使用发布分支时，您需要查找并修复所有缺陷。稳定发布分支所需的任何新更改也必须合并回开发中。这样做是为了稳定和发展分支。当测试人员认为该分支对于新版本来说足够稳定时，它就会被合并到主分支中。接下来，在此提交上创建一个标签（标签：您可以在此处阅读有关它的更多信息），并为其分配一个版本号。例如，您可以查看策略开头的图片。因此，Tag 1.0 只是一个表示项目版本 1.0 的标签。最后一件事是分支修补程序。

修补程序分支

修补程序分支也用于在 master 中发布新版本。唯一的区别是此版本尚未计划。在某些情况下，缺陷已发布并已在生产中发现。例如，iOS：一旦发布新版本，您立即会收到一堆更新，其中修复了发布后发现的缺陷。对此，有必要快速修复这个缺陷并发布新版本。在我们的图片中，这对应于版本 1.0.1。这个想法是，当您需要修复真实服务器上的缺陷时，新功能的工作可能不会停止（正如我们所说的“生产中”：再次，英语单词“生产”的副本）。修补程序分支应该从主分支创建，因为它代表生产中的工作状态。一旦缺陷的解决方案准备就绪，它就会被合并到 master 中，并创建一个新标签。就像准备发布分支一样，修补程序分支应该将其解决方案合并到开发分支中。

分叉工作流程策略

作为分叉工作流策略的一部分，开发的方式是有两个存储库：

1. 所有更改都将合并到的原始存储库。
2. 分叉存储库（这是原始存储库的副本，由另一个想要对原始存储库进行更改的开发人员拥有）。

到目前为止听起来有点奇怪，对吧？对于那些已经接触过开源开发的人来说，这种方法已经很熟悉了。这一策略具有以下优点：可以在分叉存储库中进行开发，而无需授予原始存储库中的联合开发权限。当然，原始存储库的所有者有权拒绝提议的更改。或者同意并杀死他们。这对于原始存储库的所有者和想要参与某些产品创建的开发人员来说都很方便。例如，您可以建议对Linux 内核进行更改。如果 Linus 认为它​​们有意义，则会添加这些更改（!!!）。

分叉工作流程示例

当您想要使用某个库时，可以在 GitHub 上使用 Forking Flow。它有一个缺陷，无法充分利用。假设您已经对问题进行了足够的研究并知道解决方案。使用分叉工作流策略，您可以解决此问题，而无需授予在原始库存储库中工作的权限。首先，您需要选择一个存储库，例如Spring Framework core，找到右上角的 Fork 按钮并单击它： 这将需要一些时间，之后此原始存储库的副本将出现在您的个人帐户，这将表明它是一个分叉： 然后您可以像往常一样使用此存储库，向主分支添加更改，并在一切准备就绪后，向原始存储库创建拉取请求。为此，请单击“新建拉取请求”按钮：

选择哪种策略

Git 是一个灵活而强大的工具，允许您使用广泛的流程和策略进行工作。但选择越大，现在就越难决定选择哪种策略。显然，没有一刀切的答案。这一切都取决于具体情况。然而，有一些建议可以帮助解决这个问题：

1. 最好先选择最简单的策略。仅在必要时才转向更复杂的策略。
2. 考虑具有尽可能少类型的开发人员分支的策略。
3. 查看不同策略的利弊，并根据项目选择合适的策略。

这就是我想告诉你的关于 git 中的分支策略的全部内容。感谢您的关注:) 订阅我的 GitHub 帐户，我经常在那里发布我在工作中使用的各种技术和工具的作品

有用的链接

• GitHub 流程： 使用 Git 和 GitHub 的最佳方式
• 在 GitHub 上拉取请求或如何更改别人的项目
• GitHub：关于拉取请求
• 持续集成、交付和部署的差异化
• Git 基础知识：使用标签
• Habr：Git 的成功分支模型