La mejor estrategia de Git para trabajar con ramas y en equipo

Ni Git Flow, ni GitHub Flow... si quieres una estrategia que aumente la productividad y autonomía de los equipos tienes que darle una oportunidad a Ship/Show/Ask.

Esta estrategia es para desarrollos que ya tienen buenas prácticas como una buena suite de tests, CI/CD y similar.

[ignaciocuadrazamora]

Afortunadamente he tenido dos cargos que me dan puntos de vistas variados respecto al tema de "no son niños":

Trabajé como líder técnico en múltiples proyectos de I+D con equipos pequeños de 3 o 4 programadores (y en compañía con otros equipos técnicos: mecánicos, electrónicos, telecos, etc). Y mi prioridad siempre fue enseñar y hacer que cada uno de mi equipo fuera capaz de tomar decisiones. ¿Que el junior decidió usar variables con nombres "a", "b", "c" en vez de nombres descriptivos? pues nada, reunión de 10 minutos solo con el (las correcciones siempre en privado, los halagos siempre en publico) señalandole la razón por la cual es mejor usar otro tipo de nombres. Y luego, lo acompaño mientras corrige el mismo el problema para que me pueda preguntar de ser necesario; En algunos casos volvían a "cagarla" pero al recordarles lo arreglaban ellos solos, y de hecho, con el tiempo y con la confianza en si mismos empezaban a arreglarse las cosas entre ellos e incluso a recomendarme cosas a mi.

Por otra parte, ahora mismo trabajo como consultor de procesos de negocios, les he hecho consultoría a múltiples empresas (bancos, inversoras, fiscalías, productoras importadoras, etc). Y una regla primordial son los controles cruzados. Si una persona hace algo, el mismo no puede "revisar" lo que hizo, lo tiene que hacer otro, y dejar una evidencia de que lo hizo. Riesgos y Controles; para muchas empresas no es una "decisión", es una exigencia legal.

Estoy de acuerdo con esto de "no son niños" y que cada uno sepa que hacer y como hacerlo, pero siempre debe haber un control. Si tenemos integración continua con pruebas bien hechas entonces perfecto: push a master y que un senior haga revisiones esporádicas cada tanto (idealmente dejando un comentario, correo o lo que sea como evidencia). ¿Que no tenemos buenas pruebas? pues lastimosamente veo necesario ir a punta de PRs en lo que arreglamos lo de las pruebas.

Obviamente todo depende del proyecto, si estas haciendo la web comercial de aceitunas pepito, te puedes tomar ciertas licencias. Pero si estás desarrollando el sistema que opera un equipo médico que cuesta millones... mientras mas controles, mejor.

En resumen: Estoy de acuerdo 100%: Seamos buenos profesionales y ayudemos al resto a ser mejores, pero siempre tengamos controles (si son automáticos mejor).

[murodix]

En mi opinion aun siendo senior puede implementar malas practicas.. prefiero siempre crear PR y dependiendo de las prioridades se puede usar el "SHOW", pero nunca SHIP

[guillermomualem]

Que crack Midu!! Me encantó la simpleza 👏

[albertmontagutcasero]

Mola lo que comentas y es una alternativa muy válida, lo que no haría es decir algo es blanco o negro, todo parte de un compromiso y hay que encontrar el criterio correcto. Git flow es otra estrategia totalmente válida que seguir y en algunos casos puede ser más productiva que lo que comentas, lo digo por la miniatura. Aparte, No entiendo por qué usar Ship/Show/Ask no permite usar ramas feature, develop, release, bugfix etc. puedes comitear en cualquier rama usando la regla del Ship/Show/Ask

[fernandoreynaga]

Actualmente comienzo como responsable de proyecto, que puede ser algo como líder técnico ya que tengo la responsabilidad de que las implementaciones de mis compañeros funcionen, y funcionen bien. Por ende, como las buenas prácticas era algo ausente en dicho proyecto (aún lo es pero, tenemos mucho por delante), mis compañeros no se esfuerzan demasiado en mejorar el código existente y a veces siguen las malas prácticas porque les es más fácil copiar y pegar (cosa que no paro de reclamarles).
Como no tengo experiencia como líder estaba a punto de comenzar a pedir y revisar cada PR de mis compañeros a fin de corregir lo que viese mal.
Pero entonces mencionaste que, en efecto, no somos niños. Es algo complicado de explicar cómo tus pocas palabras me empezaron a abrir los ojos, así que lo resumiré con que acabas de darme una bofetada que me aclaró bastante el panorama y te agradezco por ello

[blablabla]

Qué maravillosa tu forma de transmitir conocimiento. Gracias.

[Iceuve]

La mejor estrategia de Git para trabajar es hacerlo como determina todo el equipo, no utilizar el control de versiones como a cada uno le da la gana, porque así mantener proyectos gigantes es complicado. No nos engañemos, en muchos proyectos hay junior (y senior) que no sabe utilizar correctamente GIt, como para que se haga cada uno responsable de sus mierdas. Jamás me han revisado el código, pero sigo el flujo que determinan en conjunto todos los equipos de desarrollo que trabajan para un mismo cliente.

