Czy błędem jest odgrywanie gałęzi siły pchającej?

11

Kiedy pracuję nad gałęzią funkcji, zwykle chcę wyczyścić zatwierdzenia w gałęzi za pomocą interaktywnego bazy, zanim moja praca zostanie przejrzana i zintegrowana z gałęzią główną.

Podczas opracowywania funkcji chcę przekazać moją pracę pośrednią do zdalnego repozytorium jako środek zapasowy. To znaczy, kiedy mój dysk twardy ulega awarii, nie chcę, aby cała gałąź funkcji została utracona.

Prowadzi to jednak do tego, że często muszę zrobić git push --forcezdalne repozytorium po rebase, co jest ogólnie niezadowolone. Lub, jak mówi połączona strona github:

Ponieważ zmiana historii zatwierdzeń może utrudnić wszystkim innym, którzy korzystają z repozytorium, uważanie, że zmiana bazy danych jest już zepchnięta do repozytorium, jest złą praktyką.

Czy istnieje (ogólnie akceptowana) polityka, która rozwiązuje ten konflikt?

Dlaczego nie jest to duplikat Czy git „Złota zasada Rebasing” jest tak niezbędny?

Moje pytanie tutaj dotyczy polityki rozwiązania konfliktu między chęcią wykonania kopii zapasowej pracy w zdalnym repozytorium a ponownym udostępnieniem pracy , podczas gdy inne pytanie próbuje zaprzeczyć, że istnieje konflikt, i pyta, dlaczego niektórzy uważają, że konflikt w ogóle istnieje, i dlatego pyta, dlaczego „konieczne jest, aby nie naciskać na siły?

Chiel ten Brinke
źródło
1
@gbjbaanb, jeśli dokonujesz zatwierdzeń WIP, rebase jest bardzo przydatny, aby uniknąć wielu zatwierdzeń w ciągu jednego dnia pracy. Często dokonuję zatwierdzeń drobnych zmian po prostu w razie potrzeby mam opcję „cofnij do stanu, który pamiętam” - większość z nich jest nieistotna / zakłóca główną historię repozytorium (dlatego rebase jest tak przydatny).
kraina krańców
1
@gbjbaanb Myślę, że to kwestia opinii. Wiele zespołów stosuje strategię zmiany zasad, aby utrzymać swoją historię w czystości.
Chiel ten Brinke
1
@enderland każdy chce ładnej historii, to wciąż niewłaściwa (i niebezpieczna) czynność, jak pokazuje link. Torvalds nigdy nie powinien był tego robić, powinien zamiast tego zezwolić na kompresję zatwierdzeń na wyświetlaczu.
gbjbaanb
1
@ gbjbaanb, ale ... nie zrobił tego, więc musimy pracować z tym, co mamy. Dla mnie o wiele bardziej przydatne jest posiadanie pojedynczego zatwierdzenia w gałęzi master zamiast ponad 30 indywidualnych i przyrostowych zatwierdzeń z każdej gałęzi operacji. Ale chyba każdy będzie miał inny obieg pracy ...
Enderland

Odpowiedzi:

5

Kluczowe pytanie, które należy sobie zadać:

  • Czy utrzymujesz swój zdalny oddział po ponownym połączeniu się w master?

Jeśli usuniesz gałąź zdalnych funkcji po scaleniu w master, już tracisz historię. Zakładając, że zmiażdżysz / wyodrębnisz oddział przed dokonaniem połączenia / PR, stracisz tę historię. Wszystko, co robisz w tym przypadku, pozwala na użycie github jako kopii zapasowej.

Sytuacja, w której chcesz zachować historię, a nie wymuszać wypychanie, polega na tym, że zdalny oddział utrzymuje się po scaleniu i nie istnieje tylko przez pewien czas.

Podejrzewam, że pytasz, czy zatrzymałbym oddział pozbawiony podstaw? Nie, AFAIC. Mimo to, wymuszanie push może teoretycznie spowodować utratę zatwierdzeń od innych użytkowników, którzy pchnęli do tego samego oddziału

Wygląda na to, że wiele osób naciska jednocześnie na tę gałąź. Oznacza to, że dbasz o historię w oddziale.

