我最近完成了为我正在处理的项目添加某个功能的任务。由于此功能依赖于残留使用的旧代码，因此我决定将任务分为两个步骤：
我创建了一个分支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，我的主人提升到了提交F.我现在要做什么来继续我在分支专长/ foo中完成这项任务的工作？我看到两种可能性：
checkout -b，所以我有一个与我的旧分支同名的新分支，第一个解决方案对我来说感觉不太对，删除分支只是为了再次创建它似乎是“错误的”。但我不知道如何重复使用它。
我该怎么办？删除并重新创建分支，或者如果正确的答案将重用它，怎么做？
答案 0 :(得分：8)
在许多工作流程中，一旦功能分支合并回master，它就会被删除。 GitHub可能是这方面的主要例子。如果你遵循这种思想，你会删除feat/foo并为你的下一个sprint创建一个新的功能分支。
如果您真的想继续使用分支，那么您必须在feat/foo上重新master或将master合并到feat/foo。我没有看到任何有利于变基的优势，这可能是混乱的，所以让我们考虑合并。您在提交feat/foo将master合并到E。因此，master已具有feat/foo的所有功能，但反之则不然，即feat/foo可能缺少自master引入D以来的几个功能git checkout feat/foo
git merge master
1}}。要进行合并，您可以使用以下命令：
master您可能必须解决由feat/foo中尚未位于feat/foo分支的新功能引起的合并冲突。
现在feat/foo分支与master保持同步，如果您愿意，可以继续使用它。就个人而言，我只是将@Version留在原处并创建一个全新的功能分支。你可以保留几个短跑，直到你确定删除它是安全的。
答案 1 :(得分：6)
由于您需要继续处理分支feat/foo，首先要做的是结帐：
git checkout feat/foo
因为你没有完成新功能的工作，所以你继续工作并在分支上提交，直到你完成工作并准备将它合并回主人。
不时将主分支的最新更改引入分支机构是件好事。你可以通过运行：
来做到这一点git merge master
当你在feat/foo分支时。
删除分支只是为了重新创建它没有多大意义。 git checkout feat/foo后跟git merge master会产生相同的结果。
答案 2 :(得分：1)
这个问题有点过分简化了。在您的情况下，您具有“ 1个故事”和“ 2个任务”：重构和功能。您已经合并了重构任务，并将其移至功能任务。这意味着我们没有考虑合并冲突的可能性。您可以简单地合并/变基以重用分支，这是最简单的情况。
您为什么还要在合并到任务2之前合并任务1？为什么不合并之前先完成所有任务来完成故事？看来您已经有了一种直觉，即简短，专注的工作更易于管理。对于大多数企业级团队而言，寿命更长的分支比寿命短的分支更糟糕。
在现实中，选择在“删除或再使用”分支时，你应该考虑复杂的合并冲突的可能性。分支机构寿命长，团队沟通不畅，重构，团队庞大，故事协调不力...所有这些都增加了越野车，噩梦级合并冲突解决的可能性。
在选择要删除或重新使用一个分支，我总是用delete去。我的建议带有整体观点，即其他更高层次的问题也正在解决（再次认为大型团队，沟通不畅，重构等）。一旦分支被合并，在增加所述分支的寿命上没有显着的附加值。但是，使用寿命长的分支机构可能会带来巨大的成本。另请参见GitFlow。