Tu utilises GitHub sans vraiment savoir ce que tu fais ?
L’utiliser à l’aveugle, c’est le meilleur moyen de tout casser.
Sur GitHub, il n’y a que trois boutons verts.
Et un seul endroit où regarder avant de cliquer dessus.
Cet article te montre chaque zone à observer et où cliquer sur l’écran GitHub, le tout encadré en rouge.
Se connecter, soumettre, vérifier le diff, merger et revert.
Nous allons parcourir ce cycle complet avec 10 captures d’écran réelles.
L’IA s’occupe de taper.
Toi, tu regardes et tu cliques.
Je t’expliquerai les termes techniques simplement au fur et à mesure.
※ Les écrans et spécifications GitHub présentés dans cet article ont été vérifiés en octobre 2026. L’interface peut évoluer.
Chapitre 1 : Se connecter à GitHub | Créer un dépôt et envoyer ses historiques locaux
L’interface de GitHub est en anglais.
Mais les endroits où cliquer ne changent jamais.
Les cadres rouges sur les captures t’indiquent exactement où regarder et où cliquer.
Dans ce chapitre, il n’y a qu’un seul bouton vert sur lequel appuyer.
Commence par créer un dépôt (repository).
Un dépôt, c’est comme un casier où tu stockes tes historiques Git en ligne.
J’ai déjà expliqué ce qu’on met dans ce casier ainsi que quatre termes essentiels dans mon précédent post.
【Avec schémas】Git expliqué aux collégiens
https://x.com/dan_pro_man/status/2107224533099069671?s=20
Même si tu ne l’as pas lu, tu peux réaliser le cycle complet rien qu’avec cet article.
Connecte-toi à GitHub et clique sur « New repository » via l’icône « + » en haut à droite.
Ouvrir https://github.com/new t’amène exactement au même écran.
La seule chose à remplir, c’est le nom.
Saisis un nom alphanumérique dans « Repository name ».
« git-practice » fait très bien l’affaire.
Choisis « Private » sous « Choose visibility ».
Cela signifie que ton dépôt ne sera pas public.
Laisse l’option « Add README » désactivée pour l’instant.
Si tu as déjà des historiques en local, il est plus simple de se connecter en créant un dépôt vide.
Clique sur le bouton vert « Create repository » tout en bas.
L’écran qui s’affiche juste après est le point le plus important de ce chapitre.
Vers le bas, tu verras le titre : « …or push an existing repository from the command line ».
Les trois lignes situées en dessous sont les commandes que nous utiliserons aujourd’hui.
Les sept lignes du dessus concernent ceux qui n’ont pas encore d’historique local, tu peux donc les ignorer.
Voici ce que signifient ces trois lignes :
Ligne 1 : Indiquer à ton historique local l’adresse de ce casier.
Ligne 2 : Aligner le nom de la branche principale sur « main ».
Ligne 3 : Stocker la branche principale dans le casier.
Copie l’adresse (encadrée en rouge) depuis cet écran et envoie-la à l’IA en une seule ligne.
1Envoie les historiques de ce dossier vers https://github.com/nom-du-compte/git-practice
Claude Code tapera lui-même les trois lignes.
Claude Code est une IA qui exécute des tâches sur ton ordinateur à partir de tes instructions.
Dans mon propre manuel d’instructions, j’exige une confirmation avant tout push.
Le push, c’est l’opération qui consiste à stocker tes historiques locaux dans le casier.
Il s’arrête donc ici une première fois.
Réponds « Yes », puis actualise la page de ton navigateur.
À la place des trois commandes, tes fichiers locaux apparaissent désormais alignés. À côté, tu vois le message de commit.
C’est le signe que tu es bien « connecté ».
Il y a un détail que je veux que tu remarques.
Le texte « main » au-dessus de la liste des fichiers.
Il indique quel signet tu consultes actuellement à l’intérieur du casier.
Un signet, c’est une branche.
Il marque la colonne dans laquelle tu empiles tes historiques.
Ne touche plus directement à ce « main » par la suite.
Au début, je n’y prêtais pas vraiment attention non plus.
Je travaillais sur main et je perdais un temps fou à chercher comment revenir en arrière.
Quand la connexion échoue, c’est presque toujours un problème d’adresse.
Le « .git » à la fin est manquant.
Le nom du compte est mal orthographié.
Si tu vois « not found », recopie l’adresse depuis l’image ②.
À ce stade, tes historiques locaux sont connectés à GitHub. Passons maintenant au cycle quotidien des fusions via les Pull Requests.
**
Chapitre 2 : Fusionner via une Pull Request | Soumettre le travail de l’IA, vérifier le diff, puis cliquer
C’est ici que commence le cycle quotidien.
Une Pull Request est une demande qui dit en substance : « Merci de fusionner ceci ».
Dans ce chapitre, il y a trois boutons verts sur lesquels cliquer.
L’IA s’occupe de taper.
Ton seul rôle est de regarder et de cliquer.
Pour commencer, envoie une ligne à l’IA.
1Crée une nouvelle branche, ajoute 3 lignes d'utilisation au README, commite et envoie sur GitHub
Le README est le premier fichier où tu décris ton dépôt.
Claude Code crée une branche.
Il modifie le fichier et commite.
Enfin, il s’arrête avant le push et te demande la permission.
Réponds « Yes », puis ouvre ton casier dans le navigateur.
Une bannière jaune apparaît en haut.
Elle t’informe : « Je viens de stocker cette branche ».
Clique sur le bouton vert « Compare & pull request » à droite.
C’est la « soumission ».
Comme quand tu tends ton brouillon au professeur.
Soumettre ne copie rien dans la version finale.
La copie se fait après la relecture.
Il y a trois zones à vérifier sur l’écran de soumission.
1re : La flèche tout en haut.
« base: main » et « compare: work-branch »
Cela indique d’où et vers où la fusion va s’effectuer.
Vérifie simplement que le côté gauche affiche bien main.
2e : Le titre dans « Add a title ».
Si l’IA le génère, il inclut un résumé des modifications.
Si tu soumets manuellement, le message de commit est prérempli.
Dans ce cas, écris en une ligne « ce qui a été fait ».
3e : Le bouton vert « Create pull request ».
Cliquer dessus valide la soumission.
Après la soumission, c’est à l’humain d’agir.
Quatre onglets apparaissent en haut de l’écran.
Concentre-toi uniquement sur celui de droite : « Files changed ».
Cela signifie « fichiers modifiés ».
Les lignes vertes sont les ajouts.
Les lignes rouges sont les suppressions.
C’est ce qu’on appelle le diff.
Si les 3 lignes demandées sont en vert, c’est validé.
Sur la capture d’exemple, des titres et des lignes vides ont aussi été ajoutés, ce qui donne 6 lignes vertes.
S’il y a des lignes rouges que tu n’as pas demandées, ne merge surtout pas.
Sur la capture d’exemple, il y a 1 ligne rouge.
Une ligne de mémo a disparu de « Items placed ».
Si tu ne l’as pas demandé, arrête-toi là.
Demande à l’IA : « Pourquoi as-tu supprimé cette ligne rouge ? »
Ce sont les 30 secondes les plus cruciales quand on délègue du travail à une IA.
À l’époque où la simple vue des notifications de revue me nouait l’estomac, je cliquais sans vérifier ça.
Aujourd’hui, je compte d’abord les lignes rouges.
S’il y a ne serait-ce qu’une ligne rouge non sollicitée, je m’arrête.
Si le diff est impeccable, retourne sur l’onglet « Conversation ».
Vers le bas, tu trouveras un bouton vert « Merge pull request ».
Si la mention « No conflicts with base branch » s’affiche au-dessus, tu peux fusionner directement.
En cliquant dessus, le texte devient « Confirm merge ».
Clique une seconde fois.
Les historiques de la branche de travail sont désormais fusionnés dans main.
La couleur passe au violet et affiche « Merged ».
Un encadré apparaît en dessous avec le message « Pull request successfully merged and closed ».
À sa droite se trouve « Delete branch ».
N’hésite pas à cliquer dessus.
Seul le « signet » de la branche de travail disparaît du casier.
Puisque les historiques sont déjà fusionnés dans main, rien n’est perdu.
Pour finir, mets à jour ton environnement local.
Dis à l’IA : « Bascule sur main et récupère la dernière version depuis GitHub ».
Un cycle est terminé.
Lance la tâche suivante depuis une nouvelle branche.
Ne travaille jamais sur main.
Tu as maintenant bouclé le cycle de soumission, de vérification du diff et de fusion. Voyons ensuite le Revert, le bouton pour annuler une erreur après une fusion.
**
Chapitre 3 : Le Revert | Annuler une erreur après fusion en un clic
Il arrive qu’on remarque une erreur seulement après avoir fusionné.
Avec Git, on « annule » les historiques stockés sans les supprimer.
L’interface de GitHub propose un bouton pour ça.
Il s’appelle « Revert ».
Rouvre la Pull Request que tu viens de fusionner.
Tu y verras la ligne « merged commit … into main ».
Tout à droite de cette ligne se trouve « Revert ».
Que se passe-t-il quand tu cliques dessus ?
Les historiques ne sont pas supprimés.
Une nouvelle Pull Request est créée avec les modifications inversées.
Selon la documentation officielle, l’annulation effective se produit lorsque tu fusionnes cette nouvelle Pull Request.
Le revert suit donc exactement le même cycle que le chapitre 2.
Vérifie le diff, puis clique sur le bouton vert.
Au lieu de supprimer, on ajoute un historique indiquant que l’action a été « annulée ».
Si tu passes par l’IA, dis-lui : « Annule la Pull Request que je viens de fusionner ».
Claude Code fera la même chose avec git revert.
Il y a un autre écran que tu pourrais croiser.
« This branch has conflicts that must be resolved ».
C’est un conflit.
Il survient quand la même ligne a été modifiée différemment dans main et dans la branche de travail.
Le bouton vert devient gris et impossible à cliquer.
Ne tente pas de le régler sur l’interface ; envoie plutôt une ligne à l’IA.
1Récupère main et montre-moi les deux versions des parties en conflit
C’est à toi de décider laquelle conserver.
Dès que l’IA corrige le problème et renvoie le tout, le bouton vert réapparaît.
Un conflit n’est pas un échec.
Il met simplement en évidence le fait que la même ligne a été éditée deux fois.
Enfin, un élément qui n’apparaît pas à l’écran.
Les clés.
Les fichiers contenant des mots de passe ou des clés API ne doivent jamais être envoyés sur GitHub.
Même avec un Revert, dès qu’une clé est uploadée, elle est considérée comme compromise et doit être régénérée.
Avant tout envoi, dis à l’IA : « Exclue .env des historiques ».
Dans mon propre environnement de travail, je rédige mes configurations AWS dans des fichiers texte et je suis ce même cycle.
Des configurations fusionnées sans vérification du diff tournent directement en production.
C’est pourquoi je ne délègue jamais à l’IA ces 30 secondes critiques avant de cliquer.
C’est l’humain qui appuie sur tous les boutons de l’interface.
Même si j’étends progressivement le périmètre confié à l’IA, cette règle reste immuable.
Le cycle complet — connexion, soumission, fusion et revert — est désormais bouclé.
Pour finir, je te fournis des ressources prêtes à l’emploi.
J’ai détaillé toutes les étapes pour accomplir un cycle complet sur l’interface GitHub.
J’ai regroupé les captures d’écran et les prompts de cet article dans des formats prêts à l’emploi.
- Poster de traduction de l’interface GitHub (9 écrans, 69 termes)
- Carte de secours quand l’IA casse quelque chose (6 scénarios)
- 7 prompts pour réaliser un cycle complet
- Checklist avant fusion (8 points)
Le tout livré dans un livret PDF de 15 pages.
Avec ça, tu peux commencer à boucler des cycles dès aujourd’hui.
Pour les recevoir, rejoins simplement l’Open Chat ci-dessous.
Suis les instructions après avoir rejoint le groupe et envoie « Submit » : tu les recevras automatiquement.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
En résumé : boucle un seul cycle aujourd’hui
Ne pousse jamais le travail de l’IA directement dans main.
Soumets depuis une branche de travail, vérifie le diff et clique sur les boutons verts.
Il y avait trois boutons verts sur lesquels cliquer dans un cycle.
Le jour où j’ai cliqué sur Revert moi-même pour la première fois, j’ai compris que les historiques n’étaient pas supprimés.
Depuis, je n’ai plus peur de mettre les mains dans le cambouis.
Tu n’es pas obligé de tout faire d’un coup.
Aujourd’hui, tu n’as qu’une seule chose à faire.
Ouvre le dépôt créé au chapitre 1 et envoie une ligne à l’IA.
Crée une nouvelle branche, ajoute 1 ligne au README et envoie sur GitHub
Quand la bannière jaune apparaît, clique sur le bouton vert et ouvre « Files changed ».
S’il n’y a qu’une seule ligne verte, c’est validé.
Regarde cette ligne de tes propres yeux avant de fusionner.
C’est le premier pas pour élargir ce que tu peux déléguer à l’IA.
Pour les ingénieurs de plus de 30 ans, gagner ne dépend pas du volume de travail, mais de la conception.
Plutôt que de réapprendre tes outils à chaque mise à jour, il est bien plus rapide de définir clairement où s’arrêter.
AWS et l’IA évoluent à toute vitesse.
Observer les retours de ceux qui testent en conditions réelles va beaucoup plus vite que d’essayer de suivre seul.
Dans ma pratique de l’ingénierie × IA, je documente autant mes réussites que mes erreurs et mes exclusions.
Abonne-toi pour ne rien manquer de mes prochains partages ! @dan_pro_man
