Este documento fue escrito con el fin de unificar las reglas GitFlow internas de la empresa. Este método no introduce GitFlow puro, ya que es una mezcla tanto de GitFlow como de GitLab Flow, con las mejores prácticas de la compañía trabajadas durante muchos años. Ayuda a mantener un historial limpio y legible del repositorio y un mejor control sobre los cambios y proyecto ciclos de vida.

Inicialización del repositorio

Después de inicializar el repositorio, cree un desarrollar y maestro si no está incluida por defecto. La rama develop debe contener una rama código que es una réplica de la rama maestra con nuevas características incluidas. La master contiene una versión estable del código, que representa el estado de producción. Ambas tienen vida infinita, y en comparación con otras ramas en Git Flow, nunca serán eliminadas. Establece reglas de protección adecuadas: exigir revisiones de las solicitudes de extracción antes de fusionarlas y exigir que se superen las comprobaciones de estado antes de fusionar. También puede considerar la posibilidad de permitir sólo equipo para fusionar los cambios con el maestro.

$ git init
$ git commit --allow-empty -m "Confirmación inicial"
$ git checkout -b desarrollar maestro

NOTA: A veces es importante para el proyecto añadir más ramas infinitas, por ejemplo, para representar los entornos disponibles. No obstante, mantén la "regla de dos" si es posible.

Ramas de funciones

Cuando empiece a trabajar con una función determinada, asegúrese primero de que tiene su desarrollar rama sincronizada.

 $ git checkout develop && git pull --rebase

A continuación, pase a su rama de características. Nómbrela según el esquema dado: feature-JIRA-TASK-ID o también puede saltarse esa norma y darle un nombre diferente. En este caso, asegúrate de que no entra en conflicto con los patrones reservados para release, hotfix, bugfix, development o la rama master. Mantener los identificadores de tareas de JIRA te ayudará a gestionar tus ramas de características de forma más eficaz.

$ git checkout -b feature-JIRA-TASK-ID develop

Esta rama existirá mientras se desarrolle la función en cuestión y se fusione con la rama principal. Para hacer commit en su rama local, siga este comando:

$ git add .
 $ git commit -m "JIRA-TASK-ID: Descripción de la tarea"

Se recomienda añadir más commits a la rama local, siguiendo la regla "Commit early and often". Sin embargo, al final, deben aplastarse en un único commit que represente una JIRA Task. Hacer commits a menudo te ayudará a gestionar tu historial de desarrollo. Cuando la funcionalidad esté lista, es hora de abrir una Pull Request para desarrollar una rama. En primer lugar, puede empujar su rama local si no se empujó demasiado lejos:

 $ git push origin feature-JIRA-TASK-ID

Cuando la rama esté lista, abra su pull request en GitHub, siguiendo este artículo: https://help.github.com/en/articles/creating-a-pull-request

Antes de abrir una pull request, asegúrese de lo siguiente:

• a descripción adecuada se ha dado - por lo general, se vincule su tarea JIRApero también puede incluir alguna información útil relacionada con el código actual
• CircleCI los pasos se han superado con éxito
• su se asignaron miembros del equipo - es una buena práctica incluir a todos los miembros de su equipo como cesionarios
• el los revisores fueron seleccionados - el número de revisores depende de su equipo
• su código está realmente listo para su revisión - eche un último vistazo a su código, piense de nuevo si queda algo por refactorizar, pruébelo localmente y asegurarse de que está listo para los siguientes pasos.
• hay no hay conflictos de fusión y una rama está actualizada con develop - si los hay, resuélvalos primero

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag para squash
$ git push -f origin feature-JIRA-TASK-ID #Utilícelo con cuidado ya que -f sobrescribe el repositorio remoto

• conservar sólo los commits importantes - cada commit debe estar representado por una tarea JIRA, por ejemplo, JIRA-TASK-ID: Configuración de nuevas funciones; otros deben ser aplastado al volver a basar su rama con la rama de desarrollo
• tiene la rama de destino adecuada seleccionada
• no te olvides de cambiar el estado de su tarea JIRA

Fusión de la rama de características

Es hora de fusionar los cambios a desarrollar rama cuando:

• la pull request ha sido aprobada por los miembros del equipo seleccionados
• todas las pruebas han finalizado con éxito
• No hay conflictos de fusión y el historial de confirmaciones parece correcto.

Esto puede hacerlo el gestor del proyecto o el desarrollador de funciones. Para realizar la fusión, siga estos pasos:

 $ git checkout desarrollar
 $ git merge feature-JIRA-TASK-ID
 $ git push origin desarrollar
 $ git branch -d feature-JIRA-TASK-ID
 $ git push origin :feature-JIRA-TASK-ID

Ahora, el estado de la tarea JIRA se puede cambiar.

Comunicados

Las ramas de versiones deben ser creadas por una persona responsable de la versión actual. Por lo general, las versiones se crean periódicamente, por ejemplo, de acuerdo con el programa sprint ciclo de vida.

Versionado semántico

Dar a una rama de lanzamiento un nombre apropiado y la etiqueta correspondiente no es una tarea fácil al principio. Es una buena práctica empezar a utilizar el versionado semántico (https://semver.org/) que permite un mejor control y facilita la lectura del historial de git. La cadena de versión se construye según el esquema MAJOR.MINOR.PATCH:

• MAYOR - cambio que representa cambios incompatibles de la API
• MINOR - añadir nuevas funciones de forma compatible con versiones anteriores.
• PATCH - se añaden correcciones de errores compatibles con versiones anteriores

También puedes utilizar sufijos especiales, como los que representan ramas beta o legacy, o crear versiones preliminares. En ese caso, nómbralo adecuadamente, por ejemplo 1.1.0-beta.4, 1.1.0-beta.5 o 1.1.0-alpha.

Hacer un comunicado

La rama de lanzamiento debe ser hija de desarrollo y sólo puede contener commits relacionados con correcciones de errores.

El nombre de la rama debe basarse en la versión de lanzamiento, con el prefijo release-: release-MAJOR.MINOR.PATCH. La rama de lanzamiento debe ser totalmente probado tanto automática como manualmente en el entorno de ensayo. Si se producen errores, esta es la última oportunidad para empujar correcciones adecuadas y volver a ejecutar todo el proceso, siempre y cuando no se comprueba positivamente y listo para su posterior procesamiento. A continuación, la confirmación de la versión debe ser empujado, con los cambios de la cadena de versión actual en los archivos, tales como package.json. También debe tener un impacto en el archivo CHANGELOG.md. Esto le ayudará a realizar un seguimiento de todos los cambios antes de una liberación adecuada y preparar el contenido para la liberación de GitHub cuando el proceso de fusión se ha completado. La actualización del archivo único debe consistir en todos los cambios de la versión agrupados en tres categorías: características, correcciones y mantenimiento.

En el primer paso, sin embargo, asegúrese de que tiene tanto de su desarrollo y maestro ramas al día.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Producto Nombre M.M.P release"
 $ git push origin release-M.M.P

En este punto, se puede decidir crear otro pull request al master con la rama release. Puede ser una buena idea ejecutar una comprobación adicional si todas las pruebas pasan bien en la máquina remota.

$ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # el mensaje de adición puede establecerse mediante la bandera -m
 $ git push origen M.M.P
 $ git push origen master
 $ git branch -d release-M.M.P
 $ git push origen :release-M.M.P

A continuación, vaya a la página de versiones de GitHub y pulse el botón "Redactar nueva versión". En el formulario que aparece, selecciona la etiqueta de versión actual, establece un título similar al de la confirmación de la versión (Product Name M.M.P release) y una descripción adecuada, basada en el archivo CHANGELOG.md. Para proyectos públicos, la descripción debe contener una lista de todos los PR incluidos en la versión actual.

En caso de que se hayan aplicado correcciones en la rama de lanzamiento, asegúrese de tener actualizada la rama de desarrollo:

$ git checkout desarrollo && git merge master
$ git push origin develo

Hotfixes y correcciones de errores

La principal diferencia entre un fallo y las correcciones en caliente son sus ramas de destino.

Corrección de errores

Las correcciones de errores deben parchear las ramas de lanzamiento como única forma de actualizar el código antes de fusionarlo con master. En primer lugar, cree la rama a partir de la rama de características actual. Asegúrate de tenerla actualizada localmente.

$ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b corrección-M.M.P

A continuación, confirma los cambios necesarios. Una vez finalizado el proceso, cree una pull request y diríjala a la rama de publicación. Siga las instrucciones de la sección de la rama de características. El título final de la confirmación debe coincidir con el esquema dado: "Bugfix M.M.P: Problem essence fix". Cuando se apruebe el pull request, es hora de fusionarlo con la versión actual.

$ git checkout release-M.M.P
 $ git merge corrección-M.M.P
 $ git push origin release-M.M.P

Hotfix

Para realizar una revisión en la rama maestra, deben seguirse pasos muy similares a los de una corrección de errores, teniendo en cuenta que la rama de destino es ahora la rama maestra.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representa la versión actual

A continuación, sigue los pasos habituales de desarrollo y, cuando el proceso haya finalizado, crea un pull request con la rama master como objetivo. Tenga en cuenta que el commit final debe coincidir con el esquema dado "Hotfix X.Y.(Z + 1): Problem essence fix". Cuando todos los puntos de comprobación se hayan superado con éxito, realice una fusión con la rama maestra. Estos pasos difieren de los que se presentan para una corrección de errores, ya que tenemos que fusionar la versión de lanzamiento actual.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # el mensaje de adición puede establecerse mediante la bandera -m
 $ git push origen X.Y.(Z+1)
 $ git push origen master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origen :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origin desarrollo

Hoja de trucos

Repositorio Init

$ git init
 $ git commit --allow-empty -m "Confirmación inicial"
 $ git checkout -b desarrollar maestro
 $ git push origen desarrollo
 $ git push origen master

Características

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Iniciar el desarrollo y los commits

$ git add .
$ git commit -m "IRA-TASK-ID: Descripción de la tarea" #initial commit
$ git push origin feature-JIRA-TASK-ID

Abrir pull request

Rebase y preparación para pull request

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # usa la bandera -i para squash
$ git push -f origin feature-JIRA-TASK-ID #Utilícelo con cuidado ya que -f sobrescribe el repositorio remoto

Fusionar cambios y eliminar rama

$ git checkout develop # la rama debe estar sincronizada con la rama develop en este momento
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origen :feature-JIRA-TASK-ID

Comunicados

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Crear confirmación de publicación

$ git add .
$ git commit -m "Nombre del producto M.M.P release" #initial commit
$ git push origen release-M.M.P

Abrir pull request

Fusionar cambios, liberar y eliminar rama

$ git checkout master La rama # debería estar sincronizada con la rama master en este momento
$ git merge release-M.M.P
$ git tag -a M.M.P # el mensaje de adición puede establecerse mediante la bandera -m
$ git push origen M.M.P
$ git push origen master
$ git branch -d release-M.M.P
$ git push origen :release-M.M.P

Corrección de errores

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b corrección-M.M.P

$ Confirmar correcciones
$ git add .
$ git commit -m "Bugfix M.M.P: Problema esencia solucionado" #initial commit
$ git push origin bugfix-M.M.P

Abrir pull request

Fusionar cambios y eliminar rama

$ git checkout release-M.M.P # branch should be synced with current release branch at this stage
$ git merge corrección-M.M.P
$ git push origin release-M.M.P
$ git branch -d corrección-M.M.P
$ git push origen :corrección-M.M.P

Hotfix

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representa la versión actual

$ Confirmar correcciones
$ git add .
$ git commit -m "Hotfix M.M.P: Problema esencia fix" #initial commit
$ git push origin bugfix-M.M.P

Abrir pull request

Fusionar cambios, liberar y eliminar branc

$ git checkout master # la rama debería estar sincronizada con el master actual en este momento
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # el mensaje de adición puede establecerse mediante la bandera -m
$ git push origen X.Y.(Z+1)
$ git push origen master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origen :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origin desarrollo

Más información:

• Buenas prácticas de Codest para crear software: CircleCI
• ¿Cómo crear extensiones de Google Chrome utilizando el estilizador de subtítulos de Netflix?
• React: el marco JavaScript más popular