Esquema de flujo de trabajo de git adecuado con varios desarrolladores que trabajan en la misma tarea

Tenemos un repositorio principal y cada desarrollador tiene una bifurcación de eso.

Se crea una rama principal/some_project, luego se crea el mismo nombre de rama en la bifurcación de cada desarrollador, fork/some_project.

(Usamos smartgit y también tenemos una política que los controles remotos se denominan 'principal' y 'fork' en lugar de 'origin' y 'upstream' que solo confunden a los nuevos usuarios).

Cada desarrollador también tiene una rama local llamada some_project.

La rama local de desarrolladores some_project rastrea el principal de la rama remota / some_project.

Los desarrolladores hacen su trabajo local en branch some_project y push-to a su fork/some_project, de vez en cuando crean pull requests, así es como el trabajo de cada desarrollador se fusiona en principal/some_project.

De esta manera los desarrolladores son libres de tirar/rebase localmente y empujar a sus bifurcaciones - este es más o menos el flujo de trabajo de bifurcación estándar. De esta manera obtienen las confirmaciones de otros desarrolladores y de vez en cuando pueden tener para resolver algún conflicto.

Esto está bien y todo lo que se necesita ahora es una forma de fusionar las actualizaciones en curso que aparecen en principal/master (por ejemplo, correcciones urgentes u otros proyectos que se entregan antes de que algo_project finalice).

Para completar esto designamos un 'branch lead' su rol es combinar localmente las actualizaciones de master en some_project usando merge (no pull, rebase) en SmartGit. Esto también puede generar a veces conflictos que deben resolverse. Una vez que esto es hecho que el desarrollador (el líder de la rama) fuerza empuja a su bifurcación/some_project rama luego crea una solicitud de extracción para fusionar en principal/some_project.

Una vez que la solicitud de extracción se fusiona, todas las confirmaciones nuevas que estaban en principal/master ahora están presentes en la rama principal/some_project (y nada se ha rebasado).

Por lo tanto, la próxima vez que cada desarrollador esté en some_project y tire (recuerde, su rama rastreada es principal / some_project) obtendrán todas las actualizaciones que incluirá el material fusionado desde principal / master.

Esto puede sonar largo, pero en realidad es bastante simple y robusto (cada desarrollador también podría fusionarse localmente desde principal/master, pero es más ordenado si una persona hace eso, el resto del equipo vive en un mundo simple al igual que el flujo de trabajo de un solo desarrollador).

Puede que veas Git-flow esto puede ayudarte

Http://nvie.com/posts/a-successful-git-branching-model /

Creo que todavía nadie respondió a la pregunta original de cómo colaborar en ramas temáticas manteniendo un historial limpio.

La respuesta correcta es lo siento, no puedes tener todo eso junto. Solo se puede preparar su historia local privada, después de publicar algo para los demás que debe trabajar en la parte superior de eso.

Lo mejor que podría hacer en su caso particular donde el dev del servidor no se preocupa por los cambios dev del cliente es bifurcar localmente las ramas del cliente desde los dev / feature y rebase esa parte en la parte superior del trabajo del servidor justo antes de terminar la característica, o relaje sus restricciones y cambie a un flujo de trabajo diferente, como lo hizo;)

Que le hará imposible rebase o cambiar commits, que son ya publicado.

Esto depende de tu audiencia. "Server dev" puede enviar la" estructura básica "a Bitbucket para que" client dev " tenga acceso a ella. Sí esto significa potencialmente que otros tendrán acceso a estas confirmaciones "temporales".

Sin Embargo, esto sólo sería un problema si otro usuario ramificada de uno de estos comete antes de eran reajustado. En un proyecto más pequeño / una base de usuarios más pequeña, estas confirmaciones temporales podrían nunca notarse incluso antes de que ocurriera la rebase, por lo tanto, negando el riesgo.

La decisión es tuya si el riesgo de que alguien se ramifique de estas confirmaciones temporales es demasiado grande. Si es así, tal vez necesite crear un segundo repositorio privado de Bitbucket para estos cambios privados. Otra opción sería hacer merge commits en lugar de cambiar la base, pero esto tampoco es ideal.

Déjame decirte lo que hacemos aquí mientras varios desarrolladores trabajan en el mismo proyecto (incluso a veces trabajando en los mismos controladores/modelos/vistas).

En primer lugar, nuestro equipo creó git-project con dos ramas

1. Maestro (es uno protegido, nadie puede empujar aquí excepto el líder del equipo)
2. Desarrollo (todos los desarrolladores pueden presionar aquí)

Nos dijeron que trabajáramos en nuestro entorno local y creáramos commits cada vez que completáramos uno de los asignados tarea(s).

Ahora, a la hora de la tarde (o digamos, a la hora del cierre-partida), hacemos esto:

1. Git Pull

Cada desarrollador que está trabajando en el mismo proyecto Tira de la rama de desarrollo actual a su local (hacer lo mismo en la mañana - cuando se inicia para el día).

Entonces el líder del equipo le dijo al desarrollador que confirmara todos los códigos y los empujara uno por uno seguido de un tirón.

Para ex.

• dev1 crea commit y empuja al servidor
• dev2 tira de nuevo y crea commit y push
• dev3 tira de nuevo y crea commit y push
• y así sucesivamente..

Ahora el problema son los conflictos:

• En algún momento mientras se extrae el código de la rama de desarrollo, git notifica que fusionamos todos los conflictos automáticamente, lo que significa que git aplica automáticamente los nuevos cambios realizados por otro desarrollador
• Pero en algún momento el MISMO git dice que la fusión automática falló y muestra algunos nombres de archivo
• entonces el papel de líder del equipo entra en escena -- lo que hace es : "Revisa todos los archivos listados (durante el proceso fallido de fusión automática) y fusiona los conflictos manualmente y crea commit y push al servidor.

Ahora cómo fusionar manualmente: GIT simplemente actualiza los archivos de conflicto con todos los contenidos como este :

<<< HEAD
New lines from server that you don't have is here shown
=====
Your current changes....
>>> [commit id]

Team-lead actualiza ese archivo después de analizar esto:

 New lines from server that you don't have is here shown
 Your current changes

Y crea commit y push.

Nuevamente en la mañana tiramos (solo para asegurarnos de que no nos perdimos nada del día anterior), Esto así es como trabajamos aquí.

Las reglas para recordar son:

• Tiene 1 master y 1 develop rama
• Tienen ramas de características que aparecen fuera de develop rama
• Cada vez que tenga la versión lista para QA para probar, merge en develop
• Hacer que las ramas de liberación se generen fuera de develop rama
• Hacer correcciones de errores en las ramas de lanzamiento
• Cuando tenga la versión lista para QA para probar, merge en develop
• Cuando tenga la versión lista para PRODUCCIÓN, fusionar en master, y crear una etiqueta para él

El siguiente diagrama es la estrategia de tiro al blanco seguida en equipos de todo el mundo (Crédito: tomado de aquí):