Kiedy powinienem dokonać pierwszego zatwierdzenia kontroli źródła?


118

Nigdy nie jestem pewien, kiedy projekt jest wystarczająco daleko, aby najpierw zatwierdzić kontrolę źródła. Mam tendencję do odkładania zobowiązania, dopóki projekt nie będzie „kompletny w ramach” i od tego czasu głównie zatwierdzam funkcje. (Nie stworzyłem żadnych projektów osobistych na tyle dużych, aby mieć zbyt dużą strukturę podstawową.) Mam wrażenie, że nie jest to najlepsza praktyka, choć nie jestem pewien, co może pójść nie tak.

Załóżmy na przykład, że mam projekt, który składa się z jednego pliku kodu. Zajmie to około 10 linii kodu typu „kocioł” i 100 linii, aby projekt działał z niezwykle podstawową funkcjonalnością (1 lub 2 funkcje). Czy powinienem najpierw się zameldować:

  1. Pusty plik?
  2. Kod płyty grzewczej?
  3. Pierwsze funkcje?
  4. W innym momencie?

Jakie są powody odprawy w konkretnym punkcie?


10
zanim wrócisz do domu, zobowiązujesz się do założenia własnego oddziału.
Reactgular

59
Pierwszego zatwierdzenia należy zawsze dokonać po utworzeniu projektu Sourceforge, założeniu strony internetowej, skonfigurowaniu listy mailingowej i blogowaniu o projekcie przez kilka lat. :)
Kaz

15
Jaki jest minus zbyt częstego lub zbyt częstego angażowania się?
Isaac Rabinovitch

13
mkdir myproj; cd myproj; git init; zacząć pracę.
Eddie B,

10
Nauczyłem się zarządzać zapisywaniem postępów za pomocą przycisku szybkiego zapisywania w grach wideo. Zasada jest taka: Will I mind having to redo that part ? Save : SaveAnyway;używam tego samego podejścia do kontroli źródła, nie czekam, aż coś zadziała lub nie będzie prawie ukończone, po prostu czekam, aż coś wymyślę lub wprowadzę wystarczającą liczbę zmian, których nie chcę muszę spróbować to odkryć ponownie lub wprowadzić te zmiany ponownie, a następnie sprawdzam. Dlatego ludzie sugerują oszczędzanie po utworzeniu projektu; Tworzenie projektów jest denerwujące, zamelduj się, więc absolutnie nie będziesz musiał tego robić ponownie.
Jimmy Hoffa

Odpowiedzi:


103

Powinieneś popełnić, jak tylko będziesz mieć sensowną „jednostkę” ukończoną.

Co to jest jednostka? To zależy od tego, co robisz; na przykład, jeśli tworzysz projekt Visual Studio, zatwierdź rozwiązanie zaraz po jego utworzeniu, nawet jeśli nie ma w nim nic.

Odtąd kontynuuj zatwierdzanie tak często, jak to możliwe, ale nadal zatwierdzaj tylko ukończone „jednostki” (np. Klasy, konfiguracje itp.); robienie tego ułatwi ci życie, jeśli coś pójdzie nie tak (możesz cofnąć niewielki zestaw zmian) i zmniejszy prawdopodobieństwo konfliktów.


27
Cholernie blisko oddaję oddział pracy i łączę ten oddział z linią główną w jednostkach. Daje to, co najlepsze z obu światów, ponieważ linia główna składa się z jednostek z niewielkimi zestawami zmian do przywrócenia, ale gałąź tematyczna może pozwolić mi cofnąć się tylko trochę.
Jeff Ferland

16
Zatwierdzenie nigdy nie jest za małe! Nie powstrzymuj się od zatwierdzania zmian!
Leonardo Herrera

1
Powiedziałbym +1 do wielu małych, częstych zmian, w zależności od przepływu pracy i liczby osób zainteresowanych twoim repozytorium, aby wykonać swoją pracę. Zdolność Gita do ponownego napisania historii, aby te 15 zobowiązań FooSerializermogło stać się jedną rzeczą, zanim je przeforsujesz.
Tim Post

