Git lit la config depuis plusieurs fichiers dans l'ordre : système, global (~/.gitconfig), local (.git/config), worktree (quand activé) et ligne de commande (-c). Les couches plus tardives écrasent les antérieures.
La plupart des plateformes attendent ce flux : forker le repo upstream, cloner votre fork, brancher pour le changement, push, ouvrir une pull request. Git le traite comme un workflow triangulaire avec deux remotes.
Un monorepo héberge plusieurs projets dans un dépôt — meilleurs refactors, changements atomiques cross-projets, un seul graphe de dépendances. Le coût : l'échelle. Les repos peuvent croître à des gigaoctets et des millions de fichiers, où Git naïf devient pénible.
Les workflows réels impliquent souvent plus d'un remote : un origin pour votre fork, un upstream pour le repo canonique, plus des mirrors, cibles de déploiement et forks par environnement.
Sparse checkout peuple uniquement un sous-ensemble de l'arbre de travail d'un repo, tout en conservant toutes les métadonnées et l'histoire. Pour les monorepos, cela peut signifier faire checkout de 1% des fichiers et ignorer les 99% restants, accélérant dramatiquement git status, l'indexation IDE et l'usage disque.
Stash est plus capable que le simple save/pop que vous voyez d'habitude. Bien utilisé, c'est un brouillon personnel pour les changements de contexte qui surpasse de commiter du WIP dans la branche.
git archive produit un instantané tar ou zip d'un tree — code sans histoire, parfait pour les releases. git bundle produit un fichier de transport portable contenant des objets et refs — parfait pour le transfert offline d'un repo entier.
git notes attache des métadonnées arbitraires à des commits existants sans changer leurs SHAs. Reviews, statuts de build, sign-offs, métriques de performance — tout ce que vous voulez associer à un commit peut vivre dans des notes. Elles sont stockées dans la ref spéciale refs/notes/commits par défaut.
git range-diff (introduit dans Git 2.19) compare deux plages de commits, les appariant par similarité et montrant les changements entre versions. Il est indispensable lors de la review de rerolls de séries de patches ou de la comparaison de branches rebases.
Beaucoup de projets revoient les patches par série, pas par branche. Vous publiez v1, recevez du feedback, révisez, envoyez v2, répétez jusqu'au merge. Git fournit des outils de première classe pour cette boucle.