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