Bauen Sie Ihren Flow für Git von Grund auf neu auf

Neulich gab es einen schönen, wenn auch kontroversen Artikel - Bitte hör auf, GitFlow zu benutzen! (und ein Dutzend mehr zum gleichen Thema danach).

Ihre Hauptpunkte waren:

• GitFlow widerspricht der These "Zweige sollten von kurzer Dauer sein".
  Dies ist wichtig, denn je weniger der Zweig lebt, desto geringer ist die Wahrscheinlichkeit von Konflikten (nicht nur git, sondern auch logisch).
• GitFlow rät von Rebases ab, um Merge-Commits zu speichern.
  Ja, sie können mit Rebuys gespeichert werden, die Git Flow-Teams jedoch nicht.
• GitFlow lehnt den Contunious Delivery-Ansatz ab und ist der Ansicht, dass jeder Delivery-Vorgang von einem Release-Ingenieur ausgeführt werden sollte. Im Allgemeinen kann man sehen, dass er sich nur auf einen langen Release-Zyklus konzentriert.
• GitFlow ist nicht mit Microservices über Multi-Repositories befreundet (hier gibt es jedoch nicht viel zu tun, es ist eine Idee, die immer schlecht endet).

• Das Problem mit GitFlow ist jedoch, dass es auch nicht mit Mono-Repositories befreundet ist.

  
  

  Ich selbst bin beim Entwerfen von CI-Pipelines darauf gestoßen: GitFlow stört ungeheuerlich, wenn es auf einem einzelnen Repository mit mehreren Liefergegenständen ausgeführt wird, z. B. wenn sowohl das Backend als auch das Frontend in einem Repository getrennt sind - aufgrund der Tatsache, dass Sie sich dazu verpflichten können, Zweige freizugeben. Konflikte können bei der umgekehrten Zusammenführung auftreten, wenn mehr als ein Release-Zweig gleichzeitig vorhanden ist. Ja, auch wenn es eines ist, ist es trotzdem schlecht - unter solchen Bedingungen ist es im Prinzip notwendig, die Release-Mechanismen von GitFlow zu patchen, damit zumindest irgendwie separate Releases von Entitäten funktionieren.

  
  

Was tun?

Der Autor des Originalartikels wurde von Trunk-basierten Entwicklungs- und Feature-Flags unterstützt - fast Google Green Trunk, aber nicht wirklich. Dies bedeutet jedoch keineswegs, dass Sie diesen Ansatz benötigen.

Zunächst müssen Sie die Prioritäten verstehen.

Wie sehen deine Veröffentlichungen aus?

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

Wenn Sie das Gefühl haben, dass Ihr Git Sie verletzt - schreiben Sie mir, ich helfe Ihnen gerne weiter.