Git 2.5x: zmiany w merge, rebase i bezpieczeństwie, które warto wdrożyć w zespole

Dlaczego Git 2.5x jest ważny dla pracy zespołowej

Git 2.5x jako próg zmian w codziennym użyciu

Linia Git 2.5x to nie pojedyncza funkcja, ale cała seria dopracowań, które szczególnie mocno uderzają w trzy obszary: merge, rebase i bezpieczeństwo. Dla pojedynczego developera część z nich może wydawać się kosmetyczna. Dla zespołu – zwłaszcza rozproszonego, z wieloma aktywnymi branchami – to często granica między chaotycznym a przewidywalnym workflow.

W starszych wersjach Git część operacji była mniej intuicyjna, a niektóre sytuacje prowadziły do zaskakujących konfliktów lub trudnych do odtworzenia błędów. Git 2.5x doprecyzowuje zachowanie merge’ów, poprawia rebase (szczególnie interaktywny) oraz zaostrza domyślne podejście do bezpieczeństwa – dzięki temu łatwiej wprowadzić sensowne standardy w całej organizacji.

Gęstszy ruch na repozytorium, większe ryzyko kolizji

W pojedynczym projekcie open source często pracuje naraz kilkanaście lub kilkadziesiąt osób. W firmach zdarza się więcej – do tego dochodzą boty CI, automatyczne mergowanie, release branche, cherry-picki i hotfixy. Każde takie miejsce zetknięcia się gałęzi zwiększa ryzyko:

• niespodziewanych konfliktów merge,
• post factum odkrytych regresji wynikających z „cichego” nadpisania zmian,
• zaburzonej historii, w której trudno prześledzić, kto i kiedy coś wprowadził,
• pomyłek przy rebase, kończących się utratą commitów z lokalnych branchy.

Git 2.5x nie rozwiązuje wszystkich problemów za nas, ale daje narzędzia, które czynią te sytuacje bardziej kontrolowalnymi. Lepsza detekcja wspólnego przodka, poprawiona obsługa rename’ów czy dopracowany interaktywny rebase przekładają się bezpośrednio na mniejszą liczbę konfliktów i bardziej czytelną historię.

Typowe obawy przed zaawansowanym użyciem Git

W wielu zespołach, także bardzo senioralnych, wciąż wraca ten sam zestaw lęków:

• „Zepsuję historię” – obawa przed rebase, force-pushem, rewordowaniem commitów.
• „Stracimy commity” – brak zaufania do refloga, brak świadomości, że większość „znikniętych” commitów można odratować.
• „Narobię szkód na mainie” – szczególnie przy pracy bez odpowiednich zabezpieczeń na serwerze (protected branches, policyje pushowania).

Git 2.5x nie usuwa tych obaw, ale umożliwia zbudowanie takich praktyk, w których ryzyko drastycznie spada. To m.in. bardziej przewidywalny merge, bezpieczniejsze opcje rebase i większe wsparcie dla podpisywania commitów, co poprawia audytowalność zmian i pozwala wdrożyć sensowną politykę bezpieczeństwa w repozytoriach.

Co zyskuje zespół po wdrożeniu zmian z linii 2.5x

Dobrze przeprowadzona aktualizacja Git połączona ze zmianą praktyk w repozytorium przynosi kilka bardzo namacalnych korzyści:

• Mniej konfliktów przy merge’ach – lepsza detekcja wspólnego przodka i rename’ów oznacza mniej ręcznej roboty po stronie developera.
• Bardziej przewidywalny workflow z rebase – dzięki dopracowaniu interaktywnych trybów i obsługi konfliktów łatwiej porządkuje się historię przed mergem.
• Wyższy poziom bezpieczeństwa – podpisywanie commitów, bardziej rygorystyczne domyślne ustawienia, lepsze integracje z CI/CD.
• Lepsza audytowalność – czytelna historia, mniej „śmieciowych” merge commitów, większa wiarygodność tego, kto co zrobił.

