Какви модели на работа с Git сте използвали?

• Git-flow: Използва се за проекти с ясно дефиниран цикъл на издаване. Подходящ за управление на функции, корекции на грешки и подготовка за издаване. Създава клонове feature, develop, release, hotfix, master.

• GitHub flow: Прилагаше се за проекти, където приоритет са честите, малки издания. Прост модел, базиран на един основен клон (main или master) и клонове за всяка функция или корекция, които се сливат веднага след преглед.

• Разработка, базирана на trunk: Практикувана за проекти, изискващи висока честота на интеграция и непрекъснато внедряване. Разработчиците правят промени директно в основния клон (trunk) или в краткотрайни клонове, които бързо се сливат обратно. Ключов елемент — Feature Toggles.

Освен тези основни модели, се използваха:

• Rebase vs Merge: В зависимост от ситуацията и договореностите в екипа, се използваше git rebase за поддържане на чиста история на комитите в локалните клонове преди сливането, и git merge --no-ff за запазване на явна история на сливане в основния клон.

  # Пример rebase
  git checkout feature/нова-функция
  git pull --rebase origin main 
  # Разрешаване на конфликти, ако има
  git push -f origin feature/нова-функция 
  # Или pull request за сливане в main
  

  # Пример merge --no-ff
  git checkout main
  git merge --no-ff feature/нова-функция -m "Сливане на feature/нова-функция в main"
  git push origin main
  

• Squash and Merge: Често при сливане на клонове с функции в основния клон чрез Pull Request. Позволява обединяване на няколко комита от клона с функция в един чист комит в основния клон.

  # Пример за squash merge чрез интерфейса на Git платформа (GitHub, GitLab)
  # Обикновено се извършва при потвърждаване на Pull Request.
  

• Cherry-picking: Използва се за пренасяне на конкретни комити между клонове, например за backporting на корекции от основния клон към релийз или staging клон.

  # Пример cherry-pick
  git checkout release/v1.2
  git cherry-pick <commit_hash>