关于Git的合并和重组 [英] About Git's merge and rebase

问题描述

以上是合并和rebase的结果。 p>

我的问题是，在最终状态下， C5 和 C3'完全相同吗？

或者说， git rebase 等于 git merge + remove C3 ？？？？？？？？提交（合并或重新分配），给你的结果是相似的提交的印象。一般来说，一个rebase会添加多个提交，而一个合并最多会添加一个（快进合并添加none）。

此外，只要<没有冲突解决，或者如果你每次都以相同的方式解决冲突，C3'和C5的最终内容将是相同的，但它们仍然是不同的提交（因为C3 '和C5有不同的父母，他们也会有不同的哈希值，这一点在下面的插图中更为明显）。相应地，每个记录的历史是不同的。注意rebase，历史是线性的，而合并则是

我们的和他们的合并和rebase：为什么我们和他们的的含义颠倒了

The above is the result of merge and rebase.

My question is that in the final state ,are C5 and C3' identical?

Or say,git rebase is equal to git merge + remove C3?

解决方案

The example isn't very good, because it only consider one commit (merged or rebased), giving you the impression that the resulting commits are similar. In general, a rebase will add multiple commits, while a merge will add at most one (fast-forward merges add none).

Moreover, as long as there is no conflict to solve, or if you solve said conflicts the same way each time, the final content of C3' and C5 will be the same but they remain different commits (since C3' and C5 have different parents, they'll also have different hashes, a fact that is more obvious in the illustrations below). Correspondingly, the recorded history for each is different. Note for the rebase, the history is linear, while for the merge it's a lattice.

Consider the same question when merging/rebasing several commits, as illustrated in "A Visual Git Reference" from Mark Lodato. You will see that the end result is quite different.

git checkout master
git merge other # update master with tip of branch 'other' changes

You take only:

• the current commit (ed489 below since you are on master),
• the latest commit of branch other (which is a snapshot representing the full content of the repo when branched in 'other', not a delta)
• their common ancestor (b325c), and performs a three-way merge.

For the meaning of the working directory and stage in this diagram, note the arrows going to the three-way merge, then to the working directory and stage. The working directory represents all the files that you see (on your hard drive), some of which are changed as a result of the three-way merge. The stage holds the files changed by the three-way merge, which is then used to create the new commit (f8bc5).

This is very different from a rebase which strives to reapply each and every commit of a branch on top of the destination branch:

git checkout topic # this time we are on topic
git rebase master  # means: recreate every topic commits on top of master
                           at the end, we are still on (new) 'topic' branch

The above command takes all the commits that exist in 'topic' but not in master (namely 169a6 and 2c33a), replays them onto master, and then moves the branch head to the new tip. Note that the old commits will be [eventually] garbage collected if they are no longer referenced.

Rebasing uses the working directory and the staging area as it replays the commits (apply changes to working directory, add changes to staging area, commit the staged changes, repeat). Once all this is done, the head of the rebased branch is set to the last of the new commits (f7e63).

---

2 additional differences:

• Merge and rebase serve different workflows: See "git merge vs. rebase"
• "ours" and "theirs" are different between a merge and a rebase: "Why is the meaning of "ours" and "theirs" reversed"

这篇关于关于Git的合并和重组的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！