5 ideas para un flujo de trabajo de GitHub mejorado
Dependiendo de su historial con el control de fuente en funcionamiento, la forma en que trabaja con una base de código, realiza confirmaciones, etc., varía.
Además, dependiendo de si usa Git, Subversion, Mercurial, etc., también determina cómo administra su código.
Pero si eres alguien que está trabajando con Git (que sé que muchas personas en WordPress están comenzando a usar cada vez más casi a diario), hay algunas pequeñas cosas que recomiendo hacer para ayudar a administrar los cambios, especialmente con un equipo. más manejable.
Sugerencias para un flujo de trabajo de GitHub mejorado
1 No te comprometas con el maestro
Master debe usarse específicamente para código listo para producción y listo para implementar. No es tu rama de trabajo, no es tu rama de trabajo.
En términos generales, aquí es donde se fusionan todas las solicitudes de extracción.
2 Trate de crear siempre sucursales
Cada vez que tenga una colección de tareas, problemas o hitos, cree una rama y asegúrese de que todo lo que está trabajando esté relacionado. Por ejemplo, no desea realizar trabajo de base de datos y trabajo de JavaScript en sus solicitudes de incorporación de cambios.
3 Agrupe su trabajo
Incluso si está trabajando únicamente en el trabajo de front-end, es posible que deba dividirlo en ramas más pequeñas. Facilita las revisiones de código y mejora las solicitudes de incorporación de cambios.
4 Generar pequeñas relaciones públicas
Esto es muy similar al encabezado anterior, pero la idea de crear PR pequeños es mucho más productiva que crear solicitudes de extracción más largas.
- Esto ayuda cuando necesita solicitar una revisión de código, ya que les brinda a sus compañeros de equipo una manera más fácil de manejar las revisiones de código y ofrecer comentarios.
- Mantiene el registro de cambios reducido y ayuda a brindar un informe detallado de lo que hace el lote específico de código.
Pero, ¿qué constituye un buen PR?
5 Da buenos detalles en tu PR
En lo que a mí respecta, una buena solicitud de extracción hará un pequeño conjunto de cosas:
- Detalle, en solo una oración o dos, lo que la persona que revisa sus cambios debe esperar que suceda.
- Vincule el PR al ticket, tarjeta de gestión de proyectos (o como lo llamen en su sistema),
- Enumere versiones más cortas de los mensajes de compromiso para que sea lo más fácil posible para su revisor.
Dicho esto, es probable que haya más cosas que pueda hacer, pero estas son las cosas que he encontrado más útiles (y no me importaría decir que no aprendí algunas de estas cosas de mi equipo ).
¿Hay más cosas?
Siempre.
Pero estas son algunas de las cosas que he encontrado que son cada vez más útiles, especialmente al rastrear cambios, trabajar con otros y tratar con solicitudes de incorporación de cambios (tanto de aquellos con quienes trabajo como de aquellos que contribuyen a proyectos de código abierto).
Finalmente, ninguna de estas cosas son prescriptivas. Hay una curva de aprendizaje (hablando por experiencia), pero recomiendo probar algunos de estos, aunque solo sea para ver si no mejora su flujo de trabajo.
Incluso si es solo un poco.