Efekt uboczny, często niedoceniany: rośnie zaufanie do procesu. Jeśli merge i rebase zachowują się przewidywalnie, a repozytorium jest odpowiednio zabezpieczone, ludzie mniej „kombinują” na boku i chętniej trzymają się uzgodnionego workflow.

Przegląd najważniejszych zmian w linii Git 2.5x

Nowości w Git 2.5 dotyczące merge

Najodczuwalniejsze dla zespołów zmiany w obszarze merge koncentrują się wokół jakości wykrywania wspólnego przodka i obsługi zmian w strukturze projektu. Git 2.5x lepiej radzi sobie z:

• skomplikowanymi drzewami branchy, w których merge base nie jest oczywisty,
• plikiem przeniesionym i jednocześnie zmienionym w kilku miejscach,
• dużymi refaktorami katalogów i nazw plików,
• konfliktami wynikającymi z długotrwałych, równoległych prac nad tym samym obszarem.

Zmienia to dynamikę konfliktów: jest ich mniej, a gdy się pojawiają, zwykle lepiej odzwierciedlają faktyczną kolizję intencji, a nie niedoskonałości algorytmów merge.

Usprawnienia rebase i interaktywnej edycji historii

Rebase w Git 2.5x zyskuje kilka usprawnień, które szczególnie przydają się przy porządkowaniu historii przed mergem do głównej gałęzi:

• interaktywny rebase (rebase -i) staje się wygodniejszy i bardziej odporny na błędy – lepsze komunikaty, dopracowany mechanizm edycji commitów,
• ulepszone zachowanie przy konfliktach, w tym możliwość czytelnego przerwania rebase i powrotu do poprzedniego stanu,
• lepsze wsparcie dla zachowywania merge commitów w określonych sytuacjach.

W efekcie rebase przestaje być „czarną magią”, a zaczyna pełnić rolę precyzyjnego narzędzia do higieny historii. Dla tech leadów i reviewerów oznacza to mniej czasu spędzanego na czytaniu przypadkowych commitów i łatwiejsze zrozumienie co, kiedy i dlaczego zostało wprowadzone.

Bezpieczeństwo i podpisywanie commitów w Git 2.5x

Git 2.5x pogłębia wsparcie dla bezpiecznych workflow, szczególnie w zakresie:

• podpisywania commitów GPG – łatwiejsza konfiguracja, lepsza współpraca z serwerami i platformami hostingu kodu,
• ostrzejszych domyślnych ustawień – wyraźniejsze komunikaty i bezpieczniejsze zachowanie przy potencjalnie niebezpiecznych operacjach,
• ochrony przed złośliwymi hookami i konfiguracjami – lepsze separowanie ustawień lokalnych i zdalnych, ograniczanie powierzchni ataku.

To fundament, na którym można budować dojrzałą politykę bezpieczeństwa repozytorium: wymuszanie podpisanych commitów, ograniczanie uprawnień do pushowania na krytyczne gałęzie, powiązanie commitów z procesem CI/CD.

Nowe przełączniki i ergonomia codziennej pracy

Obok dużych zmian pojawiają się też drobniejsze usprawnienia:

• nowe lub dopracowane flagi dla git merge i git rebase,
• bardziej informacyjne komunikaty błędów i ostrzeżeń,
• lepsza wydajność dla większych repozytoriów (np. przy liczeniu merge base, logach).

Z perspektywy zespołu liczy się nie tylko to, że Git może coś zrobić, ale że robi to w sposób zrozumiały. Jasny komunikat, czemu rebase został przerwany, często oszczędza kilkanaście minut śledztwa na Slacku czy w Jirze.

Kiedy aktualizacja do Git 2.5x realnie ma sens

Nie każdy zespół od razu odczuje pełen pakiet zmian. Aktualizacja ścina najwięcej problemów w sytuacjach, gdy:

• jest rozbudowany model branchowania (feature, release, hotfix),
• występują częste refaktory struktury katalogów, modularizacja monolitu,
• rebase jest (lub ma być) elementem codziennej pracy, a nie tylko „awaryjną” operacją,
• repozytorium jest częścią krytycznego procesu biznesowego, więc audytowalność i bezpieczeństwo są na pierwszym planie.

