Question

我在某个特征分支中进行的更改未在master中反映的情况下，即使此分支已合并到其中。我不知道为什么。为简单起见，我们假设这个提交有一个哈希＆＃34; A＆＃34;并更改了文件＆＃34;文件＆＃34;

以下命令可能最好地说明了这一点：

$ git checkout master

$ git branch --contains A
* master
feature_branch

$ git log file | grep A
(no output)

$ git checkout feature_branch

$ git log file | grep A
A

有人能解释一下这里发生了什么吗？更重要的是，有什么办法可以防止将来出现这种情况吗？

修改

正如一些人所提到的，以下确实显示了提交：

$ git checkout master

$ git log --follow file | grep A
A

但事情是......文件不重命名。因此，这并不能完全解释事情......

Answer 1

你是邪恶合并的受害者。

以下是如何重现它

git init testrepo
cd testrepo

touch initial
git add initial
git commit -m 'initial commit'

git checkout -b feature_branch
echo "A" >> file
git add file
git commit -m 'file committed'

git checkout master

现在进行交互式合并，就好像存在合并冲突一样

git merge --no-commit --no-ff feature_branch

并移动文件file（邪恶合并）。

testrepo (master|MERGING)

git mv file someOtherFile
git commit

现在您将看到分支主文件包含引入文件9469682的提交（在我的情况下为file）

 git branch --contains 9469682
  feature_branch
 * master

但git日志不会显示它，因为它被移动了

 git log -- file
 (no output)

使用

git log --follow -- file

再次出现提交。

还要记住合并可能会变得更加邪恶。如果file的内容也发生了很大的变化，那么由于重命名阈值，git log --follow将无法检测到它。

在这种情况下，请使用git log --follow --find-renames=调整重命名阈值。

如果生成差异，请检测并报告每次提交的重命名。要在遍历历史记录时通过重命名跟踪文件，请参阅--follow。如果指定n，则它是相似性指数的阈值（即，与文件大小相比的添加/删除量）。例如，-M90％表示如果超过90％的文件未更改，Git应将删除/添加对视为重命名。如果没有％符号，则该数字将作为分数读取，并在其前面加上小数点。即，-M5变为0.5，因此与-M50％相同。同样，-M05与-M5％相同。要将检测限制为精确重命名，请使用-M100％。默认相似性指数为50％。

Answer 2

如果某个文件的位置发生了变化，您可能需要告诉git log follow：

$ git checkout master
$ git log --follow -- file | grep A

您可以检查git log --oneline -- file和git log --oneline --follow -- file之间是否存在差异，以查看该文件是否已重新定位。

Git＆＃34;失踪＆＃34;承诺

2 个答案: