You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Web-Dev-For-Beginners/translations/ur/1-getting-started-lessons/2-github-basics/README.md

333 lines
27 KiB

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

<!--
CO_OP_TRANSLATOR_METADATA:
{
"original_hash": "05666cecb8983a72cf0ce1d18932b5b7",
"translation_date": "2025-08-25T22:44:13+00:00",
"source_file": "1-getting-started-lessons/2-github-basics/README.md",
"language_code": "ur"
}
-->
# گِٹ ہب کا تعارف
یہ سبق گِٹ ہب کے بنیادی اصولوں کا احاطہ کرتا ہے، جو کہ آپ کے کوڈ کو ہوسٹ کرنے اور اس میں تبدیلیوں کو منظم کرنے کا ایک پلیٹ فارم ہے۔
![گِٹ ہب کا تعارف](../../../../translated_images/webdev101-github.8846d7971abef6f947909b4f9d343e2a23778aa716ca6b9d71df7174ee5009ac.ur.png)
> اسکیچ نوٹ از [Tomomi Imura](https://twitter.com/girlie_mac)
## لیکچر سے پہلے کا کوئز
[لیکچر سے پہلے کا کوئز](https://ff-quizzes.netlify.app/web/quiz/3)
## تعارف
اس سبق میں ہم درج ذیل موضوعات کا احاطہ کریں گے:
- اپنی مشین پر کیے گئے کام کو ٹریک کرنا
- دوسروں کے ساتھ پروجیکٹس پر کام کرنا
- اوپن سورس سافٹ ویئر میں حصہ ڈالنے کا طریقہ
### ضروریات
شروع کرنے سے پہلے، آپ کو یہ چیک کرنا ہوگا کہ آیا گِٹ انسٹال ہے یا نہیں۔ ٹرمینل میں درج کریں:
`git --version`
اگر گِٹ انسٹال نہیں ہے، تو [گِٹ ڈاؤن لوڈ کریں](https://git-scm.com/downloads)۔ پھر، اپنے لوکل گِٹ پروفائل کو ٹرمینل میں سیٹ اپ کریں:
* `git config --global user.name "your-name"`
* `git config --global user.email "your-email"`
یہ چیک کرنے کے لیے کہ آیا گِٹ پہلے سے کنفیگرڈ ہے، درج کریں:
`git config --list`
آپ کو ایک گِٹ ہب اکاؤنٹ، ایک کوڈ ایڈیٹر (جیسے Visual Studio Code)، اور ٹرمینل (یا: کمانڈ پرامپٹ) کھولنے کی ضرورت ہوگی۔
[github.com](https://github.com/) پر جائیں اور اگر آپ کے پاس پہلے سے اکاؤنٹ نہیں ہے تو ایک اکاؤنٹ بنائیں، یا لاگ ان کریں اور اپنا پروفائل مکمل کریں۔
✅ گِٹ ہب دنیا میں واحد کوڈ ریپوزٹری نہیں ہے؛ دیگر بھی موجود ہیں، لیکن گِٹ ہب سب سے زیادہ مشہور ہے۔
### تیاری
آپ کو اپنی لوکل مشین (لیپ ٹاپ یا پی سی) پر کوڈ پروجیکٹ کے ساتھ ایک فولڈر اور گِٹ ہب پر ایک پبلک ریپوزٹری کی ضرورت ہوگی، جو دوسروں کے پروجیکٹس میں حصہ ڈالنے کی مثال کے طور پر کام کرے گی۔
---
## کوڈ مینجمنٹ
فرض کریں کہ آپ کے پاس لوکل مشین پر ایک کوڈ پروجیکٹ کے ساتھ ایک فولڈر ہے اور آپ گِٹ - ورژن کنٹرول سسٹم - کا استعمال کرتے ہوئے اپنی پیش رفت کو ٹریک کرنا چاہتے ہیں۔ کچھ لوگ گِٹ کے استعمال کو اپنے مستقبل کے لیے محبت نامہ لکھنے کے مترادف سمجھتے ہیں۔ جب آپ دنوں، ہفتوں یا مہینوں بعد اپنے کمیٹ میسجز پڑھیں گے تو آپ کو یاد آئے گا کہ آپ نے کوئی فیصلہ کیوں کیا تھا، یا کسی تبدیلی کو "واپس لینا" ممکن ہوگا - بشرطیکہ آپ نے اچھے "کمیٹ میسجز" لکھے ہوں۔
### کام: ریپوزٹری بنائیں اور کوڈ کمیٹ کریں
> ویڈیو دیکھیں
>
> [![گِٹ اور گِٹ ہب کے بنیادی اصول ویڈیو](https://img.youtube.com/vi/9R31OUPpxU4/0.jpg)](https://www.youtube.com/watch?v=9R31OUPpxU4)
1. **گِٹ ہب پر ریپوزٹری بنائیں**۔ GitHub.com پر، ریپوزٹریز ٹیب میں، یا نیویگیشن بار کے اوپر دائیں جانب، **نئی ریپو** بٹن تلاش کریں۔
1. اپنی ریپوزٹری (فولڈر) کو ایک نام دیں۔
1. **ریپوزٹری بنائیں** کو منتخب کریں۔
1. **اپنے ورکنگ فولڈر پر جائیں**۔ اپنے ٹرمینل میں، اس فولڈر (جسے ڈائریکٹری بھی کہا جاتا ہے) پر جائیں جسے آپ ٹریک کرنا چاہتے ہیں۔ درج کریں:
```bash
cd [name of your folder]
```
1. **گِٹ ریپوزٹری کو انیشیالائز کریں**۔ اپنے پروجیکٹ میں درج کریں:
```bash
git init
```
1. **اسٹیٹس چیک کریں**۔ ریپوزٹری کی اسٹیٹس چیک کرنے کے لیے درج کریں:
```bash
git status
```
آؤٹ پٹ کچھ اس طرح نظر آ سکتا ہے:
```output
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` کمانڈ آپ کو یہ بتاتی ہے کہ کون سی فائلیں ریپو میں _محفوظ_ کرنے کے لیے تیار ہیں یا ان میں ایسی تبدیلیاں ہیں جنہیں آپ محفوظ کرنا چاہتے ہیں۔
1. **تمام فائلوں کو ٹریکنگ کے لیے شامل کریں**
اسے فائلوں کو اسٹیجنگ ایریا میں شامل کرنا بھی کہا جاتا ہے۔
```bash
git add .
```
`git add` کے ساتھ `.` دلیل یہ ظاہر کرتی ہے کہ آپ کی تمام فائلیں اور تبدیلیاں ٹریکنگ کے لیے شامل کی جائیں۔
1. **منتخب فائلوں کو ٹریکنگ کے لیے شامل کریں**
```bash
git add [file or folder name]
```
یہ کمانڈ ہمیں صرف منتخب فائلوں کو اسٹیجنگ ایریا میں شامل کرنے میں مدد دیتی ہے جب ہم تمام فائلوں کو ایک ساتھ کمیٹ نہیں کرنا چاہتے۔
1. **تمام فائلوں کو ان اسٹیج کریں**
```bash
git reset
```
یہ کمانڈ ہمیں تمام فائلوں کو ایک ساتھ ان اسٹیج کرنے میں مدد دیتی ہے۔
1. **کسی خاص فائل کو ان اسٹیج کریں**
```bash
git reset [file or folder name]
```
یہ کمانڈ ہمیں کسی خاص فائل کو ان اسٹیج کرنے میں مدد دیتی ہے جسے ہم اگلے کمیٹ میں شامل نہیں کرنا چاہتے۔
1. **اپنے کام کو محفوظ کریں**۔ اس مرحلے پر آپ نے فائلوں کو اسٹیجنگ ایریا میں شامل کر لیا ہے۔ یہ وہ جگہ ہے جہاں گِٹ آپ کی فائلوں کو ٹریک کر رہا ہے۔ تبدیلی کو مستقل بنانے کے لیے آپ کو فائلوں کو _کمیٹ_ کرنا ہوگا۔ ایسا کرنے کے لیے درج ذیل کمانڈ استعمال کریں:
```bash
git commit -m "first commit"
```
یہ آپ کی تمام فائلوں کو کمیٹ کرتا ہے اور "پہلا کمیٹ" کا میسج شامل کرتا ہے۔ مستقبل کے کمیٹ میسجز کے لیے آپ کو زیادہ وضاحتی تفصیل فراہم کرنی چاہیے تاکہ یہ ظاہر ہو کہ آپ نے کس قسم کی تبدیلی کی ہے۔
1. **اپنے لوکل گِٹ ریپو کو گِٹ ہب سے جوڑیں**۔ ایک گِٹ ریپو آپ کی مشین پر اچھا ہے لیکن کسی وقت آپ اپنی فائلوں کا بیک اپ کہیں اور لینا چاہیں گے اور دوسروں کو اپنے ریپو پر کام کرنے کی دعوت دینا چاہیں گے۔ گِٹ ہب ایسا کرنے کے لیے ایک بہترین جگہ ہے۔ یاد رکھیں کہ ہم نے پہلے ہی گِٹ ہب پر ایک ریپو بنایا ہے، لہذا ہمیں صرف اپنے لوکل گِٹ ریپو کو گِٹ ہب سے جوڑنا ہے۔ کمانڈ `git remote add` یہ کام کرے گی۔ درج ذیل کمانڈ درج کریں:
> نوٹ، کمانڈ درج کرنے سے پہلے اپنے گِٹ ہب ریپو پیج پر جائیں اور ریپوزٹری یو آر ایل تلاش کریں۔ آپ اسے نیچے دی گئی کمانڈ میں استعمال کریں گے۔ ```https://github.com/username/repository_name.git``` کو اپنے گِٹ ہب یو آر ایل سے تبدیل کریں۔
```bash
git remote add origin https://github.com/username/repository_name.git
```
یہ ایک _ریموٹ_ یا کنکشن بناتا ہے، جسے "origin" کہا جاتا ہے، جو آپ کے پہلے سے بنائے گئے گِٹ ہب ریپوزٹری کی طرف اشارہ کرتا ہے۔
1. **لوکل فائلوں کو گِٹ ہب پر بھیجیں**۔ اب تک آپ نے لوکل ریپو اور گِٹ ہب ریپو کے درمیان ایک _کنکشن_ بنایا ہے۔ آئیے ان فائلوں کو گِٹ ہب پر بھیجتے ہیں درج ذیل کمانڈ `git push` کے ساتھ:
> نوٹ، آپ کی برانچ کا نام ```main``` سے مختلف ہو سکتا ہے۔
```bash
git push -u origin main
```
یہ آپ کی "main" برانچ میں موجود کمیٹس کو گِٹ ہب پر بھیج دیتا ہے۔
2. **مزید تبدیلیاں شامل کریں**۔ اگر آپ مزید تبدیلیاں کرنا چاہتے ہیں اور انہیں گِٹ ہب پر بھیجنا چاہتے ہیں تو آپ کو صرف درج ذیل تین کمانڈز استعمال کرنے کی ضرورت ہوگی:
```bash
git add .
git commit -m "type your commit message here"
git push
```
> ٹپ، آپ `.gitignore` فائل اپنانا بھی چاہ سکتے ہیں تاکہ وہ فائلیں جو آپ ٹریک نہیں کرنا چاہتے گِٹ ہب پر ظاہر نہ ہوں - جیسے وہ نوٹس فائل جو آپ اسی فولڈر میں محفوظ کرتے ہیں لیکن اس کا پبلک ریپوزٹری میں کوئی کام نہیں۔ آپ `.gitignore` فائلز کے ٹیمپلیٹس یہاں تلاش کر سکتے ہیں: [.gitignore templates](https://github.com/github/gitignore)۔
#### کمیٹ میسجز
ایک بہترین گِٹ کمیٹ سبجیکٹ لائن درج ذیل جملے کو مکمل کرتی ہے:
اگر لاگو کیا گیا، تو یہ کمیٹ <آپ کا سبجیکٹ لائن یہاں> کرے گا۔
سبجیکٹ کے لیے حکم دینے والا، موجودہ زمانہ استعمال کریں: "change" نہ کہ "changed" یا "changes"۔
سبجیکٹ کی طرح، باڈی (اختیاری) میں بھی حکم دینے والا، موجودہ زمانہ استعمال کریں۔ باڈی میں تبدیلی کی وجہ شامل کریں اور اسے پچھلے رویے کے ساتھ موازنہ کریں۔ آپ `کیوں` کی وضاحت کر رہے ہیں، `کیسے` کی نہیں۔
✅ گِٹ ہب پر کچھ وقت گزاریں۔ کیا آپ کوئی واقعی بہترین کمیٹ میسج تلاش کر سکتے ہیں؟ کیا آپ کوئی بہت ہی مختصر میسج تلاش کر سکتے ہیں؟ آپ کے خیال میں کمیٹ میسج میں کون سی معلومات سب سے زیادہ اہم اور مفید ہیں؟
### کام: تعاون کریں
گِٹ ہب پر چیزیں ڈالنے کی بنیادی وجہ یہ تھی کہ دوسرے ڈویلپرز کے ساتھ تعاون ممکن ہو۔
## دوسروں کے ساتھ پروجیکٹس پر کام کرنا
> ویڈیو دیکھیں
>
> [![گِٹ اور گِٹ ہب کے بنیادی اصول ویڈیو](https://img.youtube.com/vi/bFCM-PC3cu8/0.jpg)](https://www.youtube.com/watch?v=bFCM-PC3cu8)
اپنی ریپوزٹری میں، `Insights > Community` پر جائیں تاکہ یہ دیکھ سکیں کہ آپ کا پروجیکٹ تجویز کردہ کمیونٹی معیارات کے ساتھ کیسے موازنہ کرتا ہے۔
یہاں کچھ چیزیں ہیں جو آپ کے گِٹ ہب ریپو کو بہتر بنا سکتی ہیں:
- **تفصیل**۔ کیا آپ نے اپنے پروجیکٹ کے لیے تفصیل شامل کی؟
- **README**۔ کیا آپ نے README شامل کیا؟ گِٹ ہب [README لکھنے کے لیے رہنمائی](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) فراہم کرتا ہے۔
- **شراکت کے رہنما اصول**۔ کیا آپ کے پروجیکٹ میں [شراکت کے رہنما اصول](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon) ہیں؟
- **کوڈ آف کنڈکٹ**۔ کیا آپ کے پروجیکٹ میں [کوڈ آف کنڈکٹ](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/) شامل ہے؟
- **لائسنس**۔ شاید سب سے اہم، کیا آپ کے پروجیکٹ میں [لائسنس](https://docs.github.com/articles/adding-a-license-to-a-repository/) شامل ہے؟
یہ تمام وسائل نئے ٹیم ممبرز کو آن بورڈ کرنے میں مددگار ثابت ہوں گے۔ اور یہ وہ چیزیں ہیں جنہیں نئے شراکت دار آپ کے کوڈ کو دیکھنے سے پہلے دیکھتے ہیں تاکہ یہ معلوم کریں کہ آیا آپ کا پروجیکٹ ان کے وقت کے قابل ہے یا نہیں۔
✅ README فائلز، اگرچہ انہیں تیار کرنے میں وقت لگتا ہے، اکثر مصروف مینٹینرز نظر انداز کر دیتے ہیں۔ کیا آپ کسی خاص طور پر وضاحتی README کی مثال تلاش کر سکتے ہیں؟ نوٹ: کچھ [ٹولز موجود ہیں جو اچھے READMEs بنانے میں مدد کرتے ہیں](https://www.makeareadme.com/) جنہیں آپ آزمانا چاہ سکتے ہیں۔
### کام: کچھ کوڈ مرج کریں
شراکت کے ڈاکیومنٹس لوگوں کو پروجیکٹ میں شراکت کرنے میں مدد دیتے ہیں۔ یہ وضاحت کرتا ہے کہ آپ کس قسم کی شراکتیں تلاش کر رہے ہیں اور یہ عمل کیسے کام کرتا ہے۔ شراکت داروں کو آپ کے گِٹ ہب ریپو میں شراکت کرنے کے لیے کئی مراحل سے گزرنا ہوگا:
1. **آپ کے ریپو کو فورک کرنا**۔ آپ شاید چاہیں گے کہ لوگ آپ کے پروجیکٹ کو _فورک_ کریں۔ فورک کرنے کا مطلب ہے کہ آپ کے ریپوزٹری کی نقل ان کے گِٹ ہب پروفائل پر بنائی جائے۔
1. **کلون**۔ اس کے بعد وہ پروجیکٹ کو اپنی لوکل مشین پر کلون کریں گے۔
1. **برانچ بنائیں**۔ آپ چاہیں گے کہ وہ اپنے کام کے لیے ایک _برانچ_ بنائیں۔
1. **اپنی تبدیلی کو ایک علاقے پر مرکوز کریں**۔ شراکت داروں سے کہیں کہ وہ اپنی شراکت کو ایک وقت میں ایک چیز پر مرکوز کریں - اس طرح ان کے کام کو _مرج_ کرنے کے امکانات زیادہ ہوں گے۔ تصور کریں کہ انہوں نے ایک بگ فکس لکھا، ایک نئی فیچر شامل کی، اور کئی ٹیسٹس اپڈیٹ کیے - اگر آپ 3 میں سے 2 یا 1 تبدیلیاں ہی نافذ کرنا چاہتے ہیں تو کیا ہوگا؟
✅ ایسے حالات کا تصور کریں جہاں برانچز خاص طور پر اچھا کوڈ لکھنے اور بھیجنے کے لیے اہم ہوں۔ آپ کون سے استعمال کے کیسز سوچ سکتے ہیں؟
> نوٹ، وہ تبدیلی بنیں جو آپ دنیا میں دیکھنا چاہتے ہیں، اور اپنے کام کے لیے برانچز بنائیں۔ آپ جو بھی کمیٹس کریں گے وہ اس برانچ پر ہوں گے جس پر آپ اس وقت "چیک آؤٹ" ہیں۔ `git status` استعمال کریں تاکہ دیکھ سکیں کہ آپ کس برانچ پر ہیں۔
آئیے ایک شراکت دار کے ورک فلو سے گزرتے ہیں۔ فرض کریں کہ شراکت دار نے پہلے ہی ریپو کو _فورک_ اور _کلون_ کر لیا ہے تاکہ ان کے پاس ایک گِٹ ریپو ہو جس پر وہ اپنی لوکل مشین پر کام کر سکیں:
1. **برانچ بنائیں**۔ کمانڈ `git branch` استعمال کریں تاکہ ایک برانچ بنائی جا سکے جس میں وہ تبدیلیاں ہوں جو وہ شراکت کے لیے دینا چاہتے ہیں:
```bash
git branch [branch-name]
```
1. **ورکنگ برانچ پر سوئچ کریں**۔ مخصوص برانچ پر سوئچ کریں اور ورکنگ ڈائریکٹری کو اپڈیٹ کریں `git switch` کے ساتھ:
```bash
git switch [branch-name]
```
1. **کام کریں**۔ اس مرحلے پر آپ اپنی تبدیلیاں شامل کرنا چاہتے ہیں۔ گِٹ کو اس کے بارے میں بتانا نہ بھولیں درج ذیل کمانڈز کے ساتھ:
```bash
git add .
git commit -m "my changes"
```
یقینی بنائیں کہ آپ اپنے کمیٹ کو اچھا نام دیں، اپنے لیے اور اس ریپو کے مینٹینر کے لیے جس پر آپ مدد کر رہے ہیں۔
1. **اپنے کام کو `main` برانچ کے ساتھ ملائیں**۔ کسی وقت آپ کام مکمل کر لیتے ہیں اور آپ اپنے کام کو `main` برانچ کے ساتھ ملانا چاہتے ہیں۔ اس دوران `main` برانچ میں تبدیلیاں ہو سکتی ہیں، لہذا پہلے درج ذیل کمانڈز کے ساتھ اسے تازہ ترین کریں:
```bash
git switch main
git pull
```
اس مرحلے پر آپ یہ یقینی بنانا چاہتے ہیں کہ کوئی بھی _تنازعہ_، ایسی صورتحال جہاں گِٹ آسانی سے تبدیلیوں کو _ملانے_ سے قاصر ہو، آپ کی ورکنگ برانچ میں ہو۔ اس لیے درج ذیل کمانڈز چلائیں:
```bash
git switch [branch_name]
git merge main
```
یہ `main` سے تمام تبدیلیاں آپ کی برانچ میں لائے گا اور امید ہے کہ آپ آسانی سے کام جاری رکھ سکیں گے۔ اگر نہیں، تو VS Code آپ کو بتائے گا کہ گِٹ کہاں _کنفیوز_ ہے اور آپ متاثرہ فائلوں کو تبدیل کر کے درست مواد شامل کریں۔
1. **اپنے کام کو گِٹ ہب پر بھیجیں**۔ اپنے کام کو گِٹ ہب پر بھیجنے کا مطلب دو چیزیں ہیں۔ اپنی برانچ کو اپنے ریپو پر پش کریں اور پھر ایک PR (پُل ریکویسٹ) کھولیں۔
```bash
git push --set-upstream origin [branch-name]
```
اوپر دی گئی کمانڈ آپ کے فورک کیے گئے ریپو پر برانچ بناتی ہے۔
1. **PR کھولیں**۔ اگلے مرحلے میں آپ PR کھولنا چاہتے ہیں۔ ایسا کرنے کے لیے گِٹ ہب پر فورک کیے گئے ریپو پر جائیں۔ آپ کو گِٹ ہب پر ایک اشارہ نظر آئے گا جہاں یہ پوچھے گا کہ کیا آپ نیا PR بنانا چاہتے ہیں، آپ اس پر کلک کریں گے اور آپ کو ایک انٹرفیس پر لے جایا جائے گا جہاں آپ کمیٹ میسج کا عنوان تبدیل کر سکتے ہیں، اسے مزید مناسب تفصیل دے سکتے ہیں۔ اب وہ ریپو مینٹینر جسے آپ نے فورک کیا تھا اس PR کو دیکھے گا اور _امید ہے_ وہ آپ کے PR کو سراہیں گے اور _مرج_ کریں گے۔ آپ اب ایک شراکت دار ہیں، مبارک ہو :)
1. **صفائی کریں**۔ یہ اچھا عمل سمجھا جاتا ہے کہ PR کو کامیابی سے مرج کرنے کے بعد _صفائی_ کریں۔ آپ اپنی لوکل برانچ اور وہ برانچ جسے آپ نے گِٹ ہب پر پش کیا تھا، دونوں کو صاف کرنا چاہتے ہیں۔ پہلے
گٹ ہب کے فورکڈ ریپو کے صفحے پر جائیں اور وہ ریموٹ برانچ ہٹا دیں جسے آپ نے ابھی وہاں پش کیا ہے۔
`پُل ریکویسٹ` ایک عجیب سا لفظ لگتا ہے کیونکہ حقیقت میں آپ اپنی تبدیلیاں پروجیکٹ میں پش کرنا چاہتے ہیں۔ لیکن مینٹینر (پروجیکٹ کا مالک) یا کور ٹیم کو آپ کی تبدیلیوں پر غور کرنا ہوتا ہے اس سے پہلے کہ وہ پروجیکٹ کی "مین" برانچ کے ساتھ مرج کریں، اس لیے آپ حقیقت میں مینٹینر سے تبدیلی کی منظوری کی درخواست کر رہے ہیں۔
پُل ریکویسٹ وہ جگہ ہے جہاں آپ برانچ پر کی گئی تبدیلیوں کا موازنہ اور ان پر تبادلہ خیال کر سکتے ہیں، ریویوز، کمنٹس، انٹیگریٹڈ ٹیسٹس، اور مزید کے ساتھ۔ ایک اچھا پُل ریکویسٹ تقریباً وہی اصول اپناتا ہے جو ایک کمیٹ میسج کے لیے ہوتے ہیں۔ آپ مسئلے کے ٹریکر میں کسی مسئلے کا حوالہ دے سکتے ہیں، جب آپ کا کام کسی مسئلے کو حل کرتا ہے۔ یہ `#` کے ساتھ کیا جاتا ہے، اس کے بعد آپ کے مسئلے کا نمبر۔ مثال کے طور پر `#97`۔
🤞امید ہے کہ تمام چیکس پاس ہو جائیں اور پروجیکٹ کے مالک آپ کی تبدیلیوں کو پروجیکٹ میں مرج کر دیں🤞
اپنے موجودہ لوکل ورکنگ برانچ کو گٹ ہب پر موجود متعلقہ ریموٹ برانچ سے تمام نئے کمیٹس کے ساتھ اپ ڈیٹ کریں:
`git pull`
## اوپن سورس میں تعاون کیسے کریں
سب سے پہلے، گٹ ہب پر ایک ریپوزیٹری (یا **ریپو**) تلاش کریں جو آپ کے لیے دلچسپ ہو اور جس میں آپ تبدیلی کرنا چاہتے ہوں۔ آپ اس کے مواد کو اپنی مشین پر کاپی کرنا چاہیں گے۔
✅ 'بگنر فرینڈلی' ریپوز تلاش کرنے کا ایک اچھا طریقہ [ٹیگ 'good-first-issue' کے ذریعے تلاش کرنا](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/) ہے۔
![ریپو کو لوکل کاپی کریں](../../../../translated_images/clone_repo.5085c48d666ead57664f050d806e325d7f883be6838c821e08bc823ab7c66665.ur.png)
کوڈ کاپی کرنے کے کئی طریقے ہیں۔ ایک طریقہ یہ ہے کہ ریپوزیٹری کے مواد کو "کلون" کریں، HTTPS، SSH، یا گٹ ہب CLI (کمانڈ لائن انٹرفیس) کا استعمال کرتے ہوئے۔
اپنا ٹرمینل کھولیں اور ریپوزیٹری کو اس طرح کلون کریں:
`git clone https://github.com/ProjectURL`
پروجیکٹ پر کام کرنے کے لیے، صحیح فولڈر پر جائیں:
`cd ProjectURL`
آپ پورے پروجیکٹ کو [Codespaces](https://github.com/features/codespaces)، گٹ ہب کے ایمبیڈڈ کوڈ ایڈیٹر / کلاؤڈ ڈیولپمنٹ ماحول، یا [GitHub Desktop](https://desktop.github.com/) کا استعمال کرتے ہوئے بھی کھول سکتے ہیں۔
آخر میں، آپ کوڈ کو زپ فولڈر میں ڈاؤنلوڈ کر سکتے ہیں۔
### گٹ ہب کے بارے میں کچھ مزید دلچسپ باتیں
آپ گٹ ہب پر کسی بھی پبلک ریپوزیٹری کو اسٹار، واچ اور/یا "فورک" کر سکتے ہیں۔ آپ اپنے اسٹار کردہ ریپوزیٹریز کو ٹاپ رائٹ ڈراپ ڈاؤن مینو میں دیکھ سکتے ہیں۔ یہ کوڈ کے لیے بک مارکنگ جیسا ہے۔
پروجیکٹس میں ایک مسئلہ ٹریکر ہوتا ہے، زیادہ تر گٹ ہب پر "Issues" ٹیب میں جب تک کہ دوسری جگہ کا ذکر نہ ہو، جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ اور پُل ریکویسٹ ٹیب وہ جگہ ہے جہاں لوگ جاری تبدیلیوں پر بات کرتے ہیں اور ان کا جائزہ لیتے ہیں۔
پروجیکٹس میں فورمز، میلنگ لسٹس، یا چیٹ چینلز جیسے کہ Slack، Discord یا IRC میں بھی گفتگو ہو سکتی ہے۔
✅ اپنے نئے گٹ ہب ریپو کے ارد گرد دیکھیں اور کچھ چیزیں آزمائیں، جیسے سیٹنگز میں ترمیم کرنا، اپنے ریپو میں معلومات شامل کرنا، اور ایک پروجیکٹ بنانا (جیسے کہ کانبان بورڈ)۔ آپ بہت کچھ کر سکتے ہیں!
---
## 🚀 چیلنج
کسی دوست کے ساتھ جوڑی بنائیں اور ایک دوسرے کے کوڈ پر کام کریں۔ ایک پروجیکٹ مل کر بنائیں، کوڈ فورک کریں، برانچز بنائیں، اور تبدیلیوں کو مرج کریں۔
## لیکچر کے بعد کا کوئز
[لیکچر کے بعد کا کوئز](https://ff-quizzes.netlify.app/web/quiz/4)
## جائزہ اور خود مطالعہ
اوپن سورس سافٹ ویئر میں تعاون کے بارے میں مزید پڑھیں: [contributing to open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution).
[گٹ چیٹ شیٹ](https://training.github.com/downloads/github-git-cheat-sheet/).
پریکٹس، پریکٹس، پریکٹس۔ گٹ ہب کے پاس [skills.github.com](https://skills.github.com) کے ذریعے بہترین لرننگ پاتھز دستیاب ہیں:
- [گٹ ہب پر پہلا ہفتہ](https://skills.github.com/#first-week-on-github)
آپ کو مزید ایڈوانس کورسز بھی ملیں گے۔
## اسائنمنٹ
[گٹ ہب پر پہلا ہفتہ کورس](https://skills.github.com/#first-week-on-github) مکمل کریں۔
**ڈسکلیمر**:
یہ دستاویز AI ترجمہ سروس [Co-op Translator](https://github.com/Azure/co-op-translator) کا استعمال کرتے ہوئے ترجمہ کی گئی ہے۔ ہم درستگی کے لیے کوشش کرتے ہیں، لیکن براہ کرم آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا غیر درستیاں ہو سکتی ہیں۔ اصل دستاویز کو اس کی اصل زبان میں مستند ذریعہ سمجھا جانا چاہیے۔ اہم معلومات کے لیے، پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ ہم اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کے ذمہ دار نہیں ہیں۔