Cómo pedirle a un desarrollador senior que aprenda Git correctamente, ya que siempre confirma el código directamente en la rama maestra

Git es un dolor en el trasero.

Cualquier conversación sobre un SCCS ( Sistema de control de código fuente ) que comience con la pregunta “¿Cómo haces esto?”, Y en lugar de una respuesta definitiva en respuesta, obtiene una pregunta como “¿Qué has hecho hasta ahora?” Indicador fuerte de que su SCCS está mal diseñado.

El problema es que hay muchas maneras de hacer lo mismo, y todos lo hacen.

Algunas personas lo consideran “una insignia de honor”: se supone que tener que aprender absolutamente todo acerca de un software para poder usarlo demuestra que tienes testículos enormes, porque pudiste superar la curva de aprendizaje.

Su equipo debe tener documentado “The One True Way ™”, y todos en el equipo deben usar el mismo proceso.

Si ingresa una nueva persona, puede dirigirse a cualquier miembro del equipo y preguntarle “¿Cómo hago esto?”, Y obtendrán exactamente la misma respuesta de todos.

O simplemente pueden usar la “hoja de trucos” escrita.

Si no establece un “The One True Way ™” escrito al comienzo del proyecto, cada desarrollador de su equipo tendrá su propia forma de hacer algo usando git.

Y será un desastre confuso para cualquier persona nueva que agregue al equipo, porque nadie tiene el mismo conjunto de comandos git para hacer lo mismo. Cuando preguntan a tres personas cómo hacer algo, obtendrán cuatro respuestas, y si vuelven a preguntar las mismas tres la próxima semana, entonces pueden agregar dos respuestas más.

En primer lugar, me aseguraría de que el desarrollador principal no esté usando Git de la manera adecuada para el repositorio en cuestión. El hecho de que el sistema de relaciones públicas se use en otros proyectos y repositorios, especialmente de código abierto, no lo hace adecuado para el suyo. Lo mismo con GitFlow, o cualquier otra forma de discutir con Git. Gran parte de esto son pautas útiles, pero la mayoría, si no todas, son opiniones y si no has aprendido que hay formas N + 1 para desollar a este gato, entonces daría un paso atrás y aprendería.

Algunas personas usan master como el salvaje oeste de commit land, y luego tenían ramas de liberación y operación para cada línea de liberación fuera de la línea principal. Esto se usó una tonelada en cosas como ClearCase e incluso Perforce. Lo he visto también usado con Subversion e incluso Git. A veces las personas mueven sus procesos a un método SCM diferente por varias razones. Esto funciona especialmente bien si la mayoría de las confirmaciones de tareas son pequeñas confirmaciones individuales que se prueban y se envían a una versión. O dicho de otra manera: si todos menos algunos de sus RP tienen una única confirmación y se fusionan rápidamente, entonces hacer un RP es casi por definición ineficiente. ¿Todavía hay razones para hacerlos? Claro, pero a menos que tenga una rama que exista por un tiempo, o tenga muchas confirmaciones, entonces el valor es mucho menor.

Lo que me parece extraño es que muchas de las respuestas a esta pregunta ignoran la simple verdad, y que no hay una forma correcta (o incorrecta) de usar Git.

En primer lugar, me aseguraría de que el desarrollador principal esté “equivocado” en cuanto a cómo se está comprometiendo. ¿Cuántos otros desarrolladores hay? Si solo son usted y el desarrollador principal, a menos que haya documentación que el equipo del proyecto haya aprobado, lo más probable es que estén jodidos. Puedes adaptarte al camino de la tierra, intentar cambiar las cosas, teniendo en cuenta que esta persona tiene más experiencia y probablemente ha estado allí más tiempo y, por lo tanto, ha ganado más credibilidad con el equipo del proyecto. Su última opción es encontrar algo que más se adapte a su estilo.

Ahora digamos que tiene razón, hay más que solo ustedes dos, y la mayoría de ustedes quiere hacer la ruta PR o no maestra. Luego, depende nuevamente si el proceso ha sido cerrado. No todos los lugares deciden las cosas democráticamente, e incluso aquellos que lo hacen, generalmente hay una pista que tiene la última palabra. Una vez más, puede presionar, adaptarse o irse.

