Git 合并会影响“合并"吗?分支? [英] Do Git merges affect the "merged" branch?
问题描述
我工作的公司一直在尝试具有三个主要分支(开发、测试、主)以及各个功能分支的 Git 工作流程.这涉及将功能分支相互独立地合并为开发"和测试版"，然后定期将测试版"合并到主版"以进行发布.
问题:当我们将一个功能分支合并到 'develop' 时，它似乎会影响该功能分支的提交历史，所以当我们尝试将同一分支合并到 'beta' 时，它也会包括来自发展"，这不是我们想要的.
有人知道这是怎么回事吗?是否可以将一个分支合并到另外两个分支而不包含任何不需要的提交?我们的工作流程有哪些变化可以防止这种情况发生?我知道没有代码示例或任何东西，但这并不是真正的那种类型的问题，我不知道如何提供更多有用的信息.
谢谢！
从一种基本意义上讲，合并操作并不会真正影响任何分支.(它当然会进行新的提交，这会以通常的方式影响该分支.)Git 的诀窍是将以下五个同时出现的想法保留在您的脑海中:
在 Git 中重要的是提交及其父链接.分支名称大多只是分散注意力(但请参见第 2 点和第 3 点).
分支名称只是特定提交的名称，我们称之为该分支的提示提交.
在进行新提交时，Git 将当前提交作为其父提交写入新提交.1 如果新提交有多个父提交(见下一点)，则当前提交变为它的第一个父级.在任何情况下，Git 都会更新分支名称以指向新的提交.这就是分支生长"的方式.
合并提交是具有两个(或多个)父提交的提交.这实际上是作为名词合并".
进行合并的行为——我的意思是合并提交——包括执行三向合并操作，然后进行新的提交像往常一样，除了新提交有两个(或更多)父母.额外的"父项是合并的提交.2
合并操作——作为动词合并"——使用通过上述五点建立的历史记录.Git 发现三个提交:
- 当前提交，又名
HEAD.(这很容易.) - 要合并的提交:
git rev-parse为传递给git merge的参数提供的任何 ID.分支名称只是找到分支提示提交. - 合并基础.这就是提交历史的来源，这也是您需要绘制图形片段的原因.
任何两个提交的合并基础被松散地定义为图重新组合在一起的(第一个)点":
...--o--*--o--o--o <-- branch1o--o--o--o <-- 分支2名称 branch1 指向顶行的提示(最右侧)提交.名称 branch2 指向底行的提示提交.这两个提交的合并基础是标记为*的那个.3
为了执行合并操作，Git 然后将合并基础提交 * 与两个提示进行比较(如在 git diff 中一样)，给出两个差异.然后 Git 合并差异，每次更改只取一份副本:如果您(在 branch1 上)和他们(在 branch2 上)更改了单词 color 到 color 在 README 中，Git 只需更改一次.
结果 source 存储在工作树中，成为合并提交的树.请注意，到目前为止，我们是将 branch2 合并到 branch1 中，还是将 branch1 合并到 branch2 中都没有关系>:我们将获得相同的合并基础，并具有相同的两个提示提交，因此获得相同的两个差异并以相同的方式组合这两个差异以到达相同的工作树.但是现在我们使用它的两个父节点进行实际的合并提交，并且现在我们在哪个分支上很重要.如果我们在 branch1 上，我们在 on branch1 上进行新的提交，并将名称推进 branch1:
...--o--o--o--o--o---M <-- branch1/o--o--o--o <-- 分支2新的合并提交有两个父项:一个是branch1的旧提示，另一个是branch2的提示.
因为我们现在有了一个新图，以后的 git merge 会找到一个新的 merge base.假设我们在两个分支上都进行了多次提交:
...--o--o--o--o--o---M--o--o <-- branch1/o--o--o--*---o--o--o <-- branch2如果我们现在要求合并两个分支，Git 首先会找到基数.这是两个 分支上的提交，最接近两个提示.我再次将这个提交标识为 *，并查看它的位置:它曾经是 branch2 的提示，回到我们进行合并时.
请注意，无论我们采用哪种方式进行合并，情况仍然如此.
然而，我们进行实际的合并提交至关重要.如果我们使用git merge --squash，它不会进行合并提交，我们将不会得到这种图.同样重要的是，合并后两个分支都不会重新定位"，因为 git rebase 通过 copying 提交工作，而 git merge 基于提交身份并遵循父指针.任何副本都是不同的提交，因此任何旧的提交都不会指向新的复制提交.(在这些图中，可以在合并点之后重新调整提交 - 向右，在这些图中；不能复制左侧的提交.)
如果您不禁止 git merge 进行快进"操作，git merge 也可以跳过进行合并提交，而只是 移动分支标签.在这种情况下，两个分支标签——你刚刚移动的一个和你要求合并的一个——最终指向同一个提交.一旦发生这种情况，除非将标签移回，否则无法解开"这两个分支.要防止 git merge 执行此快进而不是实际合并，请使用 --no-ff.
这是一个快进合并"的例子(用引号引起来，因为没有实际的合并).像往常一样，我们从不同的分支开始——但是在 current 分支上没有提交，branch1 还没有 也在other 分支，branch2:
...--o--* <-- branch1o--o--o <-- 分支 2如果在 branch1 上运行 git merge branch2——注意缺少 --no-ff——Git 注意到不需要实际合并.相反，它执行标签快进"操作，将名称 branch1 向前滑动，直到遇到 branch2 上的提示提交:
...--o--oo--o--o <-- 分支 1，分支 2此图无处记录两个分支之间的任何分离"，因此我们不妨理顺一下扭结:
...--o--o--o--o--o <-- branch1, branch2直到我们在 branch2 上进行新的提交:
...--o--o--o--o--* <-- branch1o <-- 分支 2这没有什么错误，但请注意，现在无法判断我们上移"到第一行的三个提交是否已合并.
<小时>1这适用于常规 git commit 和 git merge，但不适用于 git commit --amend.提交的修改"变体像往常一样进行新提交，但不是将 current 提交设置为新提交的父级，而是设置当前提交的 父级(如他们中的许多人，甚至可能根本没有父母)作为新提交的父母.其效果是将当前提交推到一边，使其看起来提交已更改，而实际上旧提交仍在存储库中.
2多于两个父母的情况被称为章鱼合并"，我们在这里可以忽略它.(它对重复的成对合并无能为力.)
3在复杂的图形中，这样的第一点"可能不止一个.在这种情况下，所有最低共同祖先节点都是合并基础，对于 Git，-s strategy 合并策略参数决定如何处理这个案子.(当然，还有 -s ours 策略，它忽略所有其他提交，并且完全绕过三路合并代码.但我在这里假设正常合并.)>
The company I work for has been trying out a Git workflow with three main branches (develop, beta, master) plus individual feature branches. This involves merging feature branches into 'develop' and 'beta' independently of one another, and then periodically merging 'beta' into 'master' for releases.
The problem: when we merge a feature branch to 'develop', it seems to affect the commit history for the feature branch, so when we try to merge that same branch into 'beta' it will also include all the commits from 'develop', which is not what we want.
Does anyone know what's going on here? Is it possible to merge a branch into two other branches without including any unwanted commits? What changes to our workflow could prevent this? I know there's no code sample or anything, but it's not really that type of question and I'm not sure how else to give more useful information.
Thank you!
The merge operation doesn't really affect any branch, in one fundamental sense. (It does of course make a new commit, which affects that branch in the usual way.) The trick with Git is to keep the following five simultaneous ideas in your head:
What matters in Git are commits, and their parent links. Branch names are mostly just distractions (but see points 2 and 3).
A branch name is just the name for a particular commit, which we call the tip commit of that branch.
When making a new commit, Git writes the new commit with the current commit as its parent.1 If the new commit has multiple parents (see next point), the current commit becomes its first parent. In any case Git then updates the branch-name to point to the new commit. This is how branches "grow".
A merge commit is a commit with two (or more) parent commits. This is "merge as a noun", as it were.
The act of making a merge—by which I mean a merge commit—involves doing the three-way-merge action, then making a new commit as usual, except that the new commit has two (or more) parents. The "extra" parents are the merged-in commit(s).2
The merge action—"merge as a verb"—uses the history built up through the five points above. Git finds three commits:
- The current commit, aka
HEAD. (This is easy.) - The commit(s) to be merged: whatever ID(s)
git rev-parsecomes up with for the argument(s) you pass togit merge. A branch name just finds the branch-tip commit. - The merge base. This is where the commit history comes in, and this is why you need to draw graph fragments.
The merge base of any two commits is loosely defined as "the (first) point where the graph comes back together":
...--o--*--o--o--o <-- branch1
o--o--o--o <-- branch2
The name branch1 points to the tip (rightmost) commit on the top line. The name branch2 points to the tip commit on the bottom line. The merge base of these two commits is the one marked *.3
To perform the merge action, Git then diffs (as in git diff) the merge base commit * against the two tips, giving two diffs. Git then combines the diffs, taking just one copy of each change: if both you (on branch1) and they (on branch2) changed the word color to colour in README, Git just takes the change once.
The resulting source, as stored in the work-tree, becomes the tree for the merge commit. Note that up until this point, it does not matter whether we are merging branch2 into branch1, or branch1 into branch2: we will get the same merge base, and have the same two tip commits, and hence get the same two diffs and combine those two diffs in the same way to arrive at the same work-tree. But now we make the actual merge commit, with its two parents, and now it matters which branch we're on. If we are on branch1, we make the new commit on branch1, and advance the name branch1:
...--o--o--o--o--o---M <-- branch1
/
o--o--o--o <-- branch2
The new merge commit has two parents: one is the old tip of branch1 and the other is the tip of branch2.
Because we now have a new graph, a later git merge will find a new merge base. Let's say that we make several more commits on both branches:
...--o--o--o--o--o---M--o--o <-- branch1
/
o--o--o--*---o--o--o <-- branch2
If we now ask to merge the two branches, Git first finds the base. That's a commit that's on both branches, nearest to the two tips. I've identified this commit as * again, and look where it is: it's the commit that used to be the tip of branch2, back when we did the merge.
Note that this is still the case regardless of which way we do the merge.
It is, however, critical that we make an actual merge commit. If we use git merge --squash, which does not make a merge commit, we will not get this kind of graph. It's also important that neither branch gets "rebased" after merging, since git rebase works by copying commits, and git merge works on the basis of commit identities and following parent pointers. Any copies are different commits, so any old commits will not point into the new copied commits. (It's OK to rebase commits after the merge point—to the right, in these drawings; what's not OK is copying commits that are to the left.)
If you do not prohibit git merge from doing a "fast forward" operation, it's also possible for git merge to skip making a merge commit, and instead just move the branch label. In this case the two branch labels—the one you just moved, and the one you asked to merge—wind up pointing to the same commit. Once this happens, there's no way to "untangle" the two branches except by moving the label back. To prevent git merge from doing this fast-forward instead of actually merging, use --no-ff.
Here is an example of a fast-forward "merge" (in quotes because there is no actual merge). We start, as usual, with diverged branches—but there are no commits on the current branch, branch1, that are not already also on the other branch, branch2:
...--o--* <-- branch1
o--o--o <-- branch2
If, while sitting on branch1, we run git merge branch2—note the lack of --no-ff—Git notices that no actual merging is required. Instead, it does a label "fast forward" operation, sliding the name branch1 forward until it meets the tip commit on branch2:
...--o--o
o--o--o <-- branch1, branch2
This graph has nowhere to record any "separateness" between the two branches, so we might as well straighten out the kink:
...--o--o--o--o--o <-- branch1, branch2
until we make new commits on branch2:
...--o--o--o--o--* <-- branch1
o <-- branch2
There's nothing wrong with this, but note how it is now impossible to tell that the three commits we "moved up" to the first row were merged.
1This is true for regular git commit and for git merge, but not for git commit --amend. The "amend" variant of a commit makes a new commit as usual, but instead of setting the current commit as the new commit's parent, it sets the current commit's parents (as many of them as there are, which may even be no parents at all) as the new commit's parents. The effect is to shove the current commit aside, making it seem as though the commit has changed, when in fact the old commit is still in the repository.
2The more-than-two-parents case is called an "octopus merge" and we can ignore it here. (It does nothing you cannot do with repeated pairwise merges.)
3In complex graphs there may be more than one such "first point". In this case, all lowest-common-ancestor nodes are merge bases, and for Git, the -s strategy merge strategy argument decides how to handle this case. (Of course, there is also the -s ours strategy, which ignores all the other commits, and simply bypasses the three-way merge code entirely. But I'm assuming normal merge here.)
这篇关于Git 合并会影响“合并"吗?分支?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
