Пошук уроків, статей та іншого контенту
Як звести зміни з окремої гілки назад у main — fast-forward проти merge commit.
Коли робота в feature-гілці завершена, її потрібно повернути назад у main — це і робить git merge: переносить усі зміни, зроблені в одній гілці, в іншу, зазвичай поточну.
git switch main
git merge feature/login-form # злити зміни feature/login-form у mainЯкщо main не отримав жодного нового коміту з моменту, коли feature-гілка від нього відгалузилась, Git просто пересуває вказівник main вперед до останнього коміту feature-гілки — жодного окремого коміту злиття не створюється, історія лишається лінійною:
До: main -> A -> B
\
feature -> C -> D
Після fast-forward:
main -> A -> B -> C -> DЯкщо main отримав власні нові коміти після того, як feature-гілка відгалузилась (типова ситуація в командній роботі — хтось інший тим часом теж змержив свою роботу в main), Git не може просто пересунути вказівник — потрібен новий коміт злиття із двома батьками, що об'єднує обидві лінії історії:
До: main -> A -> B -> E
\
feature -> C -> D
Після merge commit:
main -> A -> B -> E -> M (коміт злиття, батьки: E і D)
\ /
C -> D ------Git визначає результат злиття, порівнюючи три точки: спільного предка обох гілок, і останні коміти кожної з них. Якщо зміни торкались різних частин файлів, Git зливає їх автоматично без втручання людини; якщо ті самі рядки змінені по-різному в обох гілках — виникає конфлікт злиття, що вимагає ручного вирішення (детально в наступному уроці).
На практиці більшість команд не викликають git merge вручну на своїй машині для feature-гілок — злиття відбувається через Pull Request на GitHub/GitLab (окремий урок далі в курсі), де та сама операція злиття виконується через веб-інтерфейс, часто після код-рев'ю.
Зливати незавершену, нестабільну feature-гілку в main — main має завжди лишатись у робочому, розгортаному стані для решти команди.
Плутати fast-forward і merge commit як однаково «безпечні» — merge commit явно фіксує момент об'єднання двох ліній історії в лозі, fast-forward цього не робить, що іноді ускладнює пізніший аналіз, коли саме й звідки прийшла конкретна зміна.
Забути перейти на правильну цільову гілку (main) перед git merge — злиття застосовується до поточної гілки, тож помилково виконане на неправильній гілці змішує історію не туди.
git merge переносить зміни однієї гілки в іншу — fast-forward, якщо цільова гілка не змінювалась з моменту відгалуження (просте пересування вказівника), або новий коміт злиття з двома батьками, якщо гілки розійшлись. Three-way merge (спільний предок + дві останні версії) визначає результат автоматично там, де зміни не перетинаються, і сигналізує конфлікт, коли перетинаються.