git - 为什么我的 master 分支在将 develop 压缩成 master 后显示它落后于 develop？

Question

我刚刚 merge 了我的整个 develop history历史进入我的主分支。正如我所见，应该连接 network graph 中的两个分支，它没有。另外，我的主分支显示:This branch is 1 commit ahead, 151 commits behind develop. ，虽然我希望它在 Squash merge 后与 develop 保持一致。为什么不是这样？

以及如何将我的更改从 develop merge 到 master 中，这样它只是对 master 的一次提交，甚至与 develop(在那时)并在网络图中连接？

Answer 1

Squash merge 会在“我们的”分支(在您的情况下是 master)上创建一个新提交，以引入“他们”分支(开发)的更改，就好像您已将两者 merge 一样。它实际上并没有创建 merge (将两个分支联系在一起的多父提交)；如果这样做，那将只是常规 merge 。所以 git 之后无法判断来自开发的提交等于添加到 master 的新提交。

我想我没有看到正确的用例，但我发现 Squash merge 有点毫无意义。据我所知， merge 和 rebase 之间的两个世界中最糟糕的。

更新 - 根据评论，一些澄清可能会有所帮助......

所以我们知道常规 merge 是具有两个或更多父级的单次提交。它的第一个父级是来自 merge 的“我们的”分支(假设是 master)，我们 merge 的分支是额外的父级。单次提交就是添加到 master 的全部内容。

A ---- B - M
         /
X ---- Y 

所以这似乎是错误的，因为 git log将分别显示 A、B、X 和 Y。这是默认行为，因为它向您展示了如何真正引入更改。

你可以通过说 git log --first-parent 来获得更线性的 View 。 ，但仍然 log不想显示 merge 的补丁(meh)，因此它看起来不像您从 Squash 或 rebase 中获得的线性历史记录。

但肯定 M^等于 B ，所以从大师的角度来看 M是一个单一的提交，它引入了来自分支的所有更改。如果您还希望它记录来自 X 的更改和 Y可从 M 到达，那么这就是 git 提供的方式。

现在你可能已经发现我不喜欢 merge --squash太多了，原因如下:

假设我进行了 Squash merge ，而不是上图中的常规 merge 。为清楚起见，我将添加一个共同的祖先 O:

O ---- A ---- B ---- XY <--(master)
 \
  X ---- Y <--(development)

现在还有更多的工作发生在开发上

O ---- A ---- B ---- XY <--(master)
 \
  X ---- Y ---- Z <--(development)

那么我如何最好地将 Z merge 到我的主分支中呢？

如果我将 Z 定期 merge 到 master，那么 git 就会知道 Y 是 Z 和 M 的共同祖先(但我没有 M；我做了一个 Squash ，所以我有 XY)，我可以做另一个 merge 没有问题。

如果我将我的开发分支重新设置为 master，我会

O ---- A ---- B ---- X' ---- Y' <-- (master)
                               \
                                 Z <-- (development)

这也可以，只要我的 rebase 没有弄乱其他任何人的历史(如果 X 和 Y 已经发布，它可能会这样做，但那是另外一 jar 蠕虫)。

在这两种情况下，我都可以毫无问题地进行另一次 merge 或 rebase 。但是通过进行 Squash merge ，我将 git 混淆为看到两个历史记录，而它们之间没有良好的记录关系，因此除非我一直将 ref 指向 Y，否则我很不走运

O ---- A ---- B ---- XY <--(master)
 \
  X ---- Y ---- Z <--(development)
         ^- (last_merge)

而且，正如您所注意到的， git status如果你走这条路，你会永远迷茫。