گٹ ہب ریپوزٹری کیا ہے اور پہلی ریپوزٹری کیسے بنائیں

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

اگر آپ پہلی مرتبہ گٹ ہب استعمال کررہے ہیں تو آپ کو بار بار یہ جملے سننے کو ملیں گے:

ریپوزٹری بنائیں۔

کوڈ ریپوزٹری میں پش کریں۔

ریپوزٹری کلون کریں۔

گٹ ہب ریپو کا لنک بھیجیں۔

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

سادہ الفاظ میں:

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

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

ریپوزٹری کو ایک عام فولڈر سے سمجھیں

فرض کریں آپ اپنے کمپیوٹر پر ایک سکول مینجمنٹ سسٹم بنا رہے ہیں۔

آپ نے ایک فولڈر بنایا:

school-management-system

اس کے اندر مختلف فائلیں ہیں:

school-management-system/
│
├── index.php
├── login.php
├── students.php
├── attendance.php
├── fees.php
├── database.php
├── css/
├── js/
└── images/

عام حالت میں یہ صرف ایک فولڈر ہے۔

لیکن جب اس پراجیکٹ کو گٹ کے ذریعے مینیج کیا جاتا ہے تو یہ ایک گٹ ریپوزٹری بن سکتا ہے۔

اور جب یہی پراجیکٹ گٹ ہب پر رکھا جائے تو وہاں اس کی گٹ ہب ریپوزٹری موجود ہوتی ہے۔

ریپوزٹری صرف فائلوں کا فولڈر نہیں

یہاں ایک بنیادی فرق سمجھنا ضروری ہے۔

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

لیکن ریپوزٹری میں صرف موجودہ فائلیں نہیں بلکہ ان کی تبدیلیوں کی ہسٹری بھی اہم ہوتی ہے۔

مثلاً:

Version 1
Login completed

↓

Version 2
Student module added

↓

Version 3
Attendance added

↓

Version 4
Fee module added

یہ مختلف مراحل کمیٹس کے ذریعے محفوظ کیے جاسکتے ہیں۔

اس لیے ریپوزٹری کو یوں سمجھنا زیادہ درست ہوگا:

ریپوزٹری = پراجیکٹ + فائلیں + کوڈ + چینج ہسٹری

 

لوکل ریپوزٹری اور ریموٹ ریپوزٹری

ریپوزٹری کی دو اہم صورتیں سمجھنا ضروری ہیں۔

لوکل ریپوزٹری

وہ ریپوزٹری جو آپ کے اپنے کمپیوٹر یا ڈیویلپمنٹ مشین پر موجود ہو۔

مثلاً:

My Computer
│
└── school-management-system

آپ یہاں کوڈ لکھتے ہیں، فائلیں تبدیل کرتے ہیں اور کمیٹس بناتے ہیں۔

 

ریموٹ ریپوزٹری

وہ ریپوزٹری جو گٹ ہب جیسے آن لائن پلیٹ فارم پر موجود ہو۔

مثلاً:

Local Repository
      ↓
    GitHub
      ↓
Remote Repository

گٹ ہب پر موجود ریپوزٹری کو عام طور پر ریموٹ ریپوزٹری کہا جاتا ہے۔

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

 

گٹ ہب پر ریپوزٹری بنانے کی ضرورت کیوں پڑتی ہے؟

فرض کریں آپ ایک ویب ایپ بنا رہے ہیں۔

اسے صرف اپنے کمپیوٹر میں رکھنے کے بجائے گٹ ہب ریپوزٹری میں رکھنے سے کئی فائدے ہوتے ہیں۔

آپ:

• پراجیکٹ کی چینج ہسٹری رکھ سکتے ہیں۔
• دوسرے ڈیویلپرز کے ساتھ کام کرسکتے ہیں۔
• اے آئی کوڈنگ ایجنٹس کے ساتھ منظم ورک فلو بنا سکتے ہیں۔
• مختلف برانچز میں کام کرسکتے ہیں۔
• کوڈ ریویو کرسکتے ہیں۔
• پرانی کمیٹس دیکھ سکتے ہیں۔
• دوسرے کمپیوٹر پر ریپوزٹری کلون کرسکتے ہیں۔
• پراجیکٹ کو ٹیم کے ساتھ شیئر کرسکتے ہیں۔

پہلی گٹ ہب ریپوزٹری کیسے بنائیں؟

اب عملی طریقہ دیکھتے ہیں۔

سب سے پہلے اپنے گٹ ہب اکاؤنٹ میں لاگ اِن کریں۔

گٹ ہب کے موجودہ ویب انٹرفیس میں اوپر دائیں جانب + مینیو سے New repository منتخب کیا جاسکتا ہے۔

اس کے بعد نئی ریپوزٹری بنانے کا فارم کھل جائے گا۔

ریپوزٹری نیم کیا رکھیں؟

سب سے پہلے آپ سے ریپوزٹری کا نام پوچھا جائے گا۔

مثلاً اگر آپ سکول مینجمنٹ سسٹم بنا رہے ہیں تو نام ہوسکتا ہے:

school-management-system

یا:

school-management

یا:

school-erp

کوشش کریں کہ نام مختصر، واضح اور پراجیکٹ سے متعلق ہو۔

غیر ضروری ناموں سے بچیں، مثلاً:

my-new-project-final-2

اس کے بجائے بہتر نام ہوگا:

school-management-system

ڈسکرپشن کیا ہوتی ہے؟

ریپوزٹری بناتے وقت آپ مختصر ڈسکرپشن بھی لکھ سکتے ہیں۔

مثلاً:

A complete school management system for students, teachers, attendance and fees.

ڈسکرپشن لازمی نہیں، لیکن اچھی ریپوزٹری میں اسے شامل کرنا مفید ہوتا ہے۔

یہ دیکھنے والے کو فوری طور پر بتاتی ہے کہ پراجیکٹ کا مقصد کیا ہے۔

 

پبلک اور پرائیویٹ ریپوزٹری

نئی ریپوزٹری بناتے وقت ایک اہم فیصلہ یہ ہوتا ہے کہ اسے:

پبلک

رکھنا ہے یا:

پرائیویٹ

پبلک ریپوزٹری کیا ہوتی ہے

پبلک ریپوزٹری دوسرے لوگوں کو نظر آسکتی ہے۔

یہ ان پراجیکٹس کے لیے مناسب ہوسکتی ہے جو:

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

مثلاً آپ نے سٹوڈنٹس کو HTML سکھانے کے لیے ایک سادہ پراجیکٹ بنایا ہے۔

اسے پبلک رکھا جاسکتا ہے۔

 

پرائیویٹ ریپوزٹری کیا ہوتی ہے؟

پرائیویٹ ریپوزٹری عام لوگوں کو نظر نہیں آتی۔

صرف وہ لوگ اسے دیکھ سکتے ہیں جنہیں مناسب ایکسس دیا گیا ہو۔

یہ زیادہ مناسب ہے:

• کلائنٹ پراجیکٹس کے لیے۔
• کمرشل سافٹ ویئر کے لیے۔
• کاروباری سسٹمز کے لیے۔
• زیرِ تعمیر پراجیکٹس کے لیے۔
• ایسے کوڈ کے لیے جسے ابھی عوام کے ساتھ شیئر نہ کرنا ہو۔

مثلاً آپ کسی کمپنی کا اکاؤنٹنگ سسٹم بنا رہے ہیں۔

اسے عام طور پر پرائیویٹ ریپوزٹری میں رکھنا زیادہ مناسب ہوگا۔

پبلک اور پرائیویٹ کا ایک اہم اصول

پرائیویٹ ریپوزٹری کا مطلب یہ نہیں کہ آپ حساس معلومات کو بے احتیاطی سے وہاں رکھ سکتے ہیں۔

مثلاً یہ چیزیں براہ راست ریپوزٹری میں کمیٹ نہیں کرنی چاہییں:

API_KEY
DATABASE_PASSWORD
SECRET_TOKEN
PRIVATE_KEY

