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 .