खरोंच से गिट के लिए अपने प्रवाह का निर्माण

दूसरे दिन एक सुंदर, यद्यपि विवादित लेख था - कृपया, GitFlow का उपयोग करना बंद करें! (और इसके बाद एक ही विषय पर एक दर्जन से अधिक)।

उसके मुख्य बिंदु थे:

• GitFlow ने थीसिस का विरोधाभास किया "शाखाओं को अल्पकालिक होना चाहिए।"
  यह महत्वपूर्ण है, क्योंकि कम शाखा रहती है, संघर्षों की संभावना कम (न केवल गिट, बल्कि तार्किक भी)
• GitFlow विलय को बचाने के लिए विद्रोहियों को हतोत्साहित करता है।
  हां, उन्हें पुनः निर्माण के साथ बचाया जा सकता है, लेकिन गिट फ्लो टीमें ऐसा नहीं करती हैं।
• GitFlow कंटुनियस डिलीवरी दृष्टिकोण से इनकार करता है, यह विश्वास करते हुए कि प्रत्येक वितरण अधिनियम एक रिलीज इंजीनियर द्वारा किया जाना चाहिए, और सामान्य तौर पर आप देख सकते हैं कि यह केवल एक लंबे रिलीज चक्र पर केंद्रित है।
• मल्टी-रिपॉजिटरी के शीर्ष पर माइक्रोसर्विस के साथ GitFlow दोस्त नहीं हैं (हालांकि, यहां बहुत कुछ नहीं किया जाना है, यह एक ऐसा विचार है जो हमेशा बुरी तरह से समाप्त होता है)

• लेकिन GitFlow के साथ समस्या यह है कि यह मोनो-रिपॉजिटरी के साथ दोस्त नहीं है।

  
  

  मैं खुद सीआई पाइपलाइनों को डिजाइन करने की प्रक्रिया में इस पर लड़खड़ाया: GitFlow राक्षसी हस्तक्षेप करता है जब यह एक एकल रिपॉजिटरी के शीर्ष पर कई डिलिवरेबल्स के साथ चलता है, उदाहरण के लिए, जब बैकएंड और फ्रंटेंड दोनों एक रिपॉजिटरी में अलग होते हैं - इस तथ्य के कारण कि यह आपको शाखाएं जारी करने की अनुमति देता है, यदि एक से अधिक रिलीज़ शाखा एक समय में मौजूद हैं, तो रिवर्स मर्ज के साथ विरोध हो सकता है। हां, भले ही यह एक ही है, यह सब एक ही बुरा है - ऐसी स्थितियों में यह आवश्यक है कि गीताफ्लो रिलीज तंत्र को सिद्धांत रूप में पैच किया जाए, ताकि कम से कम किसी भी तरह से संस्थाओं की अलग-अलग रिलीज काम हो सके।

  
  

इसलिए क्या करना है?

मूल लेख के लेखक को ट्रंक-आधारित विकास + सुविधा झंडे द्वारा मदद की गई थी - लगभग गूगल ग्रीन ट्रंक, लेकिन वास्तव में नहीं। लेकिन इसका मतलब यह बिल्कुल नहीं है कि आपको इस दृष्टिकोण की आवश्यकता है।

सबसे पहले, आपको प्राथमिकताओं को समझने की आवश्यकता है।

आपकी रिलीज़ कैसी दिखती हैं?

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

यदि आपको लगता है कि आपका गिट आपको चोट पहुँचाता है - मुझे लिखें, तो मुझे मदद करने में खुशी होगी।