ڇا توھان سکيو آھي Git ڪمانڊ پر تصور ڪرڻ چاھيو ٿا ته ڪيئن مسلسل انٽيگريشن (CI) حقيقت ۾ ڪم ڪندو آھي؟ يا ٿي سگهي ٿو توهان پنهنجي روزاني سرگرمين کي بهتر ڪرڻ چاهيو ٿا؟ هي ڪورس توهان کي GitHub مخزن استعمال ڪندي مسلسل انضمام ۾ عملي صلاحيتون ڏيندو. هن ڪورس جو مقصد هڪ جادوگر نه آهي جنهن جي ذريعي توهان آساني سان ڪلڪ ڪري سگهو ٿا؛ ان جي برعڪس، توهان اهي ئي عمل ڪندا جيڪي ماڻهو اصل ۾ ڪم تي ڪندا آهن، ساڳيءَ طرح جيئن اهي ڪندا آهن. آئون نظريي جي وضاحت ڪندس جيئن توهان شامل قدمن ذريعي وڃو.

اسان ڇا ڪريون؟

جئين اسان ترقي ڪندا آهيون، اسان تدريجي طور تي عام CI مرحلن جي هڪ فهرست ٺاهينداسين، جيڪو هن فهرست کي ياد ڪرڻ جو هڪ بهترين طريقو آهي. ٻين لفظن ۾، اسان عملن جي هڪ فهرست ٺاهينداسين جيڪي ڊولپرز وٺن ٿا جڏهن مسلسل انضمام ڪندي، مسلسل انضمام ڪندي. اسان اسان جي سي آءِ عمل کي حقيقي جي ويجھو آڻڻ لاءِ ٽيسٽن جو ھڪڙو سادو سيٽ پڻ استعمال ڪنداسين.

هي GIF اسڪيم طور ڏيکاري ٿو ڪميٽ کي توهان جي مخزن ۾ جيئن توهان ڪورس ذريعي ترقي ڪريو. جئين توهان ڏسي سگهو ٿا، هتي ڪجھ به پيچيده ناهي ۽ صرف تمام ضروري آهي.

توھان ھيٺ ڏنل معياري CI منظرنامي ذريعي ويندا:

• خاصيت تي ڪم؛
• معيار کي يقيني بڻائڻ لاء خودڪار ٽيسٽ جي درخواست؛
• ترجيحي ڪم کي لاڳو ڪرڻ؛
• شاخن کي ضم ڪرڻ وقت تڪرار جو حل (مضبوط تڪرار)؛
• Возникновение ошибки в продуктивной среде.

توهان ڇا سکندا؟

توھان ھيٺ ڏنل سوالن جا جواب ڏئي سگھندا.

• مسلسل انضمام (CI) ڇا آهي؟
• CI ۾ ڪهڙي قسم جا خودڪار ٽيسٽ استعمال ڪيا ويندا آهن، ۽ انهن جي جواب ۾ ڪهڙن ڪارناما شروع ڪيا ويندا آهن؟
• ڇڪڻ جون درخواستون ڇا آهن ۽ جڏهن انهن جي ضرورت آهي؟
• ٽيسٽ ڊولپمينٽ ڊولپمينٽ (TDD) ڇا آهي ۽ ان جو CI سان ڪهڙو تعلق آهي؟
• ڇا مون کي ضم ڪرڻ يا تبديلين کي بحال ڪرڻ گهرجي؟
• واپس رول ڪريو يا ايندڙ ورزن ۾ درست ڪريو؟

شروع ۾ مون هر هنڌ ”پل درخواستون“ جهڙيون شيون ترجمو ڪيون، پر نتيجي ۾ مون فيصلو ڪيو ته ڪجهه هنڌن تي انگريزيءَ ۾ جملا موٽايا وڃن ته جيئن متن ۾ جنون جو درجو گهٽجي. مان ڪڏهن ڪڏهن استعمال ڪندس ”پروگرامر سرزڪ“ جهڙو عجيب فعل ”ڪمٽ“ جتي ماڻهو اصل ۾ ڪم تي استعمال ڪندا آهن.

Что такое непрерывная интеграция?

