क्या आपने Git कमांड सीखे हैं लेकिन कल्पना करना चाहते हैं कि निरंतर एकीकरण (CI) वास्तविकता में कैसे काम करता है? या शायद आप अपनी दैनिक गतिविधियों को अनुकूलित करना चाहते हैं? यह पाठ्यक्रम आपको GitHub रिपॉजिटरी का उपयोग करके निरंतर एकीकरण में व्यावहारिक कौशल प्रदान करेगा। इस कोर्स का उद्देश्य एक जादूगर बनना नहीं है जिसे आप आसानी से क्लिक कर सकते हैं; इसके विपरीत, आप वही कार्य करेंगे जो लोग वास्तव में काम पर करते हैं, उसी तरह जैसे वे करते हैं। जैसे-जैसे आप इसमें शामिल चरणों से गुजरेंगे, मैं सिद्धांत समझाऊंगा।

हम क्या करें?

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

जैसे-जैसे आप पाठ्यक्रम में आगे बढ़ते हैं, यह GIF आपके रिपॉजिटरी में कमिट को योजनाबद्ध रूप से दिखाता है। जैसा कि आप देख सकते हैं, यहां कुछ भी जटिल नहीं है और केवल सबसे आवश्यक है।

आप निम्नलिखित मानक सीआई परिदृश्यों से गुजरेंगे:

• एक फीचर पर काम करें;
• गुणवत्ता सुनिश्चित करने के लिए स्वचालित परीक्षणों का अनुप्रयोग;
• प्राथमिकता वाले कार्य का कार्यान्वयन;
• शाखाओं का विलय करते समय संघर्ष समाधान (विलय संघर्ष);
• उत्पादन परिवेश में कोई त्रुटि उत्पन्न होती है.

आप क्या सीखेंगे?

आप निम्नलिखित प्रश्नों का उत्तर देने में सक्षम होंगे:

• सतत एकीकरण (सीआई) क्या है?
• सीआई में किस प्रकार के स्वचालित परीक्षणों का उपयोग किया जाता है, और वे किन क्रियाओं के जवाब में ट्रिगर होते हैं?
• पुल अनुरोध क्या हैं और उनकी आवश्यकता कब होती है?
• टेस्ट ड्रिवेन डेवलपमेंट (टीडीडी) क्या है और यह सीआई से कैसे संबंधित है?
• क्या मुझे परिवर्तनों को मर्ज करना चाहिए या पुनः आधार बनाना चाहिए?
• वापस रोल करें या अगले संस्करण में ठीक करें?

सबसे पहले मैंने हर जगह "पुल रिक्वेस्ट" जैसी चीजों का अनुवाद किया, लेकिन परिणामस्वरूप मैंने पाठ में पागलपन की डिग्री को कम करने के लिए कुछ स्थानों पर अंग्रेजी में वाक्यांशों को वापस करने का फैसला किया। मैं कभी-कभी "प्रोग्रामर सुरज़िक" का उपयोग अद्भुत क्रिया "कमिट" की तरह करूंगा जहां लोग वास्तव में इसे काम पर उपयोग करते हैं।

सतत एकीकरण क्या है?

लगातार एकीकरण, या सीआई, एक तकनीकी अभ्यास है जिसमें प्रत्येक टीम का सदस्य दिन में कम से कम एक बार अपने कोड को एक सामान्य रिपॉजिटरी में एकीकृत करता है, और परिणामी कोड कम से कम त्रुटियों के बिना बनाया जाना चाहिए।

इस शब्द को लेकर मतभेद हैं

विवाद का मुद्दा एकीकरण की आवृत्ति है। कुछ लोगों का तर्क है कि दिन में केवल एक बार कोड को मर्ज करना वास्तव में लगातार एकीकृत करने के लिए पर्याप्त नहीं है। एक टीम का उदाहरण दिया गया है जहां हर कोई सुबह ताजा कोड लेता है और शाम को उसे एकीकृत करता है। हालांकि यह एक उचित आपत्ति है, आम तौर पर यह माना जाता है कि दिन में एक बार की परिभाषा काफी व्यावहारिक, विशिष्ट और विभिन्न आकारों की टीमों के लिए उपयुक्त है।

एक और आपत्ति यह है कि C++ अब विकास में उपयोग की जाने वाली एकमात्र भाषा नहीं है, और सत्यापन के तरीके के रूप में त्रुटि-मुक्त असेंबली की आवश्यकता कमजोर है। परीक्षणों के कुछ सेट (उदाहरण के लिए, स्थानीय स्तर पर निष्पादित इकाई परीक्षण) को भी सफलतापूर्वक पूरा करना होगा। फिलहाल, समुदाय इसे एक आवश्यकता बनाने की दिशा में आगे बढ़ रहा है, और भविष्य में "बिल्ड + यूनिट परीक्षण" संभवतः आम अभ्यास बन जाएगा, अगर यह पहले से ही नहीं हुआ है।

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

