client-svn.asc

Git y Subversión

Una gran parte de los proyectos de desarrollo de código abierto y un gran número de proyectos corporativos usan Subversion para administrar su código fuente. Ha existido por más de una década, y la gran parte de ese tiempo fue la elección de facto de VCS para proyectos de código abierto. También es similar en muchos aspectos a CVS, que fué el sistema mas popular de control de código del mundo antes de eso.

Una de las mejores características de Git es un puente birideccional para Subversion llamado git svn. Esta herramienta te permite usar Git como un cliente válido para un servidor de Subversion, por lo que puedes usar todas las características locales de Git y enviarlo a un servidor de Subversion como si estuvieras usando Subversion localmente. Esto significa que puedes realizar bifurcaciones y fusiones locales, usar el área de preparación, usar el rebasamiento y la selección selectiva, y demás, mientras tus colaboradores continuan trabajando en sus formas oscuras y antiguas. Es una buena forma de introducir Git en el ambiente corporativo y ayudar a tus compañeros desarrolladores a ser más eficientes mientras presionas para que se modifique la infraestructura para que sea compatible con Git por completo. El puente de subversión es la droga de entrada al mundo de DVCS.

git svn

El comando base en Git para todos los comandos de puente de Subversion es git svn. Se requieren bastantes comandos, por lo que mostraremos los más comunes mientras realizamos algunos flujos de trabajo simples.

Es importante tener en cuenta que cuando usas git svn, estás interactuando con Subversion, que es un sistema que funciona de manera muy diferente a Git. Aunque * puede * realizar bifurcaciones y fusiones locales, generalmente es mejor mantener su historial lo más lineal posible al volver a basar su trabajo y evitar hacer cosas como interactuar simultáneamente con un repositorio remoto de Git.

No reescriba su historial y trate de volver a presionar, y no presione a un repositorio paralelo de Git para colaborar con otros desarrolladores de Git al mismo tiempo. Subversion solo puede tener un único historial lineal, y confundirlo es muy fácil. Si trabajas con un equipo, y algunos utilizan SVN y otros usan Git, asegúrate de que todos estén usando el servidor SVN para colaborar, ya que hacerlo te hará la vida más sencilla.

Configurando

Para demostrar esta funcionalidad, necesitas un repositorio SVN típico al que tengas acceso de escritura. Si desea copiar estos ejemplos, tendrá que hacer una copia escribible de mi repositorio de prueba. Para hacer eso fácilmente, puedes usar una herramienta llamada svnsync que viene con Subversion.

Para seguir, primero necesitas crear un nuevo repositorio local de Subversion:

$ mkdir /tmp/test-svn
$ svnadmin create /tmp/test-svn

Luego, habilite a todos los usuarios a cambiar revprops – la manera más facil es añadir un script pre-revprop-change que siempre muestra 0:

$ cat /tmp/test-svn/hooks/pre-revprop-change
#!/bin/sh
exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-change

Ahora puede sincronizar este proyecto con su máquina local llamando a svnsync init con los repositorios

$ svnsync init file:///tmp/test-svn \
  http://progit-example.googlecode.com/svn/

Esto configura las propiedades para ejecutar la sincronización. A continuación, puede clonar el código ejecutando

$ svnsync sync file:///tmp/test-svn
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .............................[...]
Committed revision 2.
Copied properties for revision 2.
[…]

A pesar de que esta operación puede tardar solo unos minutos, si intentas copiar el repositorio original a otro repositorio remoto en vez de uno local, el proceso tardará cerca de una hora, aunque haya menos de 100 commits. Subversion tiene que clonar una revisión a la vez y luego ponerlas en otro repositorio – es ridículamente ineficiente, pero es la única forma fácil de hacerlo.

Empezando

Ahora que tienes un repositorio de Subversion al que tienes acceso para escribir, puedes ir a través de un flujo de trabajo típico. Comenzarás con el comando git svn clone, que importa un repositorio completo de Subversion en un repositorio local de Git. Recuerde que si está importando desde un repositorio de Subversion alojado real, debe reemplazar el file: /// tmp / test-svn aquí con la URL de su repositorio de Subversion:

$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
Initialized empty Git repository in /private/tmp/progit/test-svn/.git/
r1 = dcbfb5891860124cc2e8cc616cded42624897125 (refs/remotes/origin/trunk)
    A	m4/acx_pthread.m4
    A	m4/stl_hash.m4
    A	java/src/test/java/com/google/protobuf/UnknownFieldSetTest.java
    A	java/src/test/java/com/google/protobuf/WireFormatTest.java
…
r75 = 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae (refs/remotes/origin/trunk)
Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/my-calc-branch, 75
Found branch parent: (refs/remotes/origin/my-calc-branch) 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae
Following parent with do_switch
Successfully followed parent
r76 = 0fb585761df569eaecd8146c71e58d70147460a2 (refs/remotes/origin/my-calc-branch)
Checked out HEAD:
  file:///tmp/test-svn/trunk r75

Esto ejecuta el equivalente de dos comandos - git svn init seguido de` git svn fetch` - en la URL que proporcione. Esto puede tomar un rato. El proyecto de prueba solo tiene alrededor de 75 confirmaciones y la base de código no es tan grande, pero Git tiene que verificar cada versión, una a la vez, y enviarla por separado. Para un proyecto con cientos o miles de confirmaciones, esto puede demorar literalmente horas o incluso días.

La parte -T trunk -b branches -t tags le dice a Git que este repositorio de Subversion sigue las convenciones básicas de bifurcación y etiquetado. Si nombra el tronco, las ramas o las etiquetas de manera diferente, puede cambiar estas opciones. Debido a que esto es tan común, puede reemplazar esta parte completa con -s, lo que significa diseño estándar e implica todas esas opciones. El siguiente comando es equivalente:

$ git svn clone file:///tmp/test-svn -s

En este punto, debe tener un repositorio de Git válido que haya importado sus ramas y etiquetas:

$ git branch -a
* master
  remotes/origin/my-calc-branch
  remotes/origin/tags/2.0.2
  remotes/origin/tags/release-2.0.1
  remotes/origin/tags/release-2.0.2
  remotes/origin/tags/release-2.0.2rc1
  remotes/origin/trunk

Tenga en cuenta cómo esta herramienta gestiona las etiquetas de Subversion como referencias remotas. Echemos un vistazo más de cerca con el comando de plomería de Git show-ref:

$ git show-ref
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/heads/master
0fb585761df569eaecd8146c71e58d70147460a2 refs/remotes/origin/my-calc-branch
bfd2d79303166789fc73af4046651a4b35c12f0b refs/remotes/origin/tags/2.0.2
285c2b2e36e467dd4d91c8e3c0c0e1750b3fe8ca refs/remotes/origin/tags/release-2.0.1
cbda99cb45d9abcb9793db1d4f70ae562a969f1e refs/remotes/origin/tags/release-2.0.2
a9f074aa89e826d6f9d30808ce5ae3ffe711feda refs/remotes/origin/tags/release-2.0.2rc1
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/remotes/origin/trunk

Git no hace esto cuando se clona desde un servidor Git; esto es lo que parece un repositorio con etiquetas después de un nuevo clon:

$ git show-ref
c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master
32ef1d1c7cc8c603ab78416262cc421b80a8c2df refs/remotes/origin/branch-1
75f703a3580a9b81ead89fe1138e6da858c5ba18 refs/remotes/origin/branch-2
23f8588dde934e8f33c263c6d8359b2ae095f863 refs/tags/v0.1.0
7064938bd5e7ef47bfd79a685a62c1e2649e2ce7 refs/tags/v0.2.0
6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0

Git busca las etiquetas directamente en refs / tags, en lugar de tratarlas en sucursales remotas.

Comprometerse con la subversión

