Premiers pas avec Git et GitHub

Avant d'écrire la moindre commande, il faut lever la confusion la plus répandue chez les débutant·es : Git et GitHub ne sont pas la même chose. Git est un logiciel installé sur ta machine qui suit l'historique de tes fichiers — il fonctionne entièrement en local, sans internet. GitHub est un service en ligne qui héberge des dépôts Git pour les sauvegarder et les partager. Autrement dit : Git est le moteur, GitHub est le garage où tu ranges et exposes ce que le moteur a produit. Tu peux parfaitement utiliser Git sans GitHub ; l'inverse n'a pas de sens.

Cette distinction n'est pas qu'une question de vocabulaire : elle structure toute ta façon de travailler. Tu versionnes en local avec Git (tu enregistres des étapes, tu compares, tu reviens en arrière), puis tu synchronises avec GitHub quand tu veux sauvegarder ou collaborer. GitHub n'est d'ailleurs pas seul sur ce créneau — GitLab, Bitbucket ou Gitea rendent le même service — mais c'est le plus utilisé, et tout ce que tu apprends ici se transpose aux autres.

Quatre mots reviendront sans cesse, autant les fixer tout de suite. Un dépôt (repository, ou « repo ») est un projet versionné. Un commit est une photo de ton projet à un instant précis, toujours accompagnée d'un message qui décrit le changement. Une branche est une ligne d'évolution indépendante du code. Un remote est un dépôt distant (sur GitHub, par exemple) connecté à ton dépôt local. Garde ces quatre termes en tête : tout le reste du cours n'est qu'un assemblage de ces briques.

Git : le versionneur local

Git est un logiciel installé sur ta machine qui suit l'historique de tes fichiers. Il fonctionne sans internet. Chaque modification, chaque retour en arrière, chaque comparaison entre versions passe par Git.

GitHub : la plateforme de partage

GitHub est un service en ligne qui héberge des dépôts Git. C'est là que tu sauvegardes ton code, que tu collabores avec d'autres dev, que tu publies tes projets open source. Il y en a d'autres (GitLab, Bitbucket, Gitea), GitHub est le plus utilisé.

Le vocabulaire de base

• Dépôt (repository, repo) : un projet versionné
• Commit : une photo de ton projet à un instant T, avec un message qui décrit le changement
• Branche (branch) : une ligne d'évolution indépendante du code
• Remote : un dépôt distant (sur GitHub par exemple), connecté à ton dépôt local

git --version
# git version 2.45.0 ou plus récent

La bonne nouvelle avec Git, c'est que la configuration se fait une seule fois et te suit ensuite sur tous tes projets. Cinq minutes bien investies au départ t'évitent des heures de tracas plus tard — notamment des commits signés du mauvais nom, un grand classique quand on saute cette étape. L'installation d'abord : sur macOS via brew install git, sur Windows via l'installeur Git for Windows, sur Linux via le gestionnaire de paquets (sudo apt install git). Une commande git --version confirme que tout est en place.

Le réglage le plus important est ton identité. Chaque commit que tu crées est signé avec un nom et un email, inscrits de façon permanente dans l'historique. Tu les configures avec git config --global user.name et user.email. Un détail qui compte : utilise l'email associé à ton futur compte GitHub, sinon tes contributions n'apparaîtront pas sur ton profil. Profite-en pour poser deux autres réglages utiles : la branche par défaut sur main (init.defaultBranch main) et ton éditeur préféré pour rédiger les messages (core.editor "code --wait"), ce qui t'évite de te retrouver coincé·e dans Vim sans savoir en sortir.

Un mot sur l'option --global, source de confusion fréquente. Avec --global, ta configuration s'applique à tous tes dépôts ; sans elle, uniquement au dépôt courant. Dans 99 % des cas, tu veux le réglage global — tu ne configures ton identité qu'une fois. La configuration locale (sans --global) sert aux cas particuliers, par exemple utiliser une autre adresse email sur un projet client précis. En cas de doute, git config --list t'affiche l'ensemble de ta configuration active.

Installation

• macOS : brew install git (recommandé), ou via les Xcode Command Line Tools
• Windows : télécharge Git for Windows sur git-scm.com
• Linux : via le gestionnaire de paquets, ex sudo apt install git sur Ubuntu

Configurer ton identité

Chaque commit que tu fais est signé avec un nom et un email. À toi de les configurer une bonne fois pour toutes :

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

# Branche par défaut sur "main" pour tout nouveau projet
git config --global init.defaultBranch main

# Éditeur par défaut (VS Code dans cet exemple)
git config --global core.editor "code --wait"

# Vérifier la config
git config --list

Pour bien comprendre Git, il faut visualiser qu'il travaille avec trois zones distinctes. Le répertoire de travail (working directory) est ton dossier, là où tu modifies réellement les fichiers. La zone de préparation (staging area, ou index) est un sas où tu rassembles ce qui ira dans le prochain commit. Le dépôt (repository) est l'historique des commits enregistrés. Cette étape intermédiaire du staging déroute souvent les débutant·es, mais c'est elle qui te donne le contrôle : tu choisis précisément quelles modifications regrouper dans un même commit, plutôt que de tout enregistrer en vrac.

Le cycle de base tient donc en trois temps : tu modifies tes fichiers, tu ajoutes au staging ce que tu veux enregistrer (git add), puis tu commites avec un message clair (git commit -m). Entre ces étapes, une commande deviendra ton réflexe permanent : git status, qui te dit à tout moment où en sont tes fichiers — modifiés, en staging, ou déjà commités. En cas de doute, c'est toujours la première commande à lancer. Et git log --oneline te donne l'historique condensé de tes commits.

Un fichier mérite une attention particulière dès le premier projet : le .gitignore. Certains fichiers ne doivent jamais être versionnés — les dépendances installées (node_modules), les secrets (.env), les artefacts de build (dist, build). Tu les listes dans un fichier .gitignore à la racine, et Git les ignore purement et simplement. C'est loin d'être un détail : le pire accident de débutant·e, c'est de committer un fichier .env contenant une clé secrète. Git gardant tout dans son historique, la clé doit alors être considérée comme compromise même après suppression — il faut la régénérer immédiatement. Un bon .gitignore dès le départ t'épargne ce genre de frayeur.

Les trois zones de Git

• Working directory : ton dossier, où tu modifies les fichiers
• Staging area (index) : la zone où tu prépares ce qui ira dans le prochain commit
• Dépôt (repository) : l'historique des commits enregistrés

Le cycle de base : tu modifies → tu places dans le staging avec git add → tu enregistres avec git commit.

Les commandes essentielles

# Dans le dossier de ton projet
git init

# Voir l'état des fichiers en permanence
git status

# Ajouter un fichier au staging
git add README.md

# Tout ajouter (à utiliser avec un .gitignore propre)
git add .

# Enregistrer un commit avec un message clair
git commit -m "Init : structure du projet"

# Voir l'historique
git log --oneline

Le .gitignore : ce que Git ne doit pas suivre

Certains fichiers ne doivent jamais être versionnés : dépendances installées (node_modules), secrets (.env), artefacts de build (dist, build). Crée un fichier .gitignore à la racine :

node_modules/
.env
.env.local
dist/
build/
.DS_Store
*.log

Une branche est sans doute le concept qui inquiète le plus au début, alors qu'il est libérateur une fois compris. Imagine que tu puisses faire une copie parallèle de ton projet, y expérimenter librement une nouvelle fonctionnalité, et ne réintégrer le résultat que s'il te convient — le tout sans jamais mettre en péril la version qui marche. C'est exactement ce qu'est une branche : une ligne d'évolution indépendante. La branche principale, main, reste stable pendant que tu construis ailleurs.