مسلسل انضمام، يا CI، هڪ ٽيڪنيڪل مشق آهي جنهن ۾ هر ٽيم ميمبر پنهنجي ڪوڊ کي هڪ عام مخزن ۾ ضم ڪري ٿو گهٽ ۾ گهٽ هڪ ڏينهن ۾، ۽ نتيجو وارو ڪوڊ گهٽ ۾ گهٽ بنا ڪنهن غلطي جي.

هن اصطلاح جي باري ۾ اختلاف آهن

تڪرار جو نقطو انضمام جي تعدد آهي. ڪجهه دليل ڏين ٿا ته ضمير ڪوڊ صرف هڪ ڏينهن ۾ هڪ ڀيرو ڪافي نه آهي اصل ۾ مسلسل ضم ڪرڻ لاء. هڪ مثال هڪ ٽيم آهي جتي هرڪو صبح جو تازو ڪوڊ وٺندو آهي ۽ شام جو هڪ ڀيرو ان کي ضم ڪري ٿو. جڏهن ته اهو هڪ معقول اعتراض آهي، اهو عام طور تي قبول ڪيو ويو آهي ته هڪ ڏينهن جي وصف معقول طور تي عملي، مخصوص ۽ مختلف سائزن جي ٽيمن لاءِ موزون آهي.

ٻيو اعتراض اهو آهي ته C++ هاڻي ترقيءَ ۾ استعمال ٿيندڙ واحد ٻولي نه رهي آهي، ۽ صرف غلطي کان پاڪ اسيمبليءَ جي ضرورت آهي جيئن تصديق جي طريقي سان ڪمزور آهي. ٽيسٽن جا ڪجھ سيٽ (مثال طور، يونٽ ٽيسٽ مقامي طور تي انجام ڏنو ويو) پڻ ڪاميابي سان مڪمل ٿيڻ گھرجي. هن وقت، ڪميونٽي هن کي هڪ گهربل بڻائڻ طرف وڌي رهي آهي، ۽ مستقبل ۾ "تعمير + يونٽ ٽيسٽ" شايد عام رواج بڻجي ويندا، جيڪڏهن اهو اڳ ۾ ئي نه آهي.

مسلسل انضمام کان الڳ آهي مسلسل فراهمي (مسلسل ترسيل، سي ڊي) انهي ۾ ته ان کي هر انضمام واري چڪر کان پوء ڇڏڻ واري اميدوار جي ضرورت ناهي.

قدمن جي فهرست جيڪا اسان سڄي ڪورس ۾ استعمال ڪنداسين

1. تازو ڪوڊ ۾ ڇڪيو. مان هڪ شاخ ٺاهيو master. ڪم شروع ڪريو.
2. پنھنجي نئين شاخ تي ڪميٽ ٺاھيو. مقامي طور تي تعمير ۽ جانچ ڪريو. پاس؟ ايندڙ قدم ڏانھن وڃو. ناڪام؟ غلطيون يا ٽيسٽ کي درست ڪريو ۽ ٻيهر ڪوشش ڪريو.
3. پنھنجي ريموٽ مخزن يا ريموٽ شاخ ڏانھن ڇڪيو.
4. Create a pull request. Discuss the changes, add more commits as discussion continues. Make tests pass on the feature branch.
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 جي قابليت کي رينڊر ڪرڻ لاءِ Markdown جي لسٽ جي موجوده حالت کي ڏسڻ لاءِ جيڪو اسان ھتي مرتب ڪري رھيا آھيون

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

جوابن جي باري ۾

جڏهن ته هن ڪورس کي مڪمل ڪرڻ جو بهترين طريقو اهو آهي ته اهو پنهنجو پاڻ ڪريو، توهان کي ڪجهه مشڪلاتون ٿي سگهن ٿيون.

