Git worktree ou submodule : lequel choisir ?
Ces blocs sont des cas différents, pas un script unique. Choisissez celui de votre dépôt. Remplacez branches, chemins et VERIFIED_COMMIT avant usage. Les commandes d’annulation concernent seulement leur opération active ; n’exécutez pas les deux alternatives.
Réponse courte
Utilisez worktree pour un autre checkout du même dépôt en parallèle ou pour revoir une branche. Utilisez submodule quand le parent doit enregistrer un commit précis d’un autre dépôt comme dépendance. L’un ajoute un répertoire à l’historique partagé ; l’autre apporte un dépôt versionné séparément dont le parent conserve la sélection.
| Décision | Worktree | Submodule |
|---|---|---|
| Historique | Même dépôt ; objets et références partagés | Dépôt enfant distinct ; parent enregistre un commit |
| Fichiers | HEAD, index et répertoire propres | Checkout enfant et pins commité/indexé peuvent différer |
| Version | Branche ou commit du même dépôt | Commit enfant sélectionné, pas seulement .gitmodules |
| Actualisation | Examiner et intégrer la branche choisie | Checkout du pin enregistré ; --remote est un autre choix |
| Limite | Normalement un checkout par branche ; pas un sandbox | Support incomplet dans plusieurs worktrees ; travail enfant séparé |
Exemple et conditions
Déterminez d’abord qui gère l’historique. Deux agents testant des corrections d’une application ont généralement besoin de branches et d’arbres séparés. Une bibliothèque publiée indépendamment peut demander un pin. Aucun mécanisme n’est un sandbox de permissions : accès aux fichiers et aux agents demandent leurs propres contrôles.
Examiner avant de modifier
Un worktree lié possède HEAD, index et fichiers propres, mais partage les objets et la plupart des références. Il permet de revoir une autre branche sans remplacer votre checkout. Git empêche normalement la même branche dans deux worktrees. Partager les objets ne recopie pas automatiquement les modifications non indexées.
git status --short
git branch --show-current
git worktree listGarder une référence ou un checkout séparé
Examinez l’état et créez review/worktree dans ../topic-review. Utilisez git -C pour inspecter ce checkout et comparer ses commits avant l’intégration choisie. Des répertoires séparés réduisent le mélange de tâches sans rendre les modifications compatibles. Vérifiez l’intégration et évitez deux outils modifiant simultanément le même checkout.
git worktree add -b review/worktree ../topic-review HEAD
git -C ../topic-review status --short
git -C ../topic-review branch --show-currentPremier parcours
Un submodule est un autre dépôt dans un chemin du parent. L’arbre commité du parent conserve un gitlink, normalement mode 160000, vers un commit enfant. L’index peut préparer un autre pin et le checkout enfant différer des deux. .gitmodules décrit chemin et URL ; le commit enregistré détermine la version.
Choisir l’autre résultat consciemment
Pour deps/library, inspectez séparément submodule status, gitlink de HEAD du parent, gitlink indexé et HEAD de l’enfant. Un pull du parent peut changer le pin sans déplacer le checkout enfant. Submodule update consomme la sélection enregistrée ; --remote suit volontairement une sélection distante, décision de version différente d’un nettoyage d’état.
git submodule status -- deps/library
git ls-tree HEAD -- deps/library
git ls-files --stage -- deps/library
git -C deps/library rev-parse HEAD
git --no-optional-locks -C deps/library status --shortLimites et exceptions
Git documente un support incomplet des submodules dans plusieurs worktrees. --recursive ne transforme pas toute combinaison en environnement isolé supporté. Vérifiez les limites et le véritable parcours de checkout/mise à jour ; envisagez un clone séparé pour un état indépendant. Cette comparaison n’est pas une recette universelle d’automatisation combinée.
Conflits et nettoyage
Avant de retirer un worktree, examinez fichiers locaux et branche, puis utilisez worktree remove au lieu d’effacer aveuglément le dossier. Gardez la branche utile ou le merge revu. Avant de modifier un pin, commitez et publiez le changement enfant selon son propre parcours, afin qu’un autre clone puisse l’obtenir, puis enregistrez le pin parent.
git -C ../topic-review status --short
git worktree remove ../topic-review
git worktree listVérifier le résultat
Pour worktree, vérifiez branche, état et résultat intégré. Pour submodule, comparez les trois états et assurez-vous que le public prévu peut obtenir l’objet enfant. Un parent propre ne garantit pas des enfants propres. Aucun mécanisme ne conserve un backup permanent des fichiers non commités ; vérifiez selon la relation des historiques.
git worktree list
git submodule status -- deps/libraryQuestions fréquentes
Pourquoi worktree ? Une autre branche sans remplacer le checkout actuel. Quand submodule ? Une dépendance versionnée séparément fixée dans le parent. Pourquoi les éviter ? Leurs règles d’actualisation ajoutent de la coordination. Gestionnaire de paquets, vendoring, subtree ou clone séparé sont des alternatives selon propriété et livraison, sans gagnant universel.
Examiner l’opération dans FluxGit
Utilisez l’historique visuel et la vue des modifications de FluxGit pour examiner l’opération et les commits concernés. Gardez les vérifications de branche, de partage et de fichiers locaux de cet exemple. La page de téléchargement présente les builds et plateformes disponibles.