Git et GitHub : quelle différence et comment ils fonctionnent ensemble

On confond sans cesse Git et GitHub, alors qu'ils ne sont pas du même niveau. Git est un logiciel de gestion de versions que vous installez sur votre ordinateur : il mémorise chaque état enregistré du projet et permet d'y revenir. GitHub est un service web qui héberge des copies de dépôts Git et autour duquel sont construits des outils de travail en équipe. Pour retenir : Git est le moteur, GitHub le garage avec atelier où l'on peut installer ce moteur.

Qu'est-ce que Git

Git est un système de gestion de versions distribué. Linus Torvalds l'a créé en 2005 pour le développement du noyau Linux, et il est depuis devenu le standard de l'industrie. Git fonctionne entièrement en local : l'historique est stocké dans le dossier caché .git du projet, et la plupart des opérations ne nécessitent pas Internet.

Le mot « distribué » est essentiel. Chaque participant possède sur son ordinateur une copie complète du dépôt avec tout l'historique, et pas seulement les derniers fichiers. Si le serveur disparaît, le projet peut être restauré depuis n'importe quel poste.

Ce que Git sait faire à lui seul :

• enregistrer les modifications sous forme de commits — des instantanés du projet avec auteur, date et description ;
• montrer qui a modifié une ligne précise, quand et pourquoi (git log, git blame) ;
• mener des lignes de développement parallèles dans des branches et les fusionner ;
• annuler des erreurs sans perdre le reste du travail ;
• échanger l'historique avec d'autres dépôts via git push, git pull et git fetch.

Git est un outil en ligne de commande. Les clients graphiques et les panneaux intégrés aux éditeurs (VS Code, IntelliJ IDEA) ne sont que des surcouches qui appellent les mêmes commandes.

Qu'est-ce que GitHub

GitHub est une plateforme cloud d'hébergement de dépôts Git, qui appartient aujourd'hui à Microsoft. Vous y créez un dépôt, y envoyez votre code local avec git push, et il devient accessible à vos collègues, à un employeur ou à tout Internet si le dépôt est public.

Mais la valeur de GitHub ne se limite pas au stockage. Autour du dépôt, GitHub ajoute ce que Git ne propose pas :

• Pull request — une demande de fusion de branche avec discussion et revue de code ligne par ligne ;
• Issues — tâches et rapports de bug rattachés au projet ;
• GitHub Actions — CI/CD : lancement automatique des tests, du build et du déploiement à chaque push ;
• gestion des accès — qui peut lire, écrire, fusionner dans les branches protégées ;
• profil de développeur — graphe d'activité et projets publics que consultent les recruteurs ;
• GitHub Pages — hébergement gratuit de sites statiques directement depuis le dépôt.

Les recherches comme « git com » ou « git hub » désignent généralement ce service, dont l'adresse est github.com. Le site officiel de Git lui-même est git-scm.com, d'où l'on télécharge l'installateur.

Git et GitHub : comparatif en tableau

Comment Git et GitHub fonctionnent ensemble

Le lien entre les deux, c'est le remote, le dépôt distant. Le dépôt local conserve l'adresse du dépôt GitHub sous un nom court, origin par défaut. L'échange passe ensuite par trois commandes :

• git push — envoyer vos nouveaux commits sur le serveur ;
• git fetch — télécharger les commits des autres sans toucher à vos fichiers ;
• git pull — télécharger et intégrer aussitôt les changements dans la branche courante (en pratique fetch + merge ou rebase).

Important : GitHub ne voit pas votre code tant que vous ne l'avez pas envoyé. Un commit n'existe qu'en local jusqu'au premier git push. D'où l'erreur fréquente des débutants : « j'ai commité, mais rien n'apparaît sur GitHub ».

Parcours typique : du projet local à GitHub

# 1. On crée le dépôt en local
cd my-project
git init
git add .
git commit -m "Premier commit"

# 2. On crée un dépôt vide sur github.com (sans README),
#    on copie son adresse et on l'ajoute comme remote
git remote add origin git@github.com:username/my-project.git

# 3. On renomme la branche en main et on envoie
git branch -M main
git push -u origin main

L'option -u (forme longue --set-upstream) relie la branche locale main à la branche distante. Ensuite, un simple git push ou git pull sans argument suffit.

Parcours inverse : partir d'un dépôt GitHub

Si le projet est déjà sur GitHub, on ne le recrée pas, on le clone :

git clone https://github.com/username/my-project.git
cd my-project

La commande télécharge tout l'historique et configure automatiquement le remote origin.

Authentification : SSH ou HTTPS

Depuis 2021, GitHub n'accepte plus le mot de passe du compte pour Git en HTTPS. Deux options fonctionnent.

