Apprendre Git pas à pas : commandes essentielles, branches, GitHub et Copilot dans VS Code

Apprendre Git, c’est apprendre à enregistrer l’historique de votre code sous forme d’étapes nommées, les commits, pour pouvoir revenir à une version qui fonctionnait, tester une idée sans risque et travailler à plusieurs sur les mêmes fichiers. Couplé à GitHub pour l’hébergement et à GitHub Copilot pour l’assistance par IA, c’est la base de tout développement moderne.

Ce guide s’adresse aux débutants en programmation, aux développeurs qui utilisent Git « par réflexe » sans le comprendre, aux intégrateurs web et aux data analysts qui versionnent leurs scripts. Vous y apprendrez à installer et configurer Git, à utiliser les commandes essentielles, à travailler avec les branches et GitHub, à annuler une erreur proprement et à tirer parti de Copilot dans VS Code.

Qu’est-ce que Git et GitHub ?

Git est un logiciel libre de gestion de versions : il enregistre l’état de vos fichiers à chaque étape validée (commit) dans un dépôt local, ce qui permet de comparer, restaurer et fusionner des versions. GitHub est une plateforme en ligne qui héberge ces dépôts, les partage et ajoute des outils de collaboration comme les pull requests.

Trois zones structurent le fonctionnement de Git :

Zone	Rôle	Commande pour y passer
Répertoire de travail	Vos fichiers tels que vous les modifiez	(modification des fichiers)
Zone de préparation (staging area)	Les modifications choisies pour le prochain commit	git add
Dépôt local	L’historique des commits, dans le dossier caché .git	git commit
Dépôt distant (GitHub)	La copie partagée en ligne	git push

Comprendre ces zones règle la majorité des incompréhensions des débutants : un fichier modifié n’est pas enregistré tant qu’il n’est pas ajouté puis commité, et un commit n’est pas partagé tant qu’il n’est pas poussé.

Pourquoi apprendre Git, même seul sur un projet ?

• Revenir en arrière : une modification a tout cassé ? Vous retrouvez l’état exact d’hier en une commande.
• Expérimenter sans risque : une branche permet de tester une idée, puis de l’abandonner ou de la garder.
• Comprendre l’historique : chaque commit dit qui a changé quoi, quand et pourquoi.
• Sauvegarder : le dépôt sur GitHub est une copie hors de votre machine.
• Collaborer : plusieurs personnes modifient le même projet, Git fusionne leurs travaux.
• Déployer : de nombreux hébergeurs publient automatiquement un site à chaque push.
• Être employable : Git est attendu dans quasiment toutes les offres d’emploi techniques.

Git ne sert pas qu’aux développeurs d’applications. Vos pages HTML et vos feuilles de style CSS, vos scripts Python ou vos requêtes SQL gagnent tous à être versionnés.

Comment apprendre Git : les commandes git essentielles pas à pas

Étape 1 — Installer et configurer Git

Téléchargez Git depuis le site officiel git-scm.com (sur Mac, il peut aussi s’installer avec les outils de développement Apple). Sur Windows, vous pourrez ensuite utiliser Git dans PowerShell, dans le terminal de VS Code ou dans Git Bash.

Vérifiez l’installation, puis déclarez votre identité, qui signera chacun de vos commits :

git --version
git config --global user.name "Votre Nom"
git config --global user.email "vous@exemple.fr"
git config --global init.defaultBranch main
git config --list

Utilisez la même adresse e-mail que votre compte GitHub pour que vos commits vous soient correctement attribués.

Étape 2 — Créer un dépôt et faire un premier commit

Placez-vous dans le dossier de votre projet et initialisez le dépôt :

cd mon-projet
git init
git status

git status est la commande à taper sans modération : elle indique la branche courante, les fichiers modifiés, ceux qui sont prêts à être commités et ceux que Git ne suit pas encore.

Ajoutez les fichiers à la zone de préparation, puis enregistrez le commit avec un message clair :

git add index.html styles.css
git add .                      # ou tous les fichiers modifiés du dossier
git commit -m "Ajoute la page d'accueil et la feuille de style"

Un bon message de commit décrit ce que fait le changement, à l’impératif et en une ligne : « Corrige l’affichage du menu sur mobile », pas « modifs » ou « ça marche ».

Étape 3 — Consulter l’historique et les différences

git log --oneline --graph      # historique compact, avec les branches
git diff                       # modifications non encore préparées
git diff --staged              # modifications préparées pour le prochain commit
git show a1b2c3d               # détail d'un commit précis

Chaque commit est identifié par un hash, dont les sept premiers caractères suffisent en général.

Étape 4 — Ignorer les fichiers inutiles avec .gitignore

Certains fichiers ne doivent jamais entrer dans l’historique : dépendances téléchargées, fichiers générés, réglages personnels et surtout secrets (mots de passe, clés d’API). Créez un fichier .gitignore à la racine :

# Dépendances et fichiers générés
node_modules/
dist/
__pycache__/

# Fichiers système et éditeur
.DS_Store
Thumbs.db
.vscode/

# Secrets : ne jamais les versionner
.env
*.key

