Git rebase i git push: non-fast forward, po co używać?

Kilka uwag na temat działania git (non technical):

Podczas rebase ' u, git pobiera commity, o których mowa, i "recommenduje" je na podstawie czystej historii. Ma to na celu uniemożliwienie wyświetlania historii:

Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge
Commit SHA1: aaaa -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg

Po rebase może wyglądać tak (lub podobnie):

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

Problem polega na tym, że nowy commit, który próbujesz wypchnąć, nie jest potomkiem commita na końcu gałęzi, do której naciskasz.

Teraz wiesz, że te same informacje są w commitach, ale git jest odpowiedzialny nie tylko za nadpisywanie tych commitów (bbbb-gggg w powyższym przykładzie).

Shared Repo Model

Jeśli używasz współdzielonego repozytorium, takie rzeczy mogą być bardzo mylące. Pozwól mi wyjaśnić dlaczego. Powiedzmy, że inny programista ściągnął gałąź i ma commity aaaa -> gggg w swojej gałęzi. Następnie wykonują commit iiii

W międzyczasie, you rebased i zmusił do pchnięcia, powodując, że drzewo wygląda tak:

Description: tree -> rebase
Commit SHA1: aaaa -> hhhh

Kiedy drugi programista próbuje przeforsować, otrzymuje komunikat "non-fast forward". Po połączeniu obie historie są połączone razem, a ty skończysz z bałaganem

Coś takiego (bałagan):

Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge 
Commit SHA1: aaaa -> hhhh   -> bbbb   -> cccc  -> dddd   -> eeee  -> ffff   -> gggg -> iiii    -> jjjj

Innymi słowy, jeśli inni ciągną i pchają, lepiej trzymać się Git merge, lub unikać pchania aż po rebase (i tylko rebase Twój pracy).

Publicznie Widoczny Model Repozytorium

Być może używasz innego (bardziej gittish) modelu, w którym po prostu chcesz, aby ludzie byli w stanie wyciągnąć z repo. W tym przypadku, git push -- force nie jest tak źle, ponieważ wtedy mogą sobie poradzić z nadążaniem za nim. Mogą zmienić swoje zmiany , aby być na bieżąco z Twoimi zmianami przed przekazaniem ci swoich poprawek. Zapobiega to zepsuciu twojego repo.

Jednak może być lepszy sposób dla Ciebie. git push --mirror

Od http://www.kernel.org/pub/software/scm/git/docs/git-push.html

Zamiast nazywania każdego ref do push, określa, że wszystkie refy pod $GIT_DIR/refs / (który zawiera ale jest nie ogranicza się do refów/głowic/, refs / remotes/, oraz refs / tags/) be skopiowane do zdalnego repozytorium. Nowo utworzone lokalne refy będą / align = "left" / zaktualizowane refy zostaną zaktualizowane na koniec zdalny i usunięte refs will być usunięte z odległego końca. To jest domyślna, jeśli konfiguracja opcja zdalna..lustro ustawione.

Jedną z wspaniałych rzeczy wgit jest to, że jest bardzo elastyczny i pozwala na wiele różnych przepływów pracy. Ale jego prawdziwa siła polega na tym, że jest to model rozproszony, więc wierzę, że największy zwrot z inwestycji można uzyskać, używając go w ten sposób.