Git et GitHub 2026: Les Bases pour Tout Développeur

Tu veux devenir développeur, ou juste arrêter de paniquer dès qu’un recruteur te demande “tu maîtrises Git ?”. Je te rassure, tu n’es pas seul. Beaucoup de candidats savent coder un peu, suivre un tuto React, faire une API Node, mais dès qu’il faut versionner proprement, créer une branche, régler un conflit ou pousser sur GitHub, c’est le brouillard total.

Et pourtant, en 2026, Git et GitHub ne sont plus “des bonus”. Ce sont des bases. Chez Doctolib, Back Market, BlaBlaCar, Ledger, L’Oréal, BNP ou TotalEnergies, tu peux être junior, alternant, data analyst, développeur web ou ingénieur logiciel, on attend de toi que tu comprennes au moins le workflow de base.

La bonne nouvelle, c’est que tu n’as pas besoin de devenir expert Git en une semaine. Tu dois surtout comprendre les bons réflexes, savoir collaborer sans casser le travail des autres, et montrer sur ton CV que tu sais utiliser les outils du métier.

Pourquoi Git est devenu indispensable en 2026#

Git, c’est l’outil qui permet de suivre l’historique de ton code.

Imagine que tu travailles sur une application. Tu modifies un fichier, puis un autre, puis tu casses tout sans savoir pourquoi. Sans Git, tu pleures. Avec Git, tu peux revenir à une version précédente, comparer les changements, comprendre ce qui a bougé, et travailler avec d’autres développeurs sans envoyer des fichiers ZIP nommés projet-final-vraiment-final-v3.

GitHub, lui, est une plateforme qui héberge tes projets Git en ligne. C’est aussi une vitrine. Quand un recruteur tech regarde ton profil, il peut voir :

• Tes projets personnels
• Ton style de code
• Ta régularité
• Ta capacité à documenter
• Tes contributions
• Ton niveau de collaboration

Pour un poste de développeur junior à Paris, Lyon, Lille, Nantes ou remote, les salaires tournent souvent entre €36k et €45k brut annuel. Pour un profil confirmé, tu peux viser €50k à €70k, parfois plus sur des stacks très demandées comme React, TypeScript, Java, Python, DevOps ou cybersécurité.

Mais si ton GitHub est vide, désorganisé ou rempli de projets sans README, tu perds une occasion simple de rassurer.

Git vs GitHub : comprends bien la différence#

C’est une confusion très fréquente.

Git, c’est l’outil sur ta machine

Git est installé sur ton ordinateur. Il suit les versions de ton projet localement.

Avec Git, tu peux :

1. Enregistrer des versions de ton code
2. Revenir en arrière
3. Créer des branches
4. Fusionner du code
5. Comparer des changements

Tu l’utilises dans ton terminal, dans VS Code, ou via des interfaces comme GitKraken ou GitHub Desktop.

GitHub, c’est la plateforme en ligne

GitHub permet d’héberger ton code à distance.

Avec GitHub, tu peux :

• Partager un projet avec un recruteur
• Collaborer avec une équipe
• Créer des pull requests
• Suivre des issues
• Déployer certains projets
• Participer à l’open source

En gros : Git est le moteur, GitHub est le garage partagé où tout le monde peut voir et travailler sur le véhicule.

Les commandes Git que tu dois absolument connaître#

Tu n’as pas besoin de mémoriser 150 commandes. Si tu maîtrises celles-ci, tu es déjà dans le bon wagon.

1. git init

Cette commande transforme un dossier classique en projet suivi par Git.

git init

Tu l’utilises quand tu démarres un projet localement.

Exemple :

mkdir portfolio
cd portfolio
git init

Là, Git commence à suivre ton projet.

2. git status

C’est probablement la commande que tu vas taper le plus souvent.

git status

Elle te dit :

• Quels fichiers ont été modifiés
• Quels fichiers sont prêts à être enregistrés
• Sur quelle branche tu es
• S’il y a des changements non suivis

Réflexe de base : quand tu es perdu, tape git status.

