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

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

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

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

کمیٹ پراجیکٹ کی تبدیلیوں کا ایک محفوظ ریکارڈ ہوتا ہے۔

یعنی آپ نے پراجیکٹ میں جو تبدیلی کی، اسے ایک واضح مرحلے کے طور پر محفوظ کردیا۔

مثلاً:

         Login system completed

پھر:

         Student registration added

پھر:

           Attendance module completed

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

کمیٹ کو ایک سادہ مثال سے سمجھیں

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

شروع میں پراجیکٹ صرف لاگ اِن پر مشتمل ہے۔

آپ کمیٹ بناتے ہیں:

       Login system working

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

دوسری کمیٹ:

       Student module completed

پھر اٹینڈنس شامل کرتے ہیں۔

تیسری کمیٹ:

         Attendance module added

اب آپ کی ورژن ہسٹری کچھ یوں نظر آسکتی ہے:

         Commit 1
         Login system working

↓

           Commit 2
          Student module completed

↓

           Commit 3
          Attendance module added

یہ صرف تین فائلوں کے Save Points نہیں ہیں۔

یہ پورے پراجیکٹ کی ڈیویلپمنٹ ہسٹری ہیں۔

کمیٹ اور عام Save میں کیا فرق ہے؟

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

جب آپ کسی فائل کو Save کرتے ہیں تو صرف موجودہ تبدیلی فائل میں محفوظ ہوتی ہے۔

مثلاً:

               Ctrl + S

اس کے بعد فائل کا نیا ورژن محفوظ ہوگیا۔

لیکن عام Save یہ نہیں بتاتا:

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

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

کمیٹ ایک سنیپ شاٹ جیسی ہوتی ہے

کمیٹ کو ایک سنیپ شاٹ سمجھنا آسان ہے۔

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

تعمیر کے مختلف مراحل کی تصاویر لی جاتی ہیں:

          Foundation complete

          Ground floor complete

           First floor complete

           Finishing complete

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

گٹ میں کمیٹ کچھ ایسا ہی کام کرتی ہے۔

ورژن ہسٹری کیا ہے؟

تمام کمیٹس مل کر پراجیکٹ کی ورژن ہسٹری بناتی ہیں۔

مثلاً:

          Initial project setup
           ↓
           Login completed
           ↓
           Student module added
           ↓
           Attendance added
           ↓
           Fee module added
           ↓
           Dashboard redesigned

اس ہسٹری کی مدد سے آپ پورے پراجیکٹ کی ترقی دیکھ سکتے ہیں۔

یہ خاص طور پر بڑے پراجیکٹس میں بہت اہم ہے۔

کمیٹ بنانے سے پہلے کیا ہوتا ہے؟

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

         Working Directory

          ↓

          Staging Area

           ↓

          Repository

ان تینوں کو الگ الگ سمجھتے ہیں۔

ورکنگ ڈائریکٹری کیا ہے؟

ورکنگ ڈائریکٹری وہ جگہ ہے جہاں آپ حقیقت میں فائلوں پر کام کررہے ہوتے ہیں۔

مثلاً:

             school-management-system/

آپ نے login.php میں تبدیلی کی۔

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

لیکن ابھی کمیٹ نہیں ہوئی۔

سٹیجنگ ایریا کیا ہے؟

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

میں ان تبدیلیوں کو اگلی کمیٹ میں شامل کرنا چاہتا ہوں۔

مثلاً:

         git add login.php

یا تمام موجودہ تبدیلیاں شامل کرنے کے لیے:

          git add .

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

ریپوزٹری میں کب جاتی ہیں؟

جب آپ کمیٹ بناتے ہیں:

              git commit -m "Fix login validation"

تو سٹیجڈ تبدیلیاں ریپوزٹری کی ہسٹری کا حصہ بن جاتی ہیں۔

ورک فلو:

              File changed
              ↓
               git add
               ↓
               Staged
               ↓                git commit
                ↓
               Commit history

git add اور git commit میں فرق

