¿Cómo usar git-svn como herramienta de revisión intermedia para un repository SVN?

En la empresa para la que trabajo, tenemos la política de revisar todo el código antes de que se ingrese en el repository SVN. Normalmente, antes de comprometerme, solo le pido a un colega que lo revise, pero en este momento no hay nadie alnetworkingedor por un par de días, y tengo varias tareas que hacer con la misma class.

Instalé git y usé git-svn para hacer un repository local. git-svn dcommit todos los cambios que voy a proponer después de un time, y con git-svn dcommit , puedo sincronizar mis cosas dentro del repository principal.

La pregunta ahora es: ¿qué sucede si mi compañero de trabajo que revisará mis cosas en unos pocos días no está de acuerdo con una confirmación, o quiere que haga algunos cambios adicionales (por ejemplo, comentarios del código)? ¿Cómo hago eso sin tener que hacer una confirmación extra, que eventualmente aparecerá en mi repository principal SVN?

Ejemplo, digamos, en aras de la comprensión, que estoy trabajando en un file.

  • SVN obtuvo rev 1000
  • Se agregó el cambio de código A, git commit.
  • Se agregó el cambio de código B, git commit.
  • Se agregó el cambio de código C, git commit.

Ahora, mi compañero de trabajo acepta los cambios A y C, pero no está de acuerdo con el cambio B, y quiere que entren más comentarios junto con el cambio B. El resultado con el que quiero terminar es:

  • SVN rev 1001 – Cambio de código A
  • SVN rev 1002 – Cambio de código modificado B + comentarios adicionales
  • SVN rev 1003 – Cambio de código C.

No estoy muy familiarizado con git , y estoy bastante familiarizado con SVN. ¿Cómo cambio las contribuciones que cometí en el cambio de código B sin hacer un cuarto compromiso?

En primer lugar, no debería necesitar un VCS adicional para realizar revisiones de código en su empresa antes de comprometerse con el enlace trunk . La respuesta de khmarbaise es la correcta. La forma correcta (y sensata) de hacerlo es crear una sucursal , realizar los cambios en la sucursal , pedir a su colega que revise esa sucursal cuando haya terminado, revisar el código, realizar cambios correctivos en su sucursal y, luego, quienquiera que haya La autoridad fusionará su twig en el trunk . Este es el protocolo VCS básico. Si esta no es la forma en que su empresa lo hace, es una señal segura de que su empresa lo está haciendo mal cuando se trata de VCS.

Si absolutamente debe usar una herramienta externa porque la política de su compañía es inane, entonces para abordar la siguiente parte de su pregunta

Ejemplo, digamos, en aras de la comprensión, que estoy trabajando en un file.

  • SVN obtuvo rev 1000
  • Se agregó el cambio de código A, git commit.
  • Se agregó el cambio de código B, git commit.
  • Se agregó el cambio de código C, git commit.

Ahora, mi compañero de trabajo acepta los cambios A y C, pero no está de acuerdo con el cambio B, y quiere que entren más comentarios junto con el cambio B. El resultado con el que quiero terminar es:

  • SVN rev 1001 – Cambio de código A
  • SVN rev 1002 – Cambio de código modificado B + comentarios adicionales
  • SVN rev 1003 – Cambio de código C.

No estoy muy familiarizado con git, y estoy bastante familiarizado con SVN. ¿Cómo cambio las contribuciones que cometí en el cambio de código B sin hacer un cuarto compromiso?

Ni siquiera entiendo por qué querrías evitar un cuarto commit en primer lugar, si puedes hacer tres commits que afecten una característica.

Si de verdad quieres realmente seguir con esta idea, entonces sí, puedes hacerlo, y para hacerlo, necesitarías usar cuidadosamente git rebase --interactive . Este poderoso command puede permitirle regresar a sus compromisos y alterar por completo los cambios realizados en cada uno. Debo enfatizar que esto tiene un alto potencial de pérdida de trabajo (o al less le puede costar un time significativo en la recuperación), y solo debe hacerse si usted tiene un conocimiento muy firme de la git.

Pero realmente, realmente deberías estar usando la ramificación SVN y la fusión para hacer todo esto.

Simplemente crea una twig y realiza commits en esa twig. Deje que su compañero de trabajo tarde revise el código y luego fusione el código de nuevo a la línea externa (por ejemplo) o a otra twig.

La key no es impulsar los cambios en svn hasta que se aprueben. Una vez que hayas ejecutado git svn dcommit , perderás el poder del git para editar y reorderar tus commits. dcommit hace públicos sus cambios, y la historia de svn es (en su mayor parte) inmutable.

Por lo general, realizo mis cambios en una sucursal y los llevo a un repository git público cuya location doy a mis revisores de código. Entonces puedo seguir trabajando en otro proyecto en una twig separada. Con base en los comentarios de la revisión, puedo hacer cambios en la sucursal de mi repository en funcionamiento y volver a publicar para su revisión, y cuando todo esté listo, hago un último git svn dcommit para finalizar mis cambios en svn.