Dependiendo de su historial con el control de fuente en funcionamiento, la forma en que trabaja con una base de c\u00f3digo, realiza confirmaciones, etc., var\u00eda.<\/p>\n
Adem\u00e1s, dependiendo de si usa Git<\/a>, Subversion<\/a>, Mercurial<\/a>, etc., tambi\u00e9n determina c\u00f3mo administra su c\u00f3digo.<\/p>\n Pero si eres alguien que est\u00e1 trabajando con Git (que s\u00e9 que muchas personas en WordPress est\u00e1n comenzando a usar cada vez m\u00e1s casi a diario), hay algunas peque\u00f1as cosas que recomiendo hacer para ayudar a administrar los cambios, especialmente con un equipo. m\u00e1s manejable.<\/p>\n Master debe usarse espec\u00edficamente para c\u00f3digo listo para producci\u00f3n y listo para implementar. No es tu rama de trabajo, no es tu rama de trabajo.<\/p>\n En t\u00e9rminos generales, aqu\u00ed es donde se fusionan todas las solicitudes de extracci\u00f3n.<\/p>\n Cada vez que tenga una colecci\u00f3n de tareas, problemas o hitos, cree una rama y aseg\u00farese de que todo lo que est\u00e1 trabajando est\u00e9 relacionado. Por ejemplo, no desea realizar trabajo de base de datos y trabajo de JavaScript en sus solicitudes de incorporaci\u00f3n de cambios.<\/p>\n Incluso si est\u00e1 trabajando \u00fanicamente en el trabajo de front-end, es posible que deba dividirlo en ramas m\u00e1s peque\u00f1as. Facilita las revisiones de c\u00f3digo y mejora las solicitudes de incorporaci\u00f3n de cambios<\/a>.<\/p>\n Esto es muy similar al encabezado anterior, pero la idea de crear PR peque\u00f1os es mucho m\u00e1s productiva que crear solicitudes de extracci\u00f3n m\u00e1s largas.<\/p>\n Pero, \u00bfqu\u00e9 constituye un buen PR?<\/p>\n En lo que a m\u00ed respecta, una buena solicitud de extracci\u00f3n har\u00e1 un peque\u00f1o conjunto de cosas:<\/p>\n Dicho esto, es probable que haya m\u00e1s cosas que pueda hacer, pero estas son las cosas que he encontrado m\u00e1s \u00fatiles (y no me importar\u00eda decir que no aprend\u00ed algunas de estas cosas de mi equipo<\/a> ).<\/p>\n Siempre.<\/p>\n Pero estas son algunas de las cosas que he encontrado que son cada vez m\u00e1s \u00fatiles, especialmente al rastrear cambios, trabajar con otros y tratar con solicitudes de incorporaci\u00f3n de cambios (tanto de aquellos con quienes trabajo como de aquellos que contribuyen a proyectos de c\u00f3digo abierto).<\/p>\n 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.<\/p>\n Incluso si es solo un poco.<\/p>\nSugerencias para un flujo de trabajo de GitHub mejorado<\/h2>\n
1 No te comprometas con el maestro<\/strong><\/h3>\n
2 Trate de crear siempre sucursales<\/strong><\/h3>\n
3 Agrupe su trabajo<\/strong><\/h3>\n
4 Generar peque\u00f1as relaciones p\u00fablicas<\/strong><\/h3>\n
\n
5 Da buenos detalles en tu PR<\/strong><\/h3>\n
\n
\u00bfHay m\u00e1s cosas?<\/h2>\n