Comment créer un dépôt Git contenant plusieurs autres dépôts Git?

Question

Disons que je veux créer un nouveau site Web et utiliser git pour suivre mes révisions. Maintenant, je veux inclure plusieurs choses utiles sur mon site qui proviennent des dépôts git d’autres personnes, comme:

html5-boilerplate jquery colorbox

Chacun a son propre dépôt, que je place dans différents dossiers de mon site. Comment puis-je créer/mettre à jour mon rapport pour qu'il inclue ces autres dépôts? ... avec le dossier scr ou code de chaque dépôt situé au bon endroit dans mon référentiel. Exemple: le dossier html5 boilerplate '/ src' doit être le répertoire racine de mon site Web.

Est-il possible d'obtenir automatiquement des mises à jour? Si je modifie l'un des fichiers de l'autre dépôt, comment puis-je conserver les modifications directement ??

Puis-je avoir un clone de dépôt "html5 boilerplate"/"jquery" sur mon serveur Debian et utiliser des liens symboliques pour le placer à l'endroit souhaité? Comment?

mperrin · Answer

Bien que l’utilisation du gestionnaire de dépendances soit vraiment encouragée, car ils font bien plus que simplement inclure des référentiels distants (configuration minimale/maximale requise, téléchargement des dépendances, incompatibilités, etc.), mais il existe plusieurs autres solutions permettant d’inclure des référentiels git dans un git principal. dépôt.

Chaque solution peut être appropriée en fonction de la manière dont vous souhaitez inclure et utiliser les sources distantes:

>> sous-module git

Avec le sous-module git, le code et l’historique restent dans chaque référentiel. L'utilisation d'un sous-module peut devenir fastidieuse lorsque branchement et que certains développeurs partagent leurs conseils ou leur haine travaille avec des sous-modules.

Un sous-module vous permet de conserver un autre référentiel Git dans un sous-répertoire de votre référentiel. L'autre référentiel a son propre historique, qui n'interfère pas avec l'historique du référentiel actuel. Cela peut être utilisé pour avoir des dépendances externes telles que des bibliothèques tierces, par exemple.

Lors du clonage ou de l'extraction d'un référentiel contenant des sous-modules, ceux-ci ne seront pas extraits par défaut. les sous-commandes init et update maintiendront les sous-modules extraits et révisés de manière appropriée dans votre arbre de travail.

>> sous-arbre git

Avec git subtree, le code et l'historique sont fusionnés dans le référentiel git de niveau supérieur. Le sous-arbre Git a une approche beaucoup plus simple pour inclure des référentiels git distants et a other avantages sur les sous-modules. Cependant, il devient très complexe à utiliser si de nombreuses modifications de code doivent être effectuées et envoyées dans les référentiels inclus.

Les sous-arbres permettent d'inclure des sous-projets dans un sous-répertoire du projet principal, en incluant éventuellement l'historique complet du sous-projet.

Par exemple, vous pouvez inclure le code source d'une bibliothèque en tant que sous-répertoire de votre application.

Les sous-arbres ne doivent pas être confondus avec les sous-modules, qui sont destinés à la même tâche. Contrairement aux sous-modules, les sous-arbres n'ont pas besoin de constructions spéciales (telles que des fichiers .gitmodule ou gitlinks) dans votre référentiel, et n'obligent pas les utilisateurs finaux de votre référentiel à faire quelque chose de spécial ou à comprendre le fonctionnement des sous-arbres. Un sous-arbre est simplement un sous-répertoire dans lequel vous pouvez valider, créer des branches et fusionner avec votre projet.

>> git slave

Git slave peut être utile si votre flux de travail doit exécuter les mêmes opérations git sur plusieurs référentiels liés à un projet.

Gitslave crée un groupe de référentiels associés - un référentiel de superprojet et un certain nombre de référentiels esclaves - qui sont tous développés simultanément sur lesquels toutes les opérations git devraient normalement fonctionner. Ainsi, lorsque vous branchez, chaque référentiel du projet est créé à son tour. De même lorsque vous validez, Push, Pull, Fusion, Tag, Checkout, statut, journal, etc. chaque commande git sera exécutée tour à tour sur le superprojet et tous les référentiels esclaves. Ce type d’activité peut être très familier aux utilisateurs de CVS et (dans une moindre mesure) de Subversion. La conception de Gitslave vise la simplicité pour les opérations git normales.

>> google repo

Repo est un outil conçu par Google sur Git pour les aider à gérer les 17 Go du code source Android en interaction avec leur système d'intégration continue. Cela peut être utile lorsque vous travaillez avec un très grand nombre de référentiels git. Il utilise un fichier XML manifeste pour décrire les référentiels à obtenir et leur emplacement dans l'arborescence du projet. Repo prend en charge le clonage multithread git, les instantanés, les opérations Shell sur plusieurs référentiels ...

Repo est un outil que nous (Google) avons construit sur Git. Repo nous aide à gérer les nombreux référentiels Git, effectue les téléchargements sur notre système de contrôle de révision et automatise des parties du flux de travaux de développement Android. Repo n'a pas pour vocation de remplacer Git, mais uniquement de faciliter le travail avec Git dans le contexte d'Android. La commande repo est un script exécutable Python que vous pouvez placer n'importe où dans votre chemin.

>> gr

Gr est un projet beaucoup moins connu et ne permet pas d'inclure des dépôts git dans un autre. Cependant, il est très utile de gérer plusieurs référentiels git en leur attribuant des balises et en effectuant des opérations git sur les référentiels git sélectionnés (ou tous) en une seule commande. Vraiment utile pour obtenir toutes les mises à jour des télécommandes, ou s’assurer d’avoir un engagement ou pousser tout notre travail.

Tag toutes les choses! gr @work foo exécutera la commande foo dans tous les chemins balisés @work.

Découverte automatique des référentiels git pour une configuration et une gestion faciles des balises.

gr ne réinvente aucune opération git, mais passe et exécute des commandes inconnues. Tout votre git-fu fonctionnera toujours! par exemple. gr @work git fetch est identique à l'exécution de git fetch dans tous les chemins balisés @work.

Commandes intégrées pour les points douloureux courants: statut des résumés d'une ligne de mises en pension (modifiés, en arrière/en avant, tags)

Extensible via des plugins et des intergiciels: REST Gestionnaires de requêtes de type API/Connect (fonction (req, res, next)) {...}

Tim Fountain · Answer

Ce que vous décrivez est fondamentalement git submodules . Cependant, les sous-modules ont leurs bizarreries et seraient probablement plus problématiques qu'ils ne valent la peine pour ce cas d'utilisation.

Pour vos dépendances JavaScript, vous feriez mieux d'utiliser quelque chose comme Bower . (Il existe également d'autres options dans le monde JS.) Si vous effectuez une programmation côté serveur, il existe généralement des outils de gestion des dépendances spécifiques à la langue (par exemple, Composer pour PHP, Bundler pour les rails, etc.).

"Obtenir automatiquement les mises à jour" n'est pas toujours une bonne idée. Ces outils vous permettent de contrôler les versions de vos dépendances utilisées par votre projet, tout en vous offrant un moyen simple (une commande) de les mettre à jour.