Tuto GitHub : du compte au premier push, pas à pas

Ce tuto GitHub vous conduit du compte gratuit au premier push : un dépôt, un commit, une copie locale du projet, puis Claude Code qui fait les commits pour vous. Pour un freelance, GitHub héberge aussi le code de votre client : un dépôt à son nom, des accès que vous donnez puis retirez, et un historique qui prouve chaque modification livrée. J’ai revérifié les écrans et les commandes dans la documentation de GitHub en octobre 2026, neuf mois après le tournage.

11:31

Git et GitHub : ce que fait chacun

Git est un logiciel installé sur votre ordinateur. Il enregistre l’historique de votre projet : chaque sauvegarde, qu’on appelle un commit, porte une date, une heure, un auteur et un message qui dit ce qui a changé.

GitHub est le site qui héberge ce projet en ligne. Dans la vidéo, je le compare à Google Drive pour le code : votre code est sauvegardé, accessible de n’importe où, et vous pouvez le montrer ou travailler à plusieurs dessus.

Imaginez : vous codez un projet depuis 3 jours, votre ordinateur plante, ou une modification casse tout. Avec Git et GitHub, vous remontez à la dernière version qui marchait. Sans eux, vous recommencez.

C’est encore plus vrai avec Claude Code ou Cursor : une seule demande peut modifier des dizaines de fichiers. Si le résultat ne vous va pas, un historique propre vous ramène en arrière en une commande. Sinon, vous démêlez à la main.

Les 6 mots à connaître :

• Dépôt (repository, ou repo) : un projet sur GitHub, avec tout son historique.
• Commit : une sauvegarde datée, avec un message.
• Push : l’envoi de vos commits de votre ordinateur vers GitHub.
• Clone : la copie complète d’un dépôt sur votre ordinateur.
• Branche : une ligne de travail à côté de la version principale, main.
• Pull request : la demande de fusionner une branche dans main, relue avant d’être acceptée.

Étape 1 : créer votre compte GitHub

Allez sur github.com/signup. Vous entrez votre email, un mot de passe et un nom d’utilisateur, ou vous passez par Continue with Google (Apple est aussi proposé). Vérifiez ensuite votre adresse email : sans elle, GitHub vous bloque sur des tâches de base, comme créer un dépôt.

Choisissez un nom d’utilisateur professionnel. C’est lui que vos clients verront dans l’historique et dans chaque invitation : votre prénom et votre nom, ou celui de votre activité. Évitez DarkKiller2007.

Dans la foulée, activez l’authentification à deux facteurs, que GitHub recommande fortement, et gardez le plan gratuit : il comprend les dépôts privés et les collaborateurs en nombre illimité, ce qui suffit pour tout ce tutoriel.

Une fois inscrit, vous arrivez sur votre tableau de bord, votre page d’accueil sur GitHub.

Étape 2 : créer votre premier dépôt

Sur le tableau de bord, cliquez sur le bouton vert New, à gauche. Depuis n’importe quelle page, l’icône + en haut à droite mène au même endroit : New repository.

Remplissez la page dans l’ordre :

1. Owner : votre compte. Pour un projet client, ce sera son organisation (j’y reviens plus bas).
2. Repository name : un nom clair, en minuscules avec des tirets, comme site-vitrine ou app-devis. GitHub accepte les lettres, les chiffres, le point, le tiret et le tiret bas, 100 caractères au plus.
3. La description : facultative, mais une phrase sur ce que fait le projet vous aidera le jour où vous en aurez vingt.
4. La visibilité : public, tout le monde voit votre code ; privé, seuls vous et les personnes invitées. Choisissez privé presque à chaque fois : vous protégez votre code et celui de vos clients.
5. Add README : activez-le. GitHub crée un fichier de présentation du projet, vide au départ. Quand le projet aura pris forme, demandez à Claude Code de le remplir : il lit votre code et rédige la documentation.
6. Cliquez sur Create repository.

Dans la vidéo, l’option s’appelait encore « Initialize this repository with a README ». C’est aujourd’hui un interrupteur, Add README.

