Поки ви працюєте над задачею, main просувається. Чим довше гілка живе окремо, тим більше конфліктів і тим вищий ризик, що код, який працює в гілці, зламається після злиття. Тому гілку періодично оновлюють.
Варіант 1 - злити main у гілку:
git fetch origin
git merge origin/main
- історія гілки не переписується - безпечно, навіть якщо в гілці працюють кілька людей;
- push без force;
- конфлікти розв'язуються один раз;
- в історії з'являються коміти злиття
Merge branch 'main' into feature- при squash-злитті pull request вони зникнуть.
Варіант 2 - rebase на main:
git fetch origin
git rebase origin/main
git push --force-with-lease
- лінійна історія: гілка виглядає так, ніби її почали щойно;
- коміти отримують нові хеші, потрібен force push;
- конфлікти розв'язуються для кожного коміту окремо - на довгій гілці це може повторюватися (допомагає
rerere); - небезпечно, якщо гілкою користуються інші: їхні локальні копії розійдуться з вашою.
Як обрати:
| Ситуація | Що краще |
|---|---|
| особиста гілка, коміти ще не рев'ювали | rebase |
| у гілці працюють кілька людей | merge |
| pull request уже на рев'ю | merge - рецензенти бачать, що змінилося після їхніх коментарів (після rebase GitHub гірше показує різницю) |
злиття в main буде через squash |
будь-який, історія гілки все одно зникне |
Як часто: невеликими кроками - щодня чи перед кожним push, а не раз на тиждень. Конфлікт у двох файлах розв'язати легше, ніж у двадцяти.
Найкращий захист від болісного оновлення - короткоживучі гілки: задача на 1-3 дні дає значно менше розбіжностей, ніж гілка, що живе місяць.
На GitHub кнопка «Update branch» у pull request робить merge (чи rebase, якщо обрати). Branch protection з вимогою «Require branches to be up to date» змушує оновлювати гілку перед злиттям.