1
@loldop: To zależy od używanego oprogramowania do kontroli wersji. Powiedzmy, że używasz Gita: możesz ukryć to, co zrobiłeś, naprawić, zatwierdzić, ponownie zastosować ukryte zmiany i wznowić pracę nad nimi. W Subversion możesz zrobić kolejną kontrolę repozytorium w innym folderze, naprawić błąd i zatwierdzić tam repozytorium bez wpływu na refaktoryzację. Lub stwórz plik łatki, cofnij edycję, napraw błąd, zatwierdź, ponownie zastosuj łatkę. Można to zrobić na wiele sposobów.
Albireo,

1
Może to dobra odpowiedź na 2., 3. zatwierdzenie itd. Ale pierwsza powinna być pusta.
Felipe

143

Jeśli o mnie chodzi, twoje repozytorium kontroli źródła jest częścią podstawowej konfiguracji projektu, więc zatwierdzam zaraz po wygenerowaniu pustego projektu.


29
Popełniaj wcześnie, często popełniaj.
Leonardo Herrera

11
Zgadzam się z tym bardziej niż zaakceptowaną odpowiedzią. Widzę również kontrolę źródła (mam na myśli DVCS) jako duży przycisk cofania, jeśli po królewsku spieprzę sprawę. Gorąco polecam również używanie semver (za pomocą tagów) i rozpoczynanie od wersji 0
Antony Scott

2
Dzięki @AntonyScott Zgadzam się w 100% z zaakceptowaną odpowiedzią, ale kiedy to napisałem, miałem taką wizję zamulenia wód za pomocą eseju zawierającego 1500 słów na temat tego, jak zarządzam kontrolą źródła i dlaczego. Postanowiłem więc uprościć sprawę.
John MacIntyre

2
Tak, +1. Jeśli źle się czujesz z pustym zatwierdzeniem, zacznij od .gitignore (lub odpowiednika), jak Xion napisał w innej odpowiedzi [ programmers.stackexchange.com/a/176845/5405] . To bardzo naturalne pierwsze zatwierdzenie.
Hanno Fietz

Zauważyłem flagę „długich odpowiedzi” na pytanie i nie mogę nie myśleć, że odnosi się do tej odpowiedzi. AFAIC Odpowiedziałem „dlaczego?” pytanie z „repozytorium kontroli źródła jest częścią podstawowej konfiguracji projektu” częścią odpowiedzi. Tak jak powiedziałem, mógłbym napisać esej na temat mojej pełnej filozofii, w jaki sposób korzystam z kontroli źródła, ale to tylko pogorszyłoby tę odpowiedź. Jeśli ktoś ma jakieś pytanie dotyczące mojej odpowiedzi, chętnie odpowiem na to pytanie, ale w przeciwnym razie nie chcę puścić tej odpowiedzi ze względu na werbę. Jeśli chcesz go usunąć, śmiało.
John MacIntyre

77

Wczoraj

... alternatywnie, jeśli nie jesteś w stanie podróżować w czasie ...
(być może twój samochód nie osiąga prędkości 88 km / h lub po prostu pękł kondensator topnika)

Teraz

Nowe projekty powinny być realizowane w cholernym miejscu, to szalone, że nie, a współczesne systemy DVCS po prostu usunęły wszelkie możliwe wymówki, aby uniknąć popełnienia błędów : git init . ; git add * ; git commit -m initial-committeraz, zanim będzie za późno, jak być może już jest.

Kolejnym sensownym, dyskusyjnym pytaniem mogłoby być: „Kiedy powinienem połączyć swoje zobowiązania ze wspólną kontrolą źródła w repozytorium zarządzanym przez zespół w ustalonym projekcie?” (zwróć uwagę na przymiotniki, przymiotniki są ważne) I mam wrażenie, że większość innych odpowiedzi próbuje na nie odpowiedzieć.

Twój osobisty oddział powinien być zaangażowany w szalone , przynajmniej raz dziennie przed snem. Możesz po prostu obudzić się następnego dnia i odkryć, że nie masz pojęcia, co do diabła robiłeś poprzedniej nocy. VCS powinien cię przed tym zabezpieczyć i mieć możliwość przywrócenia do najnowszej pod-wersji-pod-wersji, która ładnie się kompiluje, działa płynnie i / lub pomyślnie przechodzi testy.


