کیا آپ نے Git کمانڈز سیکھے ہیں لیکن تصور کرنا چاہتے ہیں کہ مسلسل انضمام (CI) حقیقت میں کیسے کام کرتا ہے؟ یا شاید آپ اپنی روزمرہ کی سرگرمیوں کو بہتر بنانا چاہتے ہیں؟ یہ کورس آپ کو GitHub ذخیرہ کا استعمال کرتے ہوئے مسلسل انضمام میں عملی مہارت فراہم کرے گا۔ اس کورس کا مقصد ایک جادوگر ہونا نہیں ہے جس کے ذریعے آپ آسانی سے کلک کر سکتے ہیں؛ اس کے برعکس، آپ وہی اعمال انجام دیں گے جو لوگ کام پر کرتے ہیں، بالکل اسی طرح جیسے وہ کرتے ہیں۔ جب آپ اس میں شامل مراحل سے گزریں گے تو میں نظریہ کی وضاحت کروں گا۔

ہم کیا کریں؟

جیسے جیسے ہم ترقی کریں گے، ہم آہستہ آہستہ عام CI اقدامات کی ایک فہرست بنائیں گے، جو اس فہرست کو یاد رکھنے کا ایک بہترین طریقہ ہے۔ دوسرے لفظوں میں، ہم ان اقدامات کی ایک فہرست بنائیں گے جو ڈویلپر مسلسل انضمام کرتے ہوئے کرتے ہیں، مسلسل انضمام کرتے ہیں۔ ہم اپنے CI عمل کو حقیقی کے قریب لانے کے لیے ٹیسٹوں کا ایک سادہ سیٹ بھی استعمال کریں گے۔

یہ GIF اسکیمیٹک طور پر آپ کے ذخیرے میں کمٹ کو دکھاتا ہے جب آپ کورس کے ذریعے ترقی کرتے ہیں۔ جیسا کہ آپ دیکھ سکتے ہیں، یہاں کچھ بھی پیچیدہ نہیں ہے اور صرف سب سے زیادہ ضروری ہے۔

آپ درج ذیل معیاری CI منظرناموں سے گزریں گے:

• ایک خصوصیت پر کام کرنا؛
• معیار کو یقینی بنانے کے لیے خودکار ٹیسٹوں کا اطلاق؛
• ترجیحی کام کا نفاذ؛
• شاخوں کو ضم کرتے وقت تنازعات کا حل (تصادم کو ضم کریں)؛
• پیداواری ماحول میں ایک خرابی ہوتی ہے۔

آپ کیا سیکھیں گے؟

آپ درج ذیل سوالات کے جوابات دے سکیں گے۔

• مسلسل انضمام (CI) کیا ہے؟
• CI میں کس قسم کے خودکار ٹیسٹ استعمال کیے جاتے ہیں، اور ان کے جواب میں کن کارروائیوں کو متحرک کیا جاتا ہے؟
• پل کی درخواستیں کیا ہیں اور ان کی کب ضرورت ہے؟
• ٹیسٹ ڈرائیون ڈیولپمنٹ (TDD) کیا ہے اور اس کا CI سے کیا تعلق ہے؟
• کیا مجھے تبدیلیوں کو ضم یا دوبارہ ترتیب دینا چاہئے؟
• رول بیک کریں یا اگلے ورژن میں ٹھیک کریں؟

پہلے میں نے ہر جگہ "پل درخواستیں" جیسی چیزوں کا ترجمہ کیا، لیکن اس کے نتیجے میں میں نے متن میں پاگل پن کو کم کرنے کے لیے کچھ جگہوں پر انگریزی میں جملے واپس کرنے کا فیصلہ کیا۔ میں کبھی کبھی "پروگرامر سرزیک" کا استعمال کروں گا جیسے شاندار فعل "عزم" جہاں لوگ اسے کام پر اصل میں استعمال کرتے ہیں۔

مسلسل انضمام کیا ہے؟

مسلسل انضمام، یا CI، ایک تکنیکی مشق ہے جس میں ہر ٹیم کا رکن اپنے کوڈ کو دن میں کم از کم ایک بار ایک مشترکہ ذخیرہ میں ضم کرتا ہے، اور نتیجے میں آنے والا کوڈ کم از کم بغیر کسی غلطی کے بنایا جانا چاہیے۔

اس اصطلاح کے بارے میں اختلاف ہے۔

