Git : tout savoir sur cet outil incontournable des développeurs

Git est devenu un outil essentiel pour les développeurs de tous horizons. Conçu par Linus Torvalds, le créateur de Linux, Git s’est rapidement imposé comme un standard dans le monde du développement logiciel. Son statut open source a favorisé son adoption massive, permettant aux individus et aux entreprises de gérer efficacement leurs projets de code source.

Qu’est-ce que Git ?

Git est un système de gestion de versions distribué et open source, conçu par Linus Torvalds. Devenu un standard dans le développement logiciel, et une compétence clé pour tout développeur full stack, il permet de suivre les modifications du code, de travailler à plusieurs et de conserver un historique fiable des évolutions. Au cœur de Git se trouve le commit, une sorte d’instantané du code à un moment donné : l’historique est ainsi fait d’une suite d’instantanés que l’on peut parcourir, comparer ou restaurer.

En contraste avec d’autres VCS qui enregistrent surtout des suites de différences, Git privilégie la notion d’instantané et son modèle distribué. Chaque copie locale d’un projet est un dépôt complet avec tout l’historique. Vous pouvez donc créer des commits, explorer l’historique ou créer des branches sans connexion, puis synchroniser vos changements avec un dépôt distant quand vous le souhaitez.

À quoi sert un système de contrôle de version ?

Un contrôle de version sert à enregistrer chaque étape d’un projet, identifier qui a modifié quoi et pourquoi, revenir à un état antérieur en cas de problème, travailler en parallèle sur des fonctionnalités distinctes et faciliter les revues de code. Il améliore la collaboration, la qualité et la traçabilité, même lorsque plusieurs personnes modifient les mêmes fichiers.

Exemple simple : vous développez une fonctionnalité pendant qu’un collègue corrige un bug. Chacun travaille dans sa propre branche, enregistre des commits avec des messages clairs, puis vous fusionnez vos travaux une fois validés. Si un incident survient en production, il suffit de revenir à un commit antérieur connu comme stable pour rétablir rapidement la situation.

En quoi Git se distingue-t-il des autres VCS (modèle distribué) ?

Git se différencie par son modèle distribué et sa gestion très souple des branches. Plutôt que de dépendre d’un serveur central pour chaque action, la plupart des opérations se font en local, ce qui rend le travail plus rapide, résilient et fluide.

• Local et distant : chaque clone est un dépôt complet. Vous travaillez, validez et explorez l’historique hors ligne, puis vous synchronisez quand vous êtes prêt.
• Vitesse : les opérations clés (commit, branche, fusion, comparaison) sont locales et optimisées, ce qui accélère les cycles de développement.
• Travail hors connexion : dans le train ou en avion, vous continuez d’avancer. La connexion n’est nécessaire que pour partager vos changements.
• Collaboration non linéaire : la création de branches est légère, ce qui favorise les expérimentations, les correctifs ciblés et les intégrations progressives.
• Intégrité de l’historique : chaque commit est identifié par un hachage, ce qui assure la traçabilité et détecte les altérations involontaires.

Pourquoi utiliser Git ?

Git est un système de gestion de versions conçu pour le travail quotidien des développeurs et des équipes. Il permet de suivre précisément chaque modification, de travailler en parallèle via les branches, et de synchroniser un dépôt local avec un dépôt distant. Pensé pour être rapide, sécurisé et flexible, il facilite une collaboration fluide sur des projets de toute taille.

• Performance : opérations locales très rapides (commits, branches, fusions, comparaisons), travail possible hors ligne, gestion efficace même sur de larges bases de code.
• Sécurité : intégrité de l’historique grâce au hachage cryptographique des objets (SHA‑1 et SHA‑256), traçabilité complète des changements, possibilité de signer les commits pour authentifier les auteurs.
• Flexibilité : prise en charge de multiples workflows (développement par fonctionnalités, intégration continue, trunk-based), gestion légère des branches et tags, outils puissants pour organiser un développement non linéaire.
• Collaboration : plusieurs personnes peuvent travailler simultanément sans se gêner, proposer des changements via des revues de code et des pull requests, et s’appuyer sur des plateformes comme GitHub ou GitLab pour centraliser discussions, intégrations et déploiements.

Comment fonctionne Git ?

Git enregistre l’historique comme une suite d’instantanés immuables du projet. Chaque instantané s’appelle un commit, identifié par l’empreinte cryptographique de son contenu (SHA‑1 ou SHA‑256 selon la configuration). Ces commits forment un graphe orienté (parents, éventuellement multiples lors d’une fusion), ce qui explique la puissance de log et de diff pour naviguer et comparer des versions.

Au cœur de Git se trouve le concept de commit, une sorte d’instantané de votre code à un moment donné. Ces commits forment une chronologie, vous permettant de revenir à une version antérieure si nécessaire. Un dépôt Git (repository) peut contenir plusieurs branches, chacune représentant une version différente du code.

Espace de travail, index et dépôt : quelle différence ?

Le socle de Git repose sur trois zones complémentaires. Comprendre ce triptyque évite la plupart des confusions.

Couche	Rôle	Commandes clés
Répertoire de travail (working directory)	Vos fichiers tels qu’ils sont sur le disque, modifiables librement.	git status, git diff
Index (staging area ou cache)	Panier de sélection des changements qui entreront dans le prochain commit.	git add, git restore --staged (ou git reset <fichier>)
Dépôt (repository, dossier .git/)	Base d’objets adressés par contenu qui stocke l’historique validé.	git commit, git log

Objets Git (commit, tree, blob, tag) : à quoi ça sert ?

Git n’enregistre pas des fichiers nommés, il stocke des objets identifiés par leur empreinte. Cette vision “contenu d’abord” explique la robustesse du renommage, du déplacement et des comparaisons.

Objet	Contenu principal	Intuition
blob	Octets d’un fichier, sans nom ni chemin.	Le contenu pur d’un fichier.
tree	Liste de couples (mode, nom) vers des blob ou des tree.	Un répertoire, c’est un index qui mappe noms et contenus.
commit	Référence vers un tree racine, un ou plusieurs parents, auteur, message, date.	Un instantané complet du projet et son lien avec l’historique.
tag	Pointeur nommé vers un objet (souvent un commit), avec message et signature possible.	Un alias lisible pour marquer une version (ex. v1.2.0).

Conséquence utile : git log parcourt la chaîne de parents entre commits, tandis que git diff compare des arbres ou des blobs entre deux instantanés.

Références, HEAD et branches : comment sont-ils liés ?

Une référence (ou ref) est un nom qui pointe vers un commit. Les refs sont stockées dans .git/refs/ et agrégées dans .git/packed-refs selon les cas.

• Branche : ref locale dans refs/heads/<nom> (ex. refs/heads/main) qui pointe vers le dernier commit de la ligne de développement.
• Tag : ref dans refs/tags/<nom>, immuable par convention, souvent utilisée pour versionner des livrables.
• Suivi distant : ref dans refs/remotes/<remote>/<branche> (ex. refs/remotes/origin/main) mise à jour par git fetch.
• HEAD : ref spéciale qui indique la branche courante (ex. fichier contenant ref: refs/heads/main). En “détaché”, HEAD pointe directement vers un commit.

Schéma mental simple : HEAD → branche → commit. Quand vous commitez, la branche avance vers le nouveau commit, et HEAD suit cette branche.

Quel est le cycle d’un commit, de la modification au push ?

1. Modifier des fichiers dans le répertoire de travail, puis vérifier l’état.

   git status
   git diff

2. Sélectionner ce qui doit entrer dans le prochain commit.

   git add <fichier>        # ajoute au staging
   git add -p               # sélection par hunk
   git restore --staged <fichier>  # retire du staging

3. Valider un instantané cohérent avec un message clair.

   git commit -m "Décrire brièvement la modification"

4. Synchroniser avec le dépôt distant si nécessaire.

   git push -u origin main   # premier push d’une branche
   git push                   # suivants

5. Mettre à jour votre copie des branches distantes, puis intégrer.

   git fetch origin
   git merge origin/main   # ou git rebase origin/main
   # git pull = fetch + intégration selon la config

6. Corriger si besoin : créer un commit d’annulation ou amender le dernier commit local non poussé.

   git revert <sha>         # annule proprement un commit existant
   git commit --amend       # réécrit le dernier commit local

Comment installer Git ?

Pour commencer avec Git, la première étape consiste à l’installer. Vous pouvez télécharger Git pour Windows, macOS ou Linux depuis son site officiel. L’installation est généralement simple. Une fois installé, vous pouvez accéder à Git depuis le terminal ou utiliser des interfaces graphiques tierces.

Windows, macOS, Linux : quelles options ?

Système	Méthode d’installation	Commande ou action
Windows	Installeur Git for Windows, inclut Git Bash	Exécuter l’installeur téléchargé, puis ouvrir Git Bash
Windows	Windows Package Manager	winget install --id Git.Git -e
Windows	Chocolatey	choco install git
macOS	Outils en ligne de commande Xcode	xcode-select --install
macOS	Homebrew	brew install git
macOS	PKG officiel	Télécharger le paquet d’installation et l’exécuter
Linux (Debian, Ubuntu)	Gestionnaire de paquets	sudo apt update && sudo apt install -y git
Linux (Fedora, RHEL)	Gestionnaire de paquets	sudo dnf install -y git
Linux (Arch)	Gestionnaire de paquets	sudo pacman -S git
Linux (openSUSE)	Gestionnaire de paquets	sudo zypper install git

Comment vérifier l’installation ?

• Ouvrez un terminal, ou Git Bash sur Windows.
• Vérifiez que Git est bien installé : git --version doit afficher un numéro de version.
• Configurez votre identité, nécessaire pour vos commits :

• (Facultatif) Définir le nom de branche par défaut en main : git config --global init.defaultBranch main
• (Facultatif) Test rapide : créez un dossier, initialisez Git, puis vérifiez l’état.

GUI ou ligne de commande : que choisir au début ?

Deux approches coexistent. La ligne de commande aide à comprendre les concepts fondamentaux, fonctionne partout et reste idéale pour apprendre. Les interfaces graphiques (par exemple celles intégrées aux IDE ou des clients dédiés) rendent la prise en main plus visuelle, utiles si vous débutez ou si vous préférez manipuler les commits, branches et comparaisons avec des vues graphiques.

• Commencer en ligne de commande si vous êtes à l’aise avec le terminal, vous apprendrez plus vite ce que fait réellement chaque action.
• Commencer avec une GUI si vous débutez totalement, puis alterner avec le terminal pour progresser en compréhension.
• Dans tous les cas, connaître les commandes de base (git status, git add, git commit, git push) reste un atout, même quand vous utilisez une GUI.

Comment configurer Git au départ ?

Avant d’initier ou de cloner vos dépôts, prenez 5 minutes pour poser des réglages sains. Vous éviterez des surprises entre plusieurs postes et projets, vous gagnerez du temps, et vous mettrez en place les bases de la sécurité.

Niveaux de configuration (system/global/local) : que signifient-ils ?

Portée	Commande	Où c’est enregistré	Usage typique	Priorité
Système	git config --system	Fichier de config du système (ex. /etc/gitconfig)	Règles communes sur une machine partagée	Faible
Global (utilisateur)	git config --global	Profil utilisateur (ex. ~/.gitconfig)	Préférences de votre compte: identité, alias, éditeur	Moyenne
Locale (dépôt)	git config --local ou sans option	.git/config dans le dépôt	Spécifique à un projet	Forte

Astuce contrôle: git config --list --show-origin affiche les valeurs effectives et leur fichier d’origine.

Identité, éditeur, alias, fin de ligne (autocrlf) : que régler ?

• Votre identité (utilisée dans chaque commit) :

• Branche par défaut pour les nouveaux dépôts :

• Éditeur par défaut pour écrire des messages de commit ou des reverts :

• Alias utiles pour aller plus vite :

• Fin de ligne (source d’erreurs fréquentes entre Windows et macOS/Linux) :

• Comportements réseau pratiques :

Clés SSH et tokens HTTPS : comment s’authentifier ?

