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?
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.
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 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.
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.
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:
other
', not a delta)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 inmaster
(namely169a6
and2c33a
), replays them ontomaster
, 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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With