تنازعہ کا نقطہ انضمام کی تعدد ہے۔ کچھ لوگ دلیل دیتے ہیں کہ دن میں صرف ایک بار کوڈ کو ضم کرنا دراصل مسلسل انضمام کے لیے کافی نہیں ہے۔ ایک ٹیم کی مثال دی گئی ہے جہاں ہر کوئی صبح تازہ کوڈ لیتا ہے اور شام کو ایک بار اس کو مربوط کرتا ہے۔ اگرچہ یہ ایک معقول اعتراض ہے، لیکن عام طور پر یہ خیال کیا جاتا ہے کہ دن میں ایک بار کی تعریف معقول حد تک عملی، مخصوص اور مختلف سائز کی ٹیموں کے لیے موزوں ہے۔

ایک اور اعتراض یہ ہے کہ C++ اب ترقی میں استعمال ہونے والی واحد زبان نہیں ہے، اور توثیق کے طریقے کے طور پر غلطی سے پاک اسمبلی کی ضرورت کمزور ہے۔ ٹیسٹوں کے کچھ سیٹ (مثال کے طور پر، مقامی طور پر کیے جانے والے یونٹ ٹیسٹ) کو بھی کامیابی سے مکمل کرنا چاہیے۔ اس وقت، کمیونٹی اسے ایک ضرورت بنانے کی طرف بڑھ رہی ہے، اور مستقبل میں "تعمیر + یونٹ ٹیسٹ" شاید عام رواج بن جائے گا، اگر یہ پہلے سے نہیں ہے۔

مسلسل انضمام سے مختلف ہے مسلسل ترسیل (مسلسل ڈیلیوری، CD) اس میں کہ ہر انضمام سائیکل کے بعد اسے ریلیز امیدوار کی ضرورت نہیں ہے۔

ان اقدامات کی فہرست جو ہم پورے کورس میں استعمال کریں گے۔

1. تازہ ترین کوڈ کو کھینچیں۔ سے ایک برانچ بنائیں master. کام شروع کرو.
2. اپنی نئی برانچ پر کمٹ بنائیں۔ مقامی طور پر بنائیں اور ٹیسٹ کریں۔ پاس؟ اگلے مرحلے پر جائیں۔ ناکام؟ غلطیوں یا ٹیسٹوں کو درست کریں اور دوبارہ کوشش کریں۔
3. اپنے ریموٹ ریپوزٹری یا ریموٹ برانچ پر پش کریں۔
4. پل کی درخواست بنائیں۔ تبدیلیوں پر تبادلہ خیال کریں، بحث جاری رہنے پر مزید کمٹ شامل کریں۔ فیچر برانچ پر ٹیسٹ پاس کرائیں۔
5. ضم/ریبیس ماسٹر سے کمٹ کرتا ہے۔ انضمام کے نتائج پر ٹیسٹ پاس کریں۔
6. فیچر برانچ سے پروڈکشن تک تعینات کریں۔
7. اگر کچھ عرصے کے لیے پیداوار میں سب کچھ اچھا ہے، تو تبدیلیوں کو ماسٹر میں ضم کریں۔

️ تیاری

یقینی بنائیں کہ آپ کے پاس صحیح سافٹ ویئر ہے۔

اس کورس کو لینے کے لیے آپ کو ضرورت ہوگی۔ Node.js и گٹ کلائنٹ.

آپ کسی بھی گٹ کلائنٹ کو استعمال کرسکتے ہیں، لیکن میں صرف کمانڈ لائن کے لیے کمانڈ فراہم کروں گا۔

یقینی بنائیں کہ آپ کے پاس گٹ کلائنٹ انسٹال ہے جو کمانڈ لائن کو سپورٹ کرتا ہے۔

اگر آپ کے پاس ابھی تک گٹ کلائنٹ نہیں ہے جو کمانڈ لائن کو سپورٹ کرتا ہو، تو آپ انسٹالیشن کی ہدایات حاصل کر سکتے ہیں۔ یہاں.

ذخیرہ تیار کریں۔

آپ کو ذاتی کاپی بنانے کی ضرورت ہوگی (فورک) کورس کے کوڈ کے ساتھ ٹیمپلیٹ ریپوزٹری 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. فائل میں پہلے 4 مراحل کے ساتھ متن شامل کریں۔ ci.md.

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

   ٹیمیں

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

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

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

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

ایک نئی برانچ پر کمٹ بنائیں، مقامی طور پر بنائیں اور ٹیسٹ کریں۔

ہم ارتکاب کرنے سے پہلے چلانے کے لیے ٹیسٹ ترتیب دینے جا رہے ہیں، اور پھر کوڈ کا ارتکاب کریں گے۔

عام حالات جب ٹیسٹ خود بخود چلتے ہیں۔

• مقامی طور پر:
  • مسلسل یا مناسب کوڈ تبدیلیوں کے جواب میں؛
  • محفوظ کرنے پر (تشریح شدہ یا جے آئی ٹی کی مرتب کردہ زبانوں کے لیے)؛
  • اسمبلی کے دوران (جب تالیف کی ضرورت ہو)؛
  • عہد پر؛
  • مشترکہ ذخیرہ میں شائع کرتے وقت۔

• بلڈ سرور یا تعمیراتی ماحول پر:
  • جب کوڈ کسی ذاتی برانچ/ریپوزٹری میں شائع کیا جاتا ہے۔
  • اس تھریڈ میں موجود کوڈ کی جانچ کی جا رہی ہے۔
  • انضمام کے ممکنہ نتیجہ کی جانچ کی جاتی ہے (عام طور پر اس کے ساتھ master).
  • مسلسل انضمام کے مرحلے/مسلسل ترسیل پائپ لائن کے طور پر

عام طور پر، ٹیسٹ سویٹ جتنی تیزی سے چلتا ہے، آپ اسے چلانے کے لیے اتنا ہی زیادہ برداشت کر سکتے ہیں۔ ایک عام مرحلے کی تقسیم اس طرح نظر آسکتی ہے۔

• تیز یونٹ ٹیسٹ - تعمیر کے دوران، 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 پر اوپن سورس پروجیکٹس میں استعمال ہوتا ہے۔ یہ میرے ایڈوانس کورس میں بھی استعمال ہوتا ہے [ٹیم ورک اور سی آئی کے ساتھ گٹ] (http://devops.redpill.solutions/).
• ایک اور طریقہ یہ ہے کہ صرف ایک ریموٹ ریپوزٹری کا استعمال کیا جائے اور صرف برانچ کی گنتی کی جائے۔ master مشترکہ ذخیرہ "محفوظ"۔ اس منظر نامے میں، انفرادی ڈویلپرز اپنے کوڈ کو دور دراز کے ذخیرے کی شاخوں میں شائع کرتے ہیں تاکہ دوسرے اس کوڈ کو دیکھ سکیں، اگر سب کچھ ٹھیک ہے، تو اسے اس کے ساتھ ضم کریں۔ master مشترکہ ذخیرہ.

اس خاص کورس میں، ہم ایک ورک فلو استعمال کریں گے جو شاخوں کو استعمال کرتا ہے۔

آئیے اپنا کوڈ شائع کریں۔

️ٹاسک

• آپ کی ورکنگ برانچ کے نام کے ساتھ ریموٹ برانچ میں تبدیلیاں شائع کریں۔

ٹیمیں

git push --set-upstream origin feature

پل کی درخواست بنائیں

عنوان کے ساتھ پل کی درخواست بنائیں اقدامات کا جائزہ لیں۔. انسٹال کریں۔ feature جیسے "سر کی شاخ" اور master جیسے "بیس برانچ"۔

یقینی بنائیں کہ آپ نے انسٹال کر لیا ہے۔ master اس میں ذخیرہ کانٹا ایک "بیس برانچ" کے طور پر، میں کورس کے مواد کے ذخیرے میں تبدیلیوں کی درخواستوں کا جواب نہیں دوں گا۔

GitHub lingo میں، "بیس برانچ" وہ برانچ ہے جس پر آپ اپنے کام کی بنیاد رکھتے ہیں، اور "ہیڈ برانچ" وہ برانچ ہے جس میں مجوزہ تبدیلیاں ہوتی ہیں۔

تبدیلیوں پر تبادلہ خیال کریں، بحث جاری رہنے کے ساتھ ہی نئے وعدے شامل کریں۔

کھینچنے کی درخواست (PR)

کھینچنے کی درخواست (PR) کوڈ پر بحث کرنے اور دستاویز کرنے کے ساتھ ساتھ کوڈ کا جائزہ لینے کا ایک طریقہ ہے۔ پل کی درخواستوں کا نام مجموعی کوڈ میں انفرادی تبدیلیوں کو ضم کرنے کے عمومی طریقے کے نام پر رکھا گیا ہے۔ عام طور پر، ایک شخص پروجیکٹ کے ریموٹ آفیشل ریپوزٹری کو کلون کرتا ہے اور مقامی طور پر کوڈ پر کام کرتا ہے۔ اس کے بعد، وہ کوڈ کو اپنے ذاتی ریموٹ ریپوزٹری میں رکھتا ہے اور سرکاری ذخیرے کے ذمہ داروں سے کہتا ہے کہ وہ اٹھا لیں(ھیںچو) اس کا کوڈ ان کے مقامی ذخیروں میں ہے، جہاں وہ جائزہ لیتے ہیں اور ممکنہ طور پر انضمام کرتے ہیں(ضم) اس کا۔ یہ تصور دوسرے ناموں سے بھی جانا جاتا ہے، مثال کے طور پر، ضم کرنے کی درخواست.

آپ کو درحقیقت GitHub یا اس سے ملتے جلتے پلیٹ فارمز کی پل ریکوئسٹ فیچر استعمال کرنے کی ضرورت نہیں ہے۔ ترقیاتی ٹیمیں رابطے کے دیگر طریقے استعمال کر سکتی ہیں، بشمول آمنے سامنے بات چیت، صوتی کالیں، یا ای میل، لیکن فورم کی طرز کی پل کی درخواستوں کو استعمال کرنے کی اب بھی بہت سی وجوہات ہیں۔ ان میں سے کچھ یہ ہیں:

• مخصوص کوڈ کی تبدیلیوں سے متعلق منظم گفتگو؛
• آٹوٹیسٹرز اور ساتھیوں دونوں کی جانب سے جاری کام پر فیڈ بیک دیکھنے کے لیے ایک جگہ کے طور پر؛
• کوڈ کے جائزوں کو باقاعدہ بنانا؛
• تاکہ بعد میں آپ کوڈ کے اس یا اس ٹکڑے کے پیچھے وجوہات اور تحفظات معلوم کر سکیں۔

عام طور پر جب آپ کو کسی چیز پر بحث کرنے یا رائے حاصل کرنے کی ضرورت ہو تو آپ پل کی درخواست بناتے ہیں۔ مثال کے طور پر، اگر آپ کسی ایسی خصوصیت پر کام کر رہے ہیں جسے ایک سے زیادہ طریقوں سے لاگو کیا جا سکتا ہے، تو آپ کوڈ کی پہلی لائن لکھنے سے پہلے اپنے خیالات کا اشتراک کرنے اور اپنے ساتھیوں کے ساتھ اپنے منصوبوں پر بات کرنے کے لیے ایک پل کی درخواست کر سکتے ہیں۔ اگر کام آسان ہے، تو پل کی درخواست اس وقت کھولی جاتی ہے جب کچھ پہلے ہی کیا جا چکا ہو، ارتکاب ہو، اور اس پر بات کی جا سکے۔ کچھ منظرناموں میں، آپ صرف کوالٹی کنٹرول وجوہات کی بنا پر 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 کو محفوظ کرتا ہے۔
• ایک بار تنازعات کا حل درکار ہے۔
• کہانی کو غیر خطی بنا دیتا ہے۔
  • بڑی تعداد میں شاخوں (IDE کیبل کی یاد دلانے والی) کی وجہ سے کہانی کو پڑھنا مشکل ہو سکتا ہے۔
  • خودکار ڈیبگنگ کو مزید مشکل بناتا ہے، جیسے git bisect کم مفید - یہ صرف انضمام کمٹ کو پائے گا۔

ریبیس

• ایک کے بعد ایک بیس برانچ کے اوپر موجودہ برانچ سے کمٹ ری پلے ہوتے ہیں۔
  • نئے SHAs کے ساتھ نئے وعدے تیار کیے جاتے ہیں، جس کی وجہ سے 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 اور جتنی جلدی ممکن ہو نئے ورژن کو تعینات کرنا۔ چونکہ 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 اس میں ذخیرہ کانٹا ایک "بیس برانچ" کے طور پر، میں کورس کے مواد کے ذخیرے میں تبدیلیوں کی درخواستوں کا جواب نہیں دوں گا۔

پل کی درخواست کو منظور کریں "فیچر کو ٹھیک کرنا"

اصلاح کے لیے شکریہ! برائے مہربانی تبدیلیوں کو منظور کریں۔ master کھینچنے کی درخواست سے۔

️ٹاسک

1. "ضم کرنے کی درخواست" پر کلک کریں۔
2. "انضمام کی تصدیق کریں" پر کلک کریں۔
3. "برانچ کو حذف کریں" پر کلک کریں کیونکہ ہمیں اس کی مزید ضرورت نہیں ہے۔

یہ وہی ہے جو آپ کو اس وقت ہونا چاہئے.

مبارک ہو!

آپ نے وہ تمام اقدامات مکمل کر لیے ہیں جو لوگ عام طور پر مسلسل انضمام کے دوران اٹھاتے ہیں۔

اگر آپ کو کورس میں کوئی دشواری نظر آتی ہے یا آپ جانتے ہیں کہ اسے کیسے بہتر بنایا جائے، تو براہ کرم اس میں ایک مسئلہ پیدا کریں۔ کورس کے مواد کے ساتھ ذخیرہ. یہ کورس بھی ہے۔ انٹرایکٹو ورژن GitHub لرننگ لیب کو بطور پلیٹ فارم استعمال کرنا۔

ماخذ: www.habr.com