27 KiB

Raw Permalink Blame History Unescape Escape

گِٹ ہب کا تعارف

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

اسکیچ نوٹ از Tomomi Imura

لیکچر سے پہلے کا کوئز

تعارف

اس سبق میں ہم درج ذیل موضوعات کا احاطہ کریں گے:

اپنی مشین پر کیے گئے کام کو ٹریک کرنا
دوسروں کے ساتھ پروجیکٹس پر کام کرنا
اوپن سورس سافٹ ویئر میں حصہ ڈالنے کا طریقہ

ضروریات

شروع کرنے سے پہلے، آپ کو یہ چیک کرنا ہوگا کہ آیا گِٹ انسٹال ہے یا نہیں۔ ٹرمینل میں درج کریں:
git --version

اگر گِٹ انسٹال نہیں ہے، تو گِٹ ڈاؤن لوڈ کریں۔ پھر، اپنے لوکل گِٹ پروفائل کو ٹرمینل میں سیٹ اپ کریں:

git config --global user.name "your-name"
git config --global user.email "your-email"

یہ چیک کرنے کے لیے کہ آیا گِٹ پہلے سے کنفیگرڈ ہے، درج کریں: git config --list

آپ کو ایک گِٹ ہب اکاؤنٹ، ایک کوڈ ایڈیٹر (جیسے Visual Studio Code)، اور ٹرمینل (یا: کمانڈ پرامپٹ) کھولنے کی ضرورت ہوگی۔

github.com پر جائیں اور اگر آپ کے پاس پہلے سے اکاؤنٹ نہیں ہے تو ایک اکاؤنٹ بنائیں، یا لاگ ان کریں اور اپنا پروفائل مکمل کریں۔

✅ گِٹ ہب دنیا میں واحد کوڈ ریپوزٹری نہیں ہے؛ دیگر بھی موجود ہیں، لیکن گِٹ ہب سب سے زیادہ مشہور ہے۔

تیاری

آپ کو اپنی لوکل مشین (لیپ ٹاپ یا پی سی) پر کوڈ پروجیکٹ کے ساتھ ایک فولڈر اور گِٹ ہب پر ایک پبلک ریپوزٹری کی ضرورت ہوگی، جو دوسروں کے پروجیکٹس میں حصہ ڈالنے کی مثال کے طور پر کام کرے گی۔

کوڈ مینجمنٹ

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

کام: ریپوزٹری بنائیں اور کوڈ کمیٹ کریں

ویڈیو دیکھیں

گِٹ ہب پر ریپوزٹری بنائیں۔ GitHub.com پر، ریپوزٹریز ٹیب میں، یا نیویگیشن بار کے اوپر دائیں جانب، نئی ریپو بٹن تلاش کریں۔
1. اپنی ریپوزٹری (فولڈر) کو ایک نام دیں۔
2. ریپوزٹری بنائیں کو منتخب کریں۔
اپنے ورکنگ فولڈر پر جائیں۔ اپنے ٹرمینل میں، اس فولڈر (جسے ڈائریکٹری بھی کہا جاتا ہے) پر جائیں جسے آپ ٹریک کرنا چاہتے ہیں۔ درج کریں:
```
cd [name of your folder]
```
گِٹ ریپوزٹری کو انیشیالائز کریں۔ اپنے پروجیکٹ میں درج کریں:
```
git init
```
اسٹیٹس چیک کریں۔ ریپوزٹری کی اسٹیٹس چیک کرنے کے لیے درج کریں:
```
git status
```
آؤٹ پٹ کچھ اس طرح نظر آ سکتا ہے:
```
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

     modified:   file.txt
     modified:   file2.txt
```
عام طور پر git status کمانڈ آپ کو یہ بتاتی ہے کہ کون سی فائلیں ریپو میں محفوظ کرنے کے لیے تیار ہیں یا ان میں ایسی تبدیلیاں ہیں جنہیں آپ محفوظ کرنا چاہتے ہیں۔
تمام فائلوں کو ٹریکنگ کے لیے شامل کریں
اسے فائلوں کو اسٹیجنگ ایریا میں شامل کرنا بھی کہا جاتا ہے۔
```
git add .
```
git add کے ساتھ . دلیل یہ ظاہر کرتی ہے کہ آپ کی تمام فائلیں اور تبدیلیاں ٹریکنگ کے لیے شامل کی جائیں۔
منتخب فائلوں کو ٹریکنگ کے لیے شامل کریں
```
git add [file or folder name]
```
یہ کمانڈ ہمیں صرف منتخب فائلوں کو اسٹیجنگ ایریا میں شامل کرنے میں مدد دیتی ہے جب ہم تمام فائلوں کو ایک ساتھ کمیٹ نہیں کرنا چاہتے۔
تمام فائلوں کو ان اسٹیج کریں
```
git reset
```
یہ کمانڈ ہمیں تمام فائلوں کو ایک ساتھ ان اسٹیج کرنے میں مدد دیتی ہے۔
کسی خاص فائل کو ان اسٹیج کریں
```
git reset [file or folder name]
```
یہ کمانڈ ہمیں کسی خاص فائل کو ان اسٹیج کرنے میں مدد دیتی ہے جسے ہم اگلے کمیٹ میں شامل نہیں کرنا چاہتے۔
اپنے کام کو محفوظ کریں۔ اس مرحلے پر آپ نے فائلوں کو اسٹیجنگ ایریا میں شامل کر لیا ہے۔ یہ وہ جگہ ہے جہاں گِٹ آپ کی فائلوں کو ٹریک کر رہا ہے۔ تبدیلی کو مستقل بنانے کے لیے آپ کو فائلوں کو کمیٹ کرنا ہوگا۔ ایسا کرنے کے لیے درج ذیل کمانڈ استعمال کریں:
```
git commit -m "first commit"
```
یہ آپ کی تمام فائلوں کو کمیٹ کرتا ہے اور "پہلا کمیٹ" کا میسج شامل کرتا ہے۔ مستقبل کے کمیٹ میسجز کے لیے آپ کو زیادہ وضاحتی تفصیل فراہم کرنی چاہیے تاکہ یہ ظاہر ہو کہ آپ نے کس قسم کی تبدیلی کی ہے۔
اپنے لوکل گِٹ ریپو کو گِٹ ہب سے جوڑیں۔ ایک گِٹ ریپو آپ کی مشین پر اچھا ہے لیکن کسی وقت آپ اپنی فائلوں کا بیک اپ کہیں اور لینا چاہیں گے اور دوسروں کو اپنے ریپو پر کام کرنے کی دعوت دینا چاہیں گے۔ گِٹ ہب ایسا کرنے کے لیے ایک بہترین جگہ ہے۔ یاد رکھیں کہ ہم نے پہلے ہی گِٹ ہب پر ایک ریپو بنایا ہے، لہذا ہمیں صرف اپنے لوکل گِٹ ریپو کو گِٹ ہب سے جوڑنا ہے۔ کمانڈ git remote add یہ کام کرے گی۔ درج ذیل کمانڈ درج کریں:

نوٹ، کمانڈ درج کرنے سے پہلے اپنے گِٹ ہب ریپو پیج پر جائیں اور ریپوزٹری یو آر ایل تلاش کریں۔ آپ اسے نیچے دی گئی کمانڈ میں استعمال کریں گے۔ https://github.com/username/repository_name.git کو اپنے گِٹ ہب یو آر ایل سے تبدیل کریں۔
```
git remote add origin https://github.com/username/repository_name.git
```
یہ ایک ریموٹ یا کنکشن بناتا ہے، جسے "origin" کہا جاتا ہے، جو آپ کے پہلے سے بنائے گئے گِٹ ہب ریپوزٹری کی طرف اشارہ کرتا ہے۔
لوکل فائلوں کو گِٹ ہب پر بھیجیں۔ اب تک آپ نے لوکل ریپو اور گِٹ ہب ریپو کے درمیان ایک کنکشن بنایا ہے۔ آئیے ان فائلوں کو گِٹ ہب پر بھیجتے ہیں درج ذیل کمانڈ git push کے ساتھ:

