Czy w scentralizowanej kontroli wersji zawsze warto często aktualizować?

Przy założeniu, że:

• Twój zespół używa scentralizowanej kontroli wersji.
• Pracujesz nad większą funkcją, której ukończenie zajmie kilka dni, a wcześniej nie będziesz mógł jej zatwierdzić, ponieważ spowodowałoby to uszkodzenie kompilacji.
• Członkowie Twojego zespołu codziennie zatwierdzają coś, co może zmienić niektóre pliki, nad którymi pracujesz.

Ponieważ jest to scentralizowana kontrola wersji, w pewnym momencie będziesz musiał zaktualizować swoją lokalną kasę: przynajmniej raz przed zatwierdzeniem nowej funkcji.

Jeśli aktualizujesz tylko raz tuż przed zatwierdzeniem, może być wiele konfliktów z powodu wielu innych zmian dokonanych przez twoich kolegów z drużyny, co może być światem bólu do rozwiązania naraz.

Lub możesz często aktualizować, a nawet jeśli istnieje kilka konfliktów do rozwiązania z dnia na dzień, powinno to być łatwiejsze, krok po kroku.

Czy zostaniesz, warto często aktualizować?

Osobiście aktualizuję moje lokalne wersje codziennie.

W opisanym przez ciebie scenariuszu poszedłbym o krok dalej

• Tworzenie gałęzi dla nowej, długiej funkcji.
• Scalaj często z głównej linii do tej nowej gałęzi.

Tą drogą,

• Możesz meldować się codziennie, aby zachować swój kod na serwerze
• Nie musisz się martwić o zerwanie kompilacji poprzez odprawę.
• Możesz użyć repozytorium, aby cofnąć niektóre prace lub różnice, jeśli to konieczne, przy wcześniejszych odprawach.
• Na pewno będziesz pracować nad najnowszą bazą kodu i wcześnie wykryć możliwe zmiany w konflikcie kodu.

Wady, jakie widzę, to

• Scalanie z głównego musi być wykonane ręcznie (lub skryptowo)
• To wymaga więcej „administracji”

Tak, często warto aktualizować. Często aktualizujesz, aby uniknąć trudnych konfliktów scalania, a to jest podstawowa wiedza na temat zarządzania konfiguracją oprogramowania (SCM) z problemem rozbieżnych zmian.

Jest to niezależne od tego, czy jest scentralizowane czy dystrybuowane; im dłuższy czas odejdziesz od źródła źródłowego (tzn. jeśli jest to pień, gałąź lub inne repozytorium w przypadku DVCS), tym większa szansa na konflikt scalenia. Tak, przy aktualizacji mogą pojawić się nieprzyjemne niespodzianki ze strony zespołu, ale odkładanie nieprzyjemnej niespodzianki jest jeszcze gorsze (im dłużej czekasz, tym mniej ludzie pamiętają, dlaczego wprowadzono zestaw zmian).

Aby aktualizacja działała, oznacza to również, że ty i inni programiści pracujący nad kodem nigdy nie powinniście świadomie zatwierdzać lub przekazywać kodu źródłowego, który psuje kompilację . Jest to zazwyczaj powód, dla którego programiści rozgałęziają się (lub odchodzą od głównego nurtu w kategoriach SCM), aby chronić członków zespołu i innych interesariuszy przed złamaniem kodu, jeśli taka sytuacja nieuchronnie się pojawi.

Mantra, której możesz użyć do zapamiętania, brzmi: „aktualizuj, aktualizuj, aktualizuj, zatwierdzaj”. Zawsze upewnij się, że zmiany działają z innymi przed zatwierdzeniem. Ma to również na celu sprawdzenie, czy kod po raz pierwszy działa.

Trzeci punkt w pytaniu jest po prostu zły :

• Pracujesz nad nową funkcją, której wykonanie z pewnością potrwa kilka dni, a wcześniej nie będziesz mógł jej zatwierdzić, ponieważ spowodowałoby to uszkodzenie kompilacji.

Jeśli wiesz , że będziesz pracować nad czymś, czego nie możesz zatwierdzić przez jakiś czas, jest to podręcznikowy przykład użycia gałęzi.

Nie stawiaj się w sytuacji, gdy masz wiele oczekujących zmian. Jeśli wiesz, że przez pewien czas nie będziesz mógł zatwierdzić w głównym oddziale swojego projektu, pracuj nad innym. I tam często popełniaj .

Jeśli jesteś już w sytuacji opisanej w pytaniu, a następnie przejść do oddziału teraz , swoje zmiany i kontynuować pracę w tej branży.

Zwykle w CVCS dobrym pomysłem jest częsta aktualizacja. Ale jeśli pracujesz nad oddziałem, pytanie „często aktualizuj lub nie” staje się „często scalać lub nie”. I tak odpowiedź brzmi tak. Po prostu upewnij się, że zatwierdziłeś wszystkie oczekujące zmiany (w oddziale) przed połączeniem z innym oddziałem, abyś mógł bezpiecznie wycofać scalanie, jeśli musisz.