گٹ ہب بھی اپنی ڈاکیومنٹیشن میں پاس ورڈز، اے پی آئی کیز اور دوسرے سیکرٹس کو ریپوزٹری میں پش نہ کرنے کی تنبیہ کرتا ہے۔

 

README کیا ہے؟

ریپوزٹری بناتے وقت آپ کو Add README کا آپشن بھی دکھائی دے سکتا ہے۔

README عموماً اس فائل کا نام ہوتا ہے:

README.md

یہ پراجیکٹ کا تعارف ہوتی ہے۔

مثلاً README میں لکھا جاسکتا ہے:

# School Management System

A web-based school management system.

## Features

- Student Management
- Teacher Management
- Attendance
- Fee Management
- Reports

گٹ ہب README کو پراجیکٹ کے بارے میں معلومات دینے، اسے سمجھنے، سیٹ اپ کرنے اور چلانے کی وضاحت کے لیے استعمال کرنے کی سفارش کرتا ہے۔

 

README کیوں اہم ہے؟

فرض کریں چھ ماہ بعد آپ اپنی ہی ریپوزٹری کھولتے ہیں۔

اگر README موجود ہو تو چند سیکنڈ میں یاد آسکتا ہے:

• یہ پراجیکٹ کیا تھا؟
• اسے کیسے چلانا ہے؟
• کون سی ٹیکنالوجیز استعمال کی گئی تھیں؟
• کون سے فیچرز مکمل ہیں؟
• کون سے باقی ہیں؟

اور اگر ٹیم کا نیا ممبر ریپوزٹری کھولے تو اسے بھی آغاز سے پورا کوڈ پڑھنے کی ضرورت نہیں پڑتی۔

 

.gitignore کیا ہے؟

ریپوزٹری بناتے وقت گٹ ہب آپ کو .gitignore شامل کرنے کا آپشن بھی دے سکتا ہے۔

فائل کا اصل نام یہ ہوتا ہے:

.gitignore

یہ گٹ کو بتاتی ہے کہ کن فائلوں یا فولڈرز کو ریپوزٹری میں شامل نہیں کرنا۔

مثلاً:

node_modules/
.env
cache/
temp/

فرض کریں .env فائل میں حساس معلومات ہیں۔

آپ اسے .gitignore میں شامل کرسکتے ہیں:

.env

اس سے گٹ عام حالات میں اسے کمیٹ کے لیے ٹریک نہیں کرے گا۔

لائسنس کیا ہے؟

پبلک یا اوپن سورس پراجیکٹ میں آپ لائسنس بھی شامل کرسکتے ہیں۔

لائسنس یہ واضح کرتا ہے کہ دوسرے لوگ آپ کے کوڈ کو:

• استعمال کرسکتے ہیں یا نہیں۔
• تبدیل کرسکتے ہیں یا نہیں۔
• دوبارہ تقسیم کرسکتے ہیں یا نہیں۔
• کن شرائط کے تحت استعمال کرسکتے ہیں۔

اگر آپ صرف اپنی پرائیویٹ بزنس ایپ بنا رہے ہیں تو شروع میں لائسنس شامل کرنا ضروری نہیں۔

 

نئی ریپوزٹری بناتے وقت README کب شامل کریں؟

یہاں دو مختلف حالات ہوسکتے ہیں۔

حالت 1: نیا پراجیکٹ گٹ ہب سے شروع کررہے ہیں

اگر ابھی پراجیکٹ بنا ہی نہیں تو:

Add README

منتخب کرنا مناسب ہے۔

گٹ ہب آپ کے لیے ابتدائی:

README.md

بنا دے گا۔

 

حالت 2: پہلے سے موجود لوکل پراجیکٹ گٹ ہب پر لے کر جارہے ہیں

اگر آپ کے کمپیوٹر میں پہلے سے مکمل گٹ ریپوزٹری موجود ہے اور آپ اسے نئی گٹ ہب ریپوزٹری سے جوڑنا چاہتے ہیں تو خالی ریموٹ ریپوزٹری بنانا اکثر زیادہ آسان ہوتا ہے۔

