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