Le workflow quotidien d'un développeur Git
Résumé : un développeur qui utilise Git répète chaque jour le même cycle en quatre étapes : éditer, indexer, créer un commit, pousser. Cette leçon décrit ce cycle avec précision, et introduit les trois « zones » de Git — la notion la plus mal comprise par les débutants.
1. La journée type d'un développeur avec Git
Voici ce que fait un développeur senior, entre son café du matin et son départ le soir.
Ce workflow se répète quotidiennement dans toutes les équipes de développement modernes. Chaque étape a un rôle précis. Regardons-les de près.
2. Le cœur : la boucle éditer / indexer / commit
C'est la partie qui revient plusieurs fois par jour. Trois actions se répètent en boucle.
Un commit typique rassemble une intention cohérente : « corriger la validation du courriel », « ajouter le bouton d'export CSV », « refactoriser la fonction de paiement ». Pas dix choses différentes en même temps — un commit = une idée.
En moyenne, un développeur productif fait entre 5 et 15 commits par jour sur sa branche de travail.
3. Les trois zones de Git — la clé pour tout comprendre
C'est ici que 90 % des débutants se perdent. Git organise votre travail en trois zones distinctes, et chaque commande fait passer les fichiers de l'une à l'autre.
Chaque zone a un rôle précis :
| Zone | À quoi elle sert |
|---|---|
| Répertoire de travail | C'est là que vous éditez. Toute modification y est visible immédiatement, mais non enregistrée dans Git tant que vous n'en avez pas décidé. |
| Index / Staging area | Zone d'attente. Vous y déposez les modifications que vous voulez inclure dans le prochain commit. C'est cette zone qui permet de découper un travail en plusieurs commits propres. |
| Dépôt local | Historique permanent. Une fois qu'un commit est là, il ne disparaîtra pas (sauf action explicite). C'est là que vous pouvez remonter dans le temps. |
Analogie : préparer un colis à envoyer.
- Répertoire de travail = votre pièce en désordre, avec des objets partout.
- Index / Staging = la boîte en carton dans laquelle vous mettez ce que vous voulez envoyer.
- Commit = le moment où vous scellez la boîte, écrivez l'étiquette et notez la date.
4. Pourquoi une staging area ? Le vrai bénéfice
C'est LA fonctionnalité qui distingue Git de systèmes plus anciens comme SVN. Pourquoi ne pas commit directement les modifications ?
Voici un scénario réaliste : vous avez modifié 3 fichiers dans la matinée, mais pour deux raisons complètement différentes.
Grâce à la staging area, vous pouvez faire deux commits distincts au lieu d'un commit fourre-tout du type « modifs du matin ». Six mois plus tard, quand vous chercherez d'où vient un bug, un historique lisible vous fera gagner des heures.
C'est ce petit détail — la staging area — qui rend un projet Git bien géré infiniment plus consultable qu'un projet où tout est mélangé.
5. Anatomie d'un bon commit
Un commit contient trois éléments qui vont apparaître à jamais dans l'historique du projet :
Un bon message de commit répond à la question « pourquoi », pas « quoi ». Comparez :
| Mauvais message | Bon message |
|---|---|
| « modif » | « Corriger la validation du courriel pour accepter les adresses avec un + » |
| « update file » | « Migrer la connexion Redis vers TLS 1.3 (RGPD, ticket #4823) » |
| « fix bug » | « Empêcher le double clic sur le bouton d'achat (ticket #892, incident P2 du 14 mars) » |
Le quoi est déjà dans le diff. Le message doit expliquer le pourquoi — ce que le diff ne dit pas.
Une convention très populaire est Conventional Commits, qui préfixe le message par un type (fix:, feat:, docs:, refactor:…). Elle est enseignée en détail dans le Cours Premium Git.
6. Le push — sortir de sa bulle locale
Tant que vous n'avez pas fait git push, personne d'autre que vous ne voit vos commits. Ils vivent uniquement sur votre poste, dans votre dépôt local.
Deux règles d'or :
- Poussez souvent (au moins une fois par jour). Un push est aussi une sauvegarde — si votre disque meurt, votre travail est en sécurité sur le serveur.
- Ne poussez pas de commits sur la branche principale directement. Toujours passer par une branche de fonctionnalité + une pull request — c'est le sujet de la leçon 2.
Retenir en 30 secondes
- Un développeur Git répète chaque jour le même cycle : récupérer → brancher → éditer/indexer/commit en boucle → pousser → ouvrir une PR.
- Git organise le travail en 3 zones : répertoire de travail, staging area, dépôt local.
- La staging area est ce qui permet de découper une session de travail en commits propres et lisibles.
- Un bon message de commit explique pourquoi, pas quoi.
- Tant que vous ne faites pas
git push, votre travail reste invisible aux autres.
Suivant : Travailler en équipe : branches et pull requests →