Attention : un fichier déjà commité reste suivi même s’il est ajouté ensuite au .gitignore. Il faut alors le retirer du suivi avec git rm --cached nom-du-fichier.

Étape 5 — Travailler avec les branches git

Une branche est une ligne de développement indépendante. La branche main contient la version stable ; chaque nouvelle fonctionnalité se développe dans sa propre branche.

git branch                     # liste les branches
git switch -c menu-mobile      # crée la branche et s'y place
# ... modifications, add, commit ...
git switch main                # revient sur main
git merge menu-mobile          # fusionne la fonctionnalité dans main
git branch -d menu-mobile      # supprime la branche fusionnée

Si deux branches ont modifié les mêmes lignes, Git signale un conflit. Il insère des marqueurs dans le fichier concerné :

<<<<<<< HEAD
<h1>Bienvenue</h1>
=======
<h1>Bienvenue sur notre site</h1>
>>>>>>> menu-mobile

Choisissez la bonne version (ou combinez-les), supprimez les marqueurs, puis git add et git commit pour terminer la fusion. VS Code propose des boutons pour accepter l’une ou l’autre version, ce qui simplifie l’opération.

Étape 6 — Relier le projet à GitHub

Créez un compte sur GitHub, puis un nouveau dépôt vide (bouton New repository). Reliez votre dépôt local et envoyez votre branche :

git remote add origin https://github.com/votre-compte/mon-projet.git
git push -u origin main

L’option -u mémorise la branche distante : les fois suivantes, un simple git push suffit. À la première connexion, Git vous demande de vous authentifier ; le gestionnaire d’identifiants installé avec Git sur Windows ouvre une fenêtre de connexion à GitHub.

Étape 7 — Cloner et récupérer les modifications

Pour travailler sur un dépôt existant ou sur un autre ordinateur :

git clone https://github.com/votre-compte/mon-projet.git
cd mon-projet
git pull                       # récupère et fusionne les nouveautés du dépôt distant

Prenez l’habitude de lancer git pull avant de commencer à travailler : vous partez ainsi de la dernière version et réduisez les conflits.

Annuler des modifications sans tout casser

Savoir revenir en arrière est la raison d’être de Git. Choisissez la commande selon la situation :

Situation	Commande	Effet
Annuler les modifications d’un fichier non préparé	git restore fichier.html	Revient à la version du dernier commit (modifications perdues)
Retirer un fichier de la zone de préparation	git restore --staged fichier.html	Le fichier reste modifié, mais n’ira pas dans le prochain commit
Corriger le message du dernier commit (non poussé)	git commit --amend -m "Nouveau message"	Remplace le dernier commit
Annuler un commit déjà partagé	git revert a1b2c3d	Crée un nouveau commit inverse, historique conservé
Défaire les derniers commits locaux en gardant le travail	git reset --soft HEAD~1	Le commit disparaît, les modifications restent préparées
Revenir brutalement à un commit	git reset --hard a1b2c3d	Supprime commits et modifications suivants : à manier avec prudence
Mettre de côté un travail en cours	git stash, puis git stash pop	Range temporairement les modifications

La règle d’or : sur une branche déjà partagée, utilisez revert, jamais reset. Réécrire un historique que d’autres ont déjà récupéré crée des divergences difficiles à réparer.

Pull requests et bonnes pratiques de collaboration sur GitHub

Une pull request (PR) est une demande de fusion d’une branche dans une autre, affichée sur GitHub avec la liste des commits, les différences ligne par ligne et un espace de discussion. Le flux de travail classique :

1. créer une branche pour la fonctionnalité ;
2. commiter et pousser la branche (git push -u origin ma-branche) ;
3. ouvrir la pull request sur GitHub, avec un titre et une description qui expliquent le pourquoi du changement ;
4. faire relire : les collègues commentent des lignes précises, suggèrent des corrections, approuvent ;
5. fusionner, puis supprimer la branche.

Autres bonnes pratiques :

• des commits petits et cohérents, un sujet par commit ;
• un README clair à la racine : à quoi sert le projet, comment l’installer, comment le lancer, comment contribuer ;
• une protection de la branche main dans les réglages du dépôt, pour imposer une relecture avant toute fusion ;
• des tickets (issues) pour suivre bugs et idées, liés aux pull requests qui les résolvent.

Au quotidien, une session de travail bien menée suit toujours le même rituel : git switch main puis git pull pour partir de la dernière version, création d’une branche au nom explicite (correction-formulaire-contact), une série de petits commits au fil de l’avancement, git push en fin de session pour sauvegarder le travail sur GitHub, même inachevé, puis ouverture de la pull request quand la fonctionnalité est prête. Ce rituel prend quelques secondes et évite la quasi-totalité des situations délicates.

Pour les projets en équipe, convenez aussi d’une convention de nommage des branches (par exemple feature/, fix/, docs/ en préfixe) et d’une langue unique pour les messages de commit. La cohérence de l’historique compte autant que la qualité du code.

Un README minimal en Markdown ressemble à ceci :

# Mon projet

Site vitrine d'un atelier de menuiserie.

