Crie seu fluxo para o git do zero

Outro dia, houve um artigo bonito, embora controverso - Por favor, pare de usar o GitFlow! (e mais uma dúzia sobre o mesmo tópico depois).

Seus principais pontos foram:

• O GitFlow contradiz a tese "os galhos devem ter vida curta".
  Isso é importante, porque quanto menos o ramo vive, menor a chance de conflitos (não apenas git, mas também lógico)
• O GitFlow desencoraja os rebotes para salvar confirmações de mesclagem.
  Sim, eles podem ser salvos com rebuys, mas as equipes do Git Flow não.
• O GitFlow nega a abordagem Contunious Delivery, acreditando que todo ato de Entrega deve ser realizado por um engenheiro de lançamento e, em geral, você pode ver que ele se concentra apenas em um longo ciclo de lançamento.
• O GitFlow não é amigo de microsserviços no topo de multi-repositórios.

• Mas o problema com o GitFlow é que ele também não é amigo de mono-repositórios.

  
  

  Eu mesmo me deparei com isso no processo de criação de pipelines de CI: O GitFlow interfere monstruosamente quando é executado no topo de um único repositório com várias entregas, por exemplo, quando o back-end e o front-end são separados em um repositório - devido ao fato de permitir que você se comprometa a liberar ramificações, conflitos podem ocorrer com a mesclagem inversa se existir mais de uma ramificação de liberação por vez. Sim, mesmo se for um, é tudo a mesma coisa - em tais condições, é necessário corrigir os mecanismos de lançamento do GitFlow em princípio, para que pelo menos de alguma maneira versões separadas de entidades funcionem.

  
  

Então o que fazer?

O autor do artigo original foi ajudado por desenvolvimentos baseados em tronco + sinalizadores de recursos - quase no google green trunk, mas na verdade não. Mas isso não significa que você precise dessa abordagem.

Primeiro, você precisa entender as prioridades.

Como são seus lançamentos?

• ? , , , , ?
• ? , , 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 — , , . , , .

Se você sentir que seu Git a machuca - escreva para mim, terei prazer em ajudar.