Hola como están?

Les traigo un tema que quiero tratar y del cual tengo un gran desconocimiento.

• La problemática
  

En mi trabajo usan SVN. En la facultad aprendí a usar GIT. Haber conocido GIT me hizo dar cuenta muchas ventajas sobre SVN que desconocía del todo.
Siempre viene a cuento en mi trabajo (donde trabajamos cerca de 30 personas usando repositorios) del por qué no nos pasamos a GIT.
Hoy tuvimos una discusión muy seria al respecto de introducción de errores en el código... como tema derivado surgió que uno de los chicos hizo notar que "si commiteamos todos sobre el trunk, al hacerme un update se me rompen cosas sobre las cuales estaba trabajando", y casos similares.
A raíz de esto, volvimos a hablar sobre el tema manejo de branches y la posible incorporación de GIT.
Entonces surgió que, según mi team leader, "hay una política de la empresa que no nos permite que cada desarrollador tenga su propia branch"... ¿por qué?, las razones:
* SVN es una herramienta con un pésimo manejo de branches... que al momento de mergear varias branches el SVN introduce problemas (que GIT no tendría en un ppio).
* Habría que capacitar a todo el personal que desconoce SVN al uso de GIT. Esto lleva tiempo.
* Habría que cambiar "todos los procedimientos".
* El "socio" encargado del uso de servidores "le gusta" que toda la información esté siempre centralizada (por ende está en contra del uso de repositorios locales).

• La solución
  

- Una solución que "acepta" la alta cúpula de socios fundadores es... entregar una propuesta concreta con todos los pro y contras reales de la implementación de GIT (y por ende dejar de usar SVN) en un proyecto ya muy avanzado, con tiempos y esfuerzos estimados con un cierto grado de certeza.

La última solución es la que más me gusta pero ni yo sé que hacer o qué decir que no hayan discutido con anterioridad. Estoy convencido que este tema ha alcanzado una cierta madures en el mercado... que GIT ya no es un producto experimental. Tampoco sé con certeza si SVN realmente es tan malo para el manejo de branches como dicen. Tampoco sé si está bien o mal que cada usuario tenga su branch sí o sí, hasta donde llega el apocalipsis si todos le pegan a master todo el tiempo (aclaro que sí armamos branches, pero sólo al momento de hacer una entrega).

Me siento muy ignorante en esto ya que no tengo tanta experiencia en el tema y a mi, en lo personal, me está jodiendo bastante que nadie acá dentro se esté preguntando cuánto podríamos mejorar si se tomara más en serio el tema.

¿Sugerencias? ¿Experiencias personales? ¿Bibliografía recomendada?

Saludos!

Si no lo conoces, te recomiendo ver esto: http://aprendegit.com/que-es-git-flow/
A esto, si le sumas un esquema de 'Pull Requests' (basicamente, no mergeas directo sino que subis tu codigo para que el resto lo chequee, y si esta todo ok lo mergeen) tenes un flujo bastante copado. El tema del PR al principio se ve como una perdida de tiempo, o bien como un "me estan controlando". Pero nada que ver, los que revisan tu codigo se toman un tiempito para mirar el codigo, recomendarte cosas, detectar posibles bugs temprano y tambien para aprender de otra persona.

Una revision puede llevar ponele 1h (haciendola bien completa, en un ticket promedio). Arreglar un bug, por mas tonto que sea, cuanto lleva? 8hs? Si detectas las cosas temprano, ahorras tiempo.

Cualquier cosa avisa! Son interesantes estos asuntos!

Yo labure en un lugar donde todos commiteabamos a un branch propio de SVN y despues, antes de deployar, mergeabamos todos al trunk. Una patada ninja, bugs por todos lados. Les propuse usar gitflow y ni pelota. Al mes viene el CTO y dice "che, encontre la posta... gitflow" y migramos todo a git. A veces las cosas son asi :/

(23-05-2016 19:04)Adriano escribió:  Si no lo conoces, te recomiendo ver esto: http://aprendegit.com/que-es-git-flow/
A esto, si le sumas un esquema de 'Pull Requests' (basicamente, no mergeas directo sino que subis tu codigo para que el resto lo chequee, y si esta todo ok lo mergeen) tenes un flujo bastante copado. El tema del PR al principio se ve como una perdida de tiempo, o bien como un "me estan controlando". Pero nada que ver, los que revisan tu codigo se toman un tiempito para mirar el codigo, recomendarte cosas, detectar posibles bugs temprano y tambien para aprender de otra persona.

Una revision puede llevar ponele 1h (haciendola bien completa, en un ticket promedio). Arreglar un bug, por mas tonto que sea, cuanto lleva? 8hs? Si detectas las cosas temprano, ahorras tiempo.

Cualquier cosa avisa! Son interesantes estos asuntos!

Yo labure en un lugar donde todos commiteabamos a un branch propio de SVN y despues, antes de deployar, mergeabamos todos al trunk. Una patada ninja, bugs por todos lados. Les propuse usar gitflow y ni pelota. Al mes viene el CTO y dice "che, encontre la posta... gitflow" y migramos todo a git. A veces las cosas son asi :/