उन चरणों की सूची जिनका हम पूरे पाठ्यक्रम में उपयोग करेंगे

1. नवीनतम कोड खींचें. से एक शाखा बनाएं master. काम शुरू।
2. अपनी नई शाखा पर कमिट बनाएँ। स्थानीय स्तर पर निर्माण और परीक्षण करें। उत्तीर्ण? अगले चरण पर जाएं। असफल? त्रुटियों या परीक्षणों को ठीक करें और पुनः प्रयास करें।
3. अपने दूरस्थ रिपॉजिटरी या दूरस्थ शाखा पर पुश करें।
4. एक पुल अनुरोध बनाएं. परिवर्तनों पर चर्चा करें, चर्चा जारी रहने पर और प्रतिबद्धताएँ जोड़ें। फ़ीचर शाखा पर परीक्षण पास करें।
5. मास्टर से कमिट को मर्ज/रीबेस करें। मर्ज परिणाम पर परीक्षण पास करें।
6. फ़ीचर शाखा से उत्पादन तक परिनियोजन करें.
7. यदि कुछ समय तक उत्पादन में सब कुछ अच्छा रहता है, तो मर्ज को मास्टर में बदल दिया जाता है।

️तैयारी

सुनिश्चित करें कि आपके पास सही सॉफ़्टवेयर है

इस कोर्स को करने के लिए आपको आवश्यकता होगी Node.js и गिट क्लाइंट.

आप किसी भी Git क्लाइंट का उपयोग कर सकते हैं, लेकिन मैं केवल कमांड लाइन के लिए कमांड प्रदान करूंगा।

सुनिश्चित करें कि आपके पास एक Git क्लाइंट स्थापित है जो कमांड लाइन का समर्थन करता है

यदि आपके पास अभी तक Git क्लाइंट नहीं है जो कमांड लाइन का समर्थन करता है, तो आप इंस्टॉलेशन निर्देश पा सकते हैं यहां.

भंडार तैयार करें

आपको एक व्यक्तिगत प्रतिलिपि (कांटा) बनाने की आवश्यकता होगी पाठ्यक्रम के लिए कोड के साथ टेम्पलेट रिपॉजिटरी GitHub पर. आइए इसे व्यक्तिगत प्रति कहने पर सहमत हों पाठ्यक्रम भंडार.

हो गया? यदि आपने डिफ़ॉल्ट सेटिंग्स नहीं बदली हैं, तो संभवतः आपके पाठ्यक्रम भंडार को कॉल किया जाएगा continuous-integration-team-scenarios-students, यह आपके GitHub खाते में स्थित है और URL इस तरह दिखता है

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

मैं बस इस पते पर कॉल करूंगा <URL репозитория>.

कोण कोष्ठक जैसे <тут> इसका मतलब यह होगा कि आपको ऐसी अभिव्यक्ति को उचित मान से बदलना होगा।

सुनिश्चित करें कि GitHub क्रियाएँ इस पाठ्यक्रम भंडार के लिए शामिल किया गया। यदि वे सक्षम नहीं हैं, तो कृपया पृष्ठ के मध्य में बड़े बटन पर क्लिक करके उन्हें सक्षम करें, जिसे आप GitHub इंटरफ़ेस में क्रियाएँ पर क्लिक करके प्राप्त कर सकते हैं।

यदि GitHub क्रियाएँ सक्षम नहीं हैं तो आप मेरे निर्देशों का पालन करते हुए पाठ्यक्रम पूरा नहीं कर पाएंगे।

हम यहां जो सूची बना रहे हैं उसकी वर्तमान स्थिति देखने के लिए आप मार्कडाउन को प्रस्तुत करने के लिए हमेशा GitHub की क्षमता का उपयोग कर सकते हैं

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

उत्तर के बारे में

हालाँकि इस कोर्स को पूरा करने का सबसे अच्छा तरीका इसे स्वयं करना है, लेकिन आपको कुछ कठिनाइयाँ हो सकती हैं।

यदि आपको लगता है कि आप समझ नहीं पा रहे हैं कि क्या करना है और आप जारी नहीं रख सकते हैं, तो आप इस सूत्र पर गौर कर सकते हैं solution, जो आपके प्रारंभ भंडार में है।
कृपया विलय न करें solution в master अध्ययन के दौरान। आप इस शाखा का उपयोग यह पता लगाने के लिए कर सकते हैं कि क्या करना है, या Git द्वारा हमें दी गई सभी क्षमताओं का उपयोग करके अपने कोड की तुलना लेखक के कोड से करने के लिए कर सकते हैं। यदि आप पूरी तरह से खो गए हैं, तो आप अपनी शाखा को पूरी तरह से बदल सकते हैं master एक शाखा पर solution और फिर अपनी कार्यशील निर्देशिका को आपके आवश्यक पाठ्यक्रम चरण पर रीसेट करें।

