¿Revisión de código de Gerrit o modelo de tenedor y tracción de Github?


64

Estoy comenzando un proyecto de software que será desarrollado en equipo Y en la comunidad. Anteriormente me vendieron en Gerrit, pero ahora el modelo de solicitud de tenedor y extracción de Github parece casi proporcionar más herramientas, formas de visualizar confirmaciones y facilidad de uso.

Para alguien que tiene al menos un poco de experiencia con ambos, ¿cuáles son los pros y los contras de cada uno y cuál sería mejor para un proyecto basado en equipo que quiere dejar abierta la posibilidad de desarrollo comunitario?

Respuestas:


84

La principal diferencia entre los flujos de trabajo de Gerrit y GitHub es cómo se modelan los cambios.

En Gerrit, cada compromiso es un cambio que se sostiene por sí solo. Aunque Gerrit le mostrará las relaciones entre los compromisos, las revisiones se realizan por compromiso. Es probable que los equipos que son buenos para dividir los grandes cambios en pequeños compromisos independientes tengan más éxito con Gerrit. Sin embargo, dado que el modelo de Gerrit incluye revisiones sucesivas a un compromiso particular, alienta los flujos de trabajo de Git a los que muchos desarrolladores no están acostumbrados, como enmendar un compromiso anterior y volver a empujarlo, o aplastar un conjunto creciente de compromisos de una rama de tema en un solo cometer.

En Github, una solicitud de extracción modela una relación entre dos ramas. El flujo de trabajo esperado en Github es confirmar uno o más cambios en una rama de tema (a menudo en una bifurcación del repositorio, pero no necesariamente) y crear una solicitud de extracción entre esa rama y la rama "ascendente". En este caso, lo que se está revisando es un conjunto de compromisos que continúa creciendo a medida que continúa la revisión. El resultado es un conjunto de cambios que luego pueden fusionarse atómicamente cuando están completos. Las solicitudes de extracción pueden ser efectivas para rastrear cambios con un alcance mayor que puede implementarse en múltiples confirmaciones. Las solicitudes de extracción también admiten flujos de trabajo SCM a los que están acostumbrados más desarrolladores, como responder a un comentario de revisión enviando una confirmación de seguimiento en la misma rama.

Una gran ventaja a favor de Github es la cantidad de desarrolladores que están familiarizados con él en comparación con Gerrit. Gerrit puede ser popular entre los usuarios avanzados de Git, pero su uso sin fricción requiere un conocimiento de git intermedio o avanzado, y la tolerancia de una curva de aprendizaje empinada.

La ventaja de Gerrit es una relación más profunda con Git. Las solicitudes de extracción de Github están lo suficientemente alejadas del modelo de datos estándar de Git que uno debe usar la interfaz de usuario web de Github o su API patentada para crear solicitudes de extracción. La interfaz de Gerrit para crear y actualizar cambios es el protocolo git en sí.


8
Gracias Martin, esa es una respuesta interesante. He tenido la intención de mirar a Gerrit por un tiempo, pero creo que lo dejaré de lado. Si alienta el historial de edición y las confirmaciones de aplastamiento, no quiero tener nada que ver con eso. * 8 '(
Mark Booth

15
Para ser claros (uso a menudo Gerrit en mi lugar de trabajo), lo que Martin dice aquí, "Gerrit ... alienta los flujos de trabajo de Git ... como enmendar un compromiso anterior y volver a presionarlo, o aplastar un conjunto creciente de compromisos. ..into un solo commit "es exactamente correcto. Mi aclaración es que el comentario de @ MarkBooth sobre el "historial de edición" no es lo que dijo Martin. Las confirmaciones enmendadas (mientras todavía está en Gerrit, y aún no se fusionó con origen / maestro) no implica el "historial de edición". De hecho, este flujo de trabajo funciona muy bien. La edición 'mala' de la historia a la que se refiere Mark Booth es volver a empujar las historias editadas a origen / maestro.
likethesky

2
Gracias por la aclaración @likethesky, pero tengo una interpretación bastante más literal del 'historial de edición', y en lo que a mí respecta, cualquier cosa que resulte en conjuntos de cambios que contengan contenido que no haya confirmado explícitamente es 'historial de edición'. Sin embargo, me doy cuenta de que esta es una interpretación bastante draconiana y a la que pocos se adhieren. * 8 ')
Mark Booth

2
Lo suficientemente justo. :-) No estoy seguro de entender lo que quiere decir con "conjuntos de cambios que contienen contenido que no confirmó explícitamente", así que por favor. elaboro ... Asumo que estás no decir que nunca jamás se compromete temporal (local o compartida entre los miembros del equipo a través de las sucursales remotas) sobre como, "trabajo en curso: esta intenta resolver el problema de arco discutimos", seguido de una squash / enmienda más útil que dice: "Problema 123: XYZ refactorizado para aumentar la resistencia y la facilidad de escala horizontal" como mensaje final de compromiso para ese trabajo. Pero de todos modos, ¡por supuesto, puedes elegir usar git de cualquier manera que te haga feliz!
likethesky

77
Esta es una respuesta fantástica. Para agregar, descubrí que las solicitudes de extracción de GitHub fomentan compromisos más pequeños e iterativos y, a menudo, terminan con un registro de git mucho más descriptivo que muestra no solo el producto de trabajo sino también el proceso de trabajo. La revisión del código de Gerrit fomenta un historial de repositorio mucho más limpio (hay muy, muy pocas confirmaciones de fusión reales) con confirmaciones más grandes y pulidas.
tophyr
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.