Branching, Merging and Resolving a Conflict
Two branches that changed different lines merge on their own; two that changed the same lines cannot, and a person has to decide. A rebase rewrites the history into a straight line instead, which reads better and throws away what actually happened.
What a learner can do afterwards
- Merge two branches and identify the common ancestor the merge used
- Resolve a conflict by choosing what the combined code should mean, not by picking a side
- Say when a rebase is a better choice than a merge, and when it is a worse one
1 · Read
A merge joins two branches at their shared base, the ancestor both grew from. Lines touched on one side only slide in on their own. Lines touched on both sides in different ways stop the tool: it cannot know which meaning you want.
You renamed a setting on main while a teammate rewrote its checks on feature. Keep both intents: the new name with the new checks, then run the tests. Deleting one side blindly throws real work away.
A rebase instead replays your commits onto the tip of the other branch, drawing one straight line. It reads cleanly, but it rewrites history: dates and parents change and the true branching is gone.
Rebase a private branch before sharing to keep review simple. Merge a shared branch so the true history stays. Never rebase commits others already built on.
Merge from the shared base, resolve by meaning, and rebase only what nobody else uses.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.