What is a GitHub Issue, Why is it Created, and How is it Used?

What is a GitHub Issue, Why is it Created, and How is it Used?
ایک معلوماتی انفوگرافک جو GitHub پر مسائل (Issues) کے انتظام کے عمل کو تین مراحل میں دکھاتا ہے: رپورٹنگ، انتظام، اور حل۔ یہ ایک ہوم اسکرین سے شروع ہوتا ہے، مسائل کی فہرست اور بورڈ دکھاتا ہے، اور کوڈ ایڈیٹر پر ختم ہوتا ہے، جس میں ہر مرحلے کی وضاحت اردو اور انگریزی میں کی گئی ہے۔

گٹ ہب میں اشو کسے کہتے ہیں؟ کیوں بنایا جاتا ہے اور کیسے استعمال ہوتا ہے؟

گٹ ہب سیکھتے وقت ایک اصطلاح بار بار سامنے آتی ہے:

اشو

نئے سیکھنے والے اکثر نام سن کر سمجھتے ہیں کہ شاید اشو صرف کسی خرابی یا بگ کے لیے بنایا جاتا ہے، لیکن گٹ ہب میں اس کا دائرہ اس سے کہیں زیادہ وسیع ہے۔

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

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

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

    گٹ ہب اشو کو ایک عام مثال سے سمجھیں

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

سسٹم میں یہ مسئلہ سامنے آیا:

ایک ہی سٹوڈنٹ کی فیس رسید دو مرتبہ بن رہی ہے۔

آپ یہ بات صرف زبانی طور پر ڈیویلپر کو بتاسکتے ہیں۔

لیکن چند دن بعد:

  • وہ بھول سکتا ہے۔
  • آپ بھول سکتے ہیں۔
  • معلوم نہیں ہوگا کس نے کام کرنا تھا۔
  • معلوم نہیں ہوگا مسئلہ حل ہوا یا نہیں۔
  • یہ بھی واضح نہیں ہوگا کہ مسئلہ کس ورژن میں آیا تھا۔

اس کے بجائے گٹ ہب میں ایک اشو بنا دیا جائے:

Duplicate fee receipt is generated for the same payment

اب یہ ایک باقاعدہ ریکارڈ بن گیا۔

اشو صرف بگ کے لیے نہیں ہوتا

گٹ ہب اشو کئی قسم کے کام کے لیے استعمال ہوسکتا ہے۔

مثلاً:

بگ

Login button does not work on mobile

نیا فیچر

Add student attendance report

بہتری

Improve dashboard loading speed

ٹاسک

Create database backup system

آئیڈیا

Add parent mobile application

ڈاکیومنٹیشن

Add installation instructions to README

اس لیے اشو کو صرف مسئلہ سمجھنا محدود تصور ہے۔

زیادہ درست بات یہ ہے:

اشو پراجیکٹ میں کسی بھی قابلِ عمل یا قابلِ گفتگو کام کا ریکارڈ ہوسکتا ہے۔

اشو بنانے کی ضرورت کیوں پڑتی ہے؟

جیسے جیسے پراجیکٹ بڑا ہوتا ہے، صرف یادداشت پر کام کرنا مشکل ہوجاتا ہے۔

فرض کریں آپ کے پراجیکٹ میں بیک وقت یہ کام چل رہے ہیں:

Fix login issue
Add customer module
Improve dashboard
Create backup system
Add email notifications
Fix invoice calculation

اگر یہ سب صرف WhatsApp یا زبانی گفتگو میں ہوں تو بہت جلد چیزیں بکھرنا شروع ہوجاتی ہیں۔

اشوز انہیں ایک منظم جگہ فراہم کرتے ہیں۔

اشو کا بنیادی فائدہ

ایک اچھا اشو کم از کم یہ واضح کرتا ہے:

  • مسئلہ یا کام کیا ہے؟
  • یہ کہاں سامنے آیا؟
  • متوقع نتیجہ کیا تھا؟
  • اصل نتیجہ کیا آیا؟
  • کس کو یہ کام کرنا ہے؟
  • ترجیح کیا ہے؟
  • اس کی موجودہ حالت کیا ہے؟
  • اس پر کیا گفتگو ہوئی؟
  • یہ کب مکمل ہوا؟

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

اشو کہاں بنایا جاتا ہے؟

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

سادہ ورک فلو:

Repository
↓
Issues
↓
New issue

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

