9.1 Git y Otros Sistemas - Git como Cliente

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 reescribas su historial y trates de volver a presionar, y no presiones a un repositorio paralelo de Git para colaborar con otros desarrolladores de Git al mismo tiempo. Subversion sólo 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.

Para demostrar esta funcionalidad, necesitas un repositorio SVN típico al que tengas acceso de escritura. Si deseas copiar estos ejemplos, tendrás que hacer una copia escribible del 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:

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

Ahora puedes sincronizar este proyecto con tu máquina local llamando a svnsync init con los repositorios

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

A pesar de que esta operación puede tardar sólo 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.

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. Recuerda que si estás importando desde un repositorio de Subversion alojado real, debes reemplazar el file: /// tmp / test-svn aquí con la URL de tu repositorio de Subversion:

Esto ejecuta el equivalente de dos comandos - git svn init seguido de` git svn fetch` - en la URL que proporciones. Esto puede tomar un rato. El proyecto de prueba sólo 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 nombras el tronco, las ramas o las etiquetas de manera diferente, puedes cambiar estas opciones. Debido a que esto es tan común, puedes reemplazar esta parte completa con -s, lo que significa diseño estándar e implica todas esas opciones. El siguiente comando es equivalente:

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

Ten 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 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 busca las etiquetas directamente en refs / tags, en lugar de tratarlas como ramas remotas.

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

A continuación, debes impulsar tu cambio en sentido ascendente. Observa cómo esto cambia la forma en que trabaja con Subversion: puedes 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, ejecuta el comando git svn dcommit:

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 tus proyectos simultáneamente con un servidor de Subversion no es una buena idea. Si miras la última confirmación, puedes ver el nuevo git-svn-id que se agregó:

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

Si estás 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 verá así:

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

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

Ten en cuenta que, a diferencia de Git, que requiere fusionar el trabajo original que todavía no tienes localmente antes de poder enviarlo, git svn lo hace sólo 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:

Es importante recordar esto, porque el resultado es un estado del proyecto que no existía en ninguna de las computadoras cuando se aplicó. Si los cambios son incompatibles pero no conflictivos, es posible que tengas 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 debes ejecutar este comando para obtener cambios del servidor de Subversion, incluso si no estás listo para confirmar. Puedes ejecutar git svn fetch para obtener los nuevos datos, pero git svn rebase hace la búsqueda y luego actualiza tus confirmaciones locales.

Ejecutar git svn rebase de vez en cuando asegura que tu código esté siempre actualizado. Debes asegurarte de que tu directorio de trabajo esté limpio cuando lo ejecutes. Si tienes cambios locales, debes esconder tu 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.

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ás presionando un servidor de Subversion a través de git svn, es posible que desees volver a establecer tu 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 tu historial se parece a lo siguiente: creaste una rama experiment, hiciste dos confirmaciones y luego las fusionaste de nuevo en master. Con dcommit, ve resultados como este:

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` experiment`; sin embargo, 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.

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, puedes crear y comprometerte con ramas en Subversion usando git svn.

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

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 sin más; si confirmas en este punto, esa confirmación irá a trunk en el servidor, no en opera.

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

