Git – système de contrôle de version distribué (tutoriel 2026)

Git, le système de contrôle de version distribué, est le socle du travail collaboratif moderne : chaque développeur conserve une copie complète de l’historique, peut travailler hors ligne et synchroniser ses commits avec un remote (GitHub, GitLab, Azure Repos). Ce tutoriel 2026 vous guide pas à pas sous Ubuntu 24.04 : installation, configuration, workflow local, branches, remotes, merge versus rebase, commandes avancées, erreurs fréquentes et FAQ. À la fin, vous saurez versionner un projet proprement et l’intégrer dans un parcours Azure DevOps / Git.

Prérequis

Avant de commencer, préparez un environnement stable. Vous aurez besoin d’Ubuntu 24.04 LTS avec un accès sudo, d’un terminal et de bases de ligne de commande. Git 2.43 ou plus récent est recommandé pour les workflows actuels (branche main par défaut, --force-with-lease, worktrees). Un compte sur un hébergeur Git (GitHub, GitLab ou Azure Repos) est utile dès la section remotes, mais n’est pas obligatoire pour les premiers commits locaux.

Pourquoi un contrôle de version distribué ?

Contrairement à un système centralisé (SVN), Git duplique tout l’historique sur chaque machine. Avantages concrets : commits locaux sans réseau, branches légères pour isoler une feature, revue de code via pull/merge requests, et résilience si le serveur distant tombe. Dans un pipeline Azure DevOps, Azure Repos s’appuie sur Git : maîtriser les commandes ci-dessous, c’est maîtriser la source de vérité de vos pipelines YAML.

Installer Git sur Ubuntu 24.04

Mettez d’abord à jour les métadonnées des paquets, puis installez le paquet officiel. La vérification de version confirme que le binaire est bien dans le PATH.

sudo apt update
sudo apt install git -y
git --version

Une sortie du type git version 2.43.0 (ou supérieure) indique que Git est prêt. Si le dépôt Ubuntu propose une version trop ancienne pour un besoin précis, vous pourrez plus tard ajouter le PPA officiel ou compiler depuis les sources ; pour 95 % des cas DevOps, le paquet apt suffit.

Configurer votre identité Git

Chaque commit enregistre un auteur. Configurez le nom et l’e-mail de façon globale (tous les dépôts), puis forcez le nom de branche par défaut à main pour rester aligné avec GitHub, Azure Repos et la majorité des modèles CI/CD 2026.

git config --global user.name "Votre Nom"
git config --global user.email "votre.email@example.com"
git config --global init.defaultBranch main
git config --list

Astuce : pour un projet client uniquement, omettez --global et exécutez les mêmes commandes dans le dépôt. Vérifiez toujours git config --list --show-origin si deux valeurs semblent se contredire (fichier local qui surcharge le global).

Workflow Git de base : init, add, commit, status

Le cycle quotidien repose sur quatre idées : initialiser (ou cloner) un dépôt, préparer une zone de staging avec git add, figer un instantané avec git commit, et inspecter l’état avec git status / git log. Commencez dans un dossier vide :

mkdir my-project && cd my-project
git init
echo "Contenu initial" > README.md
git add README.md
git commit -m "Initial commit"
git status

Après le premier commit, git status doit indiquer une branche propre (nothing to commit, working tree clean). Habituez-vous à des messages de commit courts et intentionnels (« Ajoute endpoint health », « Corrige race condition sur le cache ») : l’historique devient alors une documentation vivante pour l’équipe et pour Azure Boards / work items liés.

Travailler avec un dépôt distant (remote)

Un remote est l’URL d’un dépôt partagé. Ajoutez origin, poussez la branche main, puis synchronisez régulièrement avec fetch et merge (ou pull). En Azure Repos, l’URL HTTPS ressemble à https://dev.azure.com/Org/Project/_git/Repo ; en SSH, préférez une clé dédiée.

git remote add origin https://github.com/username/my-project.git
git push -u origin main
git fetch origin
git merge origin/main

git push -u enregistre le suivi upstream : les prochains git push / git pull n’auront plus besoin du nom de branche. En cas d’authentification HTTPS sur GitHub, utilisez un personal access token ; sur Azure DevOps, un PAT avec le scope Code. SSH reste souvent plus confortable au quotidien.

Branches locales et branches distantes

Les branches Git sont des pointeurs légers. Créez une feature branch, développez isolément, poussez-la pour ouvrir une pull request / merge request, puis listez l’ensemble des références :

git checkout -b feature/login
git push -u origin feature/login
git branch -a

Convention utile : feature/, fix/, hotfix/ + ticket Azure Boards. Évitez de committer directement sur main en équipe ; protégez la branche dans les réglages du dépôt (policies Azure Repos : reviewers, build validation).

Merge versus rebase

Le merge conserve l’historique exact des deux branches (commit de fusion). Le rebase réécrit l’historique de la feature pour le rendre linéaire sur main. Les deux sont valides ; le choix dépend de la politique d’équipe.

git checkout main
git merge feature/login

git checkout feature/login
git rebase main
git push --force-with-lease origin feature/login

Après un rebase d’une branche déjà poussée, préférez --force-with-lease à --force : Git refuse d’écraser le remote si quelqu’un a poussé entre-temps. Ne rebasez jamais une branche partagée comme main sans accord explicite de l’équipe.

Commandes avancées : squash, reset, revert, cherry-pick, stash

Ces outils permettent de nettoyer l’historique, d’annuler proprement et de basculer de contexte sans perdre du travail en cours.

git rebase -i HEAD~3
git reset --soft HEAD~1
git revert <commit-hash>
git cherry-pick <commit-hash>
git stash push -m "WIP login form"
git stash pop

Le rebase interactif sert souvent à squash plusieurs micro-commits avant une PR. reset --soft retire le dernier commit mais garde les changements en staging. revert crée un nouveau commit d’annulation (sûr sur main). cherry-pick rejoue un commit précis ailleurs. stash range temporairement un work-in-progress pour changer de branche.

.gitignore et inspection des différences

Excluez artefacts de build, dépendances et secrets. Inspectez ensuite le diff non indexé et le diff déjà stagé avant de committer.

echo "node_modules/
*.log
.env" > .gitignore
git diff
git diff --staged

Ajoutez aussi .DS_Store, __pycache__/, dist/, .terraform/ selon la stack. Un fichier .env versionné est une erreur classique : une fois poussé, considérez le secret comme compromis et faites-le tourner.

Worktrees et tags de release

Un worktree ajoute un second répertoire de travail lié au même dépôt, idéal pour un hotfix sans quitter une feature en cours. Les tags annotés marquent une release stable.

git worktree add ../hotfix main
git tag -a v1.0.0 -m "First stable release"
git push origin v1.0.0

En CI/CD (Azure Pipelines, GitHub Actions), un tag v* déclenche souvent le job de publication. Documentez la sémantique de version (MAJOR.MINOR.PATCH) dans le README du repo.

Erreurs fréquentes

• Permission denied au push : vérifiez la clé SSH ou utilisez HTTPS + PAT Azure DevOps / GitHub.
• Non-fast-forward : faites git fetch puis merge/rebase avant de repousser.
• Detached HEAD : vous êtes sur un commit nu ; revenez sur une branche avec git checkout main.
• Fichiers trop volumineux refusés : ajoutez-les au .gitignore ou passez par Git LFS.
• Conflits de merge : éditez les marqueurs <<<<<<<, git add les fichiers résolus, puis git commit.

Git dans le parcours Azure DevOps

Sur ce site, Git est la porte d’entrée du mega-menu Azure : Azure Repos héberge vos dépôts Git, Azure Boards lie commits et work items, Azure Pipelines écoute les push/PR pour build et déploiement. Bonnes pratiques : branches protégées, revue obligatoire, builds de validation, messages de commit clairs, et jamais de secrets dans l’historique. Une fois ce tutoriel assimilé, enchaînez sur Azure Repos, les agents hébergés Microsoft, puis les pipelines YAML.

Pour aller plus loin

• Explorez les hooks Git (pre-commit, pre-push) pour lint et tests automatiques.
• Intégrez Git à un pipeline CI/CD (Azure Pipelines ou GitHub Actions) dès le premier service.
• Adoptez le trunk-based development pour réduire la durée de vie des branches longues.
• Signez vos commits avec GPG/SSH pour renforcer la traçabilité en équipe.

Conclusion

