Ceci est un travail-en-cours.

Pour le français, appuyez sur le 2 ⸨fr⸩

Du code, un document écrit, ce sont des outils de communication avant tout: c'est pour communiquer aux développeuses, lecteurs ce qu'on fait.

Un historique Git est la même chose. C'est avant tout un outil qui communique ce qui a changé, et comment.

L'historique Git doit être délibéré. Pas accidentel, ni de scruter les moindres erreurs.

Quand on l'utilise à son plein potentiel, c'est un outil puissant qui nous permet de:

• voir, comprendre quels changements ont été faits quand
• obtenir la version de l'application à n'importe quel stade de son évolution
  • avant ou après tel changement précis
• savoir exactement quand l'application a brisé
  • ou a échoué tel test, même s'il n'était pas écrit encore
  • même automatiquement!
• créer des versions avec certains changements, mais sans certains autres

Mais pour ça, il faut avoir la discipline de créer un historique clair et sémantique.

Commits: Atomiques, sémantiques, descriptifs

→ Les commits identifient les liens de dépendance entre les changements.

Pas de lien de dépendance = commits séparés

Changement A dépend de chg B → Commit B, Commit A

A fonctionne si et seulement si B → Commit (AB)

En théorie, chaque commit présente une nouvelle révision de l'application qui fonctionne, qui passe les tests, qui est améliorée par rapport à la précédente. (On dévie parfois de cette règle)