Czy codzienne wprowadzanie / sprawdzanie kodu jest dobrą praktyką?

63

Czytałem notatkę Martina Fowlera na temat ciągłej integracji, a on wymienia jako „Wszyscy zobowiązują się do głównej linii każdego dnia”.

Nie lubię zatwierdzać kodu, chyba że sekcja, nad którą pracuję, jest kompletna i że w praktyce zatwierdzam swój kod co trzy dni: jeden dzień w celu zbadania / odtworzenia zadania i wprowadzenia wstępnych zmian, drugi dzień w celu uzupełnienia zmian , i trzeci dzień, aby napisać testy i posprzątać ^ do przesłania. Nie czułbym się komfortowo, przesyłając kod wcześniej.

Teraz pobieram zmiany z repozytorium i integruję je lokalnie zwykle dwa razy dziennie, ale nie robię tego często, chyba że mogę wykonać mniejszą pracę.

Pytanie: czy codzienne zobowiązanie jest tak dobrą praktyką, że powinienem zmienić przepływ pracy, aby go dostosować, czy nie jest to wskazane?

Edycja: Wydaje mi się, że powinienem był wyjaśnić, że miałem na myśli „zatwierdzenie” w jego CVS (inaczej „push”), ponieważ jest to prawdopodobnie to, co Fowler miałby na myśli w 2006 roku, kiedy to napisał.

^ Kolejność jest bardziej dowolna i zależy od zadania, moim celem było zilustrowanie okresu czasu i działań, a nie dokładnej sekwencji.

Sanki
źródło
20
Możesz zatwierdzić swój kod, jeśli się skompiluje i wykona jakąś przydatną logikę. Lepiej zatwierdzać kod w krótkich cyklach, jeśli pracujesz w środowisku zespołowym.
EL Yusubov
4
Czy Martin Fowler zakłada VCS, który nie jest dystrybuowany?
user16764,
4
Zwróć uwagę na datę tego artykułu: 1 maja 2006 r. Git i Mercurial zaczęły się dopiero w kwietniu 2005 r. I mam wrażenie, że naprawdę zaczęły zyskiwać popularność około roku 2008. Nie mogę znaleźć żadnych artykułów na stronie Fowlera do jednego z nich przed 2009 rokiem. Zatem ten artykuł z 2006 roku wyraźnie zakłada scentralizowany system kontroli źródła, taki jak SVN. Porada nie dotyczy zespołów korzystających z DVCS.
Kyralessa,
2
@ Kyralessa: Artykuł mówi nawet, że „Subversion jest nowoczesnym [systemem kontroli wersji]”.
che
4
Najpierw kod, a potem testy?

Odpowiedzi:

43

Nie zgadzam się z tą zasadą i zgadzam się z tym, co powiedział Mason Wheeler . Chciałbym dodać kilka pomysłów.

Próbuję zatwierdzić za każdym razem, gdy mam znaczącą zmianę do zatwierdzenia: może to być kilka razy dziennie, jeśli naprawię kilka drobnych błędów, lub raz w tygodniu, jeśli pracuję na większym oprogramowaniu, z którego nie mogą korzystać pozostałe kod w jakikolwiek znaczący sposób, dopóki nie osiągnie spójnego stanu.

Ponadto interpretuję zatwierdzanie jako publikację znaczącej wersji, która dodaje nową funkcjonalność do podstawy kodu. Myślę, że należy spróbować wyczyścić kod przed zatwierdzeniem, aby inni programiści mogli zrozumieć znaczenie i cel zmiany, gdy patrzą na historię zmian. Im mniej zmian widzą inni programiści w historii, tym lepiej: kiedy patrzę na historię zmian, chcę zobaczyć przyrosty, które dodają znaczącą funkcjonalność; Nie interesuje mnie każdy mały pomysł, który każdy programista miał i chciał wypróbować, zanim dotrą do rozwiązania.

Co więcej, nie sądzę, że dobrym pomysłem jest używanie serwera SVN (lub innego systemu kontroli wersji) jako narzędzia do tworzenia kopii zapasowych, do których zobowiązana jest bieżąca migawka kodu (pod warunkiem, że się kompiluje): można użyć pamięci USB lub zewnętrzny dysk USB lub dysk sieciowy do dublowania bieżącego kodu, aby nie zgubił się w przypadku awarii komputera. Kontrola wersji i tworzenie kopii zapasowych danych to dwie różne rzeczy. Publikowanie wersji to nie to samo, co zapisanie migawki kodu.

