Créez votre flux pour git à partir de zéro

L'autre jour, il y avait un bel article, quoique controversé - Arrêtez d'utiliser GitFlow! (et une douzaine d'autres sur le même sujet après).

Ses principaux points étaient les suivants:

• GitFlow contredit la thèse «les branches devraient être de courte durée».
  C'est important, car moins la branche vit, moins les risques de conflits (non seulement git, mais aussi logiques)
• GitFlow décourage les rebases pour enregistrer les validations de fusion.
  Oui, ils peuvent être enregistrés avec rebuys, mais pas les équipes Git Flow.
• GitFlow nie l'approche Contunious Delivery, estimant que chaque acte de livraison doit être effectué par un ingénieur de publication, et en général, vous pouvez voir qu'il se concentre uniquement sur un long cycle de publication.
• GitFlow n'est pas ami avec les microservices en plus des multi-référentiels (cependant, il n'y a pas grand chose à faire ici, c'est une idée qui se termine toujours mal)

• Mais le problème avec GitFlow est qu'il n'est pas non plus ami avec les mono-référentiels.

  
  

  Je suis moi-même tombé sur cela dans le processus de conception de pipelines CI: GitFlow interfère monstrueusement lorsqu'il s'exécute au-dessus d'un référentiel unique avec plusieurs livrables, par exemple, lorsque le backend et le frontend sont séparés dans un même référentiel - du fait qu'il vous permet de vous engager à libérer des branches, des conflits peuvent survenir avec la fusion inverse s'il existe plusieurs branches de publication à la fois. Oui, même si c'est un, c'est tout de même mauvais - dans de telles conditions, il est nécessaire de patcher les mécanismes de libération de GitFlow en principe, de sorte que des versions distinctes d'entités au moins fonctionnent.

  
  

Alors que faire?

L'auteur de l'article original a été aidé par les indicateurs de développement + fonctionnalité basés sur le tronc - presque le tronc vert de Google, mais pas vraiment. Mais cela ne signifie pas du tout que vous ayez besoin de cette approche.

Tout d'abord, vous devez comprendre les priorités.

À quoi ressemblent vos sorties?

• ? , , , , ?
• ? , , 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 vous sentez que votre Git vous fait mal - écrivez-moi, je serai heureux de vous aider.