Jeśli zespół pracuje od lat na starszej wersji Git i ciągle przewijają się te same skargi: „ciągle te konflikty”, „boję się rebase”, „nie wiadomo, kto co naprawdę zmergował”, przejście na 2.5x to dobry punkt wyjścia do zmiany nawyków.

Aktualizacja Git do 2.5x w organizacji – od pojedynczego deva po CI

Jak sprawdzić wersję Git na lokalnych maszynach i serwerach CI

Punktem startu jest inwentaryzacja. Żeby uniknąć chaosu, trzeba wiedzieć, kto i gdzie ma jaką wersję Git. Podstawowe polecenie jest oczywiste, ale kluczowe, żeby każdy je wykonał:

git --version

Warto zebrać informacje:

• od wszystkich developerów (lokalne środowiska),
• ze wszystkich agentów CI (np. workerów w Jenkinsie, runnerów w GitLab CI, maszyn w GitHub Actions),
• z serwerów integrujących (np. serwery buildujące paczki, jeśli wykonują operacje na Git),
• z maszyn, na których stoją mirrorowane repozytoria (jeśli takie istnieją).

Różnice wersji są normą, ale jeśli w jednym projekcie pojawia się mieszanka typu 1.8, 2.1, 2.3 i 2.5x, dobrze to uporządkować, zanim zacznie się narzucać nowy workflow pracy z merge i rebase.

Różnice między systemami: Linux, macOS, Windows

W zależności od systemu aktualizacja Git będzie wyglądała inaczej:

• Linux – najczęściej przez menedżer pakietów (apt, yum, dnf, pacman). Warto sprawdzić, czy domyślne repozytoria nie oferują jedynie starszych wersji; w razie potrzeby skorzystać z PPA lub repozytoriów dostawcy.
• macOS – zwykle przez Homebrew (brew install git lub brew upgrade git). Trzeba uważać, żeby nie używać jednocześnie wersji systemowej i tej z Homebrew.
• Windows – Git for Windows (oficjalne instalatory), ewentualnie instalacja przez narzędzia typu Chocolatey lub winget; w środowiskach korporacyjnych czasem przez SCCM lub inne systemy dystrybucji oprogramowania.

W CI/CD często stosuje się obrazy Dockerowe z preinstalowanym Git. Tam aktualizacja oznacza przebudowanie obrazów bazowych i dopilnowanie, by wszystkie joby korzystały z aktualnej wersji.

Ryzyka mieszanki wersji w tym samym zespole

Posiadanie różnych wersji Git w jednym zespole nie jest automatycznie katastrofą, ale wprowadza kilka subtelnych ryzyk:

• odmienna logika merge w starszych wersjach może generować inne konflikty niż w 2.5x,
• część flag czy opcji rebase może nie być dostępna dla developera na starszej wersji,
• różne komunikaty błędów utrudniają wspólne debugowanie; ktoś widzi „inny Git” niż reszta.

Jeśli nowy workflow opiera się np. na interaktywnym rebase według możliwości Git 2.5x, osoby na starszej wersji będą albo go unikały, albo traciły czas na obejścia. To często rodzi niepotrzebne frustracje i powoduje, że nowa praktyka „nie przyjmuje się” w całym zespole.

Bezpieczny plan aktualizacji Git w organizacji

Aby aktualizacja była spokojna i przewidywalna, zamiast robić ją „po cichu”, lepiej oprzeć się na prostym planie:

1. Test na środowisku CI – zaktualizować Git na jednym z runnerów / workerów, uruchomić pełny pipeline, sprawdzić, czy skrypty nie korzystają z przestarzałych flag lub nieoptymalnych obejść.
2. Pilotaż na części zespołu – kilku developerów (np. z różnych projektów) aktualizuje Git i przez tydzień monitoruje, czy pojawiają się problemy w codziennej pracy.
3. Aktualizacja całego CI/CD – po pozytywnym pilotażu, ujednolicenie wersji Git na wszystkich maszynach CI/CD.
4. Aktualizacja reszty zespołu – najlepiej zsynchronizowana w krótkim czasie (np. w jednym tygodniu), z prostą instrukcją krok po kroku dla każdego systemu.

