产生git合并冲突 [英] Producing a git merge conflict
问题描述
我正试图故意产生git合并冲突.这是我所做的
I'm trying to produce a git merge conflict intentionally. Here is what I did
mkdir to-stack
cd to-stack
git init
vi a.txt
Added some text to first line of a.txt
git add a.txt
git commit -m "Added a line to a.txt"
git checkout -b other
vi a.txt
Updated the text on first line of a.txt to something else
git add a.txt
git commit -m "Updated line 1"
git checkout master
git merge other
发生合并,并且master分支中的a.txt内容被其他分支的内容覆盖
Merge happened and the content a.txt in master branch got overwritten to that of from other branch
我期望合并时会发生合并冲突.由于我在其他分支中更改了同一行
I was expecting a Merge conflict to happen when doing the merge. Since I had changed the same line in other branch
您能告诉我为什么在上述情况下没有发生合并冲突吗?
Can you tell me why Merge conflict didn't happen in above case?
推荐答案
一个 merge 合并了从某些常见提交到两个不同提交的更改(它们之间的关系是他们俩在历史上都有共同的承诺.
A merge combines the changes from some common commit, to two different commits (whose relationship is that they both have that common commit in their histories).
也就是说,考虑以下提交图,其中每个o
或*
代表一个提交,每个提交的 parent 是通过向左跟随其连接(向上移动)而找到的提交或按需要下移):
That is, consider the following commit graph, where each o
or *
represents a commit, and every commit's parent is the commit that is found by following its connection leftwards (moving up or down if necessary):
o <-- branchA
/
...--o--*
\
o--o <-- branchB
branchA
和branchB
share 的第一个提交是标记为*
的提交.它们还共享每个较早的提交(在*
的左侧),但是*
是最有趣的此类提交.我们将此提交称为branchA
和branchB
的合并基础.
The first commit that branchA
and branchB
share is the one marked *
. They also share every earlier commit (to the left of *
), but *
is the most interesting such commit. We call this commit the merge base of branchA
and branchB
.
运行时:
$ git checkout branchA
$ git merge branchB
git merge
步骤可以看到我们在 branchA
上(由于git checkout
命令),并且我们要求合并branchB
的最尖端提交.然后,Git找到此合并基础提交,并运行两个 git diff
命令.
the git merge
step sees that we are on branchA
(due to the git checkout
command), and that we are asking to merge the tip-most commit of branchB
. Git then locates this merge base commit, and runs two git diff
commands.
假设提交*
的哈希值是ba5e...
,并且branchA
上的提示提交是提交1111...
,而branchB
的提示提交是2222...
.这两个git diff
命令实际上是:
Let's say the hash of commit *
is ba5e...
, and the tip commit on branchA
is commit 1111...
with the tip commit of branchB
being 2222...
. The two git diff
commands are then essentially:
$ git diff ba5e 1111
和:
$ git diff ba5e 2222
第一个差异告诉Git我们做了什么":我们的内容从*
变为branchA
的尖端.第二个差异告诉Git他们做了什么":从*
到branchB
的尖端,他们发生了什么变化.
The first diff tells Git "what we did": what we changed from *
to the tip of branchA
. The second diff tells Git "what they did": what they changed going from *
to the tip of branchB
.
当我们所做的事情"的某些部分更改同一文件的同一行时,与他们所做的事情"的某些部分更改时,发生<合并>冲突,但是两种变化是不同的.例如,如果我们都更改README.txt
来更改苹果的颜色,但是我们将其从紫色更改为黑色,而又将其从紫色更改为橙色,则Git不知道哪个服用.
A merge conflict occurs when some part of "what we did" changes the same line(s) of the same file(s) as some part of "what they did" changes, but the two changes are different. For instance, if we both change README.txt
to change the color of an apple, but we change it from purple to black, and they change it from purple to orange, Git doesn't know which one to take.
所以,让我们做到这一点:
So, let's do just that:
mkdir mtest && cd mtest && git init
echo 'for testing' > README.txt
echo 'have a purple apple' >> README.txt
git add README.txt && git commit -m initial
这将使用一个文件README.txt
创建分支master
.现在,让我们从一次提交中创建两个独立的分支,并在每个分支中更改苹果的颜色:
This creates branch master
with one file, README.txt
. Now let's create two separate branches forking from this one commit, and change the color of the apple in each branch:
git checkout -b branchA master
sed -i '' s/purple/black/ README.txt
git add README.txt && git commit -m black
git checkout -b branchB master
sed -i '' s/purple/orange/ README.txt
git add README.txt && git commit -m black
现在,我们只需将一个分支与另一个分支合并即可.我们当前在branchB
上,因此我们现在可以在git merge branchA
上.解决冲突并提交后,我们将在branchB
上进行合并.或者,我们可以先git checkout branchA
,然后再git merge branchB
.我们将得到 same 冲突,但是一旦解决并提交,我们将在branchA
上进行合并.
Now we simply merge one branch with the other. We are currently on branchB
, so we can git merge branchA
now. Once we resolve the conflict and commit, we'll have a merge on branchB
. Or, we can git checkout branchA
first, then git merge branchB
. We will get the same conflict, but once we resolve it and commit, we'll have a merge on branchA
.
这篇关于产生git合并冲突的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!