Ahora que tiene un repositorio en funcionamiento, puede hacer algo de trabajo en el proyecto e impulsar sus confirmaciones en sentido ascendente, utilizando Git de manera efectiva como un cliente SVN. Si edita uno de los archivos y lo confirma, tiene una confirmación que existe en Git localmente y que no existe en el servidor de Subversion:

$ git commit -am 'Adding git-svn instructions to the README'
[master 4af61fd] Adding git-svn instructions to the README
 1 file changed, 5 insertions(+)

A continuación, debe impulsar su cambio en sentido ascendente. Observe cómo esto cambia la forma en que trabaja con Subversion: puede hacer varias confirmaciones fuera de línea y luego enviarlas todas de una vez al servidor de Subversion. Para enviar a un servidor de Subversion, ejecute el comando git svn dcommit:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	README.txt
Committed r77
    M	README.txt
r77 = 95e0222ba6399739834380eb10afcd73e0670bc5 (refs/remotes/origin/trunk)
No changes between 4af61fd05045e07598c553167e0f31c84fd6ffe1 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Esto toma todas las confirmaciones que hayas realizado sobre el código del servidor de Subversion, una confirmación de Subversion para cada una, y luego reescribe tu compromiso local de Git para incluir un identificador único. Esto es importante porque significa que todas las sumas de comprobación de SHA-1 cambian. En parte por esta razón, trabajar con versiones remotas basadas en Git de sus proyectos simultáneamente con un servidor de Subversion no es una buena idea. Si mira la última confirmación, puede ver el nuevo git-svn-id que se agregó:

$ git log -1
commit 95e0222ba6399739834380eb10afcd73e0670bc5
Author: ben <ben@0b684db3-b064-4277-89d1-21af03df0a68>
Date:   Thu Jul 24 03:08:36 2014 +0000

    Adding git-svn instructions to the README

    git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68

Observe que la suma de comprobación SHA-1 que originalmente comenzó con 4af61fd cuando usted cometió ahora comienza con` 95e0222`. Si desea enviar tanto a un servidor de Git como a un servidor de Subversion, primero tiene que presionar ('commit') al servidor de Subversion, porque esa acción cambia sus datos de confirmación.

Tirando hacia nuevos cambios

Si está trabajando con otros desarrolladores, en algún momento uno de ustedes empujará, y luego el otro tratará de impulsar un cambio que entra en conflicto. Ese cambio será rechazado hasta que te combines en su trabajo. En git svn, se veeá así:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...

ERROR from SVN:
Transaction is out of date: File '/trunk/README.txt' is out of date
W: d5837c4b461b7c0e018b49d12398769d2bfc240a and refs/remotes/origin/trunk differ, using rebase:
:100644 100644 f414c433af0fd6734428cf9d2a9fd8ba00ada145 c80b6127dd04f5fcda218730ddf3a2da4eb39138 M	README.txt
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.

Para resolver esta situación, puede ejecutar git svn rebase, que elimina cualquier cambio en el servidor que aún no tenga y rebases cualquier trabajo que tenga encima de lo que hay en el servidor:

$ git svn rebase
Committing to file:///tmp/test-svn/trunk ...

ERROR from SVN:
Transaction is out of date: File '/trunk/README.txt' is out of date
W: eaa029d99f87c5c822c5c29039d19111ff32ef46 and refs/remotes/origin/trunk differ, using rebase:
:100644 100644 65536c6e30d263495c17d781962cfff12422693a b34372b25ccf4945fe5658fa381b075045e7702a M	README.txt
First, rewinding head to replay your work on top of it...
Applying: update foo
Using index info to reconstruct a base tree...
M	README.txt
Falling back to patching base and 3-way merge...
Auto-merging README.txt
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.

Ahora, todo su trabajo está encima de lo que hay en el servidor de Subversion, por lo que puede aplicar dcommit con éxito:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	README.txt
Committed r85
    M	README.txt
