Git: ¿Qué problemas surgen al trabajar directamente en master?

25

He visto muchos consejos sobre los modelos de ramificación git y la opinión más común parece ser que hacer cambios directamente en la rama maestra es una mala idea.

Uno de nuestros compañeros de trabajo está muy contento de hacer cambios directamente en la rama maestra y, a pesar de varias conversaciones, es probable que no cambien esto.

En este momento, no puedo convencer a un compañero de trabajo de que es una mala práctica trabajar directamente en master, pero me gustaría entender las cosas que entrarán en conflicto con su forma de trabajar, para saber cuándo necesito volver a visitarlo. este problema.

version-control git svn branching linuxunil
fuente
2
Definir "trabajar directamente". El maestro existe porque está destinado a ser utilizado. ¿Para qué crees que es y para qué no?
candied_orange
3
¿Trabajar fuera de master funciona para ti? Si es así, ¿por qué siente la necesidad de cambiar ahora? Si no funciona, ¿qué problema (s) está experimentando? En lugar de pedirle a la gente que le indique los argumentos de otras personas, podemos ayudarlo a resolver sus problemas.
Thomas Owens
1
Parece que está haciendo un desarrollo troncal, que, junto con la integración continua, es bastante normal en un equipo ágil. Si quiere trabajar de esta manera, tendrá que aplicar WIP para asegurarse de que nunca se trabaje demasiado contra un producto a la vez, y también usar el cambio de funciones para garantizar que el maestro se pueda liberar con funciones incompletas desactivadas.
Sr. Cochese el
... qué tan grande es el equipo?
ZJR
@ MrCochese No llamaría al desarrollo troncal en el sentido aquí "normal". Ciertamente, ninguno de los muchos lugares en los que he usado Git ha funcionado de esa manera, y lo desalentaría. Las ramas de características simplemente funcionan mejor.
Marnen Laibow-Koser

Respuestas:

57

Existen varios problemas cuando las confirmaciones se envían directamente al maestro

  • Si empuja un estado de trabajo en progreso a remoto, el maestro está potencialmente roto
  • Si otro desarrollador comienza a trabajar para una nueva característica de master, ella comienza con un estado potencialmente roto. Esto ralentiza el desarrollo
  • Las diferentes características / correcciones de errores no están aisladas, por lo que la complejidad de todas las tareas de desarrollo en curso se combina en una sola rama. Esto aumenta la cantidad de comunicación necesaria entre todos los desarrolladores.
  • No puede hacer solicitudes de extracción que son un mecanismo muy bueno para las revisiones de código
  • No puede aplastar las confirmaciones / cambiar el historial de git en general, ya que otros desarrolladores ya podrían haber retirado la rama maestra mientras tanto
Gernot
fuente
11
¡Hey Mira! En realidad respondiste la pregunta, a diferencia de básicamente todos los demás. ++ Bienvenido a SE.SE!
RubberDuck el
La mayoría de estos son problemas derivados de trabajar mal directamente en master , no de trabajar directamente en master per se.
Ant P
1
@AntP, ¿qué problemas podrían evitarse desde su punto de vista?
Gernot
10

Explíquele que las nuevas características necesitan su propia rama de desarrollo que se pueda implementar en un entorno de prueba antes de que se lance a producción.

De lo contrario, se encuentra en un estado perpetuo de características a medio completar. No puede implementar características a medio completar en producción, por lo que si está trabajando directamente en la rama maestra, todos los demás deben esperar a que termine su característica antes de que los cambios de otra persona puedan pasar a producción, incluidas las correcciones de errores.

El uso de ramas independientes para las características significa que cada nueva característica se puede probar e implementar independientemente de las demás.

