git style

Zasady dotyczące commitowania kodu za pomocą Gita

Commity

• Pierwsza linijka opisu commitu jest jego krótkim podsumowaniem. Druga powinna być pusta. Kolejne zawierają dokładniejsze wyjaśnienia, wymieniane od myślników.
• Posumowanie commitu powinno być w trybie rozkazującym.
• Każdy commit powinien być zamkniętą całością. Kod powinien być składniowo poprawny, przechodzić testy, nie powodować nowych warningów, zawierać niezbędne migracje, itp.
• Nigdy nie commitujemy do repozytorium:
  • Plików zawierających hasła lub haseł osadzonych w kodzie.
  • Konfiguracji własnego środowiska.
  • Plików binarnych (skompilowanych plików wykonywalnych, archiwów, itp.).
  • Danych produkcyjnych lub dużych zestawów danych testowych.
  • Backupów.
  • Cache'u systemu operacyjnego lub edytora (pliki typu .swp, Thumbs.db, .DS_Store)

Gałęzie

• W nazwach gałęzi używamy myślników (-), a nie podkreśleń (_).

Merge

• Unikamy merge'owania gdy nie jest to prosty fast-forward merge. Jeżeli taki merge nie jest możliwy to najpierw robimy rebase kodu na szczyt gałęzi, do której merge'ujemy kod i wtedy musi być możliwy.
• Merge'ując gałęzie używamy opcji --no-ff aby zawsze powstał commit merge'owy zawierający nazwę gałęzi.
• Po zmerge'owaniu usuwamy etykietkę zmerge'owanej gałęzi ze zdalnego repo.

Pobieranie kodu z repo

• Aktualizując kod ze zdalnego repo najlepiej używać opcji --prune (np. git fetch origin --prune) aby git automatycznie usunął z naszej kopii roboczej gałęzie, które zostały już stamtąd usunięte.
• Warto używać git fetch i osobno git merge zamiast git pull. git pull jest operacją, która modyfikuje stan bieżącej lokalnej gałęzi. Jest to użyteczny skrót, ale jeżeli nie pamiętamy zawsze która to gałąź, może w dość nieoczekiwany sposób zmerge'ować nam zupełnie niezwiązane ze sobą gałęzie. git fetch to operacja, która nigdy nie modyfikuje nam lokalnych gałęzi, dzięki czemu zawsze można ją robić "w ciemno".

Tagi i wersje

• Tagi z wersjami zaczynamy od v. Np. v0.5.1.
• Wersja zawsze powinna zawierać wszystkie trzy numery. Np. nie skracamy v1.0.0 do 1.0 lub 1.
• Staramy się stosować Semantic Versioning.
  • Wersja (bez prefiksu v) powinna być bez błędów parsowana prez pythonowy pakiet semver (semver.parse('1.2.3')).
• Tagując wersje używamy git tag --annotate.
• W opisie taga umieszczamy release notes podsumowujące zmiany dokonane od ostatniej otagowanej wersji.

Django

• Jeżeli commit zawiera migrację, jego opis powinien zaczynać się od [M] .