इसका उपयोग केवल तभी करें जब आपको वास्तव में इसकी आवश्यकता हो

अपना कोड प्रतिबद्ध करें

git add .
git commit -m "Backing up my work"

ये आदेश

• नाम बदलने master в master-backup;
• नाम बदलने solution в master;
• एक नई शाखा के लिए चेकआउट करें master और कार्यशील निर्देशिका की सामग्री को फिर से लिखें;
• यदि आपको भविष्य में "समाधान" शाखा की आवश्यकता हो तो "मास्टर" (जो "समाधान" हुआ करता था) से एक "समाधान" शाखा बनाएं।

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

इन स्टेप्स के बाद आप इस्तेमाल कर सकते हैं git log master यह पता लगाने के लिए कि आपको किस प्रतिबद्धता की आवश्यकता है।
आप अपनी कार्यशील निर्देशिका को इस प्रकार इस कमिट पर रीसेट कर सकते हैं:

git reset --hard <the SHA you need>

यदि आप परिणाम से खुश हैं, तो किसी बिंदु पर आपको रिपॉजिटरी के अपने संस्करण को दूरस्थ रिपॉजिटरी में प्रकाशित करने की आवश्यकता होगी। जब आप ऐसा करें तो दूरस्थ शाखा को स्पष्ट रूप से निर्दिष्ट करना न भूलें।

git push --force origin master

कृपया ध्यान दें कि हम उपयोग करते हैं git push --force. यह संभावना नहीं है कि आप ऐसा अक्सर करना चाहेंगे, लेकिन हमारे पास यहां एक रिपॉजिटरी उपयोगकर्ता के साथ एक बहुत ही विशिष्ट परिदृश्य है, जो इसके अलावा समझता है कि वह क्या कर रहा है।

काम शुरू

आइए सीआई चरणों की हमारी सूची संकलित करना शुरू करें। आम तौर पर आप रिमोट रिपॉजिटरी से कोड के नवीनतम संस्करण की जांच करके इस चरण को शुरू करेंगे, लेकिन हमारे पास अभी तक कोई स्थानीय रिपॉजिटरी नहीं है, इसलिए हम इसे रिमोट से क्लोन करते हैं।

️ कार्य: स्थानीय रिपॉजिटरी को अपडेट करें, एक शाखा बनाएं master, काम शुरू

1. से पाठ्यक्रम भंडार को क्लोन करें <URL репозитория>.
2. प्रारंभ npm install पाठ्यक्रम भंडार निर्देशिका में; हमें जेस्ट स्थापित करने के लिए इसकी आवश्यकता है, जिसका उपयोग हम परीक्षण चलाने के लिए करते हैं।
3. एक शाखा बनाएं और उसका नाम रखें feature. इस थ्रेड पर स्विच करें.

4. इसमें परीक्षण कोड जोड़ें ci.test.js टिप्पणियों के बीच मुझसे ऐसा करने के लिए कहा गया।

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. फ़ाइल में पहले 4 चरणों के साथ टेक्स्ट जोड़ें ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   आदेशों

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

एक नई शाखा पर कमिट बनाएं, स्थानीय स्तर पर निर्माण और परीक्षण करें

हम कमिट करने से पहले चलाने के लिए परीक्षण सेट करने जा रहे हैं, और फिर कोड कमिट करेंगे।

विशिष्ट परिदृश्य जब परीक्षण स्वचालित रूप से चलते हैं

• स्थानीय रूप से:
  • लगातार या उचित कोड परिवर्तनों के जवाब में;
  • सहेजने पर (व्याख्यायित या जेआईटी-संकलित भाषाओं के लिए);
  • असेंबली के दौरान (जब संकलन की आवश्यकता हो);
  • प्रतिबद्ध पर;
  • किसी साझा भंडार में प्रकाशित करते समय।

• बिल्ड सर्वर या बिल्ड वातावरण पर:
  • जब कोड किसी निजी शाखा/भंडार में प्रकाशित किया जाता है।
  • इस थ्रेड के कोड का परीक्षण किया जा रहा है.
  • विलय के संभावित परिणाम का परीक्षण किया जाता है (आमतौर पर master).
  • एक सतत एकीकरण चरण/निरंतर वितरण पाइपलाइन के रूप में

आमतौर पर, एक परीक्षण सूट जितनी तेजी से चलता है, उतनी ही अधिक बार आप इसे चलाने का जोखिम उठा सकते हैं। एक विशिष्ट चरण वितरण इस तरह दिख सकता है।

