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

हामी के गर्छौ?

हामी प्रगति गर्दै जाँदा, हामी बिस्तारै विशिष्ट CI चरणहरूको सूची सिर्जना गर्नेछौं, जुन यो सूची सम्झने उत्कृष्ट तरिका हो। अर्को शब्दमा, हामी विकासकर्ताहरूले निरन्तर एकीकरण गर्दा, निरन्तर एकीकरण गर्दा गर्ने गतिविधिहरूको सूची सिर्जना गर्नेछौं। हामी हाम्रो CI प्रक्रियालाई वास्तविक प्रक्रियाको नजिक ल्याउन परीक्षणहरूको एक साधारण सेट पनि प्रयोग गर्नेछौं।

यो GIF योजनाबद्ध रूपमा तपाइँको रिपोजिटरीमा कमिटहरू देखाउँदछ जब तपाइँ पाठ्यक्रम मार्फत प्रगति गर्नुहुन्छ। तपाईले देख्न सक्नुहुन्छ, यहाँ केहि जटिल छैन र केवल सबैभन्दा आवश्यक छ।

तपाईं निम्न मानक CI परिदृश्यहरू मार्फत जानुहुनेछ:

• सुविधा मा काम;
• गुणस्तर सुनिश्चित गर्न स्वचालित परीक्षणहरूको आवेदन;
• प्राथमिकता कार्यको कार्यान्वयन;
• शाखाहरू मर्ज गर्दा द्वन्द्व समाधान (मर्ज द्वन्द्व);
• उत्पादन वातावरणमा त्रुटि हुन्छ।

के सिक्ने हो ?

तपाइँ निम्न प्रश्नहरूको जवाफ दिन सक्षम हुनुहुनेछ:

• लगातार एकीकरण (CI) के हो?
• CI मा कस्ता प्रकारका स्वचालित परीक्षणहरू प्रयोग गरिन्छ, र कुन कार्यहरूको प्रतिक्रियामा तिनीहरू ट्रिगर हुन्छन्?
• पुल अनुरोधहरू के हुन् र तिनीहरू कहिले आवश्यक छन्?
• टेस्ट ड्राइभन डेभलपमेन्ट (TDD) के हो र यो कसरी CI सँग सम्बन्धित छ?
• के मैले परिवर्तनहरू मर्ज वा रिबेस गर्नुपर्छ?
• रोल ब्याक गर्ने वा अर्को संस्करणमा समाधान गर्ने?

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

निरन्तर एकीकरण भनेको के हो?

निरन्तर एकीकरण, वा CI, एक प्राविधिक अभ्यास हो जसमा प्रत्येक टोली सदस्यले आफ्नो कोडलाई दिनको कम्तिमा एक पटक साझा भण्डारमा एकीकृत गर्दछ, र नतिजा कोड कम्तिमा त्रुटि बिना निर्माण हुनुपर्छ।

यस शब्दको बारेमा मतभेदहरू छन्

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

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

निरन्तर एकीकरण भन्दा फरक निरन्तर वितरण (निरन्तर डेलिभरी, CD) यसमा प्रत्येक एकीकरण चक्र पछि रिलीज उम्मेद्वार आवश्यक पर्दैन।

हामीले पाठ्यक्रम भर प्रयोग गर्ने चरणहरूको सूची

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

️ तयारी

निश्चित गर्नुहोस् कि तपाईंसँग सही सफ्टवेयर छ

यो कोर्स लिनको लागि तपाईलाई आवश्यक पर्दछ Node.js и Git ग्राहक.

तपाइँ कुनै पनि 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। यो सम्भव छैन कि तपाइँ यो धेरै पटक गर्न चाहानुहुन्छ, तर हामीसँग यहाँ एक भण्डार प्रयोगकर्तासँग एक धेरै विशिष्ट परिदृश्य छ जसले, थप रूपमा, उसले के गरिरहेको छ भनेर बुझ्दछ।

काम सुरु गर्दै

CI चरणहरूको हाम्रो सूची कम्पाइल गर्न सुरु गरौं। सामान्यतया तपाईले रिमोट रिपोजिटरीबाट कोडको नवीनतम संस्करण जाँच गरेर यो चरण सुरु गर्नुहुनेछ, तर हामीसँग अझै स्थानीय भण्डार छैन, त्यसैले हामी यसलाई रिमोटबाट क्लोन गर्छौं।

