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)، اور اپنا ٹرمینل (یا: کمانڈ پرامپٹ) کھولنے کی ضرورت ہوگی۔

githhub.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 کمانڈ استعمال کرتے ہیں۔ ایک کمیٹ آپ کی ریپو کی ہسٹری میں ایک محفوظ پوائنٹ کی نمائندگی کرتا ہے۔ کمیٹ بنانے کے لیے درج ذیل ٹائپ کریں:
```
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 بنانے میں مدد کرتے ہیں، آپ انہیں آزما سکتے ہیں۔

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

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

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

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

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

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

git pull

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

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

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

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

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

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

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

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

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

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

پروجیکٹس میں ایک مسئلہ ٹریکر ہوتا ہے، زیادہ تر GitHub پر "Issues" ٹیب میں جب تک کہ دوسری جگہ نہ بتایا جائے، جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ اور Pull Requests ٹیب وہ جگہ ہے جہاں لوگ جاری تبدیلیوں پر بحث اور جائزہ لیتے ہیں۔

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

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

🚀 چیلنج

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

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

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

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

Git cheatsheet۔

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

GitHub پر پہلا ہفتہ

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

اسائنمنٹ

GitHub پر پہلا ہفتہ کورس مکمل کریں۔

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

27 KiB Raw Permalink Blame History Unescape Escape