Git est un outil de collaboration, donc de communication. Un bon message de
commit doit donc exprimer pourquoi
les modifications contenues dans le commit
ont été faites. Quelle est ton intention en ajoutant ce commit au projet ?
Un bon message de commit va éclairer les contributeur du projet sur les raisons qui ont motivées ce commit. Par contributeurs du projet j'entend :
- les autres développeurs impliqués sur le projet
- toi même dans 6 mois
Tout le monde peut voir ce que tu as fait (le quoi) juste en lisant le code. Mais le code ne peux jamais expliquer pourquoi tu as fait ce commit.
- Writing great commit messages
- How to Write a Git Commit Message
Lis cet article avec attention, et imprime les 7 règles dans ta tête et partout où c'est nécessaire pour que chaque commit que tu écris respecte ces règles. - 5 Useful Tips For A Better Commit Message
Comme le précise cet article tu vas devoir abandonner la commandegit commit -m
pourgit commit
, puis écrire ton message de commit dans ton éditeur de texte. - Associer son éditeur de texte avec Git
Configure git pour qu'il ouvre ton editeur de texte préféré au moment d'écrire un message de commit : atom, sublime-text, vim ou même emacs
Afin de ne pas scier la branche sur laquelle tu est assis-e il faut toujours que tu soit conscient-e de la branche sur laquelle tu te trouve. Le meilleur moyen est de personnaliser le prompt de ton shell pour que cette information soit toujours visible dans ton terminal.
Oh My ZSH est un framework pour gérer la configuration du shell ZSH. C'est un ZSH est livré avec quelques plugins qui te permettrons de personnaliser ton prompt et le comportement de ton terminal.
En installant Oh My ZSH je te conseille d'activer le plugin git
qui va créer
des alias des commandes de git dans ton terminal. C'est à dire que tu pourra
taper les commandes:
gst
pourgit status
ga
pourgit add
gc
pourgit commit
gp
pourgit push
- ... voir la liste complète
- Installer Oh My ZSH
- Liste des thèmes livrés avec Oh My ZSH
Choisis en un où le nom de la branche en cours est affichée, personellement j'utilise le thème gallois - Exemple de .zshrc
Le fichier~/.zshrc
permet de personnaliser la configuration de ZSH (par exemple pour activer le plugin git). Après avoir modifié et enregistré ce fichier il faut recharger la configuration du shell, soit en ouvrant un nouveau terminal, soit avec la commandesource ~/.zshrc
dans un terminal déjà ouvert.
Parfois quand on est sur la branche de travail d'une fonctionnalité, il arrive à force de tatonnements que l'historique des commits de la branche ne veuille plus dire grand chose. Comme nous sommes des personnes bien élevées ça nous dérange de devoir pousser tous le bazar de notre chambre au milieu du salon ou nos collocs se réunissent.
* Ajoute le logo dans la navbar
* Charge la bonne image pour le logo
* Ajoute un lien vers l'accueil sur le logo
* Change l'image avec le nouveau logo
Est-ce que les contributeurs du projet ont besoin de connaitre tous les tumultes de la création d'un logo cliquable ? Peut-être qu'un résumé est suffisant :
* Ajoute le logo cliquable dans la navbar
En cliquant sur le logo le visiteur est redirigé vers l'acceuil.
Il s'agit de la version définitive du logo.
Pour garantir la paix sociale, git a anticipé ce cas de figure.
La commande magique ? git rebase -i
Swiffer n'a qu'à bien se tenir !
- Démo de Git rebase
Regarde cette démo (~5min) pour découvriregit rebase -i
en action
Quand tu commences à travailler sur une fonctionnalité et que chemin faisant tu
trouves du code qui pique les yeux mais qui n'est pas lié à la fonctionnalité
en cours et que tu décide de le refactorer quand même...
Alors tu te trouves dans une situation où des modifications non liées entre elles
se retrouvent dans le Working directory de git.
Quelles sont tes options ?
- Ajouter toutes les modifications dans l'index de git et faire un commit.
- Ajouter les modifications liées à ta fonctionnalité dans l'index et les commiter, puis ajouter les modifications liées au refactoring dans l'index et faire un deuxième commit.
Dans le premier cas c'est un peu comme si tu rangeais ton appartement avec un grand sac poubelle avant de le stocker dans un placard. Dans le deuxième cas tu ranges vraiment chaque chose à sa place sans tout mélanger.
Bien entendu la deuxième option est la bonne, surtout quand tu n'est pas le seul à vivre dans l'appartement en question.
La commande magique est git add -p
comme patch. Elle permet de sélectionner
avec précision quels sont les changements du working directory que l'on ajoute
dans l'index.
Redonne du sens à l'historique de cette branche. Garde en tête que tes messages de commits doivent raconter une histoire à celui ou celle qui les lis.
- clone ce repo sur ta machine
- clone ton fork sur ta machine
- Place toi sur la branche
pere-castor
- Créé une branche depuis
pere-castor
qui s'appelleton_pseudo_github-pere-castor
- Remet de l'ordre dans les commits ta branche
- Push ta branche sur github
- Depuis github fais une pull request de ta branche vers le master, SANS LA MERGER
Tu peux aller te promener sur les pull requests des autres pour commenter leur travail.
- Les commits de la branche ont été remodélés
- Les messages de commits ont été changés