• तीव्र इकाई परीक्षण - निर्माण के दौरान, सीआई पाइपलाइन में
• धीमी इकाई परीक्षण, तेज़ घटक और एकीकरण परीक्षण - प्रतिबद्धता पर, सीआई पाइपलाइन में
• धीमे घटक और एकीकरण परीक्षण - सीआई पाइपलाइन में
• सुरक्षा परीक्षण, लोड परीक्षण और अन्य समय लेने वाली या महंगी परीक्षण - सीआई/सीडी पाइपलाइनों में, लेकिन केवल निर्माण के कुछ मोड/चरणों/पाइपलाइनों में, उदाहरण के लिए, रिलीज उम्मीदवार तैयार करते समय या मैन्युअल रूप से चलाते समय।

️कार्य

मेरा सुझाव है कि पहले कमांड का उपयोग करके परीक्षण मैन्युअल रूप से चलाएं npm test. उसके बाद, आइए अपने परीक्षणों को कमिट पर चलाने के लिए एक git हुक जोड़ें। एक समस्या है: Git हुक को रिपॉजिटरी का हिस्सा नहीं माना जाता है और इसलिए इसे बाकी पाठ्यक्रम सामग्री के साथ GitHub से क्लोन नहीं किया जा सकता है। हुक स्थापित करने के लिए आपको दौड़ना होगा install_hook.sh या फ़ाइल कॉपी करें repo/hooks/pre-commit स्थानीय निर्देशिका के लिए .git/hooks/.
जब आप प्रतिबद्ध होते हैं, तो आप देखेंगे कि परीक्षण चलाए गए हैं और वे यह देखने के लिए जांच करते हैं कि सूची में कुछ कीवर्ड मौजूद हैं या नहीं।

1. कमांड चलाकर मैन्युअल रूप से परीक्षण चलाएँ npm test आपके पाठ्यक्रम भंडार फ़ोल्डर में। सत्यापित करें कि परीक्षण पूरे हो गए हैं.
2. चलाकर एक कमिट हुक (प्री-कमिट हुक) सेट करें install_hook.sh.
3. अपने परिवर्तनों को अपने स्थानीय भंडार में जमा करें।
4. सुनिश्चित करें कि प्रतिबद्ध होने से पहले परीक्षण चलाए जाएं।

इन चरणों का पालन करने के बाद आपकी रिपॉजिटरी इस तरह दिखनी चाहिए।

आदेशों

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

किसी दूरस्थ रिपॉजिटरी या दूरस्थ शाखा में कोड प्रकाशित करें

एक बार जब वे स्थानीय स्तर पर काम पूरा कर लेते हैं, तो डेवलपर्स आमतौर पर अपना कोड सार्वजनिक रूप से उपलब्ध कराते हैं ताकि अंततः इसे जनता के साथ एकीकृत किया जा सके। GitHub के साथ, यह आम तौर पर कार्य को रिपॉजिटरी की एक व्यक्तिगत प्रति (व्यक्तिगत कांटा) या एक व्यक्तिगत शाखा में प्रकाशित करके प्राप्त किया जाता है।

• फोर्क्स के साथ, एक डेवलपर एक रिमोट शेयर्ड रिपॉजिटरी को क्लोन करता है, इसकी एक व्यक्तिगत रिमोट कॉपी बनाता है, जिसे फोर्क के रूप में भी जाना जाता है। इसके बाद यह स्थानीय स्तर पर काम करने के लिए इस व्यक्तिगत भंडार को क्लोन करता है। जब काम पूरा हो जाता है और प्रतिबद्धताएं पूरी हो जाती हैं, तो वह उन्हें अपने फोर्क में धकेल देता है, जहां वे दूसरों के लिए उपलब्ध होते हैं और सामान्य भंडार में एकीकृत किए जा सकते हैं। यह दृष्टिकोण आमतौर पर GitHub पर ओपन सोर्स प्रोजेक्ट्स में उपयोग किया जाता है। इसका उपयोग मेरे उन्नत पाठ्यक्रम [टीम वर्क और सीआई विद गिट] में भी किया जाता है।http://devops.redpill.solutions/).
• दूसरा तरीका केवल एक रिमोट रिपॉजिटरी का उपयोग करना और केवल शाखा की गिनती करना है master साझा भंडार "संरक्षित"। इस परिदृश्य में, व्यक्तिगत डेवलपर्स अपने कोड को दूरस्थ रिपॉजिटरी की शाखाओं में प्रकाशित करते हैं ताकि अन्य लोग इस कोड को देख सकें, यदि सब कुछ क्रम में है, तो इसे मर्ज करें master साझा भंडार.

इस विशेष पाठ्यक्रम में, हम एक वर्कफ़्लो का उपयोग करेंगे जो शाखाओं का उपयोग करता है।

आइए अपना कोड प्रकाशित करें।

️कार्य

• अपनी कार्यशील शाखा के समान नाम से किसी दूरस्थ शाखा में परिवर्तन प्रकाशित करें

आदेशों