Si deseas trabajar en más de una rama al mismo tiempo, puedes configurar las ramas locales para comprometer a las ramas de Subversion específicas, comenzándolas en la confirmación de Subversion importada para esa rama. Si deseas que una rama `opera ' pueda trabajar por separado, puedes ejecutar:

Ahora, si deseas fusionar tu rama opera en trunk (tu rama` master`), puedes hacerlo con un git merge normal. Pero debes 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 puedes volver atrás fácilmente y continuar trabajando en esa rama, como lo haces normalmente en Git. El comando dcommit que ejecutaste, 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 ejecutaste 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 lo usas como su servidor. Para evitar problemas, debes eliminar la rama local (en este caso, opera) después de fusionarla en el enlace troncal.

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 lo que solías hacer en Subversion.

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

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.

Primero, necesita instalar git-remote-hg. Esto básicamente implica dejar caer su archivo en algún lugar de su camino, así:

(Si no tiene instalado Python, visite https://www.python.org/ y consígalo primero.)

Lo último que necesitará es el cliente Mercurial. Vaya a https://www.mercurial-scm.org/ e instálelo si aún no lo ha hecho.

Ahora está listo para el rock. Todo lo que necesita es un repositorio Mercurial al que pueda presionar. Afortunadamente, todos los repositorios de Mercurial pueden actuar de esta manera, así que sólo usaremos el repositorio de "hola mundo" que todos usan para aprender Mercurial:

Ahora que tenemos un repositorio “server-side” adecuado, podemos pasar por un flujo de trabajo típico. Como verá, estos dos sistemas son lo suficientemente similares como para que no haya mucha fricción.

Como siempre con Git, primero clonamos:

Notará que el uso de un repositorio de Mercurial utiliza el comando git clone estándar. Esto se debe a que git-remote-hg está funcionando a un nivel bastante bajo, utilizando un mecanismo similar a como se implementa el protocolo HTTP / S de Git (auxiliares remotos). Dado que Git y Mercurial están diseñados para que cada cliente tenga una copia completa del historial del repositorio, este comando hace un clon completo, incluyendo todo el historial del proyecto, y lo hace con bastante rapidez.

El comando de registro muestra dos confirmaciones, la última de las cuales es señalada por un montón de refs. Resulta que algunos de estos no están realmente allí. Echemos un vistazo a lo que realmente está en el directorio .git:

Git-remote-hg está tratando de hacer las cosas más idiomáticamente Git-esque, pero bajo el capó es la gestión de la cartografía conceptual entre dos sistemas ligeramente diferentes. El directorio refs/hg es donde se almacenan las referencias remotas reales. Por ejemplo, el refs/hg/origen/branches/default es un archivo ref de Git que contiene el SHA-1 que comienza con “ac7955c”, que es el commit que señala master. Así que el directorio refs/hg es como un`refs/remotes/origen' falso, pero tiene la distinción añadida entre marcadores y ramas.

El archivo notes/hg es el punto de partida de cómo git-remote-hg asigna los hashes de commit de Git a los identificadores de cambios de Mercurial. Vamos a explorar un poco:

Así que refs/notes/hg apunta a un árbol, que en la base de datos de objetos Git es una lista de otros objetos con nombres. Git ls-tree genera el modo, el tipo, el hash de objeto y el nombre de archivo de elementos dentro de un árbol. Una vez que excavamos hacia abajo a uno de los elementos del árbol, encontramos que en su interior hay un blob llamado “ac9117f” (el hash SHA-1 del commit apuntado por master), con contenidos “0a04b98”. Que es el identificador del conjunto de cambios Mercurial en la punta de la rama default).

La buena noticia es, que en general, no tenemos que preocuparnos por todo esto. El flujo de trabajo típico no será muy diferente de trabajar con un control remoto de Git.

Hay una cosa más a la que debemos atender antes de continuar: ignore. Mercurial y Git usan un mecanismo muy similar para esto, pero es probable que no quiera realmente comprometer un archivo .gitignore en un repositorio de Mercurial. Afortunadamente, Git tiene una forma de ignorar los archivos que son locales a un repositorio en disco, y el formato Mercurial es compatible con Git, por lo que sólo tiene que copiarlo:

El archivo .git / info / exclude 'actúa como un .gitignore`, pero no está incluido en commits.

Supongamos que hemos hecho algunos trabajos e hicimos algunos commit en la rama master y estamos listos para enviarlo al repositorio remoto. A continuación, le mostramos nuestro repositorio:

Nuestra rama master está a dos compromisos por delante de origin/master, pero estos dos commits sólo existen en nuestra máquina local. Veamos si alguien más ha estado haciendo un trabajo importante al mismo tiempo:

Puesto que utilizamos el indicador --all, vemos las “notes refs” que son utilizadas internamente por git-remote-hg, pero podemos ignorarlas. El resto es lo que esperábamos; origin / master ha avanzado por una comisión, y nuestra historia ha divergido ahora. A diferencia de los otros sistemas con los que trabajamos en este capítulo, Mercurial es capaz de manejar fusiones, por lo que no vamos a hacer nada extravagante.

Perfecto. Hacemos las pruebas y todo pasa, así que estamos listos para compartir nuestro trabajo con el resto del equipo:

¡Eso es! Si echa un vistazo al repositorio de Mercurial, verá que esto hizo lo que esperábamos:

El conjunto de cambios numerado 2 fue hecho por Mercurial, y los conjuntos de cambios numerados 3 y 4 fueron hechos por git-remote-hg, al empujar los commit hechos con Git.

