Git Werkwijze

Een paar aandachtspunten bij het gebruik van Git:

• Atomic commits. Dwz commits introduceren één wijziging (verbetering/stukje nieuwe functionaliteit) tegelijkertijd. Dit maakt het terugdraaien (revert) van een commit een stuk eenvoudiger. Daarnaast helpt het bij het schrijven van een goede commit message; het is immers makkelijker één wijziging toe te lichten dan meerdere tegelijkertijd.

• Goede commit messages:

  • Korte bondige titel die omschrijft wat er is gewijzigd, voorafgegaan door het issue nummer (AB#xxxx)
  • uitgebreidere body die het waarom omschrijft:
    • toelichting op de bug die gefixed wordt, en waarom de wijziging deze fixt
    • waarom een verbetering daadwerkelijk een verbetering t.o.v. de huidig code
    • de motivatie voor de nieuw geintroduceerde feature
    • Zie ook: https://chris.beams.io/posts/git-commit/

• Clean history dmv git rebase:

  • Atomic commits impliceren het reeds, maar een commit met als een titel Review feeback zegt niets en behoort geen aparte commit te zijn. De gewijzigde code, voortkomende uit de review, moet met de oorspronkelijke commits samengevoegd worden.
    • Dit is makkelijk te doen met:
      • git add -i of git add -u (en dan selectief updates en/of patches te selecteren)
      • git commit --amend of vaker, omdat het oudere commits betreft dan de laatste, git commit --fixup <commit_id> gevolgd door een git rebase -i '<commit_id>~'
  • Dit geldt ook voor wat als een atomaire wijziging beschouwd kan worden, maar uitgesmeerd is over meerdere commits. Of voor een commit die een wijziging introduceert en later gevolgd word door een commit die het terugdraait (binnen dezelfde PR); die kunnen samen compleet verwijderd worden.
    • Dit kan makkelijk gedaan worden met een interactive rebase (git rebase -i ...)

• Op GitHub bij mergen altijd "Merge with Rebase" doen. Zodoende blijft de git history overzichtelijk (lineaire history, ipv een kronkelige warboel)

Handige ~/.gitconfig configuratie die helpen met bovenstaande werkwijze:

[rerere]
    enabled = true
[alias]
    pushf = push --force-with-lease
[pull]
    rebase = merges
[rebase]
    autoStash = true
    autoSquash = true

De pushf alias is met name handig in de context van rebases. Met rebases wijzig je de history en dus zal je een push naar de centrale repo (GitHub) met --force moeten doen. Het probleem daarvan is dat je met een --force wijzigingen van andere mensen per ongelijk kan overschrijven. Met --force-with-lease kan je allen geforceerd pushen als jij de laatste was die gepusht had. Blijkt iemand ander in de tussentijd gepusht te hebben dan zal --force-with-lease de push afbreken. Je zal dan eerst een pull moeten doen. En daarbij helpt dan weer bovenstaande configuratie voor pull die dan netjes een rebase uitvoert zodat een nette overzichtelijke lineaire history wordt behouden.