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

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

हामी अगाडि बढ्दै जाँदा, हामी बिस्तारै विशिष्ट 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 Actions सक्षम नभएसम्म तपाईंले मेरा निर्देशनहरू पालना गरेर पाठ्यक्रम पूरा गर्न सक्नुहुन्न।

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

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

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

️ कार्य

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

Команды

git push --set-upstream origin feature

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

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

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

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

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

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

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

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

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

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

सामान्यतया PR सिर्जना गर्दा तपाईंले निम्न कार्यहरू गर्नुहुन्छ:

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

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

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

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

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