Git“缺失”承诺 [英] Git "missing" commit
问题描述
我处于一种情况,即在功能分支中进行的某些更改未反映在master中,即使此分支已合并到该分支中。我不明白为什么。为了简单起见,我们假设这个提交有一个散列A,并更改了文件file。
这可能最好用下面的命令来说明:
$ git checkout master
$ git branch --contains A
* master
feature_branch
$ git log file | grep A
(不输出)
$ git checkout feature_branch
$ git log file | grep A
A
任何人都可以解释这里发生了什么?更重要的是,未来有什么可以做到的,以防止这种情况发生?
编辑:
正如少数人提到的,提交:
$ git checkout master
$ git log --follow file | grep A
A
但事情是...文件不是重命名。所以,这并不能完全解释事情。无论如何。
你是一个邪恶合并的受害者。 / strong>
以下是重现它的方法
git init testrepo
cd testrepo
触摸初始
git添加初始
git commit -m'初始提交'
git checkout -b feature_branch
回声A>> file
git add file
git commit -m'file committed'
git checkout master
现在做一个交互式合并,就好像存在合并冲突一样
git merge --no -commit --no-ff feature_branch
并移动文件 file <
$ b $ pre $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ file someOtherFile
git commit
现在您将看到分支主控包含提交(在我的引入文件 file
9469682 > git branch --contains 9469682
feature_branch
* master
但是一个git日志不会显示它,因为它被移动了。
git log - 文件
(无输出)
使用
git log --follow - file
和提交应用耳朵再次。
另外请记住,合并可以得到更多的邪恶。如果文件
的内容也改变了很多,比
在这种情况下,请使用 git log --follow --find-renames =
来调整重命名阈值。
如果生成差异,则检测并报告每次提交的重命名。在遍历历史记录时跨越重命名后续文件,请参阅 - 关注。如果指定了n,则它是相似度指数的阈值(即与文件大小相比的添加/删除的量)。例如,-M90%表示Git应该考虑删除/添加对是一个重命名,如果超过90%的文件没有改变。如果没有%符号,则该数字应作为分数读取,并在其前面加小数点。即,-M5变为0.5,因此与-M50%相同。同样,-M05与-M5%相同。要将检测限制为精确重命名,请使用-M100%。默认相似度指数为50%。
I'm in a situation where some changes made in a feature branch are not reflected in master, even though this branch was merged into it. I'm at a loss to understand why. For simplicity, let's say this commit has a hash "A" and changed file "file"
This can probably best be illustrated by the following commands:
$ 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
Can anyone explain what's going on here? More importantly, is there anything that can be done to prevent this in the future?
EDIT:
As mentioned by a few people, the following does show the commit:
$ git checkout master
$ git log --follow file | grep A
A
But the thing is... the file was not renamed. So that doesn't fully explain things, either..
You are a victim of an evil merge.
Here is how to reproduce it
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
Now do an interactive merge as if there were merge conflicts
git merge --no-commit --no-ff feature_branch
and move the file file
(evil merge).
testrepo (master|MERGING)
git mv file someOtherFile
git commit
Now you will see that branch master contains the commit (in my case 9469682
) that introduced file file
git branch --contains 9469682
feature_branch
* master
But a git log will not show it, because it was moved
git log -- file
(no output)
Use
git log --follow -- file
and the commit appears again.
Also keep in mind that the merge can get more evil. If the file
's content also changed a lot than èven git log --follow
will not detect it, because of the rename threshold.
In this case use git log --follow --find-renames=
to adjust the rename threshold.
If generating diffs, detect and report renames for each commit. For following files across renames while traversing history, see --follow. If n is specified, it is a threshold on the similarity index (i.e. amount of addition/deletions compared to the file’s size). For example, -M90% means Git should consider a delete/add pair to be a rename if more than 90% of the file hasn’t changed. Without a % sign, the number is to be read as a fraction, with a decimal point before it. I.e., -M5 becomes 0.5, and is thus the same as -M50%. Similarly, -M05 is the same as -M5%. To limit detection to exact renames, use -M100%. The default similarity index is 50%.
这篇关于Git“缺失”承诺的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!