2009-06-25 5 views
2

Lors de l'utilisation de sous-modules git, quelle est la méthode préférée pour effectuer des personnalisations? Dois-je ...Sous-modules git: personnalisation

  • fork du projet et le suivi de la fourche
  • tentative de remplacer le comportement par défaut
  • faire les changements localement

Si aucune de ces sens, alors qu'est-ce ?

+0

Il serait utile si vous pouviez clarifier ce que vous entendez par "remplacer le comportement par défaut" et "faire les changements localement". Je ne suis pas tout à fait sûr de ce que vous voulez dire. –

Répondre

5

Je ne sais pas si votre question implique que tous les projets que vous souhaitez inclure sont déjà des projets git ou s'ils sont actuellement svn, mercurial, non-version contrôlée. Si c'est le dernier, il faudrait que ce soit une réponse au cas par cas. Très probablement, les projets que vous voulez inclure et personnaliser sont déjà sur, disons, github, et vous devez absolument passer en revue github et utiliser ces liens comme sous-modules. Toute personnalisation doit être archivée et transmise à github.

Il pourrait être plus difficile si les projets que vous souhaitez inclure sont ailleurs (ou sont basés sur svn, mercurial, etc.). L'one-way est de fourcher les projets localement et ensuite mettre en place cron-travaux pour pousser tous les changements entrants à github. C'est, créer des miroirs github. Pour avoir le contrôle total de la fusion et de la mise à niveau, vous devrez peut-être déboiter ces miroirs et les inclure comme sous-modules dans votre projet, en vérifiant les personnalisations locales et en les poussant vers la fourche du miroir.

La variante 3, les projets fork et les check-ins locaux seulement, pourrait être utilisée dans les situations où vous n'avez pas les options ci-dessus et ce que vous créez n'est pas vraiment destiné à être facilement distribué.

La correction de singe (alternative # 2 sur votre liste) devrait être une alternative aux situations où vous ne voulez pas qu'un projet devienne dépendant de vous en gardant un fork personnalisé à jour avec les changements en amont.

2

Je trouve que les sous-projets de forking utilisant le sous-module git sont extrêmement fatigants, c'est pourquoi j'ai écrit git subtree à la place.

L'idée de git subtree est que vous importez le contenu du sous-projet dans votre propre projet, donc vous branchez tout en même temps et faites de nouveaux commits comme bon vous semble. Ensuite, lorsque vous êtes prêt (si jamais), vous pouvez utiliser git subtree split pour extraire l'historique du sous-projet et le soumettre en amont.