Votre premier dépôt existe, à l’adresse github.com/votre-nom/site-vitrine.

Étape 3 : ajouter un fichier depuis le site

C’est la façon la plus simple de commencer, sans rien installer.

1. Sur la page du dépôt, cliquez sur Add file, puis Create new file.
2. Donnez un nom au fichier, par exemple index.html. Un / dans le nom crée un dossier.
3. Écrivez votre code dans l’éditeur.
4. Cliquez sur Commit changes....
5. Dans Commit message, décrivez ce que vous avez fait en quelques mots : « Ajout de la page d’accueil ».
6. Pour ce premier fichier, restez sur la branche actuelle, main, et cliquez sur Commit changes.

Votre fichier est sur GitHub, avec la date, l’heure et votre message. Voilà ce qu’est un commit : une sauvegarde du code, accompagnée de la phrase qui dit ce qui a changé. Plus vous en faites, plus l’historique est précis, et plus vous savez où chercher le jour où quelque chose casse.

Pour un fichier, le site suffit. Pour un vrai projet, vous travaillerez depuis votre ordinateur.

Étape 4 : travailler en local avec GitHub CLI

Cloner, c’est télécharger une copie complète du dépôt sur votre ordinateur, historique compris. Il vous faut deux outils : Git, qui fait le travail, et GitHub CLI (la commande gh), l’outil officiel de GitHub qui relie votre ordinateur à votre compte.

Installer Git et GitHub CLI

Sur Mac, avec Homebrew :

brew install git gh

Sans Homebrew, xcode-select --install installe Git avec les outils de développement d’Apple, et GitHub CLI se télécharge sur cli.github.com.

Sur Windows, installez Git for Windows depuis git-scm.com, puis GitHub CLI dans le terminal :

winget install --id GitHub.cli --source winget

Ouvrez ensuite une nouvelle fenêtre de terminal : d’après la documentation de GitHub CLI, un nouvel onglet ne suffit pas. Sur Linux, la commande dépend de votre distribution ; elle est dans le guide d’installation du dépôt cli/cli.

Vérifiez que tout répond :

git --version
gh --version

Dans la vidéo, je demande la commande à l’agent IA de mon terminal, Warp, qui donne celle de votre système : Mac, Windows ou Linux. Claude Code fait pareil si vous lui écrivez « installe-moi GitHub CLI ».

Connecter gh à votre compte

Git n’accepte plus le mot de passe de votre compte GitHub pour envoyer du code. Il lui faut un jeton d’accès personnel, une clé SSH, ou un outil qui gère la connexion à votre place. Pour débuter, le plus simple est gh :

gh auth login

Répondez aux questions : GitHub.com, puis HTTPS comme protocole, puis Y quand gh propose d’authentifier Git avec vos identifiants GitHub. Le navigateur s’ouvre, vous vous connectez, et c’est réglé. Le jeton est rangé dans le gestionnaire d’identifiants de votre système, et git push ne vous demandera plus rien. gh auth status confirme que la connexion tient.

Sans cette étape, le premier push s’arrête sur une demande de mot de passe que GitHub refuse.

Dire à Git qui vous êtes

Chaque commit porte un nom et un email. Réglez-les une fois pour toutes :

git config --global user.name "Prénom Nom"
git config --global user.email "vous@exemple.fr"

Pour ne pas afficher votre adresse personnelle dans l’historique d’un dépôt public, GitHub vous fournit une adresse noreply : photo de profil, Settings, puis Emails, avec la case Keep my email addresses private.

Cloner votre dépôt

gh repo clone votre-nom/site-vitrine
cd site-vitrine

Le dossier site-vitrine apparaît là où vous avez lancé la commande. Ouvrez-le dans votre éditeur, ou lancez claude dedans, et travaillez normalement.

Une fois gh installé, vous pouvez même sauter l’étape 2 : gh repo create app-devis --private --clone crée le dépôt privé et le clone d’un coup.

Étape 5 : sauvegarder vos modifications avec add, commit et push

Vous avez modifié des fichiers sur votre ordinateur. Pour les envoyer sur GitHub, ce sont toujours les 3 mêmes étapes :

