Version control and teamwork
도입됨
어휘
| English | 의미 |
|---|---|
| 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}
연습
In the course model, main is —
난이도 1/5 · 100코인 + 오늘 첫 완료 시 작은 보너스 추가
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}
연습
Bisect over 12 runnable commits needs at most —
난이도 1/5 · 100코인 + 오늘 첫 완료 시 작은 보너스 추가
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}
연습
A conflict resolution belongs —
난이도 1/5 · 100코인 + 오늘 첫 완료 시 작은 보너스 추가
The resolution is a decision: record it where the code lives.