Este post de javahispano me ha hecho pensar de nuevo en Git. Leyendo los comentarios, llegué también a este otro donde cuentan las ventajas de Git sobre Subversion.
Hay un problema que creo que es generalizado y es que cuando se comparan dos herramientas, dos lenguajes dos entornos de desarrollo o dos lo que sea en este mundo de la programación siempre se tiende a decir que esto es mejor que aquello y que todos deberíamos usar esta herramienta. No hay nada más lejos de la realidad, cada herramienta suele tener su propósito y razón de ser, no hay cosas buenas y mejores en términos absolutos, siempre depende de cuales sean nuestras necesidades.
Mi opinión puede estar sesgada puesto que trabajo y me encuentro cómodo con Subversion, mientras que con Git sólo he hecho algunas incursiones (tengo un par de proyectos en GitHub ) y he intentado instalarme algún servidor Git en algún momento. Veamos las ventajas de Git.
Imagina, como es nuestro caso, que somos un grupo de desarrolladores (alrededor de 30) trabajando conjuntamente en proyectos, dentro de una empresa, en una sala todos juntos y con un servidor corporativo en la red interna para alojar el control de versiones (Subversion en nuestro caso). Los proyectos no son proyectos vivos, en el sentido de que el cliente pone unos requisitos, paga un precio, hay un plazo y acabado ese tiempo, el proyecto entra en mantenimiento para corregir errores, pero deja de evolucionar.
Ventajas de Git:
Es más rápido que svn en los checkouts/clone y demás comandos con accesos masivos al servidor, el repositorio ocupa menos tamaño. De acuerdo, no he hecho pruebas, pero no tengo motivos de duda.
Una vez que has hecho tu clone, puedes hacer tus commit en local, aunque no tengas acceso al servidor. Esto es una ventaja si quieres mantener tu histórico de cambios personales y que luego vaya al servidor más adelante. En nuestro caso es poco probable que no tengamos acceso al servidor, salvo que estemos trabajando desplazados. En cualquier caso, sí es una ventaja, aunque le veo una utilidad relativa en nuestro caso donde el 99% del trabajo se hace en la empresa.
Git hace mucho mejor los merges. No he probado, seguramente es cierto porque los de subversion dejan bastante que desear. En cualquier caso, nosotros no solemos hacer demasiados merges, así que en nuestro caso, nuevamente la ventaja sería relativa. Aunque claro, quizás no hagamos merges porque los merges de subversion son un infierno.
¿Y cuales son las pegas?
La primera es que nuestro servidor es windows y tiene un directorio LDAP de usuarios. He buscado tutoriales para configurar un servidor Git en Windows con LDAP y parece que es posible, pero no evidente. Git está pensado para linux y su soporte windows no es muy allá. Las ventajas que pienses conseguir con Git deberían compensar las horas de tu administrador para instalar todo eso correctamente.
Y la segunda pega es que me hace la impresión de que en general hay algo en Git que no gusta a la comunidad. El motivo es la aparición de herramientas como la mencionada en javahispano ( subgit ) o herramientas como git-svn que pretenden hacer una "mezcolanza" entre ambos repositorios. Esto hace pensar que los desarrolladores tienden a no cambiar a git (no ven suficientes ventajas o lo ven demasiado complejo) y es necesario este tipo de herramientas para animarles.
Otras pegas que me he encontrado con git es que no soporta fácilmente subproyectos dentro de un mismo repositorio ni es fácil extraer sólo la parte del repositorio que te interesa. Esta es una molestia importante en proyectos grandes con muchos desarrolladores donde cada uno está especializado en alguna parte del proyecto. El desarrollador se ve obligado a sacar/hacer clone de todo el proyecto. Por supuesto, es una duda mía, no conozco git y es lo que he encontrado en rápidas buscas en google cuando he hecho pruebas, seguramente alguien con experiencia en git pueda decir que esto es posible y fácil.
Y finalmente, mis busquedas en google tampoco me han dejado claro si git soporta fácilmente el tema de ramas y etiquetas más allá de hacer clones del repositorio. Hacer clones no me parece una solución adecuada para ramas oficiales (por ejemplo, para tener una versión que se ha entregado al cliente y corregir sobre ella los errores que encuentre el cliente). Me obligaría a pensar en el servidor una estructura de directorios para hacer los clones y a ponerlos accesibles de alguna manera a los desarrolladores (directorios compartidos, añadir más directorios al servidor git si es que se puede, etc). Una búsqueda rápida en google sobre ramas en subversion lo deja bastante claro, dentro del repositorio se pone trunk, tags y branches y se hace svn copy. El mismo servidor subversion sin tocar nada tiene todo esto público, incluidas nuevas ramas. Insisto, no conozco git, quizás lo soporta bien pero da la impresión de que los tutoriales que digan cómo no son tan fáciles de encontrar.
Y hay otro artículo que me ha llamado la atención. De alguna forma da a entender que si lo que realmente quieres hacer es trabajar en tu proyecto y usar un repositorio distribuido como una herramienta, casi es mejor usar Mercurial. Git es más interesante, de alguna forma, se convierte más en el fin que en la herramienta, haciendo quizás que el proyecto en el que estás trabajando sea sólo la excusa para usar Git. Git es adecuado para proyectos de gran envergadura, con múltiples ramas, con procesos de trabajo complejos y que necesitan ser configurados fuera de los estándar que ofrece Mercurial.
Soy bastante friki y me gusta/quiero pasarme a git, pero veo que tendría que tener una, dos o tres semanas libres para aprender a montar todo y organizarlo lo suficientemente bien como para hacer que todo nuestro grupo migre a git de forma cómoda, teniendo acceso a las ramas actuales con el código instalado en los clientes, la rama principal de desarrollo, etc, etc. Y la pega es que no sabría explicar claramente a los no frikis qué ventajas reales van a tener con una única excepción. Si varios desarrolladores se van un período largo a las instalaciones del cliente a desarrollar, pueden montar fácilmente su propia red de repositorios git entre ellos para corregir bugs, hacer merges entre ellos y cuando estén de vuelta, hacer un merge en el repositorio oficial.
Pero resumiendo, posiblemente Git sea bueno para proyectos opensource con muchos colaboradores, donde se hacen muchas ramas experimentales, muchos desarrolladores cada uno a su bola intenta hacer mejoras, se quiere juntar todo con cierta frecuencia, etc. Es decir, proyectos vivos, complejos y con muchos desarrolladores más o menos independientes. Para un proyecto de empresa que requiere un repositorio central con la versión oficial del cliente, donde los desarrolladores están todos ubicados en la misma sala y no tienen tanta libertad para sus desarrollos porque deben limitarse a requisitos concretos en plazos de tiempo concretos, quizás Subversion es más que suficiente.
Conicido con tus opiniones y conclusiones al 100%… supongo que también influye tener un contexto laboral similar al tuyo…
Gracias por tu contribución.
P.D.: esto… una cosita: (no puedo evitarlo, lo siento) te sugiero corregir esa «embergadura». Saludos!! 😉
Hay que partir de que tanto svn como git (¡y Mercurial!, uso las tres asiduamente…) son herramientas excelentes. En efecto todo depende de las necesidades de uso que tengas, y hay que tratar de analizar muy bien el tipo de usuarios, el tipo de proyecto y la forma de trabajo para que la elección perdure sin traumas.
Algunas cosejas/aclaraciones/recomendaciones:
– git-svn y cosas por el estilo: no funcionan bien del todo, cuidado. No es tan fácil. Si no te ves en la necesidad de usarlos, mejor.
– Metadatos: una característica que me encanta de SVN es que también puedes versionear metadatos (properties) de los archivos, sin necesidad de crear archivos adicionales que los contengan. Le saco mucho partido a esta capacidad y es algo muy difícil de emular en git (lo hago con .gitattributes, pero me resulta chapucero, no está pensado para eso)
– Un factor importante es el cliente que uses. En Windows, TortoiseSVN es tan acojonantemente bueno que es una buena justificación para usar SVN, sobre todo en el caso de usuarios noveles (conozco incluso a no programadores que usan SVN muy a gusto con TortoiseSVN). TortoiseGIT es más complicadillo… porque git es más complicadillo.
– Los tags/branches en git: notablemente superiores a SVN. El concepto de tags/branches en SVN es sencillo, pero especialmente en el caso de los tags no me parece muy acertado. git hace tags de verdad, etiquetas de toda la vida, más sencillas y no se corre el riesgo de modificarlas.
– Muy importante tu comentario sobre hacer check-out solo de partes de un repositorio: un gran plus de SVN para muchas aplicaciones prácticas. Es cómodo trabajar con subproyectos en SVN, con git no tanto. En efecto git solo te permite hacer un clon de un repositorio completo, es parte de su filosofía. Esto hay que tenerlo muy en cuenta.
– Bloqueo de archivos: si tienes necesidad de trabajar con bloqueo de archivos (por ejemplo: algunas herramientas de modelado lo requieren, o si versioneas archivos binarios de uso frecuente), sencillamente el modelo de DCVS (git, Mercurial…) no sirve, te implica ser muy , muy organizado para no liarla. SVN sí lo permite.
¡Un saludo!
Saludos, sigo el hilo de lo que todos comentan acerca de que cada herramienta es mas o menos aplicables según el contexto.
Lo que no me gusta de SVN:
– Dependo del servidor para hacer commits.
– Cuando se realiza un cambio mínimo y se hace commit SVN cambia el número de versión en todos pero todos los archivos y subdirectorios y eso es sumamente costoso
– Hacer ramas, merges, etc es sumamente costoso por la razón anterior
Coincido con jacho con respecto a lo de git-svn, se debe usar con mucho cuidado y generalmente se usa cuando dentro de una organización hay un SVN en producción y algún externo prefiere usar git para acometer contra ese SVN.
Este es el mejor enlace que he visto donde explican todo acerca de Git:
http://git-scm.com/book
Usar el .gitignore es sumamente sencillo y para lo que comentan de bajarse sólo parte del repositorio, es posible, de hecho yo lo realizo a menudo con git-modules, pero hay que organizar desde el principio el proyecto para que se haga de manera fácil.
Las ramas y tags es otra cosa en la que Git es muy potente y fácil de usar, independientemente de si el proyecto es grande o no, yo particularmente uso este esquema de ramas para TODOS mis desarrollos por pequeños que sean:
http://nvie.com/posts/a-successful-git-branching-model/
Jacho no entendí lo que comentáis del bloque de archivos.
Si se animan a migrar algún proyecto de SVN a Git encantado les echo una mano 😀
Así aprendemos todos acerca de la migración.
Saludos
@carloschacin
Corregido embergadura, gracias. Y lo peor es que ni siquiera puedo decir que fue un despiste, totalmente convencido que se escribía así 😛
TortoiseSVN dejé de usarlo, me hacía muy, muy lento el explorador de arcivos de windows. Supongo que fue con windows 7 recién salido y sin posibilidad a tortoiseSVN de actualizarse.
@carloschachin: buenísimos los enlaces. Tu esquema de ramas me encanta, un buen ejemplo de lo bien que se apaña git con múltiples ramas, voy a probarlo a ver qué tal.
Por bloqueo me refiero al mecanismo de lock. Trataré de explicarlo mejor:
Antiguamente, para evitar conflictos a lo bestia, se establecía un mecanismo de bloqueo, esto es, quien quería editar un archivo primero tenía que pedir al repositorio central su bloqueo, de modo que solo ese usuario podía editar un archivo en un momento determinado. Esto se vio en la mayoría de los casos un engorro, y los SCM modernos lo evitan, mejorando mucho la capacidad de merge automático y favoreciendo la edición concurrente, como debe ser.
Peeero… hay situaciones en que el bloqueo de archivos es conveniente. El ejemplo más claro: si dos usuarios quieren editar un mismo archivo «.jpg», como el merge es imposible y habría un conflicto seguro, el mecanismo de bloqueo viene bien. SVN te permite indicar si un archivo necesita bloqueo (propiedad svn:needs-lock) y así, antes de editarlo harás un «svn lock» para que tú y solo tú puedas hacer commit, y hasta que no lo hagas otro usuario no podrá.
Os podréis preguntar ¿y para qué meter archivos binarios en control de versiones? Esa es otra historia que depende de gustos… Pero aparte de binarios hay tipos de archivo, como XML generados por alguna herramienta visual, por ejemplo, con los que el merge es muy complicado. Aquí el bloqueo también es bueno.
Por definición, un DVCS como git no puede implementar mecanismos de bloqueo de este estilo, porque no hay un repositorio central que gestione quién tiene un archivo bloqueado.
Pero aun así, una característica también muy buena de git (y Mercurial) son las múltiples extensiones que los complementan. Concretamente en el caso de manejo de archivos binarios existe una extensión para git llamada «git-annex» que proporciona un mecanismo que evita conflictos, extremadamente potente.
Pingback: Diario de Programación » Blog Archive » Jugando con GIT