git add .
git commit -m "Ajout du formulaire de contact"
git push

1. git add . : vous dites à Git quels fichiers sauvegarder. Le point désigne tous les fichiers modifiés du dossier où vous êtes. Pour un seul fichier : git add index.html.
2. git commit -m : vous créez la sauvegarde, avec un message entre guillemets qui décrit ce que vous avez fait, comme « Correction du bug de connexion ».
3. git push : vous envoyez le tout sur GitHub.

Pour garder la main, git status montre ce qui a changé et n’est pas encore sauvegardé, et git log --oneline affiche l’historique, un commit par ligne.

Les deux erreurs classiques :

• Oublier le push. Vous avez fait vos commits, vous pensez que c’est sauvegardé. Tant que vous n’avez pas poussé, tout reste sur votre ordinateur.
• Écrire des messages vagues. « Modifs » ou « fix » ne vous diront plus rien dans 2 semaines. Écrivez ce qui a changé.

J’en ajoute une troisième pour le travail client : pousser un fichier .env qui contient des clés d’API. Avant le premier commit, ajoutez une ligne .env dans le fichier .gitignore, à la racine du projet, et Git ignorera ce fichier. Une clé déjà poussée reste dans l’historique, même après suppression du fichier : il faut la révoquer et en créer une nouvelle.

Enfin, si vous travaillez sur deux ordinateurs ou si vous avez modifié un fichier sur le site, lancez git pull avant de pousser. Il récupère ce qui est sur GitHub ; sans lui, le push est refusé.

Étape 6 : laisser Claude Code faire les commits

Si vous avez fait gh auth login, Claude Code est déjà connecté : il lance Git et gh dans votre terminal, avec vos identifiants. Vous n’avez rien de plus à configurer.

Au quotidien, Claude modifie des fichiers, ajoute une fonctionnalité, corrige un bug. Quand le résultat vous convient, dites-lui : « Fais un commit et push sur GitHub. » Il lit les changements, écrit un message de commit clair, puis lance l’add, le commit et le push. Vous n’avez plus à retenir les commandes.

Pour garder le contrôle : « Montre-moi les changements avant de faire un commit. » Il affiche le diff, les lignes ajoutées et retirées, et attend votre accord.

Pour que ce soit systématique, écrivez la règle dans le CLAUDE.md du projet, le fichier de consignes que Claude Code charge au début de chaque session (CLAUDE.md et les autres concepts de Claude, expliqués). Par exemple :

- Avant chaque nouvelle fonctionnalité, crée une branche depuis main.
- Un commit par étape terminée, avec un message en français qui dit ce qui change.
- Termine par une pull request, jamais de push direct sur main.

Si vous avez installé le plugin des 6 Claude Code skills, /branche et /livre font déjà ce travail : le premier crée une branche à partir d’un main à jour, le second commit, pousse et ouvre la pull request.

Et quand Claude casse quelque chose malgré tout, l’historique vous sauve. Tant que rien n’est commité, git restore . annule les modifications en cours. Après un commit, git revert l’annule en gardant la trace. Puis cherchez la cause avec la méthode de debug en 4 phases, au lieu d’empiler les correctifs.

Branches et pull requests : travailler à plusieurs sans casser main

GitHub devient vraiment utile quand vous travaillez à plusieurs, avec un autre développeur ou avec un agent comme Claude Code. Le concept à comprendre, c’est la branche.

Imaginez votre projet comme un arbre. Le tronc, c’est la version principale : main. Pour ajouter une fonctionnalité sans risquer le tronc, vous créez une branche et vous y travaillez tranquillement. Si ça marche, vous la fusionnez dans le tronc. Sinon, vous la supprimez, et main n’a jamais été touché.

git checkout -b formulaire-contact      # crée la branche et bascule dessus
# vous travaillez et faites vos commits, puis :
git push -u origin formulaire-contact   # envoie la branche sur GitHub
gh pr create --fill                     # ouvre la pull request avec vos messages de commit

git switch -c formulaire-contact fait la même chose que la première ligne, avec une commande plus récente.