Если вы чувствуете, что не понимаете что делать и не можете продолжать, можете подсмотреть в ветку solution، جيڪو توهان جي شروعاتي مخزن ۾ آهي.
مهرباني ڪري ضم نه ڪريو solution в master ڪورس دوران. توهان هن برانچ کي استعمال ڪري سگهو ٿا اهو معلوم ڪرڻ لاءِ ته ڇا ڪجي، يا توهان جي ڪوڊ کي ليکڪ سان ڀيٽڻ لاءِ، انهن سڀني صلاحيتن کي استعمال ڪندي جيڪي گيٽ اسان کي ڏئي ٿو. جيڪڏهن توهان مڪمل طور تي گم ٿي ويا آهيو، توهان مڪمل طور تي پنهنجي برانچ کي تبديل ڪري سگهو ٿا 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. اهو ممڪن ناهي ته توهان اهو گهڻو ڪري ڪرڻ چاهيندا، پر اسان وٽ هتي هڪ خاص منظرنامو آهي هڪ مخزن جي استعمال ڪندڙ سان جيڪو، اضافي طور تي، سمجهي ٿو ته هو ڇا ڪري رهيو آهي.

Starting working

Начнем составлять наш список шагов 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. فائل ۾ پهرين 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 как описано выше

ھڪڙي نئين شاخ تي ڪمٽ ٺاھيو، مقامي طور تي ٺاھيو ۽ ٽيسٽ ڪريو

اسان ڪم ڪرڻ کان اڳ هلائڻ لاءِ ٽيسٽ قائم ڪرڻ وارا آھيون، ۽ پوءِ ڪوڊ کي انجام ڏيون ٿا.

عام حالتون جڏهن ٽيسٽ پاڻمرادو هلن ٿيون

• مقامي طور تي:
  • مسلسل يا مناسب ڪوڊ تبديلين جي جواب ۾؛
  • محفوظ ڪرڻ تي (ترجمان يا JIT-مرتب ٿيل ٻولين لاءِ)؛
  • اسيمبلي جي دوران (جڏهن تاليف گهربل هجي)؛
  • انجام ڏيڻ تي؛
  • جڏهن هڪ گڏيل مخزن ڏانهن شايع ڪيو وڃي.

• بلڊ سرور تي يا ماحول جي تعمير تي:
  • Когда код публикуется в персональную ветку / репозиторий.
  • هن سلسلي ۾ ڪوڊ آزمايو پيو وڃي.
  • ضمير جو امڪاني نتيجو آزمائشي آهي (عام طور تي master).
  • هڪ مسلسل انضمام اسٽيج / مسلسل پهچائڻ واري پائپ لائن جي طور تي

عام طور تي، تيزيءَ سان هڪ ٽيسٽ سوٽ هلندو، گهڻو ڪري توهان ان کي هلائڻ جي متحمل ٿي سگهو ٿا. ھڪڙي عام اسٽيج جي تقسيم ھن طرح نظر اچي سگھي ٿي.

