Question

我试图故意产生一个git合并冲突。这就是我做的事情

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

合并发生，主分支中的内容a.txt被覆盖到其他分支的内容

我希望在进行合并时发生合并冲突。因为我在其他分支中改变了相同的行

你能告诉我为什么在上述案件中没有发生合并冲突吗？

Answer 1

merge 将来自某些常见提交的更改组合到两个不同的提交（其关系是它们在其历史记录中都具有该公共提交）。

也就是说，考虑以下提交图，其中每个o或*表示提交，每个提交的父是通过跟随其连接找到的提交向左（必要时向上或向下移动）：

          o   <-- branchA
         /
...--o--*
         \
          o--o   <-- branchB

branchA和branchB 共享的第一次提交是标记为*的提交。它们还共享每个早期的提交（*的左侧），但*是最有趣的提交。我们将此提交称为branchA和branchB的合并基础。

当你跑步时：

$ git checkout branchA
$ git merge branchB

git merge步骤看到我们 on branchA（由于git checkout命令），并且我们要求合并最尖端提交branchB。然后Git找到此合并基础提交，并运行两个 git diff命令。

假设提交*的哈希是ba5e...，而branchA上的提示提交是提交1111...，提示branchB为2222... {1}}。这两个git diff命令基本上是：

$ git diff ba5e 1111

和

$ git diff ba5e 2222

第一个差异告诉Git“我们做了什么”：我们从*更改为branchA的提示。第二个差异告诉Git“他们做了什么”：他们的变化从*变为branchB的尖端。

合并冲突发生在“我们做了什么”的某些部分改变了相同文件的相同行，而“他们做了什么”的某些部分发生了变化，但是两个变化是不同的。例如，如果我们都改变README.txt来改变苹果的颜色，但是我们将它从紫色变为黑色，并且它们从紫色变为橙色，Git不知道哪一个。

所以，让我们这样做：

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

这会创建一个文件master的分支README.txt。现在让我们从这个提交中创建两个独立的分支，并在每个分支中更改apple的颜色：

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。我们将得到相同的冲突，但一旦我们解决并提交，我们就会在branchA上进行合并。

产生git合并冲突

1 个答案: