Git के लिए सफल ब्रांचिंग मॉडल

विन्सेन्ट ड्रिसेन: एक सफल गिट ब्रांचिंग मॉडल अनुवाद



इस लेख में, मैं एक विकास मॉडल प्रस्तुत करता हूं जिसे मैं पिछले साल के लिए अपनी सभी परियोजनाओं (काम करने और निजी दोनों) के लिए उपयोग कर रहा हूं, और जिसने खुद को अच्छे पक्ष में दिखाया है। एक लंबे समय के लिए मैं उसके बारे में लिखने जा रहा था, लेकिन अभी भी कोई खाली समय नहीं मिला है। मैं परियोजना के सभी विवरणों के बारे में बात नहीं करूंगा, मैं केवल ब्रांचिंग और रिलीज प्रबंधन रणनीतियों पर संपर्क करूंगा।







यह Git का उपयोग सभी स्रोत कोड के लिए एक संस्करण नियंत्रण उपकरण के रूप में करता है।

क्यों git?

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



लेकिन गिट के साथ, ये गतिविधियां बेहद सरल और सस्ती हो जाती हैं, और इसलिए, वास्तव में, वे सामान्य दैनिक वर्कफ़्लो के लिए केंद्रीय हो जाते हैं। बस तुलना करें: सीवीएस / सबवर्सन ब्रांचिंग और मर्जिंग पर पुस्तकों में आमतौर पर अंतिम अध्याय (उन्नत उपयोगकर्ताओं के लिए) पर चर्चा की जाती है, जबकि गिट के बारे में किसी भी पुस्तक में वे पहले ही तीसरे अध्याय (मूल बातें) में उल्लिखित हैं।



उनकी सादगी और पूर्वानुमानशीलता के कारण, ब्रांचिंग और मर्जिंग से सावधान रहने की क्रिया नहीं रह जाती है। संस्करण नियंत्रण उपकरण अब ब्रांचिंग और किसी भी अन्य से अधिक विलय करने में मदद कर सकते हैं।



लेकिन उपकरणों के बारे में बात करना बंद करो, चलो विकास मॉडल पर चलते हैं। मैं जिस मॉडल को पेश करना चाहता हूं, वास्तव में, प्रक्रियाओं का एक सेट है जो प्रत्येक टीम सदस्य करता है ताकि एक साथ वे विकास प्रक्रिया की उच्च प्रबंधन क्षमता प्राप्त कर सकें।

विकेंद्रीकृत लेकिन केंद्रीकृत

प्रस्तावित ब्रांचिंग मॉडल एक प्रोजेक्ट कॉन्फ़िगरेशन पर निर्भर करता है जिसमें एक केंद्रीय "सच" रिपॉजिटरी होती है। मैं ध्यान देता हूं कि यह भंडार केवल केंद्रीय माना जाता है (चूंकि गिट डीवीसीएस है, इसमें तकनीकी स्तर पर मुख्य भंडार के रूप में ऐसा नहीं है)। हम इस भंडार को मूल शब्द कहेंगे, क्योंकि यह नाम सभी Git उपयोगकर्ताओं के लिए पहले से ही परिचित है।







प्रत्येक डेवलपर ने मूल में परिवर्तन (पुल एंड पुश) प्रकाशित किए और प्रकाशित किए। लेकिन, केंद्रीकृत पुश-पुल संबंध के अलावा, प्रत्येक डेवलपर अपनी माइक्रो-टीम के भीतर अन्य सहयोगियों से भी बदलाव उठा सकता है। उदाहरण के लिए, यह विधि ऐसी स्थिति में सुविधाजनक हो सकती है जहां दो या दो से अधिक डेवलपर्स एक साथ एक बड़ी नई सुविधा पर काम कर रहे हों, लेकिन समय से पहले मूल में प्रगति पर काम प्रकाशित नहीं कर सकते। ऊपर की तस्वीर एलिस और बॉब, एलिस और डेविड, क्लेयर और डेविड के उपसमूहों को दिखाती है।



तकनीकी रूप से, यह आसान है: ऐलिस एक दूरस्थ गिट शाखा बनाता है जिसे बॉब कहा जाता है जो बॉब के भंडार को इंगित करता है, और बॉब उसकी रिपॉजिटरी के साथ भी ऐसा ही करता है।

मुख्य शाखाएँ

विकास मॉडल का मूल अधिकांश मौजूदा मॉडलों से अलग नहीं है। केंद्रीय भंडार में दो मुख्य शाखाएं होती हैं जो हर समय मौजूद रहती हैं।

• स्वामी
• विकसित करना

