Sobes.tech
Pomoc w rozmowie kwalifikacyjnej
Zasoby
Przygotowanie do rozmowy kwalifikacyjnej
Zasoby
Wyszukiwanie pracy
Zasoby
Prawo
Wróć do pytania
Middle

Jak w Twojej firmie przebiega łączenie gałęzi (merge) lub przepisywanie historii (rebase) w systemie kontroli wersji?

sobes.tech AI

Odpowiedź od AI

W naszym zespole stosujemy workflow oparty na Git. Aby integrować zmiany, używamy dwóch głównych podejść: merge i rebase, wybierając je w zależności od sytuacji i typu gałęzi.

Merge:

  • Zazwyczaj stosuje się go do łączenia długotrwałych gałęzi, np. dev z main, lub do integracji gałęzi funkcji z dev.
  • Tworzy commit scalający, który wyraźnie pokazuje, kiedy nastąpiła integracja zmian z innych gałęzi.
  • Zachowuje pełną historię commitów, w tym wszystkie rozgałęzienia.
git checkout dev  // Przełącz na gałąź docelową
git merge feature/nowa-funkcja  // Scal gałąź funkcji

Rebase:

  • Używany do utrzymania czystej i liniowej historii commitów na gałęziach funkcji do momentu ich integracji (zwykle w dev).
  • Przenosi commity bieżącej gałęzi na szczyt gałęzi docelowej (dev), efektywnie "przepisyując" historię.
  • Upraszcza historię, unikając commitów scalających dla każdej małej funkcji lub poprawki.
  • Ważne: Nigdy nie wykonuj rebase na publicznych gałęziach, nad którymi pracują inni programiści, ponieważ może to powodować konflikty przy pobieraniu zmian.
git checkout feature/nowa-funkcja  // Przełącz na gałąź funkcji
git rebase dev  // Przenieś commity gałęzi funkcji na szczyt dev
// Jeśli to konieczne, rozwiązuj konflikty
git push --force-with-lease  // Użyj --force-with-lease dla bezpiecznego push po rebase

Nasz standardowy workflow:

  1. Nowa funkcja lub poprawka jest rozwijana w osobnej gałęzi (feature/..., fix/...).
  2. Od czasu do czasu (przed pull requestem lub w celu synchronizacji z dev) gałąź funkcji jest rebase'owana na aktualną wersję dev. Pomaga to rozwiązać konflikty na wczesnym etapie.
  3. Po zakończeniu rozwoju i przeglądzie kodu, gałąź funkcji jest scalana do dev z no-ff (non-fast-forward), aby zachować informacje o scaleniu. Rzadziej, jest ona squashowana do jednego commita przed scaleniem do dev dla bardzo małych funkcji lub poprawek.
  4. Z dev regularnie tworzone są wydania w main (gałęzi produkcyjnej), zawsze za pomocą merge.

W ten sposób balansujemy zachowanie historii commitów (merge) z utrzymaniem czystej gałęzi rozwojowej (rebase gałęzi funkcji).

PoprzedniaDalej