Razones para usar GIT antes que TFS

Ya hemos hablado de qué es Git y cómo funciona y de las ventajas de Git . No obstante algunos me han comentado que en sus empresas o incluso ellos mismos trabajan con el sistema de control de versiones de Microsoft ( TFS –Team Foundation Server ), que para qué iban a migrar ahora a Git por muy de moda que estuviese.

Y en respuesta de ese ‘por qué’, vamos a ver qué es lo que os estáis perdiendo compañeros ;).

No podrás crear y fusionar ramificaciones del proyecto principal de forma tan rápida como con, por ejemplo Git. Por norma general un cambio entre las diferentes ramas dentro de TFS suele tardar de 15 a 30 minutos, mientras que con Git podremos contar este tiempo de transición en segundos (varios minutos si nuestro proyecto es de gran envergadura), cambiando por completo el flujo de trabajo de desarrollo. Además no podrás dotar a tu sistema de control de versiones de un nivel de aislamiento similar al de Git, al tratarse de un sistema de control de versiones centralizado.

No tendrás a tu disposición herramientas como Pull request (PR), una función compartida por todas las plataformas Git fundamental en equipos de desarrollo al simplificar el desarrollo de diferentes componentes de un proyecto del que no somos propietarios , puesto que nos permitirá crear una “copia” del proyecto o ramificación sobre la que nosotros podremos trabajar y solicitar al equipo o persona autor o dueño de dicho código si quiere añadir nuestras modificaciones. Esta “solicitud de extracción” ayudará enormemente si contamos o sabemos de alguna comunidad de desarrollo que suela implementar o crear mods, mejoras, revisiones, etc… a raíz de un proyecto base.

En efecto, contaréis con TFS changeset (Conjunto de Cambios TFS) que os permitirá revisar las anotaciones de los testers sobre el código del proyecto o rama que estén trabajando para corregir aquellas anotaciones o comentarios. No obstante, en Git encontramos funcionalidades avanzadas en este campo, pudiendo limpiar el historial de cambios y anotaciones del proyecto (o de una parte de este) antes de combinarlo con la línea principal de desarrollo. Al pasar esta nueva revisión de la app a los testers, éstos no conocerán comentarios anteriores por lo que comprobaremos de nuevo desde cero si existe algún fallo en lugar de que se centren únicamente en los referentes a los comentarios previos.

Disfrutaréis de multitud de conflictos a la hora de combinar ramas entre sí. Git a diferencia de TFS y su control de versiones centralizado, sabe exactamente en qué punto inicia una rama, dónde dos ramas se diversificaron una de la otra, etc… Además, TFS no atenderá al tipo de archivo mientras que Git en función del tipo de archivo realizará la fusión de código y cambios de una forma u otra.

La fusión en modo rebase será inaccesible para vosotros. Si creamos una rama y trabajamos en ésta durante unos días, puede darse la situación en la que encontremos que la rama principal ha sufrido cambios con respecto a nuestro punto de partida. TFS presentará multitud de conflictos durante la fusión (enjoy! ;) puesto que la base del proyecto que está implementando es diferente a cuando se sacó el código. Git cuenta con Git Rebase , con la que añadiremos la rama en la que hemos estado trabajando sobre el punto desde el que la descargamos, estando nuestros cambios presentes para las revisiones posteriores y sin que nuestro trabajo y tiempo haya sido en vano.

Vuestro trabajo de desarrollo en paralelo será más complejo y al no contar con Git rebase, sufriréis de multitud de conflictos incluso dentro de la misma rama . Haciendo uso de Git, los desarrolladores podrán trabajar en paralelo en la misma rama en la que trabajan otro miembros del equipo, ya estemos en el repositorio central o en un fork obtenido desde éste.

¿Y cómo controlar esto? Gracias a las Pull Request como propietarios de un proyecto controlaremos y revisaremos los cambios que se integrarán en la rama compartida del mismo.

No tendréis la versatilidad de Git a la hora de obtener el código, puesto que en sistemas Git se trata a las ramas como punteros de una lista confirmada de modificaciones o cambios, con lo que sólo tendremos que seleccionar de qué puntero queremos obtener el código para descargarlo en cuestión de segundos (como antes, minutos si el proyecto cuenta con cierta envergadura).

Esto es para empezar y como veis no es poco lo que os perdéis, así que si queréis aprovechar bien vuestro tiempo y trabajo, no dejéis de pasar por el curso de Git, GitHub y GitLab donde aprenderemos cómo implementar estos sistemas en nuestros proyectos para obtener un máximo rendimiento de nuestro trabajo.

¿Quieres gestionar tu código de una manera más eficiente, escalabre y rápida? Descarga esta Cheat Sheet de los 20 Comandos de GIT imprescindibles para cualquier programador.

También puedes visitar el centro de recursos, encontrarás las últimas guías, ebooks y webinars de programación, sistemas y gestión del talento IT.