Jakie wzorce pracy z Git używałeś?

• Git-flow: Używany dla projektów z jasno określonym cyklem wydań. Przydatny do zarządzania funkcjami, poprawkami błędów i przygotowaniem wydań. Tworzy gałęzie feature, develop, release, hotfix, master.

• GitHub flow: Stosowany w projektach, gdzie priorytetem są częste, małe wydania. Prosty model oparty na głównej gałęzi (main lub master) i gałęziach dla każdej funkcji lub poprawki, które są od razu scalane z główną gałęzią po przeglądzie.

• Rozwój oparty na trunk: Praktykowany w projektach wymagających wysokiej częstotliwości integracji i ciągłego wdrażania. Programiści wprowadzają zmiany bezpośrednio do głównej gałęzi (trunk) lub krótkotrwałych gałęzi, które szybko są scalane z powrotem. Kluczowy element — Feature Toggles.

Oprócz tych głównych wzorców, używano:

• Rebase vs Merge: W zależności od sytuacji i ustaleń zespołu, używano git rebase do utrzymania czystej historii commitów na lokalnych gałęziach przed scaleniem, oraz git merge --no-ff do zachowania jawnej historii scalania na głównej gałęzi.

  # Przykład rebase
  git checkout feature/nowa-funkcja
  git pull --rebase origin main 
  # Rozwiązywanie konfliktów, jeśli występują
  git push -f origin feature/nowa-funkcja 
  # Lub pull request do scalenia z main
  

  # Przykład merge --no-ff
  git checkout main
  git merge --no-ff feature/nowa-funkcja -m "Scalanie feature/nowa-funkcja do main"
  git push origin main
  

• Squash and Merge: Często stosowany przy łączeniu gałęzi funkcji z główną gałęzią przez Pull Request. Pozwala na połączenie kilku commitów z gałęzi funkcji w jeden czysty commit na głównej gałęzi.

  # Przykład squash merge przez interfejs platformy Git (GitHub, GitLab)
  # Zazwyczaj wykonywany przy zatwierdzaniu Pull Request.
  

• Cherry-picking: Używany do przenoszenia konkretnych commitów między gałęziami, np. do backportowania poprawek z głównej gałęzi do wersji lub gałęzi staging.

  # Przykład cherry-pick
  git checkout release/v1.2
  git cherry-pick <commit_hash>