- Ramas
Cuando un desarrollador quiere corregir un error o implementar una característica, crea una nueva rama por fuera de la rama principal. Gracias al modelo de ramificación de Git, creamos estas hot branches de corta duración cada vez que queremos escribir algo de código. Se anima a los desarrolladores a hacer commit temprano y a evitar hot branches de larga duración.
- Push
Cuando el desarrollador está listo para integrar sus cambios y enviarlos al resto del equipo, se realiza un push de su rama local a una rama remota, y abre un pull request. En el caso de tener varios desarrolladores trabajando en un repositorio, cada uno con muchas ramas, es recomendable utilizar una convención de nombres para los branches remotos para ayudar a aliviar la confusión y la proliferación de ramas. Generalmente, los desarrolladores crean una rama local llamada users/<username>/feature, donde <username> es reemplazado por su usuario.
- Pull request
Utilizamos pull request para controlar el merge de las hot branches en la principal. Los pull request garantizan que se cumplan las políticas de las ramas. Por ejemplo, construimos los cambios propuestos y ejecutamos un testeo de prueba rápido, lo suficiente para rápidamente confiar en el pull request. A continuación, otros miembros del equipo revisan el código y aprueben los cambios. La revisión del código continúa donde lo dejaron las pruebas, y es especialmente bueno para detectar incovenientes. Las revisiones manuales del código garantizan que más ingenieros del equipo tengan visibilidad sobre los cambios y que la calidad del código siga siendo alta. El flujo de un pull request proporciona un punto en común para forzar las pruebas, la revisión del código y la detección de errores en una fase temprana del proceso. Esto nos ayuda a acortar el ciclo de retroalimentación a los desarrolladores, ya que los errores suelen detectarse en minutos, no en horas o días. Además, nos da confianza a la hora de refactorizar, ya que todos los cambios se prueban en todo momento.
- Merge
Una vez que todas las políticas de compilación sean pasadas y los revisores han dado su visto bueno, el pull request se completa. Esto significa que la hot branch realiza un merge con la rama principal (main). Después del merge, ejecutamos pruebas de aceptación adicionales que llevan más tiempo. Estas son más bien pruebas tradicionales posteriores a la revisión y las utilizamos para realizar una validación aún más exhaustiva. Esto nos da un buen equilibrio entre tener pruebas rápidas durante la revisión de un pull request y tener una cobertura de pruebas completa antes de la publicación.
- Estrategia de repositorios Git
Existen diferentes estrategias a la hora de optar en la gestion de sus repositorios en Git. Para algunos equipos, la mayor parte de su código está en un repositorio Git. El código se divide en componentes, cada uno de los cuales vive en su propia carpeta de nivel raíz. Los componentes realmente grandes, especialmente los más antiguos, pueden estar formados por múltiples subcomponentes. Esos subcomponentes tienen subcarpetas separadas dentro del componente principal. Algunos equipos también gestionan algunos repositorios adjuntos. Por ejemplo, el agente y las tareas de compilación se desarrollan en abierto en GitHub, y los cambios de configuración se registran en un repositorio separado.
- Mono repo o multi-repo con Git
Mientras que algunos pueden optar por tener un único repositorio monolítico (el mono-repo) de un proyecto, otros utilizan un enfoque multi-repo. Skype, por ejemplo, tiene cientos de pequeños repositorios que se unen en varias combinaciones para crear sus diferentes clientes, servicios y herramientas. Especialmente para los equipos que adoptan los microservicios, los repositorios múltiples pueden ser el enfoque correcto. Por lo general, los productos más antiguos que comenzaron como un monolito terminan encontrando un enfoque de un solo repositorio para ser la transición más fácil a Git, y su organización de código refleja eso.
