从头开始构建git的流程

前几天有一篇漂亮的，尽管有争议的文章- 请停止使用GitFlow！（之后还有更多关于同一主题的信息）。

她的主要观点是：

• GitFlow与“分支应该是短暂的”这一论点相矛盾。
  这很重要，因为分支的寿命越短，发生冲突的机会就越少（不仅是git，而且是逻辑上的）
• GitFlow不鼓励使用rebase来保存合并提交。
  是的，可以通过重新购买来保存它们，但是Git Flow团队则不能。
• GitFlow拒绝采用Contunious Delivery方法，认为每项Delivery行为都应由发布工程师完成，并且总的来说，您会发现它只关注较长的发布周期。
• GitFlow不是在多存储库之上使用微服务的朋友（但是，这里要做的事情并不多，这是一个总是很糟糕的结局）

• 但是GitFlow的问题在于，它也不是单一存储库的朋友。

  
  

  我本人在设计CI管道的过程中偶然发现了这一点：当在具有多个可交付成果的单个存储库上工作时，GitFlow会产生极大的干扰，例如，当后端和前端在同一个存储库中分开时–因为它允许您提交发布分支，如果一次存在多个发布分支，则反向合并可能会发生冲突。是的，即使它是一个，也都一样糟糕-在这种情况下，原则上有必要修补GitFlow的发布机制，以便至少可以以某种方式单独进行实体发布。

  
  

那么该怎么办？

原始文章的作者受到基于主干的开发+功能标记的帮助-几乎是Google绿色主干，但并非如此。但这并不意味着您完全需要这种方法。

首先，您需要了解优先级。

您的发行是什么样的？

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

如果您觉得自己的Git伤害了您-写信给我，我将很乐意为您提供帮助。