Git pull con rebase que causa conflictos excesivos. ¿Cómo puedo arreglar nuestro flujo de trabajo?

Question

Tenemos un sistema base personalizado para cada cliente. La base vive en su propio repositorio, y cada cliente vive en su propio repositorio (originalmente clonado desde la base).

El objetivo es tener la capacidad de agregar correcciones de errores/funciones a la base, que se pueden propagar a los clientes, a pedido.

Hasta ahora, el flujo de trabajo ha sido la siguiente:

• Hacer comete/ramas puntuales para las correcciones de base/características: (en la base, maestro) git commit -m "Fix admin typo"
• Combinar esos cambios en el cliente: (en el cliente, maestro) git merge base/master. Obviamente, esto incluye solucionar cualquier conflicto entre la base y las personalizaciones del cliente.
• Empuje la fusión con el origen del cliente: (en el cliente, maestro) git push origin master
• Nuestra convención ha sido para tirar usando rebase (para mantener la historia legible). Por lo tanto, a continuación, un desarrollador diferente a trabajar en el proyecto de cliente haría (en el cliente, maestro) git pull --rebase origin master

Es en este punto que llegamos a problemas importantes con la tracción/rebase. Los desarrolladores obtienen conflictos en la extracción/rebase después de una fusión desde la base al cliente. Y no son solo algunos conflictos, son muchos (¿muchas de las confirmaciones se reproducen?) Y, a menudo, el código que un desarrollador en particular nunca tocó. Creo que esto es irracional e insostenible.

¿Cuál es la mejor solución aquí?

Mi único pensamiento es dejar de usar rebase al tirar y lidiar con registros descuidados y difíciles de leer, pero prefiero no tener que hacer esto. Estos proyectos de clientes pueden durar años y me gustaría poder seguir teniendo sentido con las fusiones del sistema base en el futuro.

Answer 1

A ver si lo recto en sus repositorios:

1. el proyecto principal está separado, llamados base
2. cada proyecto cliente se clona a partir base, actualizaciones sólo tirando
3. los desarrolladores trabajar desde el público client_foo repo, y push/pull a/desde que

El flujo de trabajo está fallando sea porque un desarrollador está reescribiendo client_foo rama en las nuevas confirmaciones desde el repositorio base y volviendo al client_foo. Esto terminará rompiendo todos los demás desarrolladores usando client_foo cuando intentan hacer su siguiente extracción. Entonces no puedes hacer eso, y esperar que git lo maneje automáticamente.

Si solo hubiera un desarrollador por repositorio de clientes, entonces quizás eso funcionaría. Supongo que ese no es el caso.

Opciones:

1. seguir haciendo lo que estás haciendo, pero cuando el dev empuja el porcentualizada client_foo rama (con los nuevos base commit) de nuevo a la client_foo repo pública, todos los demás tienen que hacer un reset --hard en origin/master. Si conservan todos sus cambios no utilizados en una rama de tema privada, entonces tienen que volver a rebase en el nuevo client_foo/master.

2. Cambie el dev merge de base a client_foo. Esto le dará un compromiso de fusión en client_foo que dijo que está tratando de evitar, pero le dará la historia más precisa. Cuando tus desarrolladores hacen un 'pull --rebase', ya no deberías obtener la larga lista de conflictos que tienes ahora.

3. Tiene su dev cherrypick los cambios de base en client_foo. Esto mantiene su historial lineal, pero git ya no registrará que el cherrypick 'd commits provino del base. Tendrás que encontrar otra forma de rastrearlo.

Yo diría que quedarse con el n. ° 2 ya que esa es la forma en que se supone que git funciona. Sin embargo, alguien más puede pensar en una mejor solución no obvia.