sjdonado
commented
6 years ago El modelo es sencillo, trabajar con dos ramas principales (master y develop). La rama master será la que tendrá el código en producción. La rama develop tendrá todo el código actual en desarrollo, no recibe commits directos sino a través de pull requests. Los pull vienen de branches llamadas features las cuales se trabajan de forma descentralizada, antes de que un pull request sea aceptado el proyect manager hace un code review de la nueva característica. Cuando ya varios features han sido aceptados se dispone a realizarse un release, el cual consiste en hacer pruebas de integración con los features y corregir los bugs. Después de que todo esté trabajando correctamente se mergea la rama creada para dicho release en master (se libera una nueva versión a producción). Todos los merges son non-fast-forward por lo que es importante que cada commit sea semántico y esté relacionado a un ticket (Jira) o tarjeta (trello) para futuro soporte.(Anexo las diapositivas al canal en el cual muestran los detalles del commit template). Para los hotfix se crea una nueva rama que sale de master y vuelve a master cuando el error sea corregido, los hotfix no necesitan pull request y se trabajan con tags para el versionamiento de igual manera que master) http://nvie.com/posts/a-successful-git-branching-model/ http://udacity.github.io/git-styleguide/
carlosazaustre
Completar el documento CONTRIBUTING.md que nos sirva para trabajar y recibir contribuciones de otr@s.