git push --set-upstream origin feature

एक पुल अनुरोध बनाएं

शीर्षक के साथ पुल अनुरोध बनाएं चरणों की समीक्षा... इंस्टॉल feature जैसे "मुख्य शाखा" और master जैसे "आधार शाखा"।

सुनिश्चित करें कि आपने इंस्टॉल कर लिया है master से पहले रिपॉजिटरी को फोर्क करें "आधार शाखा" के रूप में, मैं पाठ्यक्रम सामग्री भंडार में बदलाव के अनुरोधों का जवाब नहीं दूंगा।

GitHub भाषा में, "बेस ब्रांच" वह शाखा है जिस पर आप अपना काम आधारित करते हैं, और "हेड ब्रांच" वह शाखा है जिसमें प्रस्तावित परिवर्तन होते हैं।

परिवर्तनों पर चर्चा करें, चर्चा जारी रहने पर नई प्रतिबद्धताएँ जोड़ें

पुल अनुरोध(पीआर)

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

आपको वास्तव में GitHub या समान प्लेटफ़ॉर्म की पुल अनुरोध सुविधा का उपयोग करने की आवश्यकता नहीं है। विकास दल आमने-सामने संचार, वॉयस कॉल या ईमेल सहित संचार के अन्य तरीकों का उपयोग कर सकते हैं, लेकिन फ़ोरम-शैली पुल अनुरोधों का उपयोग करने के अभी भी कई कारण हैं। उनमें से कुछ यहां हैं:

• विशिष्ट कोड परिवर्तनों से संबंधित संगठित चर्चाएँ;
• ऑटोटेस्टर और साथियों दोनों से प्रगति पर काम पर प्रतिक्रिया देखने के स्थान के रूप में;
• कोड समीक्षाओं को औपचारिक बनाना;
• ताकि बाद में आप इस या उस कोड के टुकड़े के पीछे के कारणों और विचारों का पता लगा सकें।

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

आमतौर पर, पीआर बनाते समय, आप निम्नलिखित कार्य करते हैं।

• बताएं कि आप क्या और कहां बदलाव का प्रस्ताव रखते हैं।
• परिवर्तनों के उद्देश्य को समझाते हुए एक विवरण लिखें। आप चाहेंगे:
  • कुछ भी महत्वपूर्ण जोड़ें जो कोड से स्पष्ट न हो, या संदर्भ को समझने के लिए कुछ उपयोगी हो, जैसे प्रासंगिक #बग और कमिट नंबर;
  • @जिस किसी के साथ आप काम करना शुरू करना चाहते हैं उसका उल्लेख करें, या आप बाद में टिप्पणियों में उनका @उल्लेख कर सकते हैं;
  • सहकर्मियों से किसी चीज़ में मदद करने या किसी विशिष्ट चीज़ की जाँच करने के लिए कहें।

एक बार जब आप पीआर खोलते हैं, तो ऐसे मामलों में चलाने के लिए कॉन्फ़िगर किए गए परीक्षण निष्पादित होते हैं। हमारे मामले में, यह परीक्षणों का वही सेट होगा जो हमने स्थानीय स्तर पर चलाया था, लेकिन एक वास्तविक परियोजना में अतिरिक्त परीक्षण और जांच हो सकती हैं।

कृपया परीक्षण पूरा होने तक प्रतीक्षा करें। आप GitHub इंटरफ़ेस में PR चर्चा के नीचे परीक्षणों की स्थिति देख सकते हैं। परीक्षण पूरा होने पर जारी रखें.

️ सीआई चरणों की सूची की यादृच्छिकता के बारे में एक नोट जोड़ें

इस पाठ्यक्रम में प्रयुक्त सूची मनमानी और व्यक्तिपरक है, हमें इस बारे में एक नोट जोड़ना चाहिए।

️ कार्य: इस टिप्पणी के लिए एक पुल अनुरोध बनाएं

1. शाखा में स्विच करें master.
2. नाम की एक शाखा बनाएं bugfix.
3. फ़ाइल के अंत में नोट टेक्स्ट जोड़ें ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. परिवर्तन प्रतिबद्ध करें.
5. सूत्र प्रकाशित करें bugfix एक दूरस्थ भंडार के लिए.
6. नाम से एक पुल अनुरोध बनाएँ एक टिप्पणी जोड़ रहा हूँ एक प्रमुख शाखा के साथ bugfix और आधार शाखाmaster.

सुनिश्चित करें कि आपने इंस्टॉल कर लिया है master से पहले रिपॉजिटरी को फोर्क करें "आधार शाखा" के रूप में, मैं पाठ्यक्रम सामग्री भंडार में बदलाव के अनुरोधों का जवाब नहीं दूंगा।

आपकी रिपॉजिटरी इस तरह दिखनी चाहिए।

आदेशों

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

