Branching, merging and resolving a conflict
Git compares branch tips with a merge base and can combine many text changes automatically. Conflicts need a person to decide the required behavior. Rebase replays commits on a new base, changing their identities and ancestry. Rewriting commits that teammates use needs coordination.
What a learner can do afterwards
- Merge two branches and identify the common ancestor the merge used
- Resolve a conflict by checking what the combined code must do instead of choosing a side without checking
- Say when a rebase is a better choice than a merge, and when it is a worse one
1 · Read
You have followed commit parents and branch labels. In a simple branch history, Git compares both tips with their most recent shared ancestor, the merge base. Separate edits or identical changes can often merge automatically. Incompatible edits to overlapping text may cause a conflict. A clean text merge can still break behavior, so check the result.
At a shared commit, git switch -c feature creates a branch label and switches to it. After main and feature gain separate commits, git switch main followed by git merge feature starts combining their work. A completed ordinary merge of divergent branches adds a commit with both tips as parents. If main is an ancestor of feature, a fast-forward can move main to feature's tip without adding a commit.
If a merge pauses for a conflict, inspect the base and both edits. Edit the file to give the required behavior and remove conflict markers. Run relevant tests. Stage each resolved file with git add, then finish this merge with git commit. Editing alone does not tell Git that the file is resolved.
Main renames a setting while feature adds checks for its value. Both changes are required. Keep the new name and make the new checks use it. Test valid and invalid values. Either complete side alone may omit required behavior, so inspect both before choosing the final code.
An ordinary rebase replays selected commits on a new base. Suppose feature's C has parent A, while main's B also has parent A. Replaying C onto B creates C' with parent B and a new commit ID. The feature label moves to C'. Author dates normally remain; committer dates normally change. This new chain does not erase every reference to the old commits. Rebase options can preserve merge structure.
Read left to right: B has parent A, and C' has parent B. This shows only the new chain.
Rebasing private work onto an updated base can make review easier. Merging shared work keeps the existing commits and their ancestry. Rewriting commits that teammates use can make their histories diverge. Prefer merging when you need to preserve shared history. If shared history must be rewritten, agree on how everyone will update their work first.
Compare with the merge base, resolve the conflict to give the required behavior and test. Rebase creates new commits; coordinate before rewriting work that teammates use.
Original teaching, questions and flashcards about Git merging, conflict resolution and rebasing, written for this dataset.
2 · Watch
En anglaisTake 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.