Por qué Git es mejor que X

Posiblemente la razón más fuerte a favor de Git que realmente lo hace destacar de casi cualquier otro SCV es su modelo de ramas. Es totalmente diferente de todos los demás con los que lo estamos comparando, la mayoría de los cuales recomiendan que la mejor rama es básicamente una copia del repositorio en un nuevo directorio.

Pero Git no funciona así. Git te permitirá tener múltiples ramas locales que pueden ser totalmente independientes entre sí y se tarda segundos en crear, fusionar, o borrar estas líneas de desarrollo.

Lo que quiere decir que puedes hacer cosas como :

• Crear una rama para probar una idea, hacer varias entregas un par de veces, volver al punto desde el cual bifurcaste, aplicar un parche y volver a donde estabas experimentado y fusionarlo.
• Tener una rama que siempre contiene sólo lo que va a producción, otra en la que acumulas el trabajo para testear y varias ramas más pequeñas para el trabajo del día a día.
• Crear nuevas ramas para cada una de las nuevas funcionalidades en las que estés trabajando, de forma que puedas conmutar entre ellas y borrarlas cuando su funcionalidad ha sido propagada a la rama principal.
• Crear una rama en la que experimentar, darte cuenta de que no va a ninguna parte y borrarla, abandonando todo el trabajo - sin que nadie más lo vea (incluso aunque hayas entregado otras ramas mientras tanto)

Es importante el que, cuando uno entrega sus cambios a un repositorio remoto, no tienes que subir todas tus ramas: puedes compartir sólo una de tus ramas y no todas. De esta forma la gente tiende a sentirse libre para probar nuevas ideas sin preocuparse de tener un plan de cómo y cuándo van a mezclar sus cambios o compartirlos con otros.

Se pueden encontrar maneras de hacer algunas de estas cosas en otros sistemas, pero el trabajo necesario es mucho más complicado y dado a error. Git hace que este proceso sea increíblemente sencillo y cambia la forma en la que trabajan los desarrolladores que aprenden a usarlo.

Esto es básicamente cierto en todos los SCV distribuidos, pero en mi mi experiencia lo es mucho más con Git. Aparte de 'fetch', 'pull' y 'push' hay muy pocos comandos que trabajen con cualquier cosa que no sea tu disco duro.

Esto no sólo hace que todo vaya mucho más rápido que de costumbre, también te permite trabajar cuando estés sin conexión. Que a lo mejor no te parece gran cosa, pero a mí al menos me ha llegado a sorprender la cantidad de veces que realmente trabajo sin conexión. El poder hacer ramas, mezclarlas, y navegar por la historia de mi proyecto mientras se está en un avión o un tren es realmente muy productivo.

Incluso en Mercurial comandos comunes como 'incoming' y 'outgoing' tocan al servidor, mientras que con Git puedes hacer 'fetch' de toda la información del servidor antes de quedarte sin conexión y hacer comparaciones, merges, y ver logs de todos los datos que están en el servidor aunque no pertenezca a tus ramas locales.

Lo que quiere decir que es muy fácil tener copias de no sólo todas tus ramas, sino también de todas las ramas que los demás que trabajan contigo proyecto hayan ido subiendo al repositorio de Git.

Git es rápido. Todo el mundo, hasta los más acérrimos usuarios del resto de sistemas lo reconoce. Esto se debe, comparado con SVN y Perforce, a que todas las operaciones se hacen localmente. Sin embargo cuando se compara con otros SCVs distribuidos, Git también es veloz.

Es posible que esto se deba en buena parte a que fue construido para trabajar en el kernel de Linux, lo que quiere decir que desde el primer día ha tenido que mover de manera efectiva repositorios de gran tamaño. Otra razón es que Git está escrito en C, y otra razón más es que, en mi experiencia, los desarrolladores principales de Git están muy preocupados por la velocidad.

A continuación veremos algunas pruebas que realicé en tres copias del código fuente de django en 3 sistemas diferentes: Git, Mercurial y Bazaar. También hice alguna prueba con SVN, pero creedme cuando os digo que es más lento - básicamente es añadirle la latencia de red a los números de Bazaar.

El resultado final es que para todo menos para añadir nuevos archivos, Git es el más rápido (también commits muy grandes, empatado con Git, pero la entrega que hice era tan grande que es bastante raro que alguna vez tengas que hacer algo parecido - los commits normales son mucho más rápidos en Git)

Los tiempos de creación de rama en frío y en caliente se corresponden, respectivamente, con el tiempo empleado en la primera y segunda vez que bifurqué el repositorio - de forma que en el segundo caso la rama se hizo con la caché del disco caliente.

Nótese que aunque los números para el añadido de ficheros son mucho más elntos, se trataba de una operación masiva (más de 2000 archivos) Para lo que la mayor parte de la gente hace, el añadir cosas al repositorio sólo lleva una fracción de segundo. El resto de operaciones es bastante más indicativo de las cosas que uno realmente termina haciendo en el día a día.

No es nada difícil volver a generar estas medidas. Simplemente clona el proyecto Django en cada uno de los sistemas e intenta ejecutar los mismos comandos en cada uno

• git clone git://github.com/brosner/django.git dj-git
• hg clone http://hg.dpaste.com/django/trunk dj-hg
• bzr branch lp:django dj-bzr
• svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn

Git es realmente hábil a la hora de ahorrar espacio. En general tu repositorio Git será poco más grande que una copia de trabajo de SVN - y en algunos casos es posible que sea más pequeño (parece ser que hay un montón de cosas que acaban en los directorios .svn)