मास्टर ब्रांच तब बनाई जाती है जब रिपॉजिटरी को इनिशियलाइज़ किया जाता है, जिसे हर Git यूजर को पता होना चाहिए। उसके समानांतर, हम विकास नामक एक शाखा भी बनाते हैं।



हम मूल / मास्टर शाखा को मुख्य मानते हैं। अर्थात्, इसमें स्रोत कोड किसी भी मनमाने बिंदु पर उत्पादन-तैयार अवस्था में होना चाहिए।



मूल / विकास शाखा जिसे हम विकास के लिए मुख्य शाखा मानते हैं। किसी भी समय इसमें संग्रहीत कोड में अगली रिलीज़ के लिए आवश्यक नवीनतम प्रकाशित परिवर्तन होने चाहिए। इस शाखा को "एकीकरण" भी कहा जा सकता है। यह स्वचालित रात बनाता की विधानसभा के लिए एक स्रोत के रूप में कार्य करता है।



जब विकास शाखा में स्रोत कोड (विकसित) एक स्थिर स्थिति तक पहुंच जाता है और रिलीज के लिए तैयार होता है, तो सभी परिवर्तनों को एक निश्चित तरीके से मुख्य शाखा (मास्टर) में डाला जाना चाहिए और रिलीज संख्या के साथ टैग किया जाना चाहिए। नीचे हम इस प्रक्रिया पर विस्तार से विचार करेंगे।



इसलिए, हर बार मुख्य शाखा (मास्टर) में विलय हो जाता है, हम परिभाषा के अनुसार, एक नई रिलीज प्राप्त करते हैं। हम इस नियम को बहुत सख्ती से लेने का प्रयास करते हैं, इसलिए, सिद्धांत रूप में, हम अपने उत्पादों को स्वचालित रूप से इकट्ठा करने के लिए गिट हुक का उपयोग कर सकते हैं और उन्हें मुख्य शाखा (मास्टर) के लिए प्रत्येक प्रतिबद्ध पर उत्पादन सर्वर पर डाल सकते हैं।

सहायक शाखाएँ

मुख्य शाखाओं के मालिक और विकसित होने के अलावा, हमारे विकास मॉडल में कई प्रकार की सहायक शाखाएं शामिल हैं, जिनका उपयोग टीम के सदस्यों के बीच विकास को समानांतर बनाने, नई सुविधाओं के कार्यान्वयन को सरल बनाने, रिलीज तैयार करने और आवेदन के उत्पादन संस्करण में समस्याओं को जल्दी से ठीक करने के लिए किया जाता है। मुख्य शाखाओं के विपरीत, इन शाखाओं में हमेशा एक सीमित जीवनकाल होता है। उनमें से प्रत्येक अंततः जल्दी या बाद में छोड़ देता है।



हम निम्नलिखित प्रकार की शाखाओं का उपयोग करते हैं:

• फ़ीचर शाखाएँ
• रिलीज शाखाएं
• हॉटफ़िक्स शाखाएँ

प्रत्येक प्रकार की शाखा का अपना विशिष्ट उद्देश्य और नियमों का एक सख्त सेट होता है, जिसमें से वे शाखाएँ उत्पन्न की जा सकती हैं, और जिसमें उन्हें विलय करना होगा। अब हम उन्हें बदले में विचार करेंगे।



बेशक, एक तकनीकी दृष्टिकोण से, इन शाखाओं में "विशिष्ट" कुछ भी नहीं है। श्रेणियों में शाखाओं का विभाजन केवल इस संदर्भ में मौजूद है कि उनका उपयोग कैसे किया जाता है। और बाकी सब कुछ गिट की अच्छी पुरानी शाखाएं हैं।

फ़ीचर शाखाएँ

से उत्पन्न हो सकता है: विकास

में प्रवाह होना चाहिए: विकास

नामकरण सम्मेलन: मास्टर, डेवलप, रिलीज़- * या हॉटफ़िक्स- * को छोड़कर सब कुछ



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



फ़ीचर शाखाएँ आमतौर पर डेवलपर रिपॉजिटरी में मौजूद होती हैं, लेकिन मुख्य रिपॉजिटरी (मूल) में नहीं।

एक सुविधा शाखा बनाना

जब आप नई कार्यक्षमता पर काम करना शुरू करते हैं, तो एक शाखा को विकसित शाखा से बनाया जाता है।



$ git checkout -b myfeature develop

Switched to a new branch "myfeature"

विकसित करने के लिए पूर्ण कार्यक्षमता जोड़ना

पूर्ण कार्यक्षमता (सुविधा) वापस विकसित शाखा में विलीन हो जाती है और अगली रिलीज में बदल जाती है।



