tło

W gitprzeszłości korzystałem z VCS (głównie ) do zarządzania wieloma istniejącymi projektami i działa to świetnie. Zazwyczaj w przypadku istniejącego projektu sprawdzałbym każdą wprowadzoną przeze mnie zmianę w kodzie, który albo optymalizuje, albo zmienia ogólną funkcjonalność (wiesz, co mam na myśli, w odpowiednich krokach, nie w każdej linii, którą zmieniam).

Problem

Jedną z rzeczy, na których nie miałem tyle praktyki, jest tworzenie nowych projektów. Jestem w trakcie uruchamiania nowego projektu, który prawdopodobnie będzie dość duży, ale odkrywam, że jest wiele do zrobienia i wiele się zmienia w ciągu pierwszych kilku dni / godzin / tygodni / okresu w górę dopóki produkt nie zacznie działać w najbardziej podstawowej formie.

Czy ma sens sprawdzanie na każdym etapie procesu, tak jak w przypadku istniejącego projektu? Nie przerywam projektu zmianami, które wprowadzam, ponieważ jeszcze nie działają. W tej chwili po prostu używam VCS jako kopii zapasowej na koniec każdego dnia, kiedy wychodzę z komputera.

Moje pierwsze zatwierdzenia były takie jak „Podstawowa struktura katalogów na miejscu” i „Utworzono tabele DB”. Jak korzystać z VCS przy rozpoczynaniu nowego projektu?

Zacznij prosty

git init

Wczesne zameldowanie, często meldowanie

Po prostu rób to, co zwykle robisz z każdym projektem: „melduj się” dla każdego zestawu zmian, które odnoszą się do określonego zadania lub grupy działań. Jeśli korzystasz z narzędzia do śledzenia problemów, zatwierdzaj zmiany związane z zadaniem za każdym razem, gdy jest ono w stanie stabilnym (zobacz to SO pytanie, jak często należy zatwierdzać ). Może nie być w stanie ukończenia, tylko stabilny, w którym oprogramowanie nie uruchamia się lub witryna nie jest renderowana. Jak mówi Jeff Atwood w swoim poście:

Jeśli kod nie jest wpisany do kontroli źródła, nie istnieje. [...]

Nie proponuję programistom sprawdzania uszkodzonego kodu - ale argumentuję również, że istnieje duża różnica między uszkodzonym kodem a niekompletnym kodem.

Popełniaj często, doskonale później, opublikuj raz

Jeśli produkt nie jest nawet w stanie funkcjonalnym, po prostu sprawdzaj zmiany według własnego uznania, zachowując rozsądek i zdrowy rozsądek, aby je zgrupować. Nie musisz zatwierdzać zmiany wiersza każdego pliku jeden po drugim, ale zatwierdzenie wszystkiego jako dużego fragmentu utrudni Ci przywrócenie w razie potrzeby.

W końcu twój VCS jest tutaj, aby ci pomóc . Pomóż więc VCS, aby Ci pomógł !!

Nie przemyśl tego

Twoje pierwsze zobowiązania były w porządku. Nie przemyśl tego. Najważniejsze, że są odprawieni. Jeśli spojrzysz na wszystkie istniejące projekty online typu open source, które rozpoczęły się od zera, a nie z istniejącej bazy kodu, mają one jako pierwszą wersję coś podobnego do:

utworzył strukturę katalogów (tak!)

Zrób z tego nawyk

Na koniec każdego dnia spróbuj wygenerować dziennik tego, co zrobiłeś na podstawie dzienników zatwierdzeń. Jeśli wyniki, które otrzymujesz git shortlogi git logNIE wydają się satysfakcjonujące i użyteczne , a mimo to włożyłeś dużo wysiłku w projekt w ciągu dnia i sprawdziłeś te zmiany, prawdopodobnie nie zrobiłeś tego dobrze .

• git shortlognależy czytać jak ogólny przegląd tego, co zrobiłeś.
• git logpowinien czytać jak historia ORAZ historia twojego projektu.

To, co robisz, to właściwe podejście.

Korzystasz z kontroli źródła od pierwszego dnia - zapewni to, że masz wszystko, czego potrzebujesz w kontroli źródła i nie ma sensu mówić:

Powinienem używać kontroli źródła, ale sprawdzenie wszystkich tych rzeczy po raz pierwszy potrwa zbyt długo.

Jest to główna przeszkoda dla osób spóźniających się na kontrolę źródła, ponieważ uważają, że korzystanie z niej jest „zbyt trudne”. Rozpoczynając wcześnie i zatwierdzając zmiany, często ograniczyłeś tę przeszkodę do małego kroku, a każdy, kto dołączy do ciebie w projekcie, będzie mógł od razu zacząć pracę.