Preguntas sobre el flujo de trabajo para un equipo usando un git-svn repo

Question

He estado leyendo en git y git-svn. Soy bastante nuevo en git, pero he podido crear repositorios básicos. Sin embargo, estoy un poco confundido sobre cómo sería el flujo de trabajo para git-svn utilizado por un equipo. El objetivo es convertir svn a git para fines de bifurcación y uso compartido, luego volver a comprometerse con el repo de svn principal cuando esté listo para pasar a la producción. Aquí están mis preguntas:

¿Debería cada miembro del equipo crear un repositorio git del repositorio svn? ¿Funcionaría este enfoque al fusionarse de nuevo a svn/pulling el uno del otro?

-o-

En caso de repo a un git ser creados desde SVN, entonces eso es empujado repo 'públicamente' para los miembros del equipo para clonar? Entonces, ¿los cambios serían devueltos al repositorio original de git para volver a basar y presionar a svn?

-o-

podemos hacer lo mismo que el anterior, excepto simplemente extraer los cambios de uno al otro repo copia de trabajo?

-o-

Am I añadir demasiada complejidad al flujo de trabajo y sólo debe seguir usando SVN, ya que no es una opción de convertir sólo en su totalidad a git?

Answer 1

Hago algo en esta línea todo el tiempo.Aquí, tenemos un repositorio svn, pero varias personas prefieren usar git. Acabamos de hacer que una persona creara el repositorio de git, y luego todos lo compartimos entre nosotros (en lugar de que todos creen su propia copia de git-svn, la importación original tomó más de 30 horas). Ahora cualquiera que quiera puede simplemente trabajar en git y git svn dcommit para llevar sus cambios al repositorio svn "real".

Answer 2

Git-svn soporta fácilmente lo que quiere hacer. Recomendaría que cada desarrollador cree su propio repositorio de Git desde el repositorio de Subversion (git svn clone). Los desarrolladores pueden extraerse entre ellos si así lo desean, incluidos tanto los commits que ya se han enviado a Subversion como los que no.

El equivalente de git-svn de svn update es git svn rebase, que efectivamente hace una operación git rebase contra el repositorio de Subversion. Cualquier commmits que pueda estar listo para comprometer, que ya haya sido cometido por otra persona, se omite automáticamente.

Answer 3

¿Alguna vez los desarrolladores han tenido la necesidad de un repositorio local sin poder conectarse al repositorio principal? (es decir: Codificación en un avión en una computadora portátil)

Si no, entonces evitaría este dolor de cabeza por completo y solo usaría SVN con ramas específicas del desarrollador.

Si, no obstante, que le gusta mucho el enfoque distribuido de git, me gustaría ir con su tercera opción:

Si uno repositorio git ser creados a partir SVN, entonces ese repo es empujado 'públicamente 'para que los miembros del equipo clonen? ¿Entonces los cambios serían devueltos a el repositorio original de git para volver a basar y presionando para svn?

Con:

podemos hacer lo mismo que el anterior, excepto acaba de extraer los cambios de copia de trabajo de recompra de cada uno?

Eso debería funcionar bien.

Answer 4

Piense en el repositorio git de cada usuario como un cliente de Subversion elegante, particularmente como uno con el que es fácil compartir revisiones sin involucrar al repositorio central. Entonces, todos deberían hacer lo que les parezca mejor y correcto.

También podría pensar en el repositorio de Subversion como un repositorio de fantasía git.

En caso de que se cree un repositorio de git desde svn, ¿ese repositorio se publica 'públicamente' para que los miembros del equipo lo clonen? Entonces, ¿los cambios serían devueltos al repositorio original de git para volver a basar y presionar a svn?

No creo que eso sea necesario, porque git svn clone obras en su mayoría los mismos que git clone para empezar.

Lo más importante que hacer es siempre do git svn rebase antes de hacer git svn dcommit. Si está compartiendo muchas revisiones entre los repositorios de git, probablemente sea una buena idea examinar los cambios que va a enviar a Subversion antes de hacerlo git svn dcommit.