r85 = 9c29704cc0bbbed7bd58160cfb66cb9191835cd8 (refs/remotes/origin/trunk)
No changes between 5762f56732a958d6cfda681b661d2a239cc53ef5 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Tenga en cuenta que, a diferencia de Git, que requiere fusionar el trabajo original que todavía no tiene localmente antes de poder enviarlo, git svn hace que lo haga solo si los cambios entran en conflicto (muy parecido a cómo funciona Subversion). Si alguien más presiona un cambio en un archivo y luego presiona un cambio en otro archivo, su dcommit funcionará bien:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	configure.ac
Committed r87
    M	autogen.sh
r86 = d8450bab8a77228a644b7dc0e95977ffc61adff7 (refs/remotes/origin/trunk)
    M	configure.ac
r87 = f3653ea40cb4e26b6281cec102e35dcba1fe17c4 (refs/remotes/origin/trunk)
W: a0253d06732169107aa020390d9fefd2b1d92806 and refs/remotes/origin/trunk differ, using rebase:
:100755 100755 efa5a59965fbbb5b2b0a12890f1b351bb5493c18 e757b59a9439312d80d5d43bb65d4a7d0389ed6d M	autogen.sh
First, rewinding head to replay your work on top of it...

Es importante recordar esto, porque el resultado es un estado del proyecto que no existía en ninguna de sus computadoras cuando aplicó Si los cambios son incompatibles pero no conflictivos, es posible que tenga problemas que son difíciles de diagnosticar. Esto es diferente a usar un servidor Git: en Git, puedes probar completamente el estado en tu sistema cliente antes de publicarlo, mientras que en SVN, nunca puedes estar seguro de que los estados inmediatamente antes de la confirmación y después de la confirmación sean idénticos.

También debe ejecutar este comando para obtener cambios del servidor de Subversion, incluso si no está listo para confirmar. Puede ejecutar git svn fetch para obtener los nuevos datos, pero` git svn rebase` hace la búsqueda y luego actualiza sus confirmaciones locales.

$ git svn rebase
    M	autogen.sh
r88 = c9c5f83c64bd755368784b444bc7a0216cc1e17b (refs/remotes/origin/trunk)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/trunk.

Ejecutar git svn rebase de vez en cuando se asegura de que su código esté siempre actualizado. Debe asegurarse de que su directorio de trabajo esté limpio cuando lo ejecute. Si tiene cambios locales, debe esconder su trabajo o confirmarlo temporalmente antes de ejecutar git svn rebase; de lo contrario, el comando se detendrá si ve que la rebase dará como resultado un conflicto de fusión.

Problemas de Git Branching

Cuando te sientas cómodo con un flujo de trabajo de Git, probablemente crearás ramas temáticas, trabajarás en ellas y luego las fusionarás. Si está presionando un servidor de Subversion a través de git svn, es posible que desee volver a establecer su trabajo en una sola rama cada vez en lugar de fusionar ramas. La razón para preferir el rebasamiento es que Subversion tiene un historial lineal y no trata con fusiones como Git, por lo que git svn sigue al primer padre cuando convierte las instantáneas en confirmaciones de Subversion.

Supongamos que su historial se parece a lo siguiente: creó una rama experiment, hizo dos confirmaciones y luego las fusionó de nuevo en master. Cuando dcommit, ve resultados como este:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	CHANGES.txt
Committed r89
    M	CHANGES.txt
r89 = 89d492c884ea7c834353563d5d913c6adf933981 (refs/remotes/origin/trunk)
    M	COPYING.txt
    M	INSTALL.txt
Committed r90
    M	INSTALL.txt
    M	COPYING.txt
r90 = cb522197870e61467473391799148f6721bcf9a0 (refs/remotes/origin/trunk)
No changes between 71af502c214ba13123992338569f4669877f55fd and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Ejecutar dcommit en una rama con historial combinado funciona bien, excepto que cuando miras el historial de tu proyecto Git, no ha reescrito ninguno de los commits que hiciste en la rama` experimento`; en cambio, todos esos cambios aparecen en el Versión SVN de la confirmación de fusión única.

Cuando alguien más clona ese trabajo, todo lo que ven es la combinación de fusión con todo el trabajo aplastado en ella, como si ejecutaras git merge --squash; no ven los datos de confirmación sobre su procedencia o cuándo se cometieron.