نیا اشو کیسے بنایا جاتا ہے؟

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

پھر:

Issues

پر جائیں۔

اس کے بعد:

New issue

منتخب کریں۔

اب عام طور پر دو بنیادی چیزیں مانگی جائیں گی:

ٹائٹل

مختصر اور واضح عنوان۔

مثلاً:

Login fails after password reset

ڈسکرپشن

مسئلے یا کام کی مکمل تفصیل۔

مثلاً:

After resetting the password, the user is redirected to the login page.

When the new password is entered, the system shows "Invalid password".

Expected result:
The user should be able to log in using the newly created password.

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

اچھا اشو ٹائٹل کیسے لکھیں؟

اشو کا ٹائٹل ایسا ہونا چاہیے کہ اسے پڑھتے ہی اندازہ ہوجائے کہ مسئلہ کیا ہے۔

خراب مثال:

Problem

یا:

Fix this

یا:

Not working

یہ ٹائٹل کوئی واضح معلومات نہیں دیتے۔

بہتر مثال:

Login button does not respond on mobile

یا:

Duplicate invoice is created after double click

یا:

Add monthly attendance export

اشو ڈسکرپشن میں کیا لکھنا چاہیے؟

ایک مفید اشو ڈسکرپشن میں یہ چیزیں شامل ہوسکتی ہیں:

  • مسئلہ کیا ہے؟
  • کہاں سامنے آیا؟
  • اسے دوبارہ کیسے پیدا کیا جاسکتا ہے؟
  • آپ کیا نتیجہ چاہتے تھے؟
  • اصل نتیجہ کیا آیا؟
  • اسکرین شاٹ یا ایرر موجود ہے؟
  • ماحول کیا ہے؟
  • کوئی متعلقہ اشو یا پل ریکویسٹ موجود ہے؟

بگ اشو کی اچھی مثال

مثلاً:

Title:
Fee receipt total is incorrect when discount is applied

Description:

Steps to reproduce:

1. Open the fee collection page.
2. Select a student.
3. Add a 10% discount.
4. Generate the receipt.

Expected result:

The receipt total should reflect the discounted amount.

Actual result:

The receipt shows the original amount.

Environment:

Chrome
PHP 8.2
MySQL 8

ایسا اشو ڈیویلپر کے لیے بہت زیادہ مفید ہوگا۔

فیچر اشو کی مثال

فرض کریں نیا فیچر چاہیے:

Title:
Add monthly attendance report

ڈسکرپشن:

Add a monthly attendance report for each class.

The report should include:

- Student name
- Total working days
- Present days
- Absent days
- Attendance percentage
- Export to PDF

اب کام واضح ہے۔

اشو نمبر کیا ہے؟

ہر اشو کو گٹ ہب ایک نمبر دیتا ہے۔

مثلاً:

#12

یا:

#48

اس نمبر سے اشو کو مختصر طور پر ریفرنس کیا جاسکتا ہے۔

مثلاً:

Fixes #12

یا:

Related to #48

یہ ٹیم ورک میں بہت مفید ہوتا ہے۔

اوپن اور کلوز اشو

نیا اشو عام طور پر اوپن حالت میں ہوتا ہے۔

یعنی:

اس پر ابھی کام باقی ہے۔

جب مسئلہ حل ہوجائے یا کام مکمل ہوجائے تو اشو کلوز کیا جاسکتا ہے۔

سادہ تصور:

Open
↓
Work in progress
↓
Resolved
↓
Closed

اشو کلوز کرنے کا مطلب کیا ہے؟

اشو کلوز کرنے کا مطلب عام طور پر یہ ہوتا ہے کہ:

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

لیکن اشو کلوز ہونے کے بعد بھی اس کی ہسٹری باقی رہتی ہے۔

اشو میں کمنٹس کیوں ہوتے ہیں؟

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

مثلاً کسی ڈیویلپر نے لکھا:

I reproduced the issue on Chrome but not on Safari.

دوسرا شخص جواب دے سکتا ہے:

The issue appears to be related to the form validation script.

بعد میں یہ پوری گفتگو ریکارڈ میں موجود رہتی ہے۔

یہی چیز بڑے پراجیکٹ میں بہت اہم ہوجاتی ہے۔

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

اشو میں اسائنی وہ شخص ہوتا ہے جسے کام کی ذمہ داری دی گئی ہو۔