Hola Adro, el proyecto final lo hicimos todo bajo ese esquema de hacer pull requests, hacer code review antes de hacer el merge de branches de requerimientos, etc... Para mi fue la mejor experiencia que tuve al respecto de manejo de versionadores.

Sin embargo acá estoy bajo un mal manejo de "políticas" en la empresa. No solo eso, sino que además hay gente que estudió conmigo en la UTN (y están por arriba mío) que dicen cosas como ... "¿Y por qué GIT es mejor? Dicen que MERCURIAL es mejor incluso... ¿qué tiene de malo que usemos SVN?" ... y otras cosas como... "un buen desarrollador tiene que trabajar independiente de la tecnología".

O sea, estamos a un punto en donde no basta mostrarles un link de internet para que cambien de opinión... Si me preguntás a mi, prefiero mil veces mi experiencia con GIT en la facu que las experiencias con SVN en empresas... Pero no cuento con las herramientas/conocimientos necesarios para poder ir con algo más elaborado para presentarle a las personas que siguen pensando que migrar todo a GIT no es un calvario tan pesado como el que se imaginan.

Aca veo varias cosas.

(23-05-2016 18:47)Fly escribió:  Hoy tuvimos una discusión muy seria al respecto de introducción de errores en el código... como tema derivado surgió que uno de los chicos hizo notar que "si commiteamos todos sobre el trunk, al hacerme un update se me rompen cosas sobre las cuales estaba trabajando", y casos similares.

Aca hay que preguntarse: Para que usamos el repositorio? Es para tener una copia de mi trabajo al final del dia, o solo subo las cosas cuando tengo una funcionalidad cerrada/estable?

Si haces lo primero, si o si tenes que tener branches separados. Commitear todo al mismo branch desde donde todos hacen update es malo. Este problema lo vas a tener en todos lados, ya sea usando SVN, GIT, o el que venga despues. Es una mala practica, justamente porque vas a romper las cosas a los demas .

Si haces lo segundo, va a estar todo bien siempre... hasta que quieras compartirle una funcionalidad semi-hecha a otro. O lo mandas por mail/chat/etc, o creas otro branch, o le rompes todo a los demas. Ademas de perder un respaldo por si le pasa algo a tu maquina, u otra persona tiene que seguir con tu trabajo.

Cita:* SVN es una herramienta con un pésimo manejo de branches... que al momento de mergear varias branches el SVN introduce problemas (que GIT no tendría en un ppio, según cuenta la leyenda).

http://stackoverflow.com/questions/24716...han-in-svn

SVN es una garcha no solo con los branches, si no con cualquier cosa que no sea el codigo que actualmente estas usando. Si queres una revision anterior, SVN va a buscarlo al repositorio remoto. Si queres comparar tu revision con otra, o con otro branch, va a buscarlo al repo remoto. Cuando los proyectos son grandes, e involucran archivos pesados, son muchos minutos que perdes hasta que svn haga su trabajo... Cuando son cortos, es tiempo perdido que te hincha las bolas.

Hacer esto en Git tiene un costo 0, ya que toda esa info la tenes local.

Cita:* Habría que capacitar a todo el personal que desconoce SVN al uso de GIT. Esto lleva tiempo.

Lo mejor es que alguien que sepa git DE VERDAD les explique. Y tambien ser metodicos con la forma de organizarse. La base de git para que trabajen podes explicarlas en unas horas, mas un par de horas mas de practica. No hace falta que sepan todo.

Explicar solo comandos y compararlo con SVN puede ser rapido, pero despues vienen los problemas, gente que intenta cambiar la historia del repo y termina rompiendo todo, reaprender conceptos mal explicados, etc. Creo que gran parte de los problemas de implementar git vienen por pensar que es svn.

Cita:* Habría que cambiar "todos los procedimientos" (¿cuáles son? No lo sé bien... Esto ya tiene olor a historieta de Dilbert).
* El "socio" encargado del uso de servidores "le gusta" que toda la información esté siempre centralizada (por ende está en contra del uso de repositorios locales).

La informacion puede estar siempre centralizada. El repositorio local es algo que le sirve al trabajador. Se pueden aplicar politicas de "suban los cambios al repo central al finalizar el dia" y listo, igual que svn. Este es un tema mas de organizarse que otra cosa.

Cita:- Una solución que "acepta" la alta cúpula de socios fundadores es... entregar una propuesta concreta con todos los pro y contras reales de la implementación de GIT (y por ende dejar de usar SVN) en un proyecto ya muy avanzado, con tiempos y esfuerzos estimados con un cierto grado de certeza.

Para mi Git tiene un pro a nivel organizacion: Manejo simple de branches locales y remotos.