3. git add

Avant d’enregistrer une version, tu dois indiquer à Git quels fichiers tu veux inclure.

git add index.html

Ou pour tout ajouter :

git add .

Attention, git add . est pratique, mais ne l’utilise pas les yeux fermés. Tu peux ajouter par erreur des fichiers inutiles, des logs, ou pire, des clés API.

4. git commit

Un commit, c’est une photo de ton code à un moment précis.

git commit -m "Ajoute la page d'accueil"

Ton message doit être clair. Évite :

git commit -m "modif"

Préférable :

git commit -m "Corrige le formulaire de connexion"

Un bon commit aide ton équipe, et ton futur toi dans trois semaines.

5. git log

Pour voir l’historique des commits :

git log

Version plus lisible :

git log --oneline

Tu verras une liste courte avec les identifiants de commits.

6. git branch

Pour afficher tes branches :

git branch

Pour créer une branche :

git branch feature-login

Une branche te permet de travailler sur une fonctionnalité sans toucher directement à la version principale.

7. git checkout ou git switch

Ancienne commande très utilisée :

git checkout feature-login

Commande plus récente et plus claire :

git switch feature-login

Pour créer et aller directement sur une branche :

git switch -c feature-login

8. git merge

Une fois ta fonctionnalité terminée, tu peux la fusionner dans la branche principale.

git switch main
git merge feature-login

Dans une vraie entreprise, tu ne fais pas toujours ça directement en local. Tu passes souvent par une pull request sur GitHub.

9. git clone

Pour récupérer un projet depuis GitHub :

git clone https://github.com/utilisateur/projet.git

C’est ce que tu fais quand tu rejoins une équipe ou quand tu veux lancer un projet open source sur ta machine.

10. git pull

Pour récupérer les changements récents depuis GitHub :

git pull

Très important quand tu travailles en équipe. Avant de coder pendant trois heures, fais souvent un git pull.

11. git push

Pour envoyer tes commits vers GitHub :

git push

Si c’est une nouvelle branche :

git push -u origin feature-login

C’est comme ça que ton travail devient visible en ligne.

Le workflow simple à connaître pour travailler en équipe#

Si tu postules chez BlaBlaCar, Doctolib ou Back Market, tu ne vas pas coder directement sur main comme dans un tuto du dimanche.

En général, le workflow ressemble à ça :

1. Tu récupères la dernière version du projet
2. Tu crées une branche
3. Tu codes ta fonctionnalité
4. Tu fais des commits propres
5. Tu pousses ta branche sur GitHub
6. Tu ouvres une pull request
7. Tes collègues relisent
8. Tu corriges si besoin
9. La branche est fusionnée

Exemple concret

Tu dois ajouter une page de profil utilisateur.

Tu peux faire :

git pull
git switch -c feature-user-profile

Puis tu codes.

Ensuite :

git status
git add .
git commit -m "Ajoute la page profil utilisateur"
git push -u origin feature-user-profile

Sur GitHub, tu ouvres une pull request vers main.

Dans la description, tu expliques :

• Ce que tu as ajouté
• Comment tester
• Les éventuels points à surveiller
• Le ticket associé si l’équipe utilise Jira, Linear ou GitHub Issues

Un junior qui fait ça proprement inspire confiance.

Les pull requests : ton vrai test de professionnalisme#

Une pull request, souvent appelée PR, n’est pas juste un bouton à cliquer. C’est un moment où ton code est lu.

Et là, tout compte :

• Le nom de ta branche
• Le nombre de fichiers modifiés
• La clarté de tes commits
• La description de ta PR
• Ta réaction aux commentaires
• Ta capacité à corriger sans te vexer

Un bon développeur ne voit pas la review comme une attaque. Il la voit comme une sécurité collective.

Exemple de mauvaise PR

Titre :

update

Description :

modifs diverses

Fichiers modifiés : 47.

Aucun test.

Là, tu fatigues toute l’équipe.

Exemple de bonne PR

Titre :

Ajoute la réinitialisation du mot de passe

Description :

