Dlaczego wydaje się, że DVCS mają irracjonalną fobię niezamierzonych zmian?

Pochodząc ze środowiska SVN, jedną z najtrudniejszych rzeczy, do których należy się przyzwyczaić podczas pracy z systemami DVCS, jest sposób, w jaki wszyscy postrzegają każdą niezaangażowaną zmianę jak tykającą bombę zegarową.

W Mercurial, jeśli próbujesz pobrać zmiany i masz jakieś niezatwierdzone zmiany w kopii roboczej, musisz przeskakiwać obręcze, aby po prostu scalić nadchodzące zmiany. Chcesz zmienić gałęzie? Zmusi cię to do odłożenia wszystkiego na półkę, a następnie będziesz musiał natychmiast odłożyć to wszystko na drugim końcu. (SVN nie ma problemów z żadnym z tych scenariuszy.)

Git jest mniej więcej taki sam. Współpracuję z innym programistą przy projekcie i właśnie próbowałem wybrać jeden z jego commits do mojego widelca. Odmówił mi pozwolenia, ponieważ wprowadziłem niezatwierdzone zmiany w mojej kopii roboczej, w zupełnie innych plikach niż te zmienione w jego zatwierdzeniu. Nie ma nawet opcji scalania; najwyraźniej najpierw muszę ukryć swoje zmiany!

Gdyby ktoś traktował coś całkowicie nieszkodliwego z tak wielką ostrożnością, nazwałbym to „fobią”, irracjonalnym strachem, który należy uznać za zaburzenie psychiczne. Ale Git i Mercurial zostały zaprojektowane przez dwa różne zespoły inteligentnych, racjonalnych programistów, więc muszę się zastanawiać, czy wiedzą coś, czego nie jestem świadomy.

Czy istnieje powód techniczny, który uzasadnia takie podejście do niezaangażowanych zmian? A jeśli tak, to dlaczego wydaje się, że problem występuje tylko w DVCSes?

version-control dvcs

— Mason Wheeler
źródło

Czy sens tych rzeczy, które możesz sprawdzić w lokalnym oddziale, nie jest trywialny? Scalenie od drugiego programisty staje się wówczas faktycznym połączeniem zamiast próby rozwiązania trzech źródeł (twojej wersji, twoich zmian, ich wersji). Nie jestem jednak ekspertem w tej dziedzinie, więc może być nie na miejscu.

— Telastyn

Zgadzam się z Telastyn. Myślę, że powodem, dla którego napotykasz pozornie irracjonalne ograniczenia, jest to, że nie używasz Gita w idiomatyczny sposób. Jedną z głównych zalet Git jest to, że możesz dokonywać transakcji lokalnie. Gdybym musiał scalić czyjś kod z moją kopią roboczą, byłbym pewien, że do cholery najpierw zatwierdzi lokalnie. Lokalne zobowiązania są tanie, łatwe do czyszczenia i niesamowitą siatką bezpieczeństwa. Nie jestem zaskoczony, że przepływy pracy Git obracają się wokół niego (w związku z tym ostrzeżenia i ograniczenia zakładają, że wolisz zatwierdzić, niż pracować nad nieproszonymi plikami).

— MetaFight,

@Telastyn: Nie, nie możesz, ponieważ rejestracja - nawet w lokalnym oddziale - wymaga powodu zatwierdzenia i tworzy zapis w historii. Jeśli więc wpiszesz coś, co nie było jeszcze gotowe do zatwierdzenia, w końcu, gdy będziesz gotowy wypchnąć zmiany do zdalnego repozytorium, historia będzie tam, chyba że przejdziesz dodatkowe operacje, aby przepisać historię. To nie pasuje do żadnej definicji „trywialnej”, którą rozpoznaję, i wydaje mi się, że to dużo dodatkowej złożoności bez żadnej wymiernej korzyści.

— Mason Wheeler,

Naprawdę? „Ustabilizowana XYZ do scalenia z głównego” to jakieś obciążenie, czy też przejdziesz do zbyt grzecznej historii?

— Telastyn

Czy zgłosiłbyś artykuł do publikacji bez przynajmniej edycji dla jasności? Następnie nie przesyłaj pierwszej wersji serii zatwierdzeń do publikacji. Zrób wszystkim, którzy przeczytają Twój kod, wielką przysługę: wróć i stwórz serię zatwierdzeń, którą napisałeś, gdybyś miał przede wszystkim odwagę, aby zrobić to w ten sposób. Interaktywny rebase nie jest trudny ..

— 2015

Odpowiedzi:

W świecie DVCS zobowiązania są tanie, a historia zmienna. WIP może być tak „brudny”, jak chcesz: i nie widzę żadnych powodów, aby „upuścić mój obecny stan w zestawie zmian do przechowywania”
Historia SVN jest liniowa, a więc - ty musi scalić ty sporządza ze zmianami z nowymi wersjami. DVCS używa (naturalnie) DAG, a dodatkowa głowa (zatwierdzanie + wyciąganie + podnoszenie) do rozbieżnej historii jest bezpieczniejsza niż łączenie w locie zmodyfikowanego roboczego katalogu z pobranymi zmianami zewnętrznymi
Kiedy przełączysz (na jakiś węzeł ) zmodyfikowane WC w Subversion, pozbędziesz się jednego potencjalnego dodatkowego scalenia (w przeciwieństwie do „zatwierdzenia do starego” - „przełączenia” - „scalenia 1 rew. Zakresu”) ... i wiemy: łączy się w SVN nie są idealną stroną narzędzia, chociaż nie jest to żadnym problemem dla DVCSes

Wznawianie

To nie jest fobia, to (czasem surowe) egzekwowanie przestrzegania dobrych manier „często popełniaj” (użytkownicy SVN czasami boją się tego stylu)

I w końcu hg qnew|qpop|qpushjest mała uczciwa cena za porządek i porządek

— Leniwy Borsuk
źródło

Kiedy scalasz lub wybierasz git, natychmiast tworzysz zatwierdzenie. Operacja nie jest zakończona, dopóki zatwierdzenie nie zostanie zakończone i nie będzie częścią historii.

Co by się stało, gdybyś gitpozwolił ci przerzucić niezatwierdzone zmiany w katalogu roboczym? Miałbyś (mniej lub bardziej) trudny czas na rozróżnienie między konfliktami zmian / scalania, które musisz zadbać o scalenie / wybranie cherry, a zmianami, które sam wprowadziłeś. Ponadto byłoby prawie niemożliwe przetestowanie tego, co faktycznie popełniasz.

Zatem wymuszenie czystego katalogu roboczego dla sytuacji scalania pomaga zachować prostotę i łatwość zarządzania. W końcu wszystko, co musisz zrobić, to ukryć swoje niezaangażowane zmiany przed scaleniem, a następnie je schować. Pamiętaj, że w przepływie pracy

git stash
git pull
git stash pop

masz dwie (!) operacje scalania. Jeden, który łączy twoje ostatnie zatwierdzenie z nadchodzącymi zmianami, i ten, który łączy twoje niezatwierdzone zmiany z wynikowym zatwierdzeniem scalania. W ten sposób musisz tylko połączyć dwie rzeczy w jedną, unikając zamieszania, które wynikałoby z próby połączenia trzech rzeczy w jedną podczas jednej operacji, próbując zignorować te trzy rzeczy. git stash/ git stash popPozwala na łatwe i jednoznaczne, że ignorują swoje niezatwierdzone zmiany dla seryjnej.

— cmaster - przywróć monikę
źródło