2014-09-23 4 views
0

J'ai 3 dépôts git avec une organisation similaire et quelques répertoires en double entre eux. Ce sont des sous-projets d'un grand projet.Git. Comment faire des répertoires de partage au lieu de dupliquer?

Proj1/ 
    .git/ 
    feature1_lib/ 
    feature1_app/ 
    feature1/  <- specific to Proj1 

    feature2_lib/ 
    ... 

Proj2/ 
    .git/ 
    feature1_lib/ 
    feature1_app/ 
    feature1/  <- specific to Proj2 

    feature2_lib/ 
    ... 

Proj3/ 
    .git/ 
    feature1_lib/ 
    feature1_app/ 
    feature1/  <- specific to Proj3 

    feature3_lib/ <- specific to Proj3 
    feature3_app/ <- specific to Proj3 
    feature3/  <- specific to Proj3 
    ... 

Ils ont été développés simultanément, mais ont un historique légèrement différent.

Proj1/ 
     ... 
     commit4 "Commit specific to Proj1." 
     commit5 "Add code to feature1_lib." 
     commit6 "Fix bugs in feature1_lib." 
     commit7 "Refactoring in feature1_lib." 
     ... 

Proj2/ 
     ... 
     commit6 "Import changes from Proj1." <- after commit7 in Proj1 
     commit7 "Commit specific to Proj2." 
     commit8 "Fix bugs in feature2_lib." 
     commit9 "Add code to feature2_lib." 
     ... 

et ainsi de suite.

Maintenant, je suis à la recherche d'options pour couper et pièces en double de la colle. Je pense qu'il devrait ressembler à ceci

Proj1_2_common/ 
    .git/ 
    ... 
Proj1_2_3_common/ 
    .git/ 
    ... 
Proj1/ 
    .git/ 
    ... 
Proj2/ 
    .git/ 
    ... 
Proj3/ 
    .git/ 
    ... 

Je lis à propos de sous-arbre et sous-module, mais ne comprends pas complètement. Pourquoi dois-je faire un sous-arbre si je peux juste pointer dans mes projets vers certains répertoires? Autrement dit, au lieu de faire de sous-arbre "feature1_lib/" Je peux simplement reconfig mes projets à examiner "Proj1_2_3_common/feature1_lib/".

Alors quelle est la meilleures options ici de la vôtre point de vue? Quel est le plus facile? Comment faire face à une telle histoire désordonnée d'avoir des références après le mouvement?

Répondre

2

Vous devez gérer votre application d'une autre manière:

  1. créer un référentiel pour chaque projet
Proj1/ 
    .git 
Proj2/ 
    .git 
Proj3/ 
    .git 
  1. Créer un référentiel pour tous les modules/fonctions
ProjModules/ 
    .git 
    feature1/ 
    feature2/ 
    feature3/ 
  1. Utilisez Git sous-modules pour inclure votre fonction dans vos 3 projets:
Proj1/ 
    .git 
    .gitmodules 
    vendor/ 
    ProjModules/ 
Proj2/ 
    .git 
    .gitmodules 
    vendor/ 
    ProjModules/ 
Proj3/ 
    .git 
    .gitmodules 
    vendor/ 
    ProjModules/ 

Ensuite, vous pouvez faire des changements dans Proj1/vendor/ProjModules et propager ces changements dans Proj2/ et Proj3/:

$ cd /Proj1/vendor/ProjModules/ 
$ touch newfile.txt 
$ git add --all 
$ git commit -m "New file !!" 
$ git push origin master 

$ cd ../../../Proj2/vendor/ProjModules/ 
$ git submodule foreach git pull 

$ cd ../../../Proj3/vendor/ProjModules/ 
$ git submodule foreach git pull 

une autre idée serait de créer un représentant ository par module. Cela vous permettrait d'importer uniquement celui dont vous avez besoin.

+0

'1.' je l'ai. '2.' Je dois le couper des repos originaux. '3.' Pourquoi sous-modules est une meilleure option ici? Et l'histoire? – LVitya

+0

@LVitya Avec les modifications apportées, sous-modules à '*/fournisseur/ProjModules' seront affectés à l'histoire du projet' ProjModules'. C'est le même comportement que si vous passiez à 'ProjModules' pour faire vos changements, puis revenez à' Proj * 'pour tirer ces changements. A partir de maintenant, l'historique de 'ProjModules' appartient au projet' ProjModules', et l'historique 'Proj *' appartient au projet 'Proj *'. – zessx

+0

Quelle est la différence vs subtree? Comment puis-je sauvegarder l'historique des changements dans les répertoires détachés? – LVitya

Questions connexes