Zamiast tego możesz zrobić dla swojej pracy pośredniej rozwidlenie tej gałęzi. Możesz naciskać na to, a następnie przekształcić wszystkie swoje zatwierdzenia w jeden zatwierdzenie przed połączeniem, więc kiedy scalisz je w swoją gałąź funkcji, masz tylko 1 zatwierdzenie (z przebudowaną historią całego oddziału).

kraina krańca
źródło
„Czy utrzymujesz swój zdalny oddział po ponownym połączeniu się w master?” Podejrzewam, że pytasz, czy zatrzymałbym oddział pozbawiony podstaw? Nie, AFAIC. Mimo to, wymuszanie push może teoretycznie spowodować utratę zatwierdzeń od innych użytkowników, którzy pchnęli do tego samego oddziału.
Chiel ten Brinke
@ChieltenBrinke Ja trochę o tym napisałem. FYI
enderland
Myślę, że rozwidlenie jako środek zapobiegający zniszczeniu zatwierdzeń podczas wymuszania push jest w rzeczywistości bardzo dobrą sugestią. Ale AFAIK nie jest tak naprawdę koncepcją git i potrzebujesz otoki usług, aby to zrobić łatwo (na przykład github). Czy mam rację? A może mylę twoje użycie terminu „rozwidlanie” tylko do utworzenia oddzielnej gałęzi?
Chiel ten Brinke
@ChieltenBrinke dobrze możesz osiągnąć to samo na wiele sposobów. Jeśli gałąź funkcji znajduje się w zdalnym repozytorium, możesz rozwidlić repozytorium i uzyskać wersję tej gałęzi. A następnie scal tę gałąź ze zdalną gałęzią po zatwierdzeniu zgniatania. Lub możesz po prostu utworzyć inną gałąź lokalną (być może featurebranch-local), a następnie aktywować programistę w tej gałęzi, z dowolną liczbą zatwierdzeń. Gdy chcesz scalić, zmiażdż te zatwierdzenia, a następnie połącz je z funkcją. Zasadniczo po prostu robię dev w rzeczywistej gałęzi tymczasowej, a następnie zgniatanie / scalanie w twoją funkcję.
kraina krańca
Zakładając, że rozwiązywanie repo nie wchodzi w grę, ponieważ nie używa się github, pracowalibyśmy z „prywatną” develop-featuregałęzią. Oczywiście, prywatność odbywa się wyłącznie na podstawie konwencji i nie jest narzucona przez nic, ale może stać się częścią polityki, szczególnie jeśli zostaną do tego wprowadzone pewne konwencje nazewnictwa gałęzi. (Może jestem teraz zbyt niespokojny, a może nie :) Kombinacja z --force-with-leasenie może boleć, chociaż nie należy na niej polegać, jak wskazano w moim innym poście.
Chiel ten Brinke
3

Wymieniam tutaj niektóre możliwości, które przychodzą mi do głowy.

Zawsze bazuj na nowej gałęzi

Jeśli masz brudną gałąź some-feature, ustaw ją na nowej gałęzi. Na przykład

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Następnie some-feature-rebaseprzejrzeli i zintegrowali.

Problem: Dużym minusem jest to, że, ściśle mówiąc, potrzebujesz nowej gałęzi dla każdej bazy. (Na przykład możesz mieć wiele zmian, jeśli wprowadzisz zmiany po sprawdzeniu kodu)

Posługiwać się git push --force-with-lease

Właśnie dowiedziałem się o git push --force-with-leasealternatywiegit push --force , która

odmawia aktualizacji oddziału, chyba że tego oczekujemy; tzn. nikt nie zaktualizował oddziału powyżej.

Problem : Wydaje się, że poprawia się to bezpośrednio w sytuacji, w której używamy tylko --force, ale nadal ma pewne zastrzeżenia, szczególnie gdy robię git fetchzamiast zamiast git pull, który aktualizuje nasze lokalne oddziały powyżej, podstępnie --force-with-leasemyśląc, że nie wprowadzono żadnych zmian gałąź.

Chiel ten Brinke
źródło