Comment bien utiliser Git
publié leVoici quelques éléments à consolider sur la façon dont on conseille d'utiliser Git ici. Il n'y a pas d'usage universel de Git, voici notre copie, à discuter bien sûr.
L'historique git n'est pas fait pour être exposé dans un musée. Il est fait pour pouvoir revenir facilement en arrière pour supprimer un changement proposé ou trouver un bug : unitaire, au maximum unitaire.
Si vous avez une idée que vous expérimentez dans le code, même si vous avez de grands doutes sur son succès, comittez-là ! Et faites ensuite un revert, avant de partir sur une meilleure idée.
Si vous voulez à la fois supprimer un import inutile dans un fichier, et apporter un ajout significatif dans un autre, n'hésitez pas à faire deux commits ! On ne vous en tiendra pas rigueur non plus si vous mutualisez un changement peu significatif avec un autre qui l'est.
Par contre, ne faites pas deux changements significatifs en un commit ! Par exemple, si un gros fichier comporte un gros bloc de JSX (Html pour react) et vous voulez à raison l'extraire dans un nouveau fichier dédié (MonSuperComposant.tsx) pour le modifier, faites-le d'abord dans un premier commit. Puis dans un deuxième, modifier le contenu cible. Comme ça le relecteur comprendra bien mieux ce que vous avez fait, étape par étape. Si l'app ne compile pas après le commit intermédiaire, c'est pas grave.
Pour les titres des commits, utilisez le ton que vous voulez, la langue que vous voulez entre l'anglais et le français. Mais soyez explicites et parlez simplement ! Nul besoin d'ajouter "feat" en en-tête : c'est ce que vous avez vraiment fait qui nous importe, pas comment vous le classez.
Si ce que vous avez fait est relativement compliqué, subtil, astucieux, documentez-le dans le code et ajouter un paragraphe au commit (saut à la ligne -> écrire un paragraphe) en plus du titre du commit.
Après votre première PR via un fork, n'hésitez pas à nous demander les droits : vous pourrez alors contribuer directement dans notre dépôt :)