合并到master时为什么要删除功能分支答案

【问题标题】：why should I delete feature branches when merged to master合并到master时为什么要删除功能分支
【发布时间】：2015-03-28 10:47:42
【问题描述】：

我见过的大多数 git 工作流都建议在 branch 合并到 master 之后删除它。例如，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

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

【问题讨论】：

因为你的功能已经完成了。什么需要保留分支，从而使 git branch -a 等的结果混乱？
@OliverCharlesworth 历史
@Z.Khullah - 提交仍将保留在历史记录中。
是的，我的意思是这就是人们问这个问题的原因，因为他们不知道这个问题
删除代码从来都不是一个好主意（除非它完全是垃圾/完全搞砸了）。假设该功能非常复杂，尝试了 3 种不同的解决方案/代码路径。第一个似乎是最好的，只是后来发现应该使用解决方案 2。根据解决方案 2 是否是解决方案 1 的子分支，它现在可能会消失，失去解决方案 2 和 3 的工作。功能也可以在模块中开发。将其视为一个分支而不是一个新模块，这有点奇怪。该模块可以与代码库分开完成。

标签： git git-flow

【解决方案1】：

需要意识到的重要一点是 Git 分支只不过是一个指向提交的标签。 Git 中的分支实际上就是分支。如果 feature 在 master 是提交 B 时从 master 分支出来，则存储库的外观如下。

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

看到了吗？实际分支。当你 git merge feature 进入 master 时，你会得到这个。

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，G就无法存在。等等。分支必须保留

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

git merge --no-ff 用于防止 Git 执行“快进”并丢失分支历史记录。如果自创建分支以来没有对 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 和我都在 master 上作为单独的提交完成了。 git merge --no-ff 告诉 Git 永远不要这样做，始终执行合并。

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

即便如此，为什么要删除分支？两个原因。首先，它会使您的分支列表中出现死枝。

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

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

如果您使用的是 Mac，GitX 将为您可视化存储库。 gitk 是通用版本。

【讨论】：

感谢您的回答！您能否在解释什么是 git 分支之前移动以 why delete the branch 开头的部分，以便寻找相同答案的人在顶部得到响应:)。 VonC 的回答也非常有帮助，也许您可以将他的部分回答合并到您的回答中，以便成为一个完整的信息来源。谢谢！
@Maximus IMO 在不了解 Git 分支如何工作的情况下，我删除分支的理由没有意义。至于 VonC 的回答，我看不出他有什么我没有涵盖的内容；你能详细说明一下吗？
可能你是对的，也许是因为我知道所有我不认为它是必备知识。我发现 VonC 的这段回答非常有帮助：因为 myfeature 分支历史代表了为实现 myfeature 所做的所有中间提交。这种策略只在 master 中保留一个提交，而忘记中间步骤，这对于长期存在的分支是有意义的，
@Maximus 我觉得我的插图表达了这一点。也许我可以让它更明确。
插图很好，但必须推断出这一点此策略仅在 master 中保留一次提交，而我会明确说明以使某人的学习更容易:)跨度>

【解决方案2】：

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

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

master 中完成（合并）的一个提交的提交消息应该清楚地表明它是为实现“myfeature”而完成的。

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

【讨论】：

谢谢。短命的树枝是什么意思？与功能分支有什么不同吗？另外，据我了解，当 feature 分支合并到 master 时，有关分支的信息应该存储在合并提交中？
你也可以看看我留下的评论here你的答案吗？
@Maximus stackoverflow.com/a/2850413/6309 展示了一个实时分支（只有少数提交快速合并到 master 中），而不是一个长期分支，其中将完成许多提交（有试验和错误) 在最终合并到 master 之前：在后一种情况下，在 master 中只保留一个提交会更干净。
知道了，谢谢！我在某处读到直接提交到 master 不是一个好主意，但似乎这正是快速转发的短期分支的情况。所以据我了解，这不是一个坏习惯，对吧？
最近在 6 年前的某个 git 相关论坛上偶然发现了你关于 git 约会的非常基本的问题......很难想象你曾经像我一样擅长 git :)