合并后，合并文件的提交ID（无冲突）如何改变？ [英] After merge, how does the commit ID of a merged file (no conflicts) change?
问题描述
假设我们有分支A和分支B.
分支A对文件a.cpp有效，并且有几个提交说commit ID 10000 10001，10002，10003 （伪造）。
分支B具有a.cpp。 a.cpp仍然显示旧的提交ID 10000. [注]分支B已经有其他提交。但是Gighub中的a.cpp历史记录只显示一个旧的提交ID 10000.
现在我们将A合并到B.
在B中，我们有a.cpp。它的历史提交ID系列FOR a.cpp文件是什么？
我并不是指B的提交历史记录。我的意思是文件a.cpp的历史记录（您将在Gighub中看到它）
它们是相同的提交ID？
我认为它们是相同的。
但是从Github上的一个实际项目中，我发现它们不是一样的！
问题是：有人对分支B中的其他文件进行了修改（不在a.cpp文件上）。后来我将B合并到A，因为我在A上工作，但发现a.cpp文件存在冲突，尽管它们是相同的！ （但不同的提交ID）。
我不想解决冲突，这很耗时。
[Update 1]
以下是一些来自
的报价：https：//stackoverflow.com/questions/24993253/do-the-commit-ids-remain-same-after合并后的提交ID保持不变吗？
如果您的工作是重新组织的（或樱桃-picked）到上游，然后你
获取然后尝试合并上游，有时git会但是
不总是，能够检测到重复并自动清理
。当它无法自动检测重复时，您
几乎总会遇到各种合并冲突：
怎么回事？如果Git无法自动检测到某些文件没有更改，它会创建大量假合并冲突错误，这对手动解决起来非常耗时。
[Update 2]
感谢下面的答案。
但是，在github中，我发现相同的提交文件，作者和更改的不同提交ID。
请参阅提交id是否保持相同在合并之后？
我查看了团队分支的提交日志，并意识到
虽然是提交消息，作者（我）&日期相同，在远程分支中提交
id是不同的。
[Update 3]
For Tomato Branch：
1000,1001,1002,1003 p
马铃薯分行：
1000年，2001年，2002年，2003年
现在合并番茄分公司到马铃薯分行：
共同的祖先是1000，并且合并提交是2004年在1000到2004年之间，有1001,1002,1003,2001,2002,2003年。
似乎Git会根据编年史顺序将它们放在一起，并更改提交名称。
所以它想要
$ b $ 1000
$ b $（3001（从1001），
3002（表格1002），
<400>（从2001年），
4002（从2002年开始），
<4003（从2003年开始），
<300>（从1003开始） ）
2004
合并基于共同的祖先1000，并且两个最新的提交1003,2003）。
Git也给出了4003，这也许意味着它也会合并：
2003 AND 1002
因此，实际上Git可能会进行许多合并操作，以便发出有效的编年史中间提交。 >解决方案
要了解git中的工作方式，有时候我喜欢使用使用D3可视化Git Concepts ，它可以合理地显示每个提交或分支或rebase存储库的外观。
从以下开始：
git分支B
git commit
git commit
git commit
回购看起来像：
检出B（ git checkout B ）将我们带到：
现在将两者与 git同步合并主人：
这边的历史记录看起来像：
注意快进合并。 Git检测到自从分支以来没有对B进行任何更改，因此它能够移动标签。
但是，如果我们不移动到B分支，而是改为在master上执行 git merge B ，我们得到：
Suppose we have branch A, and branch B.
Branch A works on file a.cpp, and have several commits say commit ID 10000 10001, 10002, 10003 (faked).
Branch B has a.cpp. a.cpp still shows the old commit ID 10000. [Note] Branch B has other commits already. But a.cpp history in Gighub only show one old commit ID 10000.
Now we merge A to B. In B, we have a.cpp. What are its history commit ID series "FOR a.cpp File"? I didn't mean the commit history for B. I mean the history for the file a.cpp (you will see that in Gighub)
Are they same commit IDs?
I assumed they are the same. But from one practical project on Github, I find they are not the same!
The problem is: Someone made modification on some other files in Branch B (not on a.cpp file). Later on I merge B to A, since I work on A, I find that there are conflicts for a.cpp file, although they are the same! (but different commit IDs).
I don't want to resolve the conflicts, which is time-consuming.
[Update 1] Here is some quote from Do the commit ids remain same after a merge?
If your work is rebased (or cherry-picked) into an upstream, and you fetch and then attempt to merge the upstream, git will sometimes, but not always, be able to detect the duplication and clean up automatically. When it cannot auto-detect the duplication, you will almost always get various merge conflicts:
How come? If Git cannot automatically detect no change of some files, it creates a lot of fake merge conflict errors, which is time-consuming to manually solve.
[Update 2] Thanks for answers below. However, in github, I find that different commit IDs for the same commit files, authors and change. See the quote from Do the commit ids remain same after a merge?
I viewed the commit log of the team's branch and realized that although the commit message, author(me) & date were same, the commit id was different in the remote branch.
[Update 3] For Tomato Branch:
1000, 1001, 1002, 1003
For Potato Branch:
1000, 2001, 2002, 2003
Now merge Tomato Branch to Potato Branch:
The common ancestor is 1000, and the merge commit is 2004
Between 1000 and 2004, there are 1001, 1002, 1003, 2001, 2002, 2003.
it seems Git put them between based on chronicle order, AND change the commit name. So it would like
1000
( 3001 (from 1001),
3002 (form 1002),
4001 (from 2001),
4002 (from 2002),
4003 (from 2003),
3003 (from 1003) )
2004
Merge are based on common ancestor 1000, and the two latest commits from the two branches (1003, 2003).
Git also give out 4003, which might mean it also merge:
2003 AND 1002
So actually Git might do many merging operations in order to give out an effective chronicle intermediate commits.
To see how things work in git, sometimes I like to use Visualizing Git Concepts with D3 which does a reasonable job of showing how the repository looks with each commit or branch or rebase.
Starting out with:
git branch B
git commit
git commit
git commit
the repo will look like:
Checking out B (git checkout B) brings us to:
And now to bring the two into sync with a git merge master:
The history on the side looks like:
Note the fast-forward merge. Git detected no changes were done on B since the branch so it was able to just move the label.
However, if we don't move to the B branch and instead do a git merge B while on master, we get:
这篇关于合并后，合并文件的提交ID（无冲突）如何改变？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