Digamos que tienes razón, y hay un proceso documentado, el hombre mayor no lo está siguiendo y el equipo está a bordo. Lo mejor sería que un compañero le hablara. Ese par debe ser directo, pero lo más no conflictivo posible. Si eso funciona, genial. Si no, entonces haría que el equipo escalara al gerente de esta persona. Dependiendo del nivel de esa persona, prepárate para mostrar por qué esto está causando el caos en la tubería de construcción.

No recuerdo haber visto personalmente a alguien reprendido, y mucho menos despedido por esto, y es un hecho relativamente común. Diré que apesta, lidiando con el caos de construcción. He tenido que lidiar con eso personalmente y, en mi experiencia, la mejor manera de enfrentar los problemas es mediante la detección automática del problema.

He visto en otras respuestas usar herramientas para evitar que el ingeniero errante se comprometa, pero en mi experiencia es un lugar raro donde se ve que un desarrollador junior tiene más acceso al repositorio que el desarrollador senior. Siempre es lo contrario. Y hay razones legítimas para necesitarlo. Incluso con herramientas como relaciones públicas y GitFlow, todavía hay un gran potencial, y alguien necesita poder arreglar la fusión jodida o el final de liberación de flujo de Git errante de alguien.

Esta es una respuesta muy larga, y me disculpo por el muro de texto.

TL; DR

Hay más de una forma “correcta” de usar Git. Tal vez su desarrollador lo esté usando de una manera diferente. Si no, es política corporativa 101 para ti.

¡Buena suerte!

Muchos desarrolladores que pueden recordar los viejos tiempos con CVS o … bueno, no hablemos de las cosas anteriores … pueden recordar lo dolorosa que podría ser la fusión. Ramificar era algo malo porque te estabas preparando para mucho dolor. Subversion nos convenció a muchos de que podíamos bifurcarnos y fusionarnos con seguridad por un par de razones:

• Todo el proyecto tenía un solo concepto de revisión, en lugar de ser archivo por archivo. Cuando creó una rama, cada archivo en el que trabajó estaba en esa rama. De repente. Cuando te uniste, lo hiciste una vez. Los archivos no se olvidaron.
• Las herramientas de fusión mejoraron. Todos tienen su favorito y no quiero comenzar una guerra de llamas sobre ellos, pero creo que todos podemos estar de acuerdo en que mejoraron … mucho mejor.

Una de las cosas que requiere la ramificación son algunas convenciones para nombrar sucursales y cuándo se crean y fusionan las sucursales. En algunos de los proyectos que he trabajado en la convención se incluyen detalles sobre qué sucursales se construirán automáticamente por el sistema CI y lo cual no lo hará. La idea es que todas las ramas compartidas se construyan automáticamente. Las ramas utilizadas por los desarrolladores individuales no tienen que serlo. Esto significa que una confirmación rápida de una característica parcialmente completa al final del día no corre el riesgo de romper la compilación durante la noche.

Mi primera experiencia con un sistema de control de versiones distribuido fue con Mercurial. Todavía lo amo. Cuando se lo expliqué a otros desarrolladores, todo lo que tenía que decirles era que funcionaba casi de la misma manera que estaban acostumbrados con Subversion, pero con un par de comandos adicionales para las operaciones de inserción y extracción. Dibujaría algunas burbujas y flechas en una pizarra, señalaría un par y diría “Aquí están las cosas nuevas”. Luego señalaría que tenían un repositorio de clones localmente en sus propias computadoras portátiles que hacía que trabajar desde casa o un habitación de hotel mucho más fácil. Casi todos se fueron felices.

Luego vino Git. Mi problema con Git es que hay demasiados comandos nuevos para aprender. La forma de hacerlo funcionar para un equipo de desarrollo que lo está viendo por primera vez es destilarlo a los comandos que necesitan para las operaciones que desean realizar.

Una de las cosas que amo tanto de Mercurial como de Git es que reducen la necesidad de sucursales personales. Debido a que las confirmaciones son para su repositorio de clones local, no interrumpe la compilación para nadie más al incorporar características parcialmente completadas. Cualquier sistema que me permita realizar cambios más pequeños hace que TDD sea más fácil, lo que a su vez hace que muchas otras cosas funcionen mejor.

