Tratar con una solicitud de extracción grande

Deje que el desarrollador que pasó un par de meses sin fusionarlo lo solucione. Tal vez puedan obtener una gran parte de código para fusionar, tal vez puedan obtener una gran cantidad de pequeños trozos para fusionar uno a la vez. En cualquier caso, deberían estar haciendo todo lo posible para solucionar el problema, ya que lo causaron.

  

¿Cuál es la mejor manera de enfrentar una situación en la que una rama está realmente lejos de las otras?

En general, no te preocupes por eso: es el problema del otro desarrollador. Si dos ramas están realmente demasiado separadas para fusionarse, entonces ya no son parte del mismo proyecto y usted tiene una bifurcación de facto. Si es un proyecto de código abierto, eso puede no ser un problema.

Si este desarrollador es realmente brillante, y su código es mejor / más inteligente / más importante que el resto del equipo combinado, entonces vale la pena que sea su problema en lugar del suyo. De lo contrario, no lo es.

Para responder a la pregunta literal: la forma mejor de lidiar con este tipo de situación es no meterse en ese tipo de situación.

  

¿De qué manera podemos evitar que las sucursales obtengan un gran número de confirmaciones fuera del maestro en el futuro?

Asegúrese de que todos se den cuenta de que el desarrollador que pasó meses sin fusionarse tiene que solucionar el problema que causó. Asegúrese de que todos sepan que es más fácil comprometerse a dominar con frecuencia que con poca frecuencia, ya que menos cambios significa menos oportunidades para conflictos.

Asegúrese de que las personas sepan que pueden retirarse del maestro para mantenerse al día con los cambios de otras personas.

"Si te fusionas todos los días, de repente nunca llegas al punto en que tengas grandes conflictos que son difíciles de resolver". --Linus Torvalds

Esa cita es de una charla que dio en Google, aquí está la transcripción , y aquí está el video .

Si tiene una confirmación de que sabe esto y todas las confirmaciones anteriores están bien probadas y deberían fusionarse, entonces simplemente bifurque desde esta última confirmación buena y fusione la nueva rama con la maestra.

Si tiene algunas confirmaciones que le gustaría fusionar, pero están entremezcladas con otras confirmaciones que no están listas para la producción, veo 2 posibilidades:

1. Crea una nueva rama, y elige las mejores confirmaciones, fusiona con el maestro.
2. Intente reajustar los compromisos no deseados a la parte superior (quizás en una nueva sucursal solo para estar seguro).

En cuanto a los métodos de prevención, intente definir algunas reglas divertidas del equipo como "Una que no se fusione con el maestro en una semana ordenará pizza durante un mes".

Primero, vea si realmente hay confirmaciones separadas que se puedan fusionar o seleccionar, como lo sugiere @Maciej Chalpuk. Si este es el caso, entonces la situación realmente no es tan mala, y no me preocuparía demasiado por ello en el futuro.

Sin embargo, si la situación real es que se han desarrollado múltiples funciones simultáneamente en una sola rama, dentro de los mismos compromisos, entonces se convierte en un problema mucho más grande de tratar. Afortunadamente, el método de prevención está integrado: requiere que el desarrollador separe los cambios para cada característica en ramas separadas y extraiga las solicitudes antes de fusionarlos. Ambos obtendrán sus fusiones atómicas, así como disuadirán a este desarrollador de hacerlo. el futuro.

El proceso real de separación de las funciones es completamente manual. Cree nuevas sucursales a partir del maestro, y copie en cualquier cambio de la mega rama que esté relacionada con él. Compile, pruebe la función, presione y emita una solicitud de extracción. Cuanto menos entremezclados estén los cambios de código, más fácil será hacerlo. Si él estaba pirateando un solo método para todos ellos, bueno, diviértanse. Él no lo hará de nuevo.

Aquí hay una solución simple.

Realice un seguimiento de las características que esta persona ha implementado y vaya a cada confirmación en esa rama que se actualizó por característica. Toma esta confirmación y combínala con el repositorio maestro.

Permítame desglosar esto en la forma de un ejemplo.

  

Sea: la rama A es la rama del maestro        Rama A + = Rama A + nueva característica 1        Rama A ++ = Rama A + nueva característica 2        y así sucesivamente

     

Lo que debes hacer es volver a: Branch A +

     

Toma la rama A + y combínala con la maestra.

     

Ahora ve a la Rama A ++ y fusiona con (Master + Rama A +).

     

Repita hasta que haya alcanzado la Rama final A + ... + que sea estable.

Este método puede parecer contrario a la intuición al principio, pero si combina cada característica nueva por separado con el maestro, resulta fácil alternar entre la rama maestra " por característica agregada "

  

¿De qué manera podemos evitar que las sucursales obtengan un gran número de confirmaciones fuera del maestro en el futuro?

Creo que mi solución anterior indica qué método futuro deberías adoptar. Vaya con un método por función o por tarea para cada rama.

Sugeriría utilizar un enfoque de:

maestro principal y maestro

master: final / nivel de producción. Se modifica no a menudo. Se considera siempre estable

pre-master: el área donde se agrega una nueva característica al código existente. Se ha probado exhaustivamente para trabajar con la base de código existente, y es el lugar donde otras sucursales pueden bifurcarse para la implementación de nuevas características.

También deberías intentar agrupar funciones y apuntar a la orientación por versión.

Orientación por versión: especifique un número arbitrario que actuará como el marcador de posición para la rama maestra. "En V1.0.0, desearemos alcanzar las características X, Y, Z. V1.0.0 también tendrá todas estas funcionalidades disponibles: ..."

Al mantener una versión en contra del maestro, también puede ser una forma de mantener el "maestro" estable y listo para la producción en todo momento.

Solucionar el problema de la solicitud de extracción grande es una cosa, y hay algunas buenas respuestas al respecto. Pero en lo que respecta a tratar con sucursales que están muy desactualizadas, es posible que desee revisar sus procesos para tratar con el trabajo en equipo.

Si está trabajando dentro de un marco Agile o SCRUM, el equipo debería preguntarse por qué la función no se completó y fusionó como parte de la iteración / sprint. Si era "demasiado grande" para encajar dentro de una iteración, debería haberse dividido en partes más pequeñas.

También plantea la cuestión de la propiedad del código: dentro de su equipo, ¿los desarrolladores individuales son los únicos que tienen su propio trabajo por separado o todo el equipo trabaja en conjunto para garantizar que se hayan completado los elementos?

Por supuesto, lo anterior supone que su equipo está dentro de algún tipo de estructura de la empresa. Si este es un proyecto de código abierto con colaboradores voluntarios, esa es otra historia. En general, tales proyectos tienen un control más flexible sobre los flujos de trabajo, pero la responsabilidad de generar solicitudes de extracción aceptables recae más a menudo en los contribuyentes individuales.

En muchos sentidos, esto se convierte en una pregunta de proceso. Tal vez su proceso necesario incluya la verificación periódica (¿semanal? ¿Mensual?) Para sucursales de larga duración sin combinar. Algunas herramientas hacen que esto sea fácil de verificar visualmente; p.ej. en github, visite el enlace "sucursales" y muestra qué tan adelante / detrás está cada rama.