2010-04-19 4 views
1

mise en page du projet:répertoire commun de référence git/repo

/project_a 
    /shared 
/project_b 
    /shared 
/shared 

project_a et les deux project_b doivent contenir le dossier partagé. Avec svn, nous avons utilisé svn: externes et cela a bien fonctionné, puisque svn peut référencer des sous-répertoires (avec des chemins relatifs aussi). Cependant, nous avons déménagé à git et il semble ne pas prendre en charge les sous-répertoires.

Notre solution est maintenant de mettre project_a, project_b et partagé tous dans différents repos git, et d'utiliser des sous-modules git dans project_a et project_b. Cependant cela semble beaucoup plus compliqué qu'un svn repo monolithique avec svn: externals. Quelle est la bonne façon de gérer les éléments communs dans git?

EDIT: Le consensus est sous-modules sont la voie à suivre. Mais après l'avoir utilisé pendant une journée, il semble très hostile à utiliser.

Après avoir fait un changement dans un fichier partagé, je dois:

  1. les modifications au Partagés
  2. Poussez le changement de la part
  3. Ajouter le nouveau répertoire partagé dans le répertoire parent
  4. Poussez le répertoire parent

par rapport à une seule livraison en svn, cela semble plus compliqué. Et l'absence de l'une de ces étapes entraîne un énorme désordre de versioning. Est-ce que j'ai râté quelque chose?

Répondre

1

Les sous-modules sont la bonne réponse.

Le fait que vous ne conservez pas l'approche monolithique de SVN est pretty much by design with a DVCS (où vous marquez et faites référence à un référentiel comme tous). Cela vous permet de référencer une configuration exacte (voir submodules true nature), c'est-à-dire que vous vous référez toujours à une référence SHA1 précise (par opposition à svn external, où vous n'êtes pas obligé d'indiquer un numéro de révision).

+0

Merci pour la réponse détaillée VonC. Avoir à courir 4 étapes est un dealbreaker pour nous, retour à svn c'est – phillee

Questions connexes