estrategia de trabajo de GIT - muchas características, comunicados muy frecuentes

Question

aquí está la descripción de mi trabajo diario:

Dos desarrolladores que trabajan en muchas pequeñas características o correcciones, digamos 3-4 por día para cada desarrollador. que necesito para ser capaz de trabajar en las características A - B - C, al mismo tiempo, mientras mi compañero de trabajo trabaja en función D y E.

Lunes: la función A es empujado a un servidor de ensayo para la revisión del cliente . La característica B se envía al mismo servidor de ensayo para la revisión del cliente. La característica D se envía al mismo servidor de ensayo para la revisión del cliente.

Martes: Recibimos la aprobación del cliente para A y D (pero no para B). Y necesitan ir a vivir con esos cambios de inmediato.

Miércoles: La característica C se envía al mismo servidor de etapas para la revisión del cliente. La aprobación para B finalmente se recibe.

Jueves: La característica B tiene que pasar a producción inmediatamente.

Viernes: Se ha detectado un error en la última versión de producción y tenemos que volver a la versión anterior.

Esto no se puede tratar como un proceso de Scrum porque no hay posibilidad de agrupar funciones en Stories o en la planificación de sprints. Esto es más como un proceso de mantenimiento (¿quizás Kanban?).

¿Puedes dar un ejemplo de cómo manejarías esto usando Git? Supongamos que en este momento, tenemos solo una rama principal y cada vez que queremos impulsar cualquier cosa a la puesta en escena o la producción, tenemos que "git pull" haciendo todos los cambios en vivo (incluso los no deseados). ¿Qué pasa con git "cherry-pick" para recuperar compromisos específicos? Una rama por función parece demasiado onerosa ya que tenemos muchas funciones. Si pudieras dar ejemplos específicos de comandos y ramas de Git (solo para mostrar la idea principal, no es necesario que sean 100% correctos) eso sería genial.

Gracias.

Answer 1

finalmente eligió la siguiente manera de manejar esto: repositorio remoto

• Un Maestro.
• Una sucursal local en la organización.

• Una sucursal local en la producción.

  git checkout -b staging #on staging server
git checkout -b production #on production server

programador Una tiene que trabajar en un rasgo/patch A:

#local development box 
git checkout master 
git checkout -b issue-A 
#work on the feature 
git push origin issue-A 
#log in to the staging server 
git checkout staging 
git pull origin issue-A #merge with the staging branch, changes are live on staging. 

Lo mismo vale para el programador B a trabajar en función B.

Going vivo en producción:

#log in to the production server. 
git checkout production 
git pull origin issue-A #merge with the production local branch, changes are live on production. 

Además, la rama de la producción local puede ser empujado a dominar cuando los cambios son en vivo y aprobado:

git add <files> 
git commit <commit info> 
git push origin master 

Esto es lo que funcionó mejor en nuestra situación, espero que ayude a alguien.

Answer 2

Hemos utilizado git flow para escenarios como estos.

Dado que gitflow le permite crear múltiples funciones y solo enviar las que desea a través del desarrollo y las ramas maestras, debe seguir perfectamente sus requisitos.

aquí están algunos enlaces para git-flow:

https://github.com/nvie/gitflow/ http://yakiloo.com/getting-started-git-flow/

Answer 3

he adaptado git-flow a esto: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

la gran diferencia es que usted inicia todas las funciones desde el mismo comienzo para un sprint/itteration.

Answer 4

Según lo que ha descrito, adoptaría la estrategia de una rama de lanzamiento y muchas ramas de trabajo.

Significado: Es necesario configurar el servidor de transición a tirar solamente de la rama staging mientras usted y sus compañeros de trabajo están trabajando en sus propias ramas de opción (A, B, C y tal vez maestro)

Siempre un cambio tiene que activarse, simplemente fusiona la función en la rama staging y la envía al servidor; el entorno intermedio transfiere esa rama y la implementa.

Una vez que tenga la autorización de su cliente a continuación, puede empujar la rama de la característica (que ya fue combinado en staging en otra rama (tal vez stable) e implementar dicha producción.

Una vez en la producción que pueda eliminar la rama de la característica y empezar de nuevo ..

TLDR: tratar a cada uno de sus ambientes como una rama que sólo es empujado a una característica cuando tiene que ir allí esa manera usted puede incluso revertir los cambios de ramas/ambientes. que se supone que no deben ir allí.

E iría con un enfoque Kanban, más fácil y para lo que pareces estar haciendo más adecuado.