Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

About Git's merge and rebase

Tags:

git

enter image description here

enter image description here

enter image description here

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?

like image 983
asker Avatar asked Aug 15 '11 06:08

asker


People also ask

When to use rebase and merge?

All the commits on a feature branch are combined into a single commit on the master branch. All commits are rebased, and the same number of commits are added to the master branch. Merge is best used when the target branch is supposed to be shared. Rebase is best used when the target branch is private.

What is rebase and merge in pull request?

When you select the Rebase and merge option on a pull request on GitHub.com, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. In that way, the rebase and merge behavior resembles a fast-forward merge by maintaining a linear project history.

What is git rebase used for?

What Does Git Rebase Do? A Git rebase changes the base of the developer's branch from one commit to another, so it looks like they have created their branch from a different commit. Internally, Git creates a new commit and applies it to the specified base.

What is the difference between fast forward merge and rebase?

There are a few differences between the two workflows: The rebase workflow keeps the git graph linear, while the merge workflow keeps track of the branch commits.


2 Answers

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

git merge other

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

git rebase master

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"
like image 93
VonC Avatar answered Oct 18 '22 10:10

VonC


No. C5 and C3' will have different parent commits, meaning they will themselves be different.

If you are asking whether the root treeish referenced by C5 and C3' will be identical, then yes (assuming that any conflicts were resolved the same way). In other words, the tree of files "contained in" both commits will be the same.

like image 44
cdhowie Avatar answered Oct 18 '22 08:10

cdhowie