¿Funcionará este flujo de trabajo git-svn?

Question

Estoy experimentando con git-svn, y estoy tratando de encontrar un flujo de trabajo relativamente no propenso a errores. Creo que lo siguiente debería funcionar, y es bastante simple, pero he visto people using far more complicated workflows, así que quiero ver por qué.

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 - esto es una fusión de avance rápido, así que no hay fusión cometer
8. (master) $ git svn rebase
9. (master) $ # fix conflicts
10. (master) $ git svn dcommit
11. GOTO 4

Answer 1

Sí, eso es básicamente lo que hago cuando se trabaja con repositorios de Subversion. La clave de la simplicidad de esto es mantener localizadas las sucursales de Git y no tratar de mapearlas en absoluto a las ramas de Subversion.

Acabo de darme cuenta de que se ha vinculado directamente a mi respuesta en esa otra pregunta. Entonces tal vez debería explicar más. :)

A veces hago la resolución de conflictos en la rama temática si espero que algún conflicto funcione. De lo contrario, si no espero muchos conflictos, podría fusionarme para dominar primero antes de hacer el git svn rebase. No importa mucho.

El punto clave es que Git es tan flexible que el flujo de trabajo mínimo es muy simple. Usted ha agregado una rama de tema a eso; He agregado el rebase en la rama de tema.

Answer 2

Es seguro si mientras realiza los pasos 5 nunca cambie a maestro y haga "git svn rebase". De lo contrario, recomendaría hacer un "maestro de git rebase" entre los pasos 5 y 6.

Answer 3

Desde mi breve experiencia que he hecho pequeños ajustes en el flujo de trabajo y los comentarios añadidos:

1. (master) $ git svn init <path> (o (master) git svn clone <url>)
2. (master) $ git svn fetch
3. (master) $ git svn rebase (comenzará bucle, resolver conflictos)
4. (master) $ git checkout -B topic-branch (cuidadoso antes de hacer esto)
5. (topic-branch) ## HACK HACK COMMIT HACK COMMIT (uso de 3 ª parte)
6. (topic-branch) $ git checkout master
7. (master) $ git rebase topic-branch (resolver conflictos)
8. (master) $ git svn rebase (resolver conflictos, si los hubiere)
9. (master) $ git svn dcommit (cuidado leer aquí)
10. GOTO 3 (o 4 si no hay necesidad de rebase de nuevo)

Estoy usando master rama solo para la integración con SVN y haciendo todo el trabajo en tema-rama, justo como creo que era. Espero que esto tenga más sentido, ya que no podría usar tu flujo de trabajo como era, incluso si fuera básicamente lo que quería, ¡evidentemente! :-)

Más detalles sobre los ajustes que se hicieron:

• Atención al capital -B en el paso 4, se restablecer el tema rama así que siempre es nueva corriente de SVN. sin él, el ciclo se rompería dando un error "la rama ya existe".
• Paso 7 usando rebase en lugar de merge. sí, probablemente sea una fusión de avance rápido, pero es mejor prevenir que lamentar. imagen si se hace algo entre los pasos 6 y 7.
• Pasa a 3 en lugar de 4. Además, solo para jugar en el lado seguro. Parece que usar svn rebase nunca es un abuso y dado que siempre se realiza en el maestro, siempre hay ramas como respaldo.