Les branches servent au quotidien à isoler une fonctionnalité du code stable, à travailler à plusieurs sans s'écraser mutuellement, à pouvoir abandonner un essai raté sans conséquence, ou à préparer une livraison pendant que le développement continue. Les commandes tiennent en quelques verbes : git switch -c ma-branche crée une branche et bascule dessus, git branch les liste, git switch main revient sur la principale, git merge fusionne, et git branch -d supprime une branche devenue inutile. Adopte une convention de nommage qui dit l'intention : feat/ pour une fonctionnalité, fix/ pour un correctif, refactor/ ou docs/ pour le reste.

Une précision qui évite bien des confusions face aux vieux tutoriels : pour changer de branche, tu verras souvent git checkout. Depuis Git 2.23, la commande dédiée est git switch, plus claire car elle ne fait qu'une chose. L'ancienne checkout était surchargée (elle servait aussi à restaurer des fichiers, un rôle désormais dévolu à git restore). Prends l'habitude de switch pour les branches et de restore pour les fichiers : ton usage de Git en sera d'autant plus lisible.

Pourquoi des branches

• Isoler une nouvelle fonctionnalité du code stable
• Travailler à plusieurs sans s'écraser
• Pouvoir abandonner un essai sans bousiller main
• Préparer une release pendant que le dev continue ailleurs

Les commandes

# Créer une branche et basculer dessus
git switch -c feat/page-contact

# Lister les branches (l'actuelle est marquée *)
git branch

# Basculer sur une branche existante
git switch main

# Fusionner une branche dans la branche courante
git merge feat/page-contact

# Supprimer une branche fusionnée
git branch -d feat/page-contact

git switch vs git checkout

Les vieux tutos utilisent git checkout pour changer de branche. Depuis Git 2.23, la commande dédiée est git switch, plus claire. checkout reste pour restaurer des fichiers. Préfère switch pour les branches.

C'est le chapitre où beaucoup de débutant·es se découragent, non pas à cause de Git, mais à cause de l'authentification. Prends-le calmement : une fois configurée, tu n'y reviens plus. Le principe est simple : tu crées un dépôt vide sur GitHub (sans README ni .gitignore, pour éviter tout conflit avec ton dépôt local), puis tu le relies à ton projet et tu y pousses ton code. Le point qui coince, c'est la manière de prouver à GitHub que c'est bien toi.

Depuis 2021, GitHub n'accepte plus le simple mot de passe pour pousser en HTTPS. Deux options s'offrent à toi : un jeton d'accès personnel (PAT), que tu utilises comme un mot de passe temporaire, ou une clé SSH, plus confortable au quotidien. La clé SSH repose sur une paire de clés : une privée qui reste secrète sur ta machine, une publique que tu colles dans les réglages GitHub. Une fois en place, tu pousses sans jamais retaper d'identifiant. On génère la clé avec ssh-keygen -t ed25519 — le type ed25519 étant le standard moderne, court et sûr.

Relier le local au distant se fait ensuite en deux commandes. git remote add origin enregistre l'URL du dépôt GitHub sous le nom origin (la convention pour « le dépôt distant principal »). Puis git push -u origin main envoie ta branche pour la première fois. L'option -u (pour --set-upstream) est importante : elle lie ta branche locale à sa jumelle distante, si bien qu'ensuite un simple git push ou git pull saura tout seul où aller. Tu ne la mets qu'une fois par branche.

Créer un dépôt sur GitHub

Sur github.com, clique New repository. Donne-lui un nom, laisse-le vide (pas de README, pas de .gitignore) pour pouvoir y pousser ton dépôt local sans conflit.

Authentification : token ou clé SSH

Option recommandée : clé SSH

# Génère une clé SSH
ssh-keygen -t ed25519 -C "ton.email@exemple.fr"

# Affiche la clé publique pour la copier
cat ~/.ssh/id_ed25519.pub

Colle la clé publique sur GitHub : Settings → SSH and GPG keys → New SSH key. Ensuite, tu peux pousser sans jamais retaper de mot de passe.

Relier ton dépôt local

# Ajoute le remote (l'URL SSH du dépôt GitHub vide)
git remote add origin git@github.com:tonpseudo/mon-projet.git

