tipos - git ver archivos modificados

¿Usando git para las revisiones de código? (9)

Me gustaría desarrollar un proceso de revisión de código ligero que sea similar al que utilicé cuando trabajé en MSFT.

Este es un esquema general del proceso:

Desarrollador hace cambios.
El desarrollador empaqueta cambios en algún archivo de almacenamiento
El desarrollador envía el archivo al equipo de desarrollo
Miembro aleatorio del equipo de desarrollo, abre el archivo de cambios automágicamente en una utilidad diferente, toma notas
Si el código es bueno, el miembro aleatorio lo dice, de lo contrario responde con las notas solicitadas

Para que quede claro: sé cómo cambiar el código (: D) y enviar un correo electrónico. Me gustaría saber si existe una forma directa de crear un archivo de cambios y verlos fácilmente en una herramienta de diferencias usando git . Creo que puedo crear un git patch y git patch correo electrónico, pero eso es solo la mitad de la historia. ¿Puedo ver fácilmente lo que el parche haría con la base de código actual?

Quiero que esto sea lo más claro posible, porque de lo contrario es poco probable que se hagan revisiones de código, y soy un firme creyente de que un simple proceso de revisión de código aumentará la calidad del código.

¿Puedo ver fácilmente lo que el parche haría con la base de código actual?

Git 2.17.x (Q1 2018) podría ayudar con el git format-patch :
" git format-patch " ha aprendido a dar 72-cols para difstat, que es coherente con otros límites de longitud de línea que utiliza el subcomando para su salida destinada a correos electrónicos.

Ver commit 071dd0b (01 Feb 2018), y commit 43662b2 (25 Jan 2018) por Nguyễn Thái Ngọc Duy ( pclouds ) .
^{(Fusionada por Junio C Hamano - gitster - en commit e469e9c , 21 de febrero de 2018)}

format-patch : reduce el ancho del difstato de parche a 72
Los parches generados por el parche de formato están destinados a ser intercambiados como correos electrónicos, la mayoría de las veces.
Y dado que generalmente se acepta que los mensajes de texto se envuelvan alrededor de las 70 columnas aproximadamente, asegúrese de que estos difsstat sigan la convención (especialmente cuando se usa con --cover-letter -cover ya que de manera predeterminada envolvemos 72 columnas). El valor predeterminado aún se puede anular con las opciones de línea de comando.

¿Has considerado a Gerrit?

http://code.google.com/p/gerrit/

No veo por qué querría eludir su sistema de control de fuente enviando parches por correo electrónico y tratando de hacer un seguimiento de qué parches se han fusionado o no cuando tiene el modelo de git branching disponible.

En lugar de enviar parches por correo electrónico, ¿por qué no presionar una sucursal remota y solicitar a un revisor que se responsabilice de fusionarla en su rama de desarrollo principal? De esta forma, puede confiar en su repositorio para mostrarle qué código se ha fusionado o no en su rama principal ( git branch -r --no-merged ). Puede volver a establecer fácilmente las sucursales de características que necesitan revisión para mantenerlas por delante de su rama principal, lo que permite que la revisión realice una fusión rápida y no tenga que preocuparse por los conflictos de combinación. También puede aprovechar cualquier herramienta de reconocimiento de git para revisar los cambios.

Personalmente, sugiero también que sus revisores combinen las ramas de la característica usando --no-ff para crear una fusión de confirmación para que pueda obtener un historial que se parece a algo así como:

Usted termina con un buen historial limpio de características fusionadas en su rama principal, visibilidad del trabajo realizado en cada rama de características y puede ver quién revisó el código tal como se fusionó.

Otras respuestas lo señalaron a las herramientas existentes para la revisión del código, y es probablemente lo que realmente desea.

Pero para completar, ya que solicitó una forma de trabajar con el correo electrónico:

En el lado del envío, git send-email le permite enviar un parche por correo electrónico. Simplemente enviar un parche no es suficiente, ya que no transmite los metadatos, como el mensaje de registro. Si git send-email no funciona para usted, git format-patch puede generar un parche con metadatos que puede enviar de la forma que desee.
En el extremo del receptor, git am permite tomar un conjunto de parches enviados por correo electrónico en formato mbox y aplicarlo a un repositorio. Algunos programas de correo permiten ejecutar un comando arbitrario en un mensaje: luego se ejecuta git am en el mensaje. Una alternativa es guardar los parches enviados por correo electrónico en un archivo mbox y ejecutar git am desde una línea de comandos. La revisión se puede hacer leyendo el parche o aplicando el parche a una rama arrojadiza y leyendo el historial de esta rama.

FYI, así es como se desarrolla la herramienta Git en sí misma (ver SubmittingPatches para más información).

Puede crear un "paquete" de git que almacena de manera eficiente una secuencia de confirmaciones. Esto es mejor que un archivo de parche porque puede contener más de una confirmación (el uso de archivos de revisión requeriría un archivo de parche por confirmación).

Cualquiera puede insertar fácilmente un paquete en su propio repositorio, en una rama temporal de "revisión" si lo desea, y ver cuál es el efecto de las confirmaciones. Si inserta un paquete en la misma revisión exacta desde la que comenzó el desarrollador, entonces no hay posibilidad de conflictos, por lo que el revisor no tiene que hacer nada especial.

