Как се извършва обединяването (merge) или презаписването на историята (rebase) в системата за контрол на версиите във вашата компания?

В нашия екип следваме работен процес, базиран на Git. За интегриране на промените използваме два основни подхода: merge и rebase, като ги избираме в зависимост от ситуацията и типа на клона.

Merge:

• Обикновено се използва за сливане на дългосрочни клонове, например dev в main, или за интегриране на функционални клонове в dev.
• Създава commit за сливане, който ясно показва кога е настъпило сливането на промени от други клонове.
• Запазва цялата история на commits, включително всички разклонения.

git checkout dev  // Превключване към целевия клон
git merge feature/нова-функция  // Сливане на функционалния клон

Rebase:

• Използва се за поддържане на чиста и линейна история на commits в клоновете с функции до тяхната интеграция (обикновено в dev).
• Прехвърля commits на текущия клон върху върха на целевия (dev), ефективно "пренаписвайки" историята.
• Улеснява историята, като избягва commits за сливане за всяка малка функция или поправка.
• Важно: Никога не правете rebase върху публични клонове, по които работят други разработчици, тъй като това може да създаде конфликти при pull на промените.

git checkout feature/нова-функция  // Превключване към функционалния клон
git rebase dev  // Прехвърля commits на функционалния клон върху върха на dev
// Ако е необходимо, решаваме конфликти
git push --force-with-lease  // Използваме --force-with-lease за безопасен push след rebase

Нашият стандартен работен процес:

1. Новата функция или поправка се разработва в отделен клон (feature/..., fix/...).
2. Периодично (преди pull request или за синхронизиране с dev) функционалният клон се rebase-ва върху актуалната версия на dev. Това помага за решаване на конфликти в ранна фаза.
3. След завършване на разработката и прегледа на кода, функционалният клон се слива в dev с no-ff (non-fast-forward), за да се запази информацията за сливането. Или, по-рядко, се squash-ва в един commit преди сливането в dev за много малки функции или поправки.
4. От dev периодично се правят версии в main (продукционния клон), винаги чрез merge.

По този начин балансираме запазването на историята на commits (merge) с поддържането на чиста развойна клонка (rebase на функционалните клонове).