W trakcie dobrze mieć osobę lub małą grupę, która „opiekuje się” tą zmianą: zbiera zgłoszenia problemów, aktualizuje wiki, proponuje obejścia albo modyfikację skryptów.

Jak komunikować zmianę: changelog „po ludzku”

Surowy changelog Git jest potrzebny, ale dla większości developerów niewiele mówi. Znacznie lepiej działa prosty dokument w języku zespołu, np. w Confluence albo repozytorium dokumentacji, w którym pojawia się:

• co się zmienia w merge – przykłady „było / jest”,
• co się zmienia w rebase – na czym polega bezpieczniejszy interaktywny rebase,
• co się zmienia w bezpieczeństwie – np. rekomendacja włączenia podpisywania commitów, proponowana polityka głównych branchy,
• krótka checklista: pierwsze 3–4 kroki, które każdy powinien zrobić po aktualizacji.

Minimalne wymagania konfiguracyjne po aktualizacji

Po przejściu na Git 2.5x same binarki to dopiero połowa sukcesu. Druga połowa to kilka ustawień, które wyrównują doświadczenie w całym zespole. Bez tego część osób zacznie korzystać z nowych funkcji „przypadkiem”, inni w ogóle ich nie zobaczą, a różnice w konfiguracji utrudnią diagnozowanie problemów.

Przygotowując wspólny plik .gitconfig (globalny lub projektowy), dobrze spiąć w nim kilka elementów:

• domyślne strategie merge i sensowne aliasy,
• ustawienia rebase (np. pull.rebase, rebase.autoStash),
• parametry bezpieczeństwa (GPG, restrykcje konfiguracji pobieranej z zewnątrz),
• spójne ustawienia kolorów i formatów logów, żeby debugowanie „po ekranie” było wspólnym językiem.

Na początek sprawdza się zestaw typu „bezpieczny standard”, który można wkleić do dokumentacji zespołu jako rekomendację „kopiuj–wklej”, a potem – świadomie modyfikować pod potrzeby konkretnych projektów.

Zmiany w merge: jak poprawiła się obsługa konfliktów i historii

Nowa filozofia merge: mniej magii, więcej przejrzystości

W Git 2.5x merge przestaje być czarną skrzynką, która „coś zmergowała, ale nie wiadomo jak”. Kluczowe jest to, że:

• algorytm rozwiązywania konfliktów lepiej radzi sobie ze złożonymi refaktorami (zmiany nazw plików, przenoszenie katalogów),
• lepiej dobierany jest merge base, czyli wspólny przodek dla gałęzi – dzięki temu konflikty są bliżej faktycznych zmian, a nie dawno naprawionych różnic,
• pojawiły się wygodniejsze opcje wpływania na strategię merge bez kombinowania ze skomplikowanymi flagami.

Efekt dla dewelopera jest od razu odczuwalny: mniej „losowych” konfliktów, mniej zaskakujących różnic i mniej momentów, w których ktoś patrzy w git diff i pyta: „dlaczego ten plik w ogóle się zmienił?”.

Lepsza obsługa rename i refaktorów struktury katalogów

Przy większych projektach najwięcej bólu powodują zmiany typu „wydzielmy moduł”, „przenieśmy ten pakiet do innego folderu”. Starsze wersje Git częściej „gubiły się” przy takich operacjach, traktując je jak masowe usuwanie i dodawanie plików, co w merge skutkowało lawiną konfliktów.

Git 2.5x poprawia wykrywanie przeniesionych i przemianowanych plików, przez co:

• mergowanie gałęzi z dużą refaktoryzacją skutkuje mniejszym zbiorem realnych konfliktów,
• konflikty pojawiają się tam, gdzie faktycznie weszła merytoryczna zmiana w treści, a nie tylko w ścieżce pliku,
• przegląd historii jest sensowniejszy – widać „rename + zmiana”, zamiast „remove + add”.