Maîtriser Git comme système de contrôle de version distribué améliore la collaboration, la qualité de l’historique et la fiabilité des livraisons. En pratiquant installation, configuration, branches, remotes, merge/rebase et commandes avancées sur de vrais projets, vous posez les bases solides pour Azure Repos et toute la chaîne DevOps. Revenez à ce guide comme aide-mémoire, puis passez aux laboratoires pipelines et boards du parcours Azure.

Bonnes pratiques quotidiennes pour une équipe DevOps

Au-delà des commandes, la valeur de Git vient des conventions. Découpez les commits en unités logiques (une intention = un commit), évitez les commits fourre-tout « fix stuff », et synchronisez souvent avec le remote pour réduire la taille des conflits. Avant une pull request Azure Repos, relisez git log --oneline --graph -20 et git diff main...HEAD : vous vérifiez le périmètre exact de la revue. Activez le rebase automatique à l’intégration seulement si l’équipe l’a décidé ; sinon, merge commits restent lisibles pour auditer « quand la feature est entrée dans main ».

Côté sécurité, refusez les commits qui ajoutent des clés API, des fichiers .pem ou des dumps de base. Un outil comme git-secrets ou un hook pre-commit (detect-secrets, gitleaks) bloque ces fuites avant le push. Sur Azure DevOps, couplez cela à des branch policies : build obligatoire, un ou deux reviewers, et interdiction du push direct sur main.

Cloner un dépôt existant et basculer rapidement

Quand le projet existe déjà, vous n’initialisez pas : vous clonez. Le clone récupère l’historique et crée le remote origin automatiquement. Ensuite, créez votre branche de travail immédiatement pour ne jamais committer par accident sur main.

git clone https://dev.azure.com/Org/Project/_git/my-project
cd my-project
git switch -c feature/observability
git status

La commande moderne git switch (et git restore) clarifie l’intention par rapport à l’ancien checkout polyvalent. Gardez checkout en tête pour lire d’anciens tutoriels, mais préférez switch/restore dans vos scripts 2026.

Stratégie de branches simple et scalable

Pour une petite équipe, une branche main protégée + des feature branches courtes (< 3 jours) suffit. Pour un produit multi-environnements, ajoutez éventuellement release/* et des hotfixes depuis un tag. L’anti-pattern classique est la branche longue de plusieurs semaines : plus elle vit, plus le rebase/merge coûtera cher. Préférez des PR petites, fréquentes, avec CI verte sur chaque push. Git ne remplace pas la communication : un titre de PR clair et un lien vers le work item Azure Boards accélèrent la revue plus qu’un historique parfait.

Vérifier l’historique et récupérer un fichier

Quand un bug apparaît, l’historique devient votre microscope. Affichez qui a touché une ligne, restaurez un fichier depuis main, ou cherchez un commit par message :

git log --oneline --graph --decorate -15
git blame README.md
git restore --source=main -- README.md
git log --grep="healthcheck"

Ces commandes évitent de « tout réécrire » à la main. En production, un revert d’un commit fautif sur main reste la voie sûre : l’historique public n’est pas réécrit, et le pipeline peut redéployer immédiatement.

FAQ

Quel est l’avantage principal d’un système de contrôle de version distribué comme Git ?

Chaque développeur possède une copie complète de l’historique : travail hors ligne, branches locales rapides, et collaboration résiliente sans dépendre d’un unique serveur central.

Comment résoudre efficacement un conflit de merge ?

Ouvrez les fichiers en conflit, éditez les sections marquées, indexez les fichiers résolus avec git add, puis finalisez avec git commit (ou git rebase --continue si vous étiez en rebase).

Faut-il préférer merge ou rebase pour une feature branch ?

Utilisez merge quand l’historique exact des branches compte. Choisissez rebase pour un historique linéaire avant fusion dans main, surtout si la branche n’est pas encore partagée largement.

Comment annuler le dernier commit sans perdre les modifications ?

Exécutez git reset --soft HEAD~1 : le pointeur de branche recule d’un commit et vos changements restent dans l’index, prêts à être recommités.

À quoi sert git stash ?

git stash met de côté temporairement des changements non commités pour changer de branche ou tirer des mises à jour, puis les restaurer avec git stash pop.

Retour parcours Azure DevOps — hub de la série et leçons sœurs Git / Repos / Pipelines.

Retour parcours Git — hub de la série et leçons sœurs.