نوٹ، آپ کی برانچ کا نام main سے مختلف ہو سکتا ہے۔
```
git push -u origin main
```
یہ آپ کی "main" برانچ میں موجود کمیٹس کو گِٹ ہب پر بھیج دیتا ہے۔
مزید تبدیلیاں شامل کریں۔ اگر آپ مزید تبدیلیاں کرنا چاہتے ہیں اور انہیں گِٹ ہب پر بھیجنا چاہتے ہیں تو آپ کو صرف درج ذیل تین کمانڈز استعمال کرنے کی ضرورت ہوگی:
```
git add .
git commit -m "type your commit message here"
git push
```
ٹپ، آپ .gitignore فائل اپنانا بھی چاہ سکتے ہیں تاکہ وہ فائلیں جو آپ ٹریک نہیں کرنا چاہتے گِٹ ہب پر ظاہر نہ ہوں - جیسے وہ نوٹس فائل جو آپ اسی فولڈر میں محفوظ کرتے ہیں لیکن اس کا پبلک ریپوزٹری میں کوئی کام نہیں۔ آپ .gitignore فائلز کے ٹیمپلیٹس یہاں تلاش کر سکتے ہیں: .gitignore templates۔

کمیٹ میسجز

ایک بہترین گِٹ کمیٹ سبجیکٹ لائن درج ذیل جملے کو مکمل کرتی ہے:
اگر لاگو کیا گیا، تو یہ کمیٹ <آپ کا سبجیکٹ لائن یہاں> کرے گا۔

سبجیکٹ کے لیے حکم دینے والا، موجودہ زمانہ استعمال کریں: "change" نہ کہ "changed" یا "changes"۔
سبجیکٹ کی طرح، باڈی (اختیاری) میں بھی حکم دینے والا، موجودہ زمانہ استعمال کریں۔ باڈی میں تبدیلی کی وجہ شامل کریں اور اسے پچھلے رویے کے ساتھ موازنہ کریں۔ آپ کیوں کی وضاحت کر رہے ہیں، کیسے کی نہیں۔

✅ گِٹ ہب پر کچھ وقت گزاریں۔ کیا آپ کوئی واقعی بہترین کمیٹ میسج تلاش کر سکتے ہیں؟ کیا آپ کوئی بہت ہی مختصر میسج تلاش کر سکتے ہیں؟ آپ کے خیال میں کمیٹ میسج میں کون سی معلومات سب سے زیادہ اہم اور مفید ہیں؟

کام: تعاون کریں

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

دوسروں کے ساتھ پروجیکٹس پر کام کرنا

ویڈیو دیکھیں

اپنی ریپوزٹری میں، Insights > Community پر جائیں تاکہ یہ دیکھ سکیں کہ آپ کا پروجیکٹ تجویز کردہ کمیونٹی معیارات کے ساتھ کیسے موازنہ کرتا ہے۔

یہاں کچھ چیزیں ہیں جو آپ کے گِٹ ہب ریپو کو بہتر بنا سکتی ہیں:

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

یہ تمام وسائل نئے ٹیم ممبرز کو آن بورڈ کرنے میں مددگار ثابت ہوں گے۔ اور یہ وہ چیزیں ہیں جنہیں نئے شراکت دار آپ کے کوڈ کو دیکھنے سے پہلے دیکھتے ہیں تاکہ یہ معلوم کریں کہ آیا آپ کا پروجیکٹ ان کے وقت کے قابل ہے یا نہیں۔

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

کام: کچھ کوڈ مرج کریں

شراکت کے ڈاکیومنٹس لوگوں کو پروجیکٹ میں شراکت کرنے میں مدد دیتے ہیں۔ یہ وضاحت کرتا ہے کہ آپ کس قسم کی شراکتیں تلاش کر رہے ہیں اور یہ عمل کیسے کام کرتا ہے۔ شراکت داروں کو آپ کے گِٹ ہب ریپو میں شراکت کرنے کے لیے کئی مراحل سے گزرنا ہوگا:

آپ کے ریپو کو فورک کرنا۔ آپ شاید چاہیں گے کہ لوگ آپ کے پروجیکٹ کو فورک کریں۔ فورک کرنے کا مطلب ہے کہ آپ کے ریپوزٹری کی نقل ان کے گِٹ ہب پروفائل پر بنائی جائے۔
کلون۔ اس کے بعد وہ پروجیکٹ کو اپنی لوکل مشین پر کلون کریں گے۔
برانچ بنائیں۔ آپ چاہیں گے کہ وہ اپنے کام کے لیے ایک برانچ بنائیں۔
اپنی تبدیلی کو ایک علاقے پر مرکوز کریں۔ شراکت داروں سے کہیں کہ وہ اپنی شراکت کو ایک وقت میں ایک چیز پر مرکوز کریں - اس طرح ان کے کام کو مرج کرنے کے امکانات زیادہ ہوں گے۔ تصور کریں کہ انہوں نے ایک بگ فکس لکھا، ایک نئی فیچر شامل کی، اور کئی ٹیسٹس اپڈیٹ کیے - اگر آپ 3 میں سے 2 یا 1 تبدیلیاں ہی نافذ کرنا چاہتے ہیں تو کیا ہوگا؟

✅ ایسے حالات کا تصور کریں جہاں برانچز خاص طور پر اچھا کوڈ لکھنے اور بھیجنے کے لیے اہم ہوں۔ آپ کون سے استعمال کے کیسز سوچ سکتے ہیں؟

نوٹ، وہ تبدیلی بنیں جو آپ دنیا میں دیکھنا چاہتے ہیں، اور اپنے کام کے لیے برانچز بنائیں۔ آپ جو بھی کمیٹس کریں گے وہ اس برانچ پر ہوں گے جس پر آپ اس وقت "چیک آؤٹ" ہیں۔ git status استعمال کریں تاکہ دیکھ سکیں کہ آپ کس برانچ پر ہیں۔

آئیے ایک شراکت دار کے ورک فلو سے گزرتے ہیں۔ فرض کریں کہ شراکت دار نے پہلے ہی ریپو کو فورک اور کلون کر لیا ہے تاکہ ان کے پاس ایک گِٹ ریپو ہو جس پر وہ اپنی لوکل مشین پر کام کر سکیں:

برانچ بنائیں۔ کمانڈ git branch استعمال کریں تاکہ ایک برانچ بنائی جا سکے جس میں وہ تبدیلیاں ہوں جو وہ شراکت کے لیے دینا چاہتے ہیں:
```
git branch [branch-name]
```
ورکنگ برانچ پر سوئچ کریں۔ مخصوص برانچ پر سوئچ کریں اور ورکنگ ڈائریکٹری کو اپڈیٹ کریں git switch کے ساتھ:
```
git switch [branch-name]
```
کام کریں۔ اس مرحلے پر آپ اپنی تبدیلیاں شامل کرنا چاہتے ہیں۔ گِٹ کو اس کے بارے میں بتانا نہ بھولیں درج ذیل کمانڈز کے ساتھ:
```
git add .
git commit -m "my changes"
```
یقینی بنائیں کہ آپ اپنے کمیٹ کو اچھا نام دیں، اپنے لیے اور اس ریپو کے مینٹینر کے لیے جس پر آپ مدد کر رہے ہیں۔
اپنے کام کو main برانچ کے ساتھ ملائیں۔ کسی وقت آپ کام مکمل کر لیتے ہیں اور آپ اپنے کام کو main برانچ کے ساتھ ملانا چاہتے ہیں۔ اس دوران main برانچ میں تبدیلیاں ہو سکتی ہیں، لہذا پہلے درج ذیل کمانڈز کے ساتھ اسے تازہ ترین کریں:
```
git switch main
git pull
```
اس مرحلے پر آپ یہ یقینی بنانا چاہتے ہیں کہ کوئی بھی تنازعہ، ایسی صورتحال جہاں گِٹ آسانی سے تبدیلیوں کو ملانے سے قاصر ہو، آپ کی ورکنگ برانچ میں ہو۔ اس لیے درج ذیل کمانڈز چلائیں:
```
git switch [branch_name]
git merge main
```
یہ main سے تمام تبدیلیاں آپ کی برانچ میں لائے گا اور امید ہے کہ آپ آسانی سے کام جاری رکھ سکیں گے۔ اگر نہیں، تو VS Code آپ کو بتائے گا کہ گِٹ کہاں کنفیوز ہے اور آپ متاثرہ فائلوں کو تبدیل کر کے درست مواد شامل کریں۔
اپنے کام کو گِٹ ہب پر بھیجیں۔ اپنے کام کو گِٹ ہب پر بھیجنے کا مطلب دو چیزیں ہیں۔ اپنی برانچ کو اپنے ریپو پر پش کریں اور پھر ایک PR (پُل ریکویسٹ) کھولیں۔
```
git push --set-upstream origin [branch-name]
```
اوپر دی گئی کمانڈ آپ کے فورک کیے گئے ریپو پر برانچ بناتی ہے۔
PR کھولیں۔ اگلے مرحلے میں آپ PR کھولنا چاہتے ہیں۔ ایسا کرنے کے لیے گِٹ ہب پر فورک کیے گئے ریپو پر جائیں۔ آپ کو گِٹ ہب پر ایک اشارہ نظر آئے گا جہاں یہ پوچھے گا کہ کیا آپ نیا PR بنانا چاہتے ہیں، آپ اس پر کلک کریں گے اور آپ کو ایک انٹرفیس پر لے جایا جائے گا جہاں آپ کمیٹ میسج کا عنوان تبدیل کر سکتے ہیں، اسے مزید مناسب تفصیل دے سکتے ہیں۔ اب وہ ریپو مینٹینر جسے آپ نے فورک کیا تھا اس PR کو دیکھے گا اور امید ہے وہ آپ کے PR کو سراہیں گے اور مرج کریں گے۔ آپ اب ایک شراکت دار ہیں، مبارک ہو :)
صفائی کریں۔ یہ اچھا عمل سمجھا جاتا ہے کہ PR کو کامیابی سے مرج کرنے کے بعد صفائی کریں۔ آپ اپنی لوکل برانچ اور وہ برانچ جسے آپ نے گِٹ ہب پر پش کیا تھا، دونوں کو صاف کرنا چاہتے ہیں۔ پہلے گٹ ہب کے فورکڈ ریپو کے صفحے پر جائیں اور وہ ریموٹ برانچ ہٹا دیں جسے آپ نے ابھی وہاں پش کیا ہے۔

پُل ریکویسٹ ایک عجیب سا لفظ لگتا ہے کیونکہ حقیقت میں آپ اپنی تبدیلیاں پروجیکٹ میں پش کرنا چاہتے ہیں۔ لیکن مینٹینر (پروجیکٹ کا مالک) یا کور ٹیم کو آپ کی تبدیلیوں پر غور کرنا ہوتا ہے اس سے پہلے کہ وہ پروجیکٹ کی "مین" برانچ کے ساتھ مرج کریں، اس لیے آپ حقیقت میں مینٹینر سے تبدیلی کی منظوری کی درخواست کر رہے ہیں۔

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

🤞امید ہے کہ تمام چیکس پاس ہو جائیں اور پروجیکٹ کے مالک آپ کی تبدیلیوں کو پروجیکٹ میں مرج کر دیں🤞

اپنے موجودہ لوکل ورکنگ برانچ کو گٹ ہب پر موجود متعلقہ ریموٹ برانچ سے تمام نئے کمیٹس کے ساتھ اپ ڈیٹ کریں:

git pull

اوپن سورس میں تعاون کیسے کریں

سب سے پہلے، گٹ ہب پر ایک ریپوزیٹری (یا ریپو) تلاش کریں جو آپ کے لیے دلچسپ ہو اور جس میں آپ تبدیلی کرنا چاہتے ہوں۔ آپ اس کے مواد کو اپنی مشین پر کاپی کرنا چاہیں گے۔

✅ 'بگنر فرینڈلی' ریپوز تلاش کرنے کا ایک اچھا طریقہ ٹیگ 'good-first-issue' کے ذریعے تلاش کرنا ہے۔

کوڈ کاپی کرنے کے کئی طریقے ہیں۔ ایک طریقہ یہ ہے کہ ریپوزیٹری کے مواد کو "کلون" کریں، HTTPS، SSH، یا گٹ ہب CLI (کمانڈ لائن انٹرفیس) کا استعمال کرتے ہوئے۔

اپنا ٹرمینل کھولیں اور ریپوزیٹری کو اس طرح کلون کریں: git clone https://github.com/ProjectURL

پروجیکٹ پر کام کرنے کے لیے، صحیح فولڈر پر جائیں: cd ProjectURL

آپ پورے پروجیکٹ کو Codespaces، گٹ ہب کے ایمبیڈڈ کوڈ ایڈیٹر / کلاؤڈ ڈیولپمنٹ ماحول، یا GitHub Desktop کا استعمال کرتے ہوئے بھی کھول سکتے ہیں۔

آخر میں، آپ کوڈ کو زپ فولڈر میں ڈاؤنلوڈ کر سکتے ہیں۔

گٹ ہب کے بارے میں کچھ مزید دلچسپ باتیں

آپ گٹ ہب پر کسی بھی پبلک ریپوزیٹری کو اسٹار، واچ اور/یا "فورک" کر سکتے ہیں۔ آپ اپنے اسٹار کردہ ریپوزیٹریز کو ٹاپ رائٹ ڈراپ ڈاؤن مینو میں دیکھ سکتے ہیں۔ یہ کوڈ کے لیے بک مارکنگ جیسا ہے۔

پروجیکٹس میں ایک مسئلہ ٹریکر ہوتا ہے، زیادہ تر گٹ ہب پر "Issues" ٹیب میں جب تک کہ دوسری جگہ کا ذکر نہ ہو، جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ اور پُل ریکویسٹ ٹیب وہ جگہ ہے جہاں لوگ جاری تبدیلیوں پر بات کرتے ہیں اور ان کا جائزہ لیتے ہیں۔

پروجیکٹس میں فورمز، میلنگ لسٹس، یا چیٹ چینلز جیسے کہ Slack، Discord یا IRC میں بھی گفتگو ہو سکتی ہے۔

✅ اپنے نئے گٹ ہب ریپو کے ارد گرد دیکھیں اور کچھ چیزیں آزمائیں، جیسے سیٹنگز میں ترمیم کرنا، اپنے ریپو میں معلومات شامل کرنا، اور ایک پروجیکٹ بنانا (جیسے کہ کانبان بورڈ)۔ آپ بہت کچھ کر سکتے ہیں!

🚀 چیلنج

کسی دوست کے ساتھ جوڑی بنائیں اور ایک دوسرے کے کوڈ پر کام کریں۔ ایک پروجیکٹ مل کر بنائیں، کوڈ فورک کریں، برانچز بنائیں، اور تبدیلیوں کو مرج کریں۔

لیکچر کے بعد کا کوئز

جائزہ اور خود مطالعہ

اوپن سورس سافٹ ویئر میں تعاون کے بارے میں مزید پڑھیں: contributing to open source software.

گٹ چیٹ شیٹ.

پریکٹس، پریکٹس، پریکٹس۔ گٹ ہب کے پاس skills.github.com کے ذریعے بہترین لرننگ پاتھز دستیاب ہیں:

گٹ ہب پر پہلا ہفتہ

آپ کو مزید ایڈوانس کورسز بھی ملیں گے۔

اسائنمنٹ

گٹ ہب پر پہلا ہفتہ کورس مکمل کریں۔

ڈسکلیمر:
یہ دستاویز AI ترجمہ سروس Co-op Translator کا استعمال کرتے ہوئے ترجمہ کی گئی ہے۔ ہم درستگی کے لیے کوشش کرتے ہیں، لیکن براہ کرم آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا غیر درستیاں ہو سکتی ہیں۔ اصل دستاویز کو اس کی اصل زبان میں مستند ذریعہ سمجھا جانا چاہیے۔ اہم معلومات کے لیے، پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ ہم اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کے ذمہ دار نہیں ہیں۔

27 KiB Raw Permalink Blame History Unescape Escape