$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff myfeature

Updating ea1b82a..05e9557

( )

$ git branch -d myfeature

Deleted branch myfeature (was 05e9557).

$ git push origin develop







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







दूसरे मामले में, परिवर्तन के इतिहास को देखना असंभव है जो विशेष रूप से प्रतिबद्ध वस्तुएं एक साथ कार्यक्षमता बनाती हैं - इसके लिए आपको कमिट में सभी संदेशों को मैन्युअल रूप से पढ़ना होगा। इस मामले में, संपूर्ण कार्यक्षमता (यानी, कमिट्स का एक समूह) को सिरदर्द के बिना रद्द करना असंभव है, और -no-ff ध्वज के साथ यह प्राथमिक रूप से किया जाता है।



बेशक, यह दृष्टिकोण कुछ अतिरिक्त मात्रा में (खाली) प्रतिबद्ध वस्तुओं का निर्माण करता है, लेकिन परिणामी लाभ इस तरह की कीमत को सही ठहराते हैं।



दुर्भाग्य से, मैंने अभी तक यह नहीं पाया है कि आप गिट को कैसे कॉन्फ़िगर कर सकते हैं ताकि - कोई एफएफ डिफ़ॉल्ट मर्ज व्यवहार न हो। लेकिन इस विधि को लागू किया जाना चाहिए।

रिलीज शाखाएं

से उत्पन्न हो सकता है: विकास

में प्रवाह होना चाहिए: विकसित और मास्टर

नामकरण कन्वेंशन: जारी- *



किसी उत्पाद के नए संस्करणों की रिलीज़ के लिए तैयार करने के लिए रिलीज़ शाखाओं का उपयोग किया जाता है। वे आपको एक नया संस्करण जारी करने से पहले अंतिम बिंदुओं पर रखने की अनुमति देते हैं। इसके अलावा, मामूली सुधार उन्हें जोड़ा जा सकता है, साथ ही अगली रिलीज के लिए मेटाडेटा (संस्करण संख्या, निर्माण तिथि, आदि)। जब यह सभी कार्य रिलीज़ शाखा को सबमिट किया जाता है, तो मुख्य विकास शाखा को आगे की सुविधाओं को जोड़ने के लिए साफ किया जाता है (जो अगले बड़ी रिलीज में शामिल किया जाएगा)।



एक नई रिलीज शाखा को ऐसे समय में उत्पन्न किया जाना चाहिए जब विकास शाखा की स्थिति पूरी तरह से या लगभग पूरी तरह से नई रिलीज के अनुरूप आवश्यकताओं को पूरा करती है। कम से कम, इस रिलीज के लिए आवश्यक सभी आवश्यक कार्यक्षमता पहले से ही विकसित शाखा में डाली गई है। अगले रिलीज़ के लिए इच्छित कार्यक्षमता का उल्लंघन नहीं किया जा सकता है। यह तब भी बेहतर है जब इन कार्यक्षमता के लिए शाखाएं तब तक इंतजार करें जब तक कि वर्तमान रिलीज शाखा विकसित शाखा से अलग न हो जाए।



अगली रिलीज़ को अपना संस्करण नंबर केवल उस समय मिलता है जब इसके लिए एक नई शाखा बनाई जाती है, लेकिन पहले से कोई मामला नहीं है। इस बिंदु तक, विकास शाखा में "नई रिलीज़" के लिए परिवर्तन शामिल हैं, लेकिन जब तक रिलीज़ शाखा को अलग नहीं किया जाता है, तब तक यह ज्ञात नहीं है कि इस रिलीज़ में संस्करण 0.3, या 1.0, या कुछ अन्य संस्करण होंगे। निर्णय नई रिलीज शाखा बनाते समय किया जाता है और परियोजना द्वारा अपनाई गई परियोजना संस्करण संख्या नियमों पर निर्भर करता है।

एक रिलीज शाखा बनाना

एक रिलीज शाखा एक विकसित शाखा से बनाई गई है। उदाहरण के लिए, वर्तमान रिलीज़ रिलीज़ का संस्करण 1.1.5 है, और रास्ते में परिवर्तनों से भरा एक नया बड़ा रिलीज़ है। विकसित शाखा "अगली रिलीज़" के लिए तैयार है, और हम तय करते हैं कि इस रिलीज़ का संस्करण 1.2 होगा (और 1.1.6 या 2.0 नहीं)। इस मामले में, हम एक नई शाखा बनाते हैं और इसे परियोजना के नए संस्करण के नाम देते हैं:



$ git checkout -b release-1.2 develop

Switched to a new branch "release-1.2"

$ ./bump-version.sh 1.2

