Git repo inside repo
Je veux cloner https://github.com/getyouridx/pychargify dans mon projet Django, et devra tirer des mises à jour de temps en temps.
Juste pour clarification, pourrais-je simplement écrire un gitignore depuis le répertoire racine du projet Django par exemple .gitignore: pychargify/.git ou y a-t-il d'autres pièges dont je devrais être conscient?
Pour avoir un dépôt git "à l'intérieur" d'un autre, regardez les sous-modules git: http://git-scm.com/book/en/Git-Tools-Submodules
En faisant pychargify un sous-module de votre projet Django, des révisions spécifiques de votre projet Django peuvent être associées à des révisions spécifiques de votre projet pychargify. Cela peut être très utile .
Je ne sais pas exactement quels sont les dangers de l'approche que vous décrivez, mais elle ne passe pas le test de l'odorat pour moi. Je recommanderais d'utiliser la fonctionnalité Git (sous-modules) conçue spécifiquement pour ce type de chose.
Git a une fonctionnalité pour avoir un référentiel dans un autre: sous-modules .
git submodule add https://github.com/getyouridx/pychargify.git
Assurez-vous de lire toute la documentation sur les sous-modules, car il y a quelques bizarreries impliquées dans leur utilisation, et des étapes supplémentaires qui doivent être prises lors de la création d'un nouveau clone de votre propre référentiel pour initialiser les sous-modules.
Notez également que toutes les commandes de sous-module doivent être exécutées dans le répertoire racine de votre référentiel.
Git ignore automatiquement et ne vous permet même pas d'ajouter un fichier/dossier nommé .git. Vous pouvez donc simplement ajouter un dépôt dans votre dépôt et y travailler. Cependant, vous devrez peut-être ignorer le dossier de dépôt interne pychargify.
Des sous-modules sont nécessaires lorsque vous souhaitez partager le référentiel avec d'autres personnes qui le cloneront, etc. ailleurs aussi, vous n'avez pas vraiment besoin de sous-modules.
Sous-arbres Git
Git sous-modules est un moyen courant, gagnant beaucoup de terrain depuis son introduction, afin de faire face à la situation où l'on peut vouloir ajouter un projet (repo) dans un autre projet (repo), comme les autres réponses l'ont correctement décrit.
Néanmoins, on pourrait faire valoir que la voie des sous-modules n'est pas la seule voie et parfois pas la bonne voie à suivre, en fonction des flux de travail établis, pour plusieurs raisons que je ne vais pas analyser et qui sont brièvement mentionnées dans plusieurs pages telles que - ce et ce . Le plus important est sans doute ceci:
Lorsque Git passe en mode de résolution des conflits, il ne met toujours pas à jour les pointeurs de sous-module - ce qui signifie que lorsque vous validez la fusion après la résolution des conflits, vous rencontrez le même problème ...: si vous avez oublié d'exécuter la mise à jour de sous-module git, vous 'ai juste annulé tout sous-module qui commet la branche dans laquelle vous avez fusionné.
Bien sûr, dans un flux de travail parfait, cela n'arriverait jamais.
Une autre raison importante est que le populaire PyCharm IDE (quand cela est écrit; il y a un très ancien problème pour cela) et peut-être que d'autres n'implémentent pas complètement git les sous-modules et le codeur perdront entre autres la fonctionnalité astucieuse du IDE affichant toutes les lignes modifiées dans le sous-module.
Par conséquent, une autre façon de résoudre ce problème consiste à utiliser les sous-arbres . Notez que les sous-arbres et fusion des sous-arbres n'est pas exactement la même chose, mais c'est encore une autre affaire. L'excellent Progit book dans sa 2ème édition couvre brièvement ce dernier, mais pas une seule référence pour le premier.
Donc, dans un exemple pratique, pour faire face à la situation en question, supposons qu'un subproject soit consommé dans un project:
$ git remote add subproject_remote (url)
# subproject_remote is the new branch name and (url) where to get it from, it could be a path to a local git repo
$ git subtree add —-prefix=subproject/ subproject_remote master
# the prefix is the name of the directory to place the subproject
$ git commit -am "Added subproject"
# possibly commit this along with any changes
Si le sous-projet change, pour les tirer dans project:
git subtree pull —prefix=subproject subproject_remote master
... ou l'inverse (si des modifications sont apportées dans le subproject à l'intérieur du project):
git subtree Push —prefix=subproject subproject_remote new_branch
Un tutoriel analytique mais plutôt claquant dans ce lien .
Cette fonctionnalité présente également certains inconvénients, par exemple, beaucoup de gens trouvent le flux de travail lourd et plus compliqué, mais là encore, cela dépend des flux de travail établis.
L'ajout d'un dossier contenant un projet git dans un autre projet git fonctionne comme vous pouvez vous y attendre: il n'y a pas d'interaction directe entre eux et vous pouvez valider les modifications indépendamment en travaillant dans un répertoire ou dans l'autre. Vous pouvez soit demander au projet "parent" d'ignorer complètement le dossier interne, soit valider les fichiers sélectionnés du dossier enfant comme s'ils faisaient partie du projet parent.
Si vous faites ce dernier, lorsque vous modifiez un fichier, il sera considéré comme modifié par les deux projets git et vous pouvez gérer ces modifications indépendamment (valider les modifications) en travaillant simplement dans un répertoire ou dans l'autre.
Je suppose que vous utilisez les outils de ligne de commande ici, bien que je pense que XCode 7 peut comprendre la situation et afficher des annotations de changement sur les fichiers tant que les fichiers sont considérés comme modifiés par l'un ou les deux référentiels git.
Je trouve que la procédure ci-dessus est plus simple que de traiter des sous-modules, mais d'autres ont commenté comment les utiliser afin que vous puissiez comparer.