Configuraciones¶
Es importante que sigamos las buenas prácticas y lineamientos establecidos para el uso de Github. Estas prácticas aseguran que nuestro flujo de trabajo sea eficiente y que nuestras contribuciones sean de alta calidad.
Internamente utilizamos una serie de configuraciones de protección de branches para garantizar que nuestras contribuciones sean revisadas y aprobadas antes de que se fusionen con el código base principal.
Estas configuraciones incluyen:¶
- La obligación de utilizar Pull Request y requerir aprobaciones de ciertos revisores antes de que se fusionen las ramas.
- Por default utilizamos 1 aprovador, que efectivamente no sea quien realizo el Pr.
Es importante destacar que las aprobaciones de PRs caducan si se envían nuevas confirmaciones (commits).
- También especificamos quiénes son los revisores autorizados a aprobar los PRs. (Ver Más: Organizaciones)
- Además, requerimos que ciertos status checks pasen antes de que se pueda fusionar una rama y que todas las ramas estén actualizadas antes de la fusión. Esto incluye análisis y respuesta de SonarQube para asegurar la calidad del código y la detección de problemas de seguridad.
Info
Build (16.x) puede diferir en versiones actuales. (Refiere a la version de Node.)
-
Otro aspecto importante a tener en cuenta es el uso del historial linear y del Squash Merge:
Preferimos utilizar el Squash Merge en lugar de los merge commits tradicionales para asegurar que nuestro historial de git sea más limpio y fácil de entender.
El Squash Merge combina todos los commits de la rama de características en un solo commit en la rama principal, lo que significa que no se crean merge commits adicionales en el historial de git.
Esto resulta en un historial más lineal y fácil de leer, lo que es especialmente útil para proyectos grandes y complejos.
Además, el Squash Merge ayuda a mantener nuestro código base limpio y organizado.
Al fusionar ramas de características utilizando el Squash Merge, podemos asegurarnos de que solo el código necesario se fusiona en la rama principal y de que los commits individuales sean significativos y estén bien escritos.
Ver Más: Squash Merge & Merge Commit
Organizaciones¶
Además de las configuraciones de protección de ramas mencionadas anteriormente, otra buena práctica que podemos implementar en Github es la organización de los equipos y subequipos de trabajo.
En Andreani, contamos con diferentes equipos que trabajan en proyectos específicos. Cada equipo tiene su propio conjunto de responsabilidades y objetivos, y cada miembro del equipo tiene su rol específico dentro del proyecto.
Para organizar mejor nuestros equipos y subequipos, es importante que utilicemos la función de "Teams" en Github. Esto nos permite crear equipos y subequipos dentro de nuestra organización, asignar roles específicos a cada miembro del equipo y controlar su acceso a los repositorios.
Dentro de cada equipo, podemos establecer diferentes roles para los miembros, como Owner, Codereviewers y Developers. Los Owners tienen acceso completo al repositorio y pueden realizar cualquier acción, mientras que los Codereviewers tienen la responsabilidad de revisar y aprobar los Pull Requests. Por otro lado, los Developers tienen permisos limitados y solo pueden hacer cambios en las ramas que les fueron asignadas.
Al crear un equipo, también podemos asignar repositorios específicos y establecer permisos de acceso. Por ejemplo, podemos dar permisos de escritura a los Owners y Codereviewers y solo permisos de lectura a los Developers.
En resumen, como miembros de Andreani es importante seguir estas buenas prácticas y lineamientos establecidos para el uso de Github. Esto garantizará que nuestro flujo de trabajo sea eficiente y que nuestras contribuciones sean de alta calidad. Además, debemos asegurarnos de que todos los miembros de nuestro equipo comprendan estas prácticas y las sigan de manera consistente para garantizar el éxito a largo plazo de nuestros proyectos.