Files modified successfully, version bumped to 1.2.

$ git commit -a -m "Bumped version number to 1.2"

[release-1.2 74d9424] Bumped version number to 1.2

1 files changed, 1 insertions(+), 1 deletions(-)







हमने एक नई शाखा बनाई, इसे स्विच किया और फिर संस्करण संख्या (टक्कर संस्करण संख्या) सेट की। हमारे उदाहरण में, bump-version.sh एक काल्पनिक लिपि है, जो एक नई प्रति में एक नया संस्करण लिखकर कुछ फाइलों को संशोधित करती है। (बेशक, आप इन परिवर्तनों को मैन्युअल रूप से भी कर सकते हैं; मैं सिर्फ इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि कुछ फाइलें बदल रही हैं।) फिर हम परियोजना के नए संस्करण के साथ प्रतिबद्ध हैं।



यह नई शाखा कुछ समय के लिए मौजूद हो सकती है, जब तक कि नई रिलीज़ अंततः रिलीज़ के लिए तैयार न हो जाए। इस समय के दौरान, इस शाखा में पाए जाने वाले कीड़े के सुधार को जोड़ा जा सकता है (और विकसित नहीं करने के लिए)। लेकिन इस शाखा में बड़े नए बदलाव लाना सख्त वर्जित है। उन्हें हमेशा विकसित शाखा में प्रवाह करना चाहिए और अगली बड़ी रिलीज की प्रतीक्षा करनी चाहिए।

एक रिलीज शाखा को बंद करना

जब हम तय करते हैं कि रिलीज शाखा रिलीज के लिए तैयार है, तो हमें कुछ चीजें करने की जरूरत है। सबसे पहले, रिलीज शाखा मुख्य शाखा में विलीन हो जाती है (मैं आपको याद दिलाता हूं, प्रत्येक मास्टर प्रतिबद्ध है, परिभाषा के अनुसार, एक नया रिलीज)। अगला, मास्टर में इस कमिट को टैग किया जाना चाहिए ताकि बाद में आप उत्पाद के किसी भी मौजूदा संस्करण तक आसानी से पहुंच सकें। अंत में, रिलीज़ शाखा में किए गए परिवर्तनों को वापस विकास शाखा (डेवलप ब्रांच) में जोड़ा जाना चाहिए ताकि भविष्य के रिलीज़ में बग फिक्स भी हो।



Git में पहले दो चरण:



$ git checkout master

Switched to branch 'master'

$ git merge --no-ff release-1.2

Merge made by recursive.

( )

$ git tag -a 1.2







अब रिलीज़ को प्रकाशित और टैग किया गया है।



ध्यान दें : यदि वांछित है, तो आप क्रिप्टोग्राफिक रूप से टैग पर हस्ताक्षर करने के लिए -s या -u <कुंजी> झंडे का उपयोग कर सकते हैं।



भविष्य की रिलीज़ में परिवर्तन सहेजने के लिए, हमें इन परिवर्तनों को वापस विकास में शामिल करना चाहिए। हम इसे इस तरह करते हैं:



$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff release-1.2

Merge made by recursive.

( )







यह कदम, सिद्धांत रूप में, एक विलय संघर्ष का कारण बन सकता है (यह अक्सर ऐसा होता है कि संघर्ष का कारण परियोजना संस्करण संख्या में बदलाव है)। यदि ऐसा होता है, तो उन्हें सुधारें और एक प्रतिबद्ध जारी करें।



अब हम अंत में रिलीज शाखा के साथ समाप्त हो गए हैं। आप इसे हटा सकते हैं, क्योंकि अब हमें इसकी आवश्यकता नहीं है:



$ git branch -d release-1.2

Deleted branch release-1.2 (was ff452fe).

हॉटफ़िक्स शाखाएँ

से उत्पन्न हो सकता है: गुरु

में प्रवाह होना चाहिए: विकसित और मास्टर

नामकरण कन्वेंशन: हॉटफिक्स- *



हॉटफ़िक्स शाखाएँ, रिलीज़ होने वाली शाखाओं से बहुत मिलती-जुलती हैं, क्योंकि इनका उपयोग नए उत्पाद रिलीज़ तैयार करने के लिए भी किया जाता है, जब तक कि यह अनियोजित न हो। वे उत्पाद के उत्पादन संस्करण के अवांछनीय व्यवहार को तुरंत ठीक करने की आवश्यकता के कारण होते हैं। जब एक बग उत्पादन संस्करण में पाया जाता है जिसे तुरंत ठीक करने की आवश्यकता होती है, तो मास्टर शाखा के लिए इसी मास्टर संस्करण टैग से एक नई शाखा तैयार की जाती है जो फिक्स पर काम करती है।



