Ce workflow git-svn fonctionnera-t-il?

Question

J'expérimente avec git-svn, et j'essaye de proposer un flux de travail relativement non sujet aux erreurs. Je pense que ce qui suit devrait fonctionner, et est assez simple, mais j'ai vu people using far more complicated workflows, donc je veux voir pourquoi.

1. (master) $ git svn init <path>
2. (master) $ git svn fetch
3. (master) $ git svn rebase
4. (master) $ git checkout -b topic-branch
5. (topic-branch) $ # HACK HACK COMMIT HACK HACK HACK COMMIT HACK COMMIT
6. (topic-branch) $ git checkout master
7. (master) $ git merge topic-branch - ceci est une fusion avance rapide, donc pas commit de fusion
8. (master) $ git svn rebase
9. (master) $ # fix conflicts
10. (master) $ git svn dcommit
11. GOTO 4

Answer 1

Oui, c'est essentiellement ce que je fais lorsque vous travaillez avec des dépôts Subversion. La clé de la simplicité de ceci est de garder les branches Git locales et ne pas essayer de les mapper aux branches Subversion du tout.

Je viens de remarquer que vous avez directement lié à ma réponse dans cette autre question. Alors peut-être que je devrais expliquer plus. :)

Je fais parfois la résolution de conflit dans la branche de sujet si je m'attends à un conflit. Sinon, si je ne m'attends pas à beaucoup de conflits, je pourrais fusionner pour maîtriser avant de faire le git svn rebase. Cela n'a pas beaucoup d'importance.

Le point clé est que Git est si flexible que le workflow minimum est très simple. Vous avez ajouté une branche de sujet à cela; J'ai ajouté le rebasing sur la branche de sujet.

Answer 2

Il est sécuritaire de ne pas passer en mode maître et de faire "git svn rebase" en faisant les étapes 5. Sinon, je recommande de faire un "git rebase master" entre les étapes 5 et 6.

Answer 3

De ma courte expérience, je l'ai fait des ajustements mineurs à votre flux de travail et les commentaires ajoutés:

1. (master) $ git svn init <path> (ou (master) git svn clone <url>)
2. (master) $ git svn fetch
3. (master) $ git svn rebase (boucle commencer, résoudre les conflits)
4. (master) $ git checkout -B topic-branch (prudent avant de faire cela)
5. (topic-branch) ## HACK HACK COMMIT HACK COMMIT (utilisation 3ème partie)
6. (topic-branch) $ git checkout master
7. (master) $ git rebase topic-branch (résoudre les conflits)
8. (master) $ git svn rebase (résoudre les conflits, le cas échéant)
9. (master) $ git svn dcommit (attention lecture ici)
10. GOTO 3 (ou 4 si pas besoin de rebaser à nouveau)

J'utilise master branche juste pour l'intégration avec SVN et faire tout le travail sur topic-branche, tout comme je crois que vous étiez. J'espère que cela a plus de sens, puisque je ne pouvais pas utiliser votre flux de travail de la même façon que si c'était essentiellement ce que je voulais - évidemment! :-)

Plus de détails sur les ajustements qui ont été faites:

• Attention au capital -B à l'étape 4, il sera réinitialiser le sujet branche il est donc toujours nouvelle de SVN actuelle. sans cela, la boucle casserait en donnant une erreur "la branche existe déjà". Etape 7 en utilisant rebase au lieu de merge. oui, ce sera probablement une fusion rapide, mais il vaut mieux prévenir que guérir. image si quelque chose est fait entre les étapes 6 et 7.
• Boucle à 3 au lieu de 4. Aussi, juste pour jouer du bon côté. On dirait que l'utilisation de svn rebase n'est jamais un abus et comme c'est toujours fait sur le master, il y a toujours des branches comme sauvegarde.