Git jak to odkręcić

Hej, próbuję ogarnąć git'a i się troszkę zagubiłem.
Stworzyłem lokalne repozytorium, zrobiłem pierwszego commita na masterze, w którym dodałem wszystkie pliki z projektu i wrzuciłem to na githuba.
Następnie utworzyłem nowego brancha powiedzmy o nazwie "changes", pozmieniałem kilka rzeczy, które uwzględniłem w 3 commitach. Pomyślałem, że fajnie teraz będzie te zmiany wrzucić do mastera, więc przeszedłem na mastera, użyłem polecenia "git merge changes". Oczywiście ukazał mi się komunikat o pełnym sukcesie, więc zadowolony wrzuciłem wszystko na github'a... A później zauważyłem, że faktycznie połączyło mi mastera z branchem changes ale.. wygląda to tak:

master:
-pierwszy-commit
-zmiana1
-zmiana2
-zmiana3

changes:
-pierwszy-commit
-zmiana1
-zmiana2
-zmiana3

Finalnie chciałem uzyskać tylko jednego commit'a z informacją o dodaniu zmian z brancha changes - bez całej historii jak te zmiany powstawały.

master:
-pierwszy-commit
-dodanie-changes

changes:
-pierwszy-commit
-zmiana1
-zmiana2
-zmiana3

Poczytaj o squashowaniu zmian. Natomiast nie ma nic złego w tym domyślnym zachowaniu - umożliwia wygodniejszy podgląd oraz ewentualnie cofnięcie pojedynczych zmian już po mergu.

Jak to w gicie masz 700 sposobów na uzyskanie takiego efektu ;] Jest np. git merge --squash które poskleja commity. Przy czym nie jestem przekonany czy to jest taki dobry pomysł, bo potem nagle masz mega wielki commit i szukaj sobie co tam było zmieniane.

Mhm... Czyli taki sposób w jaki ja to zrobiłem to nie jest jakieś "nieelegancki" ?
Szczerze powiedziawszy chciałbym się nauczyć pracować z git'em w taki sposób jak robi to większość i stwierdziłem, że właśnie najbardziej eleganckim podejściem będzie pracować na nowym branchu, potem w jednym commicie wrzucić całego brancha do mastera, a w branchu zostaje cała historia.
Czyli podsumowując dobrą praktyką jest robienie tak jak zrobiłem, a robienie tego tak jak chciałem jest niezbyt dobre ?

Nie, zwykle robi sie to raczej tak, że pracujesz w branchu, potem robisz rebase tego brancha do mastera i z brancha robisz pull request do mastera. Kiedy pull reuqest wchodzi to branch jest usuwany.

Wyobraź sobie, że pracujesz lokalnie na swoim branchu, robisz historię zmian commitujac regularnie np. przez cały dzień. Wrzucasz zmiany na mastera. Ktoś to pobiera i chce zobaczyć co zmieniałeś bo coś mu przestało działać. Lepiej mu będzie przeglądać gigantyczny commit z listą zmian opisanych na 2 stronach A4 zmieniający 85 plików czy kilkanaście commitow opisujących małymi porcjami jakie zmiany robiłeś dodając feature?

Okej dzięki za wyjaśnienia :D Postaram się robić tak, by kiedyś nikt nie pomyślał "co za #@%@ posklejał te commity" w jedno duże #$%@#". Pozdrawiam i jeszcze raz dziękuję.

Czyli podsumowując dobrą praktyką jest robienie tak jak zrobiłem, a robienie tego tak jak chciałem jest niezbyt dobre ?

Zależy od zespołu. Ja się spotkałem właśnie z tym, że małe commity były "jechane" i ludzie woleli większe commity, bo uważali, że to im łatwiej będzie przeglądać na CR. Chociaż moim zdaniem duże commity to patologia, ponieważ utrudniają integrację oraz zrozumienie zmian/intencji, dla którego ktoś coś zrobił. Więc - ja jestem za małymi commitami.

No i commitując coś warto robić to tak, żeby nie psuć projektu. Czyli, nie powinno się commitować rzeczy, które zostawiają rozgrzebane pół pliku, tylko raczej po commicie wszystko powinno się uruchamiać jak należy, a testy powinny dalej przechodzić.

bo potem nagle masz mega wielki commit i szukaj sobie co tam było zmieniane.

@Shalom, ale on chciał mieć mega wielki commit i w razie czego szukać sobie poszczególnych commitów w branchu. To jak to trzeba robić?

Finalnie chciałem uzyskać tylko jednego commit'a z informacją o dodaniu zmian z brancha changes - bez całej historii jak te zmiany powstawały.

Tylko po co.
Nie rozumiem tego dążenia do pięknej historii, a właściwie do zamazywania historii commitów.
Jest merge, merge poszedł, kod działa, czego jeszcze chcieć.

W Gicie brancha po merge'u i tak jest już właściwie bezużyteczna, bo staje się niczym więcej jak tagiem na pewnym (i już nienajnowszym) commicie.

Shalom napisał(a):

Nie, zwykle robi sie to raczej tak, że pracujesz w branchu, potem robisz rebase tego brancha do mastera i z brancha robisz pull request do mastera. Kiedy pull reuqest wchodzi to branch jest usuwany.

Nie lepiej merge zamiast rebase? Ja wolę jak widać kontekst zmian, rebase da tylko liniową historię, tak jakby nigdy nie było żadnego brancha.
Poza tym, zwykle to używa się git flow.

To już kwestia kosmetyki czy zrobisz pull czy rebase, ale niektórzy mają jakieś fetysze związane z liniową historią ;)