Lo siento, tengo la tentación de tener una respuesta inquietante: probablemente no tenga la herramienta adecuada.
Quiero decir, la herramienta correcta es aquella con la que su equipo es amigable / eficiente en el término del proyecto.
No quise decir que tu compañero de equipo no tiene que aprender cosas nuevas …, pero si alguien de tu equipo realmente no puede trabajar con tus procesos o herramientas, tal vez tus procesos / herramientas no sean buenos para tu equipo.

Otro punto que tengo en mente es que creo en el principio de propiedad del código colectivo [1], en este sentido he hablado con personas inteligentes que discuten sobre el uso de una sola rama. Desde este punto de vista, comprometer el código directamente en la rama maestra no es necesariamente una mala práctica, es una cuestión de contexto y opinión.

Finalmente, cada persona / equipo es diferente. Si estuviera trabajando en un equipo así, habría hablado de ello durante una retrospectiva [2], no señalando lo que alguien está haciendo, sino explicando POR QUÉ es ineficiente comprometer el código directamente en la rama maestra (si es el caso) . Si no practica retrospectivas, le sugiero que comience ahora, ya que es la mejor herramienta que tiene para hacer que su equipo funcione mejor.
Como consejo general, enfóquese en los hechos: Git: ¿qué problemas surgen al trabajar directamente en master?

Si no tiene problemas, continúe con una sola rama.

Notas al pie

[1] http://wiki.c2.com/?CollectiveCo …

[2] http://wiki.c2.com/?IterationRet …

¿Es este desarrollador senior como “su líder actual” o senior como “ha estado allí más tiempo que usted”?

Si son tu líder real, entonces sugiero preguntarles en un entorno privado por qué eligieron esa metodología en lugar de un modelo de ramificación diferente como gitflow. Estaría preparado para hablar sobre varios procesos y por qué cree que serían beneficiosos. También estaría dispuesto a aceptar que podrían tener una buena razón para hacerlo de la forma en que lo están, o pueden no tener ninguna razón en absoluto, y de cualquier manera solo tendrá que lidiar con eso. Eso apesta, pero sucede. Descubrirá que a veces hay mucho ego envuelto en el proceso de desarrollo, y a veces las personas no cambian por miedo, orgullo, etc. Sea cual sea el caso, definitivamente no diría: “Necesitas aprender git correctamente ,” en esta configuración. Acércate humildemente y es más probable que tengas éxito.

Si, por otro lado, solo han estado allí por más tiempo, entonces podría haber un conjunto completo de dinámicas sociales en juego, pero diría que generalmente es apropiado acercarse a su liderazgo real y detallar lo que cree que debe suceder y por qué. Si no hay un líder de facto en el proyecto y la estructura de su equipo de desarrollo es más plana, entonces es totalmente apropiado presentar sus ideas a todo el equipo y comenzar un diálogo sobre las mejores prácticas y estrategias de ramificación. Nuevamente, comience con un poco de humildad, pero en este escenario me sentiría cómodo intensificando mi actitud de “muy obstinado” a medida que aprendía más sobre las razones, o la falta de ellas, del proceso existente.

A menos que este desarrollador senior ofrezca algo que sea absolutamente irremplazable, pondría su trabajo en juego. La rama maestra en git está destinada a ser inmaculada, como “lista para lanzar a producción en cualquier momento”. Eso significa que NADIE se compromete directamente con el maestro, porque ese código no puede haberse probado correctamente. Por lo tanto, comprometerse directamente con el maestro es, literalmente, tan malo como pasar a los servidores en vivo y hacer cambios. En términos de código, es tan peligroso como fumar un empleado de la estación de servicio o un chef de ensaladas que no se lava las manos después de ir al baño. No hay excusas Aprenda los procesos adecuados de git, o salga.

Dependiendo de la situación real, uno o más de los siguientes podrían ayudar:

• Obtenga el consentimiento del equipo para bloquear el maestro y solo permita cambios a través de la solicitud de extracción.
• Ejecute una bolsa marrón (presentación de la reunión a la hora del almuerzo o algo similar que pueda funcionar en su entorno) que muestre un flujo de trabajo git simple pero efectivo
• Siga apareciendo cada vez que el CI falla. Si no tiene CI, sabe lo que debe hacer 😉
• Si están usando la línea de comando o Visual Studio, muéstreles una herramienta de interfaz de usuario fácil que no oculte la bifurcación. Mi elección para esto es GitExtensions.
• Explique un flujo de trabajo más complejo e intente impulsarlo (como GitFlow), si no funciona (el resultado probable), acepte una rama de característica simple -> maestro (idealmente a través de Solicitud de extracción) como un punto medio entre usted ambos. Haga que sean responsables de su acuerdo después de eso.
• Envíeles solicitudes de extracción de su código para revisar y aprobar

Actualizar:

Escribí más sobre este tema aquí.

Supongo que el desarrollador ya tiene una reputación de no escuchar (“senior”), por lo que no se lo explicas.

En un mundo ideal, tener un gerente de proyecto que haga cumplir las reglas funcionaría, pero en realidad eso solo genera resentimiento, y lo recordará para siempre.

El truco es que se le ocurra la solución que prefiera.

Imagina que tú y el equipo están teniendo problemas para usar git (técnicamente cierto, no necesitas mencionar que él es el motivo), y que su antigüedad es necesaria para encontrar una mejor solución. Ahora cruza los dedos y espera que se le ocurra algo razonable. En cualquier caso, después de haberlo inventado él mismo, es mucho más probable que lo siga.

Alternativas:

Todos comienzan a comprometerse a dominar hasta que él mismo descubra el problema.

`maestro` es solo un nombre. Puede crear una nueva rama llamada `estable` y tratarla como la nueva rama maestra. Puedes ir un paso más allá y llamarlo `junior` para que no comience a comprometerse directamente …

No se trata de decirle cuál es la forma correcta de usar Git, sino de mostrarle cuál es el proceso de lanzamiento acordado por su equipo.

Para ilustrar esto:

Trabajo con un equipo que solo trabaja en ramas de características, luego fusionan su trabajo en desarrollo, por lo que pueden cortar una rama de lanzamiento y luego fusionarla para dominar. Hacen esto porque tiene sentido para ellos. Su base de código es en su mayoría código heredado no probado que es muy rígido de cambiar y se lanzan a producción alrededor de dos veces al mes.

Trabajo en otro equipo que tiene una base de código muy bien probada y adaptativa y liberan sus microservicios tan pronto como pueden agregar valor comercial. A veces se lanzan a producción varias veces al día. Se comprometen directamente con el maestro, porque es lo que tiene sentido para su equipo.

Llamaría a una reunión de equipo y discutiría cuál es su proceso de liberación.

A las personas que no han “conseguido” git les lleva tiempo “tener” la mentalidad correcta para trabajar con otros a través de git.

Si su colega desarrollador senior disfruta acumulando conocimiento y entendiendo la razón detrás de decisiones aparentemente arbitrarias, entonces podría compartir con ellos algunos recursos fáciles de seguir sobre estrategias de ramificación de git, por ejemplo: Un modelo de ramificación de Git exitoso

Al igual que con aprender algo nuevo cuando te sientes cómodo con los procesos históricos, hay una cierta tendencia debido a la curva de aprendizaje. Entonces, la respuesta simple es pasar el tiempo haciendo que el desarrollador senior se sienta cómodo con un nuevo proceso.

¿Has intentado que un experto en Git venga a un almuerzo o una sesión de aprendizaje? ¿O tener a alguien que se sienta extremadamente cómodo con él y que esté siguiendo los procesos que usted ha instituido para guiarlo en esta área específica?

Digo esto como alguien que odia a Git. He encontrado que algunas de las herramientas y comandos son ridículamente onerosos, y estoy extraordinariamente cómodo tanto con las herramientas de línea de comandos como con el software. Mi historial de control de fuente está principalmente en VSS (bleh), CVS y SVN, pero recientemente mudé mi compañía a Git por un par de razones (y todavía lo odio). ¿Por qué no me gusta? Las herramientas de interfaz gráfica de usuario (kraken, escritorio de github y algunas otras) parecen funcionar de manera bastante inconsistente, especialmente a través de ssh, y hemos tenido bastantes fallas de fusión que tardaron horas en solucionarse. También hemos hecho que otros hagan cosas como esconder algo antes de un tirón, luego se olviden de diferir cuando eventualmente se comprometen contra ese archivo y vuelven a lanzar errores viejos, etc. De todos modos, esa no era tu pregunta 🙂