Dla zespołów, które co jakiś czas porządkują przestrzeń nazw, wydzielają biblioteki czy przechodzą z monolitu na moduły, to realne oszczędności czasu przy każdym większym mergu.

Nowe i dopracowane strategie merge

Strategia merge decyduje o tym, jak Git łączy gałęzie. W 2.5x nie chodzi o rewolucję, ale o sensowne domyślne zachowanie i lepsze wsparcie dla często używanych wariantów. Kilka przykładów, które można włączyć do codziennej praktyki:

• --no-commit – pozwala przeprowadzić merge „na sucho”: Git wykona scalanie, pokaże konflikty i zmiany, ale nie zapisze od razu commita. Przydaje się przy bardziej ryzykownych mergach na gałęziach release.
• --no-ff – wymusza tworzenie merge commitów nawet wtedy, gdy teoretycznie możliwy byłby fast-forward. Ułatwia odtwarzanie kontekstu pracy na gałęziach funkcjonalnych.
• --strategy-option ours/theirs – precyzyjniejsze sterowanie, z której strony konfliktu preferować zmiany dla wybranych plików lub katalogów.

W Git 2.5x te opcje lepiej współgrają z pozostałymi funkcjami (np. rewizją historii, logami), więc da się bez kombinowania zbudować bardziej spójny model branchowania: z czytelnymi merge commitami na branchach release i „spłaszczoną” historią na branchu deweloperskim.

Konflikty, które da się zrozumieć

Największym problemem nie jest sam konflikt, tylko konflikt, którego nikt nie rozumie. W 2.5x komunikaty i struktura konfliktów zostały dopracowane tak, żeby szybciej dojść do sedna. Pojawiają się:

• bardziej opisowe nagłówki konfliktów w plikach,
• przejrzyste informacje, skąd pochodzą dane wersje (który branch, jaki commit),
• lepsze wsparcie dla narzędzi graficznych, które potrafią ten kontekst pokazać.

Przy typowym konflikcie na końcówce sprintu, kiedy branch feature musi wylądować w develop przed code freeze, różnica jest prosta: zamiast pół godziny „kopania się” z diffami, wystarczy często kilka minut decyzji, którą wersję przyjąć i czy warto dopisać dodatkowy test.

Przerywanie i cofanie merge bez stresu

Git od dawna ma git merge --abort, ale w starszych wersjach bywało z nim różnie, szczególnie przy nietypowych scenariuszach. Git 2.5x stabilizuje to zachowanie, dzięki czemu:

• przerwanie nieudanego merge jest bardziej przewidywalne,
• szanse na pozostawienie repozytorium w „pół-zmergowanym” stanie są mniejsze,
• debugowanie „co tu się właściwie stało” jest prostsze, bo log lepiej odzwierciedla operacje.

To ważne psychologicznie: jeśli merge można bezpiecznie przerwać i wrócić do punktu wyjścia, deweloperzy chętniej podchodzą do trudniejszych scaleni. Zamiast odkładać merge gałęzi refaktoryzacyjnej „na nigdy”, zespół może go przeprowadzić wcześniej, przy mniejszym ryzyku i mniejszym zestawie konfliktów.

Merge a code review – jak wykorzystać nowe możliwości

Git 2.5x lepiej wspiera style pracy, w których code review i merge są blisko siebie. Przy kilku prostych zasadach można poukładać proces tak, żeby review nie kończyło się „niespodzianką” w postaci innego zestawu zmian po mergu:

• utrzymywanie spójnych zasad: --no-ff na main/master, fast-forward na branchach pomocniczych,
• wykonywanie ewentualnego rebase przed review, przy użyciu bezpieczniejszych opcji 2.5x,
• porównywanie branchy w narzędziu do review w oparciu o ten sam merge base, z którego korzysta Git 2.5x.

Rezultat: diff widziany podczas review jest praktycznie tym samym, który wejdzie do historii po mergu. Mniej niespodzianek, mniej „co się stało po kliknięciu merge w GUI”.

