Je dois développer deux projets Django qui partagent 90% du même code, mais ont des variations dans plusieurs applications, modèles et dans le modèle lui-même.
J'utilise GIT pour la commande source distribuée.
Mes exigences sont que:
Code commun pour les deux projets est développé à un endroit (Environnement de développement de Project1)
périodiquement, cela est fusionné dans l'environnement de développement du deuxième projet (projet2)
Les variations ne sont pas facilement encapsulées dans les applications. (par exemple, il existe des applications. tels que "profils" qui varient entre le projet1 et le projet2 mais pour lequel il existe également une évolution commune permanente)
Project1 et Project2 ont des référentiels publics, de sorte que je puisse collaborer avec d'autres
De même Project1 et Project2 devraient avoir des serveurs de développement, de démonstration, de mise en scène et de production.
Cependant, le référentiel public n'est pas sur le même serveur dans les deux cas. Donc, par exemple, lorsque je me développe dans le projet1, je veux être capable de "pousser" à mon serveur GitHub, mais je n'ai pas de choses de projet2.
Il existe des fichiers tels que local_settings.py qui sont complètement différents entre le projet1 et le projet2, mais doivent être partagés entre plusieurs développeurs de chaque projet
Alors, quelle est la meilleure façon de gérer cette situation?
Qu'est-ce qui semblerait être idéal serait quelque chose comme une "traction filtrée" où à la place de .gitignore disant "ignorer ce fichier entièrement", je peux dire "ignorer ce fichier lorsque vous tirez de ce repo" Je n'ai rien vu Tout comme ça dans la documentation, mais pourrait-il y avoir quelque chose comme ça?
5 Réponses :
Je ferais une troisième représentant où je placerais le code que les projets partagent. Ensuite, Project1 et Project2 auraient leur propre repo et ils peuvent tirer de ce "partagé" troisième repo.
Je pense que votre idée de "tirer filtré" rendra difficile la manteau.
Bonjour macarse, j'ai pensé à un repo commun, mais je ne pense pas que ce soit suffisant. (Comme dans, je devrai encore développer (correction de bugs) dans les repos de Project1 & Project2 et voudra pousser des corrections communes à la repo commune. Le problème est que je veux faire partiellement repousser, sans laisser Git en pensant que le République commune est obsolète. Ou est-ce faux?
Déplacez le code commun à sa propre bibliothèque et en faites une dépendance de ces deux projets. Ce n'est pas une question de contrôle de la version, mais une question de réutilisation de code, de conception et d'élimination duplication.
Salut Esko. Ce n'est pas vraiment une bibliothèque. C'est un site Django / Pinax. Les variantes sont nécessairement dispersées autour de plusieurs applications différentes. Il n'est pas facile d'encapsuler non plus ce qui est courant ou ce qui varie dans un seul endroit.
S'il vous plaît donner des exemples plus détaillés de quelles sont les choses qui varient. Je ne connais pas les applications Django.
Par exemple, nous pourrions avoir un utilisateur "profils"., Où le modèle de profil vit dans "/ templatefiles/profiles/profile.html". Nous devons maintenir des différences mineures entre ce dossier dans nos deux projets. Mais nous ne voulons pas ajouter de profil.html à .gitignore, car alors les changements ne seront pas partagés entre les différents développeurs travaillant dans ce projet.
Quelles différences un modèle de profil.html serait-il contenant? Quelles voies Django fournit-il pour abstraire ces différences dans un fichier différent?
Le point est que les différences de modèle peuvent dépendre du caprice de chaque projet. Aujourd'hui, les concepteurs, les clients, etc. pourraient préférer que le modèle de projet1 est divisé en trois zones à onglets, alors que le projet2 leur montre comme une seule page de défilement. Dans un mois, le projet2 pourrait avoir adopté des onglets, mais en utilisant une bibliothèque de widgets JS différente. Quelles varientes peuvent varier énormément. Ce qui est constant n'est pas ce que le modèle comprend, mais ce qui y comprend. (Et transmet des informations dans elle.)
Je voudrais essayer des sous-modules: http: //www.kernel.org/pub/software/scm/git/docs/user-manual.html#ssubmodules
Considérant qu'il s'agit d'un site Django / Pinax, avec des variantes dispersées dans plusieurs applications différentes, je ne recommanderais pas d'utiliser des sous-modules.
Les variantes doivent être gérées indépendamment dans la branche de la branche de Project1 et de Project2, en supprimant la nécessité de "filtrer" un résultat gitiignore.
Si vous identifiez des codes vraiment courants, ils peuvent se retrouver dans une troisième représentant que vous pourriez alors «sous-traiter fusionné» aux référentiels de Project1 et de Project2 (la signification de la stratégie de fusion de sous-traitance étant Illustré dans cette réponse )
Vous pouvez utiliser deux branches GIT différentes pour le développement. Lorsque vous apportez des changements dans un qui sont communs à l'autre, il vous suffit de git-cherrypick. Vous pouvez également pousser et tirer des succursales spécifiques, de sorte que personne n'a jamais besoin de savoir que vous travaillez à la fois en même temps.
Avez-vous déjà trouvé une solution pour cela? Vous cherchez à essayer de faire quelque chose de similaire moi-même?
Je cherche la même chose.