Jakie jest kanoniczne podejście do korzystania z VCS od samego początku projektu?

9

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?

Anonimowy
źródło
Twój tytuł można zamienić na pytanie ORAZ odpowiedź: „Jakie jest kanoniczne podejście do korzystania z VCS? Już od samego początku projektu” lub rzeczywiście „Jakie jest kanoniczne podejście do korzystania z VCS? Od samego początku projektu”
AakashM
1
Tytuł był edytowany, odkąd zacząłem pytanie. Chociaż widzę, co mówisz, tak naprawdę nie jest to pytanie ani odpowiedź na pytanie, które zadałem - a przynajmniej nie w tej interpretacji.
Anonimowy
@ Anonimowy-: Przepisałem twój tytuł, ponieważ był on w formie pytania uznanego za niekonstruktywne. Mam nadzieję, że nie masz nic przeciwko, zrobiłem to, aby zapobiec wcześniejszemu zamknięciu. Przepraszam, jeśli cię to pomyliło.
haylem
@haylem - Nie ma problemu, całkowicie się z tobą zgadzam! Doceniam, że próbujesz zachować moje pytanie otwarte - na które teraz mamy ostateczną odpowiedź. :)
Anonimowy
Szybki (bardzo!) Samouczek na temat Git -> try.github.com/levels/1/challenges/1
MathAttack

Odpowiedzi:

13

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.
Haylem
źródło
Są to dobre wytyczne i podkreślam, że „nie przemyślaj tego” (oczywiście dotyczy to również przestrzegania następujących wskazówek ... :) - dotarcie tam i zrobienie tego jest najlepszym sposobem na naukę, a ludzie wkrótce dostaną dobre wyczucie, jaki styl użytkowania działa najlepiej dla nich i ich projektu.
snogglethorpe
3

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ę.

ChrisF
źródło