Wreszcie, myślę, że nie powinno być problemu z dokonywaniem od czasu do czasu (tj. Tylko wtedy, gdy ktoś jest naprawdę zadowolony z obecnego stanu kodu) i unikanie konfliktów scalania nie jest dobrym uzasadnieniem częstego (zbyt) popełniania. Wiele konfliktów scalania ma miejsce, gdy różne osoby pracują jednocześnie nad tymi samymi plikami, co jest złą praktyką (patrz np. Ten artykuł , punkt 7). Konflikty scalania należy ograniczyć, dzieląc projekt na moduły z przejrzystymi interfejsami i możliwie najmniejszą liczbą zależności, oraz koordynując pracę programistów, tak aby kod, na którym pracują, nakładał się w jak najmniejszym stopniu.

Tylko moje 2 centy.

EDYTOWAĆ

Innym powodem, dla którego przyszło mi na myśl przedwczesne zatwierdzanie, jest to, że (bardzo) błędna wersja nie może zostać przetestowana. Jeśli zobowiązujesz się do połączenia, a zespół testowy testuje codziennie, mogą nie mieć wersji testowej przez kilka godzin (lub przez jeden dzień). Nawet jeśli nie spróbujesz naprawić błędu i po prostu cofniesz zmiany, przebudowa może potrwać kilka godzin. Przy, powiedzmy, pięciu testerach pracujących w twoim zespole, zmarnowałeś 5 x 2 = 10 godzin czasu zespołu z powodu braku aktywności. Zdarzyło mi się to raz, więc naprawdę staram się jak najszybciej unikać przedwczesnych zmian w nazwie commit .

Giorgio
źródło
23
„Zatwierdzenie” nie jest „opublikowaniem”. „Zatwierdź” oznacza „migawkę”; „opublikuj” w scm-lingo nazywa się „push”. Oczywiście SVN po prostu łączy obie koncepcje w jedną, co uniemożliwia wiele rozsądnych przepływów pracy, ale jest to ograniczenie narzędzia, a nie kontroli przepływu źródeł w ogóle.
tdammers
3
Revision control and data backup are two different thingsTak, zdecydowanie się tak czuję.
Sled
1
@tdammers: Miałem na myśli publikowanie w nieformalny sposób: o ile kod znajduje się na moim komputerze, to moje prywatne zmiany we wspólnym kodzie. Jak tylko go popełnię, zostaje opublikowany, znany reszcie zespołu i stanowi część oficjalnej historii projektu.
Giorgio,
1
W takim przypadku „zatwierdzenie” jest prawdopodobnie niewłaściwym słowem. Wiele SCM pozwala na lokalne zatwierdzenia, a dzielenie się kodem z resztą zespołu jest osobną czynnością, zwykle nazywaną „push”. Ponownie SVN łączy te dwie koncepcje razem, ale jest to ograniczenie narzędzia, a jeśli przeszkadza w przepływie pracy, rozważ przejście na inny SCM.
tdammers
@tdammers: Jasne rozróżnienie między lokalnym zatwierdzaniem a publikowaniem byłoby krokiem naprzód. W SVN mogę jednak użyć do tego osobnej gałęzi. Ale znowu zastanawiam się, dlaczego chciałbym śledzić wersję, która nie ma dla mnie większego sensu? Nie jestem przekonany, że chcę nowej wersji (nawet prywatnej) tylko dlatego, że jest piąta i wracam do domu. Zamiast tego wolę mieć kopię zapasową.
Giorgio,
107

Zatwierdzam kod kilka razy dziennie . Ilekroć dochodzę do punktu, w którym kod jest wystarczająco kompletny, aby skompilować i nie psuje innych rzeczy, wchodzi.

Powinieneś pomyśleć o zerwaniu z pracą, aby móc bezpiecznie odprawić się kilka razy dziennie.

Powody tego są dwa:

  1. Każda praca, która nie jest zalogowana, może zostać utracona - komputer może mieć katastrofalną awarię. W takim przypadku im dłużej czekasz, tym więcej tracisz pracy.
  2. Im więcej pracy wykonasz bez odprawy, tym więcej kodu będzie musiał zintegrować inni, kiedy w końcu zdecydujesz, że to zrobi. To zwiększa szanse na konflikty i problemy z łączeniem.