Rebase w 2.5x: nowe tryby, bezpieczniejsze porządkowanie historii

Rebase jako standard w codziennym pullu

W wielu zespołach od lat trwa spór: git pull z merge czy z rebase. Git 2.5x ułatwia postawienie na rebase jako domyślny sposób aktualizacji lokalnej gałęzi, bez nerwowego strachu, że „coś się popsuje”.

Kilka opcji, które warto rozważyć:

[pull]
  rebase = true
[rebase]
  autoStash = true

Przy takiej konfiguracji git pull zadziała jak git fetch + git rebase, a lokalne, niecommitowane zmiany zostaną tymczasowo odłożone na stash. Mniej przypadkowych merge commitów i mniej ręcznego kombinowania z git stash przed każdym pullem.

Tryby rebase dopasowane do różnych gałęzi

Nie każda gałąź powinna być traktowana tak samo. Git 2.5x daje wygodniejsze mechanizmy, żeby zróżnicować zachowanie rebase w zależności od tego, na czym pracujemy:

• na gałęziach feature: agresywny rebase, porządkowanie commitów, scalanie „mikro-commitów” w logiczne jednostki,
• na gałęziach release: ostrożniejszy rebase, czasem ograniczony do prostego przesunięcia kilku commitów bez ingerencji w ich zawartość,
• na gałęziach hotfix: często brak rebase po wypuszczeniu, żeby zachować pełną audytowalność kolejnych poprawek.

Konfigurację można w części opisać w repozytorium (np. rekomendowane aliasy), a w części – w dokumentacji zespołowej jako „kontrakt”: jak się obchodzić z konkretnymi branchami. Git 2.5x dostarcza narzędzia, ale to zespół nadaje im znaczenie.

Bezpieczniejsze przerwanie i cofanie rebase

Strach przed rebase w dużej mierze brał się z tego, że „jak coś pójdzie nie tak, to nie wiadomo, co teraz”. W 2.5x sytuacja jest czytelniejsza:

• git rebase --abort działa bardziej przewidywalnie – przywraca stan sprzed rebase w szerszym zakresie scenariuszy,
• git rebase --skip sensowniej prowadzi przez trudniejsze konflikty, kiedy jedna ze zmian może zostać bezpiecznie pominięta,
• komunikaty podczas rebase lepiej opisują, na którym commicie jesteśmy i co się właśnie dzieje.

Dla osób, które dotychczas unikały rebase „bo boją się, że coś zgubią”, to duża ulga. Nawet jeśli rebase zostanie przerwany w połowie, powrót do poprzedniego stanu jest prostszy i wyraźniej udokumentowany w logu.

Rebase a współdzielone gałęzie – zasady bez dogmatyzmu

Klasyczna rada „nigdy nie rób rebase na współdzielonej gałęzi” ma sens, ale w praktyce bywa łagodzona. Git 2.5x, dzięki lepszym narzędziom i komunikatom, pozwala wprowadzić nieco bardziej elastyczne podejście, jeśli zespół jest zgrany:

• na main/master i gałęziach release zachować twardą zasadę: żadnego rebase po wypchnięciu na origin,
• na tymczasowych, krótkotrwałych branchach zespołowych uzgodnić, że dopóki nie wejdą w CI i nie są podstawą dla innych branchy, dopuszczalny jest rebase „w porządkującym” celu,
• jasno komunikować w zespole, kiedy rebase został wykonany („branch X został zrebasowany, zróbcie świeży pull z --rebase”).

Jeśli Git 2.5x jest wszędzie, ryzyko dziwnych rozjazdów historii jest mniejsze, bo wszyscy mają ten sam zestaw zachowań rebase i identyczne komunikaty błędów. Grunt to nie traktować rebase jako magii, tylko jako kontrolowaną operację, o której się rozmawia.

Aliasowanie rebase pod potrzeby zespołu

Jednym z prostszych sposobów na oswojenie rebase jest przygotowanie aliasów, które łączą bezpieczne opcje w jedną, zapamiętywalną komendę. Przykładowo:

