Donc, j'utilise git et interagir avec un repo SVN.
J'ai un coffre SVN qui ressemble à ceci: p> et une branche de bug_fixes SVN Direction des branches à Engagez B ou C: P> -c-d-e-f-g-h-i
5 Réponses :
Cela me permet d'appliquer tous les engagements au coffre, mais ne me permettez pas de continuer à développer sur la branche. Malheureusement, comme SVN a une historique de révision linéaire, il semble que le plan d'action recommandé soit pour fusionner la succursale dans le coffre, puis supprimer la branche et créer l'un des mêmes noms.
Ce ne serait-il pas un bon cas pour rebaser votre substance locale (
Cela fonctionne bien dans Git, mais pas avec l'histoire de la révision linéaire de SVN. Vous pouvez donc obtenir les changements de la branche au coffre, mais le développement continu sur la succursale est apparemment futile.
OK, donc quelques approches que j'ai trouvées: ou ou et ensuite après tout cela. puis (de svn parce que git-svn ne prend pas en charge la suppression) Supprimer la branche,
et recréez-le du coffre et commencez le cycle de plus.
Comment obtenir une branche de SVN? Il est stocké là-bas .. pas dans Repo local.
Je pense que c'est juste une question de "git svn chercher" ou quelque chose. Kernel.org/pub/software/scm/git/ Docs / git-svn.html
Je pense que vous devriez vraiment faire un git svn rebase à la place. Il devrait conserver une histoire linéaire selon la documentation à git-scm.com.com / Docs / git-svn # git-svn-emrebaseem
Si vous dommageez une fusion, il l'écrase automatiquement en 1 commit. Malheureusement, il n'utilise pas à l'intérieur de l'intérieur svn: mergeinfo ou --Retintegrate tel qu'il le devrait, de sorte que vous perdez l'association avec la succursale créée via la «branche Git SVN».
Ce que vous pouvez aussi faire est Cherry-Chick em>, à condition que vous n'utilisiez pas fusion em>. Les deux déclarations doivent être effectuées sur la branche sans les modifications. . P> à condition que c soit plus âgé que moi et que vous souhaitez prendre toute la séquence. p> ou distinct commits p> git cherry-pick c d e f g h i
Donc, fondamentalement, aucune des solutions ne fait une réintégration exacte, laissant tous la branche en conflit si vous continuez à l'utiliser?
Franchement, en regardant en arrière, je ferais l'une de ces deux choses: 1. Utilisez un repo git sans SVN. 2. Utilisez un représentant central SVN et faites tout ma fusion et rebasing dans GIT, sans utiliser les branches SVN moins capables du tout. Si je devais partager des succursales, je le ferais dans un miroir Git -without - une branche principale et gardez uniquement la branche principale de SVN. Mais dans l'ensemble, je dispenserais avec SVN si possible.