Hacia un mejor flujo de trabajo con Git

Hemos recopilado formas de usar Git de manera más eficiente.

0. Estructura del repositorio
   • Git es un sistema de control de versiones distribuido, así que puede organizarse de varias formas: centralizada, al estilo GitHub/GitLab, jerárquica, etc.
1. Estructura de ramas
   • GitHub Flow: se mantiene Main y luego se crean ramas de funcionalidad o de corrección de errores, que se fusionan después de recibir retroalimentación
   • Git Flow: conviene más para un desarrollo tradicional que para despliegues frecuentes
     • Se crean ramas Feature y se fusionan en la rama Develop
     • Cuando Develop está lo suficientemente madura, se crea una rama Release (Stage), donde solo se corrigen errores y luego se fusiona en Develop y Master
     • Cuando todo está listo para el release, se fusiona en la rama Master y después solo se hacen hotfixes
   • GitLab Flow: una forma intermedia entre el complejo Git Flow y el demasiado simple GitHub Flow
     • En lugar de una rama Release temporal como en Git Flow, usa una rama Stage que se mantiene de forma permanente
     • Los hotfixes se reflejan en Production y Stage, y las correcciones de errores en Stage y Devlop
   • Perforce Stream: útil cuando hay que gestionar varios releases
     • Si se corrige un bug en Release, el cambio se propaga hacia Main-Develop
     • Si se desarrolla una funcionalidad en Develop, se eliminan conflictos y se refleja en Main
   • Basado en trunk: un intento de usar Main (Master) de forma más eficiente, adoptado sobre todo por grandes empresas tecnológicas
     • Se mantiene Main por largo tiempo y no se corrigen bugs directamente en las ramas de release
     • Las funcionalidades se fusionan en estado desactivado usando flags, para mantener siempre el código actualizado
2. Commits
   • Convenciones: normalmente se usa mucho la convención de Angular, aunque también se pueden usar emojis si el equipo lo acuerda
   • Unidad: idealmente deben hacerse en la unidad mínima posible, pero aun así el equipo debe acordar qué considera como unidad mínima
     • Se pueden subdividir los cambios por hunk para hacer staging
     • Resulta cómodo si se pueden comparar cambios a nivel de delta
   • Commits especulativos y registro lineal: una forma de hacer commits frecuentes para mantener el contexto sin dejar de conservar un historial lineal
     • Guardar el trabajo cada vez que haga falta conservarlo, como con stash o al probar prototipos
     • Hacer checkout donde sea necesario, seguir haciendo commits y luego mantener el historial lineal con rebase
     • Es útil usar la herramienta git-branchless
     • git sl: rastrea ramas anónimas y visualiza muy bien el historial de commits
     • git prev y git next: facilitan hacer checkout a la unidad anterior o siguiente
     • git sync: hace rebase sobre Main
     • git move: permite mover commits al lugar deseado
     • git restack: restaura el orden del historial si se rompe con rebase o commit --amend
     • git undo: permite deshacer
3. Fusión
   • Patch Stack: una forma de revisar cambios dividiéndolos como funcionalidad [1/3], funcionalidad [2/3], funcionalidad [3/3]
   • Conflictos de primera clase: Jujutsu, compatible con Git, registra los conflictos en los commits, por lo que es menos probable que vuelva a aparecer más adelante un conflicto ya resuelto
   • 3 Way Diff: en el caso de Jujusu, cuando ocurre un conflicto muestra Base-Ours como diff y Theirs como snapshot, lo que resulta intuitivo. Aun así, puede haber necesidad de ver el resaltado de sintaxis del IDE/editor o un diff Base-Their
   • Conflictos binarios: cuando Git encuentra un conflicto en archivos binarios simplemente lo deja en manos del usuario, pero personalmente se creó una herramienta simple para generar archivos Base y Their
   • Parches y correo: introducción a una forma de fusión más tradicional(?)
     • git request-pull es un comando para generar un pull request
     • Con git send-mail se pueden enviar parches por correo y con git am se pueden aplicar
4. Otros métodos de gestión
   • Worktree: el historial de Git se comparte, pero se pueden hacer varios checkouts de archivos de trabajo en distintos lugares, como si fueran ramas de SVN, para avanzar en varias tareas al mismo tiempo
   • Git LFS: una forma de gestionar archivos de gran tamaño
   • Clonado parcial y checkout parcial: permiten clonar solo una parte para reducir el tiempo de descarga, y hacer checkout parcial para trabajar solo con los directorios necesarios
   • Scalar: facilita la gestión de repositorios enormes gracias a los esfuerzos de Microsoft