从当前分支合并到另一个分支 [英] To merge from the current branch into the other branch

问题描述

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

是否可以将从当前分支合并到另一个分支，并保留在当前分支中?

Possible to merge from the current branch into the other branch, and stay in the current branch?

当然可以进行以下操作，但是需要三个步骤.

Of course the following is possible, but there are three steps.

(on brancha)
git checkout master
git merge brancha
git checkout brancha

推荐答案

简短的回答:不，您必须使用多步方法.

Short answer: no, you must use the multi-step method.

涉及的问题稍微多一点:是的，有可能，但是它比多步方法要更多.诀窍是:合并会做两种不同的事情；这两个之一是对称的； ¹ 这两个不是之一.

Slightly more involved answer: yes, it's possible, but it's even more work than the multi-step method. Here's the trick: a merges does two different things; one of those two is symmetric;¹ one of those two is not.

对称部分是产生合并结果"(就附加到提交的树而言).为此，git有四个步骤:

The symmetric part is "coming up with a merge result" (in terms of a tree to attach to a commit). To do this, git has a four-step process:

1. 找到合并基础.这是一些特定的commit ² ，它既是当前提交( HEAD )的祖先，又是命名的要合并的提交的祖先(通常是某个分支的尖端)，但您可以合并任何提交ID).
2. 将合并基础与 HEAD 相对.
3. 将合并基础与要合并的提交进行区分.
4. 合并两个差异，在没有冲突的情况下自动生成结果，并且在两个差异发生冲突的地方出现冲突的结果(导致合并停止并获得帮助). ³

1. Find the merge base. This is some particular commit² that is both an ancestor of the current commit (HEAD) and of the named, to-be-merged commit (often the tip of some branch, but you may merge any commit-ID).
2. Diff the merge base against HEAD.
3. Diff the merge base against the to-be-merged commit.
4. Combine the two diffs, with automatic results where there are no conflicts, and conflicted results (which cause the merge to stop and get help) wherever the two diffs collide.³

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

Having done all of that, git merge normally makes a new "merge commit" on the current branch (or at the detached HEAD), unless of course you tell it not to (git merge --no-commit) or it stopped due to conflicts.

此新提交是非对称部分.鉴于上述情况(并且也忽略了可能的 rerere 情况，因为这些情况可能取决于差异对的顺序)，如果阻止新的提交，则将得到相同的 tree ，无论您使用哪个方向"进行合并.但是您会得到一个不同的 commit ，因为新的合并提交具有三个有趣的属性:

This new commit is the non-symmetric part. Given the above (and ignoring potential rerere cases as well, since those can depend on the order of the diff pair), if you prevent the new commit, you'll get the same tree regardless of which "direction" you use to do the merge. But you'll get a different commit, because the new merge commit has three interesting properties:

• 父母名单:名单相同，但顺序取决于合并的方向.合并的 first 父对象始终是要合并的提交(当前分支)，而其 second 的父对象始终是要合并的提交(merge-from分支或提交).
• 提交消息:默认消息为"merge branch mergefrom"，因此将显示merged-from分支的名称.
• 当前分支的自动调整:这与任何新提交相同.如果您在分支 master 上，并且进行了新提交，则 master 指向的SHA-1将被更新，以便 master 指向到新的提交.在这种情况下，这就是新的合并提交.

• The list of parents: the list is the same, but the order depends on the direction of the merge. A merge's first parent is always the commit being merged-into (the current branch), and its second parent is the commit being merged-in (the merge-from branch or commit).
• The commit message: the default message says "merge branch mergefrom", so the name of the merged-from branch appears.
• The automatic adjustment of the current branch: this is the same as for any new commit. If you're on branch master, and you make a new commit, the SHA-1 to which master points is updated so that master points to the new commit. In this case, that's the new merge commit.

如果我们停止编写实际的合并提交(使用-no-commit )，我们将获得正确的 tree (忽略某些 rerere案例).然后，我们可以使用正确的父代，树和日志消息创建一个新提交，并使用 git write-tree 和 git commit-tree 将新的提交写入某个地方，然后使用 git update-ref 更新除我们所在分支之外的其他引用. git commit-tree 命令按照我们控制的顺序获取父SHA-1 ID列表，并采用 -m 或 -F 来设置提交消息，并且不前进当前分支(新提交对象的ID只是写到标准输出中)，因此这一切可行，但这并不是可行的方法.

If we stop the actual merge commit from being written (with --no-commit), we'll get the right tree (ignoring certain rerere cases). We can then create a new commit with the correct parents, tree, and log message, and update the other branch, rather than the one we're on, by using git write-tree and git commit-tree to write the new commit somewhere, then using git update-ref to update a reference other than the branch we're on. The git commit-tree command takes a list of parent SHA-1 IDs, in an order we control, and takes -m or -F to set the commit message, and does not advance the current branch (the new commit object's ID is simply written to standard output), so this is all feasible, but it's not the way to go.

¹ 除了进行正常(非章鱼)合并时的我们的"与他们的"之外，还包括其他相应的细微之处，例如索引中有冲突的合并项以及重新获得的可能性.

¹Aside from "ours" vs "theirs" when doing a normal (non-octopus) merge, and other corresponding subtleties such as the conflicted merge entries in the index, and the rerere possibilities.

² 这掩盖了在某些情况下递归合并所使用的虚拟基础"，但是原理仍然保持不变.

²This glosses over the "virtual base" that recursive merge uses in certain cases, but the principle remains the same even then.

³ 更准确地说，冲突不是简单地进行相同的更改"，而是仅通过一次更改而不是两次更改即可自动解决.或者，如果启用了 rerere ，则git会检查该冲突的重新"编码的重新"解决方案以使其可以重复"使用，然后将其重用而不是停止.

³More precisely, where the collision is not simply "make the same change", which is resolved automatically by taking the change only once instead of twice. Or, if rerere is enabled, git checks for a "re"corded "re"solution of that conflict that it can "re"use, and will then reuse it rather than stopping.

这篇关于从当前分支合并到另一个分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！