- Manejar branches tiene un costo 0.
- Por ende, tambien manejar tags.
- Podes ver facilmente la historia del repositorio, quien mergeo con quien en que momento, que cosas. Con SVN, dependes del commit que haga el commiteador. Te la regalo si lo tenes que hacer a mano.
- Tener varios branches ayuda a implementar buenas practicas:
* Primero, te ordena tu laburo. Para una organizacion eso es un +1000.
* Peer review (via pull requests como ya dijeron).
* Evitas en gran parte tener branches basura, que a veces los necesitas en SVN.
* Manejo sencillo de multiples entornos (un branch para dev, otro para qa, otro para preprod, etc).
* Estar ordenado facilita la automatizacion de tests/build/deploy, y luego podes hacer continuous delivery!
* Si no tenes tests automaticos, podes hacer continuous delivery para la gente de QA .

- Gitlab CE + CI. No conozco nada similar para SVN. Es una herramienta excelente para administrar repositorios. Si usan gitlab cloud ya tienen todo configurado y el costo de implementarlo es 0.

Si tenes un jefe que le gusta tener todo centralizado, con Gitlab se va a mear.

Cita:Tampoco sé con certeza si SVN realmente es tan malo para el manejo de branches como dicen.

Lo es.

Cita:Tampoco sé si está bien o mal que cada usuario tenga su branch sí o sí, hasta donde llega el apocalipsis si todos le pegan a master todo el tiempo (aclaro que sí armamos branches, pero sólo al momento de hacer una entrega).

Eso ya depende de como se manejen. Mira el link de git flow que te pasaron. Definir el esquema de trabajo es algo muy intimo de cada empresa. En mi laburo, usamos un branch por "funcionalidad". En otros laburo, por un tema de seguridad preferian que cada uno se haga un clon remoto del repo, trabaja ahi, y luego hace pull request. Hay muchisimas opciones distintas.

Lo importante de esto es que hagas lo que te sirva. Git te da mucha flexibilidad en como podes organizarte. Podes hacerlo de una forma, ver que no funciona, y despues cambiar tu flujo. Lo importante es que siempre vas a tener un seguimiento de que es lo que esta haciendo el repositorio, cosa que con svn lo perdes.

---

Cita:Sin embargo acá estoy bajo un mal manejo de "políticas" en la empresa.

Lo copado de git es que te facilita el orden. Si vas a hablar con los jefes, correlos por ese lado. Mostrales el caos que hay actualmente.

Cita:... y otras cosas como... "un buen desarrollador tiene que trabajar independiente de la tecnología".

Bueno, que programen en assembler entonces .

https://www.atlassian.com/git/tutorials/...d-workflow

Volviendo al post original, te sugiero que, antes de renunciar o matar a nadie, uses git-svn. Es un subcomando de git para interfacear con un repo SVN. Es decir, vos laburás localmente en un repo git, pero que se alimenta de un repo svn, y podés commitear al repo SVN también. Tenés que tener un mínimo cuidado a la hora de pushear (`dcommit` creo que era el comando), en cuanto a tener una historia _lineal_ (para que SVN no se maree con merges y esas cosas), pero sacando eso tenés la ventaja de que vos usás git, y el resto que hagan lo que quieran.

Cuando lo uses un par de semanas vas a ir aprendiendo mejor las diferencias entre un sistema y otro, y va a quedarte más claro qué ventajas te ofrece git sobre SVN.

La principal diferencia, para mí, es el tema de dónde hacer los merge. En SVN los merge se hacen en el server. Cuando hay conflictos los resolvés vos, pero los merge los hace el server. Y eso hace que cuando vos "pusheás" algo, nunca tengas garantías de en qué estado va a quedar el remoto - si alguien hizo un push/commit justo entre que vos updateaste y pusheaste, podés romper todo sin enterarte.

En git no podés pushear nada que no incluya todos los commits que están en el remoto (salvo que hagas un -f, claro). Entonces si hacés pull, y en los dos segundos entre tu pull y tu push alguien más pusheó, git te rechaza el push. Tenés que volver a actualizarte y mergear localmente, por lo que estás obligado a ver cómo va a quedar el repo remoto. Cuando pusheás, el remoto queda como en tu máquina, por lo que si el remoto queda roto es porque sos un forro que no revisaste lo que estás pusheando (aka, mergeaste con los ojos cerrados y sin importarte una mierda). En SVN, por "constancia" y buena actitud que tengas, cuando hacés el commit podés estar mergeando con algo que no sabías que existía - una garcha.

Si eso no le parece importante a tu jefe - la consistencia del repo central -, bue, es una discusión de locos. Correlo por el lado de "todo el mundo lo usa", "la mascota de Github es hermosa" o cualquier argumento idiota, porque razonar no parece posible.

Todo lo demás - branch por feature, logs/diffs/blames locales, git bisect, etc - son chiches. Que hacen que git sea súper awesome, pero siguen siendo chiches. El core es ese: consistencia. Hacer un push es decir "ahora mi repo queda así", así sucede, sin cruzar los dedos ni tener miedo por perder algo.

Si quieren capacitación, pingueame y puedo evangelizar sin problemas ;-)