पुल अनुरोध को स्वीकृत करें "एक टिप्पणी जोड़ना"

️कार्य

1. एक पुल अनुरोध बनाएं.
2. "मर्ज पुल अनुरोध" पर क्लिक करें।
3. "मर्ज की पुष्टि करें" पर क्लिक करें।
4. "शाखा हटाएँ" पर क्लिक करें, अब हमें इसकी आवश्यकता नहीं है।

यह मर्ज के बाद कमिट का एक आरेख है।

️ काम करते रहें और परीक्षण जोड़ते रहें

पुल अनुरोध पर सहयोग करने से अक्सर अतिरिक्त काम करना पड़ता है। यह आमतौर पर कोड समीक्षा या चर्चा का परिणाम होता है, लेकिन हमारे पाठ्यक्रम में हम सीआई चरणों की हमारी सूची में नए आइटम जोड़कर इसे मॉडल करने जा रहे हैं।

सतत एकीकरण में आम तौर पर कुछ परीक्षण कवरेज शामिल होती है। परीक्षण कवरेज आवश्यकताएँ अलग-अलग होती हैं और आमतौर पर "योगदान दिशानिर्देश" नामक दस्तावेज़ में पाई जाती हैं। हम इसे सरल रखेंगे और अपनी चेकलिस्ट में प्रत्येक पंक्ति के लिए एक परीक्षण जोड़ेंगे।

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

परीक्षण संचालित विकास (टीडीडी)

टीडीडी कोड से पहले परीक्षण लिखने की अनुशंसा करता है। टीडीडी का उपयोग करने वाला एक सामान्य वर्कफ़्लो इस तरह दिखता है।

1. एक परीक्षण जोड़ें.
2. सभी परीक्षण चलाएँ और सुनिश्चित करें कि नया परीक्षण विफल हो जाए।
3. कोड लिखें.
4. परीक्षण चलाएँ, सुनिश्चित करें कि सभी परीक्षण उत्तीर्ण हों।
5. अपने कोड को पुनः सक्रिय करें.
6. दोहराना।

क्योंकि जो परीक्षण विफल हो जाते हैं उनके परिणाम आमतौर पर लाल रंग में दिखाए जाते हैं, और जो परीक्षण उत्तीर्ण हो जाते हैं उनके परिणाम आमतौर पर हरे रंग में दिखाए जाते हैं, इस चक्र को लाल-हरा-रिफैक्टर के रूप में भी जाना जाता है।

️कार्य

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

1. शाखा में स्विच करें feature.

2. इन परीक्षणों को इसमें जोड़ें ci.test.js आखिरी कॉल के बाद it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. परीक्षण करने का प्रयास करें. अगर pre-commit हुक स्थापित है, प्रतिबद्ध प्रयास विफल हो जाएगा।
4. फिर इस टेक्स्ट को इसमें जोड़ें ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. स्थानीय स्तर पर परिवर्तन करें और प्रतिबद्ध हों।
6. शाखा में परिवर्तन पोस्ट करें feature.

अब आपके पास कुछ ऐसा होना चाहिए

आदेशों

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

विलय संघर्ष

चेंज रिक्वेस्ट पर जाएं चरणों की समीक्षा.

भले ही हमने कुछ भी गलत नहीं किया और हमारे कोड के परीक्षण पास हो गए, फिर भी हम शाखा का विलय नहीं कर सकते feature и master. ऐसा इसलिए है क्योंकि दूसरा धागा bugfix में विलय कर दिया गया master जब हम इस पीआर पर काम कर रहे थे।
यह एक ऐसी स्थिति पैदा करता है जहां दूरस्थ शाखा master जिस संस्करण पर हमने शाखा आधारित की है, उससे नया संस्करण है feature. इस वजह से हम सिर्फ HEAD को रिवाइंड नहीं कर सकते master धागे के अंत तक feature. इस स्थिति में, हमें या तो विलय करने या कमिट लागू करने की आवश्यकता है feature रिबेस master. यदि कोई विरोध न हो तो GitHub वास्तव में स्वचालित विलय कर सकता है। अफसोस, हमारी स्थिति में, दोनों शाखाओं में फ़ाइल में प्रतिस्पर्धी परिवर्तन हैं ci.md. इस स्थिति को मर्ज विरोध के रूप में जाना जाता है, और हमें इसे मैन्युअल रूप से हल करने की आवश्यकता है।

मर्ज करना या पुनः आधार बनाना

मर्ज

• एक अतिरिक्त मर्ज कमिट बनाता है और कार्य इतिहास सहेजता है।
  • शाखाओं की मूल प्रतिबद्धताओं को उनके मूल टाइमस्टैम्प और लेखकों के साथ संरक्षित करता है।
  • परिवर्तन अनुरोध चर्चाओं में प्रतिबद्धताओं के SHA और उनसे लिंक को सहेजता है।