مثلاً:

Issue:
Fix duplicate invoice bug

Assignee:
Ali

اب واضح ہے کہ اس اشو پر علی کام کررہا ہے۔

گٹ ہب اسائنی کو یہ واضح کرنے کے لیے استعمال کرتا ہے کہ کسی خاص اشو یا پل ریکویسٹ پر کون کام کررہا ہے۔

لیبل کیا ہے؟

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

مثلاً:

bug
feature
documentation
urgent
frontend
backend

اب اگر ریپوزٹری میں 500 اشوز ہوں تو آپ صرف:

bug

لیبل والے اشوز دیکھ سکتے ہیں۔

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

ایک اشو پر ایک سے زیادہ لیبل ہوسکتے ہیں

مثلاً:

bug

اور:

frontend

اور:

high-priority

ایک ہی اشو کے ساتھ لگ سکتے ہیں۔

اب فوراً معلوم ہوجائے گا:

یہ فرنٹ اینڈ کا اہم بگ ہے۔

مائل اسٹون کیا ہے؟

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

مثلاً:

Version 2.0 Launch

اس مائل اسٹون میں یہ اشوز ہوسکتے ہیں:

Add customer module
Add supplier module
Improve dashboard
Fix invoice bug
Add export to PDF

گٹ ہب مائل اسٹون میں متعلقہ اشوز اور پل ریکویسٹس کا پروگریس، اوپن اور کلوز آئٹمز اور کمپلیشن پرسنٹیج ٹریک کرسکتا ہے۔

پراجیکٹ کے ساتھ اشو کیسے کام کرتا ہے؟

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

مثلاً:

Todo
In Progress
Testing
Done

اب ہر اشو ایک کارڈ کی طرح مختلف مرحلوں میں منتقل ہوسکتا ہے۔

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

سب اشو کیا ہے؟

بڑا اشو کئی چھوٹے اشوز میں تقسیم کیا جاسکتا ہے۔

مثلاً بڑا اشو:

Build customer management module

اس کے سب اشوز:

Create customer database table
Build add customer form
Build customer list
Add edit customer feature
Add customer search

گٹ ہب اب سب اشوز کے ذریعے بڑے کام کو چھوٹے قابلِ ٹریک حصوں میں توڑنے کی سہولت بھی دیتا ہے۔

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

بعض کام اس وقت تک شروع نہیں ہوسکتے جب تک دوسرا کام مکمل نہ ہو۔

مثلاً:

Issue A:
Create database schema

اور:

Issue B:
Build customer form

اگر کسٹمر فارم ڈیٹابیس کے بغیر نہیں بن سکتا تو اشوز کے درمیان ڈیپینڈنسی ظاہر کی جاسکتی ہے۔

گٹ ہب اشو ڈیپینڈنسیز کے ذریعے یہ دکھانے کی سہولت دیتا ہے کہ کون سا اشو دوسرے کو بلاک کررہا ہے۔

اشو اور پل ریکویسٹ میں کیا فرق ہے؟

یہ بہت اہم فرق ہے۔

اشو بتاتا ہے:

کیا کرنا ہے؟

جبکہ:

پل ریکویسٹ عام طور پر دکھاتی ہے:

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

مثلاً:

Issue #15
Fix login validation bug

ڈیویلپر ایک برانچ میں کوڈ ٹھیک کرتا ہے۔

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

پل ریکویسٹ میں لکھ سکتا ہے:

Fixes #15

اب کوڈ مرج ہونے پر متعلقہ اشو بھی خودکار طور پر کلوز ہوسکتا ہے، اگر درست کلوزنگ کی ورڈ استعمال کیا گیا ہو۔

اشو اور کمیٹ کا تعلق

کمیٹ میں بھی اشو کا ریفرنس دیا جاسکتا ہے۔

مثلاً:

Fix login validation issue #15

اب بعد میں معلوم ہوسکتا ہے کہ یہ کمیٹ کس اشو سے متعلق تھی۔

اشو کیوں اہم ہے اگر صرف ایک شخص پراجیکٹ پر کام کررہا ہو؟

بہت لوگ سمجھتے ہیں کہ اشوز صرف ٹیم کے لیے ہیں۔

ایسا نہیں۔

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

مثلاً:

#21 Add backup feature
#22 Fix attendance calculation
#23 Improve mobile layout
#24 Add customer search

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

