Référentiels git nesteds?

Puis-je imbriquer des repositorys git? J’ai:

/project_root/ /project_root/my_project /project_root/third_party_git_repository_used_by_my_project 

Est-il judicieux de lancer init / add le / project_root pour faciliter la gestion de tout en local ou dois-je gérer my_project et le site tiers séparément?

Vous recherchez peut-être la fonctionnalité Git appelée sous-modules . Cette fonctionnalité vous aide à gérer les référentiels dépendants nesteds dans votre référentiel principal.

Placez vos bibliothèques tierces dans un référentiel distinct et utilisez des sous-modules pour les associer au projet principal. Voici un parcours:

http://git-scm.com/book/en/Git-Tools-Submodules

En décidant comment segmenter un repository, je déciderais généralement en fonction de la fréquence à laquelle je les modifierais. S’il s’agit d’une bibliothèque tierce et que seules les modifications que vous y apportez sont mises à niveau vers une version plus récente, vous devez absolument la séparer du projet principal.

Juste pour être complet:

Il y a une autre solution, je recommanderais: la fusion de sous – arbre .

Contrairement aux sous-modules, il est plus facile à entretenir. Vous créez chaque repository de la manière habituelle. Dans votre repository principal, vous souhaitez fusionner le maître (ou toute autre twig) d’un autre référentiel dans un répertoire de votre répertoire principal.

 $ git remote add -f OtherRepository /path/to/that/repo $ git merge -s ours --no-commit OtherRepository/master $ git read-tree --prefix=AnyDirectoryToPutItIn/ -u OtherRepository/master $ git commit -m "Merge OtherRepository project as our subdirectory"` 

Ensuite, pour extraire l’autre référentiel dans votre répertoire (pour le mettre à jour), utilisez la stratégie de fusion de sous-arborescence:

 $ git pull -s subtree OtherRepository master 

J’utilise cette méthode depuis des années, ça marche 🙂

Vous trouverez plus d’informations sur cette manière, y compris la comparaison avec des sous-modules, dans ce doc .

git-subtree vous aidera à travailler avec plusieurs projets dans un seul arbre et conservera un historique séparable.

Vous pourriez append

 /project_root/third_party_git_repository_used_by_my_project 

à

 /project_root/.gitignore 

cela devrait empêcher le repo nested d’être inclus dans le référentiel parent et vous pouvez travailler avec eux indépendamment.

Mais: si un utilisateur exécute git clean -dfx dans le repository parent, il supprimera le référentiel nested ignoré. Une autre manière consiste à créer un lien symbolique entre le dossier et ignorer le lien symbolique. Si vous lancez ensuite git clean, le lien symbolique est supprimé, mais le référentiel “nested” restra intact car il réside vraiment ailleurs.

J’utiliserais un référentiel par projet. De cette façon, l’historique devient plus facile à parcourir.

Je voudrais également vérifier la version de la bibliothèque tierce que j’utilise, dans le référentiel du projet qui l’utilise.