Queremos que sea lo más fácil posible para USTED contribuir a Bitxor. Actualmente estamos en el proceso de consolidación de los repositorios de nuestra organización, pero intentaremos mantener esta documentación actualizada.
Confiamos en gran medida en las verificaciones de código automatizadas (desenrollado, compilación y prueba) en combinación con las revisiones de código.
Fundamentalmente, creemos que la codificación es tanto un arte como una ciencia y una buena revisión del código tendrá un poco de ida y vuelta entre los revisores y el autor. En consecuencia, durante el curso de una revisión, puede haber varias confirmaciones que incorporen comentarios. Si bien mantenerlos separados durante la revisión ayuda a los revisores, la utilidad de recordar estos cambios es mínima. Como resultado, generalmente aplastamos todas las confirmaciones que componen una solicitud de extracción en una sola confirmación. Esto ayuda a mantener ordenado nuestro registro de git, así como a alentar encarecidamente las solicitudes de extracción relativamente pequeñas y de un solo propósito.
Si está trabajando en un pequeño cambio de una sola parte, debería estar trabajando fuera de la rama de desarrollo (dev).
Al fusionar, se recomienda la opción --no-ff.
Si está trabajando en un cambio más grande de varias partes, debería estar trabajando en una rama de función (feature/*).
Al fusionar, se recomienda la opción --ff para agrupar todos los cambios relacionados.
Lista de verificación ANTES de abrir una solicitud de extracción:
No combine varios cambios en una sola revisión. Por ejemplo, si desea cambiar el nombre de una función de uso común y cambiar su funcionalidad, preferimos dos PR, uno para el cambio de nombre y otro para el cambio de funcionalidad, en lugar de uno. NUNCA combine cambios de reformateo con cambios de funcionalidad.
Ejecute linter en el código y actualice el código para pasar. En la mayoría de los proyectos, puede ejecutar ./lint.sh desde la raíz del proyecto. Si dicho archivo no está presente, consulte el LÉAME específico del proyecto sobre cómo ejecutar el linter o consulte los comandos ejecutados por la canalización de CI.
Escriba pruebas unitarias para todo el código nuevo. Nos esforzamos por lograr una cobertura de sucursales superior al 95 % en todo nuestro proyecto.
Asegúrese de que pasen todas las pruebas unitarias, nuevas y existentes.
Asegúrese de que todas las puertas de calidad de construcción / canalizaciones de CI automatizadas pasen.
Realice una autoevaluación. Revise su código como si estuviera revisando el de otra persona.
Una vez que haya completado todos los pasos anteriores, abra una solicitud de extracción en GitHub.
Esté abierto a la retroalimentación y no a la defensiva.
Incorpore los comentarios de los mantenedores de manera oportuna.
Espere la aprobación de al menos dos colaboradores, incluido al menos un mantenedor principal. Si está modificando el código existente, se recomienda que el autor original lo revise, si es posible.
Rebase y aplaste su solicitud de extracción antes de fusionarla con su destino, ya sea dev o una rama feature/*. Si no tiene permisos para esto, alguien lo hará por usted.
Last updated by John Doe
on 2023‑06‑19.
