cómo sincronizar repositorys git-svn

He estado usando git-svn durante las últimas tres semanas.

Actualmente mi flujo de trabajo es así.

  1. ssh en mi caja de desarrollo,
  2. crear / editar / eliminar files allí (git svn rebase, git checkout -b twig de tema)
  3. verifica si la aplicación web funciona bien.
  4. comprometerse a svn. (git rebase master, git checkout master, git merge topic branch, git svn dcommit)

Problemas

  1. este flujo de trabajo es muy fácil para ediciones rápidas en el cuadro dev (ssh). Pero a medida que la edición remota se vuelve lenta, se vuelve difícil.
  2. Nota: No puedo configurar la copy exacta de mi aplicación web en mi máquina local (ya que extrae datos de varias fonts y muchas otras configuraciones)

Lo que quiero es editar files localmente, mover los files al server, probar, confirmar.

¿Qué podría ser un buen flujo de trabajo para esto?

Mis bashs anteriores incluyen,

  1. editar files localmente, files scp, test, dcommit
  2. edite files localmente, rsync con dev box, test, dcommit
  3. edite los files localmente, git push para dev box, test, dcommit (la extracción de git desde el recuadro local al recuadro dev no es posible porque el recuadro local está detrás de un enrutador)

No he intentado el último paso, ya que el git-svn menciona que es peligroso presionar / jalar / fusionar desde otro repository de git si está usando git-svn.

¿Puede sugerir algún flujo de trabajo eficiente con commands de muestra?

Gracias

Puede que me esté perdiendo algo, pero creo que las advertencias en la documentation de git svn no se aplican al flujo de trabajo que sugiero a continuación. (Supongo que, por cierto, solo está contento con git svn dcommit de la caja dev).

  1. Clona el repository desde tu caja de desarrollo en tu máquina local. Supongamos que luego crea una nueva twig temática localmente llamada excellent . Haces algo de trabajo en esa nueva twig.

  2. Ahora desea probarlo en el cuadro dev, pero para evitar los problemas al ingresar a un repository no vacío, puede usar una técnica sugerida en las preguntas frecuentes de git, donde puede enviar directamente a una reference en refs/remotes/ . Por ejemplo, puede hacer:

     git push origin excellent:refs/remotes/from-desktop/excellent 
  3. Ahora debe iniciar session en el cuadro dev. A continuación, puede crear una nueva twig basada en la reference que acaba de publicar con git checkout -b excellent from-desktop/excellent

  4. Puedes trabajar en esta twig como lo harías en la twig de temas en tu ejemplo, y si estás contento con ella, asegúrate de hacer la misma secuencia antes de hacer un git svn dcommit , es decir, git rebase master , git checkout master , git merge excellent , git svn dcommit

No veo por qué ese flujo de trabajo crearía problemas con git svn , ya que estás teniendo cuidado de volver a establecer la base de tu trabajo y fusionarlo en master antes de hacer el git svn dcommit .

Uso un flujo de trabajo que está invertido del tuyo y funciona bien.

Por invertido, quiero decir que mi repo de git-svn está en mi casilla local, y presiono en la casilla de desarrollo.

Hay tres repositorys:

  1. El repository de git-svn en el recuadro local.
  2. Creo un repository desnudo en el cuadro de desarrollo, y luego paso del repository de git-svn a este.
  3. En el cuadro de desarrollo, clono el repository desnudo en un directory de trabajo que utilizo para probar. Después de la creación inicial del repository, saco del repository desnudo descrito en el n. ° 2 anterior.

Raramente hago ediciones en el repository de testing (n. ° 3). Si realizo una edición trivial, con frecuencia realizo manualmente la misma edición en el repository # 1 en el recuadro local. De vez en cuando, he enviado las confirmaciones del repository de testing (n. ° 3) al repo desnudo (n. ° 2), y luego las arrastré al repository git-svn (n. ° 1) del recuadro local. Más a menudo lo que sucede es que estoy buscando un error difícil de encontrar y haciendo un montón de pequeños cambios directamente en el repository de testing (n. ° 3), y cuando encuentro el error simplemente elimino todos esos cambios de debugging y arregla el error directamente en el repo de git-svn (n. ° 1), luego presiona a n. ° 2, ingresa al n. ° 3 y testing.

El flujo de trabajo es:

  1. [local] git co -b myfeature
  2. [local] hack hackear hack
  3. [local] git commit -m'did stuff '-a
  4. [local] git push devbox myfeature
  5. [dev] cd myapp; git pull; git co origin / myfeature
  6. [dev] test test test
  7. Repite 2-6
  8. [local] git co master
  9. [local] git svn rebase
  10. [local] git co myfeature
  11. [local] git rebase master
  12. [local] git co master
  13. [local] git merge –ff-only myfeature
  14. [local] git svn dcommit
  15. [local] git br -d myfeature

A veces haré una rebase interactiva antes del paso 8 para limpiar el historial.