Skip to content

Instantly share code, notes, and snippets.

@ivandevp
Last active September 21, 2018 19:07
Show Gist options
  • Save ivandevp/faefea8e75fb4d9811bb15948c6837c5 to your computer and use it in GitHub Desktop.
Save ivandevp/faefea8e75fb4d9811bb15948c6837c5 to your computer and use it in GitHub Desktop.
How to setup around our git conventions in the LMS Dev Team :thinking_face:

LMS Git Conventions - Setup

Current status

  • Versión: v0.1.7
  • Entornos:
  • Planificación
    • Versión 0.2.0 está planificado para el feature de experimentación que se está trabajando (Project based LMS).
    • Versión 0.1.8 sería el siguiente release de la versión que está en producción.
    • Cada feature pequeño estamos actualizándolo como si fuera un patch.
    • Solo tenemos el branch master donde se solicitan todos los PRs que se preparan para el siguiente release.
    • Se tiene un branch de develop que es una copia de master, pero no contiene ningún feature diferente aun.

Applying our Git conventions

Si seguimos las convenciones de Git propuestas, podríamos hacer algunos cambios y tener un flujo como siguiente:

Versioning

  • v0.1.8, siguiente bug fix que se encuentre en producción.
  • v0.2.0, siguiente feature pequeño que no genere un cambio fuerte en el entorno actual.
  • v1.0.0, siguiente release que implique cambios que rompan las versiones anteriores. Ejemplo, agregar proyectos como feature en el LMS y que cambie la estructura de cohorts y cursos. Este debería seguir las etapas del proceso de desarrollo.

Branches

Las ramas que actualmente podríamos tener, serían:

  • master: Versión de producción.
  • develop: Desarrollo de features que serán incluidos en el release v0.2.0.
  • v1.0.0-dev: Desarrollo de los features que serán parte del release v1.0.0-alpha, básicamente los del Project Based LMS.

Pull Requests

Los pull requests cambiarían de acuerdo al feature que se esté desarrollando:

  • master: Solo se hará pull requests desde la rama release/v0.x.y que se cree cuando un set de features se haya terminado en la rama develop, o la rama hotfix/foo que se haya creado para hacer un fix que necesita corregirse sobre la base de producción.
  • develop: Solo se hará pull requests desde los forks de los devs, estos deberían incluir los features a incluir para la siguiente versión de producción.
  • v1.0.0-dev: Solo se hará pull requests desde los forks de los devs, estos incluirán features o fixes de lo necesario para el desarrollo del Project Based LMS.

Releases

  • La versión de producción seguirá el flujo de Semver: MAJOR.MINOR.PATCH.

  • El desarrollo de la versión del Project Based LMS, seguirá las etapas de desarrollo, haciendo los pre-releases:

    • v1.0.0-alpha.X
    • v1.0.0-beta.X
    • v1.0.0-rc.X

    Nota: Podemos usar como referencia el flujo llevado por el equipo de Material UI.

  • El release de esta versión debería quedar en la v1.0.0 al menos que haya un major change antes de esto.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment