El otro día hubo un artículo hermoso, aunque controvertido. ¡ Por favor, deja de usar GitFlow! (y una docena más sobre el mismo tema después).
Sus puntos principales fueron:
- GitFlow contradice la tesis "las ramas deben ser de corta duración".
Esto es importante, porque cuanto menos viva la rama, menos posibilidades hay de conflictos (no solo git, sino también lógico) - GitFlow desaconseja rebases para guardar confirmaciones de fusión.
Sí, se pueden guardar con recompras, pero los equipos de Git Flow no. - GitFlow niega el enfoque de entrega contundente, creyendo que cada acto de entrega debe ser realizado por un ingeniero de lanzamiento, y en general puede ver que se enfoca solo en un ciclo de lanzamiento largo.
- GitFlow no es amigo de microservicios además de repositorios múltiples (sin embargo, no hay mucho por hacer aquí, es una idea que siempre termina mal)
Pero el problema con GitFlow es que tampoco es amigo de mono-repositorios.
Yo mismo me topé con esto en el proceso de diseño de canalizaciones de CI: GitFlow interfiere monstruosamente cuando se trabaja en la parte superior de un único repositorio con varios entregables, por ejemplo, cuando el backend y la interfaz están separados en el mismo repositorio, porque le permite comprometerse a liberar ramas, Los conflictos pueden ocurrir con la fusión inversa si existe más de una rama de lanzamiento a la vez. Sí, incluso si es uno, es igual de malo: en tales condiciones, es necesario parchear los mecanismos de lanzamiento de GitFlow en principio, de modo que al menos de alguna manera funcionen los lanzamientos separados de entidades.
¿Entonces lo que hay que hacer?
El autor del artículo original fue ayudado por el desarrollo basado en troncales + banderas de características - casi google green trunk, pero en realidad no. Pero esto no significa en absoluto que necesite este enfoque.
Primero, necesitas entender las prioridades.
¿Cómo son tus lanzamientos?
- ? , , , , ?
- ? , , WebSockets, . .
- ? LTS-, backport- ( , , 2016 ) ? canary beta-?
- Continuous Delivery?
?
- ( ) , ? design review merge/pull-request-, PR — 5 100 ?
- , ?
? , ?
, — . , flow , . Apache Kafka SQS — , , -, - , .
— . ( ) , , , , , , , .
, , — - . , JSON YAML, — , , .
, , , — , , — . , , . — , — .
flow
-, . , , ( ). , , , , , , , , v1 v2 .
, , . , , , CI, : .
— Continuous Delivery.
— , deliverables. - , , Google. — 10% - — -, .
. , :
CI-
deliverables:
- prestable/staging-
- alert- ( -)
- ( )
— flow, ,
, backport- — , . , (master/develop/trunk), , . git — cherry-picking. "" — , .
- ,
- , . JS — eslint-. Prettier ( ).
, 5-6 , — trunk-based development ( , ). — , , git - . Google , , , , . Facebook , , .
, Trunk-based — " ", , , . , CI/CD, :
feature flags — .
, .
. 2-3 , , ( , )
— merge queue, — , .
, , .
, - :
- github-flow
- CI,
- git-flow ( + )
- CD
- git-flow , CD, staging-,
- trunk-based
- trunk-based-
— . github-flow ( GitOps- — , ). , "". , , — .
, , , , .
Git — , , . , , .
Si sientes que tu Git te lastima, escríbeme, estaré encantado de ayudarte.