• एक बार के संघर्ष समाधान की आवश्यकता है।
• कहानी को अरेखीय बनाता है.
  • शाखाओं की बड़ी संख्या (आईडीई केबल की याद दिलाती है) के कारण कहानी को पढ़ना मुश्किल हो सकता है।
  • स्वचालित डिबगिंग को और अधिक कठिन बना देता है, उदा. git bisect कम उपयोगी - यह केवल मर्ज कमिट ढूंढेगा।

रिबेस

• आधार शाखा के शीर्ष पर वर्तमान शाखा से एक के बाद एक रीप्ले कमिट होते हैं।
  • नए SHAs के साथ नए कमिट उत्पन्न होते हैं, जिससे GitHub में कमिट मूल पुल अनुरोधों से मेल खाते हैं, लेकिन संबंधित टिप्पणियों से नहीं।
  • इस प्रक्रिया में प्रतिबद्धताओं को पुनः संयोजित और संशोधित किया जा सकता है, या यहां तक ​​कि एक में विलय भी किया जा सकता है।
• अनेक विवादों को सुलझाने की आवश्यकता हो सकती है।
• आपको एक रेखीय कहानी बनाए रखने की अनुमति देता है।
  • कहानी तब तक पढ़ना आसान हो सकता है जब तक यह बिना किसी उचित कारण के बहुत लंबी न हो जाए।
  • स्वचालित डिबगिंग और समस्या निवारण थोड़ा आसान है: इसे संभव बनाता है git bisect, स्वचालित रोलबैक को स्पष्ट और अधिक पूर्वानुमानित बना सकता है।
• एक ध्वज के साथ माइग्रेटेड कमिट वाली शाखा को प्रकाशित करने की आवश्यकता है --force जब पुल अनुरोधों के साथ प्रयोग किया जाता है।

आमतौर पर, टीमें हमेशा एक ही रणनीति का उपयोग करने के लिए सहमत होती हैं जब उन्हें परिवर्तनों को मर्ज करने की आवश्यकता होती है। यह एक "शुद्ध" मर्ज या शीर्ष पर एक "शुद्ध" कमिट, या बीच में कुछ हो सकता है, जैसे अंतःक्रियात्मक रूप से शीर्ष पर कमिट करना(git rebase -i) स्थानीय रूप से उन शाखाओं के लिए जो सार्वजनिक भंडार में प्रकाशित नहीं हुई हैं, लेकिन "सार्वजनिक" शाखाओं के लिए विलय हो गई हैं।

यहां हम मर्ज का प्रयोग करेंगे।

️कार्य

1. सुनिश्चित करें कि कोड स्थानीय शाखा में है master दूरस्थ रिपॉजिटरी से अद्यतन किया गया।
2. शाखा में स्विच करें feature.
3. किसी शाखा के साथ विलय आरंभ करें master. प्रतिस्पर्धात्मक परिवर्तनों के कारण विलय विवाद ci.md.
4. विरोध को हल करें ताकि सीआई चरणों की हमारी सूची और इसके बारे में एक नोट दोनों पाठ में बने रहें।
5. किसी दूरस्थ शाखा में मर्ज कमिट प्रकाशित करें feature.
6. GitHub UI में पुल अनुरोध की स्थिति जांचें और मर्ज हल होने तक प्रतीक्षा करें।

आदेशों

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

अच्छा काम!

आपकी सूची पूरी हो गई है और अब आपको पुल अनुरोध को स्वीकृत करने की आवश्यकता है master.

️ कार्य: पुल अनुरोध को स्वीकृत करें "चरणों की समीक्षा"

1. पुल अनुरोध खोलें.
2. "मर्ज पुल अनुरोध" पर क्लिक करें।
3. "मर्ज की पुष्टि करें" पर क्लिक करें।
4. "शाखा हटाएँ" पर क्लिक करें क्योंकि अब हमें इसकी आवश्यकता नहीं है।

इस समय यह आपका भंडार है

उत्पाद त्रुटि

ऐसा कहा जाता है कि "परीक्षण का उपयोग त्रुटियों की उपस्थिति दिखाने के लिए किया जा सकता है, लेकिन उनकी अनुपस्थिति दिखाने के लिए कभी नहीं।" हालाँकि हमारे पास परीक्षण थे और उन्होंने हमें कोई त्रुटि नहीं दिखाई, फिर भी उत्पादन में एक घातक बग आ गया।

इस तरह के परिदृश्य में, हमें निम्नलिखित बातों का ध्यान रखना होगा:

• उत्पादन में क्या तैनात किया गया है;
• धागे में कोड master एक त्रुटि के साथ, जिससे डेवलपर्स नया काम शुरू कर सकते हैं।

क्या मुझे इसे वापस लेना चाहिए या अगले संस्करण में ठीक करना चाहिए?

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

