我有一个与 git 合并工作流相关的问题。
当我们将一个分支合并到另一个分支时，AFAIK 可能会发生两件事：要么在目标分支上创建单个提交（在非快进情况下），要么将来自合并分支的提交应用到“之上”在目标分支上提交。
我对第一个案例特别感兴趣。在第二种情况下，所有更改历史记录都被转移到目标分支，在第一种情况下，历史记录被“压缩”为单个提交。结果，如果我们删除合并的分支，我们只有一个提交合并了该分支的所有更改。 另一方面，如果合并分支恰好来自目标分支 AFAIK，则目标分支的每个 rebase 都需要合并分支的 rebase 以保持它们同步。
我的问题是：我们应该总是删除合并的分支，还是有办法保留合并的分支并防止每次“根”分支被重新定位时重新定位它？
保留合并分支的理由是，在这种情况下，我们可以深入了解对该分支所做更改的详细历史记录。
【问题讨论】：
标签： git git-branch git-merge
除非您在git merge 调用中使用--squash 选项，否则合并分支的分支信息将被保留。新创建的 merge 提交只有两个（或更多，在章鱼合并的情况下）父提交，而不是一个。第一个父级对应于您合并到的分支，其他父级代表合并的分支。
您可以使用例如gitk 工具，或通过例如使用
git log --pretty=oneline --abbrev-commit --graph --decorate
因此，在正常合并的情况下（非压缩，无论是快进还是非快进），您都可以轻松保留原始分支并继续使用它进行开发。如果您进行了 squash，未来的非 squash 合并可能会给后人带来极大的困惑，因此最好使用git reset --hard 或git rebase，以防您已经有了新的更改。
【讨论】：
git-rebase(1) 很好地解释了这一点。
TopGit 在这里是否有帮助。 StackedGit 当然可以让你很容易地变基，但是，用它维护的分支首先不适合合并......
合并时，您可以选择将其压缩或保持原样。
我想说的是，如果您将其压扁，只需先删除分支，因为它显然已经完成了它被压扁后的一部分。
如果您保持分支完好无损（没有挤压），您可以留下它并在需要时重新使用它。
一般来说，我只会在历史无用甚至错误的情况下压缩提交。我已经完成了提交无法构建稍后修复的开发。这些提交应该在合并之前被压扁。
【讨论】：
在我工作的地方，我们使用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 下的“换道”。这使我们可以很好地了解该功能的更改内容，但避免弄乱我们拥有的分支列表。
【讨论】：