- Partie 0 — Contrat du livre
- Partie I — Ce que les agents changent dans l’usage de Git
- Chapitre 1 — Quand un développeur devient responsable de plusieurs producteurs de code
- Chapitre 2 — Pourquoi Git ne coordonne pas automatiquement les agents
- Chapitre 3 — Dépôt, arborescence de travail, index, commit et application
- Chapitre 4 — Les quatre nouvelles catégories de risque
- Chapitre 5 — Ce que Git protège — et ce qu’il ne protège pas
- Partie II — Préparer un dépôt au travail multi-agent
- Chapitre 6 — Photographier l’état initial du projet
- Chapitre 7 — Identifier la branche et le commit de référence
- Chapitre 8 — Protéger le travail existant
- Chapitre 9 — Créer un worktree par mission
- Chapitre 10 — Définir les chemins autorisés et interdits
- Chapitre 11 — Réserver les composants sensibles
- Chapitre 12 — Préparer des règles lisibles par les agents
- Partie III — Confier une mission Git à un agent
- Chapitre 13 — Le contrat de mission
- Chapitre 14 — Fixer le point de départ
- Chapitre 15 — Limiter les changements autorisés
- Chapitre 16 — Autoriser ou interdire les sous-agents
- Chapitre 17 — Exiger de petits commits intentionnels
- Chapitre 18 — Relier les tests au commit livré
- Chapitre 19 — Obtenir un rapport de fin de mission
- Chapitre 20 — Arrêter une mission devenue obsolète
- Partie IV — Coordonner les agents et les sous-agents
- Chapitre 21 — Une branche, un worktree et un responsable par mission
- Chapitre 22 — Détecter les chevauchements avant le début du développement
- Chapitre 23 — Gérer les dépendances entre missions
- Chapitre 24 — Sérialiser ce qui ne peut pas être parallélisé
- Chapitre 25 — Migrations et contrats partagés
- Chapitre 26 — Fichiers générés et fichiers de verrouillage
- Chapitre 27 — Savoir quand réduire le parallélisme
- Partie V — Intégrer le code produit par les agents
- Chapitre 28 — Examiner le diff d’un agent
- Chapitre 29 — Vérifier le périmètre réellement modifié
- Chapitre 30 — Vérifier la provenance du code
- Chapitre 31 — Mettre à jour une mission de longue durée
- Chapitre 32 — Tester un changement de manière isolée
- Chapitre 33 — Tester le résultat combiné
- Chapitre 34 — Organiser une file de fusion
- Chapitre 35 — Protéger la branche principale
- Chapitre 36 — Publier sans réécrire l’historique partagé
- Partie VI — Communiquer avec l’IA au sujet de Git
- Chapitre 37 — Le prompt d’observation
- Chapitre 38 — Expliquer les commandes autorisées
- Chapitre 39 — Interdire les commandes destructrices
- Chapitre 40 — Le prompt d’intervention limitée
- Chapitre 41 — Contrôler la délégation aux sous-agents
- Chapitre 42 — Demander un diagnostic sans demander de réparation
- Chapitre 43 — Organiser le refus et l’escalade
- Chapitre 44 — Une bibliothèque de prompts Git
- Partie VII — Les opérations dangereuses
- Chapitre 45 — Comprendre reset, restore et revert
- Chapitre 46 — Comprendre les risques de clean
- Chapitre 47 — Comprendre stash dans un environnement multi-agent
- Chapitre 48 — Rebaser sans perdre la provenance
- Chapitre 49 — Pourquoi le force push doit rester exceptionnel
- Chapitre 50 — Supprimer un worktree sans effacer un travail inconnu
- Partie VIII — Se remettre d’une situation critique
- Chapitre 51 — Les dix premières minutes
- Chapitre 52 — Geler les écritures
- Chapitre 53 — Inventorier tous les états
- Chapitre 54 — Reconstruire la chronologie
- Chapitre 55 — Récupérer un commit avec reflog
- Chapitre 56 — Tester une récupération dans un worktree séparé
- Chapitre 57 — Distinguer la récupération Git de la récupération de l’application
- Chapitre 58 — Aligner le code, les migrations, les données et la configuration
- Chapitre 59 — Promouvoir une récupération sans force push
- Chapitre 60 — Produire le rapport d’incident
- Partie IX — Installer la méthode dans toute l’équipe
- Chapitre 61 — Le protocole quotidien de l’ingénieur
- Chapitre 62 — Le tableau de bord des missions
- Chapitre 63 — Les règles de protection du dépôt
- Chapitre 64 — Les exercices de récupération
- Chapitre 65 — Construire le playbook de l’organisation
- Annexes
- Sources et documentation officielle
- Matrice des niveaux de risque
- Modèle minimal de contrat
Git à l’ère des agents IA
Versionner, isoler, intégrer et récupérer le travail des agents et des sous-agents
Les agents IA produisent désormais du code plus vite que les équipes ne peuvent le contrôler. Ce guide opérationnel explique comment utiliser Git pour isoler les missions, coordonner agents et sous-agents, sécuriser l’intégration et récupérer un projet sans perdre son travail ni son historique.
With Membership
Free!
$14.99
You pay
Author earns
About
About the Book
Le développement logiciel a changé d’échelle.
Un ingénieur peut désormais confier simultanément une correction, une migration, une campagne de tests et une refactorisation à plusieurs agents IA. Ces agents peuvent eux-mêmes déléguer une partie de leur mission à des sous-agents. En quelques minutes, une équipe doit alors comprendre, contrôler et intégrer davantage de code qu’elle n’aurait pu en produire manuellement.
Git reste la mémoire du projet, mais il ne coordonne ni les missions, ni les responsabilités, ni l’ordre d’intégration. Il ne sait pas si deux modifications situées dans des fichiers différents affectent le même contrat métier. Il ne protège pas non plus une équipe contre une consigne ambiguë telle que « remets le dépôt propre ».
Git à l’ère des agents IA est un guide opérationnel consacré à cette nouvelle réalité.
Ce livre ne cherche pas à réenseigner les commandes élémentaires de Git. Il explique comment conserver une histoire compréhensible, un état vérifiable et des possibilités de récupération lorsque des humains, des agents et des sous-agents travaillent simultanément sur une même application.
Vous apprendrez notamment à :
- attribuer une base, une branche, un worktree et un périmètre à chaque mission ;
- empêcher plusieurs agents de partager accidentellement le même état mutable ;
- encadrer la délégation aux sous-agents ;
- examiner les différences réellement produites avant de les intégrer ;
- construire des commits petits, intentionnels et attribuables ;
- organiser une file d’intégration adaptée au débit des agents ;
- communiquer avec une IA sans lui donner une autorisation implicite de modifier Git ;
- encadrer
reset,restore,revert,clean,rebaseet le push forcé ; - préserver les travaux non validés pendant un incident ;
- retrouver un commit perdu et tester une récupération sans écraser l’état actuel ;
- construire le playbook Git et multi-agent de votre organisation.
Chaque situation fournit un problème concret, une méthode, une marche à suivre, des commandes expliquées avant leur exécution, des prompts réutilisables, les erreurs fréquentes, une checklist et un livrable exploitable par l’équipe.
Les exemples issus du projet Tansa servent de cas pratiques, mais les méthodes proposées s’appliquent à tout projet logiciel développé avec des agents IA.
L’objectif n’est pas de ralentir les agents. Il est de rendre leur vitesse assimilable par l’équipe, sans perdre la capacité de comprendre, de prouver, d’intégrer et de récupérer.
Author
About the Author
Victor Perez is an independent author whose books explore a wide variety of subjects and genres. He writes about the ideas, questions, and experiences that fascinate him—from technology, artificial intelligence, Bitcoin, and software architecture to philosophy, spirituality, human freedom, and personal transformation.
His goal is not to confine himself to a single field, but to make complex subjects clear and engaging without oversimplifying them. Whether he is documenting a real-world project, examining a philosophical question, or exploring a spiritual tradition, he approaches each book with curiosity, honesty, and a desire to invite readers to think for themselves.
Alongside his writing, he designs and develops Tansa, a Bitcoin analytics application built with Ruby on Rails, PostgreSQL, and artificial intelligence.
Translations
Translations
Languages
Contents
Table of Contents
Get the free sample chapters
Click the buttons to get the free sample in PDF or EPUB, or read the sample online here
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earned over $15 million writing, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
Write and Publish on Leanpub
You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!
Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.
Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.