让 git 分支“变老”有什么害处吗？答案

【问题标题】：Is there any harm letting a git branch "grow old"?让 git 分支“变老”有什么害处吗？
【发布时间】：2011-12-19 01:21:04
【问题描述】：

所以我听说过使用 Git 的 branch-per-feature 工作流，并且我还阅读了一些为什么 this could be a bad idea 的原因。

我真正的问题是——如果我只是开发一个小功能（如简单的正则表达式时间解析器），在将此分支合并回主干后，该分支会发生（或应该发生）什么？它只是坐在那里吗？由于我为那个非常具体的功能创建了它，所以我想不出我必须回去使用分支的原因。我应该以某种方式将此分支标记为已失效，还是继续前进并忘记它？

谢谢

【问题讨论】：

你可以在完成后删除分支，不是吗？ (git branch -d)
是的， git branch -d 总是安全的，它不会丢失任何可能随后被垃圾收集的修订。 git branch -D 甚至会删除包含在其他任何地方都找不到的更改的分支。当您确定一种方法完全是死胡同时，这主要是有用的。考虑到磁盘空间有多便宜，你可能不喜欢使用 git branch -D
这可能会帮助您记住分支只是指向提交的指针。一旦你完成了一个分支的工作，并且你已经合并了那个提交，你就不需要再指向它了。
啊，@Platinum 和@tialaramex，我想这就是我的困惑所在——我之前使用了-D 开关，它警告我可能会丢失提交。我没有意识到有一个-d，虽然我不知道为什么，因为大多数选项当他们有一个大写字母时都有一个小写字母变体。学过的知识！（让我们看看它粘得有多好……）
类似问题：What to do with experimental non-merged git branches?

标签： git git-branch

【解决方案1】：

当我使用特性分支时，我喜欢保留一个特性是在合并之后在分支中开发的事实。这使得浏览历史变得更加容易。它按功能或错误对更改进行分组，让您更容易了解最重要的事情：为什么要进行更改。

这就是为什么当我合并时，我故意用git merge --no-ff 禁用快速转发。这保留了历史分支的结构。然后我可以随意删除分支标签（git branch -d branch_name），合并点包含分支名称，清理分支集合。

相比之下，在分支上工作时，我更喜欢对上游分支进行变基。这使分支的历史保持整洁，没有大量上游合并噪音和冲突解决。我通常会在合并之前对上游进行 rebase，以使集成工作更容易（作为分支作者，我可以修复冲突和损坏的测试）以及生成的合并清理器。

这种方法保留了分支的历史记录，同时防止不再开发的旧分支阻塞。它使得使用 gitk 或 GitX 可视化历史非常有用。

我同意您链接的文章中的基本观点，随着您获得越来越多的大型功能分支同时工作，冲突和集成问题的可能性越来越大。使它们如此有用的隔离变成了一种负担。解决方案之一是没有大型的旧功能分支。如果您可以将功能分支分解为可以完成和集成的较小部分，那么您就可以避免问题。由于许多其他原因，这通常很有用，例如必须审查代码的可怜的 slob。

如果可以将功能分支持续集成到主线中，那么功能分支必须具有有用的、工作的、经过测试的、记录的工作。如果它有，那么它们可以被切成它们自己的分支。

我坦率地承认我可能对此阅读过多，但文章中可能存在的一个明显缺陷是分支是以 people 而不是 features 命名的.这意味着每个分支都是针对“Jim 正在处理的任何事情”而不是“添加蓝色小部件”。这意味着许多发展问题......

功能和分支由个人或团队拥有
分支不适用于离散特征
- 相反，分支机构是个人游乐场
- 没有定义的功能，他们可以继续下去
开发是在孤岛中完成的
- 个人之间不经常交谈
- 个人不能在分支机构一起工作
- 个人在整合之前不会谈论他们的变化