• فاسٽ يونٽ ٽيسٽ - تعمير دوران، سي آء پائپ لائن ۾
• Медленные модульные тесты, быстрые компонентные и интеграционные тесты — при коммите, в конвейере 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 تي اوپن سورس منصوبن ۾ استعمال ٿيندو آهي. اهو پڻ استعمال ڪيو ويو آهي منهنجي ترقي يافته ڪورس ۾ [ٽيم ڪم ۽ سي آءِ گيٽ سان] (http://devops.redpill.solutions/).
• ٻيو طريقو صرف هڪ ريموٽ مخزن کي استعمال ڪرڻ ۽ صرف شاخ کي ڳڻڻ آهي master گڏيل مخزن "محفوظ". هن منظر ۾، انفرادي ڊولپرز پنهنجو ڪوڊ هڪ ريموٽ مخزن جي شاخن ڏانهن شايع ڪن ٿا ته جيئن ٻيا هن ڪوڊ کي ڏسي سگهن، جيڪڏهن سڀ ڪجهه ترتيب ۾ آهي، ان سان ملائي. master گڏيل ذخيرو.

هن خاص ڪورس ۾، اسان هڪ ڪم فلو استعمال ڪنداسين جيڪو شاخن کي استعمال ڪري ٿو.

اچو ته اسان جو ڪوڊ شايع ڪريو.

️ Задание

• ريموٽ برانچ ۾ تبديليون شايع ڪريو ساڳئي نالي سان توهان جي ڪم ڪندڙ برانچ

Команды

git push --set-upstream origin feature

ڇڪڻ جي درخواست ٺاھيو

ھڪڙي عنوان سان ھڪڙي پل درخواست ٺاھيو قدمن جو جائزو. انسٽال ڪريو feature جهڙوڪ "سر شاخ" ۽ master جيئن "بنيادي شاخ".

پڪ ڪريو ته توهان انسٽال ڪيو آهي master هن جي ذخيرو کي ڇڪيو в качестве "base branch", я не буду отвечать на запросы на изменения в репозиторий с материалами курса.

GitHub lingo ۾، "بيس برانچ" اها شاخ آهي جنهن تي توهان پنهنجي ڪم جو بنياد رکو ٿا، ۽ "هيڊ برانچ" اها شاخ آهي جنهن ۾ تجويز ڪيل تبديليون شامل آهن.

تبديلين تي بحث ڪريو، نوان ڪم شامل ڪريو جيئن بحث جاري آھي

ڇڪڻ جي درخواست (PR)

ڇڪڻ جي درخواست (PR) هڪ طريقو آهي بحث ڪرڻ ۽ دستاويزي ڪوڊ، گڏوگڏ ڪوڊ جو جائزو وٺڻ جو. پل جي درخواستن کي مجموعي ڪوڊ ۾ انفرادي تبديلين کي ضم ڪرڻ جي عام طريقي جي پٺيان رکيو ويو آهي. عام طور تي، هڪ شخص منصوبي جي دور دراز سرڪاري مخزن کي ڪلون ڪري ٿو ۽ ڪوڊ تي مقامي طور تي ڪم ڪري ٿو. ان کان پوء، هن ڪوڊ کي پنهنجي ذاتي ريموٽ مخزن ۾ رکي ٿو ۽ انهن کي پڇڻ لاء سرڪاري مخزن جي ذميوارن کي کڻڻ لاء (ڇڪيو) ان جو ڪوڊ انهن جي مقامي ذخيرو ۾، جتي اهي جائزو وٺندا آهن ۽ ممڪن طور تي ضم ٿي ويندا آهنملن) سندس. اهو تصور ٻين نالن سان پڻ سڃاتو وڃي ٿو، مثال طور، ضم ڪرڻ جي درخواست.

توهان کي اصل ۾ استعمال ڪرڻ جي ضرورت ناهي پل جي درخواست جي خاصيت GitHub يا ساڳئي پليٽ فارمن جي. ڊولپمينٽ ٽيمون ڪميونيڪيشن جا ٻيا طريقا استعمال ڪري سگھن ٿيون، جن ۾ روبرو ڪميونيڪيشن، وائس ڪالز، يا اي ميل شامل آهن، پر فورم جي طرز جي پل درخواستن کي استعمال ڪرڻ جا اڃا به ڪيترائي سبب آھن. هتي انهن مان ڪجهه آهن:

• مخصوص ڪوڊ تبديلين سان لاڳاپيل بحث مباحثو؛
• آٽوٽيسٽرز ۽ ساٿين ٻنهي جي ڪم ۾ پيش رفت تي راءِ ڏسڻ لاءِ جڳهه جي طور تي؛
• ڪوڊ جي جائزي جي formalization؛
• انهي ڪري ته بعد ۾ توهان ڳولي سگهو ٿا سببن ۽ غورن جي پويان هن يا انهي ڪوڊ جي ٽڪرا.

Обычно вы создаете pull request когда вам нужно что-то обсудить или получить обратную связь. Например, если вы работаете над функцией, которая может быть реализована несколькими способами, вы можете создать запрос на внесение изменений еще до написания первой строки кода, чтобы поделиться своими идеями и обсудить свои планы с соавторами. Если работа более проста, pull request открывается, когда что-то уже сделано, зафиксировано и может быть обсуждено. В некоторых сценариях вы можете открыть PR только из соображений контроля за качеством: чтобы запустить автоматические тесты или инициировать проверку кода. Что бы вы ни решили, не забывайте @упоминать людей, одобрение которых требуется в вашем pull request’е.

عام طور تي، جڏهن پي آر ٺاهي، توهان هيٺيان ڪندا آهيو.