گٹ ہب کی موجودہ گائیڈ بھی پہلے سے موجود ریپوزٹری امپورٹ کرتے وقت README، .gitignore یا لائسنس پہلے سے شامل نہ کرنے کی ہدایت دیتی ہے، کیونکہ اس سے غیر ضروری مرج کنفلکٹ پیدا ہوسکتا ہے۔

 

Create repository

تمام معلومات درج کرنے کے بعد:

Create repository

پر کلک کریں۔

اب آپ کی پہلی گٹ ہب ریپوزٹری بن چکی ہے۔

مثلاً:

github.com/username/school-management-system

خالی ریپوزٹری کیسی ہوگی؟

اگر آپ نے README شامل نہیں کیا تو نئی ریپوزٹری تقریباً خالی ہوگی۔

گٹ ہب آپ کو کچھ Commands دکھا سکتا ہے جن کے ذریعے موجودہ لوکل پراجیکٹ کو ریپوزٹری سے جوڑا جاسکتا ہے۔

مثلاً:

git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git
git branch -M main
git push -u origin main

یہاں Commands اپنی اصل شکل میں ہیں کیونکہ یہ ٹرمینل میں اسی شکل میں استعمال ہوتی ہیں۔

پہلے سے موجود لوکل پراجیکٹ کو گٹ ہب سے کیسے جوڑیں؟

فرض کریں آپ کے کمپیوٹر میں یہ فولڈر پہلے سے موجود ہے:

school-management-system

آپ ٹرمینل میں اسی فولڈر پر جائیں۔

اگر ابھی گٹ شروع نہیں کیا تو:

git init

پھر فائلیں سٹیج کریں:

git add .

پہلی کمیٹ بنائیں:

git commit -m "Initial commit"

اب گٹ ہب ریپوزٹری کو ریموٹ کے طور پر شامل کریں:

git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git

مین برانچ سیٹ کریں:

git branch -M main

اور پراجیکٹ پش کریں:

git push -u origin main

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

git init کیا کرتا ہے؟

Command:

git init

آپ کے موجودہ پراجیکٹ میں گٹ ریپوزٹری شروع کرتی ہے۔

یعنی عام فولڈر اب گٹ کے ذریعے مینیج ہوسکتا ہے۔

git add . کیا کرتا ہے؟

Command:

git add .

موجودہ تبدیلیوں کو اگلی کمیٹ کے لیے سٹیج کرتی ہے۔

سادہ تصور:

Files changed
     ↓
git add .
     ↓
Ready for commit

git commit کیا کرتا ہے؟

مثلاً:

git commit -m "Initial commit"

یہ موجودہ سٹیجڈ تبدیلیوں کی کمیٹ بناتا ہے۔

Initial commit کمیٹ میسج ہے۔

یہ آپ اپنی ضرورت کے مطابق لکھ سکتے ہیں۔

مثلاً:

git commit -m "Login module completed"

یا:

git commit -m "Student registration added"

git remote add originکیا کرتا ہے؟

مثلاً:

git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git

یہ آپ کی لوکل ریپوزٹری کو گٹ ہب کی ریموٹ ریپوزٹری سے جوڑتا ہے۔

سادہ انداز میں:

Local Repository
       ↕
Remote Repository

یہاں origin ریموٹ کے لیے استعمال ہونے والا عام نام ہے۔

git push کیا کرتا ہے؟

Command:

git push -u origin main

آپ کی لوکل کمیٹس کو گٹ ہب کی ریموٹ ریپوزٹری میں بھیجتی ہے۔

یعنی:

Local Repository
       ↓
      Push
       ↓
GitHub Repository

گٹ ہب ویب سائٹ سے فائل اپ لوڈ کرنا

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

ریپوزٹری کھولیں۔

پھر:

Add file

اور اس کے بعد:

Upload files

منتخب کریں۔

فائلیں براؤزر میں ڈریگ اینڈ ڈراپ بھی کی جاسکتی ہیں۔

