Git: rebase or merge
Two ways to integrate a branch: merge, which keeps the history faithful with a merge commit, and rebase, which replays commits for a linear history; the golden rule, interactive rebase, squash and pull --rebase.
- 25 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
git merge: what is it?
Show the answer
The command that joins two branches keeping their commits as they are; if both have moved on, it creates a commit with two parents.
No existing commit is modified: the history tells what really happened, at the price of a branching graph.
Why does a rebased commit get a new hash?
- Its parent changed: it is a new commit that carries the same changes
- Git renumbers all of the branch's commits on every rebase to keep their order
- Rebase adds a note about the operation to each commit's message
- The hash depends on the date of the last synchronisation with the remote
Show the answer
Its parent changed: it is a new commit that carries the same changes
The hash is computed from the content, the message, the author, the dates and the parent. Replaying a commit on another base changes the parent, hence the hash, even if the diff is identical.
After a rebase, each replayed commit has a new …, because its … has changed.
Show the answer
After a rebase, each replayed commit has a new hash, because its parent has changed.
The hash depends on the parent: same content, same message, but a different parent gives a different commit. This is why rebase is a history rewrite.
Merge commit: what is it?
Show the answer
A commit with two parents, one on each of the joined branches, which marks the point where they come together.
When the destination branch has not moved, Git just advances its pointer (fast-forward) and creates no merge commit, unless you pass --no-ff.
After rebasing a shared branch and running git push --force, a colleague sees their commits appear twice. What is the cause?
- They hold the old commits, the rebase made new ones
- push --force copies each commit a second time on the remote server
- Git keeps both versions of every file edited by two people
- Their local repository is corrupted and must be recloned
Show the answer
They hold the old commits, the rebase made new ones
Their history still holds the old commits; when pulling, Git sees different commits that carry the same changes and joins them. The fix: do not rebase a shared branch, and if it is done, tell the team so everyone rebuilds their work on the new branch.