• ظاھر ڪيو ته توھان کي تبديل ڪرڻ جو مشورو ڏيو ۽ ڪٿي.
• تبديلين جي مقصد جي وضاحت ڪندي وضاحت لکو. توھان چاھيو ٿا:
  • добавить что-нибудь важное, что не является очевидным из кода, или что-нибудь полезное для понимания контекста, например соответствующие #баги и номера коммитов;
  • @ ڪنهن به ماڻهو جو ذڪر ڪريو جنهن سان توهان ڪم ڪرڻ شروع ڪرڻ چاهيو ٿا، يا توهان انهن کي بعد ۾ تبصرن ۾ ذڪر ڪري سگهو ٿا؛
  • ساٿين کان پڇو ته ڪنھن شيءِ سان مدد ڪريو يا ڪنھن خاص شيءِ تي چيڪ ڪريو.

هڪ دفعو توهان پي آر کي کوليو، ٽيسٽ کي ترتيب ڏنو ويو آهي ته اهڙين ڪيسن ۾ هلائڻ لاء. اسان جي صورت ۾، اهو ساڳيو ٽيسٽن جو سيٽ هوندو جيڪو اسان مقامي طور تي هلائيندا هئاسين، پر هڪ حقيقي منصوبي ۾ اضافي ٽيسٽ ۽ چڪاس ٿي سگهي ٿي.

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

️ 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 هن جي ذخيرو کي ڇڪيو в качестве "base branch", я не буду отвечать на запросы на изменения в репозиторий с материалами курса.

Вот как должен выглядеть ваш репозиторий.

Команды

# Переключитесь на ветку 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. Вы увидите, что тесты проходят ("зеленые").
پوءِ نئون ڪوڊ شايع ڪريو ريموٽ ريپوزٽري ڏانهن ۽ ڏسو 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. انهي جي ڪري اسان صرف سر کي ريوائنڊ نٿا ڪري سگهون master سلسلي جي آخر تائين feature. هن صورتحال ۾، اسان کي يا ته ضم ڪرڻ يا ڪمن کي لاڳو ڪرڻ جي ضرورت آهي feature بحال ڪرڻ master. GitHub اصل ۾ خودڪار ضم ٿي سگھي ٿو جيڪڏهن ڪو تڪرار نه آهي. افسوس، اسان جي صورتحال ۾، ٻنهي شاخن فائلن ۾ مقابلي ۾ تبديليون آهن ci.md. اها صورتحال ضم ٿيل تڪرار جي طور تي سڃاتو وڃي ٿو، ۽ اسان کي ان کي دستي طور حل ڪرڻ جي ضرورت آهي.

ملائڻ يا ٻيهر بحال ڪرڻ

ملن

• Создает дополнительный коммит слияния(merge commit) и сохраняет историю работы.
  • شاخن جي اصلي ڪمن کي انهن جي اصل ٽائيم اسٽيمپ ۽ ليکڪن سان محفوظ ڪري ٿو.
  • تبديلي جي درخواست جي بحثن ۾ ڪمن جي SHA کي محفوظ ڪري ٿو ۽ انھن سان ڳنڍيل آھن.
• ھڪڙي وقت جي تڪرار جي حل جي ضرورت آھي.
• ڪهاڻي کي غير لڪير بڻائي ٿو.
  • ڪهاڻي پڙهڻ ڏکيو ٿي سگهي ٿو شاخن جي وڏي تعداد جي ڪري (هڪ IDE ڪيبل جي ياد ڏياريندڙ).
  • خودڪار ڊيبگنگ کي وڌيڪ ڏکيو بڻائي ٿو، مثال طور git bisect گهٽ مفيد - اهو صرف ملندو ڪمٽ.

بحال ڪريو

• ريپليز موجوده برانچ مان هڪ ٻئي پٺيان بنيادي شاخ جي چوٽي تي ڪم ڪري ٿو.
  • نون SHAs سان نوان ڪمٽ ٺاهيا ويا آهن، جنهن ڪري GitHub ۾ ڪميٽ اصل پل جي درخواستن سان ملن ٿا، پر لاڳاپيل تبصرا نه.
  • ڪمن کي ٻيهر گڏ ڪري سگھجي ٿو ۽ عمل ۾ تبديل ڪري سگھجي ٿو، يا ان کي ھڪڙي ۾ ضم ڪري سگھجي ٿو.
