1

我一直在来回走动，不能完全决定哪个工作流程更好。我是否更喜欢压缩合并到 master 中的分支？或者我应该合并它们。

我喜欢 merge -squash 并且一直在使用它。

合并 --squash 的优点：

  1. 更清洁的历史。
  2. 更容易使用对分。

有什么理由我不应该使用 merge --squash 而是使用普通的旧合并？

4

2 回答 2

3

当您想要保留所有间歇性提交时，快进合并很有用，例如当分支尝试一些可能不起作用的事情时。丢弃临时分支比重置工作分支更容易。但是，当实验工作时，最好将提交快速转发到工作分支，将其保留为保留实验时的状态。

我没有理由不将工作提交压缩成一个包含所有更改的消息的综合提交。正如您所指出的，这使历史记录保持干净且更易于使用。从我所见，这是保持树清洁的首选方法。

git merge --squash与一个父级进行提交，因此它不显示与正在合并的父级的连接。

-A---------C  <-- `git merge --squash`
  \
   *--*--B

另一种选择是使用git merge --no-ff（不快进）强制合并提交。这个提交将有父母双方。优点是保持树干净，同时在需要时仍具有详细的提交历史记录。

-A---------C  <-- `git merge --no-ff`
  \       /
   *--*--B

两个C提交是相同的，当你想保留时选择后者B。

于 2013-01-15T19:27:37.890 回答
2

这取决于。

挤压会丢失信息，是否挤压取决于该信息是否重要。对于在六个月或六年后试图弄清楚为什么一行代码是这样的人来说很重要。这取决于分支中的内容、更改的数量、更改的大小以及日志消息的质量。

一个简单的经验法则？考虑壁球的结果并问自己“如果我在 master 上编码，我会这样做吗？” 如果答案是肯定的，那么 diff 和 log 一起将允许人们在未来弄清楚为什么一行代码发生了变化，然后压缩合并。

如果答案是否定的，这将不是一个可以接受的对 master 的提交，有太多变化或太多交织在一起的变化，那么不要挤压它。合并它，也许在考虑是否可以将分支中的任何提交压缩在一起之后。

至于挤压是“更干净”和“更容易平分”......我觉得这只是表面上的。如果你把书架上的所有书页都拿出来缝成一个巨大的封面，这样你现在只需要担心一本书就可以了。如果它们是一堆各自独立的小说，那就无济于事了。如果它们是年度会议报告，最好将它们捆绑在一起。

从某种意义上说，平分更容易，因为您不太可能有破坏构建的提交，但是如果您的平分落在一个巨大的变化上，人们仍然不得不对可能有原因的大量可能性感到困惑问题，它使平分线的工作更加困难。

使用与提交到 master 时相同的标准来决定是否压缩合并，这样就可以了。

于 2013-01-16T19:47:14.453 回答