Guide complet Git et GitHub pour débutants : codez sans stress

⚡ En bref

Git versionne votre code en local ; GitHub héberge ce dépôt en ligne pour le partager et le sauvegarder.
Quatre commandes suffisent au démarrage : git add, git commit, git log et git restore.
Pour publier : git remote add origin, puis git push -u origin main.
Les branches et les pull requests protègent la version principale et structurent le travail à plusieurs.

Vous voulez apprendre Git et GitHub sans vous perdre dans le jargon et les schémas compliqués ? On va faire simple : à la fin de cet article, vous aurez déjà versionné un petit projet, envoyé votre code sur GitHub, créé une branche et ouvert une pull request. Oui, même si aujourd’hui, vous avez encore des dossiers nommés projet_final_v3_definitif sur votre bureau.

Les points :

Git et GitHub : enfin la différence, sans jargon
Votre premier réflexe avant de coder : installer et configurer Git
Créer un dépôt local sans se perdre dès la première commande
Les commandes que vous allez utiliser tous les jours
Envoyer son code sur GitHub sans blocage
Pourquoi les branches changent tout quand on débute
Pull requests, revue de code et travail en équipe
Un parcours balisé pour passer de la théorie à la pratique
Interface graphique ou terminal : comment choisir sans se compliquer la vie
Les erreurs de débutant qui font perdre du temps
Questions fréquentes

Git et GitHub : enfin la différence, sans jargon #

On commence par la confusion la plus courante. Git, c’est un système de contrôle de version. En clair, Git garde l’historique de vos fichiers, comme un historique intelligent de votre code. À chaque étape, vous enregistrez un “snapshot” de votre projet, qu’on appelle un commit. Vous pouvez revenir en arrière, comparer, tester, sans dupliquer des dossiers dans tous les sens.

GitHub, lui, c’est une plateforme en ligne qui héberge vos dépôts Git. Git travaille sur votre machine, GitHub héberge vos projets pour que vous les partagiez, collaboriez, ou simplement les sauvegardiez à distance. On peut très bien utiliser Git sans GitHub, mais franchement, dans la pratique, les deux vont ensemble dès qu’on veut montrer son travail ou coder en équipe.

Pour voir les deux outils fonctionner côte à côte avant de taper la moindre commande, ce tutoriel pas à pas fait le tour de l’essentiel :

🎬 Git and GitHub Tutorial for Beginners — Kevin Stratvert (2 M de vues)

Retenez une image simple : Git, c’est votre coffre-fort local d’historiques. GitHub, c’est la version en ligne de ce coffre, consultable par vous, vos collègues, ou la terre entière si vous le décidez.

Votre premier réflexe avant de coder : installer et configurer Git #

Avant de taper la moindre commande, il faut installer Git. Sur Windows, vous téléchargez l’installeur Git, suivant, suivant, terminé. Sur macOS, vous pouvez passer par Homebrew ou par le paquet officiel. Sur Linux, un simple sudo apt install git ou équivalent fait le job.

Ensuite, on règle l’identité. Dans votre terminal :

git config --global user.name "Votre Nom"
git config --global user.email "[email protected]"

Ces deux lignes indiquent à Git qui enregistre les modifications. C’est ce qui apparaîtra dans les historiques de commits. Vous pouvez aussi régler un éditeur de texte (par exemple VS Code) et activer les couleurs pour y voir plus clair. Un rapide git config --list vous montre tout ce que Git connaît de vous. Ce contrôle rapide évite les surprises plus tard.

Créer un dépôt local sans se perdre dès la première commande #

On attaque le concret. Résultat à viser : votre premier dépôt Git initialisé proprement. Vous créez d’abord un dossier de travail, par exemple portfolio pour un petit site vitrine. Vous placez vos fichiers HTML, CSS, JS ou ce que vous voulez dedans.

Dans ce dossier, vous ouvrez un terminal et vous tapez :

git init

Cette commande transforme votre dossier en dépôt Git. Git ajoute un sous-dossier caché .git qui stocke toute l’info de versionnement. Pour savoir où vous en êtes, vous prenez l’habitude d’utiliser git status. Cette commande vous dit si des fichiers sont nouveaux, modifiés, déjà enregistrés, etc. Un projet propre commence souvent par une structure simple : un dossier, quelques fichiers, et ce réflexe git status dès que vous hésitez.