Oded
źródło
2
Jeśli masz poważny problem z konfliktami i połączeniami, oznacza to, że kierownik projektu nie wykonuje swojej pracy. Wiele spraw związanych z podobną funkcjonalnością powinno zostać skierowanych do tego samego programisty, tak aby nie było dwóch lub więcej programistów, które wzajemnie sobie radzą .
Mason Wheeler,
14
@MasonWheeler - po 3 dniach pracy, która nie została popełniona, istnieje bardzo duża szansa, że ​​ktoś dotknął kodu, który inni mają w tym samym czasie. Jeśli robi to grupa programistów, najlepszy menedżer projektu nie może uniknąć konfliktów.
Oded
3
@Oded: Może. Przypuszczam, że moja odpowiedź jest podbarwiona moim doświadczeniem w bazie kodu wystarczająco dużej, aby wszyscy nasi programiści (około tuzina programistów w zespole) mieli na siebie nie nakładające się obowiązki. Nie jestem pewien, jak będzie inaczej w mniejszych projektach.
Mason Wheeler,
3
@ArtB - Co jeśli ktoś taki jak ty sprawdza tylko co 3 dni? A może raz w tygodniu? Polegasz na innych, którzy postępują właściwie.
Oded
3
Kiedy przeczytałem pytanie, moja odpowiedź brzmiała: „Czy to tak, jakby pytać, czy to dobry pomysł, aby brać prysznic co tydzień”?
Andrew Grimm,
39

Niewolnicze stosowanie się do jakiejkolwiek metodologii lub praktyki bez zrozumienia przyczyn leżących u jej podstaw nigdy nie jest dobrym pomysłem. Stąd pochodzi program kultowego ładunku.

Dlatego „powinienem popełniać każdy dzień, bo tak powiedział Martin Fowler”, jest po prostu głupi. A czasem jest to również niepraktyczne. Jeśli pracujesz nad skomplikowaną nową funkcją, możesz nie dotrzeć do punktu, w którym warto się zalogować, dopóki nie pracujesz nad nią przez kilka dni.

Nie oznacza to, że powinieneś upewnić się, że wszystko jest idealne przed sprawdzeniem. To dobry sposób na utratę pracy, jeśli coś pójdzie nie tak. Właściwe jest, aby rozwinąć i odpowiednio ocenić sytuację. Praktyczne zasady mogą ci bardzo pomóc.

Mason Wheeler
źródło
1
Zatem, jeśli jest to złożona integracja / rozwój funkcji, nadal jest wielką stratą, aby jej nie zatwierdzić, może nie do pnia, ale przynajmniej w gałęzi dla tej funkcji, po to są gałęzie!
Vincent B.
2
Co masz na myśli mówiąc „warto się zameldować”? Jeśli nie łamie kodu nikogo, dlaczego by go nie sprawdzić?
Kirk Broadhurst,
2
„Co masz na myśli mówiąc„ warto się zameldować ”? Jeśli nie złamie kodu innego użytkownika, dlaczego nie miałbyś go zameldować?”: Ponieważ nie chcę przechowywać starych kopii kodu tylko dlatego, że istniały punkt w czasie. Chcę też zachować starą kopię kodu, jeśli zawiera on przydatne informacje, które chciałbym odzyskać w przyszłości. W przeciwnym razie po prostu produkuję bezużyteczny hałas w historii zmian.
Giorgio
3
+1. Kiedyś pracowałem w zespole, w którym codziennie musieliśmy sprawdzać kod w vcs, nawet jeśli kod był skokiem lub bezużytecznym dochodzeniem. Okazało się nieefektywne i marnotrawstwo, szczególnie dlatego, że wymagało okresowej konserwacji, aby wyczyścić VCS. Było to spowodowane połączeniem paranoi z powodu potencjalnego ryzyka utraty trochę czasu na wykonanie czegoś, a także dlatego, że kierownik przeczytał książkę, którą powinieneś robić codziennie. Być może skrajny przykład, ale poważnie, jeśli nie masz osądu, czy „warto” coś sprawdzić, prawdopodobnie nie jesteś dobrze przystosowany do pracy.
S.Robins,
14

Oded podał dwa ważne powody, dla których kod należy zatwierdzać tak często, jak to możliwe. Dodam jeszcze kilka:

  1. Podczas pracy nad fragmentem kodu inne mogą potrzebować niektórych funkcji tego kodu. Nie powinni czekać 6 dni, aby je zdobyć. W takim przypadku moi koledzy zwykle tworzą prototyp w moim fragmencie kodu, zatwierdzają go, dodajemy treść i zatwierdzam ponownie. I zwykle odbywa się to w ciągu kilku godzin.

  2. „Wspólny” kod umożliwia każdemu jak najszybsze zobaczenie każdej zmiany. Jeśli fragment kodu, nad którym pracujesz, jest całkowicie oddzielony od pracy innych i nie będziesz musiał czekać, to zaleca się utworzenie gałęzi, nad którą będziesz pracować, a następnie, jeśli wszystko się powiedzie, scal ją z główna linia.

