J'ai un projet source fermé construit sur mon cadre open source. Je veux savoir comment je devrais structurer mon flux de travail. Vous trouverez ci-dessous mes meilleures suppositions en utilisant Git avec des sous-modules.
d'ici, je peux apporter des modifications à:
Comment gérer un repo contenant du code privé et du public et des sous-modules. À l'heure actuelle, il semble que je dois juste conserver deux basses codes séparées pour y parvenir.
Je cherche la meilleure réponse qui puisse aider une personne assez nouvelle à gicler sur le processus de travail sur une base de codes qui est moitié open source et moitié privée. Une bonne chose à ce sujet est que chaque dossier soit privé ou public, il n'y a donc pas de souci de dossiers privés et publics ensemble quelque part - mais certains des dossiers privés pourraient être en public!
Un autre exemple que je Cela pourrait donner serait d'utiliser Zendframework pour construire votre site d'entreprise privé tout en étant capable de tirer chaque jour (et peut-être des pousses de patch) au repo Zend. Et appelle également et pousse de votre site privé à l'intérieur du Zendframework.
Par exemple, imaginez une structure de répertoire comme celle-ci: peut-être que je demande peut-être deux beaucoup à les gérer tous dans un répertoire de repo joint. Peut-être qu'il n'y a pas de moyen facile de le faire et je devrais les séparer et faire tous les correctifs publics dans un puis tirez simplement dans mon repo privé. Bien sûr, cela signifie que si je suis en train de travailler sur un code privé - je devrai quitter ce repo et aller ouvrir le public et rendre le changement de code patché, puis revenez à la privée, fusionner , puis continuez à travailler sur le code privé.
6 Réponses :
Vous pouvez avoir une branche «publique» et «privée» dans votre référentiel local. Lorsque vous appuyez, chaque branche est poussée à un référentiel à distance séparé (recherchez la syntaxe 'Git Push'). Ensuite, vous pouvez librement fusionner de public à privé.
Je suis sûr qu'il y a une façon de fusionner des changements sélectionnés de privé au public, même si je devrais le chercher.
Avec ce flux de travail, vous ne pouvez pas avoir de répertoire de travail avec des fichiers de public et de privé. Lorsque vous avez vérifié la succursale publique, vous ne voyez que les fichiers publics; Checkout La succursale privée et vous avez uniquement les fichiers privés.
@Meeeevangasse: c'est incorrect. La succursale privée a des dossiers publics et privés. La branche publique n'a que des dossiers publics. C'est ce que "fusion" fait.
Ce n'était pas évident de l'explication!
J'espérais que les gens connaissaient déjà comment "fusion" travaille, quand je dis "fusionner de public à privé".
La question que j'ai avec cette approche est que vous devez continuellement basculer entre public et privé et fusionner tout le temps. Et comme vous vous indiquez vous-même, vous pouvez obtenir des modifications à un répertoire public dans la succursale privée à la direction publique serait non triviale.
@Medeevangasse: Je pense que vous imaginez une situation plus spécifique que celle de la question. Ceci est juste une approche, pour être sûr, et il y a des cas dans lesquels il serait gênant. Par exemple, si vous imaginez que certains répertoires sont publics ou privés, ou si vous imaginez que vous souhaitez rendre les données privées publiques. Git n'a pas vraiment de notion de "privé" ou "public" de commencer. L'alternative-à utiliser plusieurs référentiels - a ses propres inconvénients. L'utilisation de sous-modules nécessite que les données publiques soient inférieures à la racine de répertoire de données privée, par exemple.
@Medeevangasse: C'est l'une de ces questions qui n'a pas vraiment de réponse "correcte", mais collectera à la place un certain nombre d'approches différentes pour résoudre le problème, chacun pourrait être la bonne approche pour un scénario spécifique.
Approche intéressante. Comme j'ai une très petite partie du code privé et j'ai rarement changé - pourrait être une très bonne approche pour moi, fusionner facilement du public à privé.
Rendez le public à un sous-module à l'intérieur du privé. Lorsque vous poussez, rappelez-vous que vous devez les pousser les deux. N'oubliez pas non plus d'enregistrer la sous-module elle-même dans le repo privé. Il suit donc quelles révisions de la sous-module utilisées.
Vous pouvez développer les deux codes (votre et les sous-modules) dans le même repo, mais lorsque vous parlez de plusieurs annuaires privés dans votre code public, cela appelle à un Stratégie de fusion de sous-arbitre . de et pour mieux gérer la poussée et tirer de parties de votre repo global à un particulier, je recommanderais le outil de script de sous-arbre git . Sumdoues git vous permet de définir une configuration (voir Cette question ), c'est une référence à un commit d'un autre composant (dans un autre repo).
Cela vous permettra de considérer vos annuaires (les services privés et publics) comme un arbre de travail naturel.
Résumer, je recommande ce flux de travail:
J'ai utilisé des sous-modules git dans le passé. Je ne pense pas qu'ils soient un bon ajustement pour votre cas d'utilisation. Les gros avantages qui sautent sur moi sont:
Voici une sous-question que je vais admettre n'est pas une coupe si claire: "Quel flux de travail permet de rebondir plus facilement entre le cadre OSS et le projet privé?"
Il existe une certaine allure à utiliser des sous-modules et à avoir les deux projets dans un seul arbre. Cela vous accélérera peut-être dans votre édition de texte, mais vous ralencerez probablement vous ralentirez (ou causera plus d'erreurs que d'habitude) en matière de validation et de poussée.
Il y a une certaine attrait à avoir les projets séparés. Le commutateur de contexte (à partir d'une fenêtre d'éditeur de texte à un autre) peut vous aider à vous rappeler que le projet OSAN est destiné à la consommation publique. Par exemple, cela peut aider à vous discipliner de ne pas casser la compatibilité en arrière et de garder un bon changement de changelog. L'engagement et la poussée seront facilement par rapport à la variante de la sous-moodule.
Un dont vous avez décidé sur vos copies de travail, vous voudrez déterminer votre flux de travail quotidien. Cela dépendra de votre langue bien sûr. (En rubis, par exemple, vous pourriez coller votre Cadre OSS en tant que gemme, le construire, puis votre code privé en dépends.) Quoi que vous choisissiez, configurez des scripts (ou des raccourcis de l'éditeur) pour vous aider à construire vos bibliothèques. (ou des paquets) rapidement, peut-être même automatiquement lorsque des fichiers changent, de sorte que vous puissiez rebondir entre votre cadre et votre projet sans effort.
J'ai beaucoup lu dans le livre Progit.com dernièrement et je pense que vous avez raison - il serait préférable de garder tout ce qui est séparé si pour une raison simple que je pourrais enfoncer accidentellement le code privé dans le repo public. L'autre raison est que je devrai adopter cette méthode de toute façon pour des projets supplémentaires qui dépendent du cadre car je ne vais pas continuer à ajouter de plus en plus de sites à un repo combiné.
Je recommande de ne pas utiliser de sous-modules git, mais 2 référentiels différents qui ne sont pas connectés sur GitHub.
Vous pouvez construire la relation entre eux à l'aide de Symlinks sur les copies enregistrées, qui sont fondamentales et simples. Les liens symboliques doivent seulement être créés une fois par lieu (production, développement, collègues). P>
L'avantage est que personne ne doit faire l'effort supplémentaire pour apprendre et maintenir les sous-modules git. Vous éviterez le risque et la complexité. Il apporte. P>
Cela pourrait être fait en gardant une copie de travail du système d'exploitation et de la répétition de git privée quelque part sur votre machine locale: p> alors puis Vous pouvez créer créer une structure de votre répertoire dans laquelle le projet vivra réellement et travaille quelque part ailleurs sur cette machine (pas à l'intérieur du / Repos / arborescence) et créera des symberines pour les sous-répertoires que vous utilisez: P> /repos/gatekeeper/myproject-os
/repos/myproject-os
/repos/myproject-priv
Bonne idée. Je suppose que pour beaucoup de dossiers (j'ai des centaines), vous pouvez créer un script shell qui créerait tous les dossiers pour vous sur chaque machine en prenant un simple repo_path variable.
Je vais vous récompenser la générosité parce que ce que vous dites travaillerait marcher - mais je ne pense pas que je le ferai réellement. Beaucoup de difficultés d'une configuration pour plusieurs personnes dans une équipe et avec plusieurs projets comme celui-ci.
Réponse intéressante. Je suis moi-même sur Linux, mais la plupart des développeurs de ma compagnie sont sous Windows, ils n'ont donc pas le luxe de LN -S. Quelqu'un a-t-il essayé cela sous Windows?
@Meeeevangasse, sous Windows, cela ne fonctionnera pas. Aussi besoin de solution multiplate-forme: Linux, Mac, Windows.
Les liens symboliques fonctionnent également sur Mac. Windows est le seul qui est difficile et ne veut pas travailler dans la plate-forme cross. Et même là, vous avez une alternative sans papiers pour les liens symboliques. Je pense qu'ils sont appelés jonctions, pas sûrs parce que je n'utilise pas Windows. Quoi qu'il en soit, il peut être fabriqué dans une plate-forme transversale avec des efforts et une bonne volonté.
@Medeeevangasse, je pense que la prochaine réponse avec la branche "publique" et "privée" dans votre référentiel local est la meilleure option. Cet article explique les détails: 24ways.org/ 2013 / ...
Il y a deux approches ici:
Vous pouvez utiliser la branche du même repo git. Dans votre repo privé crée une succursale avec une référence à votre repo public et gérez à la fois celui-là.
Si les composants utilisant votre projet privé sont sous-projet de votre produit public, vous devez utiliser des sous-modules. La manipulation de sous-module est en une sorte de stade précoce sur GIT à la version 1.6.6, mais pourrait être utile comme votre utilisation de sous-projet.
Qu'est-ce qui me semble que vous ne pouvez pas perdre si le projet hommage à chaque projet, donc si vous avez clairement clair, alors peu importe ce que vous choisissez, ça va marcher !!!!!!.
Outre git est facile.
Vous mentionnez Zend ci-dessus. Cela signifie-t-il que votre projet est basé sur PHP? Ou est-ce juste un exemple? (Je vous demande parce que des langues différentes sont un code sur différentes manières et cela peut affecter votre flux de travail.)
Oui, c'est PHP basé - donc pas bâtiment requis.