git merge 说 Already up-to-date 但在分支中有一个 promise 的差异

Question

我有两个分支:master和 develop .当从 develop 更改时最终确定它们 merge 为 master .

此时，分支应该是同步的。但是，我注意到 master 中缺少一个文件但在 develop分支。 (看起来它以某种方式被删除了，但我无法使用 git log -- myfile.txt 命令找到任何证据。

我试图 merge develop至 master但它说没有什么可以 merge 的。

> git checkout master
> git merge --no-ff develop
Already up-to-date

我如何重新 merge 我们 develop 中的那个丢失的文件分支到我们的 master分支？

Answer 1

你根本不 merge 它；相反，您只需从 develop 中提取您想要的文件。分支并将其提交到 master分支。 (我假设“丢失的”文件从未被 merge ，可能是由于最后一次 merge 的人犯了错误 - 任何 merge ，或者可能是故意的。)从另一个分支中提取文件，同时在 master :

# run "git status" here to make sure you're on master
# and have no other changes you want to commit first!
git checkout develop -- path/to/file

由于这种 check out “通过”索引写入，新文件现在已暂存并准备提交到分支 master .

下面讨论。

merge 实际上并不同步分支(更具体地说，这并不意味着它们将具有相同的工作树，无论如何)。全部 git merge确实是查看提交历史以查看应 merge 哪些更改(如果有)。这意味着它必须找到最近的共同历史。让我们画一些提交图片段来说明这一点。

git checkout master

选择一些特定的提交，然后:

git merge <sha1-or-other-identifier-like-develop>

告诉 git 从已识别的 SHA-1 开始，并查看该分支最后“与”一起的位置 master .这是“merge 基础”的 SHA-1:

...-o-*-o-o-o   <-- master
       \
        o-o     <-- develop

merge 基础是标记为 * 的提交在这里，在 * 之后有提交在 develop 标识的行上不在 master 标识的行上，所以这个序列需要 merge 。

然而:

...-o-*-o-o-o   <-- master
       `---___
              `---- develop

在这里， develop直接指向提交 * (再次 merge 基础)。从那以后没有提交 develop也未在 master 下方找到的.所以这是 Already up-to-date .同样适用于:

...-o-o-o-M   <-- master
     \   /
      o-*     <-- develop

如果 develop，您会看到这种情况最近 merge 了: master 上有一个 merge 提交，我已经标记了 M . merge 基础仍然提交 * ; develop 直接指向该提交， merge 提交也是如此 M .因此，再次没有任何要 merge 的内容(在 develop 上没有提交，还没有在 master 上提交，由 merge 提交 M 提供)。

如果(git 认为)需要 merge ，git 会将基数( * 提交)与当前分支上的最新提交( master 的提示)进行比较，并将基数与您要求的提交进行比较 merge (在这种情况下，是 develop 的尖端)。然后(本质上)查看两个差异，在第二个差异中进行第一个中尚未发生的任何更改，并将它们应用于工作树。

如果一切顺利，git 通常会在此时进行 merge 提交(尽管您可以抑制它)。如果没有，它会因 merge 冲突而停止，并让您自己解决问题，然后您执行自己的“git commit”以提交 merge 。

merge 提交的工作树包括 git 自动解析的任何内容，以及您在此之后暂存的内容(如果您手动提交)。一旦 merge 提交本身存在，提交图将使得 git 认为不需要后续 merge (例如，直到将更多提交添加到 develop)。

如果(git 认为)不需要 merge ，它当然什么都不做。

对于最后两个插图:

...-*-----M1--M2  <-- master
     \   /   /
      A-B-C-D     <-- develop

做了两次 git merge --no-ff develop 后出现这种模式s 进入 master ，在 master 上没有中间提交:

第一次 merge 始于 *作为公共(public) merge 基( M1和 M2还不存在)，所以发现 *之间的变化和 B . *之间没有变化和它本身所以 merge 很容易:git 将这些更改添加到 * (给出与 B 相同的工作树)并 merge 提交 M1 .

第二次 merge 开始于提交 B作为 merge 基础( M2 尚不存在)。所以取了 B之间的差值和 M1 , 无；和 B之间的区别和 D ，这是 develop上的新进展.然后结合这些差异，将它们应用到 M1 的树中。 ，并进行新的 merge 提交 M2 .树为 M2与 D 相同.

然而，这有点不同:

...-*-o---M1--M2  <-- master
     \   /   /
      A-B-C-D     <-- develop

在这种情况下，公共(public)基数是 *和以前一样，但有所不同 *和 o可能产生了一些东西。差异 *和 B显示了分支上发生的事情 develop . Git 通过将第二组更改应用于 o 的工作树来将这两者结合起来。 , 进行 merge 提交 M1 . M1 的工作树可能与 B 的不同，因为它还包含在提交 o 时发生的任何事情.但它可能是一样的，因为 git “组合”了这些变化。

具体来说，如果来自 o 的差异至 B包含与来自 * 的差异相同的更改至 o ，M1 的树将匹配 B 的树.如果没有，就不会。也就是说，git 只保留一个相同更改的副本。 (“相同”在这里的意思是“就 git 可以说的而言”:它不是特别聪明。如果一个更改是添加“ Shiny 金属”一词，另一个更改是添加“ Shiny 金属”一词，git 认为这些是不同的。)

在任何情况下，第二次 merge 都会重复模式:比较 B 的工作树对比 M1 , 和 B对比 D .无论在第二个中发现第一个中尚未包含的更改，都将这些更改应用于 M1 的工作树。 ，并使用结果为 M2 制作工作树.