git vs all

http://es.whygitisbetterthanx.com/#


Por qué Git es mejor que X

hg bzr svn perforce

Este sitio existe porque últimamente me parece que paso demasiado tiempo defendiendo a los usuarios de Git frente a acusaciones de fanatismo, seguidimo y fe ciega. Así que aquí veremos por qué la gente está pasándse de X a Git y por qué tú también deberías. Sólo haz clic en una razón para verla.
Ver todas | Cerrar todas

hg bzr svn perforce
Ramas locales sin coste
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.
svn perforce
Todo es local
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.
bzr svn perforce
Git is Rápido
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)
Git Hg Bzr
Inicialización 0.024s 0.059s 0.600s
Añadir 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Etiquetar 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Entrega (Grande) 12.480s 12.500s 23.002s
Entrega (Pequeña) 0.086s 0.517s 1.139s
Rama (en frío) 1.161s 94.681s 82.249s
Rama (en caliente) 0.070s 12.300s 39.411s
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
svn
Git es Pequeño
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.
Git Hg Bzr Bzr* SVN
Sólo el repo 24M 34M 45M 89M
Todo el directorio 43M 53M 64M 108M 61M
* el segundo número de Bzr es después de ejecutar 'bzr pack', que pensé que lo haría más pequeño pero por alguna razón lo hizo mucho mucho más grande.
hg bzr svn perforce
El área de montaje
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'.

svn perforce
Distribuido
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.

Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce
Cualquier flujo de trabajo
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.
Al estilo Subversion

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.


Al estilo Responsable de Integración

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.


Al estilo Dictador y Tenientes

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.
hg bzr svn perforce
GitHub

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.
perforce
Fácil de Aprender
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)
Ayuda de Mercurial

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
Ayuda de Git

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.