superM
źródło
1
Dlaczego ta odpowiedź z (IMO) jest jedyną prawidłową i dokładną odpowiedzią (punkt 2), tak nisko ocenioną?! Oczywiście, że o to chodzi oddziału! @Mason Wheeler: Więc lubisz kodować kilka dni w trybie surowym bez żadnego jednorazowego zatwierdzenia? Dlaczego więc korzystasz z systemu kontroli wersji?
Vincent B.
2
To jest poprawna odpowiedź. Jeśli Twoim zadaniem jest wiele dni pracy, zanim będzie można je wykorzystać, to zrób oddział. W przeciwnym razie zobowiązujesz się za każdym razem, gdy działa, aby upewnić się, że członkowie zespołu mają najnowszą wersję, mogą przetestować, czy to działa, i jak najszybciej identyfikują dodane / brakujące funkcje.
Kirk Broadhurst,
„Więc lubisz kodować kilka dni w trybie surowym bez żadnego jednorazowego zatwierdzenia? Dlaczego więc korzystasz z systemu kontroli wersji?!”: Ponieważ ostatecznie chcesz dokonać korekty, nawet jeśli nie jesteś zmuszony ślepo zatwierdzać codziennie. Przeciwnie, to Ty decydujesz, czy zobowiązujesz się kilka razy dziennie, czy pracujesz trzy dni z rzędu bez zobowiązań. Naprawdę nie widzę sensu w uruchamianiu niedokończonej funkcji, z której nikt nie może korzystać: po prostu wykonaj kopię zapasową, następnego dnia możesz ją ukończyć i zatwierdzić.
Giorgio
8

Mocno wierzę w każdą logiczną zmianę, którą warto zachować. Zatwierdź często, a jeśli kod nie jest wart zachowania, przywróć go z powrotem do stanu czystego. Im dłużej czekasz na wypychanie / publikowanie kodu, tym trudniej jest go wdrożyć i tym więcej problemów napotkasz. Otrzymasz również informacje zwrotne na temat swoich wkładów znacznie szybciej:

  • czy oni psują kompilację?
  • czy powielasz wysiłki innego członka zespołu?
  • robisz coś nieprawidłowego?
  • czy ludzie czekają na rzeczy od ciebie?

Małe zmiany są o wiele łatwiejsze do zarządzania.

Warto również zauważyć różnicę między różnymi systemami kontroli wersji. Niektóre, takie jak Git (dystrybuowane), pozwalają lokalnie zatwierdzać i kontrolować całą historię, pchając tylko wtedy, gdy jesteś gotowy do opublikowania. Inne, takie jak SVN (scentralizowane), połączą dwa kroki, przez co małe zatwierdzenia będą bardzo nieefektywne.

Nie zapominaj, że twoje zobowiązania zasadniczo zmieniają dokumentację. Kiedy coś pójdzie nie tak, z przyjemnością będziesz mieć więcej historii niż jej za mało. Jedno zatwierdzenie tygodniowej pracy wydaje mi się bezużyteczne. Skończyło się na tym, że czytałem każdą zmienioną linię kodu zamiast podsumowania każdego logicznego fragmentu.

Adrian Schneider
źródło
5

Myślę, że większość odpowiedzi tutaj pomija jeden z głównych punktów oświadczenia Martina Fowlersa. Jest to związane z ciągłą integracją . Kod, który nie jest zalogowany (wypchnięty / opublikowany / scalony) do głównej linii nie jest testowany.

Nie należy tego odczytywać jako zachęty do zatwierdzenia dowolnego kodu, który masz na komputerze lokalnym, ilekroć nadejdzie czas opuszczenia biura. Jak wskazało kilka innych tutaj, które byłyby złe, zepsułyby kompilację i spowodowałyby niestabilną linię główną.

Zachęcamy jednak do dokonywania zmian małymi krokami, które można wprowadzić do głównej linii bez powodowania problemów. To zachęca do ewolucji kodu zamiast rozrywania go na części i przepisywania.

