synchronisation git de branches rebasées

Question

J'ai récemment eu un question answered sur une configuration de développement git multi-ordinateur, et la solution que j'ai trouvée a résolu ma situation avec la branche master, mais pas les branches secondaires basées sur le maître.

Voici ma configuration actuelle:

A--B--C--D master 
      \ 
      E--F--G--H BUG_37 

BUG_37 est une branche qui développe une solution à un bogue tracked en option pour une demande de fonctionnalité dans le système, et finiront par être fusionnés dans la ligne principale, mais est séparé pour le moment. Avec le dépôt dans cet état, une seule machine, j'ai fait quelques changements à la branche master:

A--B--C--D--I--J--K master 
      \ 
      E--F--G--H BUG_37 

Je Rebasé alors la branche BUG_37 sur master, pour assurer qu'il fonctionne comme une amélioration des changements les plus courants: Disons que rebase avait quelques conflits qui devaient être corrigés manuellement avant que le rebasage ne soit définitif. Si je transfère ces modifications vers un référentiel distant et que je souhaite maintenant effectuer des modifications sur un autre système de développement ayant encore l'installation d'origine, quelle est la meilleure façon de le faire? git pull --rebase se déroulera rebasage à nouveau, et je vais devoir aller manuellement à travers les conflits je suis passé par la première fois, non? Et si je fais une petite erreur en passant par les conflits à nouveau, de sorte que E1-H1 sont légèrement différentes dans ce nouveau système, je vais le dépôt encore plus désynchronisés. Comment puis-je mettre un référentiel local dans l'état d'origine et le référentiel distant dans le troisième état et que le référentiel local soit mis à jour pour correspondre exactement au référentiel distant (la fonction de vidage change EH et déplace le HEAD de BUG_37 vers le nouveau emplacement)?

Answer 1

je ne serais pas du tout rebasage sur branche qui est déjà partagée. Bien qu'il résulte de l'histoire la plus propre, il aura changé les hachages de tous les commits en BUG_37. Donc, sur les machines cibles, vous devrez supprimer complètement BUG_37 et le tirer de nouveau. C'est OK à faire une ou deux fois, mais pas génial comme un flux de travail régulier.

Il sera beaucoup plus facile de fusionner master en BUG_37; alors le commit de fusion (où vous avez fixé les conflits) peut être poussé vers d'autres machines, et les branches n'auront pas besoin d'être supprimées.

Answer 2

Supprimer la branche, puis tirer les deux branches du référentiel distant.

git branch -D BUG_37 
git pull origin master 
git pull origin BUG_37:BUG_37 

Si vous ne voulez pas supprimer votre succursale locale BUG_37 avant d'être sûr que cela fonctionne, tirez la branche à distance dans une autre branche locale:

git pull origin BUG_37:NEW_BUG_37 

Answer 3

que je suis le même flux de travail, de commutation essentiellement entre un ordinateur portable et de bureau. Je garde mon repo principal sur le bureau et l'ordinateur portable clone le repo de deskotp. Finalement, ils se désynchronisent, parce que je veux rebaser mes branches de sujet après la mise à jour master.

La réponse simple, est juste ne pas utiliser git, utilisez plutôt rsync pour garder vos prises en pension synchronisé. Si vous savez que vous êtes le seul à travailler dessus, alors cela a du sens.

Eh bien, je ne suis pas un grand fan de cette solution soit. Donc, cela pourrait être un peu "propre".Sur l'ordinateur portable, en tirant les branches recalculées de la mise en pension de bureau:

git co topic 
git fetch origin/topic 
git reset --hard origin/topic 

Ce rejettera toute engage pas sur le repo de bureau, alors assurez-vous que vous voulez vraiment faire.

En outre, vous pouvez probablement git pull branche de l'ordinateur portable master, car il devrait toujours être un fast-forward, car vous n'aurez probablement pas besoin de le rebaser. Je pense qu'il est logique de rebaser les branches de sujet, car sinon, essayer de le recomposer en maître à la toute fin est une douleur.

Answer 4

Je viens de l'expérimenter et utiliser git pull --rebase fonctionne en tirant d'une branche rebasée. Sans l'indicateur --rebase, les validations seront dupliquées, mais avec --rebase, les validations ne seront pas dupliquées.