Git Workflow: Aclaración y prevención de antipatterns

Estoy en el process de desarrollar un flujo de trabajo de Git para un proyecto de aplicación web en el que estoy trabajando. He usado Git durante varios años, pero solo como desarrollador en solitario. He reunido un set de procedimientos y ayer encontré este artículo en HN: http://sandofsky.com/blog/git-workflow.html

Basado en el artículo, he ajustado mis procedimientos y agradecería algunos comentarios. Quiero asegurarme de que estoy interpretando el artículo correctamente y de no contribuir con cuestiones futuras. Con base en el artículo en cuestión y el deseo de proporcionar buenos estándares de trabajo, ¿hay algún problema con los siguientes procedimientos?


Lo esencial

  • twig principal: twig principal en la que se fusiona todo el desarrollo de código. Esto representa las adiciones más recientes a la base de código de las twigs de desarrollo individuales.
  • 'dev_' branches – Las twigs de desarrollo locales y privadas se deben usar para desarrollar nuevas características. Si necesita enviar la twig al server (para que pueda cambiar fácilmente entre las computadoras), asegúrese de que el nombre de la twig dev incluye el nombre de usuario, como 'dev_andy_authentication'.
  • bifurcación de etapas : antes de implementar cierto código de la twig maestra, el código debe probarse en un entorno que coincida lo más posible con el entorno de producción. El código de la twig maestra se fusiona con la twig de etapas, se testing y, una vez que pasa las testings, es apto para la producción.
  • twig de producción : el código estable de la twig de etapas se integra en la twig de producción, se label con un número de versión de lanzamiento y luego se implementa en el server o serveres de producción.

Desarrollo

Rama: maestro

  • Utilice las twigs de características locales y privadas para separar el código:
    • Cambiar a la twig 'master': git checkout master
    • Cree una nueva twig de funciones privadas: git checkout -b dev_newfeaturename
    • Haga adiciones de funciones.
    • Cambios de escenario: git add.
    • Confirmar cambios en 'dev_newfeaturename': git commit -m "commit description"
  • Para integrar los cambios de la twig 'dev_newfeaturename':
    • Cambiar a la twig 'master': git checkout master
    • Compruebe si hay cambios remotos en 'master': git pull –rebase origen master
    • Si los cambios en la twig 'dev_newfeaturename' son relativamente pequeños:
      • Integrar los cambios desde la twig 'dev_newfeaturename' en el maestro: git merge –squash dev_newfeaturename
      • Escriba un post de confirmación detallado de los cambios implementados desde la twig 'dev_newfeaturename': git commit -v
    • Si los cambios en la twig 'dev_newfeaturename' son más complejos, y requieren varias confirmaciones para permanecer en el historial:
      • Cambie a la twig 'dev_newfeaturename': git checkout dev_newfeaturename
      • Reintegrar cualquier código 'maestro' modificado en la twig 'dev_newfeaturename': git rebase –interactive master
      • Para limpiar el historial al combinar commits, cambia la operación de "pick" a "squash", que aplasta el segundo commit en el primero
      • Cambiar a la twig 'master': git checkout master
      • Empuje los cambios al 'maestro' remoto: git push origin master
    • Compruebe si hay cambios remotos en 'master': git pull –rebase origen master
    • Empuje todos los cambios a 'master' de return al server: git push origin master
  • 'Master' se convierte en el tree de trabajo de todas las características desarrolladas actualmente.
  • Extraiga periódicamente los cambios 'maestros' desde el control remoto: git pull –rebase origen master

Puesta en escena

Rama: puesta en escena

  • Una vez que se ha progtwigdo el lanzamiento de un cierto número de características / correcciones de errores, asegúrese de que 'maestro' esté funcionando correctamente y luego combine en 'puesta en escena' de la siguiente manera:
    • Cambiar a la twig 'staging': git checkout staging
    • Integre los cambios de 'master' a 'staging': git merge –no-ff master
    • Empuje la "puesta en escena" al repository remoto: organización de origen de git push
  • Despliegue la twig 'staging' al server de testing y realice testings rigurosas: el server de transferencia debe replicar el entorno de producción lo más cerca posible.
  • Si alguna testing falla, regrese a la twig 'principal', solucione cualquier problema asociado y reinicie el process de Etapas.
  • Si todas las testings pasan, proceda al process de producción.

Producción

Rama: producción

  • Una vez que el código en la twig de etapas ha sido probado y ha pasado, cambie a la twig 'producción': producción de pago de git
  • Integrar los cambios de 'puesta en escena' en producción: git merge –no-ff staging
  • Código de label con número de versión de lanzamiento secuencial: git tag -a 0.1
  • Empuje la 'producción' al repo remoto: producción de origen de git push
  • Implemente la twig de "producción" en el server de producción y realice testings para garantizar una implementación adecuada.

Tu escribiste:

Si los cambios en la twig ' dev_newfeaturename ' son más complejos, y requieren varias confirmaciones para permanecer en el historial:

  • Cambie a la twig ' dev_newfeaturename ': git checkout dev_newfeaturename
  • Reintegrar cualquier código ' master ' dev_newfeaturename la twig ' dev_newfeaturename ': git rebase --interactive master
  • Para limpiar el historial al combinar commits, cambia la operación de "pick" a "squash", que aplasta el segundo commit en el primero
  • Cambiar a la twig ' master ': git checkout master
  • Empuje los cambios al ' master ' remoto: git push origin master

Creo que olvidas la combinación rápida de ' dev_newfeaturename ' en ' master ':
La rebase le permite reproducir ' dev_newfeaturename ' en la parte superior de ' master ', limpiando las confirmaciones en ese process. Eso es bueno.
Pero si desea volver a enviar maestro al control remoto, el maestro necesita las confirmaciones limpias en su historial: `git merge dev_newfeaturename


Con respecto a una twig por estado de desarrollo (puesta en escena, prod), no recomendaría ese enfoque, a less que esté produciendo activamente nuevas confirmaciones en esas twigs.
Recuerde la oración sobre no-ff en el artículo que hace reference:

El único argumento restante para –no-ff es "documentation".
Las personas pueden usar confusiones de fusión para representar la última versión implementada del código de producción.
Eso es un antipatrón. Usa tags