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

介绍

Git 已成为软件开发中版本控制系统事实上的行业标准。您应该首先阅读我关于 Git 是什么以及如何开始的文章。你读过吗？太好了，我们出发吧！不管喜欢与否，这个由 Linus Tovalds 创建的工具不会退休。因此，讨论分布式团队如何使用 Git 以及他们应该为此选择什么样的分支策略是有意义的。这不是一个无关紧要的问题。当组建一个以前没有合作过的新开发团队时，分支策略通常是首先要决定的事情之一。而有些人会口吐白沫来证明一种策略比另一种策略更好。因此，我想向您传达一些关于它们的一般信息。

分支策略是否必要？

它们确实是必要的。非常有必要。因为如果团队不同意某事，那么每个团队成员都会做他或她想做的事：

• 在任何分支机构工作
• 合并到任意其他分支
• 删除一些分支
• 创造新的
• 因此每个团队成员都将在不受管理的流程中行动。

这就是为什么我们要考虑以下三种策略。我们走吧！

GitHub 流程

奇怪的是，这种分支策略在 GitHub 上是首选 :) 它带有一组规则：

1. 主分支中的代码不能被破坏。它应该随时准备好部署。也就是说，您不得将阻止您构建项目并将其部署到服务器的代码放在那里。
2. 当你打算开发新的功能时，你需要在 master 分支的基础上创建一个新的特性分支，并给它起一个有意义的名字。在本地提交代码并定期将更改推送到远程存储库中的同一分支。
3. 当您认为工作已经准备好并且可以合并到 master 分支中时（或者如果您不确定，但想获得对已完成工作的反馈），打开一个拉取请求（您可以在此处阅读有关拉取请求的信息）。
4. pull request 中的新特性通过审核后，就可以合并到 master 分支中了。
5. 当更改合并到 master 分支时，它们应该立即部署到服务器。

根据 GitHub Flow 的说法，在开始处理新事物之前，无论是修复还是新功能，您都需要基于 master 创建一个新分支并为其命名。接下来，开始实施工作。您应该不断地向具有相同名称的远程服务器提交提交。当您断定一切就绪时，您需要向 master 分支创建一个拉取请求。然后至少有一个人，或者更好的是，两个人应该在单击“批准”之前查看此代码。通常，项目的团队负责人和第二个人绝对应该看一看。然后就可以完成pull request了。GitHub Flow 还以推动项目中的持续交付 (CD)而闻名。这是因为当更改进入 master 分支时，它们应该立即部署到服务器。

GitFlow

之前的策略 (GitHub Flow) 的核心并不是很复杂。有两种类型的分支：主分支和功能分支。但 GitFlow 更严重。至少，上面的图片应该清楚了:)那么这个策略是如何工作的呢？一般来说，GitFlow 由两个持久分支和几种临时分支组成。在 GitHub Flow 的上下文中，主分支是持久的，其他分支是临时的。 持久分支

• 主人：任何人都不应该触摸或推动任何东西到这个分支。在这个策略中，master代表最新的稳定版本，用于生产（也就是在真实服务器上）
• 开发：开发分支。它可能不稳定。

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

1. 功能分支——用于开发新功能。
2. 发布分支——用于准备发布新版本的项目。
3. Hotfix 分支——用于快速修复真实用户在真实服务器上发现的错误。

特色分支

功能分支是由开发人员为新功能创建的。它们应该始终基于开发分支创建。完成新功能的工作后，您需要向开发分支创建拉取请求。显然，大型团队可以同时拥有多个功能分支。再看一下GitFlow策略描述开头的那张图。

发布分支

当所需的新功能集在开发分支中准备就绪时，您就可以准备发布新版本的产品了。基于开发分支创建的发布分支将帮助我们实现这一点。使用发布分支时，您需要查找并修复所有错误。稳定发布分支所需的任何新更改也必须合并回开发分支。这样做也是为了稳定开发分支。当测试人员说该分支对于新版本来说足够稳定时，它就会被合并到 master 分支中。稍后为该提交创建一个标记，该标记被分配了一个版本号。要查看示例，请查看策略开头的图片。在那里你会看到标签 1.0— 这只是一个表示项目 1.0 版本的标签。最后，我们有 hotfix 分支。

修补程序分支

Hotfix 分支还用于向 master 分支发布新版本。唯一的区别是这些版本不是计划中的。在某些情况下，错误会进入已发布版本并在生产环境中被发现。以 iOS 为例：新版本发布后，您会立即获得大量更新，其中修复了发布后发现的错误。因此，我们需要快速修复错误并发布新版本。在我们的图片中，这对应于版本 1.0.1。这个想法是，当需要修复真实服务器上的错误时（或者我们所说的“生产中”或“生产中”），新功能的工作不必停止。hotfix 分支应该从 master 分支创建，因为它代表当前在生产中运行的内容。一旦错误修复准备就绪，它被合并到 master 中，并创建了一个新标签。就像准备发布分支一样，修补程序分支也应该将其修复合并回开发分支。

分叉工作流程

在分叉工作流程中，开发涉及两个存储库：

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

到目前为止听起来有点奇怪，对吧？任何接触过开源开发的人都已经熟悉这种方法。这种策略具有以下优势：可以在分支存储库中进行开发，而无需授予在原始分支中进行联合开发的权限。当然，原始存储库的所有者有权拒绝提议的更改。或者接受并合并它们。这对于原始存储库的所有者和想要帮助创建产品的开发人员来说都很方便。例如，您可以建议对Linux 内核进行更改。如果 Linus 认为它​​们有意义，将添加更改 (!!!)。

分叉工作流程的示例

当有要使用的库时，将在 GitHub 上应用分叉工作流。它有一个错误，使您无法完全使用它。假设您足够深入地研究问题并知道解决方案。使用分叉工作流程，您可以在没有权限在图书馆的原始存储库中工作的情况下解决问题。要开始，您需要选择一些存储库，例如Spring Framework。找到并点击右上角的“Fork”按钮：这需要一些时间。然后原始存储库的副本将出现在您的个人帐户中，这将表明它是一个分支：现在您可以像往常一样使用这个存储库，将更改添加到 master 分支，当一切准备就绪后，您可以创建一个拉取请求到原始存储库。为此，请单击新建拉取请求按钮：

选择哪种策略

Git 是一种灵活而强大的工具，可让您使用各种流程和策略进行工作。但是你的选择越多，就越难决定选择哪种策略。很明显，每个人都没有单一的答案。一切都视情况而定。也就是说，有几条准则可以帮助解决这个问题：

1. 最好先选择最简单的策略。仅在需要时才转向更复杂的策略。
2. 考虑为开发人员提供尽可能少的分支类型的策略。
3. 查看各种策略的优缺点，然后选择您的项目所需的策略。

关于 Git 中的分支策略，我想说的就是这些。感谢您的关注 :) 在 GitHub 上关注我，我经常在这里发布我的创作，涉及我在工作中使用的不同技术和工具。