¿Corregir el flujo de trabajo de Git para la twig de características compartidas?

Estoy tratando de descubrir el flujo de trabajo correcto para esta situación:

En el repository compartido, tenemos estas twigs:

-master -feature 

La twig de características es una twig compartida , ya que muchos desarrolladores están trabajando juntos en una nueva característica. Están impulsando activamente sus cambios a la twig de características.

Estoy tratando de evitar el "infierno del conflicto" para el día en que la function finalmente se fusione de nuevo en el maestro . Actualmente, veo algunas opciones:

1) Combine activamente el maestro en la function y hágalo a menudo. Sin embargo, esto no se recomienda en los documentos de Git, y estoy empezando a ver por qué. Cuando bash esto, parece que soluciono los mismos conflictos una y otra vez.

2) Usa rebase de alguna manera. He leído sobre esto, pero parece que no funcionará ya que la twig de características en realidad se comparte. Todo lo que se necesita es un desarrollador para hacer 2 rebases, y otros desarrolladores podrían tener conflictos de historial no coincidente.

3) Convierta la twig de características en una twig de integración, y haga que los desarrolladores usen sus propias twigs de características independientes con rebase para mantener la cordura.

4) ¿Algo completamente diferente?

Para una sucursal compartida, me gustaría ir con el n. ° 3 y usarlo como una twig de "integración" para consolidar su trabajo.
Los desarrolladores tendrían que usar rebase para reproducir constantemente su twig private en la parte superior de la feature antes de volver a fusionar su trabajo en feature , de esa manera son:

  • resolver cualquier conflicto de fusión localmente (en su propio repository)
  • hacer que la fusión final (desde su twig private a la feature ) sea trivial (normalmente avance rápido)

(como se describe en la respuesta " git rebase vs. merge " )

La idea es que, una vez que la twig de entidades se haya fusionado en el master , no se acepte más contribución en la feature (la twig esté "congelada"), y se puede volver a establecer de forma segura sobre el master primero, o combinarlo directamente al master .
Y luego comienza una nueva twig de feature (que en realidad puede comenzar en paralelo a la twig de feature anterior si es necesario)

Puede usar rerere para manejar los conflictos de fusión que está viendo muchas veces.

(No estoy muy interesado en las opciones 1, 2 o 3, así que estoy tratando de encontrar un mejor flujo de trabajo; por lo tanto, estoy describiendo a continuación cómo estoy pensando en abordar el problema con la esperanza de que alguien me aconseje)

  1. Convierta la twig de características en una queue de parches utilizando una de las herramientas de queue de parches de git.
  2. Utilice un repository de git separado para controlar la versión de la queue de parches
  3. Use los enfoques habituales de git para queueborar en la queue de parches.

Puede ser conveniente que las personas vuelvan a convertir la queue de parches en una twig de características localmente.

Git Workflow para la twig de funciones

El process es el siguiente:

Primera vez:

 git pull git checkout -b sprint-4 git pull origin sprint-4 
  • Los commands anteriores extraerán todos los files de git

  • Hará una sucursal con el nombre sprint-4 en nuestra máquina local.

  • Tomaremos los files del server a nuestra twig sprint-4.

Para cada nueva característica:

 git checkout -b <feature-branch>, example: git checkout -n fer-181 git push -u origin <local-branch>:<remote-branch>, example git push -u origin fer-181:fer-181 
  • Cree una sucursal remota para esta sucursal local en el server.
  • Empujará los files desde nuestra sucursal local a una sucursal remota.

Diario: (en su twig de características)

 git pull git merge dev 
  • resolver conflictos si los hay
  • haz tu trabajo por el día

    git push origen

La function está completa:

 git pull git merge dev 

resolver conflictos si los hay

 git checkout dev git merge <feature-branch> git push origin dev 
  • Los commands anteriores fusionarán los files de la twig principal en nuestra twig de características.
  • Resuelva conflictos en nuestra twig de características, si corresponde.
  • Fusiona los files de la twig de características a la twig principal.