# Pousse la branche main pour la première fois (-u : track)
git push -u origin main

Une fois connecté·e à GitHub, ton quotidien de dev suit un rythme régulier : récupérer ce que les autres ont fait, coder, pousser, recommencer. Tout commence souvent par git clone, qui récupère un dépôt existant dans son intégralité — tous les fichiers, tout l'historique, toutes les branches — et configure automatiquement le remote origin. C'est ainsi que tu démarres sur un projet d'équipe ou un projet open source : une seule commande, et tu as une copie complète sur ta machine.

Le cœur du travail collaboratif, c'est le cycle pull → code → push. Tu commences ta session par git pull pour intégrer les changements de tes collègues, tu codes et tu fais tes commits, puis tu partages ton travail avec git push. L'ordre compte : si tu pousses sans avoir récupéré ce que quelqu'un a poussé entre-temps, Git refuse pour ne pas écraser son travail. D'où le réflexe à ancrer dès maintenant : toujours git pull au début de chaque session de code. Ça t'évite la quasi-totalité des mauvaises surprises de synchronisation.

Reste la bête noire des débutant·es : le conflit de fusion. Il survient quand deux personnes ont modifié les mêmes lignes du même fichier : Git ne peut pas deviner laquelle garder, alors il te passe la main. Il insère dans le fichier des marqueurs (<<<<<<<, =======, >>>>>>>) qui délimitent ta version et celle des autres. Tu ouvres le fichier, tu choisis la bonne version (ou tu combines les deux), tu supprimes les marqueurs, puis tu fais git add et git commit. Rien de magique ni de dangereux : un conflit se résout, il ne s'efface pas — surtout pas avec un git reset --hard qui détruirait ton travail. Le scénario ci-dessous te fait justement dérouler cette résolution pas à pas.

Cloner un dépôt existant

git clone git@github.com:equipe/projet.git
cd projet

git clone récupère le dépôt complet : tout l'historique, toutes les branches, configurées automatiquement comme remote origin.

Le cycle pull → code → push

# Avant de coder : récupérer les changements des autres
git pull

# Tu codes, tu fais tes commits
git add .
git commit -m "feat: ajout du formulaire de contact"

# Tu pousses tes commits sur GitHub
git push

Gérer un conflit

Un conflit arrive quand deux personnes ont modifié les mêmes lignes du même fichier. Git ne sait pas choisir. Il te demande de trancher.

<<<<<<< HEAD
Texte de ta version locale
=======
Texte de la version distante
>>>>>>> origin/main

Ouvre le fichier, choisis la bonne version (ou fais un mélange), supprime les marqueurs <<<, ===, >>>, puis git add + git commit.

La pull request (PR) est le rituel central de la collaboration moderne, et l'une des compétences les plus regardées en entretien. L'idée : plutôt que de pousser directement tes changements sur main, tu proposes une modification isolée que l'équipe peut relire, commenter et valider avant qu'elle rejoigne le code stable. C'est à la fois un garde-fou qualité (rien n'entre sans relecture) et un formidable outil d'apprentissage (tu reçois des retours sur ton code). Sur GitHub, c'est le format de contribution universel.

Le flux, détaillé ci-dessous, est toujours le même : tu crées une branche dédiée, tu codes, tu la pousses, puis tu ouvres une pull request sur GitHub avec un titre clair et une description du pourquoi du changement. Tes coéquipier·es relisent et commentent ; tu réponds en poussant simplement de nouveaux commits sur la même branche — et c'est un point qui rassure beaucoup de débutant·es : la PR se met à jour toute seule à chaque push, inutile d'en rouvrir une. Une fois approuvée, tu la fusionnes d'un clic, puis tu supprimes la branche devenue inutile.

