什么时候在 git 中分支？答案

【问题标题】：When to branch in git?什么时候在 git 中分支？
【发布时间】：2010-11-14 13:26:15
【问题描述】：

我刚刚开始使用 git，虽然了解如何使用 git 做某事相对容易，但我无法确定何时使用 git 做某事。

例如，一个项目通常什么时候分支？

我正在考虑对当前项目的每个版本进行分支，并在完成后将其与主项目合并 - 这是常见的做法吗？

【问题讨论】：

标签： git

【解决方案1】：

我确信有些人做的事情与我不同。但是，这是我遵循的：

始终为每个功能创建一个分支（稍后将它们合并回来）
为每个错误修复创建一个分支
不将主分支设为正在进行中的工作 (WIP)，让其保持干净

【讨论】：

“让主分支保持干净，不要使其成为正在进行的工作 (WIP)”我喜欢这个想法。
您需要将这些功能分支推送到远程存储库（例如，为了修复错误），还是您只需在本地创建分支，然后将其合并到本地主服务器，然后再推送到远程？跨度>

【解决方案2】：

我不确定分支当前项目的每个版本是什么意思。

无论如何，git 建议您创建“主题分支”。通过“主题分支”，这意味着您在处理功能/错误时创建一个分支。假设我正在开发 jQueryUI，并且有人要求我向 jQuery 日历添加一个功能，该功能允许用户指定不可选择的日期。

如果我在名为 master 的分支中，我将创建一个名为“SpecifyDateExclusion”的本地分支并开始进行更改。与此功能相关的所有代码都将放在此分支中。

master
  |
  |
  |___ SpecifyDateExclusion

在我开发此功能时，收到了一个错误报告，即 Opera 10 中的日历已损坏，现在需要修复此错误。我回到我的主分支并创建另一个名为 Opera10BugFix 的分支并开始修复其中的错误。

master
  |
  |
  |___ SpecifyDateExclusion
  |
  |
  |___ Opera10BugFix

很快，你可能会有类似的分支

master
  |
  |
  |___ SpecifyDateExclusion
  |
  |___ Feature1
  |
  |___ Feature2
  |
  |___ Feature3
  |
  |___ Opera10BugFix
  |
  |___ BugFix1
  |
  |___ BugFix2

你可能会问有什么优势？

优点是它在准备发布时为我提供了灵活性。假设我的下一个版本主要是关于错误修复。

我将从 master 创建一个名为“InterimBugFix”的新分支，并合并我所有的错误修复分支。

如果我想创建混合的错误/功能版本，我将从 master 创建一个名为“NextVersion”的分支并合并我的功能/错误修复分支。

Git 在管理这些分支方面非常强大，如果你能想到什么，Git 会让你去做。

【讨论】：

你说你只在发布时合并，这不会导致可怕的合并灾难吗？当所有分支的代码库不同，因此会发生冲突？

【解决方案3】：

Git 的最大优点是它不会强迫您做出任何决定。 Git 最糟糕的地方在于它不会强迫你做出任何决定。

您的工作流程完全取决于您。您是打算合作，还是要独立开发？发布之间的交货时间是短的还是长的？这些约束可能有助于定义合适的工作流程。

我在一个由 4 名开发人员组成的小团队中工作，迭代周期为两周。在周期开始时，我们就范围达成一致，并针对 master 进行开发。任何我们预计超过两周的东西都会在一个分支中移动（或开始生命）（这种情况并不经常发生，我们的范围很窄）。

在两周周期结束时，我们执行 QA、标记和发布。从下一个周期开始，那些其他分支将合并回 master。

如果您需要修补发布，我们会创建分支、提交、QA、标记和发布。

对于任何实验性的东西，我们通常会创建一个新分支并将其与 master 隔离，直到它适合合并或丢弃。

总之，我们的团队在以下情况下分支：

功能超出了我们的迭代周期
修补版本
体验特色

我们的工作流程非常集中，可能不是许多 Git 用户的典型。没有对错，只是选择最合适的。

【讨论】：

“针对 master 开发”——这是否意味着您使用 master 分支进行开发？
这很重要：Git 没有版本控制工作流。相反，它是一个版本控制工作流构建工具包。就像使用乐高积木一样，将所有东西放在一起是大量乏味、艰苦、无聊的工作，但结果会很棒，因为它是你的，你用你自己的双手建造了它，它完全适合你的需求。说得好！

【解决方案4】：

在 Web 应用程序开发中，我们这样做：

我们维护一个名为“Production”的原始分支。它包含实时网站上存在的代码。

在任务分支中发生的任何更改。所以你可能会看到一个分支Task-13923-add-feature-x。这些分支是从生产分支创建的，并且生产分支必须在合并到生产之前合并到它们中（因此它始终是一个干净的快进，没有潜在的冲突）。

其他人不时将“生产”分支合并到他们的任务分支中以保持最新。

【讨论】：

您是在有效地合并生产分支，还是在重新定位任务分支？我对 git 还很陌生，但后者对我来说似乎更有意义。
@MarioDS 重点是Production 只能快进。我们通常将当前接受的代码保存在master 中。在推送之前，开发人员总是被要求在master 上重新设置基础——这通常会提供一个干净的快进。如果团队足够小，我有时会在测试/上线之前将master 重新设置为production。这 99% 的时间都可以正常工作，并且可以提供非常线性的历史记录。如果团队更大，那么我会坚持不时将Production 合并到master 中，以便每个人都有更新代码。缺点是您会丢失线性历史记录。

【解决方案5】：

如有疑问，请分行。分行很便宜，而且新分行的信息可以很容易地转移到旧分行。当一个分支已经过时了，它很容易被杀死。

【讨论】：

【解决方案6】：

这取决于您的“分支策略”有很多答案。最简单的 2 个（根据我的经验）是任务/功能分支和发布分支。您使用哪一种取决于您的发布周期是如何运作的。

如果您不断地集成和发布，那么任务/功能分支是有意义的，因为它们使“主”（其他 VCS 中的主干）处于相对稳定的状态，从而使发布变得容易。但是如果你有一个更加结构化的发布周期，也许发布分支会更有意义，因为它们可以用来更仔细地定义每个发布中添加的内容。当然，混合策略也是可行的。

我通常使用任务/功能分支，因此每个错误或功能请求都是分支的。然后进行处理，完成后合并回主控。

【讨论】：