Question

我见过的大多数git工作流都建议在将branch合并到母版之后删除它。例如，此gitflow表明以下内容：

# Incorporating a finished feature on develop 
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

为什么要删除分支？我也很好奇当以后发现一个由该功能引入的错误时该怎么办 - 我是否应该再次创建具有相同名称的分支，修复那里的bug，合并到master中并再次删除分支？

Answer 1

要实现的重要事项是Git分支只不过是指向提交的标签。 Git中的分支实际上是分支。当feature是提交B时master分支master，这就是存储库的样子。

A - B - C - F - H [master]
     \
      D - E - G - I[feature]

请参阅？实际分支。当你git merge feature成为主人时，你会得到这个。

A - B - C - F - H - J [master]
     \             /
      D - E - G - I  [feature]

一旦你git branch -d feature分支历史记录仍然存在！

A - B - C - F - H - J [master]
     \             /
      D - E - G - I

J有父母H和I.如果没有他们，J就不可能存在，它是Git如何运作的。没有G.我不可能存在。没有E.不能存在。等等。分支必须保持

J是合并提交，通常包含要合并的分支的名称。它与任何其他提交一样，因此您甚至可以向其添加更多信息，例如返回问题跟踪器的链接。

git merge --no-ff用于阻止Git进行快速前进＆＃34;并失去了分支历史。如果在创建分支后master上没有完成任何工作，就会发生这种情况。快进看起来像这样。

A - B[master]- D - E - G - I [feature]

git checkout master
git merge feature

A - B - D - E - G - I [feature] [master]

由于master是feature的直接祖先，因此不需要合并。 Git可以移动master标签。您的分支历史记录丢失了，看起来D，E，G和I都是作为master上的单独提交完成的。 git merge --no-ff告诉Git永远不要这样做，总是执行合并。

将来，当它注意到G中引入了一个错误时，任何浏览存储库的人都可以看到它是作为分支的一部分完成的，预先查找合并提交，并获取有关该分支的信息从那里。

即便如此，为什么要删除分支？两个原因。首先，它会使你的分支列表变得杂乱无章。

其次，更重要的是，它会阻止您重复使用分支。分支和合并很复杂。单次使用，短期功能分支通过确保您只将分支合并回主一次来简化过程。这消除了许多技术和管理问题。合并分支时，已完成。如果您需要修复该分支中引入的问题，只需将其视为master中的错误并创建一个新分支来修复它。

不幸的是，git log对用户来说是一个非线性的历史线性表示。要解决此问题，请使用git log --graph --decorate。这将在上面的示例中绘制线条，并在每次提交时显示任何分支和标记。您将获得更真实的存储库视图。

如果您使用的是Mac，GitX会为您显示存储库。 gitk是通用版本。

Answer 2

因为myfeature分支历史记录代表了为实现myfeature而完成的所有中间提交。

这个策略只在master中保留一个提交，而忘记了中间步骤，这对于长期存在的分支是有意义的，正如我在“Why does git fast-forward merges by default?”中所解释的那样。

master中完成（合并）的一次提交的提交消息应该清楚地表明已经完成了实现“myfeature”。

如果需要修复，可以重复使用分支名称（因为之前已将其删除）。

合并为master时，为什么要删除功能分支？

2 个答案: