Git piste externe/publique/branche à distance lors de la fusion dans le serveur local

Question

J'ai une équipe avec plusieurs membres, et notre travail est basé sur un autre repo GIT, que nous ne sommes pas autorisés à pousser. Appelons cela repoA.

Nous avons créé notre propre serveur GIT et le repo a été initialement cloné à partir de repoA. Appelons le repoB repoB cloné.

Notre équipe travaille sur repoB mais repoA continue d'évoluer. L'équipe qui maintient le repo ne se soucie pas de notre travail et ne veut pas que notre code «pollue» le leur, mais nous voulons obtenir leurs changements et les fusionner dans notre repoB. La "fusion" peut être un peu étrange: nous fusionnons la plupart des changements de repoA dans notre repoB, mais gardons le code inchangé, comme les méthodes que nous avons modifiées pour notre propre exigence. Je souhaite également que la fusion soit visible dans l''arbre d'historique', comme le [Repository] -> [Visualize All Branch History] de Git GUI, ou le [Show Log] de Tortoise Git, afin que je puisse clairement quel jour, à partir de quel engagement, j'ai fait une «synchronisation» de repoA dans mon repoB. Il serait préférable que je puisse avoir une «ligne de fusion» dans Git GUI et dans la carte historique de TortoiseGit.

Je sais une approche « laid » de le faire, par exemple:

• maître de Pull REPOA comme mon propre maître, mais tous commettras mon équipe et pousser à une branche appelée « local_main ». Toujours taper le maître de repoA sur mon maître local puis créer une branche temporaire 'pick_change', puis passer à 'local_main' et fusionner 'pick_change', puis supprimer la branche 'pick_change' localement, et pousser 'local_main' sur mon serveur GIT .

Avec cette façon, je peux:

• Pick-code utile à ma branche.
• Gardez le code que je ne veux pas, sans changement d'origine/maître
• voir clairement une ligne courbe « fusion de la branche » de branche maître à mon « local_main » branche dans le GUI Git ou de commettre le graphique de l'histoire de TortoiseGit, location Je sais qu'il y avait une fusion de cette validation de origine/maître à cette validation de mon 'local_main'.

Mais est-ce que c'est une manière «élégante» de le faire?

je pense que ce devrait être une exigence très commune, comme la création d'un noyau Linux privé basé sur le projet Linux publics, changer un peu de code, mais veulent toujours garder une autre partie mise à jour avec le projet Linux public et montrer clairement l'histoire que, à ce jour, notre projet a aligné avec cela, cela, que les versions de base de Linux.

Le livre 'ProGit' fournit juste un peu de concept mais ne semble pas être une solution détaillée. Ou quelqu'un peut-il me dire à quel chapitre de section dois-je me référer?

Answer 1

Branches:

1. master de REPOA,
2. pick_change de RepoB,
3. local_main de RepoB,
4. branches de sujet de RepoB.

Rôles:

1. propriétaire de RepoB,
2. propriétaire pick_change,
3. propriétaire local_main,
4. travailleurs de RepoB.

master de RepoA va comme A-B-C-D-E-F. Supposons que votre projet commence à C, de sorte que le propriétaire de RepoB crée local_main et pick_change à partir de C.

Comme master continue comme C-D-E-F-G-H, votre équipe a besoin E et G, de sorte que les cerises choix E propriétaire pick_change et G-pick_change et poussez-le à votre repo central. pick_change est maintenant comme C-E'-G'.

Le propriétaire local_main crée une branche de sujet si nécessaire, par exemple dev_20171016, d'une certaine COMMIT local_main. Ensuite, les travailleurs télécharger dev_20171016 et de travailler dessus. Ils téléchargent leurs validations au dev_20171016. Ils ne sont pas autorisés à apporter des modifications directement à local_main ou pick_change et ils n'ont pas besoin de se préoccuper de master de RepoA. Ils peuvent aller chercher local_main et pick_change et les fusionner dans leurs branches locales à des fins de test. Il n'est pas permis de pousser une branche locale qui a été fusionnée avec local_main ou pick_change.

Quand il est prêt, le propriétaire local_main se confond pick_change et dev_20171016 à local_main avec --no-ff et pousser local_main à votre repo central.

Étant donné que RepoA n'applique pas vos validations ou vos modifications, il est fort probable que des conflits surviennent lorsque vous sélectionnez leurs validations dans pick_change. Ça pourrait être agaçant. Le propriétaire pick_change et le propriétaire local_main avaient mieux activer git rerere