Git tiene sólo un tipo de rama: una referencia que se mueve cuando se hacen los compromisos. En Mercurial, este tipo de referencia se llama marcador, y se comporta de la misma manera que una rama de Git.

El concepto de Mercurial de una "rama" es más pesado. La rama en la que se realiza un conjunto de cambios se registra con el conjunto de cambios, lo que significa que siempre estará en el historial del repositorio. He aquí un ejemplo de un commit que se hizo en la rama develop:

Observe la línea que comienza con “branch”. Git no puede realmente replicar esto (y no necesita, ambos tipos de rama puede representarse como una referencia Git), pero git-remote-hg necesita entender la diferencia, porque Mercurial se preocupa.

Crear marcadores de Mercurial es tan fácil como crear ramas de Git. En el lado Git:

Eso es todo al respecto. En el lado mercurial, se ve así:

Tenga en cuenta la nueva etiqueta [featureA] en la revisión 5. Éstos actúan exactamente como las ramas de Git en el lado de Git, con una excepción: usted no puede suprimir un marcador del lado de Git (ésta es una limitación de ayudantes remotos).

Puede trabajar con una rama “heavyweight” de Mercurial si: introduce ramas en los espacios para branches así:

Esto es lo que aparece en el lado de Mercurial:

El nombre de la rama “permanent” se registró en el conjunto de cambios marcados con 7.

Desde el lado de Git, el trabajo con cualquiera de estos estilos de rama es el mismo: sólo “checkout”, “commit”, “fetch”, “merge”, “pull” y “push” como lo haría normalmente. Una cosa que usted debe saber es que Mercurial no apoya la historia de la reescritura, agregando solamente a ella. Esto es lo que nuestro repositorio de Mercurial parece después de un “rebase interactivo” y un “force-push”:

CHangesets 8, 9 y 10 han sido creados y pertenecen a la rama permanent, pero los viejos “changesets” siguen ahí. Esto puede ser muy confuso para sus compañeros de equipo que están usando Mercurial, así que trate de evitarlo.

Git y Mercurial son bastante similares, por lo que trabajar a través de la frontera es bastante indoloro. Si evita cambiar el historial que ha dejado su máquina (como se recomienda generalmente), puede que ni siquiera sepa que el otro extremo es Mercurial.