La pull request est la demande de fusionner votre branche dans main. Vous, ou quelqu’un d’autre, relisez le code sur GitHub avant de cliquer sur Merge pull request. Sans gh, GitHub affiche aussi un bouton Compare & pull request sur la page du dépôt, juste après le push.

Claude Code fait tout cela pour vous : « Crée une branche pour cette fonctionnalité, fais tes modifications et propose une pull request. »

Un point du plan gratuit à connaître : sur un dépôt privé, la protection de branche (interdire le push direct sur main) fait partie des outils des plans payants Pro et Team. En gratuit, ce sont la règle du CLAUDE.md et la pull request systématique qui protègent main.

Une fois ces bases acquises, vous pouvez aller plus loin :

• @claude dans GitHub. Dans le dossier du projet, lancez /install-github-app depuis Claude Code : il installe l’application Claude sur le dépôt et prépare le workflow. Il faut être administrateur du dépôt et avoir connecté gh. Ensuite, un commentaire comme « @claude corrige le bug décrit dans cette issue » suffit : Claude répond dans l’issue et pousse ses commits, sans que vous ouvriez le terminal. Chaque exécution consomme des minutes GitHub Actions et votre usage de Claude.
• Plusieurs Claude en parallèle. claude --worktree formulaire ouvre une session sur sa propre copie du projet, dans sa propre branche. Une autre session, dans un second terminal, avance sur une autre fonctionnalité sans que les deux se gênent. Le dépôt doit avoir au moins un commit.

Le code de votre client sur GitHub : à son nom, avec des accès propres

Quand vous livrez avec Claude Code, le dépôt est la première chose à régler avec le client. Trois points.

Le dépôt appartient au client

Deux façons de faire.

Le client crée une organisation GitHub (le plan gratuit suffit), idéalement avec vous pendant le rendez-vous : photo de profil, Settings, Organizations, puis New organization. Il vous invite, et vous créez le dépôt en choisissant son organisation comme Owner. C’est la solution la plus propre, dès le premier jour.

Ou vous démarrez sur votre compte et vous transférez le dépôt à la livraison : Settings du dépôt, section Danger Zone, bouton Transfer, puis le nom du client ou de son organisation. Les issues, les pull requests et tout l’historique suivent, et les anciennes adresses redirigent vers la nouvelle. Vers un compte personnel, le client a un jour pour accepter, et vous restez collaborateur. Mettez ensuite votre copie locale à jour :

git remote set-url origin https://github.com/nom-du-client/site-vitrine.git

Les accès : donnés au début, retirés à la fin

Sur un dépôt de compte personnel : Settings, section Access, Collaborators, puis Add people. Tapez le nom d’utilisateur et confirmez avec Add NAME to REPOSITORY (le nom de la personne, puis celui du dépôt). La personne reçoit un email et accède au dépôt une fois l’invitation acceptée.

Attention : sur un dépôt personnel, un collaborateur peut toujours écrire, la lecture seule n’existe pas. Pour donner un simple accès en lecture à un associé du client ou à un auditeur, ou des rôles plus fins, il faut une organisation.

En fin de mission, sur la même page, le bouton Remove à droite du nom retire l’accès. Si c’est le client qui vous a invité, proposez-lui de le faire dans votre mail de clôture : personne ne garde un accès dont il n’a plus besoin.

Les clés du client (API, base de données, paiement) ne vont jamais dans le code. Elles restent dans un .env ignoré par Git, et dans les secrets du dépôt (Settings, Secrets and variables, Actions) si un workflow GitHub en a besoin.

L’historique prouve le travail

Chaque commit porte une date, une heure, un auteur et un message. Le lien des commits sur la page du dépôt, ou git log --oneline, devient le journal de votre mission : ce qui a été livré, quand et pourquoi. Avec une pull request par fonctionnalité, le client voit chaque livraison, la relit s’il le souhaite, et vous avez une trace à montrer si une question se pose sur ce qui a été fait.

Pour un exemple de projet qui finit dans le dépôt du client : le dashboard construit avec Claude Code, montré d’abord sur un export de ses données, puis branché en direct.