1. SSH (recommandé) pour GitHub, GitLab, etc.:
   1. Générer une clé moderne:

      ssh-keygen -t ed25519 -C "[email protected]"

   2. Démarrer l’agent et ajouter la clé:

      eval "$(ssh-agent -s)"
      ssh-add ~/.ssh/id_ed25519

   3. Copier la clé publique et l’ajouter à votre plateforme (GitHub/GitLab), puis tester:

      ssh -T [email protected]

   1. Créer un jeton sur votre plateforme et activer l’authentification à deux facteurs.
   2. Configurer un gestionnaire d’identifiants:

      # Git Credential Manager, multi‑plateforme
      git config --global credential.helper manager-core

   3. À la première opération git push/pull, utilisez le jeton comme mot de passe.

   Signer ses commits (GPG) : pourquoi et comment ?

   Signer vos commits ajoute une preuve d’authenticité. Les plateformes affichent alors un badge « Verified », ce qui renforce la confiance lors des revues de code et des livraisons.

   1. Installer GnuPG, puis générer une clé:

      gpg --full-generate-key

   2. Récupérer l’identifiant de clé:

      gpg --list-secret-keys --keyid-format=long

   3. Configurer Git pour signer:

      git config --global user.signingkey <VOTRE_KEYID>
      git config --global commit.gpgsign true

   4. Exporter la clé publique et l’ajouter à votre compte GitHub/GitLab:

      gpg --armor --export <VOTRE_KEYID>

   5. Faire un commit de test pour vérifier le statut « Verified ».
   Maîtriser Git de A à Z

   Premiers pas : créer ou cloner un dépôt ?

   Au moment de démarrer, deux chemins s’offrent à vous : créer un dépôt Git dans un dossier de projet existant sur votre machine, ou cloner un dépôt déjà hébergé à distance. Dans les deux cas, Git suivra l’historique de vos fichiers, facilitera la collaboration et permettra de revenir en arrière si besoin.

   En résumé, utilisez git init pour un projet neuf local, et git clone lorsque le code existe déjà sur une plateforme distante comme GitHub ou GitLab. Le premier met Git en place dans votre dossier courant, le second récupère le projet complet avec son historique et configure le dépôt distant par défaut.

   Quand utiliser git init ?

   Cas typique : vous partez d’un dossier local contenant déjà vos premiers fichiers, ou vous créez un nouveau répertoire vide pour démarrer un projet.

   1. Se placer dans le dossier du projet (exemple) :

      cd mon-projet

   2. Initialiser le dépôt :

      git init
      # ou pour nommer la branche initiale
      git init -b main

      Cette commande indique à Git que ce dossier est un dépôt. Git surveille alors ce dossier pour le suivi des modifications.

   3. Ajouter des fichiers au suivi (réutilisation des commandes de base) :

      git add [file]
      git add .

   4. Créer un premier commit :

      git commit -m "My amazing commit"

   5. (Optionnel) Lier un dépôt distant et publier :

      git remote add origin https://exemple.com/mon-projet.git
      git push -u origin main

   Comment cloner un dépôt existant avec git clone ?

   Si le projet existe déjà sur un serveur, clonez-le pour obtenir une copie locale avec tout l’historique et une connexion prête avec le dépôt distant.

   Sur GitHub, le lien à cloner se trouve depuis le bouton vert Clone, en HTTPS ou SSH :

   

   Options utiles au quotidien :

   • Choisir une branche au clonage :

     git clone -b develop --single-branch [repository_url]

     Télécharge uniquement la branche indiquée, pratique pour gagner du temps et de l’espace.

   • Clonage superficiel pour aller plus vite :

     git clone --depth 1 [repository_url]

     Ne récupère que l’historique récent. Idéal pour tester rapidement un projet.

   • Inclure les sous-modules si le projet en utilise :

     git clone --recurse-submodules [repository_url]

   Que contient le dossier .git ?

   • HEAD : pointeur vers la branche courante.
   • config : configuration du dépôt local.
   • refs/ : références des branches et tags (refs/heads, refs/tags).
   • objects/ : base de données des objets Git (commits, arbres, blobs), compressés et adressés par leur hash.
   • index : zone de staging qui prépare le prochain commit.
   • logs/ : journaux des mouvements de références (reflog).
   • hooks/ : scripts d’automatisation déclenchés sur des événements Git.
   • description : utilisé par certains outils serveur.

   Ce dossier caché contient toute l’intelligence de Git. Vous n’avez généralement pas besoin de le modifier manuellement. Évitez de le supprimer, de le déplacer ou d’en altérer le contenu, au risque de corrompre l’historique de votre projet.

   Se former au développement logiciel

   Quelles sont les commandes de base à connaître ?

   Pour travailler efficacement avec Git, concentrez-vous d’abord sur un noyau de commandes qui couvrent l’inspection, la préparation, la validation et la lecture de l’historique. Les fondamentaux ci‑dessous suffisent pour démarrer, les commandes avancées viennent ensuite pour affiner votre flux de travail.

   • Fondamentaux : git status, git diff, git add, git commit, git log, git show.
   • Pour aller plus loin rapidement (après maîtrise des bases) : git branch, git merge, git restore, git reset, git stash, interactions distantes (git pull, git push).

   Suivre l’état : git status et git diff

   Avant d’agir, inspectez. git status vous indique quels fichiers sont modifiés ou en attente de validation, tandis que git diff affiche précisément les changements ligne par ligne. Cette étape évite d’inclure des modifications non souhaitées.

   • Vérifier l’état du répertoire de travail et de l’index.
   • Comparer ce qui a changé avant ajout, puis ce qui est prêt à être validé.
   • Lister rapidement les fichiers touchés pour un aperçu global.

   État actuel du dépôt

   Comparer les modifications

   Préparer et valider : git add et git commit

   Le staging (index) vous permet de sélectionner précisément quelles modifications iront dans le prochain commit. Structurez vos commits pour raconter une histoire claire : un objectif par commit, un message explicite.

   1. Inspecter : vérifiez d’abord l’état et les diffs.
   2. Mettre en scène : ajoutez les changements pertinents à l’index.
   3. Contrôler : confirmez ce qui est prêt via git status.
   4. Valider : créez un commit clair et autonome.

   Ajouter des fichiers au prochain commit

   Ajouter tout un dossier si nécessaire

   Créer un commit avec un message descriptif

   Astuce pratique : pour scinder un gros changement en commits plus petits et plus lisibles, sélectionnez interactivement les hunks à ajouter avec git add -p, puis validez avec un message qui décrit l’intention (exemples utiles : fix:, feat:, docs:).

   Explorer rapidement : git log et git show

   Apprenez à lire l’historique dès le début. git log présente la chronologie des validations, et git show détaille une validation précise. Cela aide à comprendre l’évolution du code, à diagnostiquer un bug ou à retrouver quand un changement a été introduit.

   • Voir l’historique condensé et navigable.
   • Inspecter une validation précise avec son diff.
   • Filtrer par fichier ou afficher les statistiques de changement.

   Historique lisible et compact

   Détail d’une validation

   Se former au développement web

   Comment utiliser les branches ?

   Les branches vous permettent de développer une fonctionnalité, corriger un bug ou expérimenter, sans toucher à la base stable (main ou master). Le principe est simple : vous créez une branche à partir d’un point de l’historique, vous y effectuez vos commits, puis vous fusionnez ou rebasez votre travail pour l’intégrer.

   Créer, renommer et supprimer une branche

   • Créer une branche à partir de la branche courante : git switch -c nom-branche (ou git checkout -b nom-branche).
   • Lister les branches locales : git branch. Voir aussi la branche suivie et l’état : git branch -vv.
   • Basculer sur une branche existante : git switch nom-branche (ou git checkout nom-branche).
   • Renommer la branche courante : git branch -m nouveau-nom. Renommer une autre branche : git branch -m ancien-nom nouveau-nom.
   • Supprimer une branche locale fusionnée : git branch -d nom-branche. Forcer la suppression si nécessaire : git branch -D nom-branche.

   Branches de suivi distant (tracking) : comment ça marche ?

   Quand vous clonez un dépôt, Git crée par défaut un remote nommé origin. Une branche locale peut « suivre » une branche distante (par exemple origin/ma-branche). Cette relation de suivi indique à git push et git pull où envoyer et d’où récupérer les changements, sans répéter l’URL ni le nom du remote à chaque commande.

   Premier push d’une nouvelle branche : utilisez l’option -u pour définir l’upstream une bonne fois. Ensuite, un simple git push ou git pull suffira.

   Vérifier ou corriger le suivi : git branch -vv affiche la branche suivie. Pour lier une branche locale existante à une branche distante : git branch --set-upstream-to origin/feat/auth. Pour rester à jour sans fusionner directement, préférez souvent : git fetch puis git rebase origin/feat/auth (ou git pull --rebase selon votre politique d’équipe). Nettoyez les références obsolètes avec git fetch --prune.

   Nommage et hygiène des branches : quelles règles ?

   • Adoptez des préfixes explicites : feat/..., fix/..., hotfix/..., chore/..., refactor/..., release/....
   • Utilisez des noms courts et descriptifs en kebab case : feat/paiement-3ds, fix/api-timeout. Évitez espaces, accents et caractères spéciaux.
   • Une branche = un objectif clair (une fonctionnalité, un bug). Évitez les branches fourre-tout.
   • Restez proche de main : rebasez ou mergez régulièrement pour limiter les conflits et faciliter la revue.
   • Commits petits et lisibles : messages clairs, tests verts avant push. En cas de réécriture d’historique, utilisez git push --force-with-lease seulement sur des branches personnelles non partagées.
   • Nettoyez après fusion : supprimez la branche locale (git branch -d) et la branche distante si elle n’est plus utile (git push origin --delete nom-branche), puis git fetch --prune.
   • Protégez main et release/* côté plateforme (PR obligatoires, revues, CI verte) pour un historique plus clair.
   Formation Développeur Full Stack certifiante

   Fusionner des branches : merge ou rebase, et comment résoudre les conflits ?

   Vous avez terminé une fonctionnalité sur une branche et vous voulez l’intégrer à main. Deux stratégies existent : merge qui combine les historiques, et rebase qui réécrit vos commits pour obtenir une ligne du temps plus linéaire. Les deux peuvent entraîner des conflits qu’il faudra résoudre proprement.

   En synthèse, privilégiez merge pour préserver le contexte collaboratif et la traçabilité d’équipe, utilisez rebase pour nettoyer une série de commits locaux avant intégration. Ne réécrivez jamais l’historique déjà partagé.

   Merge vs rebase : quand choisir l’un ou l’autre ?

   Les branches sont au cœur du flux Git. Après travail sur une branche, la commande git merge intègre les changements dans une autre branche, par exemple dans main.

   Stratégie	À privilégier quand	Avantages	Limites et précautions	Commandes utiles
   Merge	Travail collaboratif, pull requests, besoin d’un point de regroupement explicite.	Préserve l’historique réel, facile à annuler par le commit de merge, aucun risque de réécrire l’historique partagé.	Historique parfois plus ramifié, graphes plus denses.	git merge, git merge --no-ff, git merge --ff-only
   Rebase	Avant de proposer votre travail, pour aplanir vos commits locaux et obtenir un historique linéaire.	Historique propre et linéaire, révision plus simple commit par commit.	Ne jamais rebase une branche déjà poussée et utilisée par d’autres. Réécriture d’historique.	git rebase main, git pull --rebase, git rebase -i main

   Fast-forward vs no-ff : quel impact sur l’historique ?

   Un fast-forward se produit si main n’a pas divergé, Git avance simplement le pointeur de main sur les commits de la branche. L’historique reste linéaire, sans commit de merge.

   Avec –no-ff, Git crée toujours un commit de merge, même si un fast-forward était possible. Cela conserve un regroupement explicite de la fonctionnalité, utile pour tracer ou annuler d’un bloc.

   Implications pratiques :

   • Fast-forward : historique plus simple, mais il devient moins évident d’identifier la frontière de la fonctionnalité.
   • No-ff : un commit de merge unique facilite la réversion de toute la fonctionnalité (git revert -m 1 <sha_merge>).

   Comment résoudre un conflit de fusion ?

   1. Détecter les conflits.

      git status
      # Les fichiers "both modified" contiennent des marqueurs <<<<<<< ======= >>>>>>>

   2. Ouvrir les fichiers en conflit et décider, fichier par fichier :
      • Garder nos changements (ours).
      • Garder les changements de l’autre branche (theirs).
      • Ou bien fusionner manuellement les deux parties.

      # Choisir notre version pour un fichier
      git checkout --ours chemin/fichier
      
      # Choisir la version distante pour un fichier
      git checkout --theirs chemin/fichier
      
      # Alternative moderne selon le contexte de merge
      git restore --source=HEAD -- chemin/fichier      # ours
      git restore --source=MERGE_HEAD -- chemin/fichier # theirs

   3. Nettoyer les marqueurs de conflit dans les fichiers si vous avez fusionné à la main, puis marquer comme résolu.

      git add chemin/fichier
      git status   # vérifier qu'il ne reste plus de conflits

   4. Terminer l’opération en cours :
      • Après un merge : git commit ou git merge --continue.
      • Après un rebase : git rebase --continue pour passer au commit suivant.
   5. Vérifier que tout est correct, puis pousser si nécessaire.

      git log --oneline --graph --decorate
      git push

   Bon réflexe avant de fusionner : mettre à jour votre branche de travail pour limiter les conflits.

   Comment terminer ou annuler une opération (continue/abort) ?

   • Terminer un merge après résolution : git merge --continue ou git commit.
   • Annuler un merge en cours et revenir à l’état initial : git merge --abort.
   • Continuer un rebase après résolution : git rebase --continue.
   • Sauter un commit problématique pendant un rebase : git rebase --skip.
   • Annuler un rebase en cours : git rebase --abort.
   • Empêcher tout merge non fast-forward sur main : git merge --ff-only ou politique serveur.
   • Éviter la réécriture d’historique partagé : ne pas utiliser git push --force sur des branches d’équipe, préférez --force-with-lease si vous devez forcer.
   Découvrir le métier de Développeur Full Stack

   Comment collaborer avec des dépôts distants ?

   Collaborer efficacement avec Git repose sur une bonne maîtrise des dépôts distants, des Pull Requests et des workflows de branches. Que vous travailliez sur votre propre dépôt ou via un fork d’un projet open source hébergé sur GitHub ou GitLab, le trio remotes, synchronisation et revue de code structure le flux de travail quotidien.

   Configurer les remotes : origin, upstream, add, set-url

   • Vérifier les remotes configurés:

     git remote -v

   • Cas 1, vous avez forké le projet:
     • origin pointe vers votre fork, où vous poussez vos branches.
     • upstream pointe vers le dépôt principal, d’où vous récupérez les nouveautés.
     • origin pointe vers le projet principal. Ajoutez un fork éventuel en remote secondaire si besoin.

     Fetch, pull, push : quand utiliser chacun ?

     Bien choisir entre fetch, pull et push évite les mauvaises synchronisations et les pertes de travail.

     Commande	Ce que cela fait	Quand l’utiliser, précautions
     git fetch	Récupère les nouvelles références distantes sans modifier votre branche courante.	Avant de rebaser ou fusionner, pour voir ce qui a changé à distance en toute sécurité.
     git pull	Fetch puis intègre les changements dans la branche active.	Sur vos branches locales suivies. Préférez git pull --rebase sur les branches de fonctionnalité pour garder un historique linéaire.
     git push	Envoie vos commits locaux vers le dépôt distant.	Pour partager votre travail ou ouvrir une PR. N’utilisez jamais --force sur une branche partagée, préférez --force-with-lease sur votre branche personnelle.

     Rappel utile depuis l’article original, interagir avec un dépôt distant est essentiel:

     • Envoyer vos commits locaux:

       git push

     • Récupérer et intégrer les derniers changements:

       git pull

     Pull Requests : comment ça marche et à quoi servent-elles ?

     Les Pull Requests sont un moyen de proposer des modifications et de les faire examiner avant de les fusionner dans la branche principale d’un projet. Elles sont fondamentales dans le travail d’équipe et les projets open source.

     • Étapes typiques:
       1. Créez une branche locale et validez vos changements.
       2. Poussez la branche vers origin.
       3. Ouvrez une PR vers main de upstream ou du dépôt principal.
       4. Décrivez le contexte, liez des issues, cochez la checklist, assignez des reviewers.
       5. Laissez tourner les vérifications CI et répondez aux commentaires.
       6. Choisissez le mode de fusion: merge commit, squash and merge, ou rebase and merge selon la politique du projet.
     • À quoi elles servent:
       • Revue de code et partage de connaissances.
       • Vérifications automatiques: tests, lint, sécurité.
       • Traçabilité centralisée des décisions et discussions.
       • Qualité accrue grâce aux exigences de validation avant fusion.

       

       Quelles stratégies de branche adopter (GitFlow, trunk-based, forking) ?

       Choisissez un workflow adapté à la taille de l’équipe, à la fréquence des livraisons et à la gouvernance.

       Workflow	Idée clé	Quand l’adopter, points de vigilance
       GitFlow	Branches develop, feature, release, hotfix.	Organisations avec cycles de versions formalisés. Plus verbeux, nécessite de la discipline et des règles claires.
       Trunk-based	Intégration continue vers main, petites branches de courte durée.	Équipes orientées livraison rapide. Demande CI solide et feature flags pour découpler déploiement et activation.
       Forking	Chaque contributeur travaille via un fork, PR vers le dépôt amont.	Projets open source et équipes distribuées. Gouvernance stricte via PR et protections de branche.

       Protection des branches et revues de code : quelles bonnes pratiques ?

       • Protéger main et les branches de version: pas de push direct, PR obligatoire, historiques linéaires si souhaité.
       • Exiger des validateurs: au moins un relecteur, idéalement des CODEOWNERS sur les zones critiques.
       • Activer les vérifications CI obligatoires: tests, lint, sécurité, build vert avant fusion.
       • Appliquer des conventions: noms de branches parlants, petites PR focalisées, messages de commit clairs.
       • Utiliser pull --rebase sur les branches de fonctionnalité pour réduire les merges inutiles.
       • Interdire --force sur les branches partagées; si réécriture nécessaire sur votre branche, utiliser --force-with-lease.
       • Nettoyer après fusion: suppression automatique des branches, conservation d’un changelog ou squash pour un historique lisible.
       • Signer les commits si la politique du projet l’exige et activer la vérification de signature.
       Se former au développement logiciel

       Comment explorer l’historique et diagnostiquer ?

       Pour comprendre, auditer et déboguer un projet, il faut lire l’historique efficacement. Les commits forment une chronologie de vos changements, ce qui permet de revenir à une version antérieure si nécessaire et d’identifier rapidement l’origine d’un problème.

       log avancé (–graph, –oneline, –decorate) : comment lire vite ?

       • --oneline : affiche un résumé compact (SHA abrégé et sujet du commit).
       • --graph : dessine l’arbre ASCII pour visualiser branches et merges.
       • --decorate : ajoute les noms de branches et de tags sur les commits.
       • --all : inclut toutes les références (branches locales et suivies).
       • --abbrev-commit : raccourcit les identifiants des commits.
       • --stat ou -p : montre respectivement le résumé des changements ou le diff complet.
       • Filtres utiles : --author=, --grep=, --since=/--until=, -- path/vers/fichier, -S ou -G pour rechercher un ajout/suppression précis.
       • Confort de lecture : --date=relative, --reverse, --color.

       Quand utiliser git blame et git bisect ?

       Cas concret : une ligne produit une erreur en production. Vous voulez savoir qui l’a modifiée en dernier, puis retrouver à quel commit exact la régression est apparue.

       • git blame pour l’attribution ligne par ligne :
         • -L start,end pour limiter à une plage de lignes.
         • -w pour ignorer les changements d’espaces.
         • -M et -C pour suivre les déplacements ou copies de code.
         • git bisect pour la recherche de régression (dichotomie) :
           • Vous marquez un état bon et un état mauvais, Git teste les commits intermédiaires.
           • Possibilité d’automatiser avec git bisect run et un script de test qui renvoie 0 en succès.

           reflog : comment remonter dans le temps ?

           reflog est la “bouée de sauvetage” locale : il mémorise les déplacements récents de vos références (HEAD, branches). Pratique après un reset --hard ou un rebase malheureux, pour retrouver un commit “perdu”.

           Exemple : vous avez fait un git reset --hard par erreur. Lancez git reflog, repérez l’entrée juste avant le reset, puis revenez dessus avec git reset --hard COMMIT_SHA ou créez une branche de secours pour examiner tranquillement.

           Se former au développement web

           Comment annuler ou récupérer après une erreur ?

           Quand on se trompe avec Git, il existe une véritable boîte à secours. Retenez l’idée clé suivante : choisissez l’outil le moins destructeur qui résout votre problème, surtout en équipe.

           • Corriger un fichier non commité : git restore (ou git checkout -- sur anciennes versions).
           • Reculer des commits localement : git reset (soft, mixed, hard selon l’impact souhaité).
           • Annuler un commit déjà partagé sans réécrire l’historique : git revert.
           • Mettre de côté du travail en cours pour revenir plus tard : git stash.

           Revenir sur des fichiers : git restore / checkout

           Pour des erreurs locales et ciblées, git restore est la méthode la plus sûre pour un débutant. Elle n’altère pas l’historique, elle agit seulement sur l’index et le répertoire de travail.

           • Annuler des modifications non indexées dans le répertoire de travail :
             git restore <fichier>
           • Annuler un git add et retirer un fichier de l’index sans toucher au contenu local :
             git restore --staged <fichier>
           • Récupérer la version d’un fichier depuis un commit donné :
             git restore --source <commit> -- <chemin>
           • Équivalent historique si votre Git est ancien :
             git checkout -- <fichier> pour annuler des changements locaux,
             git checkout <commit> -- <chemin> pour récupérer depuis un commit.

           Astuce pratique : commencez toujours par git status pour voir clairement ce qui est modifié ou indexé.

           reset (soft/mixed/hard) : quelles différences ?

           git reset déplace la référence de votre branche (HEAD) et, selon le mode, réinitialise l’index et le répertoire de travail. Choisissez le mode en fonction de l’effet souhaité.

           Mode	HEAD	Index (staging)	Répertoire de travail	Usage typique
           --soft	Se déplace	Conservé	Conservé	Revenir en arrière tout en gardant tous les fichiers prêts à être re‑commités.
           --mixed (par défaut)	Se déplace	Réinitialisé	Conservé	Recomposer vos commits en re‑sélectionnant les fichiers à ajouter.
           --hard	Se déplace	Réinitialisé	Réinitialisé	Repartir exactement d’un commit. Des changements non commités seront perdus.

           • Exemples :

             # Revenir d'un commit en gardant tout en staging
             git reset --soft HEAD~1
             
             # Refaire le staging proprement depuis ce point
             git reset --mixed HEAD~2
             
             # Tout écraser pour coller à un commit
             git reset --hard <commit>

           • Précaution : évitez reset sur des commits déjà poussés et partagés. Préférez git revert en équipe.
           • Filet de sécurité avant un --hard : créez une branche de secours.

             git switch -c sauvegarde/avant-reset

           revert : annuler proprement en conservant l’historique

           git revert crée un nouveau commit qui inverse les changements d’un commit précédent. L’historique reste linéaire et compréhensible. C’est l’option recommandée en environnement partagé.

           Exemples rapides :

           En cas de conflit, résolvez-les, puis validez le revert. Pour un commit de fusion, précisez le parent avec -m si nécessaire.

           Sauvegarder temporairement : quand utiliser git stash ?

           git stash met de côté votre travail en cours afin de changer de branche, tirer des mises à jour ou corriger une urgence, sans polluer l’historique avec des commits intermédiaires.

           • Créer un stash :
             git stash push -m "WIP: corriger login"
             Inclure aussi les fichiers non suivis : git stash push -u (ou tout, y compris ignorés : -a).
           • Revenir au travail mis de côté :
             git stash pop applique puis supprime l’entrée,
             git stash apply applique en conservant l’entrée.
           • Gérer ses stashes :
             git stash list, git stash show -p stash@{0}, git stash drop stash@{0},
             créer une branche à partir d’un stash : git stash branch fix/login stash@{0}.
           • Bons usages :
             • Idéal pour une interruption courte ou un changement rapide de contexte.
             • Ajoutez toujours un message clair pour vous y retrouver plus tard.
             • Évitez d’empiler des stashes pendant des jours, appliquez ou nettoyez régulièrement.
             Formation Développeur Full Stack certifiante

             .gitignore et .gitattributes : que configurer ?

             Deux fichiers simples évitent beaucoup d’ennuis au quotidien : .gitignore pour ne pas pusher des fichiers inutiles, et .gitattributes pour maîtriser fins de ligne, binaires et diff. Mettez-les en place dès l’initialisation du dépôt, sinon vous risquez des conflits de merge inutiles, des diffs illisibles et des problèmes CRLF entre macOS/Linux et Windows.

             • Commencez par un modèle .gitignore adapté au langage et à l’IDE, puis ajustez au projet.
             • Utilisez .gitattributes pour normaliser les fins de ligne et marquer les fichiers binaires, afin d’obtenir des diffs propres.
             • Rappelez-vous que .gitignore n’efface pas un fichier déjà tracké : utilisez git rm --cached <fichier> pour le retirer de l’index.

             Modèles par langage/outil : que faut-il ignorer ?

             • Universel : fichiers système et d’éditeur
               • .DS_Store, Thumbs.db, desktop.ini
               • .idea/, .vscode/, *.iml, .history/
               • caches et logs : .cache/, *.log, coverage/, .nyc_output/
               • node_modules/, .pnpm-store/, .eslintcache, .turbo/
               • builds : dist/, build/, out/, .next/, .nuxt/, .parcel-cache/, .vite/
               • À conserver : package-lock.json, yarn.lock, pnpm-lock.yaml
               • __pycache__/, *.py[cod], .pytest_cache/, .mypy_cache/, .ruff_cache/, .tox/
               • environnements : .venv/, venv/, env/
               • builds : build/, dist/, *.egg-info/
               • À conserver : poetry.lock ou Pipfile.lock selon l’outil
               • Maven : target/
               • Gradle : .gradle/, build/
               • IDE : .classpath, .project, .settings/, *.iml
               • bin/, obj/, .vs/, TestResults/
               • artéfacts locaux : bin/, coverage.out
               • À conserver : go.mod et go.sum
               • target/
               • Note : gardez Cargo.lock dans les applications. Dans une bibliothèque, la décision peut varier selon les pratiques.
               • vendor/ (selon la politique d’équipe), caches de framework
               • À conserver : composer.lock
               • log/, tmp/, coverage/, .bundle/, vendor/bundle/
               • .ipynb_checkpoints/, répertoires de données temporaires : data/tmp/, data/raw/ (selon la politique de versionnage des données)

               Fin de ligne, binaires, diff : quels attributs utiles ?

               Cas d’usage	Attribut .gitattributes	Exemple	Effet attendu
               Normaliser les fins de ligne	text=auto	* text=auto	Git détecte les fichiers texte et stocke uniformément, réduit les diffs liés à CRLF.
               Forcer LF pour les scripts	text eol=lf	*.sh text eol=lf	Empêche les scripts de casser entre OS, fin de ligne homogène.
               Forcer CRLF pour certains fichiers	text eol=crlf	*.bat text eol=crlf	Respecte les besoins Windows pour les scripts batch.
               Marquer un binaire	binary	*.png binary	Aucun traitement texte, pas de conversion EOL.
               Désactiver le diff sur un type	-diff	*.pdf -diff	Évite des diffs inutiles sur des formats opaques.
               Utiliser Git LFS pour gros fichiers	filter=lfs diff=lfs merge=lfs -text	*.zip filter=lfs diff=lfs merge=lfs -text	Stocke les binaires lourds hors dépôt, accélère les clones.
               Stratégie de merge spécifique	merge=ours ou merge=union	docs/CHANGELOG.md merge=union	Réduit les conflits sur fichiers concaténables. À utiliser avec discernement.
               Afficher moins de bruit dans les diffs	whitespace côté config, ou attributs adaptés	*.md text	Contribue à des diffs plus lisibles sur le texte.
               Masquer du code tiers dans les stats GitHub	linguist-vendored (spécifique GitHub)	vendor/** linguist-vendored	N’influe pas sur Git, seulement sur l’affichage GitHub.

               Secrets et données sensibles : que ne jamais valider ?

               • Clés et certificats : *.pem, *.key, id_rsa, id_ed25519, *.p12, *.jks, *.keystore, AuthKey_*.p8.
               • Fichiers d’environnement : .env, .env.*, .env.local, variables d’API en clair.
               • Identifiants cloud et CI : .aws/credentials, gcloud/application_default_credentials.json, service-account.json, jetons dans .npmrc ou fichiers de config.
               • Données et sauvegardes : dumps *.sql, *.sqlite, *.bak, exports CSV contenant des PII.
               • Mobiles : google-services.json, GoogleService-Info.plist, profils de provisioning.

               Mini‑checklist sécurité

               • Ajoutez des patterns de secrets au .gitignore du projet et à votre global ignore.
               • Mettez en place un hook pre-commit et une analyse CI avec des outils de détection de secrets.
               • Stockez les secrets dans un secret manager ou chiffrés, référencez‑les par variables d’environnement.
               • Si un secret fuit, révoquez et remplacez la clé, puis réécrivez l’historique avec un outil dédié.
               Découvrir le métier de Développeur Full Stack

               Quelles commandes avancées valent le détour ?

               Au‑delà de git status, commit, branch et merge, Git propose des outils puissants pour garder un historique propre, sélectionner finement des correctifs, travailler efficacement sur plusieurs branches et gérer des dépôts volumineux. Voici l’essentiel à connaître sans alourdir votre quotidien.

               • Réécrire l’historique en sécurité avec rebase -i pour regrouper, renommer ou éditer des commits avant une fusion.
               • Sélectionner un correctif avec cherry-pick pour backporter un patch vers une version de maintenance.
               • Accélérer vos allers‑retours avec worktree pour ouvrir plusieurs branches en parallèle, sans clones multiples.
               • Gérer de gros fichiers ou des dépendances de code avec Git LFS et les submodules.
               • Optimiser un gros dépôt grâce au shallow clone, au nettoyage (gc, prune) et aux clones partiels.
               • Automatiser les vérifications côté développeur avec les hooks locaux, par exemple en pre-commit.

               rebase interactif : comment réécrire proprement l’historique ?

               1) Préparer en sécurité

               Travaillez sur une branche de fonctionnalité à jour avec main pour limiter les conflits. Assurez‑vous que votre travail local est sauvegardé.

               2) Lancer l’édition

               Dans l’éditeur, remplacez les actions selon le besoin : reword pour modifier un message, edit pour corriger le contenu, squash/fixup pour fusionner des commits bruyants.

               3) Finaliser et pousser

               Exemple : regrouper plusieurs fix typo en un seul commit propre avant d’ouvrir une Pull Request. Vous facilitez la revue et l’history bisect futur.

               cherry-pick : comment sélectionner des commits utiles ?

               Cas typique : corriger un bug en main, puis reporter exactement ce correctif sur la branche release/1.3 sans tout fusionner.

               • Bonnes pratiques : cherry‑pick unitairement des commits autonomes, éviter les commits mixtes fonctionnalité + refactor.
               • Conflits : résolvez puis git cherry-pick --continue. En cas d’erreur : git cherry-pick --abort.
               • Backport massif : enchaînez plusieurs SHA dans l’ordre chronologique pour limiter les conflits.

               worktree : travailler sur plusieurs branches en parallèle ?

               git worktree crée des répertoires de travail additionnels adossés au même dépôt, ce qui évite les clones redondants. Idéal pour préparer un hotfix tout en gardant ouverte votre branche de feature.

               Exemple : lancez les tests d’une Pull Request dans un worktree pendant que vous continuez à coder ailleurs, sans changer de contexte.

               Submodules et LFS : dans quels cas les utiliser ?

               Cas concrets : un projet A dépend d’un projet B versionné séparément ; ou vous devez versionner de très gros fichiers binaires comme des modèles IA, des images RAW ou des PSD.

               Submodules : référence un autre dépôt à un commit précis.

               Git LFS : stocke le contenu lourd hors du dépôt pour garder l’historique léger.

               Comparaison rapide : utilisez submodules pour des dépendances de code avec versionnement indépendant. Utilisez LFS pour des binaires volumineux qui gonfleraient le dépôt. Les deux peuvent cohabiter.

               Optimiser un gros dépôt : shallow clone, gc, prune

               • Clone superficiel : git clone --depth 1 --no-tags --single-branch <url> pour récupérer uniquement la dernière révision utile.
               • Clone partiel : git clone --filter=blob:none <url> pour ne télécharger le contenu des fichiers qu’à la demande.
               • Nettoyage : git gc pour compacter l’historique, git repack -Ad pour un repack complet, git prune pour purger les objets inaccessibles.
               • Entretien continu : git maintenance start active des tâches d’optimisation en arrière‑plan.
               • Branches distantes obsolètes : git fetch --prune puis git remote prune origin pour rester à jour.

               Hooks locaux : automatiser des vérifications pré-commit

               Les hooks sont des scripts déclenchés par Git. En pre-commit, vous pouvez lancer un lint, formater le code ou exécuter des tests rapides pour empêcher l’introduction d’erreurs.

               • Rapide et non floconneux : gardez le hook rapide, réservez les suites longues au CI.
               • Messages utiles : en cas d’échec, affichez clairement la commande à rejouer.
               • Équipe : versionnez une configuration partagée via un outil dédié ou documentez l’installation des hooks.
               Se former au développement logiciel

               Quelles sont les bonnes pratiques Git ?

               Consolidez vos habitudes autour de règles simples : des commits petits et explicites, des branches par fonctionnalité, un historique propre, aucun secret dans le dépôt, une CI toujours verte.

               Comment rédiger de bons messages de commit ?

               1. Titre à l’impératif, court, avec type et scope si utile : feat(auth): ajoute 2FA.
               2. Ligne vide pour séparer.
               3. Corps bref qui explique le pourquoi, les impacts et le comment si nécessaire.
               4. Footer optionnel : références de tickets, co-auteurs, breaking changes.

               Astuce : un bon message doit permettre de comprendre la modification sans ouvrir le diff. Chaque commit doit être accompagné d’un message clair et descriptif, surtout en contexte collaboratif.

               Pourquoi préférer de petits commits et PRs ciblés ?

               De petits lots rendent la relecture plus rapide, diminuent les risques de conflits et facilitent l’identification d’un bug avec git bisect. Ils accélèrent aussi les pipelines CI et réduisent le temps d’attente avant intégration.

               Conséquence directe : un revert devient trivial (git revert <sha>) et l’historique reste compréhensible. Les PRs ciblées par fonctionnalité ou par correctif produisent une documentation vivante du projet.

               Faut-il rebase avant merge sur une feature ?

               Deux approches coexistent, à choisir selon la culture d’équipe : le rebase produit une histoire linéaire et lisible, le merge commit conserve la trace explicite des intégrations.

               • Rebase recommandé avant d’ouvrir la PR : nettoyer les commits (interactive rebase), résoudre les conflits localement, puis ouvrir une PR propre.
               • Merge commit recommandé pour les branches déjà partagées ou en open source : pas de réécriture de l’historique public.
               • Règle d’or : ne rebasez que votre branche privée. Évitez de réécrire une branche déjà consommée par d’autres sans coordination explicite.
               • Option pratique : configurer git pull --rebase pour limiter les merge commits accidentels.

               Comment maintenir un .gitignore propre et éviter les secrets ?

               • Partez d’un modèle adapté à votre écosystème (langage, framework, IDE) et complétez-le avec les artefacts locaux : node_modules, dist/, target/, .venv/, .DS_Store, .idea/.
               • Créez un ~/.gitignore_global pour les fichiers propres à votre machine (OS, IDE), et gardez le .gitignore du projet focalisé sur le repo.
               • N’ajoutez jamais de secrets : fichiers .env, clés .pem, tokens. Utilisez des variables d’environnement et un gestionnaire de secrets.
               • Mettez en place des hooks de pré-commit pour détecter les secrets et binaires indésirables.
               • En cas de fuite : révoquez les clés, puis purgez l’historique avec un outil dédié et forcez la rotation. Éduquez l’équipe et renforcez les contrôles.
               • Voir aussi la section Paramétrage et bases de Git pour ancrer le réflexe de configuration.

               Comment garder main stable et nettoyer les branches ?

               1. Protégez main : pas de push direct, revue obligatoire, CI verte, status checks requis.
               2. Intégrez tôt et souvent : mettez à jour vos branches régulièrement et résolvez les conflits côté feature.
               3. Choisissez une stratégie d’intégration claire : merge, squash merge ou rebase merge selon le projet, mais restez cohérents.
               4. Supprimez les branches fusionnées côté distant et local pour éviter l’encombrement.
               5. Faites le ménage périodique :

                  git fetch --prune
                  git branch --merged main
                  git branch -d feature/ma-tache
                  git push origin --delete feature/ma-tache

               6. Posez des repères : taguez les versions pour faciliter un rollback ciblé.

                  git tag -a v1.2.0 -m "Release 1.2.0"
                  git push origin v1.2.0

               Se former au développement web

               Pour conclure

               Git est un outil puissant et extrêmement populaire dans le monde du développement logiciel. Sa maîtrise facilite le travail en équipe et la contribution à des projets open-source. Voici le chemin d’apprentissage que vous avez parcouru, ainsi que des ressources fiables pour approfondir.

               Récapitulatif de l’itinéraire d’apprentissage

               • Installer Git : télécharger et installer sur votre système, utiliser le terminal ou une interface graphique.
               • Configurer votre identité : définir nom et e‑mail avec git config --global pour signer vos commits.
               • Démarrer un projet : initialiser un dépôt avec git init ou cloner un dépôt existant avec git clone.
               • Enregistrer votre travail : inspecter l’état avec git status, sélectionner avec git add, valider avec git commit.
               • Travailler en parallèle : créer et basculer de branche, puis fusionner vos changements avec git merge.
               • Synchroniser avec un distant : partager vos commits avec git push, récupérer et intégrer les nouveautés avec git pull.
               • Collaborer : proposer des Pull Requests pour relecture et intégration propre du code.
               • Bonnes pratiques : messages de commits clairs, branches descriptives, mises à jour régulières du dépôt local.

               Ressources officielles et neutres pour aller plus loin

               • Documentation officielle Git : git-scm.com/doc et le livre Pro Git.
               • Tutoriels Atlassian : introduction et guides pratiques Qu’est-ce que Git ?.
               • Microsoft Learn : notions de base et scénarios d’équipe Qu’est-ce que Git ?.
               • Guides GitLab : bases de Git et collaboration docs GitLab.
               • Cours d’introduction : Gérez du code avec Git et GitHub sur OpenClassrooms.
               Découvrir nos formations