¿Qué procesos de flujo de trabajo en equipo usa con respecto a git?

Question

Estoy en el proceso de mover mi equipo de TFS a GIT en un futuro muy cercano, pero antes de hacerlo quiero saber sobre cualquier error que otros puedan haber experimentado al mover un equipo desde un control de fuente centralizada como CVS , SVN, TFS, etc. a un sistema de control de fuente distribuida como GIT o Mercurial.

Algunas de las preguntas que inmediatamente vinieron cuenta el tiempo son:

1. ¿Cada trabajo del usuario de su propia rama en el servidor y luego fusionar en cuando se hace o no que simplemente se quedan local para sus máquinas y empujar a el servidor cuando haya terminado?

2. ¿Se debe realizar todo el trabajo de desarrollo nuevo en una rama (es decir, "próxima versión") o se debe hacer frente a "maestro"?

3. ¿Debe hacerse un nuevo desarrollo en un clon en el servidor, y luego emitir solicitudes de extracción a la base del código de producción, o es una rama de la base del código de producción lo suficientemente buena?

4. Siga con el número 3, si todo está hecho en una rama, ¿hay alguna manera de controlar quién puede fusionarse en "maestro"?

5. ¿Hay algo más de lo que deba preocuparme por el hecho de que no estoy pensando en eso en su mudanza del control de versión centralizada al control de versión distribuida?

Sin embargo, mi verdadera curiosidad y la pregunta se refiere a cómo gestionar sus procesos de flujo de trabajo en relación con GIT y otros sistemas de control de fuentes distribuidas, no es realmente algo que se adapte a mi proceso de flujo de trabajo actual.

Actualización: la actualidad, el proceso de desarrollo de TFS es que tenemos una carpeta principal y luego una carpeta de rama para el material de nueva versión, y cuando se termina el código de próxima versión se fusionó de nuevo a la carpeta principal . Cada miembro del equipo tiene derechos completos de compromiso para todo el proyecto. No tenemos un proceso sofisticado con ningún esfuerzo imaginativo, hasta ahora hemos utilizado nuestro control de fuente como un simple repositorio.

Sin embargo dicho esto, estoy buscando más de un proceso de flujo de trabajo de situación ideal, realmente no es algo que se adapte a mi flujo de trabajo actual. Es por eso que titulé la pregunta What team workflow processes do __you__ use concerning GIT?

Answer 1

Tenga en cuenta que no he usado Git en una configuración corporativa, y las respuestas a continuación se basan en mi experiencia trabajando en proyectos de OSS con Git, y mi comprensión de Git.

Véase también gitworkflows(7) página de manual.

• ¿Cada trabajo del usuario de su propia rama en el servidor y luego se funden en cuando se hace, ¿O es que simplemente se quedan local para sus máquinas y empuje al servidor cuando se hace?

En cualquier sistema de control de versiones distribuido , y en cualquier DVCS de flujo de trabajo utilizando, cada usuario tiene su propio depósito privado , no desnudo, en la que él o ella DOWS su/su trabajo. La práctica común es que el usuario no publique su trabajo hasta que esté listo.

Publicación el trabajo de uno puede significar presionar a algún repositorio central, o puede significar presionar al propio repositorio público; desde el repositorio público de este desarrollador, el mantenedor (o su equivalente) puede generar cambios.

Echa un vistazo a la descripción (con diagramas) de posibles flujos de trabajo en Chapter 5.1: Distributed Workflows de Pro Git. Proffesional Version Control con licencia CC de Scott Chacon.

• caso de todos los nuevos trabajos de desarrollo se haga en una rama (es decir, "la próxima versión") o debe hacerse en contra de "maestro"?

El flujo de trabajo recomendado (pero ciertamente no es la única posible) es el desarrollo de cada función por separado en la rama separada, llamada ramas de características. Cuando la función se considera lista, se fusiona en 'siguiente' (rama de desarrollo) o en 'principal' (rama estable).

[...]

• ¿Hay algo más que deba preocuparse de que no estoy pensando en eso ocurría en su movimiento de control de versiones centralizado de control de versiones distribuido?

Si tiene grandes y, a menudo cambiando archivos binarios, luego trabajar con el sistema de control de versiones distribuido podría ser más difícil de configurar; entonces el sistema de control de versión centralizada podría ser mejor.

Answer 2

Git formas para su necesidad, y no al revés (como ocurre con los sistemas de control de fuente centralizados).

Si nos dice cómo gestiona su desarrollo y lanzamientos, podemos decirle qué flujo de trabajo en GIT se adaptaría a eso.

