What happens to the commit history during a merge?
With git merge, the commit history is not rewritten; it stays exactly as it was, with all its branching and commits.
This is the key point almost always expected in an interview.
What "history is preserved" means
Git does not change existing commits:
- it does not change their hashes
- it does not change the order within branches
- it does not delete old commits
It adds new commits when needed.
What the history looks like after a merge
Situation 1: Fast-forward merge
If the main branch has not changed, Git simply "moves the pointer forward":
A---B---C (main)
\
D---E (feature)After the merge:
A---B---C---D---E (main)
The history is linear, no new commits appear.
Situation 2: A regular merge (merge commit)
If both branches evolved in parallel:
A---B---C---F (main)
\
D---E (feature)After the merge, Git creates a merge commit:
A---B---C---F---M (main)
\ /
D---E---Commit M:
- has two parents
- records the fact that the branches were combined
- does not change the old commits
What is important to emphasize in an interview
mergedoes not rewrite history- all commits remain original
- the merge commit shows the development context
- the history can be non-linear, but honest
Why this is considered safe
Because:
- nothing breaks for other developers
- no hash conflicts occur
- you can safely run
git pull
That is why:
git mergecan be used for public branches
Short answer (if you are short on time)
With
git merge, the commit history is preserved: old commits are not changed, and a new merge commit is added if needed to connect the branches.
Short Answer
Interview readyA concise answer to help you respond confidently on this topic during an interview.