Question

我有一个与git merge workflow相关的问题。

当我们将一个分支合并到另一个分支时，AFAIK可能会发生两件事：要么在目标分支上创建一个提交（在非快进的情况下），要么从合并分支的提交“应用于”提交目的地分支。

我对第一种情况特别感兴趣。在第二种情况下，所有更改历史记录都转移到目标分支，在第一种情况下，历史记录被“压缩”为单个提交。因此，如果我们删除合并的分支，我们只有一个提交包含来自分支的所有更改。另一方面，如果合并分支发生在目标分支AFAIK中，则目标分支的每个rebase都需要对合并分支进行rebase以使它们保持同步。

我的问题是：我们是否应该总是删除合并的分支，或者有一种方法可以保留合并的分支，并防止每次“root”分支重新绑定时对其进行重新定位？

保持合并分支的基本原理是，在这种情况下，我们可以深入了解在该分支上完成的更改的详细历史记录。

Answer 1

除非您在--squash调用中使用git merge选项，否则将保留合并分支的分支信息。新创建的 merge 提交只有两个（或更多，如果是章鱼合并）父提交而不是单个提交。第一个父对应于您合并的分支，其他父对象表示已合并的分支。

您可以使用例如可视化gitk工具，或者通过例如使用

git log --pretty=oneline --abbrev-commit --graph --decorate

因此，在正常合并的情况下（非压缩，无论是快速还是非快速前进），您都可以轻松保留原始分支并继续使用它进行开发。如果你被压扁了，未来的非压缩合并可能会给子孙后代带来很大的困惑，所以最好在它上面使用git reset --hard或git rebase，以防你有新的变化。< / p>

Answer 2

当您合并时，您可以选择压缩它或保持原样。

我会说，如果你压扁它只是去一个头并删除分支，因为它已经明确地完成它的部分后它被压扁。

如果您保持分支完整（不进行挤压），您可以将其保留并在需要时重复使用。

一般来说，如果历史无用甚至错误，我只会压缩提交。我已经完成了开发，其中提交无法构建，以后修复。这些承诺应该在合并之前被压扁。

Answer 3

在我工作的地方，我们使用this作为我们的工作流程模型。当我们实现更改时，我们创建一个功能分支并放入一个空提交来描述分支。

git checkout -b feature1
git commit --allow-empty -m "Create branch to add a menu."

当我们完成这项工作或者达到一个好的停止点时，我们会合并到功能分支（非快进）并删除功能分支。

git checkout develop
git merge --no-ff feature1
git branch -d feature1

分支历史仍然保留为gitk下的“车道变更”。这使我们能够很好地了解该功能的更改内容，但避免使我们拥有的分支列表变得混乱。

Git：应该合并分支是否总是被删除？

3 个答案: