Usando git-flow en una implementación de múltiples etapas

Dibujando un espacio en blanco con la finalización de mi esquema de implementación aquí. Después de publicar esta pregunta: Migrando un sitio de producción sin VCS a Git , tengo la esencia de implementarlo en un repository local.

Mi server de desarrollo local tiene un repository git-flow en el que puedo enviar y actualizará un tree de trabajo externo.

Tengo mi repository configurado con git-flow y así es como se ve mi control remoto de origen:

$ git remote show origin * remote origin Fetch URL: ssh://user@host/var/git/dev/repo.git Push URL: ssh://user@host/var/git/dev/repo.git HEAD branch (remote HEAD is ambiguous, may be one of the following): develop master Remote branches: develop tracked master tracked Local branch configunetworking for 'git pull': master merges with remote master Local refs configunetworking for 'git push': develop pushes to develop (up to date) master pushes to master (up to date) 

Lo que intenté hacer fue configurar 2 pseudoambientes. Uno para la puesta en escena y otro para la producción. Quiero que se comporten de la siguiente manera:

 git push staging #pushes to remote staging repo with a post-receive hook "git checkout develop -f" git push production #pushes to remote production repo with a post-receive hook "git checkout master -f" 

De esta forma, podemos desarrollarnos localmente e impulsar nuestro pequeño server de desarrollo interno y tener toda la historia. Luego, cuando estamos claros para la puesta en escena / producción, simplemente sacamos las twigs apropiadas.

Traté de crear repos sin formatting con treees de trabajo independientes como lo hice con el server de desarrollo (ver mi enlace al comienzo de la publicación), y simplemente lo hice:

 git push staging develop git push production master 

Y aquí están los controles remotos, respectivamente:

 $ git remote show staging * remote staging Fetch URL: ssh://user@host/var/git/dev/staging.git Push URL: ssh://user@host/var/git/dev/staging.git HEAD branch: develop Remote branch: develop tracked Local ref configunetworking for 'git push': develop pushes to develop (up to date) $ git remote show production * remote produdction Fetch URL: ssh://user@host/var/git/dev/production.git Push URL: ssh://user@host/var/git/dev/production.git HEAD branch: master Remote branch: master tracked Local ref configunetworking for 'git push': master pushes to master (up to date) 

Entonces, en teoría, podemos usar git-flow internamente, rastrear la twig de desarrollo e impulsarla para que otros departamentos puedan ver / QA. Luego podemos hacer nuestro lanzamiento interno, y empujar los cambios a la puesta en escena y luego simplemente empujar la twig principal a la producción.

Supongo que mi pregunta es: ¿voy por esto de la manera correcta? Soy un verdadero novato cuando se trata de git y git-flow. He estudiado minuciosamente todos los resources disponibles y esto es lo mejor que pude llegar hasta ahora.

Cualquier idea de personas que usan git-flow en implementación de varias etapas sería muy apreciada.

Esto es lo que terminé haciendo, esta es una pequeña variación de lo que propuse anteriormente y se deriva de otra pregunta que publiqué aquí: Implementar git branches

Un gancho post-recepción para gobernarlos a todos.

El gancho de recepción de correos mira el refname:

Si el refname = "refs / heads / master" (presionando para masterizar la twig):

 echo "Updating production document root..." GIT_WORK_TREE=/data/hosts/production/web/ git checkout -f master echo "Production document root updated" 

Luego uso el gancho de correo electrónico posterior a la recepción que viene con git para enviar un pequeño correo electrónico sobre la confirmación. Actualmente desarrollamos una API para nuestro rastreador de problemas para poder cerrar problemas con commits, etc.

Lo mismo ocurre cuando refname = "ref / heads / develop" (presionando para desarrollar):

Puntos extra

3 twigs: producción, desarrollo (puesta en escena) y una twig de seguimiento de problemas para proyectos pequeños. Sin embargo, a veces tenemos proyectos más grandes que requieren un desarrollo a largo ploop y no pueden interferir en el desarrollo diario.

Puede modificar el gancho post-recepción para search refs / heads /(.*?), Que se dispararía si hiciera algo como git push -u loco-experimental-twig de largo ploop

Esto nos permite crear una twig de proyecto a largo ploop, uploadla con -u y tener un subdominio configurado automáticamente en crazy-experimental-long-term-branch.site.com con algunos scripts simples.

Se produce un desarrollo diario, la resolución de problemas rueda y se ilumina en verde (con fusiones progtwigdas semanales para la producción), y las ramificaciones experimentales a largo ploop se pueden fusionar cuando están lists.

Estoy seguro de que estoy ofendiendo la sensibilidad de los Git Gods con esta estrategia de implementación, pero hemos implementado con éxito una aplicación a gran escala con este método durante aproximadamente 5 meses y, aparte del conflicto de fusión ocasional, no hemos tenido ninguna cuestiones.

Espero que esto sea útil.

Si solo desea implementar el maestro, puede usar el siguiente fragment:

 read oldrev newrev refname branch=$(git rev-parse --symbolic --abbrev-ref $refname) if [ "$branch" = "master" ]; then echo "Deploying new master" GIT_WORK_TREE="$DEPLOYDIR" git checkout -f master echo "Finished." else echo " No commit to master. Deploying nothing." fi