Les commandes que vous allez utiliser tous les jours #

Au début, Git se résume à quatre commandes que vous allez utiliser en boucle : git add, git commit, git log et git restore. Le reste viendra plus tard.

git add, c’est comme remplir un panier avant de valider une commande. Vous dites à Git quels fichiers vous voulez enregistrer dans le prochain “snapshot”. Exemple : git add index.html style.css. Si vous voulez tout prendre d’un coup, git add . ajoute tous les fichiers suivis et nouveaux.

git commit valide le panier. Vous enregistrez l’état actuel des fichiers avec un message explicite : git commit -m "Ajout de la page d’accueil". Essayez d’éviter les messages vagues du style “update” ou “fix”. Un jour, vous serez content d’avoir des messages clairs quand vous relirez l’historique.

Pour voir ce que vous avez fait, git log liste vos commits. Vous y voyez l’auteur, la date, le message, l’identifiant unique. C’est votre ligne du temps. Et en cas de petit raté, git restore reprend un fichier modifié et le remet dans l’état du dernier commit. Utile quand on a tenté une expérimentation un peu trop ambitieuse.

Envoyer son code sur GitHub sans blocage #

Travailler en local, c’est bien. Publier votre code sur GitHub, c’est le moment où votre projet devient partageable, clonable, et sauvegardé à distance. La première étape consiste à créer un compte GitHub, à activer un mot de passe solide, voire un second facteur. On ne rigole pas avec la sécurité quand on commence à héberger du code.

Ensuite, sur GitHub, vous créez un nouveau dépôt. Vous choisissez un nom (par exemple portfolio-git), vous ajoutez un README automatique si vous voulez, et éventuellement un fichier .gitignore pour éviter d’envoyer des fichiers temporaires ou des secrets.

Dans votre dépôt local déjà initialisé, vous liez votre projet à celui de GitHub :

git remote add origin <URL_du_depot_GitHub>
git push -u origin main (ou master selon le nom de la branche principale)

git remote enregistre la connexion vers le dépôt distant, qu’on appelle souvent origin. git push envoie vos commits vers GitHub. Résultat : en quelques secondes, votre projet est en ligne. Vous pouvez le consulter via l’interface, voir les commits, les fichiers, les branches. Voir son code apparaître en ligne pour la première fois suffit souvent à comprendre que GitHub n’est pas réservé aux experts : c’est un espace de travail ordinaire.

Pourquoi les branches changent tout quand on débute #

Un des vrais déclics avec Git, ce sont les branches. Imaginez des routes parallèles pour votre projet. La branche principale (souvent main) reste stable. À côté, vous ouvrez une branche pour une nouvelle fonctionnalité ou un test risqué. Si ça se passe mal, la version principale reste intacte.

Pour créer une branche, vous utilisez git branch nom-de-branche. Pour y aller, aujourd’hui on recommande git switch nom-de-branche, plus clair et moderne que l’ancien git checkout. Vous travaillez, vous faites vos git add, vos git commit sur cette branche. Quand vous êtes satisfait, vous fusionnez dans la branche principale avec git merge nom-de-branche.

Cas très terre à terre : vous avez un site en production sur main, et une idée de refonte du header. Vous créez feature/header-nouveau, vous testez tranquillement. Si ça casse tout, ce n’est pas grave. La branche principale n’a pas bougé. Ce jeu de branches devient vite un réflexe, même pour un petit projet perso.

Pull requests, revue de code et travail en équipe #

GitHub prend tout son sens quand on commence la collaboration. Le scénario classique : vous créez une branche, vous poussez vos commits sur GitHub, puis vous ouvrez une pull request. C’est une demande de fusion : “voici mes modifications, est-ce qu’on les intègre dans la branche principale ?”

Dans la pull request, les autres voient les différences ligne par ligne, commentent, suggèrent des ajustements. On discute, on corrige, puis on valide la fusion. Ce workflow GitHub basique suffit déjà pour travailler à deux ou trois sur un petit projet JS, Python ou PHP. Les conflits de fusion (les fameux merge conflicts) font peur au début, mais avec un peu de méthode et un éditeur qui vous montre les différences, on en sort assez vite.

