Bonnes pratiques#
Maitriser les commandes de Git est une chose ; les utiliser de manière efficace, propre et sûre en est une autre. Un développeur peut connaitre git rebase, git cherry-pick et git reflog sur le bout des doigts, mais produire malgré tout un historique illisible, committer des secrets en production ou perdre du travail par manque de méthode. Les commandes ne sont que des outils : c’est la discipline qui fait la différence entre un dépôt agréable à parcourir et un dépôt dans lequel personne ne veut plonger.
Ce chapitre consolide les bonnes pratiques qui transforment un usage fonctionnel de Git en un usage professionnel. Il couvre la rédaction des messages de commit, la configuration des fichiers .gitignore et .gitattributes, la sécurité des secrets, les réflexes quotidiens, et se conclut par un tableau de référence des commandes essentielles. C’est un chapitre à relire régulièrement — non pas pour mémoriser, mais pour ancrer des habitudes.
Ecrire de bons messages de commit#
L’historique d’un projet est aussi précieux que son code source. Un git log lisible permet de comprendre pourquoi un changement a été fait, pas seulement quoi a changé. Des messages de commit bien redigés facilitent la revue de code, le debugging avec git bisect, et l’attribution avec git blame.
Définition 84 (Conventional Commits)
Conventional Commits est une spécification qui impose une structure formelle aux messages de commit. Le format est :
type(scope): description
où type décrit la nature du changement, scope (optionnel) précise la partie du projet concernée, et description résume le changement en une phrase courte à l’impératif. Les types les plus courants sont :
feat: ajout d’une nouvelle fonctionnalitéfix: correction d’un bugdocs: modifications de la documentation uniquementstyle: changements de formatage (espaces, points-virgules, etc.) sans modification de logiquerefactor: restructuration du code sans changement de comportementtest: ajout ou correction de testschore: tâches de maintenance (mise à jour de dépendances, configuration)ci: modifications des fichiers et scripts d’intégration continueperf: amélioration des performances
Cette convention permet l’automatisation de la génération de changelogs et du versionnement sémantique.
Les 7 règles d’un bon message de commit#
Chris Beams a formulé sept règles qui font autorité dans la communauté. Elles s’appliquent que l’on adopte ou non Conventional Commits.
Séparer le sujet du corps par une ligne vide. Git utilise la première ligne comme résumé dans
git log --oneline,git shortloget de nombreuses interfaces. La ligne vide permet à Git de distinguer le titre du détail.Limiter le sujet à 50 caractères. Un titre court force la concision et reste lisible dans toutes les interfaces. C’est une limite souple : GitHub tronque à 72 caractères.
Commencer le sujet par une majuscule. Ecrire « Add OAuth support » et non « add OAuth support ».
Ne pas terminer le sujet par un point. L’espace est précieux dans un titre de 50 caractères. Le point final est superflu.
Utiliser l’impératif. Ecrire « Add feature » et non « Added feature » ou « Adds feature ». Le commit complète la phrase : « If applied, this commit will… » — « If applied, this commit will add feature. »
Limiter le corps à 72 caractères par ligne. Git ne fait pas de retour à la ligne automatique. Le corps doit être formaté manuellement à 72 caractères pour rester lisible dans un terminal.
Utiliser le corps pour expliquer quoi et pourquoi, pas comment. Le code montre le comment. Le message de commit doit documenter l’intention et le contexte.
Exemple 21 (Bon message de commit)
Un message de commit bien structuré suit les règles ci-dessus et fournit le contexte nécessaire à la comprehension du changement :
feat(auth): add OAuth2 login flow
Implement Google OAuth2 authentication as an alternative to
email/password login. This allows users to sign in with their
Google account without creating a separate password.
Closes #42
Le sujet fait moins de 50 caractères, utilise l’impératif, commence par une majuscule et ne se termine pas par un point. Le corps explique le pourquoi (offrir une alternative au login par mot de passe) et le quoi (OAuth2 Google). La référence Closes #42 lie automatiquement le commit à l’issue correspondante sur GitHub.
Exemple 22 (Mauvais messages de commit)
Voici des exemples de messages à eviter absolument :
fix
update
WIP
asdf
changes
misc
stuff
.
Ces messages ne communiquent rien. Ils rendent git log inutile, git blame frustrant, et git bisect pénible. Chaque commit est une occasion de documenter le projet ; la gaspiller avec un message vide est une dette technique silencieuse.
Remarque 74
Les bons messages de commit sont de la documentation qui vit pour toujours dans l’historique du projet. Contrairement aux commentaires dans le code, qui peuvent devenir obsolètes quand le code change, un message de commit est immutable : il décrit fidèlement l’état du projet au moment exact où il a été écrit. C’est ce qui rend git blame, git log et git bisect véritablement utiles — à condition que les messages soient informatifs.
.gitignore#
Définition 85 (.gitignore)
Le fichier .gitignore est un fichier texte placé à la racine du dépôt (ou dans un sous-répertoire) qui liste des motifs (patterns) de noms de fichiers et de répertoires que Git doit ignorer — c’est-à-dire ne pas suivre, ne pas indexer et ne pas inclure dans les commits. Les fichiers correspondant aux motifs apparaissent toujours sur le disque, mais Git les traite comme s’ils n’existaient pas.
Un .gitignore bien configuré évite de polluer le dépôt avec des fichiers générés, des dépendances, des fichiers de configuration d’IDE ou — plus grave — des secrets.
Motifs courants#
Les motifs utilisent une syntaxe de globbing :
*.o: tous les fichiers objet Cdist/: le répertoire de build et tout son contenu!important.o: exception — ce fichier est suivi malgré la règle*.o**/logs: un répertoirelogsà n’importe quelle profondeur
Exemple 23 (Un bon .gitignore)
Voici un .gitignore typique couvrant les catégories les plus courantes :
# Build outputs
dist/
build/
*.o
*.pyc
# Dependencies
node_modules/
__pycache__/
.venv/
# IDE
.vscode/
.idea/
*.swp
# OS
.DS_Store
Thumbs.db
# Secrets
.env
.env.local
*.key
*.pem
Les commentaires (lignes commencant par #) sont essentiels pour documenter les sections et faciliter la maintenance du fichier au fil du temps.
.gitignore global#
Certains motifs sont spécifiques à votre environnement de travail (IDE, système d’exploitation) et non au projet. Plutôt que de les ajouter au .gitignore de chaque dépôt, on peut configurer un fichier d’exclusion global.
%%bash
# Configurer un .gitignore global (à exécuter une seule fois)
echo '# Commande pour configurer le gitignore global :'
echo 'git config --global core.excludesFile ~/.gitignore_global'
echo ""
echo '# Contenu typique de ~/.gitignore_global :'
echo '.DS_Store'
echo 'Thumbs.db'
echo '.vscode/'
echo '.idea/'
echo '*.swp'
echo '*~'
# Commande pour configurer le gitignore global :
git config --global core.excludesFile ~/.gitignore_global
# Contenu typique de ~/.gitignore_global
:
.DS_Store
Thumbs.db
.vscode/
.idea/
*.swp
*~
Remarque 75
Le site gitignore.io (ou son équivalent sur GitHub : github.com/github/gitignore) fournit des modèles de .gitignore pour des centaines de langages, frameworks et environnements. Il est recommandé de créer le .gitignore comme premier commit du dépôt, avant même le code source. Cela évite d’indexer accidentellement des fichiers indésirables dès le départ — car un fichier déjà suivi par Git n’est pas affecté par l’ajout ultérieur d’une règle dans .gitignore.
.gitattributes#
Définition 86 (.gitattributes)
Le fichier .gitattributes permet de configurer des attributs par chemin (per-path attributes) qui modifient le comportement de Git pour certains fichiers. Il contrôle notamment :
la normalisation des fins de ligne (conversion CRLF/LF)
la classification des fichiers comme texte ou binaire
le choix du pilote de diff et de la stratégie de fusion
le suivi par Git LFS (Large File Storage)
les marqueurs linguist pour les statistiques GitHub
Exemple de configuration#
Exemple 24 (Fichier .gitattributes)
Un .gitattributes de base pour un projet multi-plateformes :
# Normaliser les fins de ligne pour tous les fichiers texte
* text=auto
# Fichiers binaires : pas de normalisation, pas de diff textuel
*.png binary
*.jpg binary
*.gif binary
*.pdf binary
*.zip binary
# Fichiers générés : exclus des statistiques GitHub
*.lock linguist-generated
package-lock.json linguist-generated
# Git LFS pour les fichiers volumineux
*.psd filter=lfs diff=lfs merge=lfs -text
Remarque 76
L’attribut text=auto est particulièrement important pour les équipes multi-plateformes. Sans lui, les fichiers édités sous Windows conservent des fins de ligne CRLF (\r\n), tandis que ceux édités sous Linux ou macOS utilisent LF (\n). Ce mélange provoque des diffs parasites ou la totalité du fichier apparait modifiée. Avec text=auto, Git normalise automatiquement les fins de ligne à LF dans le dépôt et les convertit au format natif de l’OS dans le répertoire de travail.
Sécurité : ne jamais committer de secrets#
La gestion des secrets est l’une des erreurs les plus graves et les plus fréquentes dans l’utilisation de Git. Un mot de passe ou une clé API committé par mégarde peut avoir des conséquences désastreuses.
Ce qu’il ne faut jamais committer#
Les fichiers suivants n’ont rien à faire dans un dépôt Git :
Clés d’API et tokens d’authentification
Mots de passe et identifiants de base de données
Fichiers
.envcontenant des variables d’environnement sensiblesClés privées SSH ou TLS (
.key,.pem)Fichiers de credentials (
credentials.json,serviceAccountKey.json)
Pourquoi c’est grave#
Un secret committé dans Git est dans l’historique pour toujours — même si on le supprime dans un commit ultérieur. Supprimer un fichier avec git rm crée un nouveau commit ou le fichier n’existe plus, mais tous les commits précédents contiennent encore le secret en clair. N’importe qui ayant accès au dépôt (ou à un fork, ou à un clone) peut le retrouver avec un simple git log ou git show.
%%bash
# Démonstration : un fichier supprimé reste dans l'historique
cd /tmp && rm -rf demo-secret && mkdir demo-secret && cd demo-secret && git init
git config user.email "demo@example.com" && git config user.name "Demo"
echo "DATABASE_PASSWORD=super_secret_123" > .env
git add .env && git commit -m "Add config"
# On réalise l'erreur et on supprime le fichier
git rm .env && git commit -m "Remove secrets"
echo "=== Le fichier n'est plus dans le répertoire ==="
ls -la .env 2>&1 || true
echo ""
echo "=== Mais il est toujours dans l'historique ==="
git log --oneline --all
echo ""
git show HEAD~1:.env
Dépôt Git vide initialisé dans /tmp/demo-secret/.git/
[main (commit racine) df7000c] Add config
1 file changed, 1 insertion(+)
create mode 100644 .env
rm '.env'
[main 847d39d] Remove secrets
1 file changed, 1 deletion(-)
delete mode 100644 .env
=== Le fichier n'est plus dans le répertoire ===
ls:
impossible d'accéder à '.env'
: Aucun fichier ou dossier de ce nom
=== Mais il est toujours dans l'historique ===
847d39d Remove secrets
df7000c Add config
DATABASE_PASSWORD=super_secret_123
Prévention#
La meilleure stratégie est d’empêcher les secrets d’entrer dans l’historique en premier lieu.
.gitignore: ajouter.env,*.key,*.pemet tout fichier de crédentials.Hooks pre-commit : utiliser des outils comme
git-secrets(AWS) oudetect-secrets(Yelp) qui scannent les changements indexés avant chaque commit et bloquent ceux contenant des motifs sensibles.Variables d’environnement : stocker les secrets dans l’environnement du système, pas dans des fichiers versionnés.
Gestionnaires de secrets : utiliser des outils comme HashiCorp Vault, AWS Secrets Manager ou
dopplerpour injecter les secrets au moment de l’exécution.
Récupération en cas d’erreur#
Si un secret a été committé, il faut agir vite :
Rotation immediate : changer le mot de passe, révoquer la clé API, régénérer le token. C’est la première action, avant toute réécriture d’historique.
Réécriture de l’historique : utiliser
git filter-repo(recommandé) ougit filter-branch(obsolète) pour supprimer le fichier de tous les commits.Force push : pousser l’historique réécrit vers le dépôt distant.
Notifier l’équipe : tous les collaborateurs doivent recloner le dépôt.
Remarque 77
Traitez tout secret committé comme compromis, même si le dépôt est privé, même si le commit a été poussé pendant seulement quelques secondes. Des bots automatisés scannent en permanence les dépôts publics GitHub à la recherche de clés exposées. La rotation du secret est la seule mesure véritablement sûre — la réécriture d’historique est un complément, pas un substitut.
Bonnes pratiques au quotidien#
Au-dela des règles formelles, un usage efficace de Git repose sur des réflexes quotidiens. Ces habitudes, simples individuellement, font collectivement la différence entre un dépôt sain et un dépôt chaotique.
Committer souvent, pousser régulièrement#
Des commits fréquents créent des points de sauvegarde granulaires. Si quelque chose tourne mal, on peut revenir à un état récent sans perdre beaucoup de travail. Pousser régulieèrement vers le dépôt distant ajoute une couche de sauvegarde et rend le travail visible pour l’équipe.
Un changement logique par commit#
Chaque commit doit représenter une unité logique de changement : une fonctionnalité, une correction de bug, un refactoring. Mélanger plusieurs changements non liés dans un même commit rend l’historique confus et complique les opérations comme git revert ou git cherry-pick.
%%bash
# Bonne pratique : vérifier ses changements avant de committer
cd /tmp && rm -rf demo-pratiques && mkdir demo-pratiques && cd demo-pratiques && git init
git config user.email "demo@example.com" && git config user.name "Demo"
echo "initial" > app.py && echo "initial" > utils.py && git add . && git commit -m "Initial commit"
# Modification de deux fichiers
echo "feature A" >> app.py
echo "refactor utils" >> utils.py
echo "=== Toujours vérifier le diff avant de committer ==="
git diff
echo ""
echo "=== Committer les changements séparément ==="
git add app.py && git commit -m "feat: add feature A"
git add utils.py && git commit -m "refactor: simplify utils module"
git log --oneline
Dépôt Git vide initialisé dans /tmp/demo-pratiques/.git/
[main (commit racine) e98fb26] Initial commit
2 files changed, 2 insertions(+)
create mode 100644
app.py
create mode 100644 utils.py
=== Toujours vérifier le diff avant de committer ===
diff --git a/app.py b/app.py
index e79c5e8..0e838bf 100644
--- a/app.py
+++ b/app.py
@@ -1 +1,2 @@
initial
+feature A
diff --git a/utils.py b/utils.py
index e79c5e8..a4e0a7c 100644
--- a/utils.py
+++
b/utils.py
@@ -1 +1,2 @@
initial
+refactor utils
=== Committer les changements séparément ===
[main 0d2ba10] feat: add feature A
1 file changed, 1 insertion(+)
[main 9c8eb51] refactor: simplify utils module
1 file changed, 1 insertion(+)
9c8eb51 refactor: simplify utils module
0d2ba10 feat: add feature A
e98fb26 Initial commit
Tirer avant de pousser#
Avant de faire git push, toujours exécuter git pull --rebase (ou git fetch suivi de git rebase) pour intégrer les éventuels changements distants. Cela évite les commits de fusion parasites et réduit les risques de conflits.
Garder les branches courtes#
Une branche de fonctionnalité devrait vivre quelques jours, pas quelques semaines. Plus une branche diverge de main, plus la fusion sera pénible. Les branches courtes encouragent les petites pull requests, qui sont plus faciles à revoir et moins susceptibles de générer des conflits.
Supprimer les branches fusionnées#
Après la fusion d’une branche, la supprimer immédiatement. Les branches obsolètes encombrent la liste et sèment la confusion. On peut automatiser ce nettoyage.
%%bash
cd /tmp && rm -rf demo-bp-clean && mkdir demo-bp-clean && cd demo-bp-clean && git init
git config user.email "demo@example.com" && git config user.name "Demo"
echo "init" > file.txt && git add . && git commit -m "Initial"
# Créer et fusionner une branche
git checkout -b feature-x
echo "feature" >> file.txt && git add . && git commit -m "feat: add feature X"
git checkout main && git merge feature-x
echo "=== Branches avant nettoyage ==="
git branch
# Supprimer la branche fusionnée
git branch -d feature-x
echo ""
echo "=== Branches après nettoyage ==="
git branch
Dépôt Git vide initialisé dans /tmp/demo-bp-clean/.git/
[main (commit racine) bd8e2e8] Initial
1 file changed, 1 insertion(+)
create mode 100644 file.txt
Basculement sur la nouvelle branche 'feature-x'
[feature-x d0f8073] feat: add feature X
1 file changed, 1 insertion(+)
Basculement sur la branche 'main'
Mise à jour bd8e2e8..d0f8073
Fast-forward
file.txt | 1 +
1 file changed, 1 insertion(+)
=== Branches avant nettoyage ===
feature-x
* main
Branche feature-x supprimée (précédemment d0f8073).
=== Branches après nettoyage ===
* main
Utiliser stash plutôt que des commits sales#
Quand on doit changer de contexte rapidement, git stash est préférable à un commit avec un message du type « WIP » ou « temp ». Le stash garde le travail en cours hors de l’historique et le restaure exactement dans l’état où il était.
Relire son diff avant de committer#
La commande git diff --staged affiche exactement ce qui sera inclus dans le prochain commit. C’est le dernier rempart avant de graver un changement dans l’historique — l’occasion de repérer un console.log oublié, un fichier de configuration modifié par erreur ou un secret qui s’est glissé dans le diff.
Remarque 78
Ces pratiques ne sont pas des règles absolues. Dans un projet personnel ou un prototype rapide, on peut légitimement se permettre des commits moins structurés. L’essentiel est de comprendre pourquoi ces pratiques existent pour pouvoir les appliquer consciemment dans les contextes ou elles comptent — c’est-à-dire, principalement, tout projet collaboratif ou tout projet destiné à durer.
Résumé des commandes essentielles#
Le tableau suivant récapitule les commandes Git les plus courantes, organisées par catégorie. Pour chaque commande, on indique l’usage le plus fréquent. Ce n’est pas un substitut à la documentation (git help <commande>), mais un aide-mémoire pour retrouver rapidement la bonne commande.
Commandes de base#
%%bash
echo "Commande | Description"
echo "-----------------------------------|--------------------------------------------"
echo "git init | Initialiser un nouveau dépôt"
echo "git clone <url> | Cloner un dépôt distant"
echo "git add <fichier> | Indexer un fichier pour le prochain commit"
echo "git add -A | Indexer tous les changements"
echo "git commit -m \"message\" | Creer un commit avec un message"
echo "git status | Afficher l'état du répertoire de travail"
echo "git diff | Afficher les modifications non indexées"
echo "git diff --staged | Afficher les modifications indexées"
echo "git log --oneline --graph | Afficher l'historique en format compact"
Commande | Description
-----------------------------------|--------------------------------------------
git init
| Initialiser un nouveau dépôt
git clone <url> | Cloner un dép
ôt distant
git add <fichier> | Indexer un fichier pour le prochain commit
git add
-A | Indexer tous les changements
git commit -m "message" | Creer
un commit avec un message
git status | Afficher l'état du répertoire de t
ravail
git diff | Afficher les modifications non indexées
git diff --staged | Afficher les modifications indexées
git log --oneline --graph
| Afficher l'historique en format compact
Branches et fusion#
%%bash
echo "Commande | Description"
echo "-----------------------------------|--------------------------------------------"
echo "git branch | Lister les branches locales"
echo "git branch <nom> | Créer une nouvelle branche"
echo "git switch <branche> | Changer de branche"
echo "git switch -c <branche> | Créer et basculer sur une nouvelle branche"
echo "git merge <branche> | Fusionner une branche dans la branche courante"
echo "git rebase <branche> | Rebaser la branche courante sur une autre"
echo "git branch -d <branche> | Supprimer une branche fusionnée"
Commande | Description
-----------------------------------|--------------------------------------------
git branch
| Lister les branches locales
git branch <nom> | Créer une nouvel
le branche
git switch <branche> | Changer de branche
git switch -c <branche>
| Créer et basculer sur une nouvelle branche
git merge <branche> | Fusionner une b
ranche dans la branche courante
git rebase <branche> | Rebaser la branche courante sur
une autre
git branch -d <branche> | Supprimer une branche fusionnée
Dépôt distant#
%%bash
echo "Commande | Description"
echo "-----------------------------------|--------------------------------------------"
echo "git remote -v | Lister les dépôts distants"
echo "git remote add <nom> <url> | Ajouter un dépôt distant"
echo "git fetch | Récupérer les changements distants"
echo "git pull | Fetch + merge de la branche suivie"
echo "git pull --rebase | Fetch + rebase de la branche suivie"
echo "git push | Pousser les commits vers le dépôt distant"
echo "git push -u origin <branche> | Pousser et configurer le suivi"
Commande | Description
-----------------------------------|--------------------------------------------
git remote -v
| Lister les dépôts distants
git remote add <nom> <url> | Ajouter un dép
ôt distant
git fetch | Récupérer les changements distants
git pull | Fetch + merge de la branche suivie
git pull --rebase
| Fetch + rebase de la branche suivie
git push | Pousser les commit
s vers le dépôt distant
git push -u origin <branche> | Pousser et configurer le suivi
Annulation et nettoyage#
%%bash
echo "Commande | Description"
echo "-----------------------------------|--------------------------------------------"
echo "git restore <fichier> | Annuler les modifications non indexées"
echo "git restore --staged <fichier> | Désindexer un fichier"
echo "git reset --soft HEAD~1 | Annuler le dernier commit (garder les changements)"
echo "git reset --mixed HEAD~1 | Annuler le commit et la staging area"
echo "git reset --hard HEAD~1 | Annuler le commit et les changements (destructif)"
echo "git revert <commit> | Créer un commit inversé (sur)"
echo "git stash | Mettre de côté le travail en cours"
echo "git stash pop | Restaurer le dernier stash"
echo "git clean -fd | Supprimer les fichiers non suivis (destructif)"
Commande | Description
-----------------------------------|--------------------------------------------
git restore <fichie
r> | Annuler les modifications non indexées
git restore --staged <fichier> | Dési
ndexer un fichier
git reset --soft HEAD~1 | Annuler le dernier commit (garder les changem
ents)
git reset --mixed HEAD~1 | Annuler le commit et la staging area
git reset --hard HEA
D~1 | Annuler le commit et les changements (destructif)
git revert <commit>
| Créer un commit inversé (sur)
git stash | Mettre de côté le travail en cours
git stash pop
| Restaurer le dernier stash
git clean -fd | Supprimer les fichiers no
n suivis (destructif)
Inspection et recherche#
%%bash
echo "Commande | Description"
echo "-----------------------------------|--------------------------------------------"
echo "git log --all --oneline --graph | Visualiser le graphe complet des commits"
echo "git log -p <fichier> | Historique detaillé d'un fichier"
echo "git blame <fichier> | Voir qui a modifié chaque ligne"
echo "git bisect start | Lancer une recherche dichotomique de bug"
echo "git grep <motif> | Chercher un motif dans les fichiers suivis"
echo "git show <commit> | Afficher le contenu d'un commit"
echo "git shortlog -sn | Classement des contributeurs par commits"
Commande | Description
-----------------------------------|--------------------------------------------
git log --all --one
line --graph | Visualiser le graphe complet des commits
git log -p <fichier> | Hist
orique detaillé d'un fichier
git blame <fichier> | Voir qui a modifié chaque ligne
git bisect start | Lancer une recherche dichotomique de bug
git grep <motif>
| Chercher un motif dans les fichiers suivis
git show <commit> | Affic
her le contenu d'un commit
git shortlog -sn | Classement des contributeurs par com
mits
Commandes avancées#
%%bash
echo "Commande | Description"
echo "-----------------------------------|--------------------------------------------"
echo "git cherry-pick <commit> | Appliquer un commit spécifique"
echo "git tag -a v1.0 -m \"msg\" | Créer un tag annoté"
echo "git submodule add <url> | Ajouter un sous-module"
echo "git reflog | Historique de tous les mouvements de HEAD"
echo "git worktree add <path> <branche> | Ouvrir une branche dans un autre répertoire"
echo "git filter-repo | Réécrire l'historique (outil externe)"
Commande | Description
-----------------------------------|--------------------------------------------
git cherry-pick <co
mmit> | Appliquer un commit spécifique
git tag -a v1.0 -m "msg" | Créer un tag
annoté
git submodule add <url> | Ajouter un sous-module
git reflog
| Historique de tous les mouvements de HEAD
git worktree add <path> <branche> | Ouvrir une bran
che dans un autre répertoire
git filter-repo | Réécrire l'historique (outil ex
terne)
Résumé#
Git est un outil qui récompense la compréhension plutôt que la mémorisation. Les commandes s’oublient et se retrouvent facilement dans la documentation ; ce sont les principes qui comptent. Ecrire des messages de commit clairs, configurer le .gitignore dès le départ, ne jamais committer de secrets, committer souvent et en unités logiques — ces habitudes semblent évidentes une fois acquises, mais elles demandent une discipline consciente au début.
Ce chapitre clôture le livre. De l’installation initiale aux mécanismes internes, en passant par les branches, les fusions, le rebase, les workflows collaboratifs et les hooks, nous avons parcouru Git dans sa profondeur. La maitrise viendra avec la pratique — et avec les erreurs, car Git a été conçu pour permettre de se tromper et de se rattraper. C’est peut-être sa plus grande qualité.