¿Corregir el flujo de trabajo de Git para la rama de funciones compartidas?

Question

Estoy tratando de averiguar el flujo de trabajo adecuado para esta situación:

En el repositorio compartido, tenemos estas ramas:

-master 
-feature 

El función rama es un compartían rama, ya que muchos los desarrolladores están trabajando en una nueva característica juntos. Están impulsando activamente sus cambios a la rama de características.

que estoy tratando de evitar el 'infierno conflicto' para el día que función finalmente consigue incluido de nuevo en maestro. Actualmente, veo algunas opciones:

1) fusionar activamente maestro en función , y hacerlo a menudo. Sin embargo, esto no se recomienda en los documentos de Git, y estoy empezando a ver por qué. Cuando intento esto, parece que soluciono los mismos conflictos una y otra vez.

2) Use rebase de alguna manera. He leído sobre esto, pero parece que no funcionará ya que la función 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) Girar la función se ramifican en una rama de la integración, y tienen los desarrolladores utilizar sus propias ramas de características independientes con cambio de base para mantener las cosas en su sano juicio.

4) ¿Algo completamente diferente?

Answer 1

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

• la solución de cualquier conflicto de combinación a nivel local (en su propio repo)
• hacer la fusión final (a partir de su rama private-feature) trivial (normalmente avance rápido)

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

La idea es que, una vez feature rama ha de ser fusionado en master, no más contribución es aceptado en feature (la rama está "congelada"), y se puede reajustar de forma segura en la parte superior de master primero, o fusionarla directamente al master.
Y entonces se inicia un nuevo feature rama (que en realidad puede comenzar en paralelo de la feature rama anterior si es necesario)

Answer 2

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

Answer 3

(no estoy demasiado interesado en las opciones 1, 2 o 3, así que estoy tratando de encontrar un mejor flujo de trabajo, por lo que estoy describiendo a continuación cómo estoy pensando en abordar el problema con la esperanza de que alguien va a aconsejarme)

1. Girar la rama de la característica en una cola de parches usando uno de la cola de parche git herramientas.
2. Utilice un repositorio de git separado para controlar la versión de la cola de parches
3. Utilice los enfoques de git habituales para colaborar en la cola de parches.

Podría ser sensato para las personas volver a convertir la cola de parches en una rama de características localmente.

Answer 4

Git de flujo de trabajo para la rama de la característica

El proceso es el siguiente: -

primera vez:

git pull 
git checkout -b sprint-4 
git pull origin sprint-4 

• los comandos anteriores se p ull todos los archivos de git

• Haremos una rama con el nombre sprint-4 en nuestra máquina local.

• Extraeremos los archivos del servidor a nuestra rama sprint-4.

Por 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 

• crear una rama remota para esta rama local en el servidor.
• Empujará los archivos de nuestra sucursal local a una sucursal remota.

diario: (en su rama de la característica)

git pull 
git merge dev 

• resolver los conflictos en su caso

• hacer su trabajo para el día

  git push origin

de características es completa:

git pull 
git merge dev 

resolver los conflictos en su caso

git checkout dev 
git merge <feature-branch> 
git push origin dev 

• Los comandos anteriores se fusionarán archivos de rama principal en nuestra rama de la característica .
• Resolver conflictos en nuestra rama de características, si corresponde.
• Fusiona los archivos desde la rama de características a la rama principal.