28 KiB

Raw Blame History Unescape Escape

GitHub کا تعارف

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

اسکیچ نوٹ: Tomomi Imura

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

تعارف

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

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

ضروریات

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

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

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

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

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

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

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

تیاری

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

کوڈ مینجمنٹ

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

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

ویڈیو دیکھیں

GitHub پر ریپوزیٹری بنائیں۔ GitHub.com پر، ریپوزیٹریز ٹیب میں، یا نیویگیشن بار کے اوپر دائیں جانب، نیا ریپو بٹن تلاش کریں۔
1. اپنی ریپوزیٹری (فولڈر) کو ایک نام دیں۔
2. ریپوزیٹری بنائیں منتخب کریں۔
اپنے ورکنگ فولڈر پر جائیں۔ اپنے ٹرمینل میں، اس فولڈر (جسے ڈائریکٹری بھی کہا جاتا ہے) پر سوئچ کریں جسے آپ ٹریک کرنا شروع کرنا چاہتے ہیں۔ درج کریں:
```
cd [name of your folder]
```
Git ریپوزیٹری کو انیشیئلائز کریں۔ اپنے پروجیکٹ میں درج کریں:
```
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 آپ کی فائلوں کو ٹریک کر رہا ہے۔ تبدیلی کو مستقل بنانے کے لیے آپ کو فائلوں کو کمیٹ کرنا ہوگا۔ ایسا کرنے کے لیے آپ git commit کمانڈ کے ساتھ ایک کمیٹ بناتے ہیں۔ ایک کمیٹ آپ کے ریپو کی تاریخ میں ایک محفوظ پوائنٹ کی نمائندگی کرتا ہے۔ درج ذیل درج کریں:
```
git commit -m "first commit"
```
یہ آپ کی تمام فائلوں کو کمیٹ کرتا ہے، اور پیغام "پہلا کمیٹ" شامل کرتا ہے۔ مستقبل کے کمیٹ میسیجز کے لیے آپ اپنی وضاحت میں زیادہ وضاحتی ہونا چاہیں گے تاکہ یہ ظاہر ہو سکے کہ آپ نے کس قسم کی تبدیلی کی ہے۔
اپنے لوکل Git ریپو کو GitHub کے ساتھ کنیکٹ کریں۔ ایک Git ریپو آپ کے کمپیوٹر پر اچھا ہے لیکن کسی وقت آپ اپنی فائلوں کا بیک اپ کہیں رکھنا چاہتے ہیں اور دوسروں کو اپنے ریپو پر کام کرنے کی دعوت دینا چاہتے ہیں۔ ایسا کرنے کے لیے ایک بہترین جگہ GitHub ہے۔ یاد رکھیں کہ ہم نے پہلے ہی GitHub پر ایک ریپو بنایا ہے، لہذا ہمیں صرف اپنے لوکل Git ریپو کو GitHub کے ساتھ کنیکٹ کرنا ہے۔ کمانڈ git remote add یہی کام کرے گی۔ درج ذیل کمانڈ درج کریں:

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

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

کمیٹ میسیجز

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

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

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

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

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

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

ویڈیو دیکھیں

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

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

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

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

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

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

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

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

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

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

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

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

کسی مختلف برانچ پر سوئچ کرنے کے لیے، جدید git switch کمانڈ استعمال کریں:
```
git switch [branch_name]
```
اپنا کام GitHub پر بھیجیں۔ اپنا کام GitHub پر بھیجنے کا مطلب دو چیزیں ہیں۔ اپنی برانچ کو اپنے ریپو پر پش کریں اور پھر ایک PR، Pull Request کھولیں۔
```
git push --set-upstream origin [branch-name]
```
اوپر دی گئی کمانڈ آپ کے فورک کیے گئے ریپو پر برانچ بناتی ہے۔
PR کھولیں۔ اگلا مرحلہ PR کھولنا ہے۔ آپ یہ کام GitHub پر فورک کیے گئے ریپو پر جا کر کرتے ہیں۔ GitHub پر آپ کو ایک اشارہ نظر آئے گا جہاں یہ پوچھا جائے گا کہ آیا آپ نیا PR بنانا چاہتے ہیں، آپ اس پر کلک کریں گے اور ایک انٹرفیس پر پہنچیں گے جہاں آپ کمیٹ میسج کا عنوان تبدیل کر سکتے ہیں اور اسے ایک مناسب تفصیل دے سکتے ہیں۔ اب وہ ریپو کا مینٹینر جسے آپ نے فورک کیا تھا، اس PR کو دیکھے گا اور امید ہے کہ وہ آپ کی کوشش کو سراہیں گے اور merge کریں گے۔ آپ اب ایک کنٹریبیوٹر ہیں، واہ! :)
صفائی کریں۔ یہ اچھا عمل سمجھا جاتا ہے کہ PR کامیابی سے merge ہونے کے بعد صفائی کریں۔ آپ کو اپنی لوکل برانچ اور وہ برانچ جو آپ نے GitHub پر پش کی تھی، دونوں کو صاف کرنا ہوگا۔ پہلے اسے لوکل طور پر درج ذیل کمانڈ کے ذریعے ڈیلیٹ کریں:
```
git branch -d [branch-name]
```
اس کے بعد GitHub پر فورک کیے گئے ریپو کے صفحے پر جائیں اور وہ ریموٹ برانچ ہٹا دیں جو آپ نے ابھی پش کی تھی۔

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

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

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

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

git pull

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

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

✅ 'beginner-friendly' ریپوز تلاش کرنے کا ایک اچھا طریقہ یہ ہے کہ tag 'good-first-issue' کے ذریعے تلاش کریں۔

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

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

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

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

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

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

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

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

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

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

🚀 چیلنج

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

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

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

اوپن سورس سافٹ ویئر میں تعاون کرنے کے بارے میں مزید پڑھیں۔

Git cheatsheet۔

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

GitHub پر پہلا ہفتہ

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

اسائنمنٹ

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

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

28 KiB Raw Blame History Unescape Escape