Cette PR ajoute le parcours de réinitialisation du mot de passe.

Changements :
- Ajout du formulaire email
- Ajout de la page de confirmation
- Gestion des erreurs API
- Ajout des tests du composant ResetPasswordForm

Test :
- Lancer npm test
- Tester manuellement avec un email valide et invalide

Là, tu montres que tu penses comme un pro.

Les conflits Git : pas grave, mais à gérer calmement#

Un conflit arrive quand Git ne sait pas fusionner automatiquement deux changements.

Exemple : toi et un collègue modifiez la même ligne dans le même fichier. Git te dit : “je ne sais pas quelle version garder”.

Tu peux voir quelque chose comme :

<<<<<<< HEAD
const title = "Connexion";
=======
const title = "Se connecter";
>>>>>>> feature-login

Tu dois choisir la bonne version, supprimer les marqueurs, sauvegarder, puis refaire un commit.

Méthode simple pour résoudre un conflit

1. Respire, ce n’est pas la fin du monde
2. Ouvre le fichier concerné
3. Repère les zones entre <<<<<<<, =======, >>>>>>>
4. Choisis le bon code
5. Supprime les marqueurs
6. Lance les tests
7. Fais git add
8. Fais git commit

Dans VS Code, les conflits sont plus visuels. Tu peux accepter la version actuelle, la version entrante, ou combiner les deux.

Les erreurs Git classiques chez les débutants#

Tu vas probablement en faire. Ce n’est pas honteux, mais autant les éviter.

1. Committer des fichiers sensibles

Ne pousse jamais :

• Fichiers .env
• Clés API
• Mots de passe
• Tokens
• Fichiers de configuration privée
• Données client

Si tu travailles sur un projet qui ressemble à une app fintech comme Ledger ou une plateforme santé comme Doctolib, la sécurité n’est pas un détail.

Ajoute un .gitignore.

Exemple :

node_modules/
.env
dist/
.DS_Store

2. Faire des commits énormes

Un commit qui mélange login, design, correction typo, refactor API et changement de base de données, c’est pénible à relire.

Préférable :

• Un commit pour le login
• Un commit pour les tests
• Un commit pour la correction visuelle
• Un commit pour le nettoyage

3. Travailler sur main

En équipe, évite de coder directement sur main.

Crée une branche :

git switch -c fix-navbar-mobile

4. Ne jamais faire git pull

Si tu ne récupères pas les changements des autres, tu avances sur une version ancienne du projet. Résultat : conflits, bugs, frustration.

Le matin, avant de coder :

git pull

5. Écrire des messages de commit inutiles

Évite :

• test
• ok
• final
• fix
• changes
• aaaa

Utilise des phrases simples :

• Ajoute la validation du formulaire
• Corrige l'affichage mobile du header
• Supprime le code inutilisé dans AuthService

GitHub comme portfolio : ce que les recruteurs regardent vraiment#

Tu n’as pas besoin d’avoir 200 contributions vertes. Mais si tu postules comme développeur junior à €38k, ton GitHub peut vraiment t’aider.

Un recruteur ou un tech lead peut regarder :

1. Tes dépôts publics
2. Tes README
3. La structure de tes projets
4. La clarté de ton code
5. Tes commits
6. Tes technos utilisées
7. Ta capacité à finir un projet

Un bon projet GitHub, c’est quoi ?

Pas forcément une app incroyable.

Un bon projet peut être :

• Une todo app bien codée avec tests
• Un clone simplifié de Doctolib pour réserver un rendez-vous
• Une app de suivi budget
• Un mini outil RH pour suivre des candidatures
• Un dashboard météo avec API
• Un portfolio Next.js
• Une API REST Node.js avec auth
• Un projet Python d’analyse de données

Ce qui compte, c’est la finition.

Ton README doit vendre le projet

Ton README doit répondre vite à ces questions :

• C’est quoi le projet ?
• Pourquoi tu l’as fait ?
• Quelles technos ?
• Comment l’installer ?
• Comment le lancer ?
• Quelles fonctionnalités ?
• Quelles captures d’écran ?
• Quels apprentissages ?

