stratégie de gestion Git submodule

Question

Nous utilisons GIT pour gérer notre projet.

Chaque projet a un « noyau » (comme un cadre de qui nous construit le projet) Ainsi, chaque projet a au moins 2 branches Remotes:

• 1 référentiel pour ce cadre de base.
• 1 dépôt par projet client.

Nous avons aussi des modules. Chaque module possède un noyau qui contient la fonctionnalité de base et nous personnaliser chaque module à partir de cette base pour chaque client.

• Nous avons donc inclus sous-modules dans chaque projet client
• Mais je ne peux pas comprendre comment gérer la partie des sous-modules personnalisation.

Comment peut-il aider GIT-moi si je veux ajouter quelques nouveaux fichiers dans un sous-module qui doit être utilisé que dans 1 projet client particulier?

Comme les fichiers thoses sont Personnalisés pour le projet principal, le meilleur des cas serait de commettre des fichiers contenus dans le sous-module dans la branche de projet client, mais il semble que je ne peux que chaque sous-module sont indépendants.

Ps .: Nous utilisons SmartGit.

Answer 1

Ceci est un scénario dans lequel vous pouvez utiliser git-sous-arbre (fusion)

Si vous avez modifié l'autre projet dans votre dépôt, ils peuvent veulent fusionner de votre projet. Ce est possible en utilisant subtree - il peut déplacer les chemins dans votre arbre et alors ils peuvent fusionner seulement pertinentes parties de votre arbre.

http: // www. kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

L'idée de la fusion subtree que vous avez deux projets, et l'un des projets cartes à un sous-répertoire du une autre et vice versa. Lorsque vous spécifiez une fusion de sous-arbre, Git est intelligent assez pour comprendre que l'on est sous-arbre de l'autre et de fusion de façon appropriée -. il est assez étonnant

http://progit.org/book/ch6-7.html

Mais je suppose que vous voulez utiliser et ne se déplace pas sous-modules loin de.

Answer 2

Je ne peux que chaque sous-module sont indépendants.

Il est vrai un sous-module est « indépendant », car il a son propre ensemble de commits et des branches comme un dépôt individuel, vous pouvez toujours définir une branche client-projet sur ledit sous-module.

Cette branche serait définie dans votre repo principal projet client, ainsi que dans le sous-module de base, afin d'isoler des changements spécifiques à un projet client fait dans les deux prises en pension.
Lorsque vous repoussez les modifications effectuées dans les sous-modules de base, vous les poussez dans une branche client-projet dont le nom correspond au nom de la branche de client utilisé dans votre repo parent client.

Donc en bref, une convention de nommage peut vous aider à isoler petits changements précis fait dans un sous-module de base utilisé et partagé par de nombreux clients repo-projet.