Flujo de trabajo de Git para gestionar el trabajo en varias ramas

Mi estrategia al usar Git como herramientas de control de versiones para mis proyectos

Realizo un seguimiento de todo mi desarrollo utilizando Git y siempre sigo esta estrategia.

La estrategia está inspirada enUn modelo de ramificación de Git exitoso.

Tengo 2 ramas permanentes: master y desarrollo.

Esas son las reglas que sigo en mi rutina diaria:

Cuando abordo un problema nuevo o decido incorporar una función, hay 2 carreteras principales:

  • La función es rápida, o las confirmaciones posteriores que haré no romperán el código (o al menos eso espero): puedo comprometerme en el desarrollo o hacer unarama de función rápiday luego fusionarlo para desarrollar.

  • La función tardará más de una confirmación en finalizar, tal vez se necesiten días de confirmaciones antes de que la función finalice y vuelva a estabilizarse:Hago una rama de características, luego fusionar para desarrollar.


Si algo en nuestroel servidor de producción requiere una acción inmediata, como una corrección de errores que necesito resolver lo antes posible, hago unrama de revisión corta, arregla la cosa, prueba la rama localmente y en una máquina de prueba, luego combínala para dominar y desarrollar.


Si necesito unfunción rápida / editarpara ser empujado en el servidor de producción, la rama de desarrollo tiene un código inestable, y me gustaría esa función / editar lo antes posible, puedoomita la rama de desarrollo, haga una rama de función rápida y combínela para dominar y desarrollar, siempre que la función / edición sea rápida y trivial. Si resulta ser algo más complicado en el futuro, sería mejor esperar y estabilizar el código en la rama de desarrollo.


losLa rama de desarrollo siempre estará en un estado de cambio., es por eso que debería ponerse un 'congelar'al preparar un comunicado. El código se prueba y cada flujo de trabajo se verifica para verificar la calidad del código, y está preparado para fusionarse con el maestro.


Cada vez que desarrolle o se fusione otra rama de hotfix en masterLo etiquetocon un número de versión, por lo que es fácil volver a un estado anterior si algo sale mal.


Más tutoriales de git: