要从当前分支合并到另一个分支

Ka *_* Lo 2 git

git merge合并从另一个分支到当前分支.

可以从当前分支合并到另一个分支,并保留在当前分支中?

当然,以下是可能的,但有三个步骤.

(on brancha)
git checkout master
git merge brancha
git checkout brancha
Run Code Online (Sandbox Code Playgroud)

tor*_*rek 5

简答:不,你必须使用多步法.

稍微复杂一点的回答:是的,这是可能的,但它比多步法更有效.这是诀窍:合并有两个不同的东西; 其中一个是对称的; 1其中一个不是.

对称部分是"提出合并结果"(就连接到提交的树而言).为此,git有四个步骤:

  1. 找到合并基础.这是一些特定的提交2,它既是当前commit(HEAD)的祖先,也是命名的待合并提交(通常是某个分支的提示,但您可以合并任何提交ID).
  2. 区分合并基础HEAD.
  3. 将合并基础与要合并的提交区分开来.
  4. 结合两个差异,在没有冲突的情况下自动生成结果,并且在两个差异发生碰撞的任何地方发生冲突结果(导致合并停止并获得帮助).3

完成所有这些后,git merge通常会在当前分支(或分离的HEAD)上进行新的"合并提交" ,除非您告诉它不要(git merge --no-commit)或由于冲突而停止.

这个新提交是非对称部分.鉴于上述情况(并且忽略了潜在的rerere情况,因为那些可以依赖于diff对的顺序),如果你阻止新的提交,你将获得相同的树,无论你使用哪个"方向"进行合并.但是你会得到一个不同的提交,因为新的合并提交有三个有趣的属性:

  • 父母列表:列表是相同的,但顺序取决于合并的方向.合并的第一个父级始终是要合并的提交(当前分支),其第二个父级是要合并的提交(合并来自分支或提交).
  • 提交消息:默认消息显示"merge branch mergefrom",因此将显示merged-from分支的名称.
  • 自动调整当前分支:这与任何新提交相同.如果您在分支上master,并且进行了新的提交,master则更新点的SHA-1将指向master新提交.在这种情况下,这是新的合并提交.

如果我们停止写入(with --no-commit)实际的合并提交,我们将得到正确的(忽略某些rerere情况).然后我们可以使用正确的父,树和日志消息创建一个新的提交,并通过在某处使用和编写新提交来更新另一个分支,而不是我们所在的分支,然后使用更新引用其他而不是我们所在的分支.该命令按照我们控制的顺序获取父SHA-1 ID的列表,并获取或设置提交消息,并且不提前当前分支(新提交对象的ID只是写入标准输出),所以这这一切都是可行的,但这不是可行的方法.git write-treegit commit-treegit update-refgit commit-tree-m-F


1在执行正常(非章鱼)合并时,除了"我们的"与"他们的"之外,还有其他相应的细微之处,例如索引中的冲突合并条目以及rerere可能性.

2这掩盖了递归合并在某些情况下使用的"虚拟基础",但即使这样,原则仍然是相同的.

3更准确地说,碰撞不仅仅是"进行相同的改变",而是通过仅改变一次而不是两次来自动解决.或者,如果rerere启用,git会检查它可以"重新"使用的那个冲突的"重新"有线"重新"解决方案,然后重用它而不是停止.