Los siguientes tamaños fueron obtenidos de copias del proyecto Django en cada uno de sus mirrors de Git semi-oficiales en algún punto de su historia.

Al contrario que otros sistemas, Git tiene lo que denomina "área de montaje", o "índice" que es un área intermedia donde puedes configurar lo que contendrá el aspecto que tendrá tu entrega antes de hacer el commit.

Lo mejor del área de montaje, y que marca la diferencia entre git el resto de herramientas, es que puedes fácilmente montar algunos de tus ficheros según terminas con ellos y después entregarlos sin tener que enviar todos los archivos modificados en tu directorio de trabajo y sin tener que listarlos en la línea de comandos durante la entrega.

Esto también te permite preparar sólo fragmentos de archivos que han sido modificados. Por ejemplo, montas para entregar sólo los cambios al principio de un archivo que has estado modificando pero no los cambios del final.

Por supuesto, Git también hace que sea fácil ignorar esta funcionalidad en caso de que no queramos tanto nivel de control - simplemente añade '-a' al commando 'commit'.

Una de las cosas más chulas de cualquier sistema distribuido de control de versiones, incluido Git, es que es distribuido. Esto quiere decir que en lugar de hacer un "checkout" de la punta del código, haces un "clon" del repositorio en su totalidad.

Lo que quiere decir que incluso si trabajas de manera centralizada, cada usuario tiene lo que en esencia es una copia completa del servidor principal, y cualquiera de ellas podría ser recuperada para reemplazarlo en caso de caída o corrupción. Básicamente, no hay un punto de fallo único con git... a no ser que haya un punto único.

Además esto tampoco ralentiza demasiado las cosas. En término medio un checkout de SVN es más rápido que cualquiera de los SCV distribuidos, pero por poco. Además, de entre los sistemas distribuidos git fue el más rápido en mis pruebas.

Una de las cosas que más sorpenden de Git es que debido a su naturaleza distribuida y a su super-sistema de ramas se puede implementar fácilmente prácitcamente cualquier flujo de trabajo que se nos ocurra.

Una forma de trabajo muy común, especialmente entre aquellos que se pasan de un sistema no distribuido es un flujo de trabajo centralizado. Git no permite hacer subir los cambios al servidor si alguien lo ha hecho desde la última vez que nos bajamos los últimos cambios, de forma que un modelo centralizado donde todos los desarrolladores entregan al mismo servidor funciona sin mayor inconveniente.

Otra forma muy común de trabajar con Git es donde exista un Responsable de Integración - una persona que entrega al repositorio 'bendecido', y después un número de desarrolladores se copian ese repositorio y hacen sus cambios en él le piden al integrador que integre sus cambios. Este es el tipo de modelo de desarrollo que se suele usar en repositorios de software abierto o en GitHub.

En proyectos más grandes, los desarrolladores pueden organizarse de forma similar a como lo hacen en el kernel de Linux, donde hay gente que está a cargo de un subsistema específico del proyecto (los tenientes) e integran todos los cambios que tienen que ver con ese subsistema. Después otro integrador (el dictador) puede recoger los cambios únicamente de sus tenientes y subirlos al repositorio principal el cual todo el mundo vuelve a clonar.

Y de nuevo Git es totalmente flexible en este aspecto de forma que uno puede mezclar y escoger el flujo de trabajo que mejor se adapte a sus necesidades.

En esto podría ser que yo no sea del todo imparcial porque trabajo en GitHub, pero quiero añadir esta sección de todas formas porque hay mucha gente que afirma que GitHub es la razón por la que escogieron Git.

Y GitHub es para muchos una razón para escoger Git porque se parece más a una red social de código que un mero sitio de alojamiento. Uno se encuentra con otros desarrolladores o proyectos que son similares a lo que está haciendo y es muy fácil bifurcar y contribuir, creándose una comunidad vibrante en torno a Git y los que proyectos en los que la gente lo usa.

Existen otros servicios, tanto para Git como para otros SCVs, pero hay pocos que estén orientados a los usuarios desde un punto de vista social, y ninguno de ellos se acerca al número de usuarios que tiene GitHub. Este aspecto social es decisivo, y esta junto con el resto de funcionalidades de arriba hace que trabajar con Git y GitHub sea una gran combinación para desarrollar rápidamente proyectos de código abierto.

Este tipo de comunidad no está disponible en ninguno de los otros SCVs. Simplemente.

Esto solía no ser cierto - en los comienzos de Git no era tanto un sistema de control de versiones como un puñado de herramientas que permitían hacer tareas de sistema de ficheros de manera distribuida. Sin embargo a día de hoy el conjunto de comandos y la curva de aprendizaje de Git son bastante parecidos a la de cualquier SCV, e incluso mejor en algún caso.

Como es difícil probar esto de manera objetiva sin algún tipo de estudio simplemente mostraré las diferencias entre el menú de ayuda por defecto de Mercurial y Git. He resaltado los comandos que son idénticos (o casi) entre los dos sistemas. (En Hg, si escribes 'hg help' te sale una lista de casi 40 comandos)

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...

Antes de la versión 1.6 de Git todos los comandos estaban en el path ejecutable, lo cual confundía a mucha gente. Aunque Git sigue reconociendo todos estos comandos el único comando en el path ahora es 'git'. Así que si uno compara Git con Mercurial tienen un conjunto de comandos y sistema de ayuda muy parecido - hay poca diferencia desde el punto de vista de interfaz de usuario para un principiante.

Hoy es difícil sostener que Mercurial o Bazaar sean mucho más fáciles de aprender que Git.