Jak uniknąć commita merge w Pull Requeście?

Mam pytanie, pracowałam nad zadaniem z zespołem z grupy, w dwie osoby na jednym zadaniu:

1. zrobiłam pull request jakiś czas temu na swoim branchu, w międzyczasie, inna osoba na swoim branchu zacommitowała swoje zmiany, które ja u siebie chce wykorzystac
2. zrobilam merge z branchem drugiej osoby, rozwiazane konflikty, i pewnie pushnelam ten merge na swoj branch, ze jest w moim pull request
3. push commita z nowymi moimi zmianami. i ponownie ten sam pull request, ale zawiera też zmiany drugiej osoby (pkt 1) z innego brancha, zmergowane z moimi
   jak rozwiazac ta sytuacje, by w moimi pull request zostaly tylko moje zmian? by nie zawieral zmian drugiej osoby, z ktorym rozwiazaniem (branchem) zmergowalam moj branch

Jeśli to faktycznie był merge (a nie rebase), to w Pull Requeście powinny być widoczne tylko Twoje zmiany oraz commit merge'a. Mergowanych commitów nie powinno być widać bo one są już na target branchu. Ale jeśli to nie był merge, tylko rebase - to te commity będą widoczne jako inne commity (mimo że mają taką samą nazwę i treść). Właściwie, to w jedną stronę - w drugą byłoby okej.

Najlepiej jakbyś pokazał screena jakiegoś.

rano wrzuce screen

Riddle napisał(a):

[...] to w Pull Requeście powinny być widoczne tylko Twoje zmiany oraz commit merge'a.

dokladnie tak jest
a chce by w pull requescie byly wylacznie moje zmiany, bez commita merga

No to nie powinieneś robić u siebie merge'a tego brancha innej osoby.

LoOpY_99 napisał(a):

1. zrobiłam pull request jakiś czas temu na swoim branchu, w międzyczasie, inna osoba na swoim branchu zacommitowała swoje zmiany, które ja u siebie chce wykorzystac
2. zrobilam merge z branchem drugiej osoby, rozwiazane konflikty, i pewnie pushnelam ten merge na swoj branch, ze jest w moim pull request

Punkt 1. jest spoko. Punkt 2. jest nie okej - robiąc git merge tworzysz merge commit, i on będzie widoczny w Pull Requeście. Jedyna opcja żeby merge commit nie był widoczny to jest nie robić merge'a, i inaczej zintegrować się z target branchem. A te metody to jest: rebase, cherry-pick, reset albo napisać Twoje zmiany od nowa.

