git rebase na oddziałach o długiej żywotności (zdalnej)

Question

Tło: Używamy github do naszego projektu i pracuję na własnym rozwidleniu naszego głównego repozytorium. Używamy rebase zamiast scalania, aby uniknąć dużych commitów.

Scenariusz: Sposób chcę pracować jest tak:

1. Przy wdrażaniu nowej funkcji, należy utworzyć lokalny oddział pana mego widelca i umieścić w moich zmian tam. Ja i inni członkowie grupy wykonujemy wiele małych zatwierdzeń, więc prawie zawsze będzie wiele zatwierdzeń, które wpływają na ten sam plik w oddziale.
2. Popchnij lokalny oddział do mojego widelca, więc mam zdalną kopię tego, nad czym pracuję (nie chcę, aby wszystkie moje zmiany zostały utracone, gdy mój laptop zginie lub zginie.) Próbuję to zrobić na końcu każdego dnia).
3. Jeśli ukończenie tej operacji zajmuje dużo czasu, od czasu do czasu dokonuję ponownej oceny mastera widelca, aby upewnić się, że nie nastąpiły żadne zmiany, które mogłyby spowodować uszkodzenie mojej funkcji. Zwykle to działa dobrze.
4. Aby zachować zdalną kopię gałęzi, przesyłaję lokalny oddział do tego po bazie danych.

Problem: Krok 4 to miejsce, w którym pojawia się problem. Niemal zawsze muszę radzić sobie z nieprzeciętnymi zatwierdzeniami i używać git push --force.

Szukałem na

Git: how to maintain permanent parallel branches

How to maintain (mostly) parallel branches with only a few difference

i nie znalazłem sposób, aby moje prace workflow. Wykonywanie wyszukiwania google w przepływie pracy git głównie zwraca wyniki, które zakładają, że wszyscy pracują w lokalnych oddziałach i nie przechowują zdalnej kopii na github (na przykład http://nvie.com/posts/a-successful-git-branching-model/).

Jestem względnie nowy w Git, więc chciałbym się dowiedzieć, czy czegoś tu nie ma. Chciałbym móc wykonać krok 4 bez użycia siły. Alternatywny przepływ pracy, który nadal pozwala używać rebase zamiast scalania i utrzymywania zdalnej kopii mojego lokalnego oddziału, również byłby bardzo przydatny.

Answer 1

git push --force jest faktem, gdy mamy do czynienia z odgałęzieniami i odległymi oddziałami, ponieważ git push nie wykona bez szybkiego przewijania do przodu. Większość rzeczy w git zakłada, że ​​historia jest tylko dołączona do, nigdy nie jest edytowana, a rebase łamie to założenie, więc musisz zrobić kilka ładnych rzeczy, żeby to działało.

Użyliśmy przeprojektowania w bazie danych bardzo podobnej do tej, którą opisałeś, ale ostatecznie po pewnym czasie przełączyłeś się z powrotem na przepływ pracy scalającej. Rebasing daje ci ładną, ładną, linearną historię, ale ma wiele wad, takich jak wymaganie --force, tracąc zdolność widzenia stanu oddziału przed scaleniem się z mistrzem, i tak dalej.

Jak wspomina Amber, rebase bardzo utrudnia pracę z innymi osobami w tej samej branży - przed git push --force, trzeba spojrzeć na status zdalnego oddziału, aby sprawdzić, czy ktoś wcześniej do niego wepchnął, i pull --rebase, że w, a następnie git push --force. Nawet jeśli jest to sytuacja wyścigowa - jeśli ktoś inny popycha tuż przed tobą push --force, ich zmiany zostaną nadpisane przez Ciebie.

Answer 2

Jeśli jesteś rebase, zawsze będziesz musiał --force po naciśnięciu, ponieważ rebase przepisuje historię. Tak po prostu działa. Przepisana historia nie będzie z wyprzedzeniem przewyższać tej samej historii.

Alternatywą jest merge zamiast rebase ing. Możesz użyć dokładnie tego samego przepływu pracy, z wyjątkiem scalania zamiast rebase i nie będziesz musiał wymuszać popychania.

Jeśli nikt inny nie używa twojego oddziału zdalnego poza tobą, użycie --force nie jest z natury złe. Jeśli inne osoby mają są przy użyciu oddziału zdalnego, powinieneś prawdopodobnie używać merge tak czy inaczej.