Votre développeur vous parle de branches, de commits, de merges, de pull requests.
Vous hochez la tête.
Vous n'avez pas tout compris — mais vous n'osez pas demander, parce que ça semble être la base.
Ça l'est. Et ça mérite une explication claire.
Le problème que Git résout
Imaginez que vous écrivez un document important. Vous sauvegardez. Vous continuez. Vous faites une erreur majeure. Vous voulez revenir en arrière — mais vous avez sauvegardé par-dessus.
Vous avez perdu.
Maintenant imaginez une équipe de cinq personnes qui modifient le même document en même temps. L'une écrit l'introduction. Une autre réécrit la conclusion. Une troisième change le titre. Elles travaillent depuis des ordinateurs différents, à des heures différentes.
Comment assemblez-vous tout ça sans perdre le travail de personne ?
Ce sont les deux problèmes que Git résout : l'historique complet de chaque changement, et la collaboration sans collision.
Git n'est pas un outil de sauvegarde. C'est un système de gestion de l'historique d'un projet — avec une précision chirurgicale sur qui a changé quoi, quand, et pourquoi.
Concept 1 — Le dépôt
Un dépôt Git (repository, ou *repo*) est un dossier ordinaire — avec un historique complet caché à l'intérieur.
Quand un développeur initialise Git dans un projet, un sous-dossier invisible `.git` est créé. C'est là que Git stocke tout : chaque version de chaque fichier, chaque message de changement, chaque branche, chaque auteur.
Votre projet en ce moment peut peser 50 MB. Son historique Git peut en contenir dix fois plus — chaque état passé, intact et récupérable.
Un dépôt peut être local (sur l'ordinateur du développeur) ou distant (sur un serveur comme GitHub, GitLab, ou Bitbucket). En pratique, les deux coexistent : les développeurs travaillent localement, puis synchronisent avec le dépôt distant partagé.
Ce que ça change pour vous : Si votre développeur dit "je pousse sur GitHub", il synchronise son travail local vers le dépôt distant. Le code est maintenant sauvegardé et accessible à l'équipe.
Concept 2 — Le commit
Un commit est une photo instantanée du projet à un moment précis.
Pas une sauvegarde automatique. Une décision consciente : *ce travail est cohérent, documenté, et prêt à être enregistré dans l'historique.*
Chaque commit contient trois choses : - L'état exact de tous les fichiers modifiés - L'identité de l'auteur et l'horodatage - Un message qui explique *pourquoi* ce changement a été fait
``` commit a3f8c2d Auteur : Jean-Marc Perron Date : 2026-07-08 14:23
ajoute validation du formulaire de contact ```
L'historique d'un projet ressemble à une ligne du temps de commits. Chaque point sur la ligne est un état stable et documenté du code.
C'est pourquoi le message de commit compte. "Fix stuff" n'aide personne. "Corrige la validation du courriel sur mobile" aide énormément — six mois plus tard, quand quelqu'un essaie de comprendre ce qui a changé.
Ce que ça change pour vous : Un bon développeur fait des commits réguliers avec des messages clairs. Si vous voyez des commits espacés de plusieurs jours avec des messages vagues, c'est un signal de qualité de processus.
Concept 3 — La branche
Une branche est une ligne de développement parallèle et indépendante.
Visualisez-le ainsi : votre projet est un arbre. Le tronc — qu'on appelle `main` ou `master` — c'est la version stable en production. Ce que vos utilisateurs voient.
Quand un développeur veut ajouter une fonctionnalité, il ne touche pas au tronc directement. Il crée une branche — une copie divergente sur laquelle il travaille isolément.
``` main ─────────────────────────────────────► │ └── feature/panier-achat ──► ```
Sur cette branche, il peut expérimenter, casser des choses, tester, recommencer. Le tronc ne bouge pas. La version en production reste intacte.
Quand le travail est terminé et validé, la branche est fusionnée (mergée) dans `main`.
Les équipes sérieuses maintiennent souvent plusieurs branches en parallèle : une pour chaque fonctionnalité en développement, une pour les corrections de bugs urgents, une pour les tests.
Ce que ça change pour vous : Quand votre développeur dit "je travaille sur une branche", il développe en isolation. Votre site en production n'est pas touché. C'est une bonne pratique — pas une complication.
Concept 4 — Le merge et les conflits
Fusionner deux branches, c'est demander à Git de combiner deux historiques divergents en un seul.
La plupart du temps, Git y arrive seul. Les deux branches ont modifié des fichiers différents — pas de collision. Git assemble, enregistre, continue.
Mais parfois, deux développeurs ont modifié les mêmes lignes du même fichier différemment. Git s'arrête et dit : *je ne peux pas décider lequel a raison. À vous de trancher.*
C'est un conflit.
``` <<<<<<< votre-branche Prix : 49,99 $ ======= Prix : 44,99 $ >>>>>>> branche-collègue ```
Git présente les deux versions côte à côte. Un humain choisit. Le conflit est résolu manuellement, le merge continue.
Les conflits ne sont pas des erreurs — ils sont la conséquence normale de la collaboration sur les mêmes fichiers. Une équipe bien organisée les minimise avec des conventions claires sur qui touche à quoi.
Ce que ça change pour vous : Si votre développeur dit "il y a des conflits à résoudre", c'est du travail manuel normal, pas un problème grave. Ça prend habituellement quelques minutes.
Concept 5 — La pull request
Une pull request (PR) — ou merge request selon la plateforme — est une proposition formelle de fusionner une branche dans une autre.
Mais c'est surtout un mécanisme de révision.
Quand un développeur ouvre une PR, il ne fusionne pas encore. Il dit à l'équipe : *voici ce que j'ai fait, voici pourquoi, est-ce que quelqu'un peut vérifier avant que ça entre dans main ?*
La PR devient un espace de discussion : - L'équipe lit le code ligne par ligne - Elle pose des questions, suggère des améliorations - Elle signale les bugs potentiels avant qu'ils atteignent la production - Elle approuve quand tout est satisfaisant
Seulement alors, la branche est fusionnée.
C'est la porte de qualité entre le travail individuel et le code partagé. Les équipes qui skippent les PRs et mergent directement dans main accumulent de la dette technique et des bugs silencieux.
Ce que ça change pour vous : GitHub et GitLab vous permettent de lire les PRs de votre équipe sans être développeur. Vous pouvez voir exactement ce qui change dans votre projet, avec des commentaires contextuels. C'est de la transparence totale sur le travail en cours.
La séquence complète en pratique
Voici ce que fait un développeur pour ajouter une fonctionnalité :
1. Il crée une branche depuis `main` ``` git checkout -b feature/filtre-produits ```
2. Il développe, teste, fait des commits réguliers ``` git commit -m "ajoute filtre par catégorie" git commit -m "ajoute filtre par prix" git commit -m "corrige affichage mobile du filtre" ```
3. Il pousse sa branche vers le dépôt distant ``` git push origin feature/filtre-produits ```
4. Il ouvre une pull request sur GitHub
5. L'équipe révise, commente, approuve
6. La branche est fusionnée dans `main`
7. Le déploiement en production est déclenché (souvent automatiquement)
De l'idée au code en production — traçable, documenté, réversible à chaque étape.
Pourquoi c'est irréversible — dans le bon sens
L'une des propriétés les plus puissantes de Git : vous pouvez revenir à n'importe quel commit dans l'historique.
Une mise à jour casse quelque chose en production ? Vous revenez au commit précédent en 30 secondes. Le problème est corrigé pendant que l'équipe diagnostique à tête reposée.
Cette capacité de rollback instantané change fondamentalement la relation au risque dans le développement. On déploie plus souvent, parce que revenir en arrière est simple. On expérimente plus, parce que rien n'est définitif.
Une équipe sans Git déploie avec peur. Une équipe avec Git déploie avec confiance.
Ce que vous devriez retenir
Git n'est pas un outil de développeur obscur. C'est l'infrastructure de collaboration sur laquelle repose tout le développement logiciel moderne — de la startup d'un développeur aux équipes de milliers d'ingénieurs chez Google ou Microsoft.
Si vous travaillez avec des développeurs, comprendre Git vous donne une visibilité réelle sur leur travail. Vous pouvez lire l'historique, suivre les branches actives, comprendre pourquoi un changement a été fait.
Cinq concepts. Le reste n'est que détails.
Dépôt — le projet et tout son historique. Commit — une photo documentée d'un état stable. Branche — une ligne de développement isolée et parallèle. Merge — la fusion de deux branches en une. Pull request — la révision formelle avant la fusion.
Voilà. Vous comprenez Git.