Ramificación en Subversion

La ramificación en Subversion no es lo mismo que la bifurcación en Git; si puedes evitar usarlo mucho, probablemente sea lo mejor. Sin embargo, puede crear y comprometerse con ramas en Subversion usando git svn.

Creando una nueva rama de SVN

Para crear una nueva rama en Subversion, ejecuta git svn branch [branchname]:

$ git svn branch opera
Copying file:///tmp/test-svn/trunk at r90 to file:///tmp/test-svn/branches/opera...
Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/opera, 90
Found branch parent: (refs/remotes/origin/opera) cb522197870e61467473391799148f6721bcf9a0
Following parent with do_switch
Successfully followed parent
r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera)

Esto hace el equivalente del comando svn copy trunk branches / opera en Subversion y opera en el servidor de Subversion. Es importante tener en cuenta que no te echa un vistazo en esa rama; si confirma en este punto, esa confirmación irá a trunk en el servidor, no en opera.

Cambio de ramas activas

Git averigua a qué rama se dirigen tus dcommits buscando la punta de cualquiera de tus ramas de Subversion en tu historial: debes tener solo una, y debería ser la última con un git-svn-id en tu rama actual del historial historia.

Si desea trabajar en más de una sucursal al mismo tiempo, puede configurar las sucursales locales para compromentar a las sucursales de Subversion específicas, comenzándolas en la confirmación de Subversion importada para esa sucursal. Si desea que una rama `opera ' pueda trabajar por separado, puede ejecutar

$ git branch opera remotes/origin/opera

Ahora, si desea fusionar su rama 'opera' en trunk (su rama` master`), puede hacerlo con un git merge normal. Pero debe proporcionar un mensaje de compromiso descriptivo (mediante -m), o la combinación dirá` `Merge branch opera '' en lugar de algo útil.

Recuerda que aunque estás usando git merge para hacer esta operación la fusión probablemente sea mucho más fácil de lo que sería en Subversion (porque Git detectará automáticamente la base de confirmación apropiada para ti), esto no es una situación de confirmación normal de git merge Tienes que volver a enviar estos datos a un servidor de Subversion que no puede manejar una confirmación que rastrea más de un padre; por lo tanto, después de subirlo, se verá como una única confirmación que aplastó todo el trabajo de otra rama en una sola confirmación. Después de fusionar una rama con otra, no puede volver atrás fácilmente y continuar trabajando en esa rama, como lo hace normalmente en Git. El comando dcommit que ejecuta borra cualquier información que indique en qué rama se fusionó, por lo que los cálculos subsiguientes de la base de confirmación serán incorrectos: el compromiso hace que el resultado de` git merge` parezca que usted ejecutó git merge --squash. Desafortunadamente, no hay una buena forma de evitar esta situación: Subversion no puede almacenar esta información, por lo que siempre estará paralizado por sus limitaciones mientras la usa como su servidor. Para evitar problemas, debe eliminar la rama local (en este caso, opera) después de fusionarla en el enlace troncal.

Comandos de Subversion

El conjunto de herramientas git svn proporciona una serie de comandos para ayudar a facilitar la transición a Git al proporcionar una funcionalidad similar a la que tenía en Subversion. Aquí hay algunos comandos que te dan de lo que solía hacer Subversion.

Historial de estilo de SVN

Si está acostumbrado a Subversion y quiere ver su historial en el estilo de salida SVN, puede ejecutar git svn log para ver su historial de commit en formato SVN:

$ git svn log
------------------------------------------------------------------------
r87 | schacon | 2014-05-02 16:07:37 -0700 (Sat, 02 May 2014) | 2 lines

autogen change

------------------------------------------------------------------------
r86 | schacon | 2014-05-02 16:00:21 -0700 (Sat, 02 May 2014) | 2 lines

Merge branch 'experiment'

------------------------------------------------------------------------
r85 | schacon | 2014-05-02 16:00:09 -0700 (Sat, 02 May 2014) | 2 lines

updated the changelog

Debes saber dos cosas importantes sobre git svn log. En primer lugar, funciona sin conexión, a diferencia del comando real svn log, que solicita al servidor de Subversion los datos. En segundo lugar, solo muestra los compromisos que se han comprometido hasta el servidor de Subversion. Local Git confirma que usted no se ha confirmado a no aparecer; tampoco hay confirmaciones que la gente haya hecho al servidor de Subversion mientras tanto. Es más como el último estado conocido de las confirmaciones en el servidor de Subversion.

Anotación de SVN

Al igual que el comando git svn log simula el comando` svn log` fuera de línea, puede obtener el equivalente de svn annotate ejecutando` git svn blame [FILE] `. La salida se ve así:

$ git svn blame README.txt
 2   temporal Protocol Buffers - Google's data interchange format
 2   temporal Copyright 2008 Google Inc.
 2   temporal http://code.google.com/apis/protocolbuffers/
 2   temporal
22   temporal C++ Installation - Unix
22   temporal =======================
 2   temporal
79    schacon Committing in git-svn.
78    schacon
 2   temporal To build and install the C++ Protocol Buffer runtime and the Protocol
 2   temporal Buffer compiler (protoc) execute the following:
 2   temporal

De nuevo, no muestra confirmaciones que hiciste localmente en Git o que se han enviado a Subversion mientras tanto.

Información del servidor SVN

También puede obtener el mismo tipo de información que svn info le brinda al ejecutar` git svn info`:

$ git svn info
Path: .
URL: https://schacon-test.googlecode.com/svn/trunk
Repository Root: https://schacon-test.googlecode.com/svn
Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029
Revision: 87
Node Kind: directory
Schedule: normal
Last Changed Author: schacon
Last Changed Rev: 87
Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)

Esto es como 'blame' y 'log' ya que se ejecuta fuera de línea y está actualizado solo a partir de la última vez que se comunicó con el servidor de Subversion.

Ignorar lo qué subversión ignora

Si clonas un repositorio de Subversion que tiene propiedades svn: ignore establecidas en cualquier lugar, es probable que desees establecer los archivos correspondientes '.gitignore` para que no confirmes accidentalmente los archivos que no deberías. git svn tiene dos comandos para ayudar con este problema. El primero es git svn create-ignore, que crea automáticamente los archivos correspondientes '.gitignore` para que su próxima confirmacion pueda incluirlos.