3
Nie mam nic przeciwko zatwierdzaniu zmian, które się nie kompilują, szczególnie pod koniec dnia. Następnego dnia masz coś, czego nie można skompilować, ale nadal masz swoją historię zatwierdzeń - jeśli nie chcesz, aby twoja historia była „brudna”, istnieją opcje wycofania w każdym dobrym DVCS (myślę, że wszyscy zgadzamy się, że DVCS jest jedynym sposobem na go.)
Leonardo Herrera

@LeonardoHerrera Rozumiem twój POV, chociaż w projektach z interpretowanym językiem z wieloma punktami wejścia, w końcu popełniasz niekompilującą gałąź z uzasadnionych powodów (takich jak udostępnianie poprawek błędów w innym punkcie wejścia) z pewnością można to zrobić znacznie lepiej i ładniej , ale potem staje się to kwestią gustów ... i de gustibus non est disputandum .
ZJR

20

Powiedziałbym „tak szybko”, jak to możliwe. Głównym celem kontroli źródła jest umożliwienie cofnięcia się na wypadek, gdyby coś poszło nie tak, a to rezonuje z ćwiczeniem „wcześnie i często”.

Osobiście moje pierwsze zatwierdzenie zazwyczaj zawiera tylko plik .gitignore (lub równoważny) z kilkoma filtrami, o których wiem, że będą potrzebne, jak * .py [co] dla kodu Pythona. Zwykle następuje podstawowa konfiguracja projektu i / lub pierwszy najprostszy prototyp.


Robię coś podobnego. Ponieważ używam GitHub, zawsze mam również podstawowy plik README, nawet jeśli zawiera on tylko nazwę projektu. Uważam, że posiadanie tam pliku od samego początku zwiększa prawdopodobieństwo, że zaktualizuję go w przyszłości :).
Tikhon Jelvis

16

Pierwszym zatwierdzeniem może być plik README zawierający zaledwie jeden wiersz podsumowania projektu lub wystarczającą ilość informacji o pierwszym etapie projektu. Ogólne tematy mogą również obejmować:

  • Wprowadzenie
  • Opis Projektu
  • Struktura projektu
  • Konwencje kodowania
  • Instrukcje, jak:
    • budować
    • test
    • rozmieścić
  • Znane problemy i obejścia
  • Lista rzeczy do zrobienia
  • Warunki korzystania

Praktyka aktualizowania pliku README przed wprowadzeniem zmian w projekcie jest również nazywana opracowaniem opartym na Readme i pozwala na przemyślenie zmian przed zainwestowaniem czasu w ich wprowadzenie.

Każdy, kto chce uczestniczyć w tworzeniu tego oprogramowania lub korzystać z niego, rozpocznie program README.


12

Jeśli wykonałeś pracę, której nie chciałbyś stracić, powinna ona znajdować się w systemie kontroli źródła.

Z pewnością dotyczy to rozproszonych systemów, takich jak Git. Jeśli używasz scentralizowany system, a jedynym sposobem, aby sprawdzić coś jest, aby był on widoczny dla wszystkich , to może chcieć trzymać się - lub może rozważa stworzenie własnego lokalnego repozytorium git, i przedkładanie scentralizowana system, gdy będziesz gotowy.


3
Moja reguła jest taka, z tym, że chcę, aby był to także „punkt w czasie, w którym kod się kompiluje”. Zaangażowanie się w to, co się nie kompiluje i nie dzieli, staje się o wiele bardziej irytujące, jeśli kiedykolwiek będziesz musiał znaleźć, kiedy coś złamiesz.
Warren P

Czy tymczasowy oddział nie adresowałby tego, przynajmniej dla git? Nie używałem git bisectdużo.
Keith Thompson

Używam rtęci bez bazy, więc wszystkie zatwierdzenia traktuję jako stałe
Warren P

7

Moją ogólną zasadą jest rejestrowanie się po zakończeniu pliku rozwiązania (lub innego skryptu kompilacji), nawet jeśli zawiera on kilka plików, które są puste. Jest to dobra praktyka, gdy nad projektem pracuje więcej niż jedna osoba. Plik ten ma początkowo najgorsze problemy z łączeniem, ponieważ ludzie dodają elementy do projektu, więc potrzeby są podejmowane wcześnie i często.