یہ نئے سیکھنے والوں کے لیے اہم فرق ہے۔

git add

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

مثلاً:

              git add login.php

اس کا مطلب:

اس فائل کی تبدیلی اگلی کمیٹ میں شامل کرو۔

git commit

یہ سٹیجڈ تبدیلیوں کو مستقل ہسٹری میں محفوظ کرتا ہے۔

مثلاً:

            git commit -m "Fix login validation"

اس کا مطلب:

ان منتخب تبدیلیوں کی کمیٹ بناؤ۔

کیا git add . ہمیشہ استعمال کرنا چاہیے؟

یہ آسان ضرور ہے:

             git add .

لیکن ہر حالت میں بہترین نہیں۔

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

مثلاً:

            git add login.php auth.php

تاکہ کمیٹ ایک ہی موضوع سے متعلق رہے۔

اچھی کمیٹ کیسی ہونی چاہیے؟

اچھی کمیٹ عام طور پر ایک واضح تبدیلی یا مقصد کو ظاہر کرتی ہے۔

مثلاً:

           Add student registration form

اچھی کمیٹ۔

           Fix duplicate fee receipt issue

اچھی کمیٹ۔

           Add monthly attendance report

اچھی کمیٹ۔

خراب کمیٹ کی مثالیں

یہ کمیٹ میسجز بہت کم معلومات دیتے ہیں:

      update

      changes

      fix

       new

       done

کچھ عرصے بعد آپ کو خود بھی معلوم نہیں ہوگا کہ اصل تبدیلی کیا تھی۔

اچھا کمیٹ میسج کیوں ضروری ہے؟

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

اگر کمیٹس یہ ہوں:

         update
          fix
           change
            done
             new

تو آپ کو کچھ سمجھ نہیں آئے گا۔

لیکن اگر یہ ہوں:

         Fix login redirect after authentication

         Add student search by class

         Prevent duplicate fee receipt generation

تو فوراً معلوم ہوجائے گا کہ ہر کمیٹ میں کیا ہوا۔

ایک کمیٹ میں کتنی تبدیلی ہونی چاہیے؟

اس کا کوئی سخت اصول نہیں، لیکن عمومی طور پر:

ایک کمیٹ = ایک واضح مقصد

یہ ایک اچھا اصول ہے۔

مثلاً ایک ہی کمیٹ میں:

• لوگو تبدیل کرنا
• لاگ اِن بگ فکس کرنا
• ڈیٹابیس ٹیبل بدلنا
• ڈیش بورڈ ری ڈیزائن کرنا

سب شامل کردینا مناسب نہیں۔

بہتر ہوگا:

      Commit 1
       Fix login validation

       Commit 2
        Update dashboard layout

       Commit 3
        Add database migration

بہت زیادہ چھوٹی کمیٹس بھی مسئلہ بن سکتی ہیں

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

مثلاً:

       Change button text

پھر:

       Change button color

پھر:

        Move button 2px

اگر یہ سب ایک ہی چھوٹے UI کام کا حصہ ہیں تو ایک مناسب کمیٹ بہتر ہوسکتی ہے:

          Update login button styling

بہترین کمیٹ ٹائمنگ کیا ہے؟

عمومی طور پر کمیٹ اس وقت بنائیں جب:

• ایک چھوٹا فیچر مکمل ہو۔
• ایک بگ فکس ہو۔
• ایک ماڈیول کا واضح حصہ مکمل ہو۔
• کوئی مستحکم مرحلہ حاصل ہو۔
• بڑی تبدیلی شروع کرنے سے پہلے موجودہ حالت محفوظ کرنی ہو۔

اے آئی کوڈنگ میں کمیٹ کیوں بہت اہم ہے؟

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

مثلاً آپ کہتے ہیں:

ڈیش بورڈ کا ڈیزائن بہتر کریں۔

ایجنٹ شاید:

• CSS بدلے
• JavaScript بدلے
• Template بدلے
• Routing بدلے
• Database query بھی چھو لے

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

اس لیے اے آئی ورک فلو میں کمیٹس کو چیک پوائنٹس کے طور پر استعمال کرنا بہت مفید ہے۔

اے آئی کوڈنگ کے لیے بہتر ورک فلو

مثلاً:

       Project working correctly
        ↓
       Commit
        ↓
       Ask AI to add new feature
        ↓
       Test
        ↓
       If correct
        ↓
       Commit

پھر اگلا فیچر۔

ایک عملی مثال

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

پہلے لاگ اِن مکمل ہوا۔

کمیٹ:

         Login system tested and working

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

کمیٹ:

         Student module tested and working

پھر اٹینڈنس:

         Attendance module tested and working

پھر آپ کہتے ہیں:

پورا ڈیش بورڈ ری ڈیزائن کریں۔

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

بڑی تبدیلی سے پہلے کمیٹ

بہت مفید عادت یہ ہے:

بڑی یا خطرناک تبدیلی شروع کرنے سے پہلے کمیٹ کریں۔

مثلاً:

          Stable version before dashboard redesign

اس کے بعد نیا تجربہ کریں۔

اگر مسئلہ آجائے تو کم از کم معلوم ہے کہ آخری مستحکم حالت کہاں تھی۔

کمیٹ آئی ڈی کیا ہوتی ہے؟

ہر کمیٹ کی ایک منفرد شناخت ہوتی ہے جسے کمیٹ ہیش یا کمیٹ آئی ڈی کہا جاتا ہے۔

مثلاً:

       a3f8c21

اصل ہیش اس سے کافی لمبی ہوسکتی ہے۔

گٹ اکثر اسے مختصر شکل میں دکھاتا ہے۔

مثلاً:

        a3f8c21 Fix login validation

یہ آئی ڈی کسی خاص کمیٹ کو شناخت کرنے میں مدد دیتی ہے۔

کمیٹ ہسٹری کیسے دیکھیں؟

کمانڈ لائن میں:

         git log

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

یہ کمیٹ ہسٹری دکھاتا ہے۔

مختصر شکل کے لیے:

        git log --oneline

مثلاً:

        a3f8c21 Fix login validation
        82b1d6f Add student registration
        7ac92e1 Initial project setup

یہ بہت مفید ویو ہے۔

گٹ ہب پر کمیٹ ہسٹری کیسے دیکھیں؟

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

وہاں آپ دیکھ سکتے ہیں:

• کمیٹ میسج
• کمیٹ کس نے کی
• کب کی
• کون سی فائلیں تبدیل ہوئیں
• کون سی لائنیں شامل ہوئیں
• کون سی لائنیں حذف ہوئیں

یہ کوڈ ریویو اور بگ ٹریکنگ میں بہت اہم ہوتا ہے۔

ڈِف کیا ہے؟

دو حالتوں کے درمیان فرق کو عام طور پر ڈِف کہا جاتا ہے۔

