¿Cómo se usan DVCS en equipos grandes?

Question

Recientemente comencé a entrar en Git en un proyecto personal, y puedo ver cómo un DVCS podría beneficiarnos en el trabajo (que es una gran empresa de software empresarial, que actualmente ejecuta Perforce). El trabajo de características en mi equipo, por ejemplo, consiste principalmente en desarrolladores que crean sus propias sucursales; a veces estos se comparten entre pequeños equipos de desarrolladores. Creo que sería más eficiente en esta instancia usar un DVCS.

En el caso más general, sin embargo, me gustaría saber de las personas que usan un DVCS en el trabajo, en equipos medianos y grandes.

1. ¿Cómo lidiar con las fusiones en N-way? ¿Es esto incluso un escenario común? Mercurial solo admite fusiones en N forma haciendo fusiones bidireccionales (N-1) (y read que esta es la solución preferida en otros DVCS), lo que suena como un proceso muy laborioso incluso para relativamente pequeñas N.
2. ¿Usted usar un único repositorio central autorizado, o es realmente P2P?
3. ¿Los desarrolladores a menudo empujan y extraen el código entre sí, o todo pasa por el repositorio central?

Answer 1

Mi equipo de mi empleador anterior usó Git, y funcionó bien para nosotros. No éramos tan grandes (tal vez 16 o así, con quizás 8 committers realmente activos?), Pero tengo respuestas a sus preguntas:

