Flujo de trabajo de Git / Despliegue

Soy nuevo en Git y trato de mover mi website de SVN a GIT para el control de versiones y también la implementación.

Tengo un número de desarrolladores que trabajarán en su máquina local y tengo 3 serveres, 'desarrollo', 'assembly' y 'producción'.

He estado leyendo libros y viendo videos de cómo funciona Git, así que creo que estoy bastante familiarizado con él ahora como al agregar, comprometerme, etc., sin embargo, necesito asesoramiento sobre el flujo de trabajo y la implementación.

Lo primero que necesito saber es dónde inicializar el repository de GIT. ¿Tiene que estar en el server de 'producción' y luego lo clono en 'puesta en escena' y 'desarrollo' y cada desarrollador también lo clona en su máquina local?

En segundo lugar, ¿cada server debe tener su propia sucursal? Es decir, 'desarrollo' tendrá una twig de 'desarrollo', 'puesta en escena' tendrá una twig 'de transición' y 'producción' tendrá una twig de 'producción'.

Gracias

Recientemente cambié mi equipo de SVN a Git y tenemos la misma configuration de 3 serveres, prod, stg y dev ..

Para el process de migration , primero sudo apt-get install git-svn y luego …

 $ git svn clone [subversion_repository_url] /path/to/git/repository $ cd /path/to/git/repository $ git remote add origin [gir_repo_url] $ git push origin master 

Para Workflow ,

Este enlace titulado " Un exitoso model de ramificación de Git " fue inmensamente útil. Implica cómo utilizar un tipo de flujo de trabajo de 'Producción – En etapas – Dev ' para un equipo.

Con respecto al Despliegue :

En cada uno de los serveres, lo que hacemos es: cada uno de los serveres tiene el git repo en algún lugar del sistema de files. Para implementar, archive la twig respectiva que necesito implementar y descomprimirla en la carpeta / srv / www /.

Por ejemplo, en Prod , para implementar la twig principal ,

 sudo git archive --format zip --output output.zip master -0 

^ El 'maestro' indica la twig que desea cerrar. Esto excluye la carpeta .git. Y luego para descomprimir dentro de la carpeta / srv / www /, sudo unzip output.zip -d /srv/www/app/ Esto es el equivalente de un command svn export .

Para el server de ensayo usualmente comprobamos una de las twigs de lanzamiento o las twigs Dev .

Y para el server Dev , compramos cualquier twig de function en la que necesitemos realizar testings.

Aquí tienes 3 preguntas: cómo implementar, cómo estructurar twigs y cómo estructurar / alojar repositorys.

¿Cómo estructurar las twigs?

Puedes comenzar simple. Ya tienes un repository SVN, así que si tienes un tronco y twigs, puedes configurarlas en git. Si eso no funciona para usted, cámbielo solo cuando lo encuentre necesario.

Si quieres algo más avanzado, mira git flow . Otro buen flujo de trabajo es el que usa github . Está diseñado para ser más simple que el flujo de git.

¿Cómo puedo alojar el repository?

Una manera fácil sería hacer exactamente lo que estás haciendo con SVN. Tener un repository central en un server central. Todo el mundo empuja y tira hacia y desde ese server central. Otra opción sería proporcionarle a algún desarrollador principal el repository "oficial", donde esa ventaja generaría otros cambios de los desarrolladores contribuyentes a medida que cumplen con la aprobación del líder. Hay varias forms en que podrías hacer esto. Tendría que decidir qué funciona mejor para usted.

¿Cómo despliego?

Nuevamente, esto no necesita cambiar de su flujo de trabajo SVN tampoco. Probablemente estés haciendo una svn update desde cada casilla. Me gustaría hacer un git pull a cada caja y mantener todo lo demás muy parecido.

Mucho depende de lo que termine siendo adecuado para ti.

El model de bifurcación vinculado en otra respuesta aquí es un muy buen punto de partida.

En general, tendrá una twig master que representa el código liberado.

La puesta en escena depende de lo que quiera representar: nuestro equipo tiene una twig separada llamada staging que es utilizada por la creación provisional del server de continuous integration. Diferentes características se pueden fusionar en esta twig para probarlas en etapas.

La implementación dependerá de si usa CI o implementa directamente desde una sucursal en el repository.

Desarrollé mi propia estrategia Originalmente se basó en nvie's:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Permite mezclar y combinar ad hoc las características completadas. La piedra angular de esta estrategia es comenzar cada característica desde el mismo lugar en la historia por iteración.