git fetch a git pull

Ucze sie GITA i nie bardzo rozumiem sens uzywania git fetch skoro jest git pull, albo nie rozumiem roznicy miedzy nimi.
Dla mnie normalne jest uzycie git pull, bo od razu wszystko mamy i sie merguje, a przy git fetch trzeba jeszcze zrobic inne rzeczy i wlasciwie nie wiem jakie. Albo git checkout albo git branch i git reset z tego co czytam tylko czy reset nie kasuje zmian?

Po co uzywac git fetch?

Czyli git fetchem pobieram wszystkie branche, ktore nie sa mergowane, a git pullem tylko jeden, ktory jest mergowany?

Ucze sie GITA

Chyba Gita.
Ludzie często piszą niepoprawnie GIT na wzór SVN-a, który też się tak nie nazywa, bo nazywa się Subversion.
Git to nie jest od niczego skrót.

nie bardzo rozumiem sens uzywania git fetch skoro jest git pull, albo nie rozumiem roznicy miedzy nimi.

https://git-scm.com/docs/git-pull

Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

git fetch używa się gdy chcesz mieć na dysku całą aktualną zawartość zdalnego repo, bez naruszania żadnej gałęzi lokalnej ani katalogu roboczego.

O ile się nie mylę konsolowe git pull fetchuje wszystkie branche. Komenda Pull pod TortoiseGitem pobiera jednak tylko aktualną – na co się już parę razy naciąłem.

Ja używałem git fetch gdy zmieniało się położenie zdalnego repozytorium - w pracy kolega zmigrował repozytorium gita do lokalnego GitHuba. Sekwencja poleceń była wtedy taka:

git remote add new_repo git://cośtam
git fetch new_repo
git branch -u new_repo/master master
git pull

Z samym git pullem nie chciało mi działać.

Prócz tego wszystkiego co zostało napisane wyżej to istnieje jeszcze jeden przydatny case. Powiedzmy że masz ustawiony upstream dla brancha X i przed chwila zrobiłeś git fetch albo byleś na innym branchu i również zrobiles git fetch i chciałbyś sprawdzić jakimi commitami różni sie obecny branch na którym jesteś w stosunku do branch'a na którym byłeś jak wpisałeś git fetch. Do tego masz 2 możliwości
1)

git fetch
git log --oneline ..nazwa_brancha_ktora_moze_byc_bardzo_dluga_a_ty_nie_masz_auto_complete_w_konsoli

git fetch
git log --oneline ..FETCH_HEAD

Zasadnicza różnica jest taka, że git pull robi rzeczy nie zawsze tak jakbyś chciał. Kiedyś ludzie narzekali na git pull bo zawsze robił merge, co czasem kończyło się tym, że miałeś mnóstwo commitów o nazwie Merge branch origin/master into master, więc zamiast tego zdecydowanie lepiej było użyć git fetch i git rebase origin/master bo dzięki temu miałeś liniową historię. Potem pojawiła się flaga --ff-only do git pull, która robi to samo co przy merge, robi merge tylko gdy jest możliwość fast-forward, potem dodano opcję w konfiguracji i teraz można dać git config --global pull.ff only i mieć to z głowy. Alternatywnie można też użyć git pull --rebase --preverse-merges (lub git config --global pull.rebase preserve) i mieć mniej więcej to samo co z ręcznym użyciem rebase.

Ja osobiście mam ustawione git config --global pull.ff only bo IMHO daje mi to większą kontrolę (albo FF albo sam mam zdecydować). Automatyczny rebase byłby trochę uciążliwy wg mnie.

Jest też kwestia rebase. Czasami ludzie robią tak, że zamiast robić merge mastera do localnego brancha, robią rebase i wtedy nie możesz użyć "pull" tylko właśnie fetch a potem rebase

Swoja droga git rebase na wypchnietych branchach to zuo.

Może być taka sytuacja, że robię commita na mastera, ale w międzyczasie kolega wypchnął na mastera w repo swojego commita. W takim razie muszę zrobić rebase swojego lokalnego mastera na mastera z repo i wtedy mój commit będzie na samej górze - to pozwoli na zrobienie normalnego pusha.

Z drugiej strony branche poza masterem są zwykle osobiste i tam można spokojnie robić push --force. U nas rebase brancha na defaulta + push --force to norma, by uniknąć pokręconych historii w gicie. Problemów z tym nie ma, bo tak jak już napisałem branche poza masterem/ defaultem/ etc są zwykle osobiste i dopiero po zakończeniu pracy na branchu tenże branch jest merge'owany do głównej gałęzi.