Exemple de structure :

# Job Tracker

Application pour suivre ses candidatures.

## Fonctionnalités

- Ajout d'une candidature
- Statut : envoyé, entretien, refus, offre
- Filtre par entreprise
- Authentification utilisateur

## Stack

- React
- TypeScript
- Node.js
- PostgreSQL

## Installation

npm install
npm run dev

Simple, clair, efficace.

GitHub Actions : le petit plus qui fait pro#

GitHub Actions permet d’automatiser des tâches.

Par exemple :

• Lancer les tests à chaque pull request
• Vérifier le format du code
• Déployer une application
• Construire un projet
• Scanner certaines dépendances

Tu n’as pas besoin d’être expert DevOps, mais savoir dire en entretien “j’ai ajouté une GitHub Action pour lancer les tests automatiquement” fait sérieux.

Exemple de fichier simple :

name: Tests

on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Installer Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm test

Pour un poste junior DevOps ou full-stack, ce genre de détail peut te différencier.

Chez BNP ou TotalEnergies, où les process sont souvent plus cadrés, montrer que tu comprends l’intégration continue est un vrai plus.

GitHub Copilot, IA et Git en 2026#

En 2026, beaucoup d’équipes utilisent des assistants IA comme GitHub Copilot, Cursor ou ChatGPT pour coder plus vite.

Mais attention : l’IA ne remplace pas Git.

Au contraire, si tu génères du code avec une IA sans versionner correctement, tu peux vite te retrouver avec :

• Des fichiers modifiés partout
• Du code que tu ne comprends pas
• Des bugs difficiles à isoler
• Des commits énormes et flous

Le bon réflexe :

1. Tu crées une branche
2. Tu demandes à l’IA une petite modification ciblée
3. Tu relis tout
4. Tu testes
5. Tu commits avec un message clair

L’IA peut accélérer. Git garde le contrôle.

Comment apprendre Git sans te noyer#

Tu n’as pas besoin de faire un cours de 30 heures avant de pratiquer. Le mieux, c’est d’apprendre en construisant.

Plan simple sur 7 jours

Jour 1 : installer Git et créer ton premier dépôt

• Installe Git
• Configure ton nom et ton email
• Crée un dossier
• Fais git init
• Fais ton premier commit

Commandes :

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

Jour 2 : créer un projet simple

Fais une petite page HTML, une app React, ou un script Python.

Objectif : pratiquer status, add, commit.

Jour 3 : connecter à GitHub

• Crée un compte GitHub
• Crée un repo
• Ajoute le remote
• Fais ton premier push

git remote add origin https://github.com/username/projet.git
git push -u origin main

Jour 4 : pratiquer les branches

Crée une branche par fonctionnalité.

git switch -c feature-contact-form

Code, commit, puis merge.

Jour 5 : créer une pull request

Même si tu travailles seul, entraîne-toi à créer une PR. Décris ce que tu as fait. Relis ton propre code.

Jour 6 : provoquer et résoudre un conflit

Oui, fais-le exprès.

Modifie la même ligne sur deux branches, puis fusionne. Tu vas comprendre beaucoup plus vite.

Jour 7 : améliorer le README

Ajoute :

• Description
• Installation
• Captures d’écran
• Stack technique
• Fonctionnalités
• Lien de démo si possible

À la fin de la semaine, tu as déjà un projet présentable.

Comment parler de Git sur ton CV#

Ne mets pas juste “Git” dans une liste si tu ne sais pas t’en servir. Mais si tu maîtrises les bases, montre-le intelligemment.

Exemple dans les compétences

Outils : Git, GitHub, GitHub Actions, VS Code, Docker, Jira

Exemple dans une expérience

- Utilisation de Git et GitHub en workflow branches, pull requests et code reviews sur une application React/Node.js

Exemple pour un projet personnel

- Développement d'une application de suivi de candidatures, versionnée avec Git, documentée sur GitHub, avec README, issues et déploiement Vercel

Ça montre une pratique concrète.