HTTPS + Personal Access Token. Le token se crée dans les paramètres du compte (Settings → Developer settings) et se saisit à la place du mot de passe. Pour éviter de le retaper, Git utilise un gestionnaire d'identifiants — sous Windows, il est installé avec Git for Windows.

Clés SSH. L'option que les employeurs s'attendent à vous voir configurer seul :

# On génère la clé
ssh-keygen -t ed25519 -C "you@example.com"

# On affiche la partie publique et on l'ajoute sur GitHub :
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# On teste la connexion
ssh -T git@github.com

En cas de succès, GitHub répond par un message de bienvenue avec votre identifiant et précise que l'accès shell n'est pas fourni — c'est normal. L'adresse du dépôt doit alors être au format git@github.com:user/repo.git, et non https://.

Si le dépôt est déjà relié en HTTPS, on le bascule en SSH en une commande :

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab et les autres : quelles différences

GitHub n'est pas le seul hébergeur Git. Tous utilisent le même Git, si bien qu'un dépôt peut passer de l'un à l'autre sans perte d'historique. Ils se distinguent par les outils proposés autour du code.

Dans GitLab, la demande de fusion s'appelle merge request, dans GitHub pull request, mais le principe est le même : proposer les changements d'une branche et en discuter avant la fusion. La terminologie diffère, les commandes Git sont identiques.

Un dépôt local peut avoir plusieurs remotes à la fois, par exemple pour publier le projet en miroir sur GitHub et GitLab :

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

Ai-je besoin de GitHub si je travaille seul ?

Techniquement non : Git fonctionne très bien en local. Mais un dépôt distant offre trois vrais avantages, même pour un projet solo.

• Sauvegarde. Votre portable tombe en panne — le code et tout l'historique sont intacts sur le serveur.
• Travail sur plusieurs machines. À la maison et au bureau, vous vous synchronisez avec push et pull.
• Portfolio. Pour un poste junior, le profil GitHub est souvent consulté avant le CV : projets vivants, messages de commit soignés, README.

Par où commencer quand on débute

Inutile d'apprendre Git et GitHub en même temps — l'ordre compte. Maîtrisez d'abord le cycle local : git init, git status, git add, git commit, git log, les branches et la fusion. Quand tout cela marche sans aide, créez un compte GitHub, configurez SSH et apprenez push, pull, fetch. Dernière étape : le processus d'équipe — fork, branche par tâche, pull request, revue.

Ce qu'un employeur regarde sur votre GitHub

Les petits carrés verts d'activité ne sont pas l'essentiel. Un relecteur expérimenté évalue en deux minutes autre chose :

• des messages de commit clairs au lieu de « fix », « 123 », « modifs » ;
• des commits petits et logiques, pas un unique commit géant « ajout du projet » ;
• un README qui explique comment lancer le projet ;
• un fichier .gitignore : pas de node_modules, de .env avec des mots de passe ni de fichiers d'IDE dans le dépôt ;
• des branches et des pull requests même dans les projets d'apprentissage — cela montre que vous connaissez le travail en équipe.

Erreurs fréquentes des débutants

« fatal: not a git repository »

Vous lancez une commande Git en dehors d'un dépôt. Placez-vous dans le dossier du projet ou exécutez git init. Le compte GitHub n'y est pour rien — c'est une erreur locale de Git.

« Permission denied (publickey) »

La clé SSH n'a pas été créée, n'a pas été ajoutée sur GitHub ou n'est pas chargée dans ssh-agent. Vérifiez ssh -T git@github.com et la liste des clés dans les paramètres du compte.

« rejected … (fetch first) » lors du push

Le serveur contient des commits que vous n'avez pas — par exemple, vous avez créé le dépôt GitHub avec un README. Récupérez d'abord les changements : git pull --rebase origin main, puis relancez git push. N'utilisez pas --force tant que vous ne savez pas quel travail vous allez écraser.

Des secrets dans un dépôt public

Un mot de passe ou une clé d'API entré une fois dans un commit reste dans l'historique, même si le fichier est supprimé ensuite. Il faut révoquer et régénérer cette clé immédiatement, et ajouter .env au .gitignore dès le départ.

Conclusion

Git est l'outil de gestion de versions sur votre ordinateur ; GitHub est le service où ces dépôts vivent dans le cloud et autour duquel s'organise le travail en équipe. GitLab, Bitbucket et les autres sont des alternatives à GitHub, pas à Git : sous le capot, ce sont les mêmes commits, branches et commandes. Commencez par Git en local, puis ajoutez un remote et configurez SSH. La liaison d'un dépôt local à GitHub, push, pull et fetch sont pratiqués dans le cours Git.