应该在提交历史中保持合并吗？

Question

我发现在提交历史记录中保持合并是没用的。相反，如果我在进行合并时保留提交历史记录会更加整洁。就像这篇文章中提到的Keep commits history after a 'git merge'

一样

因为我注意到在github中，当用户接受pull请求时，通常他们不会创建新的合并提交而不是仅保留提交历史记录。所以我只是想知道合并的最佳做法是什么？

Answer 1

这里没有“最佳实践”。选择是你的。

有些人保留合并提交，即使是快进，因为它可以很好地记录分支何时完成。这些人更喜欢“完整而准确”的历史，而不是“干净”的历史。

有些人避免合并提交，甚至改变他们的分支，因为它使历史更容易阅读。这些人更喜欢“干净”的历史，而不是“完整和准确”的历史。

大多数人都会选择一个中间地带，在将这些变化公之于众之前进行重新定位和压扁，这会使每个分支变得干净。然后将分支正常合并，以保留完整和准确的历史记录，至少对于大局而言。

我自己，我更喜欢在完成一个功能分支时使用merge --no-ff，而我倾向于“准确”而不是“干净”，但我试图在这里和那里用红酒和底板来保持噪音。

Answer 2

除了@Dietrich Epp所说的以外，我还要根据您使用的流程进行扩展，合并提交可以证明是否有用。

例如，我使用一个功能流，其中Jira票证必须是一个功能分支，一个功能分支始终导致一个“拉取请求”，并且PR在开发中（然后是母版）通过壁球策略{{ 1}}，它将所有PR的提交压缩到一个提交中。因此，我感觉不需要合并提交，因为我知道开发/母版中的每个提交都是PR。另一方面，如果我允许PR中进行多次提交，例如，为了使项目历史记录更加详细，我可以使用合并策略git merge --squash以便能够在合并功能时清楚地查看我的历史记录。

最后，您可以使用git merge --no-ff来读取提交的干净历史记录，或使用git log --no-merges来仅查看合并。