Robert Harvey
fuente
"No puede implementar características a medio completar en producción" , esto no es cierto en absoluto, es completamente posible trabajar directamente en la rama principal, enviar código en cada confirmación, implementar frecuentemente "características a medio completar" y nunca romper nada . La entrega continua se trata de hacer exactamente esto: desacoplar la implementación de la versión. Lo que también sucede para resolver muchos otros problemas organizacionales que las personas normalmente abordan con soluciones técnicas a medias. A veces, esto implica alternar características, pero generalmente es posible construir e implementar el 90% de una característica sin cambio de comportamiento visible.
Ant P
@AntP: El proceso que está describiendo no es lo que yo llamaría "características a medio completar". Dichas funciones se prueban, están listas para producción y se pueden usar, o están ocultas por un interruptor de función o algo similar hasta el momento en que se prueban, están listas para producción y se pueden usar. No está enviando funciones que no funcionan.
Robert Harvey
Afirmó que las nuevas características deben desarrollarse en ramas no maestras porque no puede implementar las que están a medio terminar: ese no es el caso. Puede desarrollar nuevas funciones directamente en el maestro y enviar todos los códigos relacionados con esas características a producción antes de que la característica se complete y sin demorar otro desarrollo.
Ant P
1
@AntP: Lo único que tienen las ramas de características que su técnica no puede proporcionar es una contabilidad completa del trabajo realizado en una característica en particular. En algunas tiendas (la mía en particular) ese tipo de responsabilidad no es un lujo sino un requisito.
Robert Harvey
1
@AntP Si te entiendo correctamente, lo consideraría un paso atrás. Me encantan los buenos rastreadores de problemas, y los uso ampliamente, pero quiero que el VCS me cuente el historial de desarrollo de cualquier característica o línea de código. El rastreador de problemas puede contar la historia del lado comercial de un cambio, pero si el VCS no puede ayudarme a rastrear y auditar el código por sí mismo, entonces no está haciendo su trabajo. Esta es una razón por la que me opongo al desarrollo basado en troncales: hace que el VCS sea estúpido, sin ninguna ventaja compensatoria que pueda ver. (También: ¿acoplamiento frágil? Una característica es un cambio de código).
Marnen Laibow-Koser
2

Master debería ser potencialmente liberable. Período. No debe haber ningún trabajo a medio terminar en el maestro (a menos que esté deshabilitado con un indicador de función)

Dicho esto, he visto a algunos equipos complicar su flujo.

No utilizar PR cuando se integra para dominar es un error, ya que los desarrolladores no tendrán el poder de elegir cuando ocurra la integración.

Una sola rama de desarrollo aporta muy poco valor. Por lo general, solo complica las cosas. Muchas ramas de características aportan mucho valor.

Hacer ramas para cada entorno (dev, test, prod) es un error. Esto está fuera del alcance de git y debe ser manejado por la tubería de lanzamiento. Se debe implementar exactamente la misma compilación en todos los entornos, lo cual es imposible si hay ramas para cada entorno.

Si una característica es tan grande que no se puede hacer en un día o dos, todo el trabajo en una rama de la característica debe estar en ramas separadas e integradas con PR.

Esben Skov Pedersen
fuente
Estoy de acuerdo con la mayoría de lo que ha dicho, excepto por esto: "La misma compilación debe implementarse exactamente en todos los entornos". De hecho, un canal de lanzamiento generalmente debería ser capaz de implementar diferentes compilaciones en diferentes entornos y luego promoverlos a medida que pasan las pruebas. ¿Cómo manejas esto, si no con diferentes ramas (o al menos diferentes etiquetas)?
Marnen Laibow-Koser
Tal vez no estaba completamente claro. Una vez que se implementa una compilación en un entorno. Los mismos artefactos deben implementarse en el siguiente entorno sin una reconstrucción.
Esben Skov Pedersen
Si tiene compilaciones repetibles, no debería importar si reconstruye. Si no tiene compilaciones repetibles, tiene problemas más grandes. :)
Marnen Laibow-Koser
... pero sí, creo que debería etiquetar sus confirmaciones implementadas para que pueda promover el mismo código (independientemente de si reconstruye).
Marnen Laibow-Koser
Sí, pero la mayoría de los servidores CI pueden vincular las compilaciones a las versiones listas para usar, lo que facilita el seguimiento de las implementaciones. Cuando se configura correctamente, no es realmente necesario rastrear implementaciones en git. Git es un scm. No es una herramienta de implementación.
Esben Skov Pedersen
2
  • Master debería reflejar una rama de producción, una versión final que funcione.
  • Trabajar directamente en master significa que si crea errores, no tiene otra opción para "retroceder" que revertir / eliminar / restablecer confirmaciones, lo cual no es una forma limpia de trabajar y puede hacer que pierda las partes del nuevo código que estamos bien.
  • Por supuesto, en las primeras etapas de desarrollo quizás pueda comenzar a trabajar directamente en master, pero después de tener algo que entregar, debe usar ramas de desarrollo, prueba o experimentación para no tocar la versión publicada, completa y funcional.
Tulains Córdova
fuente
2

Primero, quiero señalar que en git, cada una pulles literalmente una operación de ramificación, y cada pushuna es una fusión. losmaster máquina de un desarrollador es una rama completamente separada de la masterde un repositorio central que comparte, con la misma posición desde una perspectiva técnica. Ocasionalmente cambiaré el nombre de mi versión local upstreamo algo así si se adapta mejor a mis propósitos.

