¿Cuál es el mejor proceso para revisar el código cuando se usa GIT? Tenemos un proveedor GIT externo (Unfuddle) y tenemos límites en el uso de recursos, por lo que no podemos tener repositorios remotos dedicados para cada desarrollador.
Proceso actual:
- Nosotros tener un servidor GIT con una
masterrama a la que todos se comprometen - Los desarrolladores trabajan desde el
masterespejo local o un rama de características locales - Los desarrolladores envían al servidor «s
masterrama - Los desarrolladores solicitan la revisión del código en la última confirmación
Problema:
- Cualquier error en la revisión del código ya está en el maestro cuando se detecta.
- Peor aún, por lo general, alguien se ha pasado algunas horas intentando para averiguar qué sucedió …
Por lo tanto, nos gustaría
- revisar el código ANTES de enviarlo al «maestro».
- Tener un proceso que funcione con un equipo global (sin revisiones por encima del hombro )
- algo que no requiera que un desarrollador individual esté en su escritorio / máquina para ser encendido para que alguien más pueda n (eliminar la dependencia humana, los desarrolladores se van a casa en diferentes zonas horarias)
Usamos TortoiseGIT para una representación visual de una lista de archivos cambiados, archivos diferentes, etc. Algunos de nosotros ingresamos a GIT shell cuando la GUI no es suficiente, pero idealmente nos gustaría que el flujo de trabajo fuera simple y basado en GUI (quiero que la herramienta alivie cualquier carga, no mis desarrolladores).
Comentarios
- ¿Está haciendo una prueba unitaria antes de comprometerse?
- @GuyCoder: Principalmente, lo hacemos.
- Si su host no proporciona revisión de código capacidad, obtenga un mejor host. Eche un vistazo a Gerrit y vea si puede encontrar un host que lo proporcione.
Responder
A El modelo simple pero efectivo es el modelo de GitHub pull request , donde los contribuyentes archivan las solicitudes «por favor fusiona en mi código». Un mantenedor revisa los conjuntos de cambios y decide si necesitan más trabajo o si son adecuados para la fusión. Luego, puede fusionarse con la rama maestra. Por lo general, a los confirmadores no se les permite enviar directamente a la rama maestra (esto se puede personalizar según sus gustos, permitimos que las confirmaciones «menores» ingresen directamente).
Comentarios
- Tenemos un equipo compacto de 7 desarrolladores profesionales (frente a colaboradores anónimos) a nivel mundial, por lo que es seguro dejar que cada uno envíe directamente a nuestro maestro remoto. Aunque ' es un enlace + introducción frente a una respuesta independiente que prefiero, en este caso tiene sentido. Excelente reseña en el enlace, gracias.
- @Sid Con un equipo de 3, no ' dejaría que todos se esforzaran por dominar.
- Las solicitudes de extracción también están disponibles en Rhodecode y Atlassian Stash
- @Andrew: ¿Por qué no? Hay muchos problemas que se pueden generar canalizando el trabajo de todo el equipo a través de un punto de estrangulamiento. Todos estos pueden mitigarse, pero una estructura de comando y control de un solo punto es más adecuada para algunas situaciones que para otras.
Responder
Git es un sistema de control de versiones distribuido: ¡no tenga un solo repositorio con una rama!
Puede configurar varios repositorios, uno para cada desarrollador, y otro que es el repositorio principal. Cuando una de sus ramas está lista para fusionarse, el desarrollador solicita una fusión y sus cambios se extraen de su rama / repositorio al maestro.
Antes de que la fusión se produzca, el revisor puede introducir los cambios en su entorno y revíselos antes de presionarlos para que dominen.
Las ventajas adicionales son que de esta manera un desarrollador puede tener tantas ramas como desee, nombradas como quiera, sin interferir entre sí o incluso tener para ver tanto la ropa sucia de los demás.
Además, aprenda la jerga: «Los desarrolladores se comprometen con la rama maestra del servidor», ¿quiere decir que ellos enviar sus cambios al maestro?
Comentarios
- sí,
pushsu trabajo. No podemos ' tener repositorios remotos únicos en el servidor GIT porque pagamos a un proveedor de alojamiento GIT y ellos cobran por repositorio. ¿Quiso decir tener varias sucursales remotas por desarrollador? Y cuando dicethe reviewer can pull the changes into their environment¿a qué comandos GIT exactos (o flujo de TortoiseGIT) se refiere? - No, me refiero a tener varios repositorios; uno por desarrollador, y en ese repositorio pueden tener tantas ramas como quieran. En cuanto a
pull, no ' no sé cuál sería el comando en TortoiseGIT, pero el comando es git pull . Es ' lo opuesto a una inserción: usted extrae cambios del repositorio remoto para actualizar su entorno con el trabajo que otros desarrolladores podrían haber hecho. - Lo sé
git pull🙂 …Estaba solicitando la sintaxis completa para inspeccionar el sistema de repo / branch / tag en busca de push / pulls al que se refería. Ahora mismo hacemosgit pullde todos modos, ' está fuera de remote: master, lo que causa los problemas. De todos modos, los enlaces de Steven ' fueron geniales. Gracias - A todos los efectos prácticos, en este caso, una rama en el repositorio alojado es igual que otro repositorio.