️ कार्य: स्थानीय भण्डार अद्यावधिक गर्नुहोस्, बाट शाखा सिर्जना गर्नुहोस् 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. फाइलमा पहिलो ४ चरणको पाठ थप्नुहोस् 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 как описано выше

नयाँ शाखामा कमिटहरू सिर्जना गर्नुहोस्, स्थानीय रूपमा निर्माण गर्नुहोस् र परीक्षण गर्नुहोस्

हामी कमिट गर्नु अघि चलाउनको लागि परीक्षणहरू सेटअप गर्न जाँदैछौं, र त्यसपछि कोड कमिट गर्छौं।

परीक्षणहरू स्वचालित रूपमा चल्दा सामान्य परिदृश्यहरू

• स्थानीय रूपमा:
  • लगातार वा उपयुक्त कोड परिवर्तनहरूको प्रतिक्रियामा;
  • बचतमा (व्याख्या गरिएको वा JIT-कम्पाइल गरिएका भाषाहरूको लागि);
  • विधानसभा को समयमा (जब संकलन आवश्यक छ);
  • प्रतिबद्धतामा;
  • साझा भण्डारमा प्रकाशित गर्दा।

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

सामान्यतया, परीक्षण सुइट जति छिटो दौडन्छ, उति धेरै पटक तपाईले यसलाई चलाउन खर्च गर्न सक्नुहुन्छ। एक सामान्य चरण वितरण यस्तो देखिन सक्छ।

• द्रुत एकाइ परीक्षणहरू - निर्माणको क्रममा, CI पाइपलाइनमा
• ढिलो एकाइ परीक्षणहरू, द्रुत कम्पोनेन्ट र एकीकरण परीक्षणहरू - कमिटमा, CI पाइपलाइनमा
• ढिलो कम्पोनेन्ट र एकीकरण परीक्षणहरू - CI पाइपलाइनमा
• सुरक्षा परीक्षण, लोड परीक्षण र अन्य समय-खपत वा महँगो परीक्षणहरू - CI/CD पाइपलाइनहरूमा, तर निर्माणको निश्चित मोडहरू/चरणहरू/पाइपलाइनहरूमा मात्र, उदाहरणका लागि, रिलीज उम्मेद्वार तयार गर्दा वा म्यानुअल रूपमा चलाउँदा।

️कार्य

म आदेश प्रयोग गरेर पहिले म्यानुअल रूपमा परीक्षणहरू चलाउन सुझाव दिन्छु npm test। त्यस पछि, कमिटमा हाम्रो परीक्षणहरू चलाउनको लागि गिट हुक थपौं। त्यहाँ एउटा क्याच छ: 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 मा खुला स्रोत परियोजनाहरूमा प्रयोग गरिन्छ। यो मेरो उन्नत पाठ्यक्रम [Team Work र CI with Git] मा पनि प्रयोग गरिन्छ (http://devops.redpill.solutions/).
• अर्को दृष्टिकोण भनेको एउटा मात्र रिमोट रिपोजिटरी प्रयोग गर्नु र शाखा मात्र गणना गर्नु हो master साझा भण्डार "सुरक्षित"। यस परिदृश्यमा, व्यक्तिगत विकासकर्ताहरूले आफ्नो कोड रिमोट रिपोजिटरीको शाखाहरूमा प्रकाशित गर्छन् ताकि अरूले यो कोड हेर्न सकून्, यदि सबै कुरा व्यवस्थित छ भने, यसलाई मर्ज गर्नुहोस्। master साझा भण्डार।

यस विशेष पाठ्यक्रममा, हामी शाखाहरू प्रयोग गर्ने कार्यप्रवाह प्रयोग गर्नेछौं।

हाम्रो कोड प्रकाशित गरौं।

️कार्य

• तपाईंको काम गर्ने शाखाको नामको रूपमा टाढाको शाखामा परिवर्तनहरू प्रकाशित गर्नुहोस्

Команды

git push --set-upstream origin feature

पुल अनुरोध सिर्जना गर्नुहोस्

शीर्षकको साथ पुल अनुरोध सिर्जना गर्नुहोस् चरण समीक्षा... स्थापना गर्नुहोस् feature जस्तै "हेड शाखा" र master जस्तै "आधार शाखा"।

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

GitHub lingo मा, "आधार शाखा" त्यो शाखा हो जसमा तपाईंले आफ्नो कामलाई आधार बनाउनुहुन्छ, र "हेड शाखा" प्रस्तावित परिवर्तनहरू समावेश गर्ने शाखा हो।

परिवर्तनहरू छलफल गर्नुहोस्, छलफल जारी रहँदा नयाँ प्रतिबद्धताहरू थप्नुहोस्

पुल अनुरोध (PR)

पुल अनुरोध (PR) छलफल र कागजात कोड, साथै आचार संहिता समीक्षा गर्ने तरिका हो। पुल अनुरोधहरूलाई समग्र कोडमा व्यक्तिगत परिवर्तनहरू एकीकृत गर्ने सामान्य तरिकाको नाममा राखिएको छ। सामान्यतया, एक व्यक्तिले परियोजनाको रिमोट आधिकारिक भण्डार क्लोन गर्दछ र स्थानीय रूपमा कोडमा काम गर्दछ। यसपछि, उसले कोडलाई आफ्नो व्यक्तिगत रिमोट रिपोजिटरीमा राख्छ र आधिकारिक भण्डारको लागि जिम्मेवार व्यक्तिहरूलाई उठाउन सोध्छ।खींचो) यसको कोड तिनीहरूको स्थानीय भण्डारहरूमा, जहाँ तिनीहरू समीक्षा गर्छन् र सम्भवतः एकीकृत हुन्छन्(मर्ज) उनको। यो अवधारणा अन्य नामहरु द्वारा पनि चिनिन्छ, उदाहरण को लागी, मर्ज अनुरोध.

तपाईले वास्तवमा GitHub वा समान प्लेटफर्महरूको पुल अनुरोध सुविधा प्रयोग गर्नुपर्दैन। विकास टोलीहरूले आमने-सामने सञ्चार, भ्वाइस कल, वा इमेल सहित सञ्चारका अन्य विधिहरू प्रयोग गर्न सक्छन्, तर त्यहाँ अझै पनि फोरम-शैली पुल अनुरोधहरू प्रयोग गर्ने थुप्रै कारणहरू छन्। यहाँ तिनीहरू मध्ये केही छन्:

• विशिष्ट कोड परिवर्तन संग सम्बन्धित संगठित छलफल;
• दुबै autotesters र साथीहरु बाट कार्य प्रगति मा प्रतिक्रिया हेर्न को लागी एक ठाउँ को रूप मा;
• कोड समीक्षा को औपचारिकीकरण;
• ताकि पछि तपाईले यो वा त्यो कोडको टुक्रा पछाडिको कारण र विचारहरू पत्ता लगाउन सक्नुहुन्छ।

सामान्यतया तपाईंले कुनै कुरा छलफल गर्न वा प्रतिक्रिया प्राप्त गर्न आवश्यक हुँदा पुल अनुरोध सिर्जना गर्नुहुन्छ। उदाहरण को लागी, यदि तपाइँ एक सुविधा मा काम गर्दै हुनुहुन्छ जुन एक भन्दा बढी तरिकामा लागू गर्न सकिन्छ, तपाइँ तपाइँको विचार साझा गर्न र तपाइँको योजनाहरु लाई तपाइँको सहयोगीहरु संग छलफल गर्न कोड को पहिलो लाइन लेख्नु अघि पुल अनुरोध सिर्जना गर्न सक्नुहुन्छ। यदि काम सरल छ भने, एक पुल अनुरोध खोलिन्छ जब केहि पहिले नै गरिसकेको छ, प्रतिबद्ध छ, र छलफल गर्न सकिन्छ। केही परिदृश्यहरूमा, तपाईं गुणस्तर नियन्त्रण कारणहरूका लागि मात्र PR खोल्न चाहनुहुन्छ: स्वचालित परीक्षणहरू चलाउन वा कोड समीक्षाहरू प्रारम्भ गर्न। तपाईंले जे पनि निर्णय गर्नुहुन्छ, @मेन्सन गर्न नबिर्सनुहोस् जसको स्वीकृति तपाईंले आफ्नो पुल अनुरोधमा चाहनुहुन्छ।

सामान्यतया, PR सिर्जना गर्दा, तपाइँ निम्न गर्नुहुन्छ।

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

