Puis-je imbriquer des dépôts Git ? J'en ai :
/project_root/
/project_root/my_project
/project_root/third_party_git_repository_used_by_my_projectEst-ce que cela a un sens de git init/add le site /project_root pour faciliter la gestion de tout au niveau local ou dois-je gérer my_project et celui de la tierce partie séparément ?
Vous recherchez peut-être la fonctionnalité de Git appelée sous-modules . Cette fonctionnalité vous aide à gérer les référentiels dépendants qui sont imbriqués dans votre référentiel principal.
Le blog de chrisjean.com ne semble pas être à jour d'après ce que j'ai essayé de faire. L'article de Greg sur le wiki est peut-être un peu plus compliqué, mais en tant que novice de git, je préfère la précision à la simplicité...
Le blog semble fonctionner correctement maintenant, et malheureusement pour Sage, les 34 (maintenant 35) votes positifs sur le commentaire semblent convenir qu'il y a une valeur dans l'article du blog. Il s'avère qu'il n'est pas nécessaire de sacrifier l'exactitude à la clarté et aux conseils spécifiques aux opérations. Après l'avoir lu, j'imagine que l'auteur s'était déjà un peu documenté et qu'il avait probablement lu l'article en question. Documentation Git et pas seulement la page wiki de kernel.org. L'explication orientée Git de l'auteur du blog dans un exemple entièrement contextualisé semble être très utile pour un grand nombre de personnes...
BTW le lien de chrisjean mentionné ci-dessus est mort. Le lien mis à jour est chrisjean.com/git-submodules-ajouter-utiliser-retrait-et-mise-a-jour
Placez vos bibliothèques tierces dans un dépôt séparé et utilisez des submodules pour les associer au projet principal. Voici un exemple : Outils Git - Submodules (Livre Pro Git, 2ème édition)
Pour décider comment segmenter un repo, je me base généralement sur la fréquence de mes modifications. S'il s'agit d'une bibliothèque tierce et que les seules modifications que vous y apportez sont la mise à niveau vers une version plus récente, vous devez absolument la séparer du projet principal.
Juste pour être complet :
Il existe une autre solution, que je vous recommande : fusion de sous-arbres .
Contrairement aux submodules, il est plus facile à maintenir. Vous créerez chaque dépôt de la manière habituelle. Alors que dans votre dépôt principal, vous voulez fusionner le master (ou toute autre branche) d'un autre dépôt dans un répertoire de votre répertoire principal.
$ git remote add -f ThirdPartyGitRepo /project_root/
$ git merge -s ours --no-commit ThirdPartyGitRepo/master
$ git read-tree --prefix=third_party_git_repository_used_by_my_project/ -u ThirdPartyGitRepo/master
$ git commit -m "Merge ThirdPartyGitRepo project as our subdirectory"`Ensuite, afin de tirer l'autre référentiel dans votre répertoire (pour le mettre à jour), utilisez la stratégie de fusion de sous-arbres :
$ git pull -s subtree ThirdPartyGitRepo masterJ'utilise cette méthode depuis des années maintenant, elle fonctionne :-)
Plus d'informations sur cette méthode, y compris la comparaison avec les sous-modules, peuvent être trouvées dans ce git. manuel d'utilisation .
La référence à la fusion de sous-arbres dans le livre git ne fonctionne plus. Actuellement, ceci semble être le lien : git-scm.com/book/fr/v2/
Puis-je vous demander si vous pouvez utiliser les chemins du PO, par ex. /project_root/my_project m'aiderait à y voir plus clair. Mes deux projets sont activement développés, donc subtree me semble meilleur que submodule.
Vous pourriez ajouter
/project_root/third_party_git_repository_used_by_my_projectà
/project_root/.gitignorequi devrait empêcher le repo imbriqué d'être inclus dans le repo parent, et vous pouvez travailler avec eux indépendamment.
Mais : Si un utilisateur exécute git clean -dfx dans le repo parent, cela supprimera le repo imbriqué ignoré. Une autre façon est de faire un lien symbolique avec le dossier et d'ignorer le lien symbolique. Si vous exécutez ensuite git clean, le lien symbolique est supprimé, mais le repo 'imbriqué' reste intact car il réside réellement ailleurs.
git-subtree vous aidera à travailler avec plusieurs projets dans une seule et même arborescence y conserver un historique séparable pour eux.
Cette fonctionnalité a ensuite été fusionnée dans Git. Voici une belle description : developer.atlassian.com/blog/2015/05/the-power-of-git-subtree
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