Tuve que lidiar con el caso contrario una vez.

El liderazgo tecnológico había decidido utilizar Trunk Based Development como una práctica estándar para nuestro proyecto, pero este desarrollador en particular no lo entendió / me gustó / le importó preguntar. Exigió que todos los que estaban trabajando en su subproyecto presentaran solicitudes Pull para su aprobación. Probablemente fue uno de los empleados más antiguos y uno de los menos cooperativos.

Entonces, en lugar de decirle que estaba equivocado, hicimos una reunión con el resto del equipo y discutimos por qué una u otra práctica fue beneficiosa. Esto no se sintió como una crítica directa a él o sus habilidades, sino más bien una conversación donde todos llegamos a un consenso.

Sin estar completamente convencido, estuvo de acuerdo. Incluso se volvió más amigable con nosotros desde entonces.

Esto puede ser realmente complicado basado en,

1. La compañia
2. La mentalidad del desarrollador senior
3. Tu relacion con el

Dado que lo está publicando aquí, es muy probable que no se haya sentido cómodo hablando con él sobre esto. La señal de un buen equipo técnico es que existe una jerarquía plana para los ingenieros cuando trabajan en un equipo independientemente de sus títulos y comparten libremente pensamientos y preocupaciones. Desafortunadamente, no existe en muchos lugares y la gente trae los títulos para demostrar que tienen razón. Esto normalmente se origina en toda la cultura de la organización. La respuesta práctica sería dejarlo aprender solo, tarde o temprano cometería algún error y luego se daría cuenta de lo que estaba mal en su proceso. O encuentre otro trabajo donde tenga mejores compañeros de trabajo para trabajar (y sí, tales lugares existen).

Una desventaja de la gente técnica es que se preocupan más por las aplicaciones y los sistemas y eligen mantener los sistemas en mejor forma en lugar de mantener felices a las personas.

¿Quizás no se le ha explicado claramente el proceso que sigue su equipo con respecto a la confirmación del código? El flujo de Git de tus equipos. No es lo mismo para todos los equipos. Siéntese junto con el resto de los miembros del equipo y acuerde un flujo de Git que funcione mejor para usted. Tan pronto como acepte como equipo, senior o no, el desarrollador lo seguirá. A menos que no sea un buen ciudadano del equipo.

Además de varias respuestas excelentes aquí, siempre existe la posibilidad de que este sea un “mal hábito” por parte del desarrollador, algo que con frecuencia se hace de manera reflexiva, no consciente. Si ese es el caso, puede ayudar a abolirlo bloqueando temporalmente los impulsos a la rama maestra con un gancho de actualización, como un recordatorio para ayudarlo a dejar el hábito.

opción 1: use SourceTree o GitKraken y use GitFlow

opción 2: lo que podría funcionar es hacer un “error jar”, como si pusiera 20 centavos por cada advertencia que confirma, 50 centavos si el código no se compila después de una confirmación. Lo mismo para hacer cosas estúpidas, comprometerse a dominar la sucursal, etc. Con ese dinero, salga a almorzar después de un tiempo con todo el equipo.

En primer lugar, este problema no debería volverse loco de esta manera. Si no es práctica de su equipo comprometerse directamente a dominar, entonces su política de Git no debería permitir esto. ¿No tiene un proceso de revisión de Código en su lugar? Incluso en un flujo de trabajo de tipo fusión a troncal, debe haber al menos una, si no dos, aprobaciones necesarias para continuar con la fusión. Pregúntele cuál es su opinión sobre su configuración actual, lo que implica lo lejos que está de la norma de la industria. Con suerte, su respuesta dará alguna razón sobre por qué están haciendo lo que están haciendo.

Si su empresa no tiene un líder técnico de proyecto que haga cumplir las políticas sobre el control de versiones, está en serios problemas.

Debería plantear este asunto al gerente del proyecto.

Todo es diversión y juegos hasta que arruines el repositorio y luego comiences a buscar en Google cómo arreglar las cosas.

Es mejor si le dices esto a tu gerente de proyecto. Él / Ella está en una mejor posición para guiar al Desarrollador Senior en esto. Te recomendaría no apretar el gatillo por ti mismo.

¡Espero que ayude!