[victordeleco2]

Mirkasy mam pytanie odnośnie rebase.
Generalnie mniej wiecej wiem jak działa, i jaki daje efekt. Używam go od jakiegoś czasu.
Mam pytanie odnośnie nakładania commitów.
Załóżmy, że mamy:
- feature
- develop

Na developie wjechaly dwa merge (dwa commity). Chcę zrobić rebase mojego feature do developa. Na feature branch mam jeden commit, ale zmiany są w tym samym obszarze co commity na develop.
Pytanie brzmi:
Czy teraz commit będzie nakładany na każdy commit developa? Czyli oznacza to, że będę musiał rozwiązać konflikty dwukrotnie? Czy może tylko na ostatni commit z developa? Czy jest odwrotnie i to jeśli są dwa commity na feature branch a na develop jeden to trzeba konflikty rozwiązać dwukrotnie?
#programowanie #git

[venticco]

@victordeleco2:rebase nie robisz "do" tylko "na" - każdy commit z feature jest nakładany na deva (tak jakby dev został wykonany wcześniej), więc jeśli zmiany w commitach będą niekompatybilne z nową bazą to będzie to zakomunikowane jako normalny merge conflict, który trzeba ogarniać na nowo dla każdego commitu z brancha feature jeśli taki się pojawi (bo kontekst czyli historia poprzedzająca commit jest inna), natomiast można w gicie ustawić flagę dla funkcji "rerere"

[Saly]

Czy teraz commit będzie nakładany na każdy commit developa?

@victordeleco2: weź poczytaj o tym jeszcze raz, bo piszesz masło maślane. Będać na feature i wołając git rebase develop sprawiasz, że feature wygląda tak samo jak develop. Następnie wszystkie commity, które się różnią są nakładane na ten nowy feature. Commity są nakładane jeden po drugim, jak masz konflikt, to jest rozwiązanie polega na modyfikacji tego commita. Jak wszystko rozwiążesz to twój

[victordeleco2]

@venticco: Tak błąd w poście robi się "na". Czyli rozumiem każdy commit z feature jest nakladany na OSTATNI commit z developa?

[venticco]

@victordeleco2: tak, przy zwykłym wywołaniu 'git rebase develop' to ostatni commit developa poprzedza pierwszy commit z feature brancha, jeśli istnieje potrzeba to można dużo precyzyjniej tym sterować przy pomocy parametru --onto:
https://stackoverflow.com/questions/29914052/i-cant-understand-the-behaviour-of-git-rebase-onto

[victordeleco2]

@Saly: Rozumiem. Czyli warto na feature mieć jak najmniej commitów. Mniej razy rozwiązujemy konflikty.

[victordeleco2]

@venticco: @Saly: Wszystko jasne Panowie. Dziękuje.

[venticco]

@victordeleco2: i tak i nie, jeśli masz zmiany z feature podzielone na dużo małych commitów, to często łatwiej się odnaleźć w merge confliktachgdy takie wystąpią i rozwiązywać je na malutkim obszarze, rozwiązywanie merge confliktów w jednym dużym konflikcie może być dużo cięższe do prawidłowego obsłużenia i łatwiej o pomyłkę, z doświadczenia wydaje mi się że najlepiej robić sporo małych commitów i jednocześnie często rebasować

[Saly]

@victordeleco2: konflikty rozwiązujesz, gdy są konflikty. Najczęściej ich nie ma, liczba commitów nie ma tu dużego znaczenia, bo co za różnica czy rozwiążesz 10 lini w 1 commicie, czy 1 linię per 10 commitów. Co do feature branchów to najlepiej je często rebasować do developa, bo wtedy łatwiej zapanować nad zmianami, niż robiąć to, gdy chcesz faktycznie wrzucić zmiany z feature do developa.

A tak na boku to polecam https://trunkbaseddevelopment.com/ ,