这篇文章是我们 "高级Git "系列的一部分。请务必在 Twitter 上关注我们，或者注册我们的新闻通讯，以了解下一篇文章的内容。
几乎所有的版本控制系统（VCS）都有对分支的某种支持。简而言之，分支意味着你离开主开发线，为你的工作创建一个新的、独立的容器，并在那里继续工作。这样你就可以在不破坏生产代码库的情况下进行实验和尝试新事物。Git的用户都知道，Git的分支模型很特别，而且非常强大；它是这个VCS最酷的功能之一。它速度快，重量轻，在各分支之间来回切换就像创建或删除分支一样快。你可以说，Git鼓励使用大量分支和合并的工作流程。
Git完全让你自己决定创建多少个分支，多长时间合并一次。现在，如果你自己在编码，你可以选择何时创建一个新的分支，以及你想保留多少个分支。不过，当你在一个团队中工作时，情况就会发生变化。Git 提供了工具，但你和你的团队要负责以最佳方式使用它
在这篇文章中，我将讨论分支策略和不同类型的 Git 分支。我还会向你介绍两种常见的分支工作流程。Git Flow 和 GitHub Flow。
高级Git系列。
- 第一部分: 在Git中创建完美的提交
- 第二部分： Git中的分支策略
你在这里! - **第3部分：**通过拉动请求实现更好的协作
即将推出! - **第四部分：**合并冲突
- **第5部分：**重置与合并
- **第六部分：**交互式重做
- **第7部分：**在Git中挑选提交内容
- 第八部分使用重新记录来恢复丢失的提交
团队合作。写下一个约定
在我们探讨结构化发布和集成变化的不同方式之前，让我们先谈谈约定。如果你在一个团队中工作，你需要为你的项目商定一个共同的工作流程和一个分支策略。把这些写下来是个好主意，可以让所有的团队成员都能看到。
诚然，不是每个人都喜欢写文件或指南，但将最佳实践记录下来，不仅可以避免错误和碰撞，也有助于新团队成员的入职培训。一份解释分支策略的文件将帮助他们了解你的工作方式以及你的团队如何处理软件发布。
下面是我们自己文档中的几个例子。
master代表当前的公开发布分支next代表下一个公开发布的分支（这样我们就可以在主干上提交热修复，而不至于拉入不需要的修改）。- 特性分支被归类到
feature/ - WIP分支被归入
wip/（这些分支可以用来创建个人WIP的 "备份"）。
不同的团队可能对这些事情有不同的看法（例如对 "wip "或 "feature "组），这肯定会反映在他们自己的文档中。
整合变化和结构化发布
当你考虑如何处理 Git 仓库中的分支时，你可能应该先考虑如何整合变化和如何组织发布。所有这些主题都是紧密相连的。为了帮助你更好地理解你的选择，让我们看看两种不同的策略。这些例子是为了说明光谱的两端，这就是为什么它们应该给你一些想法，让你知道如何设计自己的分支工作流程。
- 主线开发
- 状态分支、发布分支和特性分支
第一种选择可以被描述为 "总是在整合"，基本上可以归结为：总是将自己的工作与团队的工作整合起来。在第二种策略中，你收集自己的工作并发布其集合，即多种不同类型的分支进入舞台。这两种方法都有其优点和缺点，这两种策略对某些团队有效，但对另一些团队则无效。大多数开发团队的工作都在这两个极端之间。
让我们从主线开发开始，解释这种策略是如何工作的。
主线开发
我在前面说过，但这种方法的座右铭是 "永远是集成的"。你有一个单一的分支，每个人都通过提交到主线来做出贡献。
请记住，我们是在为这个例子进行简化。我怀疑现实世界中的任何团队都是以这样一个简单的分支结构工作的。然而，了解这种模式的优缺点确实有帮助。
首先，你只有一个分支，这使得你很容易跟踪项目中的变化。其次，提交必须相对较小：在一个事物不断被集成到生产代码的环境中，你不能冒着大而臃肿的提交的风险。因此，你的团队的测试和QA标准必须是一流的!如果你没有一个高质量的测试环境，主线开发的方法就不会对你有用。
状态、发布和特性分支
现在让我们反过来看一下，如何与多个不同类型的分支合作。它们都有不同的工作：新功能和实验性代码保存在自己的分支中，发布可以在自己的分支中计划和管理，甚至你的开发流程中的各种状态也可以用分支来表示。
记住，这一切都取决于你的团队的需求和你的项目的要求。虽然这种方法一开始可能看起来很复杂，但这都是实践和习惯的问题。
现在，让我们更详细地探讨两种主要类型的分支：长期运行的分支和短期运行的分支。
长期运行的分支
每个 Git 仓库都至少有一个长期运行的分支，通常被称为主干或主干。当然，你的团队可能已经决定在项目中设置其他长期运行的分支，例如开发、生产或暂存之类的。所有这些分支都有一个共同点：它们存在于项目的整个生命周期。
像master或main这样的主线分支就是一个长期运行的分支的例子。此外，还有一些所谓的集成分支，如develop或staging。这些分支通常代表项目的发布或部署过程中的状态。如果你的代码在其开发生命周期中经历了不同的状态--例如从开发到暂存到生产--那么在你的分支中反映这种结构也是有意义的。
关于长期运行的分支的最后一件事：大多数团队都有一个规则，如 "不要直接提交到长期运行的分支"。相反，提交通常是通过合并或重定位来实现的。这样的规则有两个主要原因。
- **质量。**不应将未经测试或未经审查的代码添加到生产环境中。
- 发布捆绑和调度。你可能想分批发布新代码，甚至提前安排发布时间。
接下来是：短命的分支，通常是为了某些目的而创建的，然后在代码被整合后删除。
短暂的分支
与长期运行的分支相比，短命的分支是为临时目的而创建的。一旦它们完成了自己的职责，代码被整合到主线（或另一个长效分支），它们就会被删除。创建短期分支有许多不同的原因，例如，开始开发一个新的实验性功能，修复一个错误，重构你的代码，等等。
通常情况下，一个短命的分支是基于一个长期运行的分支。比方说，你开始着手开发软件的一个新功能。你可能会把这个新功能建立在长期运行的主分支上。经过几次提交和一些测试后，你决定这项工作已经完成。新功能可以被集成到主分支中，在它被合并或重构后，功能分支可以被删除。
两种流行的分支策略
在本文的最后一节，我们来看看两种流行的分支策略。Git Flow 和 GitHub Flow。虽然你和你的团队可能会做出完全不同的决定，但你可以把它们作为你自己分支策略的灵感。
Git Flow
有一种著名的分支策略被称为 Git Flow。主分支总是反映当前的生产状态。有第二个长期运行的分支，通常称为开发。所有特性分支都从这里开始，并将被合并到开发中。同时，它也是新版本的起点：开发者开辟一个新的发布分支，在此基础上工作、测试，并在这样的发布分支上提交他们的错误修复。一旦一切正常，你确信它可以用于生产，你就把它合并回主干。最后一步，为主干上的发布提交添加一个标签，然后删除发布分支。
Git Flow 对于（桌面）应用程序或库等打包软件来说效果很好，但对于网站项目来说，似乎有点过犹不及。在这里，主分支和发布分支之间的差异往往不够大，无法从这种区分中获益。
如果你使用的是像Tower这样的Git桌面GUI，你会在界面上找到可能的操作，不必再去记忆任何新的命令。
GitHub 流程
如果你和你的团队遵循持续交付的方法，生产周期短，发布频繁，我建议你看看 GitHub Flow。
它非常精简和简单：只有一个长期运行的分支，即默认的主分支。你正在进行的任何工作都有自己的独立分支。不管是一个功能，一个错误修复，还是一个重构，都是如此。
什么是 "最佳 "的 Git 分支策略？
如果你问十个不同的团队他们是如何使用 Git 分支的，你可能会得到十个不同的答案。没有所谓的 "最佳 "分支策略，也没有人人都应该采用的完美工作流程。为了找到适合你和你的团队的最佳模式，你应该坐下来一起分析你的项目，谈谈你的发布策略，然后决定一个能以最佳方式支持你的分支工作流程。
如果你想深入了解先进的Git工具，请随时查看我的（免费的！）"Advanced Git Kit"：它是一个简短视频的集合，主题包括分支策略、交互式重置、Reflog、子模块等等。
高级Git系列。
- 第一部分。 在Git中创建完美的提交
- 第二部分： Git中的分支策略
你在这里! - 第**3部分：**通过拉动请求实现更好的协作
即将推出! - **第四部分：**合并冲突
- **第5部分：**重置与合并
- **第六部分：**交互式重做
- **第7部分：**在Git中挑选提交内容
- 第八部分使用 Reflog 来恢复丢失的提交
The postBranching Strategies in Gitappeared first onCSS-Tricks.你可以通过成为MVP支持者来支持CSS-Tricks。