1. Las fusiones de N-Way no son terriblemente comunes. Se nos ocurrieron algunas convenciones sobre nombres de sucursales que nos permitieron escribir scripts que facilitaron el proceso de "liberación de ingeniería" (utilizo comillas de susto porque no teníamos un ingeniero de versiones), y las personas crearían ramas de características privadas, pero rara vez tuvo un problema con la fusión de más de dos ramas (ver el siguiente).
2. (y # 3).Teníamos un repositorio central en un servidor de desarrollo por tres razones: (a) La máquina de desarrollo tenía un RAID5 (más tolerante a fallas) y copias de seguridad nocturnas (las estaciones de trabajo dev no eran todas las noches), (b) las versiones de producción se creaban en el servidor de desarrollo. y (c) tener un repositorio central simplificado de scripting. Como resultado, las fusiones en N simplemente nunca sucedieron. Lo más parecido que tuvimos a N-way fue cuando alguien se fusionó lateralmente y luego se fusionó verticalmente.

Git fue una gran cosa para nosotros debido a su alto grado de flexibilidad; sin embargo, tuvimos que establecer algunas convenciones (nombres de ramas y etiquetas, ubicaciones de repositorios, scripts, etc., proceso) o podría haber sido un poco caótico. Una vez que configuramos las convenciones, la flexibilidad que teníamos era simplemente fantástica.

Actualización: nuestras convenciones básicamente eran así:

• un directorio en nuestro servidor NFS que albergaba todos los depósitos centrales
• que teníamos varios proyectos que comparten componentes, por lo que les estalló en las bibliotecas, en esencia, con sus propios repositorios, y los proyectos entregables simplemente los incluyeron como submódulos de git.
• no eran cadenas de versión y suelte los nombres que se nos imponen desde arriba, por lo que sólo utiliza una variantes de esas como nombres de rama
• Del mismo modo, para las etiquetas, siguieron los nombres de liberación procesos dictado
• los proyectos entregables contenidos un archivo de propiedades que leí en los guiones del intérprete de comandos, y eso me permitió escribir un solo guión para gestionar el proceso de lanzamiento para todos los proyectos, aunque cada uno tenía pequeñas variaciones en el proceso; las variaciones se contabilizaron en esos archivos de propiedades
• Escribí scripts que reconstruirían un paquete entregable desde cualquier etiqueta
• usando git al nos bajó para controlar el acceso usando PAM y/o permisos de usuario normales (ssh, etc.)
• Hubo otras convenciones que son más difíciles de poner en una lista con viñetas, como cuando las fusiones deberían suceder. Realmente, yo y otro hombre somos una especie de "git gurus" internos, y ayudamos a todos a descubrir cómo usar las ramas y cuándo fusionarse.
• hacer que la gente se comprometa en trozos pequeños y no dejar caer bombas-dif en la rama principal fue un desafío. Un hombre dejó caer aproximadamente dos semanas de trabajo en un compromiso, y finalmente tuvimos que resolverlo todo. Un enorme pérdida de tiempo, y frustrante para todos.
• comentarios informativos y detallados para ir con compromete

Había otras cosas que se aprende como su equipo se experimenta y aprende a trabajar unos con otros, pero esto fue suficiente para que podamos empezar.

actualización: cualquiera que siga este tipo de cosas a estas alturas ya lo sabe, pero Vicente Dreissen ha escrito un sólido y bastante completa (pero no exaustive) take on branching and release engineering using Git. Me animo a usar su proceso como un punto de partida porque, por dos razones:

• un montón de equipos de hacerlo de esta manera o si está usando alguna variante cercana (incluyendo Linux, Git, y muchos otros equipos de proyecto OSS), que significa que este método ha sido probado y ajustado para tener éxito en la mayoría de las circunstancias. Es muy poco probable que enfrente un problema que no se haya enfrentado y resuelto dentro de las limitaciones de este modelo.
• debido a lo anterior, casi cualquier ingeniero con experiencia en Git entenderá lo que está pasando. No tendrá que escribir documentación detallada sobre la naturaleza fundamental de su proceso de publicación; solo tendrá que documentar cosas específicas solo para su proyecto o equipo.

Answer 2

Aquí es un ejemplo (por no decir un "universal" uno)

Hemos VCS centrales (ClearCase o la subversión, en función de los diferentes proyectos), y los estamos utilizando para desarrollos "oficiales" esfuerzos (desarrollo, parches, arreglos), donde el número de sucursales es limitado y está bien identificado.

Sin embargo, para los desarrollos de refactorización que implican una gran cantidad de estado intermedio, en el que nada funciona, y donde muchos desarrolladores tiene que tener su propia rama basada en la actividad o ramas, algunos repositorios Git se establece entre los desarrolladores, en una Forma P2P.
Una vez que el trabajo alcanza algún tipo de estabilidad 0.1, y las fusiones se reducen, se reimporta en el VCS, donde el trabajo puede continuar de una manera central y "ordenada".

Desde Git on Windows works well (MSysGit), nos las arreglamos para tener pequeños desarrollos iniciales hechos rápidamente por el lado de esa manera.

Todavía estamos evaluando a Git para un desarrollo de proyecto a gran escala.

Answer 3

Probablemente sea mejor observar cómo funcionan los desarrolladores del kernel de Linux. Tienen un flujo de trabajo bastante complejo donde los cambios se envían desde muchas fuentes, y luego los desarrolladores de confianza para cada subsistema (llamados tenientes) incorporan los cambios, y cuando están contentos los envían a Linus, quien eventualmente los arrastra a su árbol o los rechaza Por supuesto, es más complejo que eso, pero eso es una descripción general.

Answer 4

He estado trabajando durante varios años con el equipo Glasgow Haskell Compiler utilizando Darcs. Recientemente (varios meses) comencé a usar git para mi propia copia del repositorio, tanto para el rendimiento como para mejorar mi educación.

1. ¿Cómo lidiar con N-way merges?

   No hay combinaciones de N vías. Cada desarrollador origina una secuencia de parches, y los flujos se fusionan uno a la vez en cada repositorio. Entonces, si N desarrolladores hacen cambios simultáneamente, se fusionan en pares.

2. ¿Utiliza un único repositorio central autorizado?

   Absolutamente. Es la única forma de saber qué es GHC y qué no.

3. ¿Los desarrolladores a menudo empujan y extraen el código entre ellos, o todo pasa por el repositorio central?

   Creo que depende de los desarrolladores y del VCS que esté utilizando. En el proyecto de GHC casi todos los tirones y empujones que veo pasan por el depósito central. Pero hay un portero pesado (autoadministrado) que empuja hacia el repositorio central, y si un colega tiene una corrección de errores, necesito ahora, lo sacaré directamente de su repositorio. Con Darcs es muy fácil extraer solo un parche (en lugar de todo el estado como en git), y sé que mis compañeros deveopers, que tienen más experiencia con los darcs, usan esta característica mucho más que yo --- y les gusta mucho.

   Con git, cuando estoy trabajando en estrecha colaboración con otro desarrollador, con frecuencia crearé una nueva rama con el único propósito de compartirla con otra persona. Esa rama nunca llegará al repositorio central.

Answer 5

La justa famosa "Tech Talk: Linus Torvalds en git" explica cómo se utiliza para Linux (casi tan grande como el equipo que se me ocurre)

Si no recuerdo mal, su uso se se asemeja a una cadena de comando militar: cada módulo tiene un mantenedor que maneja las solicitudes de extracción de los desarrolladores, luego hay algunas personas "más confiables" que tratan de extraer datos de los mantenedores de los módulos en el repositorio kernel.org git oficial.

"Linux: Managing the Kernel Source With 'git'" también explica que, aunque de nuevo no es ninguna explicación concisa .. esquema

Answer 6

flujo de trabajo de whygitisbetterthanx:

alt git work-flow with integration manager http://whygitisbetterthanx.com/images/workflow-b.png

Para escalar este hasta aún más desarrolladores, sólo tiene que añadir otra capa de "tenientes de confianza" entre el gerente de integración y los desarrolladores.