rama - Esquema de flujo de trabajo de git adecuado con múltiples desarrolladores trabajando en la misma tarea

git flujo de trabajo

Question

Soy un líder de equipo en nuestra empresa de desarrollo web y me gustaría implementar el flujo de trabajo de Git en nuestro equipo. Lectura de documentación y artículos He encontrado que la siguiente estructura es buena para nosotros:

Tenemos un repositorio en un Bitbucket. Se considera que la rama principal contiene solo código estable. Cada desarrollador debe crear su propia rama e implementar características / correcciones de errores en su propia rama. Una vez que decide, que su código está listo, crea un buen historial de ramas (usando rebase, modificar, seleccionar cereza, etc.) y lo empuja a Bitbucket, donde crea una solicitud de extracción a la rama maestra. QA verifica la funcionalidad y la aprueba (o la desaprueba), luego verifico el código y, si está bien, fusiono su trabajo en maestro (mediante el avance rápido o el rebase para un mejor historial de confirmaciones).

Pero este esquema es bueno solo en un caso, cuando un desarrollador único trabaja en una sucursal. En nuestro caso, casi siempre tenemos dos desarrolladores para una rama, ya que un desarrollador trabaja en el lado del servidor (PHP) y otro, en el lado del cliente (HTML / CSS / JS). ¿Cómo deberían colaborar estos dos de alguna manera, que la historia de los maestros se mantenga limpia?

El desarrollador de servidores crea la estructura básica de los archivos HTML y el desarrollador del cliente necesita obtener esta estructura. Lógicamente, el desarrollador de servidor crearía una sucursal y el desarrollador de cliente crearía su propia sucursal, en función de la rama de desarrollo del servidor. Pero esto significa que el servidor de desarrollo necesita publicar su bifurcación en Bitbucket, lo que le imposibilitará volver a establecer la base o modificar las confirmaciones , que ya están publicadas.

Otra opción es esperar, hasta que el servidor dev finalice su trabajo, publique una bifurcación con un historial agradable de commits y lo olvide, y solo después de que el cliente dev comience a trabajar en esta rama, pero esto causará retrasos, lo que es aún peor.

¿Cómo manejas esa colaboración en tus flujos de trabajo?

Answer 1

lo que le imposibilitará volver a establecer la base o cambiar los commits, que ya están publicados.

Esto depende de tu audiencia. "Server dev" puede empujar la "estructura básica" a Bitbucket para que el "cliente dev" tenga acceso a ella. Sí, esto significa potencialmente que otros tendrán acceso a estos compromisos "temporales".

Sin embargo, esto solo sería un problema si otro usuario se bifurcaba de una de estas confirmaciones antes de volver a establecerla. En un proyecto más pequeño / una base de usuarios más pequeña, estas confirmaciones temporales podrían no notarse incluso antes de que se produzca la rebase, lo que anula el riesgo.

La decisión es suya si el riesgo de que alguien se diversifique de estos compromisos temporales es demasiado grande. Si es así, entonces quizás necesites crear un segundo repositorio privado de Bitbucket para estos cambios privados. Otra opción sería hacer commit commits en lugar de rebasing, pero esto tampoco es ideal.

Answer 2

Creo que todavía nadie respondió la pregunta original de cómo colaborar en las ramas temáticas manteniendo una historia limpia.

La respuesta correcta es lo siento, no puedes tener todo eso junto . Solo puede preparar su historial local privado, después de publicar algo para otros, debe trabajar además de eso.

Lo mejor que podría hacer en su caso particular donde el desarrollador del servidor no se preocupa por los cambios dev del cliente es bifurcar sucursales de clientes localmente desde desarrolladores / características y volver a establecer la parte del servidor antes de finalizar la función o relajar sus restricciones y cambiar a un flujo de trabajo diferente, como lo hizo;)

Answer 3

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

En primer lugar, nuestro proyecto creado por el equipo git-project con dos ramas