1. Najlepsza metoda to "rebase". Po prostu robisz git rebase target_branch, również musisz rozwiązać konflikty, ale potencjalnie może być ich więcej - bo teoretycznie musisz rozwiązać konflikty dla każdego commita w którym występują (zamiast tylko raz, dla merge'a). To jest szybkie i łatwe, jeśli edytujecie różne pliki. Jeśli macie dużo zmian w tych samych plikach, to rebase to jest męka.
2. Jeśli to nie działa, to powinieneś zrobić git checkout na target branch, i potem po kolei robić git cherry-pick swojego brancha. To jest praktycznie to samo co git rebase, tylko że commit-po-commicie, co może pomóc rozwiązać niektóre problemy, albo nie dodawać niepotrzebnych commitów (co rebase'm też można zrobić, tylko trzeba dać interactive rebase).
3. Jeśli to też nie działa, to możesz zrobić git reset --soft na target branch i zrobić commit - tylko wtedy stracisz swoje porobione commity, ale zachowasz zmianny, i możesz je zacommitować jeszcze raz. To jest dobre wtedy kiedy całkowicie przepisujesz jakiś feature, i i tak zmienisz kod z którym się integrujesz.
4. Jeśli zmiana którą chcesz dodać jest prosta, jak np "Move", "rename", "extract", coś co IDE zrobi w sekundę, to warto wywalić swoje zmiany, zrobić checkout na target branch i nałożyć je drugi raz - będzie szybciej.

1. Najpierw druga osoba merdżuje swoje zmiany do master.
2. Potem Ty merdżujesz mastera do swojej gałęzi.
3. Na koniec robisz PR - masz tylko różnicę między swoją gałęzią a masterem.
4. Potem robisz merge ze squashem, aby nie naśmiecić w historii mastera commitami ze swojej gałęzi.

Nie używaj rebase, gdy nie potrzebujesz. Pobieranie i merdżowanie swoich zmian do mastera w żadnym momencie nie wymaga używania rebase.

somekind napisał(a):

Nie używaj rebase, gdy nie potrzebujesz. Pobieranie i merdżowanie swoich zmian do mastera w żadnym momencie nie wymaga używania rebase.

A co rebase szkodzi?

A po co tracić czas na coś, co nie jest konieczne?

somekind napisał(a):

A po co tracić czas na coś, co nie jest konieczne?

Jaka to jest strata czasu żeby wpisać git rebase zamiast git merge?

rebase może spowodować rozwiązywanie konfliktów.

somekind napisał(a):

rebase może spowodować rozwiązywanie konfliktów.

Merge też.

Ze sqashem? Po uprzednim merge z mastera do feature brancha.
Nie bardzo.

Poza tym merge generuje konflikty raz, a rebase dla każdego commita, więc najpierw można rozwiązywać konflikty, a potem konflikty zmieniające te konflikty na kod niekonfliktujący (który już teraz będzie w konflikcie). Brzmi jak paranoja.

somekind napisał(a):

Ze sqashem? Po uprzednim merge z mastera do feature brancha.
Nie bardzo.

Poza tym merge generuje konflikty raz, a rebase dla każdego commita, więc najpierw można rozwiązywać konflikty, a potem konflikty zmieniające te konflikty na kod niekonfliktujący (który już teraz będzie w konflikcie). Brzmi jak paranoja.

Dla mnie paranoja to historia zaśmiecona merge commitami; albo co gorsza sprowadzanie każdego PR'a do pojedynczego commita.

Riddle napisał(a):

Dla mnie paranoja to historia zaśmiecona merge commitami;

Zgoda.

albo co gorsza sprowadzanie każdego PR'a do pojedynczego commita.

No jeśli nie to, to masz masę śmieciowych, nikomu niepotrzebnych commitów w masterze. Po co?

somekind napisał(a):

No jeśli nie to, to masz masę śmieciowych, nikomu niepotrzebnych commitów w masterze. Po co?

Obie skrajności są nie dobre.

Brak squasha nie oznacza od razu 20 commitow.

Pytanie zasadnicze: czemu chcesz tego uniknąć? Moim zdaniem to robota głupiego.

Riddle napisał(a):

Brak squasha nie oznacza od razu 20 commitow.

No nie, jeśli ktoś robi jeden commit dziennie, bo tak wymagał SVN, to tak nie ma. Ale jak ktoś używa kontroli wersji zgodnie z przeznaczeniem, to commitów będzie dużo.
I po co one potem w masterze?

somekind napisał(a):

Riddle napisał(a):

Brak squasha nie oznacza od razu 20 commitow.

No nie, jeśli ktoś robi jeden commit dziennie, bo tak wymagał SVN, to tak nie ma. Ale jak ktoś używa kontroli wersji zgodnie z przeznaczeniem, to commitów będzie dużo.

Ja bym chciał w mojej historii mieć stosunkowo małe commity, które mają w sobie "jedną rzecz". Tak żeby móc z nimi pracować łatwo w historii.

Często widziałem PR które miały w sobie więcej rzeczy niż jedna, i squash Tego Potem robi Tylko gorzej.

Ale jeśli PR na starcie jest mały i ma faktycznie jedną rzecz, to nie mam problemu żeby go zesquashować. (Tylko wtedy trochę nie rozumiem - po co robić PR z tymi commitami? Czemu nie zrobić squasha lokalnie i wtedy go wrzucić?).

Riddle napisał(a):

Ja bym chciał w mojej historii mieć stosunkowo małe commity, które mają w sobie "jedną rzecz". Tak żeby móc z nimi pracować łatwo w historii.

Taki też jest mój cel. Dlatego nie chcę mieć w historii śmieciowych commitów z brudnopisu, bo one utrudniają korzystanie z historii.

Ale jeśli PR na starcie jest mały i ma faktycznie jedną rzecz, to nie mam problemu żeby go zesquashować. (Tylko wtedy trochę nie rozumiem - po co robić PR z tymi commitami? Czemu nie zrobić squasha lokalnie i wtedy go wrzucić?).

Bo po zaaplikowaniu komentarzy z PR, trzeba będzie znowu squashować. Po co robić dwa razy, skoro można raz?

somekind napisał(a):

Riddle napisał(a):

Ja bym chciał w mojej historii mieć stosunkowo małe commity, które mają w sobie "jedną rzecz". Tak żeby móc z nimi pracować łatwo w historii.

Taki też jest mój cel. Dlatego nie chcę mieć w historii śmieciowych commitów z brudnopisu, bo one utrudniają korzystanie z historii.

No to git.

somekind napisał(a):

Ale jeśli PR na starcie jest mały i ma faktycznie jedną rzecz, to nie mam problemu żeby go zesquashować. (Tylko wtedy trochę nie rozumiem - po co robić PR z tymi commitami? Czemu nie zrobić squasha lokalnie i wtedy go wrzucić?).

Bo po zaaplikowaniu komentarzy z PR, trzeba będzie znowu squashować. Po co robić dwa razy, skoro można raz?

A to nie jest 1 sekunda dla dobrego programisty (max. 2 sekundy, jak nie pił kawy)? Każde porządne IDE ma skrót do tego:

Ostatnio zrobiłem PR'a z trzema commitami:

• Replace .png images with .svg
• Update ImageMagic to "2.0.0"
• Add dropdown in user profile to select two image types

I nie chciałbym żeby ktoś mi zesquashował te 3 commity w jeden. A jak są komentarze do zmiany to robię --fixup, --amend albo commit + squash.

Riddle napisał(a):

Ostatnio zrobiłem PR'a z trzema commitami:

• Replace .png images with .svg
• Update ImageMagic to "2.0.0"
• Add dropdown in user profile to select two image types

I nie chciałbym żeby ktoś mi zesquashował te 3 commity w jeden. A jak są komentarze do zmiany to robię --fixup, --amend albo commit + squash.

Z daleka widać, że te trzy rzeczy nie są jednym zadaniem, więc nie powinny być w jednym PR.

somekind napisał(a):

Z daleka widać, że te trzy rzeczy nie są jednym zadaniem, więc nie powinny być w jednym PR.

Chciałem żeby były w jednym, bo chciałem je wdrożyć razem. Z biznesowego punktu widzenia nie opłaca się release'ować jednego lub dwóch z nich osobno.

Riddle napisał(a):

Chciałem żeby były w jednym, bo chciałem je wdrożyć razem. Z biznesowego punktu widzenia nie opłaca się release'ować jednego lub dwóch z nich osobno.

No cóż, mam to szczęście, że biznes u mnie zajmuje się biznesem, a nie mikrozarządzaniem i mówieniem mi jak i kiedy releasować.