• ڪيترن ئي تڪرارن کي حل ڪرڻ جي ضرورت ٿي سگھي ٿي.
• توهان کي هڪ لڪير واري ڪهاڻي برقرار رکڻ جي اجازت ڏئي ٿي.
  • ڪهاڻي پڙهڻ لاءِ آسان ٿي سگهي ٿي جيستائين اها ڪنهن معقول سبب جي ڊگهي نه هجي.
  • Автоматическая отладка и устранение неполадок несколько проще: делает возможным git bisect، خودڪار رول بيڪ کي صاف ۽ وڌيڪ اڳڪٿي ڪري سگھي ٿو.
• لڏپلاڻ واري ڪمن سان گڏ هڪ شاخ شايع ڪرڻ جي ضرورت آهي پرچم سان --force при использовании с запросами на внесение изменений.

عام طور تي، ٽيمون متفق آهن ته هميشه ساڳي حڪمت عملي استعمال ڪن جڏهن انهن کي تبديل ڪرڻ جي ضرورت آهي. اهو ٿي سگهي ٿو "خالص" ضم يا هڪ "خالص" ڪمٽ مٿي تي، يا ڪجهه وچ ۾، جيئن ته هڪ ڪم ڪرڻ سان مٿانهون مداخلت سان (git rebase -i) مقامي طور تي شاخن لاءِ جيڪي عوامي مخزن ۾ شايع ٿيل نه آهن، پر "عوامي" شاخن لاءِ ضم ٿي وڃن.

هتي اسان استعمال ڪنداسين merge.

️ Задание

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 ۽ جلد کان جلد نئين نسخي کي ترتيب ڏيڻ. ڇاڪاڻ ته APIs ۽ ڊيٽابيس اسڪيما تبديل ٿي ويندا آهن جيئن ڪوڊ پيداوار تي لڳايو ويو آهي، مسلسل پهچائڻ ۽ سٺي ٽيسٽ ڪوريج سان، واپس رولنگ عام طور تي ايندڙ ورزن ۾ ان کي درست ڪرڻ کان وڌيڪ ڏکيو ۽ خطرناڪ آهي.

جيئن ته واپس موٽڻ اسان جي صورت ۾ ڪو به خطرو نه آهي، اسان هن رستي تي هلنداسين، ڇاڪاڻ ته اهو اسان کي اجازت ڏئي ٿو

• исправить ошибку на продуктиве как можно скорее;
• ۾ ڪوڊ ٺاهيو 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 ضم ڪرڻ واري ڪمٽ کي واپس ڪرڻ کان پوءِ هاڻي متن "sneaky bug" تي مشتمل ناهي.

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 هن جي ذخيرو کي ڇڪيو в качестве "base branch", я не буду отвечать на запросы на изменения в репозиторий с материалами курса.

پل جي درخواست کي منظور ڪريو "خصوصيت کي درست ڪرڻ"

اصلاح لاءِ مهرباني! مھرباني ڪري تبديلين کي منظور ڪريو master ڇڪڻ جي درخواست کان.

️ Задание

1. "ضم ڪرڻ جي درخواست" تي ڪلڪ ڪريو.
2. "ضم ٿيڻ جي تصديق ڪريو" تي ڪلڪ ڪريو.
3. "شاخ کي حذف ڪريو" تي ڪلڪ ڪريو ڇو ته اسان کي وڌيڪ ضرورت ناهي.

اھو اھو آھي جيڪو توھان کي ھن وقت ھجڻ گھرجي.

مبارڪون هجن!

توهان اهي سڀئي مرحلا مڪمل ڪيا آهن جيڪي ماڻهو عام طور تي مسلسل انضمام دوران کڻندا آهن.

جيڪڏهن توهان ڪورس سان ڪا به پريشاني محسوس ڪندا آهيو يا ڄاڻو ٿا ته ان کي ڪيئن بهتر ڪجي، مهرباني ڪري هڪ مسئلو ٺاهيو ڪورس مواد سان گڏ ذخيرو. هي ڪورس پڻ آهي интерактивная версия использующая GitHub Learning Lab в качестве платформы.

جو ذريعو: www.habr.com