当我运行git checkout branch1
然后git merge branch2
合并两个分支时,似乎 branch2 只是覆盖了 branch1。这应该发生吗?
编辑:
合并前
- branch1 = readme.txt (Hello World!)
- branch2 = readme.txt(你好 2!)
合并后
- branch1 = readme.txt(你好 2!)
tbh,我不确定合并在技术上应该做什么。
当我运行git checkout branch1
然后git merge branch2
合并两个分支时,似乎 branch2 只是覆盖了 branch1。这应该发生吗?
编辑:
合并前
合并后
tbh,我不确定合并在技术上应该做什么。
当将一个分支合并到另一个分支时,git merge会将来自被合并分支的所有提交应用到被合并到的分支,因为这两个分支发生了分歧。您可以将其视为形成一个新的头部,其中包含来自两个分支的最新状态。如果您更改了分支中的文件并将其合并回其父级,则更改将应用于该分支的当前状态。如果两个文件在同一个地方发生了变化,那么合并可能无法解决这个问题,您将不得不进行干预。通常,尽管您最终会得到两个分支的最新作品。
在您的示例中,您所做的更改branch2
已合并到branch1
. 这似乎将文本更改为"Hello 2!"
.
手册页对此有这样的git-merge
说法:
假设存在以下历史并且当前分支是“master”:
A---B---C topic / D---E---F---G master
然后“git merge topic”将重放主题分支上所做的更改,因为它从主分支(即E)分歧直到其当前提交(C)在主节点之上,并将结果与名称一起记录在新提交中两个父提交和来自用户描述更改的日志消息。
A---B---C topic / \ D---E---F---G---H master
总之这是merge的正确操作。
如果和,合并readme.txt
分支将导致文件处于冲突状态。冲突由文件中存在的不同内容的两种变体表示,并用冲突标记进行描述:branch1
branch2
<<<<<<< HEAD:hello.txt
Hello world!
=======
Hello 2!
>>>>>>> 01234567890abcdef:hello.txt
有冲突的合并不会自动提交。相反,将显示一条消息,指示您手动解决冲突并显示如何提交更改:
CONFLICT (content): Merge conflict in <file>
Automatic merge failed; fix conflicts and then commit the result.
正如Nevik Rehnel 所指出的,如果文件在分支中没有分歧,而是简单地从公共共享内容 ( Hello world!
) 修改为新内容 ( Hello 2!
),则不会发生冲突,合并操作将简单地应用更改. 换句话说,合并不保证文件内容的合并,但与公共基础相比,合并更改。