चूँकि हमारे मामले में पीछे हटने में कोई जोखिम नहीं है, हम इस मार्ग पर चलेंगे, क्योंकि यह हमें अनुमति देता है

• उत्पाद पर त्रुटि को यथाशीघ्र ठीक करें;
• में कोड बनाएं master नया काम शुरू करने के लिए तुरंत उपयुक्त।

️कार्य

1. शाखा में स्विच करें master स्थानीय रूप से।
2. रिमोट रिपॉजिटरी से स्थानीय रिपॉजिटरी को अपडेट करें।
3. पीआर मर्ज कमिट को पूर्ववत करें चरणों की समीक्षा в master.
4. दूरस्थ रिपॉजिटरी में परिवर्तन प्रकाशित करें।

यह एक रिपॉजिटरी का इतिहास है जिसमें मर्ज कमिट वापस कर दी गई है

आदेशों

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ स्व-परीक्षण

सुनिश्चित करें कि ci.md मर्ज कमिट को पूर्ववत करने के बाद अब "स्नीकी बग" टेक्स्ट शामिल नहीं है।

सीआई चरणों की सूची ठीक करें और इसे मास्टर को लौटाएँ

हमने शाखा की मर्ज प्रतिबद्धता को पूरी तरह से वापस कर दिया है। feature. अच्छी खबर यह है कि अब हमें कोई त्रुटि नहीं है master. बुरी खबर यह है कि निरंतर एकीकरण कदमों की हमारी बहुमूल्य सूची भी ख़त्म हो गई है। इसलिए, आदर्श रूप से, हमें कमिट्स पर फिक्स लागू करने की आवश्यकता है feature और उन्हें वापस कर दें master ठीक करने के साथ-साथ.

हम समस्या से विभिन्न तरीकों से निपट सकते हैं:

• मर्ज को पूर्ववत करने वाली प्रतिबद्धता को वापस लाएं feature с master;
• पूर्व से प्रतिबद्ध स्थानांतरित करें feature.

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

️कार्य

1. नामक एक थ्रेड बनाएं feature-fix और उस पर स्विच करें।

2. पूर्व शाखा से सभी प्रतिबद्धताओं को माइग्रेट करें feature एक नए सूत्र के लिए. माइग्रेशन के दौरान होने वाले मर्ज विवादों का समाधान करें।

   

3. इसमें एक प्रतिगमन परीक्षण जोड़ें ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. यह सुनिश्चित करने के लिए कि वे विफल न हों, स्थानीय स्तर पर परीक्षण चलाएँ।
5. इसमें "एक डरपोक बग के साथ" टेक्स्ट हटाएं ci.md.
6. सूचकांक में परीक्षण परिवर्तन और चरण सूची परिवर्तन जोड़ें और उन्हें प्रतिबद्ध करें।
7. शाखा को दूरस्थ रिपॉजिटरी में प्रकाशित करें।

आपको कुछ इसी तरह समाप्त होना चाहिए:

आदेशों

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

एक पुल अनुरोध बनाएं.

शीर्षक के साथ पुल अनुरोध बनाएं सुविधा को ठीक करना... इंस्टॉल feature-fix जैसे "मुख्य शाखा" और master जैसे "आधार शाखा"।
कृपया परीक्षण पूरा होने तक प्रतीक्षा करें। आप पीआर चर्चा के नीचे परीक्षणों की स्थिति देख सकते हैं।

सुनिश्चित करें कि आपने इंस्टॉल कर लिया है master से पहले रिपॉजिटरी को फोर्क करें "आधार शाखा" के रूप में, मैं पाठ्यक्रम सामग्री भंडार में बदलाव के अनुरोधों का जवाब नहीं दूंगा।

पुल अनुरोध को स्वीकृत करें "सुविधा को ठीक करना"

सुधार के लिए धन्यवाद! कृपया परिवर्तनों को स्वीकृत करें master पुल अनुरोध से.

️कार्य

1. "मर्ज पुल अनुरोध" पर क्लिक करें।
2. "मर्ज की पुष्टि करें" पर क्लिक करें।
3. "शाखा हटाएँ" पर क्लिक करें क्योंकि अब हमें इसकी आवश्यकता नहीं है।

इस समय आपके पास यही होना चाहिए।

बधाई!

आपने वे सभी चरण पूरे कर लिए हैं जो लोग आमतौर पर निरंतर एकीकरण के दौरान उठाते हैं।

यदि आपको पाठ्यक्रम में कोई समस्या दिखती है या आप जानते हैं कि इसे कैसे सुधारा जाए, तो कृपया एक मुद्दा बनाएं पाठ्यक्रम सामग्री के साथ भंडार. ये कोर्स भी है इंटरैक्टिव संस्करण एक मंच के रूप में GitHub लर्निंग लैब का उपयोग करना।

स्रोत: www.habr.com