Au moment de fusionner, GitHub te propose trois boutons, et il vaut la peine de savoir lequel choisir. Squash and merge (recommandé en équipe) regroupe tous tes commits en un seul, propre, sur main : tes tâtonnements intermédiaires (« oups typo », « fix lint ») restent visibles dans la PR mais ne polluent pas l'historique principal. Merge commit conserve tous tes commits plus un commit de fusion. Rebase and merge rejoue tes commits sur main sans commit de fusion. En cas de doute, choisis le squash : un commit propre par fonctionnalité donne un historique lisible dont te remercieront toutes les personnes qui liront le projet plus tard.

Le flux complet

1. Tu crées une branche dédiée : git switch -c fix/typo-readme
2. Tu codes, tu commits
3. Tu pousses ta branche : git push -u origin fix/typo-readme
4. Sur GitHub, tu ouvres une Pull request avec un titre clair et une description du changement
5. Tes coéquipier·es relisent, commentent, demandent des ajustements
6. Tu pousses des commits supplémentaires sur la branche, la PR se met à jour automatiquement
7. Une fois approuvée, tu cliques Merge pull request sur GitHub
8. Tu supprimes la branche fusionnée (GitHub propose le bouton)

Squash, merge, rebase : quel bouton ?

• Squash and merge (recommandé pour les équipes) : tous tes commits deviennent un seul commit propre sur main
• Merge commit : garde tous tes commits + un commit de merge en plus
• Rebase and merge : rejoue tes commits sur main sans commit de merge

Git s'apprend en quelques heures, mais les bons réflexes font la différence entre une expérience sereine et une source de stress permanent. La bonne nouvelle : quelques habitudes prises dès le départ t'évitent l'immense majorité des galères classiques. La première concerne tes commits. Un bon commit porte une seule intention claire, pas douze sujets mélangés. Son message est court mais explicite, écrit à l'impératif : fix: gestion du null sur le formulaire de login vaut mille fois mieux qu'un vague update. Committe souvent, en petites bouchées : plus un commit est petit, plus il est facile à relire, à comprendre et, au besoin, à annuler.

Deuxième réflexe : savoir annuler proprement, car tout le monde se trompe. Pour abandonner des modifications non commitées d'un fichier, git restore. Pour annuler un commit déjà poussé sur une branche partagée, git revert : il crée un nouveau commit qui défait le précédent, sans réécrire l'histoire — c'est sûr pour les autres. Pour retoucher ton tout dernier commit avant de l'avoir poussé, git commit --amend. La commande à manier avec prudence est git reset --hard : elle détruit définitivement les modifications. Tant que rien n'est poussé, ce n'est pas grave ; mais sur une branche partagée, ne l'utilise jamais — préfère toujours git revert.

Dernier réflexe, et sans doute le plus précieux : en cas de doute, lance git status. Cette commande te dit exactement où tu en es — ce qui est modifié, ce qui est en staging, sur quelle branche tu te trouves — et te suggère même les commandes pour avancer. Complète-la avec git log --oneline --graph --all pour visualiser l'arborescence de tes branches, et git blame pour savoir qui a écrit telle ligne et quand. Avec ces trois commandes de lecture et les réflexes de commit et d'annulation, tu tiens de quoi te sortir de la quasi-totalité des situations. La check-list ci-dessous te propose d'ancrer tout ça sur un vrai projet cette semaine.

Des commits propres

• Un commit = une intention claire (pas 12 sujets dans le même commit)
• Message à l'impératif, court mais explicite : fix: gestion du null sur le formulaire de login
• Commits fréquents : plus c'est petit, plus c'est facile à relire et à annuler
• Conventions Conventional Commits (feat:, fix:, chore:...) facilitent les releases automatiques

Annuler proprement

# Annuler des modifs non commitées sur un fichier
git restore fichier.md

# Annuler un commit déjà poussé sur la branche partagée
# (crée un nouveau commit qui annule le précédent)
git revert <hash-du-commit>

# Modifier le dernier commit (avant push uniquement)
git commit --amend

Lire l'historique

# Historique condensé avec graphe des branches
git log --oneline --graph --all

# Voir les changements d'un commit
git show <hash>

# Voir qui a modifié quoi sur un fichier
git blame fichier.md