Co jest dobrego w tym sposobie pracy?

  1. Brak popełnienia dużych fragmentów kodu lub rewolucyjnych zmian zmniejsza ryzyko przerwania kompilacji.
  2. Jeśli twoje zatwierdzenie psuje kompilację, dość proste jest zidentyfikowanie problemów, przywrócenie go, a następnie szybkie zatwierdzenie poprawionej wersji.
  3. Upewniając się, że wszystkie testy działają przy każdej drobnej zmianie w kodzie, gwarantujesz, że nie wprowadzisz subtelnych błędów lub regresji, które mogą wynikać z rozrastania się kodu poza schematem ciągłej integracji.

Oczywiście nie wszystkie zmiany nadają się do tego podejścia. Jak zauważyli inni, żadna reguła nie jest absolutna. Jednak w przypadku zmian, które powinny pozostać poza linią główną przez długi czas, należy ustawić alternatywną linię główną z własnym schematem ciągłej integracji i stosować takie samo podejście do tego. Dzięki dzisiejszym rozproszonym VCS jest to dość łatwa rzecz.

Harald
źródło
+1: „Oczywiście nie wszystkie zmiany nadają się do tego podejścia”. Myślę, że o to chodzi. Uważam, że rada Fowlera jest OK, ale należy oceniać od przypadku do przypadku. Zamiast tego rada ta jest często uogólniana na bezwzględną zasadę i stosowana bez dalszego rozpatrywania.
Giorgio
@Giorgio, całkowicie się z tym zgadzam. Żadnych porad nie należy traktować jako bezwzględnych zasad, bez względu na to, kto stoi za nimi.
harald
Więcej pomysłów na ten temat. „Kod, który nie jest zalogowany (wypchnięty / opublikowany / scalony) do głównej linii nie jest testowany.”: Zgadzam się, że jest to dobra zasada i nie należy czekać tygodni przed zalogowaniem się i przetestowaniem ich kodu. Jednak ślepe stosowanie tej zasady może prowadzić do zepsucia aplikacji, której nawet nie można przetestować (widziałem to na żywo: cały zespół testowy pozostaje bezczynny przez wiele dni i nie może niczego testować , dopóki kod nie zostanie przywrócony do stanu używalności). Być może to, co napisali inni użytkownicy, ma zastosowanie w niektórych sytuacjach, ale ogólnie nie jest.
Giorgio
1
Sprawdzanie niestabilnego kodu nigdy nie jest prawidłowe. Zatwierdzenie, które łamie CI, powinno zostać cofnięte. Jeśli często popełniasz niewielkie zmiany przyrostowe, istnieje mniejsze prawdopodobieństwo wprowadzenia takiego złamania niż w przypadku dużej zmiany, która nie była testowana przez długi czas. Cofnięcie kompilacji może być również łatwiejsze do przywrócenia. Ale jak mówisz, czasami nie ma wyjścia poza destrukcyjną zmianą. Następnie z całą pewnością wypoleruj go najlepiej jak potrafisz i dokładnie przetestuj przed jego zatwierdzeniem. Nie chodzi o przestrzeganie zasad, ale zrozumienie, skąd pochodzi rada.
harald
3

Argumenty za odprawą każdego dnia:

  • Kod jest przechowywany i zabezpieczony przed awarią dysku twardego
  • Aktywność można zapisać w notatkach zatwierdzeń ( co zrobiłem w czwartek ...? )
  • Integracja z istniejącą bazą kodu odbywa się wcześniej i w mniejszych porcjach, miejmy nadzieję, że wcześniej zidentyfikujemy konflikty lub scalimy problemy
  • Twój zespół ma widoczność tego, nad czym pracowałeś
  • Twoi koledzy mogą szybciej pracować z Twoimi interfejsami, dając im więcej czasu na integrację z twoim „dużym złożonym bitem kodu”
  • Twój kod zostanie przetestowany w świecie rzeczywistym wcześniej, lub przynajmniej będzie wykorzystywany w większym stopniu, niż go dasz, co doprowadzi do wcześniejszej identyfikacji błędów lub pominięć.

Argumenty przeciwko odprawianiu każdego dnia:

  • Nie muszę lub nie chcę
  • Nie wyczyściłem jeszcze mojego kodu, to bałagan
  • Nie mam czasu

Nie sądzę, aby istniał jakiś dobry powód do odprawy mniej niż codziennie oprócz lenistwa lub dezorganizacji. Nie ma nic gorszego niż to, że kod działający w środowisku programistycznym nie pasuje do kodu w gałęzi programistycznej, ponieważ ktoś „jeszcze nie skończył”, a zatem nie zalogował się.