### Installation
1. Cloner le dépôt
2. Ouvrir index.html dans un navigateur

### Contribuer
Créez une branche, puis ouvrez une pull request vers main.

GitHub Copilot : coder plus vite avec l’IA dans VS Code

GitHub Copilot est un assistant d’intelligence artificielle intégré à VS Code et aux autres éditeurs pris en charge. Une fois l’extension installée et votre compte GitHub connecté, il intervient de plusieurs façons :

• Suggestions en ligne : pendant que vous tapez, Copilot propose la suite du code en gris ; la touche Tab l’accepte.
• Chat : vous posez une question sur le code sélectionné, demandez une explication, un test ou une correction d’erreur.
• Modifications sur plusieurs fichiers : vous décrivez un changement, Copilot propose les modifications à valider fichier par fichier.
• Mode agent : Copilot enchaîne lui-même plusieurs étapes (lire le projet, modifier des fichiers, lancer des commandes) pour accomplir une tâche, en vous demandant validation.
• Sur GitHub : il peut aider à résumer une pull request ou à relire du code, selon l’offre souscrite.

Pour que ses propositions respectent vos conventions, placez dans le dépôt un fichier d’instructions en Markdown, par exemple .github/copilot-instructions.md :

# Instructions pour Copilot
- Langage : JavaScript moderne (ES2020+), sans jQuery.
- Nommage : camelCase pour les variables, PascalCase pour les classes.
- Toujours commenter les fonctions publiques en français.
- Messages de commit à l'impératif, en français.

Notre conseil : relisez chaque proposition comme vous reliriez le code d’un collègue, et commitez souvent. Si une modification générée par l’IA casse le projet, Git vous permet de revenir immédiatement à l’état précédent : Copilot et Git forment un duo très complémentaire.

Les erreurs fréquentes quand on apprend Git

Erreur	Conséquence	Solution
Commiter un fichier de secrets (.env, clé d’API)	Secret exposé, même après suppression	Révoquer immédiatement le secret, ajouter le fichier au .gitignore
Travailler directement sur main	Historique désordonné, risques en équipe	Une branche par fonctionnalité
Commits énormes avec « modifs » comme message	Historique inutilisable	Petits commits, messages explicites
Oublier git pull avant de travailler	Conflits et push refusé	Toujours commencer par récupérer les nouveautés
Utiliser reset --hard sur une branche partagée	Divergences avec les collègues, travail perdu	Utiliser git revert
Push refusé (« rejected »)	Le distant contient des commits que vous n’avez pas	git pull, résoudre les conflits, puis git push
Paniquer après une erreur	Aggravation du problème	git status et git log d’abord : Git conserve presque tout

Git, GitHub, GitLab et Bitbucket : comparaison

Outil	Nature	Points forts
Git	Logiciel de gestion de versions	Local, rapide, standard du marché
GitHub	Plateforme d’hébergement de dépôts	Pull requests, communauté open source, Copilot, automatisations
GitLab	Plateforme d’hébergement, également installable sur ses serveurs	Intégration continue très complète, auto-hébergement
Bitbucket	Plateforme d’hébergement	Intégration avec les outils Atlassian
GitHub Desktop, interface de VS Code	Interfaces graphiques pour Git	Visualisation des changements, confort au quotidien

Les commandes Git sont les mêmes quelle que soit la plateforme : ce que vous apprenez avec GitHub s’applique partout.

Comment apprendre Git et progresser rapidement ?

Voici le parcours que nous conseillons :

1. Première heure : installation, configuration, init, status, add, commit, log, sur un petit dossier de test.
2. Deuxième heure : compte GitHub, remote, push, clone, pull, .gitignore et README.
3. Ensuite : branches, fusions, résolution d’un conflit volontairement provoqué, puis annulation avec restore, revert et reset.
4. Collaboration : ouvrir une pull request sur votre propre dépôt, la relire, la fusionner.
5. Productivité : installer Copilot, rédiger un fichier d’instructions et l’utiliser au quotidien sur un vrai projet, par exemple une application en JavaScript.

Pour suivre ce parcours de façon guidée, le cours complet sur Git, GitHub et GitHub Copilot d’EspritAcadémique dure 2 heures, sans prérequis. Il aborde notamment :

• l’installation, la configuration et l’usage de Git dans PowerShell ;
• la création d’un dépôt GitHub, le flux clone, pull et push, les branches et les fusions ;
• le fichier .gitignore et la rédaction d’un README efficace ;
• la navigation dans l’historique et l’annulation des modifications avec revert et reset ;
• la création et la validation d’une pull request ;
• GitHub Copilot et ses agents dans VS Code, jusqu’à la configuration d’un fichier d’instructions.

En résumé

Apprendre Git commence par le cycle add, commit, push et par une bonne compréhension des trois zones : répertoire de travail, préparation et dépôt. Ajoutez GitHub pour sauvegarder et collaborer, les branches et les pull requests pour travailler proprement, revert et restore pour corriger vos erreurs sans risque. Copilot accélère ensuite l’écriture du code, et Git vous permet d’annuler en un instant ce qui ne convient pas.