|
|
<!--
|
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
|
{
|
|
|
"original_hash": "361249da70432ddfd4741c917d1a6f50",
|
|
|
"translation_date": "2025-08-28T15:34:55+00:00",
|
|
|
"source_file": "1-getting-started-lessons/2-github-basics/README.md",
|
|
|
"language_code": "ur"
|
|
|
}
|
|
|
-->
|
|
|
# گِٹ ہب کا تعارف
|
|
|
|
|
|
یہ سبق گِٹ ہب کے بنیادی اصولوں کا احاطہ کرتا ہے، جو کہ آپ کے کوڈ کی میزبانی اور اس میں تبدیلیوں کو منظم کرنے کا ایک پلیٹ فارم ہے۔
|
|
|
|
|
|

|
|
|
> اسکیچ نوٹ: [Tomomi Imura](https://twitter.com/girlie_mac)
|
|
|
|
|
|
## لیکچر سے پہلے کا کوئز
|
|
|
[لیکچر سے پہلے کا کوئز](https://ff-quizzes.netlify.app)
|
|
|
|
|
|
## تعارف
|
|
|
|
|
|
اس سبق میں ہم درج ذیل موضوعات کا احاطہ کریں گے:
|
|
|
|
|
|
- آپ کے کمپیوٹر پر کیے گئے کام کو ٹریک کرنا
|
|
|
- دوسروں کے ساتھ پروجیکٹس پر کام کرنا
|
|
|
- اوپن سورس سافٹ ویئر میں تعاون کرنے کا طریقہ
|
|
|
|
|
|
### ضروریات
|
|
|
|
|
|
شروع کرنے سے پہلے، آپ کو یہ چیک کرنا ہوگا کہ آیا گِٹ انسٹال ہے یا نہیں۔ ٹرمینل میں یہ ٹائپ کریں:
|
|
|
`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)، اور اپنا ٹرمینل (یا: کمانڈ پرامپٹ) کھولنے کی ضرورت ہوگی۔
|
|
|
|
|
|
[githhub.com](https://github.com/) پر جائیں اور اگر آپ کے پاس پہلے سے اکاؤنٹ نہیں ہے تو ایک اکاؤنٹ بنائیں، یا لاگ ان کریں اور اپنی پروفائل مکمل کریں۔
|
|
|
|
|
|
✅ گِٹ ہب دنیا میں واحد کوڈ ریپوزٹری نہیں ہے؛ دیگر بھی موجود ہیں، لیکن گِٹ ہب سب سے زیادہ مشہور ہے۔
|
|
|
|
|
|
### تیاری
|
|
|
|
|
|
آپ کو اپنے لوکل کمپیوٹر (لیپ ٹاپ یا پی سی) پر کوڈ پروجیکٹ کے ساتھ ایک فولڈر اور گِٹ ہب پر ایک پبلک ریپوزٹری کی ضرورت ہوگی، جو دوسروں کے پروجیکٹس میں تعاون کرنے کی مثال کے طور پر کام کرے گی۔
|
|
|
|
|
|
---
|
|
|
|
|
|
## کوڈ مینجمنٹ
|
|
|
|
|
|
فرض کریں کہ آپ کے پاس لوکل طور پر ایک فولڈر میں کوئی کوڈ پروجیکٹ موجود ہے اور آپ گِٹ کے ذریعے اپنی پیش رفت کو ٹریک کرنا چاہتے ہیں - جو کہ ایک ورژن کنٹرول سسٹم ہے۔ کچھ لوگ گِٹ کے استعمال کو اپنے مستقبل کے لیے محبت نامہ لکھنے سے تشبیہ دیتے ہیں۔ جب آپ دنوں، ہفتوں یا مہینوں بعد اپنے کمیٹ میسجز پڑھیں گے، تو آپ کو یاد آئے گا کہ آپ نے کوئی فیصلہ کیوں کیا تھا، یا آپ کسی تبدیلی کو "واپس" لے سکتے ہیں - بشرطیکہ آپ نے اچھے "کمیٹ میسجز" لکھے ہوں۔
|
|
|
|
|
|
### کام: ریپوزٹری بنائیں اور کوڈ کمیٹ کریں
|
|
|
|
|
|
> ویڈیو دیکھیں
|
|
|
>
|
|
|
> [](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. **اپنے کام کو محفوظ کریں**۔ اس مرحلے پر آپ نے فائلوں کو ایک _اسٹیجنگ ایریا_ میں شامل کر لیا ہے۔ یہ وہ جگہ ہے جہاں گِٹ آپ کی فائلوں کو ٹریک کر رہا ہے۔ تبدیلی کو مستقل بنانے کے لیے آپ کو فائلوں کو _کمیٹ_ کرنا ہوگا۔ ایسا کرنے کے لیے آپ `git commit` کمانڈ استعمال کرتے ہیں۔ ایک _کمیٹ_ آپ کی ریپو کی ہسٹری میں ایک محفوظ پوائنٹ کی نمائندگی کرتا ہے۔ کمیٹ بنانے کے لیے درج ذیل ٹائپ کریں:
|
|
|
|
|
|
```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://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 فائلز، اگرچہ انہیں تیار کرنے میں وقت لگتا ہے، اکثر مصروف مینٹینرز نظر انداز کر دیتے ہیں۔ کیا آپ کسی خاص طور پر وضاحتی مثال تلاش کر سکتے ہیں؟ نوٹ: کچھ [اوزار](https://www.makeareadme.com/) ہیں جو اچھی README بنانے میں مدد کرتے ہیں، آپ انہیں آزما سکتے ہیں۔
|
|
|
|
|
|
### کام: کوڈ کو مرج کریں
|
|
|
|
|
|
تعاون کی دستاویزات لوگوں کو پروجیکٹ میں تعاون کرنے میں مدد دیتی ہیں۔ یہ وضاحت کرتی ہیں کہ آپ کس قسم کے تعاون کی تلاش میں ہیں اور یہ عمل کیسے کام کرتا ہے۔ تعاون کرنے والوں کو آپ کی گِٹ ہب ریپو میں تعاون کرنے کے لیے درج ذیل مراحل سے گزرنا ہوگا:
|
|
|
|
|
|
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. **صفائی کریں**۔ یہ اچھا عمل سمجھا
|
|
|
`پُل ریکویسٹ` ایک عجیب سا لفظ لگتا ہے کیونکہ حقیقت میں آپ اپنی تبدیلیاں پروجیکٹ میں "پش" کرنا چاہتے ہیں۔ لیکن پروجیکٹ کے مالک یا کور ٹیم کو آپ کی تبدیلیوں پر غور کرنا ہوتا ہے اس سے پہلے کہ وہ پروجیکٹ کی "مین" برانچ کے ساتھ ضم کریں، تو آپ دراصل ایک فیصلہ کی درخواست کر رہے ہیں کہ آیا یہ تبدیلی قبول کی جائے یا نہیں۔
|
|
|
|
|
|
پُل ریکویسٹ وہ جگہ ہے جہاں آپ برانچ پر کی گئی تبدیلیوں کا موازنہ اور بحث کر سکتے ہیں، ریویوز، کمنٹس، انٹیگریٹڈ ٹیسٹس، اور مزید کے ساتھ۔ ایک اچھا پُل ریکویسٹ تقریباً وہی اصول اپناتا ہے جو ایک کمیٹ میسج کے لیے ہوتے ہیں۔ آپ مسئلے کے ٹریکر میں کسی مسئلے کا حوالہ دے سکتے ہیں، جب آپ کا کام مثلاً کسی مسئلے کو حل کرتا ہے۔ یہ `#` کے ساتھ مسئلے کے نمبر کا استعمال کرتے ہوئے کیا جاتا ہے۔ مثال کے طور پر `#97`۔
|
|
|
|
|
|
🤞امید ہے کہ تمام چیکس پاس ہو جائیں اور پروجیکٹ کے مالک آپ کی تبدیلیوں کو پروجیکٹ میں ضم کر دیں🤞
|
|
|
|
|
|
اپنی موجودہ لوکل ورکنگ برانچ کو GitHub پر متعلقہ ریموٹ برانچ سے تمام نئے کمیٹس کے ساتھ اپ ڈیٹ کریں:
|
|
|
|
|
|
`git pull`
|
|
|
|
|
|
## اوپن سورس میں تعاون کیسے کریں
|
|
|
|
|
|
سب سے پہلے، GitHub پر ایک ایسا ریپوزیٹری (یا **ریپو**) تلاش کریں جو آپ کے دلچسپی کا ہو اور جس میں آپ تبدیلی کرنا چاہتے ہوں۔ آپ اس کے مواد کو اپنی مشین پر کاپی کرنا چاہیں گے۔
|
|
|
|
|
|
✅ 'ابتدائی دوستانہ' ریپوز تلاش کرنے کا ایک اچھا طریقہ یہ ہے کہ [ٹیگ 'good-first-issue' کے ذریعے تلاش کریں](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)۔
|
|
|
|
|
|

|
|
|
|
|
|
کوڈ کاپی کرنے کے کئی طریقے ہیں۔ ایک طریقہ یہ ہے کہ ریپوزیٹری کے مواد کو "کلون" کریں، HTTPS، SSH، یا GitHub CLI (کمانڈ لائن انٹرفیس) کا استعمال کرتے ہوئے۔
|
|
|
|
|
|
اپنا ٹرمینل کھولیں اور ریپوزیٹری کو اس طرح کلون کریں:
|
|
|
`git clone https://github.com/ProjectURL`
|
|
|
|
|
|
پروجیکٹ پر کام کرنے کے لیے، صحیح فولڈر پر جائیں:
|
|
|
`cd ProjectURL`
|
|
|
|
|
|
آپ پورے پروجیکٹ کو [Codespaces](https://github.com/features/codespaces)، GitHub کے ایمبیڈڈ کوڈ ایڈیٹر / کلاؤڈ ڈیولپمنٹ ماحول، یا [GitHub Desktop](https://desktop.github.com/) کا استعمال کرتے ہوئے بھی کھول سکتے ہیں۔
|
|
|
|
|
|
آخر میں، آپ کوڈ کو زپ فولڈر میں ڈاؤنلوڈ بھی کر سکتے ہیں۔
|
|
|
|
|
|
### GitHub کے بارے میں کچھ مزید دلچسپ باتیں
|
|
|
|
|
|
آپ GitHub پر کسی بھی پبلک ریپوزیٹری کو اسٹار، واچ اور/یا "فورک" کر سکتے ہیں۔ آپ اپنے اسٹار کردہ ریپوزیٹریز کو اوپر دائیں ڈراپ ڈاؤن مینو میں تلاش کر سکتے ہیں۔ یہ کوڈ کے لیے بک مارکنگ جیسا ہے۔
|
|
|
|
|
|
پروجیکٹس میں ایک مسئلہ ٹریکر ہوتا ہے، زیادہ تر GitHub پر "Issues" ٹیب میں جب تک کہ دوسری جگہ نہ بتایا جائے، جہاں لوگ پروجیکٹ سے متعلق مسائل پر بات کرتے ہیں۔ اور Pull Requests ٹیب وہ جگہ ہے جہاں لوگ جاری تبدیلیوں پر بحث اور جائزہ لیتے ہیں۔
|
|
|
|
|
|
پروجیکٹس میں فورمز، میلنگ لسٹس، یا چیٹ چینلز جیسے Slack، Discord یا IRC میں بھی گفتگو ہو سکتی ہے۔
|
|
|
|
|
|
✅ اپنے نئے GitHub ریپو کے ارد گرد دیکھیں اور کچھ چیزیں آزمائیں، جیسے سیٹنگز میں ترمیم کرنا، اپنے ریپو میں معلومات شامل کرنا، اور ایک پروجیکٹ بنانا (جیسے کانبان بورڈ)۔ کرنے کے لیے بہت کچھ ہے!
|
|
|
|
|
|
---
|
|
|
|
|
|
## 🚀 چیلنج
|
|
|
|
|
|
ایک دوست کے ساتھ جوڑی بنائیں اور ایک دوسرے کے کوڈ پر کام کریں۔ ایک پروجیکٹ مل کر بنائیں، کوڈ فورک کریں، برانچز بنائیں، اور تبدیلیوں کو ضم کریں۔
|
|
|
|
|
|
## لیکچر کے بعد کا کوئز
|
|
|
[لیکچر کے بعد کا کوئز](https://ff-quizzes.netlify.app/web/en/)
|
|
|
|
|
|
## جائزہ اور خود مطالعہ
|
|
|
|
|
|
اوپن سورس سافٹ ویئر میں تعاون کے بارے میں مزید پڑھیں: [contributing to open source software](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)۔
|
|
|
|
|
|
[Git cheatsheet](https://training.github.com/downloads/github-git-cheat-sheet/)۔
|
|
|
|
|
|
پریکٹس، پریکٹس، پریکٹس۔ GitHub کے پاس [skills.github.com](https://skills.github.com) کے ذریعے بہترین لرننگ پاتھ دستیاب ہیں:
|
|
|
|
|
|
- [GitHub پر پہلا ہفتہ](https://skills.github.com/#first-week-on-github)
|
|
|
|
|
|
آپ کو مزید ایڈوانس کورسز بھی ملیں گے۔
|
|
|
|
|
|
## اسائنمنٹ
|
|
|
|
|
|
[GitHub پر پہلا ہفتہ کورس](https://skills.github.com/#first-week-on-github) مکمل کریں۔
|
|
|
|
|
|
---
|
|
|
|
|
|
**ڈسکلیمر**:
|
|
|
یہ دستاویز AI ترجمہ سروس [Co-op Translator](https://github.com/Azure/co-op-translator) کا استعمال کرتے ہوئے ترجمہ کی گئی ہے۔ ہم درستگی کے لیے کوشش کرتے ہیں، لیکن براہ کرم آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا غیر درستیاں ہو سکتی ہیں۔ اصل دستاویز کو اس کی اصل زبان میں مستند ذریعہ سمجھا جانا چاہیے۔ اہم معلومات کے لیے، پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ ہم اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کے ذمہ دار نہیں ہیں۔ |