Nawet jeśli jesteś jedynym, który pracuje nad projektem i ma tylko jeden plik, łatwiej mi jest postępować zgodnie z tym samym tokiem pracy i zapisać myślenie o danym problemie.


6

Nie jestem pewien, czy zostało to wspomniane.

Ale upewnij się, że to, co popełniasz, działa / kompiluje! Więc nie ma błędów składniowych itp.

Nie ma nic bardziej frustrującego niż złamanie kodu kasy.


rzeczywiście ma sens!
Aquarius_Girl

Nie zgadzam się. Jeśli mój kod nie kompiluje się, gdy chcę zatwierdzić, zapisuję WIP gdzieś w komunikacie zatwierdzenia. Następnie mogę po prostu zignorować te zatwierdzenia, gdy potrzebuję najnowszej wersji, która się kompiluje.
Minthos,

5

Innym punktem widzenia, bardziej związanym z testowaniem oprogramowania (podejście TDD), byłoby zatwierdzenie, jak tylko pojawią się nowe przypadki testów w kolorze zielonym. Oznaczałoby to, że masz ukończoną nową „jednostkę” kodu.


Aby objąć metodę, możesz (przeważnie) potrzebować kilku testów jednostkowych. Nie jest prawdą stwierdzenie, że jeśli zdasz test, oznacza to, że ukończyłeś jednostkę pracy. Nie jest nawet prawdą stwierdzenie, że ukończenie tej metody to także praca.
Behnam Rasooli

5

Tuż przed zrobieniem czegoś głupiego.

Dla tych z nas, którzy nie mają magicznych mocy, oznacza to niewiele i często.

Jeśli pracujesz sam, rób to za każdym razem, gdy dostaniesz drinka lub cokolwiek innego.

Jeśli pracujesz w zespole, prawdopodobnie musisz się upewnić, że coś się kompiluje, aby jeśli ktoś dostał najnowszą wersję, nie dostałby woreczka błędów. Ale poza tym, o ile możesz.


4

Około 2 ~ 3 godziny od rozpoczęcia projektu.

Tylko żartuję. Nie ma jednej dobrej odpowiedzi, która pasowałaby do wszystkich sytuacji. Przede wszystkim, jeśli masz rozproszony system kontroli wersji (taki jak git lub Mercurial), wówczas zatwierdzenie do lokalnego repozytorium nie zachowa twoich danych w przypadku katastrofalnej awarii. Ale prywatne zdalne repo może kosztować pieniądze, np. Na github. Zachowasz historię zatwierdzeń, ale z mojego doświadczenia nie będziesz jej potrzebować, dopóki twój projekt nie będzie trochę zaawansowany.

Prawdopodobnie nie chcesz zbyt wiele rezygnacji na początku, zwłaszcza jeśli przenosisz pliki. Wprowadzanie zmian będzie ciężarem, jeśli tylko małym. Możesz nawet zdecydować się wyrzucić. Ale jeśli stracisz zmiany, które nie są łatwe do replikacji, stracisz możliwość wykonania kopii zapasowej, a systemy kontroli wersji stworzą niezwykle cenne systemy kopii zapasowych.

Niektóre osoby używają obecnie DropBox lub podobnego do przechowywania swojego kodu. Może to być dobry kompromis na początku projektu, ponieważ konfiguracja nie wymaga żadnego wysiłku. Jest to jednak barbarzyński nawyk w poważnym tworzeniu oprogramowania, zwłaszcza jeśli kilka osób jednocześnie dotyka kodu.

Tak więc mam tendencję do konfigurowania kontroli wersji, gdy tylko mam coś cennego, tj. Nie jest trywialne do replikacji. Wartość jest subiektywna (i zależy od naszych zdolności), więc będziesz musiał dokonać własnej oceny. W tym momencie przechowuję drugie repo na dysku zewnętrznym lub na github, jeśli jest to projekt publiczny lub moje konto płatnicze je przechowuje.


3

Wiele osób już odpowiedziało „od razu”, a ja w 100% zgadzam się. Podoba mi się również sugestia Xiona, aby zacząć od wzorców ignorowania VCS (tj. .gitignoreLub równoważnych).