گٹ ہب کے موجودہ ویب انٹرفیس میں براؤزر کے ذریعے ایک فائل کی حد 25 MiB ہے، جبکہ ایک وقت میں 100 فائلیں اپ لوڈ کی جاسکتی ہیں۔ بڑی فائلوں کے لیے Command Line یا Git LFS کی ضرورت پڑ سکتی ہے۔

ویب سائٹ سے نئی فائل بنانا

گٹ ہب کے اندر براہ راست نئی فائل بھی بنائی جاسکتی ہے۔

مثلاً:

index.html

یا:

README.md

یا:

notes.md

گٹ ہب ریپوزٹری میں Write Access رکھنے والا صارف ویب انٹرفیس سے نئی فائل بنا اور موجودہ فائل Edit بھی کرسکتا ہے۔

فائل اپ لوڈ کرنے کے بعد کمیٹ کیوں بنتی ہے؟

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

اس لیے آپ سے Commit message مانگا جاتا ہے۔

مثلاً:

Add login page

یا:

Update student module

یا:

Fix attendance calculation

اچھا کمیٹ میسج یہ بتاتا ہے کہ اس کمیٹ میں کیا تبدیلی ہوئی۔

خراب کمیٹ میسجز کی مثالیں

یہ میسجز بہت مفید نہیں:

update

changes

fix

new

کیونکہ چند ماہ بعد ان سے معلوم نہیں ہوگا کہ اصل تبدیلی کیا تھی۔

بہتر کمیٹ میسجز

مثلاً:

Add student registration form

Fix login validation

Add monthly attendance report

Update fee receipt layout

یہ فوراً بتاتے ہیں کہ تبدیلی کس چیز سے متعلق تھی۔

برانچ کا تعلق ریپوزٹری سے کیا ہے؟

ایک ریپوزٹری کے اندر ایک سے زیادہ برانچز ہوسکتی ہیں۔

مثلاً:

main

اصل مستحکم ورژن۔

اور:

new-dashboard

نئے ڈیش بورڈ پر کام۔

یا:

payment-module

پیمنٹ ماڈیول پر کام۔

گٹ ہب کے مطابق برانچ ریپوزٹری کے اندر کوڈ کا ایک متوازی ورژن ہوسکتی ہے جو مین برانچ کو فوری طور پر متاثر کیے بغیر تبدیلیوں پر کام کرنے دیتی ہے۔

ریپوزٹری کو اے آئی کوڈنگ کے ساتھ کیسے استعمال کریں؟

یہ موجودہ دور میں بہت اہم استعمال ہے۔

فرض کریں آپ Antigravity، Codex، Claude Code یا کسی دوسرے کوڈنگ ایجنٹ سے سافٹ ویئر بنوا رہے ہیں۔

غلط طریقہ:

AI Agent
↓
ہر چیز مسلسل تبدیل کرتا رہے
↓
کوئی واضح commit نہ ہو
↓
کچھ خراب ہوجائے
↓
معلوم نہ ہو مسئلہ کہاں پیدا ہوا

بہتر طریقہ:

Feature 1 complete
↓
Test
↓
Commit

↓

Feature 2 complete
↓
Test
↓
Commit

↓

Feature 3 complete
↓
Test
↓
Commit

مثلاً:

Initial project structure

پھر:

Login system working

پھر:

Student module working

پھر:

Attendance module working

اب ہر اہم مرحلہ الگ محفوظ ہے۔

اے آئی ایجنٹ کے لیے برانچ کیوں مفید ہے؟

فرض کریں آپ کا مین پراجیکٹ صحیح چل رہا ہے۔

اب اے آئی ایجنٹ سے نیا ڈیش بورڈ بنوانا ہے۔

براہ راست main میں تجربہ کرنے کے بجائے نئی برانچ بنائی جاسکتی ہے:

dashboard-redesign

اب ایجنٹ اس برانچ پر کام کرے۔

اگر نتیجہ اچھا ہو:

Merge

اگر خراب ہو:

برانچ ختم کی جاسکتی ہے اور main محفوظ رہتی ہے۔

