[OT] Buenas practicas con GIT

[thefull]

Buenos días a todos

Ayer hablando con Antonio, de porque pasar Harbour de Subversion a GIT, puede haber gente que no esté de acuerdo, cuando no se estuvo de acuerdo
de pasar de CVS a Subversion.

No siempre se puede estar de acuerdo con algunas decisiones que nos afectan el día a día en el uso de Harbour.
Pero esta, por dios, hace tiempo que se tenia que haber realizado hace tiempo.

No sé si conocéis GIT o no, os invito a que os acerquéis a cualquier control de versiones distribuido, es simplemente espectacular.
Nunca una herramienta me ha llegado a sorprender tanto en mi día a día con el código fuente.

Aunque me queda mucho por aprender sobre GIT, os animo que veis una entrada sobre buenas prácticas en el uso de GIT.
http://xthefull.blogspot.com.es/

[Antonio Linares]

Rafa,

Desconozco GIT y de momento pienso seguir usando SVN para los desarrollos de FiveTech

Desde mi ignorancia, la única ventaja que me parece importante es que cada usuario de un proyecto GIT tiene una copia COMPLETA del proyecto, por lo que de destruirse ó perderse el proyecto original, se podria restaurar desde el repositorio de cualquiera de los usuarios.

La pregunta del millón es: Es que se iba a destruir un proyecto alojado en SourceForge ? Yo pienso que no, puesto que su responsabilidad es muy grande y seguro que son muy rigurosos con sus copias de seguridad.

Y la otra pregunta es: Es que acaso nos ha faltado algo durante todo el tiempo que hemos usado SVN ? Todo ha ido como la seda

Como no nos queda más remedio que acatar la decisión, todo esto sobra, y hay que usar GIT para Harbour. En mi opinión, la verdadera razón de Viktor ha sido la de reorganizar la estructura de ficheros, hacer limpieza (cosa que le encanta y está muy bien) y poco más...

Harbour en si, no ha mejorado ni un ápice por que se use GIT. El código de Harbour es el mismo

[thefull]

Antonio, si te gusta SVN, adelante
Si eres feliz con Subversion y te va bien ¿ para que cambiar ?

Ahora bien, para mí, en el día a día, el uso de GIT te da una flexibilidad BRUTAL!
Si todo el mundo, a nivel de proyectos de software, está migrando de SVN a GIT/Mercurial, como en su día nos fuimos de CVS a SVN,
es básicamente por las ventajas que aporta a la hora de programar.

Claro que para el proyecto Harbour, el compilador sigue siendo el mismo, esto no hace mejorar el código en sí,
pero, si que facilita , y mucho, el uso a los desarrolladores.

Pero esto es como los comparadores de texto, una vez lo pruebas, ¿ como podíamos programar sin ellos ?
Tampoco esto te aporta nada en el código, pero ayudan al desarrollador una barbaridad.

Saludos

[Antonio Linares]

Rafa,

Pero cuales son las ventajas reales de GIT sobre SVN aparte de lo que he comentado de que los repositorios se replican ?

El concepto de trunk y branches que comentas en tu blog tambien se puede hacer en SVN. Yo no he tenido necesidad de usarlo nunca, puesto que con el historico de cambios puedo retroceder a una versión en la que se haya introducido un bug. Con tres instrucciones tengo todo: checkout (para la primera vez), update y commit.

El añadir ficheros, borrarlos, etc. se hace comodamente desde el TortoiseSVN o directamente desde la línea de comandos de Linux y OSX.

Ojo que no es crítica a GIT, solo es que no veo una razón realmente poderosa para cambiar

[thefull]

Antonio, te tomo la palabra, y me parece un debate interesante, te nombraré las mejoras de uno sobre el otro.

Estoy preparando una conferencia para hablar con GIT a otros desarrolladores , que seguramente usan SVN, y
no había caído en la cuenta que podría decir para hacerles ver el porque es más cómodo el usar uno u otro.

Prometo dejar el material libremente cuando lo tenga terminado, pero a bote pronto:

+ Puedo hacer commits, sin comprometer el repositorio central. Al ser distribuido, mi commits locales no afectan al resto de compañeros y puedo
ir viendo mis cambios sobre mi código.

+ En mi caso, me pueden entrar más de una tarea para el software en producción. Necesito solo 1 segundo de mi tiempo en partir eso en ramas separadas,
para posteriormente fusionarlo todo en la rama de producción. En este caso, puedo ir liberando partes sin tener que comprometer todo el código en el central.

* No me convence Subversion, es que no puedo dejar un cambio por la mitad, para hacer por ejemplo un arreglo en la última versión estable.
En Git, aunque tenga cambios pendientes, puedo moverlos a un nuevo branch, arreglar lo que sea que estuviera roto, y volver a poner arriba de eso los cambios que moví temporalmente.
En Subversion, sería hacer un checkout en otro directorio para hacer el arreglo ahí.

+ Otro motivo es que permite, por ejemplo, que , aparte del repositorio central, podemos hacer el programador Antonio, puede directamente trabajar con una rama que solo existe
en mi repositorio. De esta manera, podemos estar trabajando sobre algo, que el resto no tiene ni idea, pero es el mismo repositorio!
Esto es fantástico, porque puedes realizar equipos diferentes sobre el mismo proyecto.

+ Otra característica es usar el stash, no sé si existe esto en SVN, es decir, tienes el código tocando por todos lados, no lo has terminado, es incompleto, por lo tanto, no voy a hacer
un commit sobre algo que esta mal. Ahora, hay que dejarlo todo, porque se ha encontrado un bug, cambiar a una revisión y arreglarlo , y quiero volver a continuar como lo tenia.
Esto, me supone perder 1 segundo de mi tiempo , y créeme, lo he usado muchas veces, y es una gozada. Tan simple como poner git stash, esto lo mete en una especie de almacén,
cambias a la versión que necesites del código, y después vuelves donde estabas, y git stash pop.

Pero lo más me gusta, es que todo es super rápido, nada de crear directorios por cada rama/tags, porque para GIT el manejo de rama es su razón de ser
No pretendo convencer a nadie, solo comento que después de probar CVS, Subversion y GIT, es como comparar un SEAT 600, RENAULT LAGUNA y un Bugatti Veyron

Seguiré investigando motivos para convencerte , a al menos, que veas que posibilidades te brinda GIT sobre SVN