O commitowaniu słów kilka
Zastanawialiście się kiedyś, czy istnieją standardy commitowania, korzystania z systemów kontroli wersji?
Po dokonaniu małego researchu wiem, iż takowych nie ma. Są za to tak zwane dobre praktyki 😉
Należą do nich między innymi:
- przejrzyj zmiany w kodzie zanim zrobisz commita,
- przetestuj działanie kodu po wprowadzonych przez siebie zmianach,
- w razie potrzeby poproś innego dewelopera o review proponowanych zmian,
- zrób na zmodyfikowanych przez siebie plikach – jeśli inni programiści wprowadzili zmiany nie wycofasz ich,
- opisz dokładnie zmiany jakie wprowadziłeś w kodzie – z kodu nie zawsze jasno wynika jakie zmiany zostały wprowadzone,
- commitlog – podobnie jak papier – jest cierpliwy. Oprócz precyzji opisu zadbaj również (w miarę możliwości) o odpowiednie wypunktowanie tekstu wprowadzanego do commitloga,
- dodaj nr ticketa lub rewizji do którego/której odnoszą się wprowadzane przez Ciebie zmiany, tak aby było wiadomo dlaczego/po_co/na_co zmieniasz kod,
- nie commituj nie działającego kodu,
- nie commituj kodu, którego nie rozumiesz – jeśli zajdzie potrzeba modyfikacji lub naprawy nie będziesz w stanie tego zrobić,
- nie commituj kodu, który nie jest zgodny z ustaleniami,
- dodaj nazwe funkcji/struktury którą modyfikujesz,
- w przypadku modyfikacji kilku plików/modułów wyszczególnij jakie zmiany dotyczą poszczególnych modułów,
- jeśli to możliwe – wprowadzaj jedną zmianę na raz (atomowość commitów),
- jeśli w kilku kolejnych commitach wprowadzasz zmiany afektujące na działanie całości systemu poinformuj o tym w commitlogu – dzięki temu inni nie będą szukać przyczyn chwilowych problemów z działaniem apliakcji,
- jeśli masz wprowadzić (większe) zmiany w kodzie którego nie rozumiesz – skonsultuj się z innymi programistami. W miarę możliwości z tymi, co stworzyli dany fragment kodu,
- jeśli wprowadzony przez Ciebie kod psuje działanie systemu – bierz czynny udział w znalezieniu przyczyny i wprowadzaniu poprawek