इसके अस्तित्व का अर्थ यह है कि विकसित शाखा पर टीम का काम चुपचाप जारी रह सकता है, जबकि एक उत्पादन संस्करण के लिए एक त्वरित निर्धारण तैयार कर रहा है।

एक हॉटफिक्स शाखा बनाना

मास्टर शाखा से हॉटफ़िक्स शाखाएँ बनाई जाती हैं। उदाहरण के लिए, वर्तमान उत्पादन रिलीज़ का संस्करण 1.2 है, और इसमें (अचानक!) एक गंभीर बग का पता चला है। और विकास शाखा में परिवर्तन (विकास) एक नई रिलीज में प्रकाशित होने के लिए पर्याप्त स्थिर नहीं हैं। लेकिन हम एक नई पैच शाखा बना सकते हैं और समस्या के समाधान पर काम करना शुरू कर सकते हैं:



$ git checkout -b hotfix-1.2.1 master

Switched to a new branch "hotfix-1.2.1"

$ ./bump-version.sh 1.2.1

Files modified successfully, version bumped to 1.2.1.

$ git commit -a -m "Bumped version number to 1.2.1"

[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1

1 files changed, 1 insertions(+), 1 deletions(-)







शाखा बनाने के बाद संस्करण संख्या को अपडेट करना याद रखें!



अब आप बग को ठीक कर सकते हैं, और कम से कम एक कम से कम कई के साथ बदलाव प्रकाशित कर सकते हैं।



$ git commit -m "Fixed severe production problem"

[hotfix-1.2.1 abbe5d6] Fixed severe production problem

5 files changed, 32 insertions(+), 17 deletions(-)

एक पैच शाखा को बंद करना

जब बग ठीक हो जाता है, तो परिवर्तन को मुख्य शाखा (मास्टर), साथ ही विकास शाखा (विकसित) में वापस डालना चाहिए, यह सुनिश्चित करने के लिए कि यह फिक्स अगली रिलीज में दिखाई देगा। यह एक रिलीज शाखा को बंद करने के तरीके के समान है।



सबसे पहले, आपको मुख्य शाखा (मास्टर) को अपडेट करने और एक टैग के साथ नए संस्करण को टैग करने की आवश्यकता है।



$ git checkout master

Switched to branch 'master'

$ git merge --no-ff hotfix-1.2.1

Merge made by recursive.

( )

$ git tag -a 1.2.1







ध्यान दें : यदि वांछित है, तो आप क्रिप्टोग्राफिक रूप से टैग पर हस्ताक्षर करने के लिए -s या -u <कुंजी> झंडे का उपयोग कर सकते हैं।



अगला कदम फिक्स को विकसित शाखा में स्थानांतरित करना है।



$ git checkout develop

Switched to branch 'develop'

$ git merge --no-ff hotfix-1.2.1

Merge made by recursive.

( )







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



अंत में, अस्थायी शाखा हटाएं:



$ git branch -d hotfix-1.2.1

Deleted branch hotfix-1.2.1 (was abbe5d6).

निष्कर्ष

हालाँकि इस शाखामिलन मॉडल में मौलिक रूप से कुछ भी नया नहीं है, फिर भी "बड़ी तस्वीर" जिसके साथ यह लेख शुरू हुआ है, हमारी परियोजनाओं में खुद को सर्वश्रेष्ठ साबित किया है। यह एक सुरुचिपूर्ण मानसिक मॉडल बनाता है, जो एक नज़र से पूरी तरह से पकड़ना आसान है, और जो आपको टीम की संयुक्त समझ बनाने और प्रक्रियाओं को विलय करने की अनुमति देता है जो परियोजना पर काम कर रहे हैं।



इस छवि का उच्च गुणवत्ता वाला पीडीएफ संस्करण यहां डाउनलोड करने के लिए स्वतंत्र है । इसे प्रिंट करें और अपनी दीवार पर लटकाएं ताकि इसे किसी भी समय एक्सेस किया जा सके।



लगभग। अनुवादक: लेख नया नहीं है, मूल का लिंक पहले ही हब पर दिखाई दे चुका है यह अनुवाद उन लोगों के लिए है जिनके लिए अंग्रेजी अभी भी इतनी आसान नहीं है (और साथ ही मेरे सहयोगियों के लिए, जिनके बीच मैं प्रचार, हेह में व्यस्त हूं)। लेख में वर्णित प्रक्रियाओं को स्वचालित करने के लिए, लेखक ने एक गिटफ्लो परियोजना बनाई, जिसे जीथबब पर पाया जा सकता है ।