Chciałbym się mylić w tej sprawie, więc proszę o podanie uzasadnionego argumentu przeciwko codziennej odprawie.

Kirk Broadhurst
źródło
„Nie sądzę, aby istniał jakiś dobry powód do odprawy mniej niż codziennie oprócz lenistwa lub dezorganizacji.”: Uważam, że jest odwrotnie z dokładnie tego samego powodu. Mogę poświęcić trochę czasu na sprawdzenie aktualnego stanu kodu i zdecydować, czy zawiera on jakieś istotne informacje, które warto zapamiętać, lub, jeśli jestem leniwy i niezorganizowany, mogę po prostu to sprawdzić (i wprowadzić dodatkowe poprawki z niewielką ilością informacji treść), o ile się kompiluje.
Giorgio,
1
Rozumiem twoją tezę, że nie należy lenić się i codziennie czyścić kodu, aby można go było zaewidencjonować. Z drugiej strony, podczas pracy nad złożonym kodem jest to trudne do osiągnięcia, ponieważ czyszczenie może potrwać kilka godzin i nie możesz spędzać kilku godzin dziennie tylko na czyszczeniu kodu.
Giorgio,
@Giorgio Więc spędzasz kilka dni na czyszczeniu kodu? Dałem kilka dobrych powodów do codziennej odprawy - powodem jest to, że będziesz musiał wyczyścić kod? Wystarczy napisać czystszy kod od razu.
Kirk Broadhurst
Nie zawsze jest to możliwe, np. Jeśli tworzę od zera jakiś skomplikowany kod (> 4000 LOC), który wymaga wielu eksperymentów, aby uzyskać właściwy wynik. Jest całkiem możliwe, że pod koniec dnia kod jest nieco nieporządny i nie chcę go poprawiać, dopóki nie osiągnę spójnego stanu, który nastąpi kilka dni później. Niestety nie jestem tak mądry, że w mojej głowie skończyły się doskonałe, doskonałe formularze i zawsze mogę to wszystko zapisać w ciągu kilku godzin (tj. Pod koniec jednego dnia). Miałem ostatnio takie doświadczenie, a typowy cykl rozwoju (od jednego spójnego stanu do następnego) wynosił 2, 3 dni.
Giorgio,
@Giorgio nie masz oddziału programistycznego, w którym się zameldujesz? Kod powinien zostać wpisany, aby inne osoby mogły go również przejrzeć i przetestować.
Kirk Broadhurst
2

Jeśli masz na myśli „zatwierdzenie” jako „scalenie w linię główną”, zdecydowanie nie powinieneś robić tego codziennie w projekcie oprogramowania, który jest udostępniany klientom. Powinieneś scalać zmiany, które zostały wykonane i przetestowane, aby główna linia zawsze działała i była dostępna, a nie w stanie zepsutym z częściowo ukończonymi funkcjami.

Jednak luksus pracy z dzisiejszą rozproszoną kontrolą wersji polega na tym, że możesz zarówno utrzymać stabilność linii głównej, jak i jednocześnie to robić git/hg/whatever commit każdym razem, gdy czujesz, że chcesz zachować stan rzeczy. Robię to raz na kilka godzin i zdecydowanie pod koniec każdego dnia.

Dzięki DVCS możesz publikować swoje prace, współpracować z innymi w swoim zespole i aktualizować je o zmiany w głównej gałęzi. Możesz to wszystko zrobić bez narażania stabilności kodu, na którym polegają Twoi klienci i / lub inne zespoły.

W czasach, gdy Subversion było najnowszą technologią i nie było sposobu, aby rozwidlać i łączyć gałęzie cech bez ekstremalnego bólu, posiadanie linii głównej, w której kilka różnych funkcji było budowanych jednocześnie, mogłoby być najlepszym podejściem. Ale ta przewaga nie wykracza poza 2010 rok.

che
źródło
2

W Team Foundation Server możesz „odłożyć”, co nie jest tym samym, co odprawa, ale po prostu tworzy kopię zapasową kodu, aby w przypadku śmierci komputera nie utracić zmian.

Widziałem także domy oprogramowania, które mają „linię programistyczną” i „linię główną”. Deweloperzy mogą swobodnie zameldować się w linii programisty, kiedy tylko uznają to za stosowne, i tylko lider zespołu ma dostęp do linii głównej, więc są oni odpowiedzialni za kopiowanie kodu z dewelopera na główny, gdy jest on gotowy do produkcji.

Matt Wilko
źródło