Perforce proporciona un producto llamado 'Git Fusion' (disponible en http://www.perforce.com/git-fusion), que sincroniza un servidor Perforce con repositorios Git en el lado del servidor.

Git-p4 es un puente de dos vías entre Git y Perforce. Funciona completamente dentro de su repositorio Git, por lo que no necesitará ningún tipo de acceso al servidor Perforce (aparte de las credenciales de usuario, por supuesto). Git-p4 no es tan flexible ni una solución completa como Git Fusion, pero le permite hacer la mayor parte de lo que le gustaría hacer sin ser invasivo en el entorno del servidor.

git-p4 hace posible usar un flujo de trabajo de Git con un servidor Perforce, y es bastante bueno en eso. Sin embargo, es importante recordar que Perforce está a cargo de la fuente y que sólo está usando Git para trabajar localmente. Tenga mucho cuidado al compartir commits de Git; si tiene un control remoto que utilizan otras personas, no envíe ningun commit que aún no se haya enviado al servidor de Perforce.

Si desea mezclar libremente el uso de Perforce y Git como clientes para el control de código fuente, y puede convencer al administrador del servidor para que lo instale, Git Fusion hace que Git sea un cliente de control de versiones de primera clase para un servidor Perforce.

De hecho, hay dos: git-tf y git-tfs.

git-tfs (alojado en https://github.com/git-tfs/git-tfs []) es un proyecto .NET, y (al momento de escribir esto) solo se ejecuta en Windows. Para trabajar con repositorios Git, utiliza los enlaces .NET para libgit2, una implementación de Git orientada a la biblioteca que es altamente eficiente y permite mucha flexibilidad con las agallas de un repositorio Git. Libgit2 no es una implementación completa de Git, por lo que para cubrir la diferencia, git-tfs realmente llamará al cliente Git de la línea de comandos para algunas operaciones, por lo que no hay límites artificiales sobre lo que puede hacer con los repositorios Git. Su compatibilidad con las características de TFVC es muy madura, ya que utiliza los ensamblados de Visual Studio para operaciones con servidores. Esto significa que necesitará acceso a esos ensamblados, lo que significa que necesita instalar una versión reciente de Visual Studio (cualquier edición desde la versión 2010, incluido Express desde la versión 2012) o el SDK de Visual Studio.

git-tf (cuyo alojamiento se encuentra en https://gittf.codeplex.com []) es un proyecto de Java y, como tal, se ejecuta en cualquier computadora con un entorno de tiempo de ejecución de Java. Interactúa con los repositorios de Git a través de JGit (una implementación JVM de Git), lo que significa que prácticamente no tiene limitaciones en términos de funciones de Git. Sin embargo, su soporte para TFVC es limitado en comparación con git-tfs. Por ejemplo, no admite ramas.

Entonces, cada herramienta tiene ventajas y desventajas, y hay muchas situaciones que favorecen a una sobre la otra. Cubriremos el uso básico de ambas en este libro.

Lo primero que haces, al igual que con cualquier proyecto de Git, es clonar. Esto es lo que parece con git-tf:

El primer argumento es la URL de una colección TFVC, el segundo es de la forma $ / project / branch, y el tercero es la ruta al repositorio Git local que se va a crear (este último es opcional). git-tf sólo puede funcionar con una rama a la vez; si quieres hacer checkins en una rama diferente de TFVC, tendrás que hacer un nuevo clon desde esa rama.

Esto crea un repositorio de Git completamente funcional:

Esto se denomina clon shallow, lo que significa que sólo se ha descargado el último conjunto de cambios. TFVC no está diseñado para que cada cliente tenga una copia completa del historial, por lo que git-tf usa de manera predeterminada la última versión, que es mucho más rápida.

Si tienes algo de tiempo, probablemente valga la pena clonar todo el historial del proyecto, usando la opción --deep:

Observa las etiquetas con nombres como TFS_C35189; esta es una característica que te ayuda a saber qué compromisos de Git están asociados con los conjuntos de cambios de TFVC. Esta es una buena forma de representarlo, ya que puedes ver con un comando de registro simple cuál de tus confirmaciones está asociada con una instantánea que también existe en TFVC. No son necesarios (y, de hecho, puedes desactivarlos con git config git-tf.tag false) - git-tf conserva las asignaciones reales commit-changeset en el archivo .git / git-tf.

La clonación de git-tfs se comporta de forma un poco diferente. Observe:

Observa el indicador --with-branches. git-tfs es capaz de mapear ramas de TFVC a ramas de Git, y este indicador le dice que configure una rama local de Git para cada rama de TFVC. Esto es muy recomendable si alguna vez se ha bifurcado o se ha fusionado en TFS, pero no funcionará con un servidor anterior a TFS 2010; antes de esa versión, ‘` branches '’ eran sólo carpetas, por lo que `git-tfs no puede hacer esto con las carpetas regulares.

Echemos un vistazo al repositorio Git resultante:

Hay dos ramas locales, master y` featuresS`, que representan el punto inicial del clon (Trunk en TFVC) y una rama secundaria (` featureS` en TFVC). También puedes ver que el tfs` remote '' también tiene un par de referencias: `default y featureA, que representan las ramas de TFVC. git-tfs mapea la rama desde la que clonaste a tfs / default, y otras obtienen sus propios nombres.

Otra cosa a notar es las líneas git-tfs-id: en los mensajes de confirmación. En lugar de etiquetas, git-tfs usa estos marcadores para relacionar los conjuntos de cambios de TFVC con las confirmaciones de Git. Esto tiene la consecuencia de que tus confirmaciones de Git tendrán un hash SHA-1 diferente antes y después de que se hayan enviado a TFVC.

Lo siguiente que querrás hacer es trabajar en el proyecto. TFVC y TFS tienen varias características que pueden agregar complejidad a tu flujo de trabajo:

En aras de la brevedad, lo que trataremos aquí es el camino feliz, qué pasos laterales seguir para evitar la mayoría de estos problemas.

Digamos que has hecho algo de trabajo, has hecho un par de confirmaciones de Git en master y estás listo para compartir tu progreso en el servidor de TFVC. Aquí está nuestro repositorio de Git:

Queremos tomar la instantánea que está en la confirmación 4178a82 y subirla al servidor TFVC. Lo primero es lo primero: veamos si alguno de nuestros compañeros de equipo hizo algo desde la última vez que nos conectamos:

Parece que alguien más está trabajando también, y ahora tenemos una historia divergente. Aquí es donde brilla Git, pero tenemos dos opciones de cómo proceder:

La decisión es tuya: Para este ejemplo, vamos a rebasar:

Ahora estamos listos para hacer una comprobación en el servidor de TFVC. git-tf te da la opción de hacer un único conjunto de cambios que represente todos los cambios desde el último (--shallow, que es el predeterminado) y crear un nuevo conjunto de cambios para cada confirmación de Git (` --deep`). Para este ejemplo, crearemos un solo conjunto de cambios:

Hay una nueva etiqueta TFS_C35348, que indica que TFVC está almacenando la misma instantánea exacta que la confirmación` 5a0e25e`. Es importante tener en cuenta que no todas las confirmaciones de Git deben tener una contraparte exacta en TFVC; el compromiso 6eb3eb5, por ejemplo, no existe en ninguna parte del servidor.

Ese es el flujo de trabajo principal. Hay un par de otras consideraciones que querrás tener en cuenta:

Veamos el mismo escenario usando git-tfs. Aquí están las nuevas confirmaciones que hemos realizado en la rama master en nuestro repositorio de Git:

Ahora veamos si alguien más ha hecho un trabajo mientras estábamos hackeando:

Sí, resulta que nuestro compañero de trabajo ha agregado un nuevo conjunto de cambios de TFVC, que se muestra como el nuevo compromiso aea74a0, y la rama remota tfs / default se ha movido.

Al igual que con git-tf, tenemos dos opciones fundamentales sobre cómo resolver esta historia divergente:

En este caso, haremos un 'checkin profundo ', donde cada confirmación de Git se convierte en un conjunto de cambios de TFVC, por lo que queremos volver a establecer la base.

Ahora estamos listos para completar nuestra contribución al registrar nuestro código en el servidor TFVC. Usaremos el comando rcheckin aquí para crear un conjunto de cambios TFVC para cada commit de Git en la ruta de HEAD a la primera rama remota tfs encontrada (el comando checkin sólo crearía un conjunto de cambios, más o menos como aplastar cuando Git se compromete).

Observa cómo después de cada registro exitoso en el servidor TFVC, git-tfs vuelve a basar el trabajo restante en lo que acaba de hacer. Esto se debe a que está agregando el campo git-tfs-id al final de los mensajes de confirmación, lo que cambia los valores hash SHA-1. Esto es exactamente como se diseñó, y no hay nada de qué preocuparse, pero debes saber que está sucediendo, especialmente si compartes commits con otros.

TFS tiene muchas características que se integran con tu sistema de control de versiones, como elementos de trabajo, revisores designados, registros bloqueados, etc. Puede ser engorroso trabajar con estas características usando sólo una herramienta de línea de comandos, pero afortunadamente git-tfs te permite iniciar una herramienta gráfica de registro muy fácilmente:

Se parece un poco a esto:

Esto resultará familiar para los usuarios de TFS, ya que es el mismo diálogo que se inicia desde Visual Studio.

git-tfs también te permite controlar ramas de TFVC desde tu repositorio de Git. Como ejemplo, creemos una:

Crear una rama en TFVC significa agregar un conjunto de cambios donde esa rama ahora existe, y esto se proyecta como una confirmación de Git. Ten en cuenta que git-tfs también creó la rama remota tfs / featureBee, pero` HEAD` todavía apunta a master. Si deseas trabajar en la rama recién acuñada, querrás basar tus nuevas confirmaciones en la confirmación 1d54865, tal vez creando una rama de tema a partir de esa confirmación.

git-tf y git-tfs son excelentes herramientas para interactuar con un servidor TFVC. Te permiten usar el poder de Git localmente, evitar tener que realizar un viaje de ida y vuelta al servidor central de TFVC, haciendo que tu vida como desarrollador sea mucho más fácil, sin forzar a todo tu equipo a migrar a Git. Si estás trabajando en Windows (lo cual es probable si tu equipo está usando TFS), quizás quieras usar git-tfs, ya que su conjunto de características es más completo, pero si estás trabajando en otra plataforma, puedes usar git-tf, aunque es más limitado. Al igual que con la mayoría de las herramientas de este capítulo, debes elegir uno de estos sistemas de control de versiones para que sea canónico y usar el otro de forma subordinada: Git o TFVC deberían ser el centro de colaboración, pero no ambos.