Version control and teamwork
Introduit
Vocabulaire
| English | Sens |
|---|---|
| branching model | A version-control workflow defining how branches are created, used and integrated. |
| merge conflicts | Overlapping edits that version control cannot combine automatically and requires a person to resolve. |
English
Main stays releasable
- The course repo's branching model:
mainalways releasable, short-lived feature branches, pull requests with review. Merge conflicts are the machine reporting two decisions collided.
{exercise:uni-cs1204-branching}
Pratique
In the course model, main is —
Difficulté 1/5 · 100 pièces + un petit bonus lors de la première réussite aujourd'hui
Short-lived branches merge back through reviewed pull requests.
English
Commit granularity
- One commit = one defensible change, linked to its requirement, tests green at every commit. Bisect needs this: a runnable history narrows a regression to one change in $\log_2 n$ checkouts — 12 commits means at most 4.
- Commit dumps ("week of work") kill bisect; merge commits with no message lose the decision.
{exercise:uni-cs1204-commits}
Pratique
Bisect over 12 runnable commits needs at most —
Difficulté 1/5 · 100 pièces + un petit bonus lors de la première réussite aujourd'hui
log2(12) rounded up: 4 checkouts narrows the regression.
English
The conflict and the review
- Two branches edit
LOAN_LIMIT(raise to 6 vs extract to config): the resolution is a decision, recorded in the merge commit's message. Conflicts resolved silently are decisions lost. - The review contract: diff + tests + requirement link, under ~200 changed lines; review against the acceptance test, not taste.
{exercise:uni-cs1204-review}
Pratique
A conflict resolution belongs —
Difficulté 1/5 · 100 pièces + un petit bonus lors de la première réussite aujourd'hui
The resolution is a decision: record it where the code lives.