Wydaje mi się, że w zasadzie zgodzono się, że nie ma wad wcześniejszych zobowiązań. Chciałbym dodać strony pozytywne:

  • Rzadziej popełniasz rzeczy, które zdecydowałeś się odrzucić, ale to wciąż trwa. Kiedy zaczynam nowy program, będę szybko kodować i dyskredytować rzeczy, a kiedy popełniłem później, gdy jest już kilka plików, przypadkowo popełniłem rzeczy tylko po to, aby usunąć je przy następnym zatwierdzeniu. To, w przeciwieństwie do małych, a nawet pustych, zobowiązań, jest prawdziwym hałasem w historii.
  • Jeśli jesteś typowym typem i masz typowe pierwsze kroki w swoich projektach, posiadanie ich jako punktów zatwierdzenia może być pouczające dla ciebie lub innych, a może nawet stanowić okazję do rozgałęzienia się w pewnym momencie i utworzenia odcinka projektu wielokrotnego użytku. Pracowałem nad projektami opartymi na Maven, w których było to przydatne (ponieważ przy konfigurowaniu projektu Maven, niektóre małe pierwsze kroki mogą już zdefiniować całkiem pokaźną bazę, i chociaż te kroki nie są zbyt wiele do zrobienia , mogą wymagać wystarczającego myślenia, aby uzasadnić wielokrotnego użytku).

2

Może to zależeć od używanego VCS.

Za pomocą Git zatwierdzam pusty katalog (lub prawie pusty plik README). Chodzi o to, że mogę wrócić i zresetować gałąź do tego stanu pustego, jeśli chcę całkowicie zacząć od nowa, póki jestem jeszcze na wczesnym etapie procesu programowania (przed wypchnięciem w górę). Następnie zatwierdziłbym swoje „wygenerowane” pliki (np. Rozwiązanie Visual Studio). Potem, kiedy faktycznie koduję, zacznę zatwierdzać każdą jednostkę tak jak zwykle.

Dzięki SVN, przyspieszasz z każdym zatwierdzeniem, więc naprawdę nie masz luksusu, aby zacząć od nowa, tak jak w przypadku Git. W takim przypadku wczesne zatwierdzenie może nie być korzystne, jeśli podejrzewasz, że przeprowadzisz poważną modernizację na wczesnym etapie. To zależy od osoby kodującej.


2

Kiedy rozpoczynam nowy projekt, zwykle zaczynam od zatwierdzenia go przed dodaniem jakiegokolwiek kodu. Ogólna zasada, którą zawsze stosowałem, to: jeśli Twój komputer ulegnie awarii i wyczyści wszystkie twoje dane, jakiego kodu wolałbyś nie pisać z pamięci. Dziesięć lat temu przed TDD i lepszą praktyką programowania byłem optymistą co do tego, co pamiętam. Teraz jestem bardziej ostrożny. Jak wiele innych plakatów mówiło „wcześnie” i „często”. Robiąc to, nic nie tracisz.

Przez większość czasu pracuję na własną rękę, więc muszę wyznać, że się rozluźniam, ale zazwyczaj zobowiązuję się, zanim pójdę do domu. W ten sposób, jeśli nie zdążę jutro, moi koledzy mogą zacząć od miejsca, w którym skończyłem.

Obecnie używam Tortoise / SVN w pracy.


2

Natychmiast rozpocznij pusty projekt. Kontynuuj zaangażowanie kilka razy na godzinę, spędzając pracę nad projektem. Zatwierdź, nawet jeśli kod się nie skompiluje. Takie zatwierdzenia zaznaczam „WIP” w masażu zatwierdzania, aby je śledzić.

Mam również skrypt, który co 10 minut automatycznie zatwierdza wszystkie moje projekty w repozytorium kopii zapasowych, na wypadek, gdyby zapomniałem ręcznie zatwierdzić. Nazwijmy to moim cofniętym buforem.

Przyjazd (aka. Pchnąć ) projektu do repo zespołu, kiedy trzeba swój zespół, aby zobaczyć swój kod. Który jest prawdopodobnie zanim twój kod będzie gotowy do zobaczenia przez twój zespół, jeśli jesteś podobny do mnie.

Jeśli chcesz być miły dla swojego zespołu, zmiażdż swoje zobowiązania przed przekazaniem ich do repozytorium zespołu.