[keynertyc]

Usar Feature Flags con unleash es una buena opción también.

[idcmardelplata]

Pregunta, si se hacen commits a master directamente ¿Se usan toggle flags como en trunk? o se tiene una rama dedicada a releases?

[roregelg]

Me parece interesante lo que planteas, duda, dónde consigo tu libro, para empaparme más en el tema. Soy de la "vieja" escuela y lo que manejaba era TFS de Microsoft, ahora uso git flow, pero tú planteamiento me parece bueno.
Saludos.

[itenrioarq]

Me he reído bastante viendo este video. Esto es solo recomendable para proyectos nuevos o pequeños o que no sean críticos, o en empresas cuyo proceso de contratación es lo suficientemente exigente como para que los equipos tengan recursos con un alto conocimiento, pensamiento crítico y responsabilidad. Mi buen amigo Murphy me ha enseñado que si algo puede salir mal, seguramente saldrá mal; además, los procesos de desarrollo de software deben minimizar los riesgos. Permitir que cualquier recurso haga cambios no supervisados que se reflejen a producción, bajo la bandera de "no son niños", atenta contra la continuidad del negocio que exige todo proyecto serio de software.

[RichardAPalaciosG]

Gracias Midu por tus palabras del seniority hay que responsabilizarnos, ! como me gustaría algún día estar en un equipo tuyo o trabajar contigo! y crecer como debería!. Por lo de Ship / Show / Ask, creo que lo hago ya.

[sevillanocarmona]

Ya tengo el libro en casa para mi nueva andadura como DevOps Junior. Lo tendré a mano mientras me voy empapando de información sobre Kubernetes y Azure devops.

En mi caso, usaré GitLab.

[jhon_sketch]

hay que hacer un merge de master a la rama funcional antes de hacer el pr? o solo hacer el pr y que la gente vea como resolver el merge?

[Cristian]

Creo de independiente del nivel que se tenga las revisiones de código son importantes tanto para el que genera el código como el que lo revisa, obviamente el revisor no puede tomar una postura cerrada siempre se puede crecer y aprender de todos revisando código y escenarios en donde le revisen el código a uno, esto con el objetivo de discutir y llegar a consensos de mejores practicas en la implementación del código.

[davidflorez]

Realmente lo que dice midu sobre la infantilización es real.

Hace poco en un trabajo universitario estaba como líder de mi equipo y tuve que aprender por las malas que hay que delegar no solo trabajo sino también responsabilidades y confiar en el equipo (además de penalizar si se ha hecho mal).
En mi caso trabaje con un grupo de personas sin mucha experiencia y al principio hacia de profesor y de guía un poco pero después se formo un bucle en el que además de hacer mi trabajo debía revisar el del resto y corregirlo, bucle que se genero tanto desde mi lado como el del equipo, que se enojaba si no estaba ahi para corregir.

El tema es que al final aprendí que en vez de ese approach es muchísimo mejor simplemente delegar, las personas adultas son capaces de ver si tienen un error en develop o en producción y solucionarlo, y aunque tu podrías hacerlo más rápido... NO SOMOS SUPERMAN

Así que, lo siento a mi equipo y también a mi mismo, espero que esta experiencia le ayude a otras personas que estén viviendo cosas similares.

[matiaschediek]

"El que decide eres TU, porque no eres un niño" Hermoso!

[almarto]

Totalmente de acuerdo contigo, el micromanagement y ese pensamiento de yo, como lead, soy el único ser con capacidad e inteligencia universal para hacer las cosas bien solo llevan a frustración de los compañeros que ven que no avanzan, un cuello de botella increíble que se carga todo el agile y CI/CD que tiene la empresa jajaja.

A mi muchas veces me preguntan sobre desarrollos en progreso y aunque sepa que esta mal les digo: si tú lo ves bien, adelante o no veo nada raro/mal a priori.
Con la intención de que después de estar todo un día con eso llegan al punto en el que por ellos mismos se dan cuenta de que hay algo que hace inservible su estrategia y deben de empezar de 0. Es un poco putadita pero si no te equivocas a veces....
Hasta ahora he recibido más "gracias" que "joder ya me podrías haber avisado", porque así realmente aprenden varias cosas que les ayuda a subir de nivel, una de ellas es la de plantear si con esa estrategia va a funcionar todo, antes de ponerse a picar nada de código con lo primero que les parece "aceptable".
Por supuesto soy coherente con el tiempo que sé que van a invertir en equivocarse y jamás se me ocurriría que perdieran 3 días de trabajo, en ese caso hay otras estrategias, como empezar a preguntar ¿Qué pasaría si....? para intentar guiarles hasta el fallo, etc.

[danielvenegas]

Hola, estoy viendo de comprar el libro pero en ningún lado dice que cantidad de páginas tiene?
De cuántas páginas es? Y es formato libro donde hay 200 palabras por página o es formato tipo Powerpoint exportado a PDF/epub dónde lo terminas de leer en 20 solo minutos?
Gracias

[davidsuke]

Cuál es la página web que dice en el último segundo?