ایک اچھے پراجیکٹ کی ریپوزٹری کی ساخت

مثلاً ایک ویب پراجیکٹ:

school-management-system/
│
├── README.md
├── .gitignore
├── index.php
│
├── config/
│   └── database.php
│
├── students/
│   ├── add.php
│   ├── edit.php
│   └── list.php
│
├── attendance/
│   ├── mark.php
│   └── report.php
│
├── assets/
│   ├── css/
│   ├── js/
│   └── images/
│
└── docs/

یہ صرف مثال ہے۔

اصل ساخت پراجیکٹ اور استعمال ہونے والی ٹیکنالوجی کے مطابق مختلف ہوسکتی ہے۔

README میں کیا لکھنا چاہیے؟

ایک بنیادی README میں یہ چیزیں شامل کی جاسکتی ہیں:

# School Management System

## About

A web-based school management system.

## Features

- Student Management
- Teacher Management
- Attendance
- Fee Management
- Reports

## Installation

Installation instructions here.

## Technologies

- PHP
- MySQL
- JavaScript

بڑے پراجیکٹ میں README میں مزید چیزیں بھی شامل کی جاسکتی ہیں:

• پراجیکٹ اسٹیٹس
• انسٹالیشن
• کنفگریشن
• ڈیٹابیس سیٹ اپ
• استعمال کا طریقہ
• اسکرین شاٹس
• کانٹریبیوشن رولز
• لائسنس

ایک ریپوزٹری میں کیا نہیں رکھنا چاہیے؟

خاص طور پر یہ چیزیں احتیاط سے مینیج کریں:

.env

passwords.txt

database-backup-with-real-data.sql

private-key.pem

api-keys.txt

اصل صارفین کا حساس ڈیٹا بھی بلاوجہ ریپوزٹری میں نہیں ہونا چاہیے۔

بڑی فائلیں ریپوزٹری میں رکھنا ہمیشہ مناسب نہیں

گٹ ہب بنیادی طور پر سورس کوڈ اور ڈیویلپمنٹ فائلز کے لیے بنایا گیا ہے۔

بہت بڑی:

• ویڈیوز
• بیک اپس
• ڈیٹابیس ڈمپس
• خام میڈیا فائلز

کو عام گٹ ریپوزٹری میں رکھنا ہمیشہ اچھا طریقہ نہیں۔

ضرورت کے مطابق Git LFS یا کسی علیحدہ سٹوریج سروس کا استعمال بہتر ہوسکتا ہے۔

ایک عام Beginner Workflow

بالکل نئے سیکھنے والے کے لیے یہ ورک فلو کافی ہے:

GitHub account

↓

New repository

↓

Repository name

↓

Public / Private

↓

README

↓

Create repository

↓

Add files

↓

Commit changes

↓

Continue development

بعد میں آپ اس میں شامل کرسکتے ہیں:

Clone

↓

Branch

↓

Push

↓

Pull

↓

Pull Request

↓

Merge

اگر پراجیکٹ پہلے سے کمپیوٹر میں موجود ہو

تو ورک فلو کچھ اس طرح ہوگا:

Existing Project
      ↓
git init
      ↓
git add .
      ↓
git commit
      ↓
Create empty GitHub repository
      ↓
git remote add origin
      ↓
git push

اگر پراجیکٹ پہلے سے گٹ ہب پر موجود ہو

اور آپ اسے نئے کمپیوٹر میں لانا چاہتے ہوں تو عموماً:

git clone REPOSITORY-URL

استعمال کیا جاتا ہے۔

مثلاً:

git clone https://github.com/USERNAME/PROJECT.git

اس سے ریپوزٹری کی لوکل کاپی بن جاتی ہے۔

ریپوزٹری بناتے وقت سب سے عام غلطیاں

نئے سیکھنے والوں کی چند عام غلطیاں یہ ہیں:

• ہر معمولی چیز کے لیے نئی ریپوزٹری بنا دینا۔
• ایک ہی پراجیکٹ کی کئی الگ ریپوزٹریاں بنانا۔
• نام واضح نہ رکھنا۔
• README نہ بنانا۔
• کمیٹ میسجز واضح نہ لکھنا۔
• حساس معلومات کمیٹ کردینا۔
• .gitignore استعمال نہ کرنا۔
• اے آئی ایجنٹ کو بغیر کمیٹس کے مسلسل کوڈ تبدیل کرنے دینا۔
• صحیح چلتے مین ورژن پر براہ راست بڑے تجربات کرنا۔

ایک پراجیکٹ، ایک مرکزی ریپوزٹری

عام طور پر ایک پراجیکٹ کے لیے ایک مرکزی ریپوزٹری زیادہ منظم رہتی ہے۔

مثلاً:

school-management-system

اسی ریپوزٹری کے اندر:

main

student-module

fee-module

new-dashboard

جیسی برانچز بنائی جاسکتی ہیں۔

ہر نئے فیچر کے لیے نئی ریپوزٹری بنانا ضروری نہیں۔

گٹ ہب ریپوزٹری کو ایک عمارت کی مثال سے سمجھیں

فرض کریں آپ ایک عمارت تعمیر کررہے ہیں۔

ریپوزٹری پوری عمارت کا پراجیکٹ ہے۔

فائلز نقشے اور ڈاکیومنٹس ہیں۔

کمیٹس تعمیر کے محفوظ مراحل ہیں۔

برانچ کسی نئے ڈیزائن پر الگ تجربہ ہے۔

پش نیا کام مرکزی آن لائن ریکارڈ میں بھیجنا ہے۔

پل مرکزی ریکارڈ سے نئی تبدیلی حاصل کرنا ہے۔

مرج منظور شدہ تبدیلی کو اصل پراجیکٹ میں شامل کرنا ہے۔

اس مثال سے ریپوزٹری صرف فولڈر نہیں رہتی بلکہ پورے پراجیکٹ کی ڈیویلپمنٹ ہسٹری سمجھ میں آتی ہے۔

خلاصہ

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

ریپوزٹری:

• لوکل ہوسکتی ہے۔
• ریموٹ ہوسکتی ہے۔
• پبلک ہوسکتی ہے۔
• پرائیویٹ ہوسکتی ہے۔

نئی گٹ ہب ریپوزٹری بناتے وقت آپ:

ریپوزٹری نیم منتخب کرتے ہیں،
ڈسکرپشن لکھ سکتے ہیں،
پبلک یا پرائیویٹ منتخب کرتے ہیں،
README شامل کرسکتے ہیں،
.gitignore شامل کرسکتے ہیں،
اور پھر ریپوزٹری کریئیٹ کرتے ہیں۔

اگر پراجیکٹ پہلے سے آپ کے کمپیوٹر میں موجود ہے تو اسے گٹ کے ذریعے گٹ ہب ریپوزٹری سے جوڑ کر پش کیا جاسکتا ہے۔

سب سے اہم تصور یہ ہے:

ریپوزٹری صرف کوڈ رکھنے کی جگہ نہیں بلکہ پورے پراجیکٹ کی منظم ڈیویلپمنٹ ہسٹری ہے۔

اگلا مضمون

کمیٹ کیا ہے اور گٹ ہب میں ورژن ہسٹری کیسے کام کرتی ہے؟

اس میں ہم تفصیل سے سمجھیں گے:

• کمیٹ اصل میں کیا محفوظ کرتی ہے؟
• کمیٹ اور عام Save میں کیا فرق ہے؟
• اچھا کمیٹ میسج کیسے لکھا جاتا ہے؟
• git add اور git commit میں کیا فرق ہے؟
• کمیٹ ہسٹری کیسے دیکھی جاتی ہے؟
• غلط تبدیلی کا پتا کیسے چلایا جاتا ہے؟
• اے آئی کوڈنگ ایجنٹ کے ساتھ کمیٹس کو چیک پوائنٹس کے طور پر کیسے استعمال کیا جائے؟
• ہر چھوٹی تبدیلی پر کمیٹ کرنا چاہیے یا فیچر مکمل ہونے پر؟