El segundo comando es git svn show-ignore, que imprime para extender las líneas que necesita poner en un archivo` .gitignore` para que pueda redirigir el resultado al archivo de exclusión de proyecto:

$ git svn show-ignore > .git/info/exclude

De esta forma, no descarta el proyecto con archivos .gitignore. Esta es una buena opción si eres el único usuario de Git en un equipo de Subversion, y tus compañeros de equipo no quieren archivos .gitignore en el proyecto.

Resumen de Git-Svn

Las herramientas git svn son útiles si estás atascado con un servidor de Subversion, o si no estás en un entorno de desarrollo que necesita ejecutar un servidor de Subversion. Sin embargo, debería considerar que paralizó a Git, o llegará a problemas de traducción que pueden confundirlo a usted y a sus colaboradores. Para evitar problemas, intente seguir estas pautas:

• Mantener un historial lineal de Git que no contenga uniones de fusión hechas por git merge. Rebase cualquier trabajo que realice fuera de su rama principal; nos e fusiona.

• No configure y colabore en un servidor Git separado. Posiblemente tenga uno para acelerar clones para nuevos desarrolladores, pero no le empuje nada que no tenga una entrada git-svn-id. Incluso puede desear agregar un gancho pre-receive que comprueba cada mensaje de confirmación para un` git-svn-id` y rechaza los empujes que contienen commits sin él.

Si sigues esas pautas, trabajar con un servidor de Subversion puede ser más llevadero. Sin embargo, si es posible pasar a un servidor Git real, hacerlo puede hacer que tu equipo gane mucho más.