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