Git“失踪”提交
我处于一种情况，即在功能分支中进行的某些更改没有反映在master中，即使此分支已合并到该分支中。 我不明白为什么。 为了简单起见，我们假设这个提交有一个散列“A”并且改变了文件“file”
这可能最好通过以下命令来说明：
$ 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
但事情是...文件没有被重命名。 所以这并不能完全解释事情。
你是一个邪恶合并的受害者。
这里是如何重现它
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
现在您将看到分支主机包含引入文件file的提交（在我的情况下为9469682 ）
git branch --contains 9469682
feature_branch
* master
但是一个git日志不会显示它，因为它已被移动
git log -- file
(no output)
使用
git log --follow -- file
并且提交再次出现。
另外请记住，合并可能会变得更加邪恶。 如果该file的内容也比Évengit git log --follow更改很多 - 由于重命名阈值， git log --follow无法检测到它。
在这种情况下，使用git log --follow --find-renames=来调整重命名阈值。
如果生成差异，则检测并报告每次提交的重命名。 在遍历历史记录时跨越重命名后续文件，请参阅 - 关注。 如果指定了n，则它是相似度指数的阈值（即与文件大小相比的添加/删除量）。 例如，-M90％表示Git应该考虑删除/添加对是一个重命名，如果超过90％的文件没有改变。 如果没有％符号，则该数字应作为分数读取，并在其前面加小数点。 即，-M5变为0.5，因此与-M50％相同。 同样，-M05与-M5％相同。 要将检测限制为精确重命名，请使用-M100％。 默认相似度指数为50％。
如果文件的位置不知怎么改变了，你可能需要告诉git log follow ：
$ git checkout master
$ git log --follow -- file | grep A
您可以检查git log --oneline -- file和git log --oneline --follow -- file之间是否有区别，以查看文件是否已被重定位。
上一篇: Git "missing" commit
下一篇: Encrypt and Decrypt by AES algorithm in both python and android