Pour un poste développeur junior chez L’Oréal Tech ou une startup comme Back Market, ce genre de formulation peut peser plus qu’une simple ligne “Git”.

Comment parler de Git en entretien#

On peut te poser des questions simples :

“C’est quoi la différence entre Git et GitHub ?”

Réponse claire :

Git est l’outil de versioning qui suit l’historique du code. GitHub est une plateforme qui héberge des dépôts Git et facilite la collaboration via pull requests, issues et reviews.

“Tu fais quoi avant de commencer une nouvelle fonctionnalité ?”

Bonne réponse :

Je récupère la dernière version avec git pull, je crée une branche dédiée, je développe, je fais des commits clairs, puis j’ouvre une pull request pour review.

“Tu as déjà géré un conflit Git ?”

Même si c’était sur un projet perso, tu peux dire :

Oui, j’ai déjà eu un conflit sur deux modifications de la même ligne. J’ai ouvert le fichier, comparé les deux versions, gardé le code correct, supprimé les marqueurs de conflit, testé, puis validé la résolution avec un commit.

Simple, crédible, pro.

Les commandes bonus utiles quand tu progresses#

Quand tu es à l’aise avec les bases, tu peux apprendre ces commandes.

git diff

Voir ce qui a changé avant d’ajouter ou commit :

git diff

git stash

Mettre temporairement de côté des changements :

git stash

Puis les récupérer :

git stash pop

Très utile si tu dois changer de branche rapidement.

git reset

À utiliser avec prudence.

Pour retirer un fichier de la zone d’ajout :

git reset fichier.js

git revert

Pour annuler un commit en créant un nouveau commit inverse :

git revert abc123

C’est souvent plus sûr que reset en équipe.

Ce que ton profil GitHub doit afficher en 2026#

Avant d’envoyer ton CV, fais un petit check.

Checklist GitHub

• Photo ou avatar propre
• Bio courte avec ta stack
• Localisation si tu veux
• Lien vers ton portfolio
• 3 à 5 projets épinglés
• README sur chaque projet important
• Pas de secrets exposés
• Commits pas trop chaotiques
• Projets installables
• Captures d’écran si interface visuelle
• Lien démo quand c’est possible

Exemple de bio :

Développeur web junior, React, TypeScript, Node.js. Je construis des apps simples, propres et documentées.

Pas besoin de te vendre comme “ninja du code”. Sois clair.

Le vrai objectif : rassurer l’entreprise#

Quand une entreprise recrute un développeur, elle ne cherche pas seulement quelqu’un qui sait écrire du code. Elle cherche quelqu’un qui peut travailler sans mettre le bazar dans le repo.

Git et GitHub montrent que tu sais :

• Organiser ton travail
• Collaborer
• Documenter
• Corriger proprement
• Recevoir des retours
• Livrer progressivement
• Protéger le code existant

Et ça vaut cher.

Sur un poste alternant développeur à €12k à €20k selon contrat et école, c’est un gros avantage. Sur un CDI junior à €38k, ça peut faire la différence entre “profil sympa” et “on peut le mettre dans l’équipe”.

Conclusion : apprends Git comme tu apprends à conduire#

Au début, tu regardes tous les boutons. Tu as peur de casser quelque chose. Tu tapes git status toutes les deux minutes, et franchement, c’est très bien.

Puis petit à petit, les réflexes arrivent :

• Tu crées une branche
• Tu commits souvent
• Tu écris des messages clairs
• Tu pousses sur GitHub
• Tu ouvres une PR propre
• Tu règles les conflits sans paniquer

En 2026, Git et GitHub font partie du kit de survie du développeur. Pas besoin d’être parfait, mais tu dois être opérationnel.

Et si tu es en recherche d’emploi, ne laisse pas ton CV te faire perdre des entretiens pour des détails évitables. Fais vérifier gratuitement si ton CV passe bien les filtres ATS et s’il met correctement en avant tes compétences Git, GitHub et projets techniques : teste ton CV gratuitement avec l’ATS Checker de JobRise.