مثلاً پہلے:

         if ($password == $savedPassword) {

بعد میں:

         if (password_verify($password, $savedPassword)) {

گٹ اس تبدیلی کو دکھا سکتا ہے۔

یعنی:

         Old code
          vs
          New code

یہ سمجھنے میں مدد دیتا ہے کہ کسی کمیٹ میں حقیقتاً کیا تبدیل ہوا۔

کمیٹ ہسٹری بگ ڈھونڈنے میں کیسے مدد دیتی ہے؟

فرض کریں کل لاگ اِن صحیح تھا۔

آج خراب ہے۔

آپ کمیٹ ہسٹری دیکھتے ہیں:

Commit 1
Login working

Commit 2
Dashboard update

Commit 3
Auth middleware changed

اب امکان ہے کہ مسئلہ کمیٹ 3 کے آس پاس پیدا ہوا۔

آپ ڈِف دیکھ کر جانچ سکتے ہیں کہ کیا تبدیلی کی گئی تھی۔

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

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

اسے واپس لینے کے کئی طریقے ہیں۔

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

ہسٹری کو محفوظ رکھتے ہوئے غلط تبدیلی واپس لینا

اور

ہسٹری کو بدل دینا

یہ دونوں الگ چیزیں ہیں۔

git revert

اگر آپ کسی غلط کمیٹ کی تبدیلی کو محفوظ طریقے سے واپس لینا چاہتے ہیں تو:

git revert COMMIT_ID

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

یہ پچھلی ہسٹری مٹاتا نہیں۔

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

یہ شیئرڈ یا ٹیم ریپوزٹری میں زیادہ محفوظ طریقہ سمجھا جاتا ہے۔

git reset

git reset زیادہ طاقتور ہے اور ہسٹری کو بدل بھی سکتا ہے۔

مثلاً:

git reset --hard COMMIT_ID

یہ خطرناک ہوسکتا ہے، کیونکہ غیر محفوظ تبدیلیاں ختم ہوسکتی ہیں۔

اس لیے نئے سیکھنے والوں کو git reset --hard بہت احتیاط سے استعمال کرنا چاہیے۔

خاص طور پر ٹیم کے مشترکہ پراجیکٹ میں۔

Revert اور Reset کا بنیادی فرق

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

Revert

پچھلی غلطی کو نئی کمیٹ کے ذریعے واپس کرتا ہے۔

Reset

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

اسی لیے ٹیم ورک میں Revert اکثر زیادہ محفوظ آپشن ہوتا ہے۔

Uncommitted changes کیا ہوتی ہیں؟

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

مثلاً:

login.php modified

لیکن ابھی:

No commit

ایسی تبدیلی زیادہ غیر محفوظ ہوتی ہے۔

اگر آپ غلطی سے فائل اوور رائٹ کردیں یا ورکنگ ڈائریکٹری خراب ہوجائے تو ریکوری مشکل ہوسکتی ہے۔

git status کیوں اہم ہے؟

کمانڈ:

git status

آپ کو بتاتی ہے:

• کون سی فائلیں تبدیل ہوئی ہیں؟
• کون سی سٹیجڈ ہیں؟
• کون سی ان ٹریکڈ ہیں؟
• برانچ کی کیا حالت ہے؟

یہ گٹ کی سب سے مفید بنیادی کمانڈز میں سے ایک ہے۔

ایک اچھا روٹین

کام کے دوران بار بار یہ دیکھنا مفید ہے:

git status

پھر:

git add .

یا مخصوص فائلیں۔

پھر:

git commit -m "Clear commit message"

کمیٹ اور پش میں فرق

یہ بہت عام کنفیوژن ہے۔

کمیٹ

لوکل ریپوزٹری میں تبدیلی محفوظ کرتی ہے۔

پش

لوکل کمیٹس کو ریموٹ ریپوزٹری، مثلاً گٹ ہب، پر بھیجتا ہے۔

ورک فلو:

Change files
↓
Commit
↓
Local history
↓
Push
↓
GitHub

کیا کمیٹ کے لیے انٹرنیٹ ضروری ہے؟

نہیں۔

آپ آف لائن بھی:

git add .
git commit -m "Add attendance module"

کرسکتے ہیں۔

انٹرنیٹ اس وقت چاہیے جب آپ کمیٹس کو ریموٹ ریپوزٹری پر پش کرنا چاہیں۔

کیا ہر کمیٹ فوراً پش کرنی چاہیے؟

ضروری نہیں۔

آپ کئی لوکل کمیٹس بنا سکتے ہیں:

Commit 1
Commit 2
Commit 3

پھر بعد میں سب گٹ ہب پر پش کرسکتے ہیں۔

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

ریمورٹ پر باقاعدہ پش کرنا بہتر ہے۔

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

اچھی کمیٹ ہسٹری خود پراجیکٹ کی کہانی بیان کرتی ہے۔

مثلاً:

Initial project setup
Add login system
Add student management
Add attendance module
Fix attendance duplicate entries
Add fee management
Improve dashboard layout

یہ پڑھ کر ہی اندازہ ہوجاتا ہے کہ پراجیکٹ کیسے آگے بڑھا۔

ٹیم ورک میں کمیٹس کی اہمیت

اگر ایک ٹیم میں کئی افراد کام کررہے ہوں تو واضح کمیٹس مزید ضروری ہوجاتی ہیں۔

مثلاً:

Fix invoice total calculation

ٹیم کو فوراً معلوم ہوگا کہ تبدیلی کس مسئلے سے متعلق تھی۔

اگر صرف:

fix

لکھا ہو تو فائدہ بہت کم ہوجاتا ہے۔

ایک کمیٹ میں حساس ڈیٹا بھی جاسکتا ہے

یہ ایک اہم خطرہ ہے۔

اگر آپ غلطی سے یہ فائل کمیٹ کردیں:

.env

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

اس لیے .gitignore شروع سے درست بنانا بہتر ہے۔

اے آئی ایجنٹ کو کمیٹ رولز دینا

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

Do not modify unrelated working code.
Complete one feature at a time.
Run tests before committing.
Create a clear commit after each stable feature.
Do not commit secrets or environment files.

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

خودکار کمیٹس ہمیشہ اچھی نہیں ہوتیں

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

یہ ہمیشہ بہترین طریقہ نہیں۔

اگر کمیٹ سے پہلے ٹیسٹنگ نہ ہو تو آپ خراب حالت بھی محفوظ کرسکتے ہیں۔

بہتر اصول:

Change
↓
Review
↓
Test
↓
Commit

کمیٹ سے پہلے چیک لسٹ

کمیٹ سے پہلے مختصر چیک:

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

اے آئی کوڈنگ کے لیے گولڈن رول

اے آئی کے ساتھ کام کرتے وقت یہ اصول بہت مفید ہے:

Working state کو بغیر کمیٹ کے مت چھوڑیں، خاص طور پر بڑی نئی تبدیلی شروع کرنے سے پہلے۔

مثلاً:

Current system tested and stable
↓
Commit
↓
Start AI changes

یہ ایک سادہ عادت بہت سے مسائل سے بچا سکتی ہے۔

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

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

ہر اہم مرحلے پر ریکارڈ بنایا جاتا ہے:

Foundation completed

Structure completed

Electrical work completed

Finishing completed

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

گٹ میں کمیٹس یہی کردار ادا کرتی ہیں۔

مختصر عملی ورک فلو

فائل میں تبدیلی:

login.php

اسٹیٹس دیکھیں:

git status

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

git add login.php

کمیٹ بنائیں:

git commit -m "Fix login validation"

ہسٹری دیکھیں:

git log --oneline

اور جب مناسب ہو:

git push

خلاصہ

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

کمیٹ:

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

سب سے اہم بات یہ ہے:

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

اچھا ورک فلو یہ ہے:

Change
↓
Review
↓
Test
↓
Stage
↓
Commit
↓
Push

اور اے آئی کوڈنگ میں:

Stable state
↓
Commit
↓
New AI task
↓
Test
↓
Commit

یہ عادت بڑے پراجیکٹس کو زیادہ محفوظ، واضح اور منظم بناتی ہے۔

اگلا مضمون

     برانچ کیا ہے اور گٹ ہب میں محفوظ ڈیویلپمنٹ کے لیے اسے کیسے استعمال کریں؟

اس میں ہم سمجھیں گے:

• برانچ کیا ہوتی ہے؟
• main برانچ کیا ہے؟
• فیچر برانچ کیا ہوتی ہے؟
• نئی برانچ کیوں بنانی چاہیے؟
• برانچ کیسے بنائی جاتی ہے؟
• برانچ تبدیل کیسے کرتے ہیں؟
• برانچ کو مرج کیسے کیا جاتا ہے؟
• مرج کنفلکٹ کیا ہوتا ہے؟
• اے آئی ایجنٹ کو الگ برانچ میں کام کروانا کیوں مفید ہے؟
• main کو محفوظ رکھنے کا بہترین ورک فلو کیا ہے؟