[alias]
  rci = rebase --interactive
  rcs = rebase --interactive --autosquash
  rcf = rebase --interactive --autosquash origin/feature

Aliasy można dostosować do konwencji nazewniczej branchy w projekcie. Z czasem deweloperzy zapamiętają: git rcs przed otwarciem pull requesta to standardowy sposób „posprzątania” historii. Mniej pomyłek z ręcznym wpisywaniem długich opcji, mniej strachu, że „zapomnę jakąś flagę”.

Interaktywny rebase krok po kroku – scenariusze z życia zespołu

Scenariusz 1: sprzątanie historii przed pull requestem

Typowa sytuacja: na gałęzi feature powstało sporo commitów w stylu „naprawa testów”, „drobne poprawki”, „ups, poprawka poprzedniej poprawki”. Kod jest dobry, ale historia – niekoniecznie. Zanim gałąź trafi do review, dobrze ją ujednolicić.

Na Git 2.5x taki proces może wyglądać tak:

1. Sprawdzenie, ile commitów chcemy objąć:

   git log origin/feature..HEAD

2. Uruchomienie interaktywnego rebase:

   git rebase -i origin/feature

3. W edytorze zamiana części pick na:
   • fixup/f – dla commitów, które mają zostać „wklejone” do poprzedniego bez zachowania osobnego komunikatu,
   • squash/s – jeśli chcemy połączyć kilka commitów w jeden z nowym opisem.
4. Zapisanie i zamknięcie edytora. Git 2.5x przeprowadzi rebase, pokazując czytelniejsze komunikaty i w razie potrzeby poprosi o nową treść commita zbiorczego.

Na koniec w historii zamiast 10–12 drobnych commitów widać 2–3 logiczne jednostki. Reviewer dostaje zwięzły, zrozumiały ciąg zmian, a autor gałęzi nie musi się tłumaczyć z każdej literówki w osobnym wpisie.

Scenariusz 2: rozdzielanie jednej dużej funkcji na kilka mniejszych pull requestów

Często zdarza się, że pojedynczy branch „urósł” za bardzo: jedna gałąź zawiera i migrację bazy, i nowy endpoint, i refaktoryzację starego modułu. Code review się dusi, a wdrożenie wszystkiego naraz robi się ryzykowne. Interaktywny rebase w Git 2.5x pomaga taki monolit rozdzielić na kilka czystszych gałęzi.

Przykładowy plan działania:

1. Na gałęzi „przeładowanej” zmianami sprawdzenie historii:

   git log --oneline main..feature/mega

   Chodzi o zorientowanie się, które commity dotyczą jakiego obszaru.

2. Uruchomienie interaktywnego rebase na wspólnym przodku:

   git rebase -i main

   W edytorze przesunięcie commitów tak, aby zmiany należące do jednego wątku (np. migracja DB) były obok siebie.

3. Oznaczenie części commitów jako drop (lub usunięcie odpowiednich linii), jeśli mają „wypaść” z tej gałęzi i trafić na osobną:

   pick 1234abcd migracja tabeli users
   pick 5678efgh indeksy do tabeli users
   # poniższe zmiany przenosimy do innego brancha
   drop 9abc0123 nowy endpoint /profile
   drop def45678 refaktoryzacja modułu auth

4. Po zakończeniu rebase powstaje „odchudzona” gałąź z samą migracją. Z tego stanu można utworzyć kolejne branche:

   git checkout -b feature/migracja-users
   git push -u origin feature/migracja-users

   Następnie z oryginalnej gałęzi lub z main odtwarza się brakujące zmiany (np. przez cherry-pick lub kolejny rebase interaktywny).

W Git 2.5x cały ten proces jest mniej nerwowy, bo przerwanie i cofnięcie rebase działa pewniej. Jeśli podczas „segregowania” commitów coś zacznie wyglądać podejrzanie, zawsze można użyć git rebase --abort i spróbować innej strategii (np. wydzielenia tylko części zmian).

Scenariusz 3: wycofywanie niefortunnego commita bez śmieci w historii

Czasem zamiast klasycznego git revert lepiej popraw