اے آئی کوڈنگ میں اشوز کا کردار

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

غلط ورک فلو:

AI کو کہیں:
"سسٹم بہتر کردو"

یہ ہدایت بہت وسیع ہے۔

ایجنٹ بہت سی غیر ضروری تبدیلیاں کرسکتا ہے۔

بہتر ورک فلو:

Issue #31
Add search filter to customer list

پھر اے آئی ایجنٹ کو کہیں:

Implement only issue #31.
Do not modify unrelated working features.

اب اس کا کام محدود اور واضح ہے۔

اے آئی ایجنٹ کے لیے اشو ایک ورک آرڈر بن سکتا ہے

اسے ایک عملی ورک آرڈر سمجھیں۔

مثلاً:

Issue #42

Title:
Add daily sales report

Requirements:

- Show total sales
- Show total returns
- Show net sales
- Filter by date
- Export PDF

اب کوڈنگ ایجنٹ کو واضح معلوم ہے کہ کیا بنانا ہے۔

ایک بڑے اے آئی پراجیکٹ کا بہتر ورک فلو

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

ہر فیچر الگ اشو:

#1 Project setup
#2 User login
#3 Product management
#4 Customer management
#5 Sales module
#6 Purchase module
#7 Expense module
#8 Reports

پھر ہر اشو کے لیے الگ برانچ:

feature/customer-management

کام مکمل ہو:

Commit

پھر:

Pull Request

پھر:

Review

پھر:

Merge

اور آخر میں:

Close Issue

مکمل ورک فلو:

Issue
↓
Branch
↓
Code
↓
Test
↓
Commit
↓
Pull Request
↓
Review
↓
Merge
↓
Close Issue

یہ ایک بہت منظم ڈیویلپمنٹ سائیکل بن جاتا ہے۔

اچھا اشو لکھنے کا فارمولا

ایک مفید فارمولا یہ ہوسکتا ہے:

Title

Problem / Requirement

Steps to reproduce

Expected result

Actual result

Acceptance criteria

Additional notes

ہر اشو میں تمام حصے ضروری نہیں، لیکن پیچیدہ اشو میں یہ ساخت بہت مفید ہوتی ہے۔

ایکسیپٹنس کرائٹیریا کیا ہوتے ہیں؟

یہ وہ شرائط ہیں جن کے پورا ہونے پر کہا جاسکے:

یہ اشو مکمل ہوگیا۔

مثلاً:

Title:
Add customer search

ایکسیپٹنس کرائٹیریا:

- Search by customer name
- Search by phone number
- Results update without page reload
- No duplicate results
- Works on mobile

اب مکمل ہونے کی تعریف واضح ہے۔

اشو ٹیمپلیٹ کیا ہے؟

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

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

Bug description:

Steps to reproduce:

Expected result:

Actual result:

Screenshots:

Environment:

اب ہر شخص بگ اشو اسی ترتیب سے بنائے گا۔

اس سے نامکمل اشوز کم ہوجاتے ہیں۔

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

ڈپلیکیٹ اشو کیا ہے؟

کبھی کوئی شخص ایسا اشو بنادیتا ہے جو پہلے سے موجود ہوتا ہے۔

مثلاً:

#25 Login fails on mobile

اور بعد میں کوئی بناتا ہے:

#41 Mobile login not working

دونوں ایک ہی مسئلہ ہوسکتے ہیں۔

ایسی صورت میں نئے اشو کو ڈپلیکیٹ قرار دے کر پہلے اشو کی طرف ریفرنس کیا جاسکتا ہے۔

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

اشو کب نہیں بنانا چاہیے؟

ہر چھوٹی گفتگو کے لیے اشو بنانا بھی ضروری نہیں۔

مثلاً اگر ٹیم کے کسی فرد سے صرف یہ پوچھنا ہو:

میٹنگ کتنے بجے ہے؟

اس کے لیے اشو بنانے کی ضرورت نہیں۔

اشو اس وقت زیادہ مفید ہوتا ہے جب چیز:

  • قابلِ عمل ہو۔
  • ٹریک ہونی چاہیے۔
  • مستقبل میں ریفرنس کی ضرورت ہو۔
  • کوڈ یا پراجیکٹ سے متعلق ہو۔
  • کسی ذمہ دار شخص کے ساتھ منسلک ہو۔

اچھے اشوز کی خصوصیات

