Git Development Strategy for Small Team

Question

Tenemos un pequeño equipo digital (3 diseñadores, 3 desarrolladores) y estamos buscando integrar Git en nuestro sistema.

Por el momento, para la mayoría de nuestros sitios tenemos un sitio de ensayo (dev.example.com) y un sitio de producción (ejemplo.com). Nuestros desarrolladores generalmente hacen cambios de código en una versión local, mueven esos cambios al sitio de ensayo y luego, una vez aprobados, esos cambios se trasladan en vivo. Nuestros diseñadores, por otro lado, realizan pequeñas ediciones (cuando los desarrolladores están demasiado ocupados) directamente en el sitio de ensayo y luego publican en vivo una vez que se aprueban. Además, en algunos casos, no tenemos un sitio intermedio y las ediciones se envían directamente al sitio de producción.

Sé que los diferentes flujos de trabajo no son ideales, pero ¿cuál sería la mejor manera de integrar Git en este sistema actual y mantener el flujo de trabajo bastante simple (por el bien de los diseñadores)? ¿Debería estandarizarse nuestro flujo de trabajo actual antes de incorporar Git (es decir, los sitios de ensayo son obligatorios y los diseñadores deben desarrollarse localmente antes de pasar a la puesta en escena) o Git es lo suficientemente flexible como para trabajar como está?

Soy bastante nuevo en Git pero he leído que solo se debe realizar un envío a un repositorio simple. ¿Es esto necesario? Si es así, ¿podría ser este el sitio de ensayo? ¿O debería ser su propia entidad (es decir, en un servidor interno como example.local)?

¿Sería un buen flujo de trabajo sea como tal: obtiene

1. usuario y se funde repositorio desnudo en el repositorio local.
2. El usuario desarrolla localmente y confirma cambios en el repositorio local. empuja
3. de usuario cambia al repositorio desnudo en example.local (o algo similar)
4. usuario tira de cambios desde el repositorio desnudo a la organización de repositorio dev.example.com
5. Una vez aprobada, el usuario tira de cambios desde el repositorio desnudo a repositorio de producción example.com

Mi único problema con este flujo de trabajo es que el repositorio desnudo parece innecesario ... ¿no? Y finalmente, entiendo lo que se registraría en el repositorio local (los cambios de los usuarios, confirmaciones, etc.), pero no estoy seguro de qué se registraría en el repositorio vacío (después de los empujes), la puesta en escena (después de la extracción)) y la producción (después del tirón); ¿Podrían rastrearse y registrarse fácilmente todos los pasos anteriores?

¡Gracias por todos los consejos/respuestas!

Answer 1

aquí es una interestion flujo de trabajo git: http://nvie.com/posts/a-successful-git-branching-model/

si sus desarrolladores y diseñadores no están familiarizados con la interfase de línea de comandos, utilice una envoltura GUI Git, hay varios: gitx, gitbox, git tower, sólo les Google para obtener sus sitios. encuentre una herramienta o herramientas con las que su equipo se sienta cómodo.

el mejor flujo de trabajo es el que satisface las necesidades de su equipo, y puede cambiar con el tiempo.

Answer 2

es Git lo suficientemente flexible como para trabajar como está?

Mucho.

De la manera en que solía hacerlo, deje que los diseñadores trabajen en la rama design o algo similar y siempre tenga un solo comando para presionar.

El desarrollador combina el contenido de la rama de diseño cada vez que actualiza el servidor. De hecho, merge será un comando en el script de despliegue automático.

Para escenificar los cambios de diseño solamente y no los cambios de desarrollo, siempre puede cambiar la bifurcación en la transición a la rama de diseño. Para esto, puede proporcionarle al diseñador una secuencia de comandos de implementación que impulse los últimos cambios, cambie a la rama de diseño.

Dicho esto, anime a los diseñadores a usar git, lenta y gradualmente. En primer lugar, enganche al comando stash. Y tirar. Luego, pídales que creen diferentes ramas.

En cuanto al repositorio simple, es una forma estándar de mantener a todas las personas sincronizadas y no hay ninguna razón técnica para tener realmente ese extra. Excepto que la mayoría de la gente usa el github o un servicio de respaldo remoto equivalente que tiene una buena interfaz de usuario web para comunicarse y coordinarse, que de hecho se convierte en el repositorio principal.

Answer 3

No veo la razón para usar un repositorio vacío tampoco. Escribí una breve publicación sobre un proceso simple de desarrollador: A simple developer process with Git

Este no es exactamente su caso, pero es una solución más general. La idea de usar ramas de características es permitir a las personas llevar sus cambios al repositorio principal sin estropear el trabajo de todos los demás y facilitar la fusión de los cambios de otras personas.

Si hiciera esto, esto es lo que haría:

1. Instalar Gitorious. No es necesario, pero ayuda a realizar un seguimiento de las cosas,
2. Cree su repositorio de producción en Gitorious.
3. Agregue un anzuelo al repositorio de producción que, cuando se reciben las actualizaciones, actualiza automáticamente el servidor de producción (tal vez se demore hasta la próxima noche, lo que más le convenga).
4. Crear un repositorio de desarrollo en Gitorious.
5. Agregue un anzuelo similar al repositorio de desarrollo que actualiza el servidor de desarrollo.

Esta configuración tiene muchas ventajas:

• Los desarrolladores no tienen que preocuparse por la actualización del sitio. Todo lo que necesitan hacer es presionar para dev repo.
• La actualización del servidor de producción después de pasar las pruebas es muy simple, basta con un simple push (el repositorio de producción nunca se actualiza desde otro lugar que no sea el servidor de desarrollo). Incluso podría agregar una sección al anzuelo que hace esto si se empuja una etiqueta. De modo que podría marcar la versión liberable con un número de versión con una etiqueta y esto actualizaría automáticamente el servidor de producción.
• Hay muchos menos puntos en los que alguien puede estropear algo ("Vaya, quise empujar a dev, pero en lugar de eso presioné para pinchar").