Модуль 8 · Урок 31 із 58

Branches, merge conflicts і rebase boundary

Branch у Git — легкий movable reference на commit, а не копія каталогу. Конфлікт не означає, що Git зламав код: дві histories змінили однаковий context, і людина має сформулювати правильний combined result та довести його tests.

branchmergeconflictrebase

Безпечна Git-практика модуля 8

Пакет містить тільки synthetic repository files, локальний Python CLI, tests і read-only history verifier. Не додавайте .git, .env, credentials, персональні або production-дані, machine paths чи зовнішні endpoints.

Завантажити практичний пакет →

Branch ізолює intent, не filesystem назавжди

git switch -c feature/case-validation
git branch --show-current
git log --oneline --decorate --graph -n 8

Branch name рухається на кожному новому commit. HEAD зазвичай символічно посилається на current branch. Перемикання може бути заблоковане, якщо uncommitted changes були б overwritten; не обходьте guard destructive cleanup.

Merge інтегрує histories

Fast-forward можливий, коли target branch не має власних нових commits: reference просто рухається вперед. Коли обидві сторони розійшлися, three-way merge використовує common ancestor і створює combined result, часто з merge commit. Strategy detail не замінює review змісту.

git switch main
git merge --no-ff feature/case-validation
python -m unittest discover -s tests -v

Conflict markers — незавершений input

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> feature/case-validation

Не обирайте автоматично «ours» або «theirs». Прочитайте base intent, обидві changes і dependent tests. Напишіть третю, domain-correct version, видаліть markers, запустіть search по markers, tests і лише потім stage resolved paths.

Abort повертає до pre-merge state

git status
git diff --name-only --diff-filter=U
git merge --abort

Якщо ви не розумієте conflict або scope став ширшим, abort кращий за випадковий commit. Pre-existing uncommitted changes ускладнюють відновлення, тому merge починають із clean working tree та verified branch.

Rebase переносить commits і змінює IDs

Rebase replay-ить commits на нову base, створюючи нові commit objects. Це може зробити local feature history лінійною до review, але переписування branch, яку вже використовують інші, створює дублікати й force-push ризик. Узгодьте team policy до rebase.

Boundary: rebase власної unpublished branch — локальне редагування history; rebase shared protected branch — coordination event, не персональна косметика.

Integration evidence виходить за межі conflict-free

  • git diff target...feature показує contribution від common ancestor.
  • Tests запускаються на integrated result, не лише на feature tip.
  • git log --graph підтверджує topology.
  • Review notes пояснюють conflict decision і residual risk.
  • Branch deletion відбувається після merge/retention policy, не до перевірки.

Definition of Done

  • Branch name описує одну feature/fix.
  • Merge починається з clean state і correct target.
  • Conflict resolution формує domain-correct third version.
  • Integrated result проходить tests.
  • Shared history не переписується без coordination і recovery plan.

Методичні джерела

Урок, сценарії, пояснення й вправи створені SEOWORK. Посилання ведуть лише на офіційну документацію Git і GitHub.

Практична перевірка · урок 31 з 47

Закріпіть матеріал уроку

Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.

1. Що найточніше являє собою local branch у внутрішній моделі Git repository?
2. Feature branch і main розійшлися після common ancestor. Який merge model зазвичай потрібен?
3. Після merge залишилися conflict markers, але file синтаксично не запускається. Який правильний порядок?