Editar: En cuanto a la actualización, puede hacer fácilmente este flujo de trabajo en git. La pregunta es qué más quieres de la herramienta de administración de origen. Hacer un cambio solo porque queremos un cambio no es una muy buena idea.

Answer 3

Desde sus preguntas me siento su forma de pensar sigue siendo el de un sistema de control de versiones centralizado. En un sistema distribuido, el servidor ya no es un "lugar de trabajo", sino un mero espejo del trabajo colectivo. Como tal, ni siquiera es estrictamente necesario.

Por lo general, el repositorio central tiene nada más que la rama master y las etiquetas de liberación. Solo debería reflejar el factor común de todos. Las sucursales en un sistema distribuido son muy privadas, por lo que deben permanecer locales.

En mi trabajo en mi depósito privado que tienen las siguientes ramas:

• master es un reflejo exacto de la master central. Nunca me comprometo con eso. En cambio, solo tiro del espejo central en mi master.
• develop-* son un conjunto de ramas de función (trabajo) que se derivan de la rama release. Por ejemplo, podría tener una rama llamada develop-foo_performance donde ajuste el rendimiento de la clase Foo. O bien, podría tener una rama llamada develop-cosmetics donde acumulo algunos compromisos menores de cosméticos. En su mayoría, son ramas de vida corta para tareas muy específicas. Estas son las ramas del bosquejo; Me comprometo aquí todo el tiempo, escribiendo libremente los mensajes de compromiso y sin pensar un momento en "si este cambio es digno de un compromiso". Son mis errores privados: ocultar el historial de seguimiento de Ctrl-S.
• release es la rama en la que squash confirma que está lista para su publicación. Cuando termine de codificar mi idea específica para la puesta a punto del rendimiento para Foo en la rama develop-foo_performance es probable que tenga un conjunto de compromisos desorganizados, experimentando en varias direcciones. Rebase estas confirmaciones en la rama release, aplastándolas en confirmaciones orientadas a funciones lógicas, a menudo una única confirmación. Esta calabaza descarta todo el código que no terminó en el estado final, por lo que la historia que muestra release es muy clara y lineal; toda la experimentación se ha ido, como si fuera un desarrollador perfecto que pueda ver en el futuro, nunca se equivoca y tiene compromisos increíblemente descriptivos. Al final del día, empujo mi rama release hacia el espejo central y luego tomo el control remoto master y lo combino en mi master.
• napkin es mi rama de notas personales. Su confirmación raíz es distinta de la de master. Nunca fusiono ni vuelvo a adaptar esta rama a ninguna otra, nunca la empujo o la jale, nunca fusiono nada aquí. Aquí almaceno mi archivo todo, los errores que encuentro, mis notas personales, ideas, preguntas para ponderar, o cualquier otro documento de escritura libre. Es una rama disjunta y es para mi forma personal de hacer las cosas: nadie lo ve. Me mantiene organizado y claro.

Para todos y cada uno de los proyectos que tengo, ya sea en el trabajo o en el hogar, estas son las únicas ramas que tengo. Solo creo nuevas ramas develop-* y elimino las completas y fallidas. Las otras ramas nunca mueren y nunca vuelven a basarse. Tenga en cuenta que cuando fusiono el control remoto master en mi master la fusión debe ser un avance rápido. Esto se debe a que nunca me comprometo con mi propio master, solo lo conecto.

Este flujo de trabajo es compatible con un desarrollador de integración; un desarrollador que está a cargo de integrar el trabajo de otras personas en la sucursal central master. Si las personas nunca se comprometen en su rama personal master, entonces tienen la garantía de que su master personal se ve exactamente igual a la de la base del código de producción. Es una red de seguridad de algún tipo, por lo que las personas siempre pueden separarse de ella si necesitan una base de código de pizarra limpia.

Si dos desarrolladores desean compartir en un experimento, pueden enviarse mutuamente solicitudes de extracción o enviar confirmaciones por correo electrónico con git format-patch. Este es el trabajo distribuido en su máxima expresión: la comunicación es entre pares, y las personas que no se preocupan por el experimento no tienen que verlo. Se mantienen enfocados y el proyecto parece más pequeño y más simple para ellos.

Answer 4

que hicieron uso de este flujo de trabajo donde en nuestra organización: http://nvie.com/posts/a-successful-git-branching-model/

Nos configurar la administración de quién puede hacer qué a qué rama a través gitolite.

Ha sido una buena "luz de cola para seguir a través de la niebla".Con infinitas opciones que Git le brinda, es difícil tomar la decisión por sí mismo sobre cuál debe ser su flujo de trabajo. Comience con esto y adaptarse. Funcionó para nosotros realmente bien. Estamos utilizando la pila .net con un sabor OSS (NHibernate, etc.)