Este documento establece el proceso y los flujos de trabajo según las buenas prácticas de Github y gitflow (en algunos casos simplificadas y relajadas), si tiene alguna duda por favor eche un vistazo aquí o aquí.
Estas prácticas pueden parecer de "élite" o "estilo catedral" al principio, pero créeme que me agradecerás que te enseñe esto si pretendes trabajar para una compañía más grande o profesional de software. Al final y con el tiempo verán lo fácil que es señalar cualquier información del enredo de ramas, issues, travis, etc.
Al principio no seremos estrictos con esto, pero por favor, estudia el (git)flow lo antes posible.
Todo gira alrededor de los issues, cada cambio debe tener un issue de referencia en el que el equipo de desarrollo pueda debatir, y las ramas con el nombre del usuario y el issue en el que está trabajando.
Así que si necesitas hacer un cambio, arreglar algo o añadir una nueva característica, por favor abre un nuevo issue para esto. Una vez que tengas un número de issue para trabajar, crea una rama del último desarrollo en TU fork y llámala user_t#_short_description_of_issue, por ejemplo una rama llamada stdevPavelmc_t8_travis_integration donde el número 8 es el número de issue al que está relacionada.
Todos los comentarios de los commits deben comenzar con "Refs #8, ...." donde en este caso el #8 se refiere al issue en el que estás trabajando, ¿por qué? puedes verlo aquí en acción.
Pasa el ratón por encima del nombre, número y comentarios del commit d4a19cd. Github hace un gran trabajo enlazando todo, y esto es posible porque mencionamos el issue en el nombre de la rama y también en el comentario del commit.
Los pull requests son intenciones de fusionar algún código en el árbol principal del proyecto, puedes abrir un pull request con tu trabajo local en cualquier momento, la única condición es que hayas enviado al menos un commit para un issue.
De hecho es una práctica recomendada, abrir un issue, analizar, hacer su primer commit y abrir el pull request en ese momento; de esta manera los cambios serán elegidos por Travis y el CI / CD se ejecutará para decirle si sus cambios son buenos o si se rompió algo.
Como regla general, un pull requests debe terminar con un comentario en el que se menciona a @stdevPavelmc e informando que el pull request está listo para fusionarse.
El merge por parte del dueño del repo (@stdevPavelmc) cerrará automáticamente el correspondiente pull requests y el issue con sólo añadir un comentario como este al comentario de la fusión "Cerrando el issue #8..." Github hará la magia y (si la construcción de Travis es un éxito) cerrará el pull request y el issue correspondiente, todo en un paso.
Este es un software libre y puedes usarlo sin cargos, pero si quieres expresar tu gratitud en forma monetaria estamos agradecidos por ello:
Mi número de celular es: (+53) 53 847 819, puedes donar el monto que quieras.
- Los sitios oficiales para realizar las recargas son los siguientes:
- Usando Criptomonedas usando BilRefill
- Puedes donar usando cualquiera de las pasarelas de pago disponibles, escoge la más conveniente para ti.
| Con Transfermovil | Con EnZona | Con QvaPay |
|
|
|
Gracias por su contribución!