Recomiendo sinceramente Critic , un sistema de revisión de Git desarrollado y utilizado en Opera Software. El W3C también lo usa para revisar las pruebas.

Con Critic, el trabajo normal es así:

Escribir código, comprometer
Empuje hacia la crítica remota (normalmente tiene origin y critic )
Critic envía correos electrónicos a aquellos cuyos filtros coinciden con sus archivos modificados, se les asignan esos archivos
Algunas de esas personas entran y revisan los archivos a los que están asignados.
Cuando la revisión está completa al 100% (el crítico lo rastrea), puede integrar su sucursal

Lo asombroso es que cualquier problema que creas cuando revisas se aborda automáticamente cuando presionas las nuevas confirmaciones que las abordan. El revisor también recibe un correo electrónico muy bien formateado sobre los nuevos cambios (aunque prefiero solo ir a la interfaz web) para revisar los nuevos cambios.

Todos los cambios deben revisarse antes de que se acepte la revisión. Eso incluye reparaciones.

El escenario típico es:

100% reviewed, 2 issues

Luego, cuando se solucionen con una o dos correcciones, esas correcciones, por supuesto, tienen que revisarse, por lo que la revisión irá a:

98% reviewed, 0 issues

Y cuando alguien lo haya visto, se actualiza al 100% nuevamente y luego se Review Accepted .

Falta promoción y ostentación, pero es muy agradable trabajar con ella. También tenemos que usar Gerrit para nuestras revisiones de Chromium (yo trabajo en Opera), y usamos ReviewBoard por muy poco tiempo (la insatisfacción con RB fue en realidad la razón directa por la cual se creó Critic en primer lugar).

También tenemos algunas extensiones escritas, por ejemplo, puede enviar el código a commit-queue (que prueba el cambio y lo confirma si es bueno) después de que haya recibido una revisión aceptada.

También me gustaría sugerir echar un vistazo a la Junta de Revisión:

http://www.reviewboard.org/

Review Board fue desarrollado originalmente por un par de ingenieros en mi compañía (VMware, Inc.) y es utilizado por una gran cantidad de empresas de software empresarial con un flujo de trabajo muy similar al que usted describe. Actualmente requiere configurar un servidor central (es una aplicación MVC basada en Django bastante estándar, AFAIK), sin embargo, también están trabajando en un servicio de alojamiento:

https://www.rbcommons.com/

En lugar de enviar parches por correo electrónico, en realidad proporciona una interfaz de usuario web ( muy ingeniosa ) que refleja lo que el cambio propuesto le hará a la base de código actual; admite navegación por teclado, le permite adjuntar capturas de pantalla, pagina automáticamente para cambios muy grandes, le permite responder con comentarios línea por línea y admite flujos de trabajo de "cambio en el cambio" donde se aumenta el parche original y los revisores pueden concentrarse en las diferencias de una versión anterior del mismo parche. Tiene soporte básico de Git sobre el que puede obtener más información en las preguntas frecuentes:

http://www.reviewboard.org/docs/manual/dev/faq/

He usado Review Board desde su inicio. Antes de su llegada usamos un sistema de parches de envío muy similar a lo que describes y Review Board ha sido un gran paso adelante.

Usa Github . El flujo de trabajo cambia ligeramente:

Desarrollador hace cambios
El desarrollador confirma el código
Desarrollador empuja a Github
El desarrollador envía una solicitud de extracción al jefe / revisor del equipo
El revisor acepta cambios y fusiona el código en el repositorio principal

Github no es gratis, pero teniendo en cuenta lo que hace por ti, es muy barato. Puede hacer comentarios fácilmente sobre un delta (cambio único) o por línea antes de aceptar o rechazar un cambio. También puede buscar el código en su repositorio local y ver, compilar, ejecutar, ejecutar pruebas unitarias o lo que desee.

En cuanto a los revisores que se fusionan, no creo que haya una manera fácil de hacerlo. Sin embargo, puede bloquear el repositorio "bendecido" para que solo personas selectas puedan presionarlo (revisores). De esa forma, las revisiones de código son forzadas. En el sistema de correo electrónico, incluso si tuviera archivos de parche, el revisor tendría que pasar por el proceso de aplicar el parche y fusionarse. Enviar solicitudes de extracción es un paso adelante de los parches porque git puede usar el historial de la rama de fusión para obtener una mejor idea; por eso la fusión en git tiende a ser más fácil.

Esta es una situación muy común. La gente a menudo quiere revisiones forzadas del código, y github lo hace innegablemente fácil. De hecho, muchas personas comienzan a usar github simplemente para revisiones forzadas de código.

SmartGit proporciona una funcionalidad de revisión de código ligera que se puede configurar rápidamente. Funciona de forma local (los metadatos forman parte del repositorio de Git) y, por lo tanto, no requiere componentes adicionales del lado del servidor.

tipos - git ver archivos modificados

¿Usando git para las revisiones de código? (9)

format-patch : reduce el ancho del difstato de parche a 72

`format-patch` : reduce el ancho del difstato de parche a 72