Au vu du mal qu'il est dis de merge j'ai l'impression que je fais un peu du n'importe quoi.
Tu fais aussi beaucoup de boulot supplémentaire pour rien. Tes deux branches locales git pointent sur la même branche SVN t'as donc pas besoin faire tout le cirque de merge.
# Tu pars d'un état ou master et devel sont sur le même commit
git co devel
do-patch-1
git ci -a
do-patch-2
git ci -a
# Tu vérifies tes commits
git svn dcommit
# Et maintenant tu mets à jour ton trunk
git co master ; git svn rebase
Si tu utilises git comme client SVN y'a pas vraiment de raison de se faire chier à remerger les deux branches git avant de pousser dans le SVN. Tu peux adopter un schema très simple: un master qui représente toujours le trunk sans jamais de modif et X branches locales pour chacunes des features sur lesquels tu bosses. Tu rebase/dcommit directement depuis ces branches et tu les détruits quand t'as fini la feature.
Maintenant si tu tiens vraiment à le faire. Utiliser le merge au lieu du rebase te fera de toute façon perdre la trace du merge et surtout dans le SVN tu verras un seul gros commit mergé plutôt que ta suite de patch.
Après le rebase c'est vraiment puissant quand tu commences à avoir pas mal de branches locales et que tu veux empiler tes suites de patch au cours de ton boulot et les pousser petit bout par petit bout sur les branches publiées. Par exemple tu as 20 patchs en cours sur ta branches devel, tu les cherry pick un par un sur ta branches master quand ils ont été validés et tu rebases ta branche devel pour te resynchroniser.
Et il te reste le rebase -i pour réordonner tes commits et les modifier si besoin. L'exemple le plus con c'est quand tu relis tout avec git log -p avant de pousser et tu te rends compte que y'a un truc à modifier dans un commit ou que tu veux insérer une modif avant les commits existant pour ensuite pouvoir les simplifier.
[^] # Re: rebase ou merge
Posté par ckyl . En réponse à la dépêche Mercurial 2.1 : Les phases. Évalué à 5.
Tu fais aussi beaucoup de boulot supplémentaire pour rien. Tes deux branches locales git pointent sur la même branche SVN t'as donc pas besoin faire tout le cirque de merge.
Si tu utilises git comme client SVN y'a pas vraiment de raison de se faire chier à remerger les deux branches git avant de pousser dans le SVN. Tu peux adopter un schema très simple: un master qui représente toujours le trunk sans jamais de modif et X branches locales pour chacunes des features sur lesquels tu bosses. Tu rebase/dcommit directement depuis ces branches et tu les détruits quand t'as fini la feature.
Maintenant si tu tiens vraiment à le faire. Utiliser le merge au lieu du rebase te fera de toute façon perdre la trace du merge et surtout dans le SVN tu verras un seul gros commit mergé plutôt que ta suite de patch.
Après le rebase c'est vraiment puissant quand tu commences à avoir pas mal de branches locales et que tu veux empiler tes suites de patch au cours de ton boulot et les pousser petit bout par petit bout sur les branches publiées. Par exemple tu as 20 patchs en cours sur ta branches devel, tu les cherry pick un par un sur ta branches master quand ils ont été validés et tu rebases ta branche devel pour te resynchroniser.
Et il te reste le rebase -i pour réordonner tes commits et les modifier si besoin. L'exemple le plus con c'est quand tu relis tout avec git log -p avant de pousser et tu te rends compte que y'a un truc à modifier dans un commit ou que tu veux insérer une modif avant les commits existant pour ensuite pouvoir les simplifier.