其中很多不是技术问题，而是社会问题。大部分问题都可以通过强烈使用与版本控制密切相关的良好问题跟踪器来解决，例如 Github 的。主要变化是：

分支应该用于定义的功能
开发人员应该在开始工作并完成大量工作之前报告问题
没有人“拥有”某个功能（尽管他们可能对此负责）

不幸的是，大多数项目的错误跟踪政策不鼓励第二个。在报告错误之前准备好补丁的冲动非常强烈。

良好的分支管理需要良好的社会化，良好的问题跟踪器与强大的版本控制集成和受欢迎的政策促进了这一点。

【讨论】：

【解决方案2】：

如果您不再需要它，请删除它。如果您稍后意识到您再次需要它，您可以再次创建它。而且因为您将更改合并回“主干”，所以不会丢失任何内容。

【讨论】：

【解决方案3】：

Git 和分支的好处是每个分支本质上都是一个提交的指针。合并分支后，用于形成分支的提交现在已成为主要历史记录的组成部分。

                                  your branch
                                    main
                                      |
  (main)  -------x----x----x-x---x----x
                  \                  /
  (your branch)    \--x--x-x--x-x---/

此时，如果你使用“git branch -d”删除你的分支，你会得到：

                                    main
                                      |
  (main)  -------x----x----x-x---x----x
                  \                  /
  (your branch)    \--x--x-x--x-x---/

如您所见，来自您的分支的提交仍然是安全的。所改变的只是名为“你的分支”的指针已被删除。

注意，如果你没有合并到 main 中，那么“git branch -d”将会失败。如果你在那时强行删除它，你会得到：

                                  main
                                    |
  (main)  -------x----x----x-x---x--x
                  \
  (your branch)    \--x--x-x--x-x

由于在这个阶段没有分支指针，提交是“悬空的”并且将在下次 git 进行垃圾收集时被删除。

长话短说，如果您的分支已被合并，您可以并且应该将其删除。如果它没有被合并，你不应该。

【讨论】：

【解决方案4】：

需要考虑的两件事：

也许你应该习惯在登陆之前将这些分支重新定位到 master 的尖端（或任何地方）。这样一来，它们就像 KingCrush 上面所建议的那样是严格冗余的，并且可以在您发现问题时销毁以便以后重新创建。
使用重命名来标记您不确定是否需要再次使用特定前缀的分支，这样当您知道您不是在寻找一个分支时，您可以在分支列表中快速浏览它们过时的功能分支。

您可以混合使用这些技术，例如总是变基，然后将分支 foo 重命名为landed-foo，然后在设定的时间间隔（例如，一个版本或 30 天）后删除landed-foo 分支。

请注意，如果您不进行 rebase（并在 rebase 版本上运行任何测试），您将无法确定在它登陆后发现的错误实际上是在开发的代码中，而不是由在开发后合并它，所以在这种情况下，您可能希望将分支保留一段时间。这将更频繁地发生在侵入性/非常大的变化中，不像您的问题场景。

【讨论】：

变基并不总是一个好主意，因为它破坏了开发该功能的方式。正确合并它绝对没有坏处，而且 git 实际上是为了处理广泛的分支和合并而开发的。稍后在历史记录中显示一个清晰的分支表明该功能是单独开发的，如果需要，您可以在以后轻松识别它。同样，删除分支是完全安全的，因为它们只是指向历史中提交的指针。删除一个分支不会删除它所属的历史；历史将始终显示分支/合并。

【解决方案5】：

据我所知，您想要保留它的唯一原因是：

您想要了解上次工作时间的历史记录。
您可以推断它是什么时候开始开发的。

【讨论】：

即使没有指向提交的实际分支，您也可以通过查看历史记录来获得两者。当使用它的工作完成并合并回其他分支时，没有真正的理由保留一个分支。
同意。但是，我认为看到一个有用的分支名称会容易得多，而不是从提交消息中逆向工程分支所做的事情。