اچھا اشو:

  • واضح ہوتا ہے۔
  • مختصر مگر کافی معلومات رکھتا ہے۔
  • ایک واضح مقصد رکھتا ہے۔
  • غیر متعلقہ کام شامل نہیں کرتا۔
  • مکمل ہونے کی تعریف واضح کرتا ہے۔
  • ضرورت کے مطابق اسکرین شاٹ یا ایرر فراہم کرتا ہے۔

خراب اشو کی مثال

Title:
Website broken

ڈسکرپشن:

Please fix.

اس سے ڈیویلپر کو تقریباً کچھ معلوم نہیں ہوتا۔

اسی اشو کو بہتر بنائیں

Title:
Checkout page crashes after applying discount coupon

پھر:

Steps to reproduce:

1. Add a product to cart.
2. Open checkout.
3. Apply coupon SAVE10.
4. Click Place Order.

Expected result:

Order should be created with 10% discount.

Actual result:

A server error is displayed.

اب اشو قابلِ عمل ہے۔

اشو مینجمنٹ کے لیے ایک سادہ لیبل سسٹم

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

شروع میں یہ کافی ہوسکتے ہیں:

bug
feature
enhancement
documentation
urgent

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

ترجیح کیسے ظاہر کریں؟

مثلاً:

priority-high
priority-medium
priority-low

یا گٹ ہب پراجیکٹ میں ایک الگ پرائیرٹی فیلڈ استعمال کیا جاسکتا ہے۔

اہم بات یہ ہے کہ ٹیم ایک ہی نظام استعمال کرے۔

اشو کو عمارت کی مثال سے سمجھیں

فرض کریں عمارت زیرِ تعمیر ہے۔

سائٹ پر معلوم ہوا:

تیسری منزل پر باتھ روم کا ایک پائپ غلط جگہ لگا ہے۔

اگر صرف زبانی کہا گیا تو بات بھول سکتی ہے۔

اگر سائٹ رپورٹ میں لکھا جائے:

Issue #18

Third floor bathroom pipe needs relocation.

پھر:

Assigned to:
Plumbing contractor

اسٹیٹس:

In Progress

کام مکمل:

Closed

گٹ ہب اشو سافٹ ویئر پراجیکٹ میں تقریباً یہی کردار ادا کرتا ہے۔

ایک مکمل مثال

فرض کریں آپ کا اکاؤنٹنگ سسٹم ہے۔

نیا اشو:

#37

ٹائٹل:

Invoice total changes after page refresh

لیبل:

bug
high-priority

اسائنی:

Developer A

مائل اسٹون:

Version 1.2

ڈسکرپشن:

The invoice total is correct when the invoice is created.

After refreshing the page, tax is added twice.

Expected:
Tax should only be applied once.

Actual:
Tax is applied again after refresh.

پھر ڈیویلپر:

Branch:
fix/invoice-tax

کمیٹ:

Fix duplicate tax calculation

پل ریکویسٹ:

Fixes #37

ریویو کے بعد مرج۔

اشو کلوز۔

یہ مکمل ٹریس ایبل ورک فلو ہے۔

اشو کی اصل طاقت کیا ہے؟

اشو کی اصل طاقت صرف یہ نہیں کہ وہ ایک ٹو ڈو لسٹ بناتا ہے۔

اصل طاقت یہ ہے کہ وہ:

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

اسی وجہ سے بعد میں پورا ریکارڈ دیکھا جاسکتا ہے:

مسئلہ کب رپورٹ ہوا؟

کس نے لیا؟

کیا گفتگو ہوئی؟

کون سا کوڈ بدلا؟

کس پل ریکویسٹ سے حل ہوا؟

کب کلوز ہوا؟

خلاصہ

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

اشو میں آپ:

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

سب سے آسان تعریف یہ ہے:

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

جبکہ بعد میں برانچ، کمیٹ اور پل ریکویسٹ یہ دکھاتے ہیں کہ:

اس کام کو کیسے حل کیا گیا۔

اسی لیے ایک منظم گٹ ہب ورک فلو کو یوں سمجھا جاسکتا ہے:

Issue
↓
Branch
↓
Development
↓
Commit
↓
Pull Request
↓
Review
↓
Merge
↓
Close Issue

گٹ ہب کو سمجھنے کے لیے یہ مضمون بھی پڑھ لیں>>>>

تبصرہ کریں