00 - Au-dela de add, commit, push
Ce que tu vas apprendre
- Les commandes git que 90% des devs ne connaissent pas
- Ce que cette serie couvre et pourquoi ca va te sauver la mise
- Une anecdote sur un force push qui a mal tourne
Prerequisites
Savoir utiliser git add, git commit, git push. Le reste, on le construit ensemble.
Le kit de survie que tout le monde connaît
Si tu bosses avec git depuis quelques mois, tu connais probablement ces commandes par coeur :
bashgit clone https://gitlab.com/monprojet/app.git
git add .
git commit -m "fix truc"
git push
git pull
C'est le minimum vital. Ca fonctionne. Tu peux livrer du code en prod avec ca. Et pendant un moment, ca suffit. Tu créés des branches avec git checkout -b, tu fais tes commits, tu push, tu ouvres une merge request sur GitLab, quelqu'un approuve, tu merge. La vie est belle.
Puis un jour, ca derape.
Quand le minimum ne suffit plus
Le premier signal, c'est l'historique. Tu ouvres git log et tu vois un enchaînement de "Merge branch 'main' into feature/machin" tous les trois commits. Tes deux juniors font git pull (qui fait un merge par défaut) au lieu de git pull --rebase. Le graphe ressemble a un plat de spaghetti. Impossible de comprendre qui a fait quoi et quand.
Le deuxieme signal, c'est le stash oublie. Un collegue te dit "j'avais stash un truc important la semaine dernière, mais je sais plus lequel c'est". Il fait git stash list, voit huit entrees cryptiques du genre stash@{3}: WIP on feature/search: 3a2b1c0, et abandonne.
Le troisieme signal, c'est la panique face aux conflits. "J'ai des conflits, je fais quoi ?" devient une question quotidienne sur Slack. Parfois suivi de "j'ai fait git checkout --theirs . sur tout le projet". Adieu les modifications de l'équipe.
L'anecdote du force push
Il y a six mois, un de mes juniors a voulu "nettoyer" l'historique de main. Son intention etait bonne. Il a fait un git rebase -i sur main pour squasher des commits qu'il trouvait inutiles. Puis un git push --force sur main parce que le push classique refusait (évidemment). Trois jours de travail de l'équipe, partis. Les merge requests en cours pointaient vers des commits qui n'existaient plus.
J'ai passe 20 minutes a transpirer devant mon terminal avant de me souvenir d'une commande que je n'avais utilisee qu'une fois : git reflog. Le reflog garde une trace de tous les mouvements de HEAD pendant 90 jours. J'ai retrouve le commit d'avant le rebase, fait un git reset --hard dessus, puis un git push --force (ironiquement) pour restaurer le tout.
Tout etait la. Rien n'etait vraiment perdu. Mais ca m'a pousse a écrire une regle dans notre wiki interne en gras et en rouge : interdit de force push sur main. Et a protéger la branche dans les settings GitLab.
Ce que cette serie couvre
On va explorer les commandes et workflows git qui font la différence entre "je sais utiliser git" et "je maîtrise git". Voici le programme :
- Branching stratégies : quel workflow choisir (GitFlow, GitHub Flow, trunk-based)
- Rebase vs merge : comprendre la différence et savoir quand utiliser quoi
- Conventional commits : des messages structures et des changelogs automatiques
- Stash, cherry-pick, bisect : les outils de chirurgie au quotidien
- Résoudre les conflits : sans paniquer, avec méthode
- Git hooks : automatiser le linting et la validation avant chaque commit
- Reflog et recovery : rien n'est jamais perdu dans git
- Glossaire : tous les termes en un seul endroit
Chaque article contient des commandes que tu peux lancer immédiatement dans ton terminal. Pas de theorie abstraite, que du concret. Si tu utilises GitLab (comme moi) ou GitHub, ca s'applique pareil.
A qui s'adresse cette serie
A toi si tu fais git add . && git commit -m "fix" && git push en boucle et que tu sens qu'il y a mieux. A tes juniors que tu formes et qui ont peur des conflits. A quiconque a deja perdu du temps a cause d'un historique illisible.
Si tu deploies deja via GitLab CI, cette serie est le complement parfait : un bon workflow git, c'est la base d'une CI/CD qui tourne.
Article suivant : 01 - Branching stratégies : choisir son workflow