एकचोटि तपाईंले PR खोल्नुभयो भने, त्यस्ता केसहरूमा चलाउनको लागि कन्फिगर गरिएका परीक्षणहरू कार्यान्वयन हुन्छन्। हाम्रो मामलामा, यो हामीले स्थानीय रूपमा चलाएको परीक्षणको समान सेट हुनेछ, तर वास्तविक परियोजनामा ​​त्यहाँ थप परीक्षण र जाँचहरू हुन सक्छन्।

कृपया परीक्षणहरू पूरा हुँदा पर्खनुहोस्। तपाईंले GitHub इन्टरफेसमा PR छलफलको तलमा परीक्षणहरूको स्थिति हेर्न सक्नुहुन्छ। परीक्षणहरू पूरा भएपछि जारी राख्नुहोस्।

️ CI चरणहरूको सूचीको अनियमितताको बारेमा टिप्पणी थप्नुहोस्

यस पाठ्यक्रममा प्रयोग गरिएको सूची स्वेच्छाचारी र व्यक्तिपरक हो, हामीले यस बारे एक टिप्पणी थप्नु पर्छ।

️ कार्य: यो टिप्पणीको लागि पुल अनुरोध सिर्जना गर्नुहोस्

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. "शाखा मेटाउनुहोस्" मा क्लिक गर्नुहोस्, हामीलाई अब यसको आवश्यकता छैन।

यो मर्ज पछि कमिटहरूको रेखाचित्र हो।

️ काम गरिरहनुहोस् र परीक्षणहरू थप्नुहोस्

पुल अनुरोधमा सहयोग गर्नाले प्राय: अतिरिक्त कामको परिणाम हुन्छ। यो सामान्यतया कोड समीक्षा वा छलफलको परिणाम हो, तर हाम्रो पाठ्यक्रममा हामी CI चरणहरूको सूचीमा नयाँ वस्तुहरू थपेर यसलाई मोडेल गर्न जाँदैछौं।

निरन्तर एकीकरणमा सामान्यतया केही परीक्षण कभरेज समावेश हुन्छ। परीक्षण कभरेज आवश्यकताहरू भिन्न हुन्छन् र सामान्यतया कागजातमा पाइन्छ जसलाई "योगदान दिशानिर्देशहरू" भनिन्छ। हामी यसलाई सरल राख्नेछौं र हाम्रो चेकलिस्टमा प्रत्येक लाइनको लागि परीक्षण थप्नेछौं।

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

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

TDD ले कोड अघि परीक्षण लेख्न सिफारिस गर्छ। TDD प्रयोग गर्ने सामान्य कार्यप्रवाह यस्तो देखिन्छ।

1. परीक्षण थप्नुहोस्।
2. सबै परीक्षणहरू चलाउनुहोस् र नयाँ परीक्षण असफल भएको सुनिश्चित गर्नुहोस्।
3. कोड लेख्नुहोस्।
4. परीक्षणहरू चलाउनुहोस्, सुनिश्चित गर्नुहोस् कि सबै परीक्षणहरू उत्तीर्ण हुन्छन्।
5. आफ्नो कोड रिफ्याक्टर गर्नुहोस्।
6. दोहोर्याउनुहोस्।

असफल हुने परिक्षाको नतिजा सामान्यतया रातो रंगमा देखाइन्छ, र पास भएकाहरू सामान्यतया हरियोमा देखाइन्छ, चक्रलाई रातो-हरियो-रिफ्याक्टर पनि भनिन्छ।

️कार्य

पहिले, परीक्षणहरू गर्ने प्रयास गर्नुहोस् र तिनीहरूलाई असफल हुन दिनुहोस्, त्यसपछि CI चरण सूचीको पाठ थप्नुहोस् र कमिट गर्नुहोस्। तपाईले देख्नुहुनेछ कि परीक्षणहरू उत्तीर्ण हुँदैछन् ("हरियो")।
त्यसपछि रिमोट रिपोजिटरीमा नयाँ कोड प्रकाशित गर्नुहोस् र पुल अनुरोध छलफल र PR स्थिति अपडेटको तल 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 जब हामी यो PR मा काम गरिरहेका थियौं।
यसले एक अवस्था सिर्जना गर्दछ जहाँ टाढाको शाखा master हामीले शाखामा आधारित गरेको भन्दा नयाँ संस्करण छ feature। यस कारणले हामी केवल हेड रिवाइन्ड गर्न सक्दैनौं master थ्रेडको अन्त्यसम्म feature। यस अवस्थामा, हामीले या त मर्ज वा कमिटहरू लागू गर्न आवश्यक छ feature रिबेस master। GitHub ले वास्तवमा स्वचालित मर्जहरू प्रदर्शन गर्न सक्छ यदि त्यहाँ कुनै विवाद छैन। अफसोस, हाम्रो अवस्थामा, दुवै शाखाहरूले फाइलमा प्रतिस्पर्धात्मक परिवर्तनहरू छन् ci.md। यो अवस्थालाई मर्ज द्वन्द्वको रूपमा चिनिन्छ, र हामीले यसलाई म्यानुअल रूपमा समाधान गर्न आवश्यक छ।

