Git et GitHub

Comment ça marche

Git garde l’historique d’un dossier : à chaque fois qu’on enregistre, un commit, il photographie l’état des fichiers, avec un message qui dit ce qui a changé et pourquoi. On peut ensuite relire l’historique, voir exactement ce qui a été modifié entre deux états, et revenir à n’importe quel point. Les branches permettent d’essayer quelque chose à côté sans toucher à la version principale.

Avec un agent qui écrit dans vos fichiers, Git change de statut : il devient le filet de sécurité. Chaque intervention de l’agent se relit ligne par ligne avant d’être acceptée. Une modification malheureuse s’annule en une commande. GitHub ajoute le partage avec l’équipe, les demandes de modification à relire (pull requests), et des automatisations qui lancent les tests à chaque changement. Sans Git, travailler avec un agent, c’est travailler sans annuler.

Un exemple concret

1. La tâche : un agent doit harmoniser le vocabulaire dans 80 fiches de procédures en Markdown, rangées dans un dossier sous Git.
2. Le résultat : l’agent annonce 80 fichiers modifiés. Le responsable regarde les différences : dans 12 fiches, l’agent a aussi « simplifié » des paragraphes, supprimant des précisions réglementaires.
3. Le geste : il annule les modifications de ces 12 fiches en une commande, garde les 68 autres, et relance l’agent sur les 12 avec une consigne plus stricte : « change uniquement les termes de la liste, rien d’autre ».
4. Sans Git : il aurait fallu relire 80 fiches en entier pour trouver les 12, puis retrouver les précisions supprimées de mémoire.

Le commit avant la tâche a pris dix secondes. C’est le geste le plus rentable de la journée.

Ce que ça change pour une équipe

• On peut déléguer sans peur. Tout ce que l’agent fait se voit et s’annule. La délégation devient réversible.
• Chaque changement est relu. La différence avant/après, ligne par ligne, est le support naturel de la revue.
• L’historique explique. Pourquoi ce fichier est-il ainsi ? Le journal des commits, avec ses messages, répond.
• La collaboration a un cadre. Plusieurs personnes et plusieurs agents sur le même projet, sans écraser le travail des autres.

Les limites et les erreurs fréquentes

• Lancer l’agent sans commit préalable. Il n’y a plus d’état « avant » auquel revenir. Commit d’abord, toujours.
• Accepter en bloc. Quarante fichiers modifiés, validés d’un clic. La relecture des différences est l’étape qui compte.
• Mettre des secrets dans Git. Un mot de passe commité reste dans l’historique même après suppression. Les secrets vont ailleurs, et les fichiers qui les contiennent sont exclus.
• Garder tout sur un seul ordinateur. Git sans dépôt distant (GitHub ou autre) n’est pas une sauvegarde. Le dépôt distant l’est.