Myślę, że powinieneś częściej popełniać . Jeśli zamierzasz pracować przez dłuższy czas, jak kilka dni, powinieneś rozgałęzić swój kod i pracować w swoim oddziale, zamiast pracować bezpośrednio w linii głównej. Wiem, że wygodnie jest rozpocząć pracę bez rozgałęzień, ale nie jest to zbyt elastyczne, ponieważ nie możesz być pewien, że twoja aktualizacja / zatwierdzenie złamie kod, czy nie, co kończy się sytuacją, w której będziesz trzymał aktualizację / zatwierdzenie, dopóki nie wykonał swoją pracę. „Rozgałęzianie funkcji” jest lepsze, ponieważ zawsze możesz zatwierdzić swój kod i po prostu scalić go później, kiedy skończysz.

W strategii rozgałęziania aktualizacja została zastąpiona scalaniem z pnia. Z mojego doświadczenia wynika, że ​​nie trzeba często łączyć z pnia, ponieważ kod w okresie około pięciu dni niewiele by się zmienił i łatwiej jest rozwiązać konflikt tylko raz po zakończeniu.

Uważam, że wygodniej jest używać rozproszonej kontroli wersji lokalnie. To znaczy, używam git jako klienta subversion. Ma to zalety, które:

• Lokalne zmiany są zapisywane przed aktualizacją, więc jeśli popełniam błąd podczas scalania, zawsze mogę wrócić i zrobić to ponownie.
• Podczas większych zmian mogę zapisać ukończone części. Ułatwia to przegląd pozostałych zmian w toku.
• Kiedy naprawiam błąd podczas jakiejś większej pracy, mogę zatwierdzić właśnie tę poprawkę, tymczasowo zatwierdzić resztę i „polecić” poprawkę do subwersji, pozostawiając pozostałą pracę w toku.

Jeśli dodajesz nową funkcję, czy możesz utworzyć nowy pojedynczy plik źródłowy (i pasujący plik nagłówka interfejsu zewnętrznego)?

Martwię się, że „nowa funkcja” ma szerokie implikacje? Orientacja obiektowa może już nie być modnym hasłem, jak kiedyś, ale ten paradygmat ma swoje zalety.

W ten sposób możesz stworzyć platformę (interfejs zewnętrzny oraz funkcje kodu pośredniczącego) i potwierdzić, że wtedy powinny istnieć minimalne efekty stron trzecich, podczas gdy zakończysz resztę rozwoju?

W opisywanej sytuacji uważam, że lepiej mieć więcej mniejszych plików źródłowych niż mniejszych, większych.

Czym różni się scentralizowana kontrola wersji od rozproszonej?

W obu przypadkach musisz się zameldować w miejscu, którego zawartość zostanie przeniesiona w porównaniu z tym, co zacząłeś. Nie widzę żadnej różnicy w częstotliwości scalania z centralnego repozytorium do miejsca pracy (a gałąź projektu to miejsce pracy).

Zwykle często biorę udział w scalaniu (przynajmniej raz dziennie, mogę też łączyć się w innym dogodnym dla mnie czasie lub gdy wiem, że ktoś sprawdził coś, co ma wpływ na to, nad czym pracuję). Znacznie łatwiej jest wchłonąć małe zmiany, a jeśli masz problem, ludzie są bardziej pomocni, gdy pytasz ich o to, co właśnie się zameldowali, niż o to, co sprawdzili tydzień temu.

BTW, nie wiem, co nazywacie „przełamaniem kompilacji”. Zwykle pracuję w stosunkowo niewielkich przyrostach, dzięki czemu zachowuję stan kompilacji, nawet jeśli psuje to niektóre funkcje. I przeprowadzam testy, aby wiedzieć, że scalenie nie zepsuło czegoś, co powinno zadziałać. Ponownie łatwiej jest rozwiązać problem, gdy zostanie wcześnie wykryty.

Zależy to od tego, jak dobry jesteś w „aktualizacji”, gdy ktoś inny psuje kompilację. Z jednej strony chcesz aktualizować w jak najmniejszych porcjach. Osobiście aktualizuję prawie za każdym razem, gdy zauważę, że aktualizacje są dostępne. Z drugiej strony, jeśli kompilacja się zepsuje i zajmie to dzień komuś, by ją naprawił, nadal będziesz mógł pracować nad nową funkcją w międzyczasie.

Pracowałem z systemami kontroli wersji, których utworzenie kopii zapasowej jest bardzo trudne po zakończeniu aktualizacji. W tych przypadkach aktualizuję zwykle tylko przed zalogowaniem się. Dzięki lepszym systemom kontroli wersji nie ma powodu, aby nie aktualizować kilka razy dziennie.