मर्ज वा रिबेस गर्नुहोस्

मर्ज गर्नुहोस्

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

रिबेस

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

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

यहाँ हामी मर्ज प्रयोग गर्नेछौं।

️कार्य

1. निश्चित गर्नुहोस् कि कोड स्थानीय शाखामा छ master रिमोट रिपोजिटरीबाट अद्यावधिक गरियो।
2. शाखामा स्विच गर्नुहोस् feature.
3. शाखा संग मर्ज प्रारम्भ गर्नुहोस् master। मा प्रतिस्पर्धात्मक परिवर्तनहरूको कारणले गर्दा मर्ज विवाद ci.md.
4. द्वन्द्व समाधान गर्नुहोस् ताकि हाम्रो CI चरणहरूको सूची र यसको बारेमा नोट पाठमा रहन्छ।
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 र सकेसम्म चाँडो नयाँ संस्करण तैनात गर्दै। किनकी API हरू र डाटाबेस स्कीमाहरू कोड उत्पादनमा प्रयोग गरिएपछि परिवर्तन हुन्छन्, निरन्तर डेलिभरी र राम्रो परीक्षण कभरेजको साथ, रोल ब्याक गर्नु अर्को संस्करणमा फिक्स गर्नु भन्दा सामान्यतया धेरै गाह्रो र जोखिमपूर्ण हुन्छ।

किनकी रोल ब्याक गर्दा हाम्रो मामलामा कुनै जोखिम छैन, हामी यो बाटो जानेछौं, किनकि यसले हामीलाई अनुमति दिन्छ

• सकेसम्म चाँडो उत्पादन मा त्रुटि समाधान;
• कोड बनाउनुहोस् master नयाँ काम सुरु गर्न तुरुन्तै उपयुक्त।

️कार्य

1. शाखामा स्विच गर्नुहोस् master स्थानीय रूपमा।
2. रिमोट रिपोजिटरीबाट स्थानीय भण्डार अद्यावधिक गर्नुहोस्।
3. PR मर्ज कमिट उल्टाउनुहोस् चरण समीक्षा в 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 मर्ज कमिट उल्टाएपछि अब "स्नीकी बग" पाठ समावेश गर्दैन।

CI चरणहरूको सूची ठीक गर्नुहोस् र यसलाई मास्टरमा फर्काउनुहोस्

हामीले शाखाको मर्जर प्रतिबद्धतालाई पूर्ण रूपमा उल्ट्यौं। 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 जस्तै "आधार शाखा"।
कृपया परीक्षणहरू पूरा हुँदा पर्खनुहोस्। तपाईंले PR छलफलको तलमा परीक्षणहरूको स्थिति हेर्न सक्नुहुन्छ।

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

पुल अनुरोध अनुमोदन गर्नुहोस् "सुविधा फिक्स गर्दै"

सच्याउनु भएकोमा धन्यवाद! कृपया परिवर्तनहरूलाई अनुमोदन गर्नुहोस् master पुल अनुरोधबाट।

️कार्य

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

यो समय तपाईसँग हुनु पर्ने कुरा हो।

बधाई छ!

तपाईंले मानिसहरूले सामान्यतया निरन्तर एकीकरणको क्रममा लिने सबै चरणहरू पूरा गर्नुभएको छ।

यदि तपाइँ पाठ्यक्रममा कुनै समस्याहरू देख्नुहुन्छ वा यसलाई कसरी सुधार गर्ने भनेर जान्नुहुन्छ भने, कृपया मा एक मुद्दा सिर्जना गर्नुहोस् पाठ्यक्रम सामग्री संग भण्डार। यो पाठ्यक्रम पनि छ अन्तरक्रियात्मक संस्करण प्लेटफर्मको रूपमा GitHub लर्निङ ल्याब प्रयोग गर्दै।

स्रोत: www.habr.com