git: squash commitów bez rebase

Przez jakiś czas byłem fanem robienia squash’y commitów za pomocą komendy:

zsh

git rebase -i HEAD~X

gdzie X był liczbą commitów jakieś chciałem połączyć w jeden. W praktyce wyglądało to git rebase -i HEAD~5, czyli łączyłem ostatnie 5 commitów w branchu w jeden. Wszystko działało fajnie jeśli one były moje. Ciekawiej robiło się gdy na liście commitów pojawiały się merge. Wtedy szansa na konflikty stawała się bardzo prawdopodobna.

Squash bez rebase

Od niedawno ten problem rozwiązuje w znacznie prostszy i szybszy sposób. Na potrzeby przykładu przyjmijmy, że:

new_feature, to branch na którym mam bałagan z commitami,
development, to branch do którego będzie wystawiony pull request, czyli new_feature -> development

Krok po kroku wygląda, to tak:

Tworzymy, nowy, tymczasowy branch z brancha do którego będziemy merdżować (w naszym przypadku będzie to development) czyli:
zsh
```
git checkout -b new_feature_temp
```
Następnie merdżujemy new_feature do new_feature_temp komendą
zsh
```
git merge --squash new_feature
```
Ta komenda przeniesie wszystkie zmiany z new_feature ale nie zrobi żadnego commita. Można powiedzieć, że efekt jest podobny do komendy git stash pop. Teraz możemy wprowadzić commit message:
zsh
```
git commit -m "feat: my awesome feature"
```
Kolejny krok to przejście na nasz oryginalny branch (new_feature) i zresetowanie go do zmian z tymczasowego brancha.
zsh
```
git checkout new_feature
git reset --hard new_feature_temp
```
Ostatni krok to wypchnięcie nowych zmian i wyczyszczenie tymczasowanego brancha
zsh
```
git push -f
git banch -D new_feature_temp
```

Może to się wydawać trochę skomplikowane na początku, ale uwierzcie, że tak nie jest. Wszystko działa jak należy. Ten sposób na pewno będzie przydatny na feature branchach, który były wyrównywane z branchami docelowymi, bo trzeba było rozwiązać konflikty. W takim przypadku interaktywny rebase nie sprawdzi się.