1. Maestro (está protegido, nadie puede presionar 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 compromisos cada vez que completamos una de las tareas asignadas.

Ahora en el horario de la tarde (o decir el horario de cierre - irse), hacemos esto:

1. Git Pull

Cada desarrollador que está trabajando en el mismo proyecto lleva la rama de desarrollo actual a su local (haz lo mismo por la mañana, cuando comienzas por un día).

Luego, el líder del equipo le dijo al desarrollador que debe confirmar todos los códigos y presionar uno por uno seguido de un tirón.

Por ej.

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

Ahora el problema son los conflictos:

• En algún momento, al extraer el código de la rama de desarrollo, git notifica que fusionamos todos los conflictos automáticamente, lo que significa que git aplicó automáticamente los nuevos cambios realizados por otro desarrollador.
• Pero en algún momento el MISMO git dice que la combinación automática falló y muestra algunos nombres de archivos
• luego, la función líder del equipo entra en escena; lo que hace es: "Revisa todos los archivos enumerados (durante el proceso fallido de fusión automática) y fusiona los conflictos manualmente y crea la confirmación y el envío 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 luego 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 no perdernos nada del día anterior), así es como trabajamos aquí.

Answer 4

Es posible que veas Git-flow esto puede ayudarte

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

Answer 5

Las reglas para recordar son:

• Tener 1 master y 1 rama de develop
• Tener ramas de características engendrar fuera de la rama de develop
• Cada vez que tengas la versión lista para QA para probar, únete para develop
• Tienen ramas de liberación engendran de develop rama
• Hacer correcciones de errores en las ramas de lanzamiento
• Cuando tengas la versión lista para QA para probar, únete para develop
• Cuando tengas la versión preparada para PRODUCTION , únete al master y crea una etiqueta para él

El siguiente diagrama es la estrategia de ojo de buey seguida en equipos de todo el mundo (Crédito: tomado de here ):

Answer 6

Realmente no puedo hablar sobre los méritos de los métodos descritos en su publicación, pero puedo describir cómo resolvimos la codificación colaborativa en el flujo de trabajo que usamos en el trabajo.

El flujo de trabajo que usamos es una de muchas ramas. Nuestra estructura es así:

El maestro es dorado; solo el maestro de fusión lo toca (más sobre esto en un momento).

Hay una rama de desarrollo, tomada inicialmente del maestro, que todos los desarrolladores funcionan. En lugar de tener una sucursal por desarrollador, creamos una función o un ticket de las ramas del desarrollador.

Por cada característica discreta (error, mejora, etc.), se crea una nueva rama local a partir de dev. Los desarrolladores no tienen que trabajar en la misma rama, ya que cada rama de características tiene un alcance únicamente en el que está trabajando ese único desarrollador. Aquí es donde la ramificación barata de git es útil.

Una vez que la función está lista, se fusiona localmente en dev y se envía a la nube (Bitbucket, Github, etc.). Todo el mundo se mantiene sincronizado tirando de dev con frecuencia.

Estamos en un programa de lanzamiento semanal, por lo que cada semana, después de que QA haya aprobado la rama de desarrollo, se crea una rama de lanzamiento con la fecha en el nombre. Esa es la rama utilizada en la producción, en reemplazo de la rama de lanzamiento de la semana pasada.

Una vez que la rama de lanzamiento es verificada por QA en producción, la rama de lanzamiento se fusiona nuevamente en master (y dev, solo para estar seguros). Esta es la única vez que tocamos master, asegurándonos de que esté lo más limpio posible.

Esto funciona bien para nosotros con un equipo de 12. Espero que haya sido útil. ¡Buena suerte!

Answer 7

Tenemos un repositorio principal y cada desarrollador tiene un tenedor de eso.

Se crea una rama principal / some_project, se crea el mismo nombre de rama en el tenedor de cada desarrollador, fork / some_project.

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

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

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

Los desarrolladores hacen su trabajo local en la rama some_project y push-to en su fork / some_project, de vez en cuando crean solicitudes de extracción, así es como el trabajo de cada desarrollador se fusiona en principal / some_project.

De esta forma, los desarrolladores son libres de tirar / redimensionar localmente y empujar hacia sus horquillas, este es prácticamente el flujo de trabajo tenedor estándar. De esta forma obtienen compromisos de otros desarrolladores y es posible que de vez en cuando tengan que resolver el conflicto extraño.

Esto está bien y todo lo que se necesita ahora es una forma de combinar las actualizaciones continuas que aparecen en el principal / principal (por ejemplo, correcciones urgentes u otros proyectos que se entregan antes de que termine algún proyecto).

Para lograr esto, designamos un ''líder de sucursal'', su función es fusionar localmente las actualizaciones de master en some_project usando fusion (no pull, rebase) en SmartGit. Esto también puede generar conflictos y estos deben ser resueltos. Una vez hecho esto, la fuerza del desarrollador (el líder de la bifurcación) empuja hacia su bifurcación fork / some_project y luego crea una solicitud de extracción para fusionarse en principal / some_project.

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

Por lo tanto, la próxima vez que cada desarrollador esté en some_project y pulls (recuperación, su rama rastreada es principal / some_project) obtendrán todas las actualizaciones que incluirán las cosas fusionadas de principal / principal.

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