1

Przejrzałem wszystkie artykuły i myślę, że mamy już wiele dobrych rozwiązań, ale chciałbym podzielić się z Wami moją metodologią.

Podczas pracy nad tworzeniem frameworka (od zera) wiele zmian będzie miało miejsce dla każdego modułu, dopóki moduł nie zostanie ukończony lub sfinalizowany. Więc zawsze mam 2 lokalizacje, jedna z nich ma nazwę DYNAMIC, a druga jest STATYCZNA. Kiedy trwają zmiany, a framework nie jest jeszcze sfinalizowany, zostaje on zatwierdzony w lokalizacji DYANMIC, a po jego zakończeniu i finalizacji przenoszę go do lokalizacji STATIC. Mam więc pełną kontrolę źródła.

Dzięki


0

Przy każdej aplikacji poświęcisz trochę czasu na zaprojektowanie komponentów. Powinieneś znać z grubsza lub szczegółowo swoje przestrzenie nazw, projekty, referencje zewnętrzne, biblioteki stron trzecich itp.

Jeśli pracujesz w zespole, sugerowałbym, abyś poprowadził, lub kogokolwiek innego, do utworzenia projektu podstawowego, ustawienia zależności i sprawdzenia szkieletu (podstawy, na której zostanie zbudowany Twój projekt).

Chcesz również upewnić się, że masz wyspecyfikowane gałęzie zadania, wydania, pnia itp. Przed zalogowaniem, aby proces był solidny.

Jeśli pracujesz nad nowym „zadaniem” dla projektu, który jest już w toku i jesteś we własnym oddziale zadań, rób nocne zameldowania, aby zachować swoją pracę.


0

Zwykle melduję się za każdym razem, gdy dodam coś nowego, ale próbuję rozdzielić rzeczy w dyskretnych zatwierdzeniach.

Oznacza to, że jeśli dodam nową zależność, wprowadzam zmiany, dopóki albo się nie skompilują, albo będą wystarczająco duże, aby stracić czas na zrobienie ich od nowa. Jeśli mam większe zadanie, próbuję popełnić wiele razy, gdy ma to sens (raz na funkcję, za każdym razem, gdy kompiluję ją i uruchamiam pomyślnie itp.).

Zgadzam się również, gdy chcę punktu zapasowego (tzn. „Jeśli to, co próbuję teraz, nie zadziała lub stanie się zbyt skomplikowane, chcę wrócić do kodu w obecnej postaci” lub gdy ktoś poprosi mnie o usunięcie tego, kim jestem zrobienie i naprawienie pilnego problemu).

Jeśli korzystasz ze scentralizowanego systemu kontroli źródła, nie możesz arbitralnie zatwierdzać punktów kopii zapasowej, ponieważ zatwierdzenie, które nie kompiluje / nie działa, wpływa na wszystkich w zespole.

Zwykle, kiedy zaczynam dodawać nowy kod (np. Dodawać nową aplikację internetową na stronie django), zatwierdzam każdą wykonywaną operację.

Jeśli postępuję zgodnie z samouczkiem, aby wygenerować / napisać kod, używam nazw kroków w samouczku do komunikatów zatwierdzania. W ten sposób mogę różnicować wersje i zobaczyć, co zrobił krok samouczka, w dowolnym późniejszym momencie.

Załóżmy na przykład, że mam projekt, który składa się z jednego pliku kodu. Zajmie to około 10 linii kodu typu „kocioł” i 100 linii, aby projekt działał z niezwykle podstawową funkcjonalnością (1 lub 2 funkcje).

Zależy to od tego, jak trudne jest dodanie rzeczy:

  • jeśli dodanie kodu płyty kotłowej byłoby trywialne, dodałbym go i zatwierdziłem tuż przed uruchomieniem drugiego kodu (w ten sposób, jeśli popełniam błąd lub wprowadzę dziwny błąd później, mogę po prostu wrócić do kodu płyty kotłowej i uruchomić jeszcze raz).

  • Gdyby kod nie był trywialny, zatwierdzałbym za każdym razem, gdy dodawałem coś nowego (gdziekolwiek między każdymi dwiema zmienionymi liniami kodu, do setki).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.