GitHub PR को cherry-pick करके देखें

• कंपनी के अंदर mono-repository इस्तेमाल करना शुरू किए 4 महीने हो चुके हैं
• mono-repository के साथ अक्सर जुड़ने वाला कीवर्ड trunk-based development भी साथ में लागू कर रहे हैं
• trunk-based development रणनीति के अनुसार, main branch पर commit किया जाता है और release branch पर cherry-pick करने वाला flow इस्तेमाल हो रहा है
• LinkedIn तकनीकी ब्लॉग की सामग्री के आधार पर GitHub Action कॉन्फ़िगर किया, लेकिन यह CONFLICT को अपने-आप हल नहीं कर पाता। CONFLICT होने पर उपयोगकर्ता को local में सीधे git cherry-pick कमांड चलाना पड़ता है
• इस cherry-pick कमांड में मदद करने के लिए gh plugin खुद बनाया गया।

उपयोग

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• -merge option से यह चुना जा सकता है कि PR merge commit को cherry-pick करना है या PR के मूल commitों को cherry-pick करना है
  • अगर इसे निर्दिष्ट न किया जाए या -merge=auto option इस्तेमाल किया जाए, तो PR किस रणनीति से merge हुआ था यह अपने-आप inspect करके लागू किया जाता है
• -push option के जरिए cherry-pick सफल होने पर remote push अपने-आप करने का समर्थन है

अनुभव

• ऐसा प्रोग्राम विकसित करते समय जो लगातार बाहरी process और state के साथ interact करता है, एक अलग test repository बनाकर test dataset तैयार किया
  • पहले libgit2 प्रोजेक्ट और refined-github में योगदान देने का अनुभव मददगार रहा
• CLI अनुभव को बेहतर बनाने के लिए कई तरह की पढ़ाई
  • docker-cli को अकेले बनाकर देखने के लिए की गई पढ़ाई काम आई
• उम्मीद से कहीं ज़्यादा मेहनत CLI प्रोग्राम बनाने में लगती है
  • pipeline जैसी संरचना में बहुत सारे state values को मैनेज करना
  • उपयोगकर्ता को सहज input interface देना
  • input validation को जितना जल्दी हो सके उपलब्ध कराना
  • उपयोगकर्ता के सिस्टम को मूल स्थिति में वापस लाना आदि
  • लगा था कि इसे लगभग एक दिन में बनाया जा सकेगा, लेकिन इसे बनाने में करीब 5 दिन लगे (हालाँकि GitHub Actions Workflow सुधारने के लिए विकास समानांतर में चल रहा था, फिर भी अपेक्षा से बहुत अधिक समय लगा)

[qncnxnlrla]

नमस्ते~ main(trunk) ब्रांच में merge किए गए commit को अगर revert करना पड़े, तो आप इसे कैसे संभालते हैं?

• अगर main ब्रांच में revert करें, तो क्या उसे release ब्रांच में भी cherry-pick किया जाता है?
• revert का उपयोग किए बिना एक fix commit और जोड़ते हैं?

कई commit जमा होने पर conflict होने से cherry-pick मुश्किल हो सकता है, ऐसे case को संभालने का आपका अनुभव है क्या?!

[a1eng0]

नमस्ते~ जवाब देने के लिए धन्यवाद!

अगर main(trunk) ब्रांच में merge किए गए commit को revert करना पड़े, तो आप उसे कैसे संभालते हैं?

हम main ब्रांच पर revert PR बनाकर उसमें cherry-pick निर्दिष्ट करते हैं। मूल PR लिंक में cherry-pick की पूरी history रहती है, इसलिए tracking में कोई खास मुश्किल नहीं होती। अलग से कोई mechanical check नहीं करते, हाहा

अगर बहुत सारे commit जमा हो गए हों और conflict होने की वजह से cherry-pick करना मुश्किल हो जाए

सबसे पहले, trunk-based development करने पर हर PR छोटा होता है, इसलिए conflict बार-बार नहीं होते। अगर conflict हो भी जाए, तो फिर manually code लिखना पड़ता है। हम release बहुत बार-बार करते हैं ताकि बहुत पुराने versions के support को जल्दी deprecate किया जा सके और code structure में बहुत बड़े बदलाव आने से बचा जा सके!

[lamanus]

मुझे अच्छी तरह समझ नहीं आ रहा कि यह रणनीति क्यों ज़रूरी है...

[a1eng0]

अगर आप release-from-trunk में बताए गए कंटेंट को पढ़ेंगे, तो शायद समझने में मदद मिलेगी haha