Git tira con rebase causando conflictos excesivos. ¿Cómo puedo arreglar nuestro flujo de trabajo?

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

El objective es tener la capacidad de agregar correcciones de errores / características a la base, que se pueden propagar a los clientes, a pedido.

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

  • Hacer commits / topic branches para las correcciones / características base: (en base, maestro) git commit -m "Fix admin typo"
  • Combine 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 combinación al origen del cliente: (en el cliente, maestro) git push origin master
  • Nuestra convención ha sido tirar con rebase (para mantener el historial legible). Entonces, un desarrollador diferente trabajando en el proyecto del cliente (en el cliente, maestro) git pull --rebase origin master

Es en este punto que alcanzamos problemas significativos con ese pull / 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 loggings 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.

Déjame aclarar esto en tus repositorys:

  1. el proyecto principal está separado, llamado base
  2. cada proyecto de cliente se clona desde la base , solo se obtienen actualizaciones
  3. los desarrolladores trabajan desde el público repo client_foo , y push / pull a / desde ese

El flujo de trabajo está fallando porque un desarrollador está client_foo twig client_foo en las nuevas confirmaciones desde el repository base y volviendo a client_foo . Esto terminará rompiendo todos los otros 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 repository de clientes, entonces tal vez eso funcionaría. Supongo que ese no es el caso.

Opciones:

  1. Continúa haciendo lo que estás haciendo, pero cuando el client_foo twig client_foo (con la nueva base confirma) al repository client_foo público, todos los demás tienen que hacer un reset --hard en origin/master . Si conservan todos sus cambios no publicados en una twig privada de temas, entonces rebase volver a establecerlos en el nuevo client_foo/master .

  2. Haga que su desarrollador merge cambios 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 get la larga list de conflictos que tienes ahora.

  3. Haga que su desarrollador cherrypick los cambios de base en client_foo . Esto mantiene su historial lineal, pero git ya no cherrypick los commit de cherrypick vinieron de la base . Tendrás que encontrar otra forma de rastrearlo.

Yo diría que sigan con el n. ° 2 ya que se supone 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.