Lo señalo porque muchas organizaciones piensan que están utilizando sucursales de manera más efectiva que su colega, cuando realmente están haciendo poco más que crear un nombre adicional para una sucursal en el camino, que de todos modos no se guardará en el historial. Si su colega está confirmando características en una confirmación atómica, es tan fácil retroceder como una confirmación de fusión de una rama de características. La gran mayoría de las ramas de características deberían ser de corta duración y, de todos modos, fusionarse con frecuencia.

Dicho esto, los principales inconvenientes de su estilo de trabajo son dobles. Primero, hace que sea muy difícil colaborar en una característica inacabada. Sin embargo, no sería difícil crear una sucursal solo en aquellos momentos en que se necesita colaboración.

En segundo lugar, hace que la revisión antes de la fusión sea muy difícil. En este punto, en realidad no necesitas convencerlo. Puede adoptar una herramienta como github, gerrit o gitlab, y requerir revisiones de código de solicitud de extracción y pruebas automáticas aprobadas para todas las fusiones. Si no está haciendo algo como esto, francamente no está utilizando git en todo su potencial, y no es de extrañar que su colega no vea ese potencial.

Karl Bielefeldt
fuente
1
También empujar a los desarrolladores su máquina de sucursal cada día es una buena copia de seguridad.
Ian
No entiendo tu primera sesión. No veo cómo a pullcrearía una nueva sucursal o cómo a pushsería una operación de fusión. Más bien, a pulles literalmente un fetchseguido de a merge!
mkrieger1
@ mkrieger1 Puedo ver fácilmente cómo se podría considerar que el local masteres una rama diferente de origin master. Técnicamente, son ramas diferentes en dos controles remotos diferentes, cada uno con su propia historia.
RubberDuck
@RubberDuck Sí, exactamente. Con pull: Antes: dos ramas potencialmente apuntando a confirmaciones diferentes - Después: dos ramas apuntando a confirmaciones equivalentes - No se crearon ramas, por lo tanto no lo llamaría una "operación de ramificación". Si alguno de los dos comandos, lo llamaría push, porque potencialmente crea una nueva rama en el control remoto. Lo que no hace, es una fusión.
mkrieger1
@ mkrieger1 también debe tener en cuenta la dirección de la fusión.
RubberDuck
2

Otras respuestas ya han mencionado varias ventajas (características aisladas, código siempre enviable en el maestro, etc.) para trabajar NO directamente en el maestro.

Para mí parece que tienes un problema diferente. Obviamente, no tiene un proceso de desarrollo, que todos los desarrolladores acuerdan o utilizan (o su desarrollador en cuestión ignora totalmente el proceso).

¿Tiene ramas de características, que se fusionan en master o tiene diferentes ramas de versiones también o utiliza un proceso totalmente diferente?

"No utilizar la rama maestra" no es suficiente.

Simon
fuente
2

Uno de nuestros compañeros de trabajo está muy contento de hacer cambios directamente en la rama maestra y, a pesar de varias conversaciones, es probable que no cambien esto.

Esto me lleva a creer que hay más problemas. Trabajar en master o no es principalmente parte de una filosofía más amplia sobre cómo, qué y cuándo lanzar productos.

Entonces, junto con un "nunca debe trabajar en master", ¿tiene pruebas de características, prueba el trabajo de los demás y revisa el código de los demás? Pruebas de aceptación e integración.

Si no tiene ninguno de los anteriores y solo lo está haciendo para "hacer git", también podría trabajar en master.

Pieter B
fuente
1

No hay "mala práctica" en torno al trabajo directo en la sucursal. Pero debe decidir qué es lo que mejor respalda su proceso:

Pregunta 1: ¿Debería su maestro representar el estado actual de lanzamiento de su software? Luego, debe introducir una rama de desarrollo global y fusionar el desarrollo al final de un desarrollo de lanzamiento.

Pregunta 2: ¿Quieres tener un proceso de revisión de código? Entonces debe tener "ramas de características" que se fusionarán en master (o desarrollar, si tiene una) a través de solicitudes de extracción.

Pregunta 3: ¿Es necesario compartir el estado del código intermedio con otros desarrolladores que aún no deberían publicarse en producción (o prueba)? Es el caso de que más de un desarrollador desarrolle una función. Entonces deberías introducir "ramas de características".

oopexpert
fuente
Las etiquetas son una forma muy viable de representar el estado de una base de código en el lanzamiento. Git hace que sea muy fácil pagar una etiqueta específica. Hace que una rama de desarrollo sea discutible.
RubberDuck