Git重用分支或删除并重新创建答案

【问题标题】：Git reuse branch or delete and create againGit重用分支或删除并重新创建
【发布时间】：2020-11-11 00:43:02
【问题描述】：

我最近接到一项任务，为我正在处理的项目添加特定功能。由于此功能依赖于使用残酷的旧代码，因此我决定将任务拆分为 2 个步骤：

重构旧代码以提高可用性
使用重构代码创建功能

我创建了一个分支 feat/foo，重构完成后，我将它合并到我们的 master 中，以便我们可以直接使用更改。现在我留下了以下提交历史：

A ---> B ---> C --> E ---> F <master  B: created branch feat/foo
       |            ^                 D: refactoring finished
       D -----------|                 C: changes in master in between
       ^                              E: merge commit
     feat/foo                         F: master is now here

feat/foo 仍然指向 D，并且我的 master 已经进入提交 F。我现在该怎么做才能在分支 feat/foo 中继续我的这项任务？我看到了两种可能性：

要么删除 feat/foo 并再次删除 checkout -b，这样我就有了一个与旧分支同名的新分支，
或以某种方式“重用”feat/foo，我不知道该怎么做

第一个解决方案对我来说感觉不太正确，删除分支只是为了重新创建它似乎是“错误的”。但我不知道如何重复使用它。

我该怎么办？删除并重新创建分支，或者如果正确的答案是重用它，如何？

【问题讨论】：

标签： git

【解决方案1】：

在许多工作流程中，一旦功能分支被合并回master，它就会被删除。 GitHub 可能是这方面的主要例子。如果您遵循这种思想流派，您将删除 feat/foo 并为您的下一个 sprint 创建一个新功能分支。

如果您真的想继续使用该分支，那么您必须将feat/foo 重新设置为master 或将master 合并到feat/foo。我看不到变基的任何优势，这可能会很混乱，所以让我们考虑合并。你在提交E 时将feat/foo 合并到master。因此master 已经拥有feat/foo 的所有功能，但反过来则不然，即feat/foo 可能缺少自提交master 以来已引入master 的几个功能。要进行合并，您将使用以下命令：

git checkout feat/foo
git merge master

您可能必须解决 master 中尚未在 feat/foo 分支中的新功能引起的合并冲突。

现在feat/foo 分支已与 master 保持同步，如果您愿意，可以继续使用它。就我个人而言，我只是将feat/foo 留在原处并创建一个全新的功能分支。您可以将其保留几个 sprint，直到您确定删除它是安全的。

【讨论】：

谢谢，我真的没想过将master合并回feat/foo，但现在看起来很明显。虽然我考虑照你说的做，不理会 feat/foo 并开始在新分支上工作，因为这可能会更干净。
一个问题，我们可以不将feat/foo重置为当前的master并从那里开始吗？随着拉取请求被合并，feat/foo 分支实际上并没有什么主要用途。
分店便宜！
如果您在将分支合并到主分支之前对其进行变基（这是我工作的标准做法），我认为重用同一个分支没有任何害处，因为您知道主分支和工作分支有相同的历史。

【解决方案2】：

由于您需要继续在分支feat/foo 上工作，所以首先要做的是检查它：

git checkout feat/foo

因为您没有完成新功能的工作，所以您继续在分支上工作并提交，直到您完成工作并准备好将其合并回 master。

不时将主分支的最新更改拉入分支是很好的。你可以通过运行来做到这一点：

git merge master

当您在 feat/foo 分支时。

删除分支只是为了重新创建它没有多大意义。 git checkout feat/foo 后跟 git merge master 产生相同的结果。

【讨论】：

当我做 git merge master 时，我得到“合并：主人 - 我们不能合并的东西”.. 有什么建议吗？
当 repo 不包含名为 master 的分支时，将显示此消息。也许你的主分支被命名为main。或者，也许您从未检查过 master 分支（并且它仅存在于 origin 存储库中，而不是本地存在）。在这种情况下，首先运行git branch --track master origin/master，以创建本地master 分支。

【解决方案3】：

这个问题有点过于简单化了。在您的情况下，您有“1 个故事”和“2 个任务”：重构和功能。您已经合并了重构任务并移至功能任务。这意味着我们没有考虑合并冲突的可能性。您可以简单地合并/变基以重用分支，这是最简单的方案。

为什么你会在转移到任务 2 之前合并任务 1？为什么不在合并之前完成所有任务以完成故事？看来您已经有了一种直觉，即简短而专注的工作更容易管理。对于大多数企业级团队而言，寿命较长的分支比寿命短的要差。

实际上，在选择“删除或重用”分支时，您应该考虑复杂合并冲突的可能性。长期存在的分支、糟糕的团队沟通、重构、大团队、协调不力的故事……所有这些都增加了错误、噩梦级合并冲突解决的可能性。

选择删除或重复使用分支时，我总是随删除。我的建议带有一个整体的观点，即其他更高阶的问题也正在得到解决（再次考虑大团队、沟通不畅、重构等）。一旦合并了一个分支，就不会增加该分支的生命周期的显着价值。但是，长寿命的分支可能会带来巨大的成本。另见GitFlow。

【讨论】：