Un parcours balisé pour passer de la théorie à la pratique #

Parlons d’Eduforma, parce que c’est typiquement le genre de ressource qui change la donne quand on se lance. Leur formation “Git et GitHub pour les débutants : versionner son code pas à pas” suit une progression ultra concrète : installation, git init, git add, git commit, git push, branches, pull requests. Pas de concepts tirés par les cheveux, on reste sur les commandes que vous utiliserez réellement en 2026.

👉 L’approche est nettement scénarisée : on part de zéro, on suit un workflow simple, on applique directement sur un projet réel. Si vous voulez débuter avec Git et GitHub sans perdre des heures à jongler entre dix tutoriels contradictoires, ce parcours est franchement une valeur sûre. Eduforma ne s’amuse pas à faire du blabla, le contenu est orienté pratique, étape par étape.

Interface graphique ou terminal : comment choisir sans se compliquer la vie #

Question qui revient tout le temps : faut-il utiliser une interface graphique comme GitHub Desktop, ou la ligne de commande ? Pour apprendre, disons-le cash : la console reste plus formatrice. Voir les commandes Git explicites, taper git status, git add, git commit, ça aide vraiment à comprendre ce qui se passe.

Cela dit, tout le monde n’a pas envie de vivre uniquement dans un terminal. Les interfaces visuelles comme GitHub Desktop ou les intégrations dans VS Code montrent l’état des fichiers, les branches, les différences, avec des boutons. Un bon compromis consiste à démarrer avec la ligne de commande pour les bases, puis à utiliser l’interface graphique pour la revue de code et les pull requests.

Les erreurs de débutant qui font perdre du temps #

Se tromper avec Git, c’est normal. Vraiment. Les erreurs fréquentes reviennent souvent : oublier de faire un commit avant un push, travailler sur la mauvaise branche, pousser un fichier de configuration contenant des secrets, ignorer les messages de git status pendant des jours.

Un exemple classique : vous modifiez un fichier, puis vous tapez git push directement. Git vous répond qu’il n’y a rien à envoyer, parce que vous n’avez pas fait de git add ni de git commit. Autre scénario : vous pensez être sur main, en réalité vous êtes sur une branche de test et vous poussez là-dessus. D’où l’importance de vérifier la branche active avec git status ou l’indicateur de votre IDE.

Réflexes simples à adopter :

Regarder git status avant chaque gros commit.
Utiliser des messages de commit lisibles, même pour un petit projet perso.
Exclure les secrets (API keys, mots de passe) avec un fichier .gitignore.

Quand vous faites une “grosse bêtise”, la première chose à faire est de respirer, ensuite de chercher comment annuler, revert, ou demander de l’aide. Git garde une trace, ce n’est pas comme un simple copier-coller de dossiers où tout disparaît sans retour.

🎯 À retenir

Configurez user.name et user.email dès l’installation : c’est ce qui signe vos commits.
Prenez le réflexe git status avant chaque commit — la plupart des erreurs de débutant viennent de là.
Excluez les secrets (clés d’API, mots de passe) avec un .gitignore dès le premier dépôt.
Apprenez d’abord en ligne de commande, gardez l’interface graphique pour la revue de code.

Questions fréquentes #

Faut-il un compte GitHub pour utiliser Git ?

Non. Git fonctionne entièrement en local : vous pouvez versionner un projet sans jamais créer de compte. GitHub sert à héberger le dépôt en ligne, à le partager et à le sauvegarder.

Pourquoi git push répond-il qu’il n’y a rien à envoyer ?

Parce que les modifications n’ont pas été enregistrées. Repassez par git add puis git commit, vérifiez l’état avec git status, et poussez ensuite.

main ou master : quel nom de branche principale ?

main est le nom par défaut sur GitHub aujourd’hui. Les dépôts plus anciens utilisent encore master. Vérifiez le nom réel avec git status avant votre premier push.

git switch ou git checkout pour changer de branche ?

git switch est la commande recommandée aujourd’hui : elle ne fait que changer de branche, là où git checkout cumule plusieurs usages et prête à confusion.