Version control and teamwork
Introduced
Vocabulary
| English | Meaning |
|---|---|
| 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. |
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}
Practice
In the course model, main is —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Short-lived branches merge back through reviewed pull requests.
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}
Practice
Bisect over 12 runnable commits needs at most —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
log2(12) rounded up: 4 checkouts narrows the regression.
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}
Practice
A conflict resolution belongs —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
The resolution is a decision: record it where the code lives.