کمٹ کرنا — یہ کیا ہے، فارمیٹنگ کے قواعد اور Git کے ساتھ کام کرنا

Git میں کمٹ کیا ہے

Git میں کمٹ ایک آبجیکٹ ہے جو کسی مخصوص وقت پر پروجیکٹ فائلوں کی حالت کو محفوظ کرتا ہے۔ ہر کمٹ میں تمام ٹریک کردہ فائلوں کا سنیپ شاٹ، پیرنٹ کمٹ کا حوالہ اور میٹا ڈیٹا شامل ہوتا ہے۔ دوسرے ورژن کنٹرول سسٹمز کے برعکس، Git مواد سے مخاطب قابل ذخیرہ استعمال کرتا ہے — ہر آبجیکٹ کو اس کے مواد کے SHA-1 ہیش سے پہچانا جاتا ہے۔

جب ڈویلپر تبدیلیاں کمٹ کرتا ہے، Git ایک کمٹ آبجیکٹ بناتا ہے جو محفوظ کرتا ہے: ٹری آبجیکٹ (فائل کا ڈھانچہ)، پیرنٹ کمٹ ہیش، مصنف، کمٹر، تاریخ اور پیغام۔ یہ آبجیکٹ ناقابل تبدیلی ہے — بننے کے بعد، کمٹ کو اس کی ہیش تبدیل کیے بغیر تبدیل نہیں کیا جا سکتا۔ یہ ناقابل تبدیلی پروجیکٹ کی تاریخ کی سالمیت کو یقینی بناتی ہے۔

# تبدیلیاں اسٹیج کریں اور کمٹ کریں
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# کمٹ کی تفصیلات دیکھیں
git log --oneline -3
git show HEAD

# تمام تبدیلیاں اسٹیج کریں اور ایک قدم میں کمٹ کریں
git commit -a -m "Update dependencies to latest versions"

کمٹ ایک دشاتہ غیر دوری گراف (DAG) بناتے ہیں، جہاں ہر نیا کمٹ پچھلے کا حوالہ دیتا ہے۔ یہ تاریخ میں گھومنے، تبدیلیاں واپس لینے اور کوڈ بیس کے ارتقاء کا تجزیہ کرنے کی اجازت دیتا ہے۔ Git DAG کی ساخت کو سمجھنا کمٹ کے ساتھ جدید کام کی بنیاد ہے۔

تبدیلیوں کو صحیح طریقے سے کیسے کمٹ کریں

Git میں کمٹ کا عمل دو مراحل پر مشتمل ہے: اسٹیجنگ ایریا (انڈیکس) میں تبدیلیاں شامل کرنا اور کمٹ بنانا۔ اسٹیجنگ ایریا ڈویلپر کو یہ منتخب کرنے کی اجازت دیتا ہے کہ کمٹ میں کون سی مخصوص تبدیلیاں شامل ہوں گی، چاہے ورکنگ ڈائریکٹری میں بہت سی فائلیں تبدیل ہو گئی ہوں۔

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

کمٹ کرنے سے پہلے، یہ جانچنا مناسب ہے: کیا کوڈ میں ڈیبگ آؤٹ پٹ، کمنٹ شدہ بلاکس یا حادثاتی تبدیلیاں باقی ہیں۔ اس کے لیے git diff --cached کمانڈ استعمال کی جاتی ہے، جو ظاہر کرتی ہے کہ کمٹ میں بالکل کیا شامل ہوگا۔ git status کے ساتھ اضافی جانچ اسٹیجنگ ایریا میں فائلوں کی فہرست دکھاتی ہے۔

• تبدیلیاں چیک کریں — git diff --cached دکھاتا ہے کمٹ میں کیا شامل ہوگا
• معیار چیک کریں — کوڈ کو کمٹ سے پہلے لنٹر اور ٹیسٹ پاس کرنا چاہیے
• پیغام لکھیں — تبدیلی کے مقصد کی واضح وضاحت
• اسٹیج شدہ فائلیں چیک کریں — git status فائل کی فہرست کی تصدیق کرتا ہے

کمٹ پیغام لکھنے کے قواعد

کمٹ پیغام مستقبل کے ڈویلپرز کے لیے تبدیلی کی دستاویز ہے۔ ایک اچھا پیغام سوالات کا جواب دیتا ہے: کیا تبدیل کیا گیا اور کیوں۔ Conventional Commits کنونشن (Angular ٹیم، 2016) بہت سے منصوبوں کے لیے معیار بن گیا ہے اور فارمیٹ کی وضاحت کرتا ہے: قسم(دائرہ): وضاحت۔

ایک اچھے کمٹ پیغام میں ایک سرخی (50 حروف تک) اور ایک باڈی (اختیاری، فی سطر 72 حروف تک) ہوتی ہے۔ سرخی امر انداز میں لکھی جاتی ہے: «Add» نہ کہ «Added» یا «Adds»۔ Capitalization اور سرخی کے آخر میں نقطہ استعمال نہیں کیا جاتا — یہ ایک بین الاقوامی Git کنونشن ہے۔

برا پیغام: «fix things» یا «update» — یہ معلومات نہیں دیتا۔ ایک مہینے میں، ایک ڈویلپر سمجھ نہیں پائے گا کہ بالکل کیا اور کیوں تبدیل کیا گیا تھا۔ اچھا پیغام: «fix(payment): handle timeout in stripe callback» — فوراً واضح ہو جاتا ہے کہ کیا اور کہاں درست کیا گیا۔

کمٹ کرتے وقت عام غلطیاں

ڈویلپر، خاص طور پر ابتدائی، اکثر کمٹ کرتے وقت عام غلطیاں کرتے ہیں۔ سب سے عام ہے بہت بڑا کمٹ، جس میں درجنوں تبدیلیاں مخلوط ہوتی ہیں۔ ایسے کمٹ کو جزوی طور پر واپس نہیں لیا جا سکتا، اور کوڈ ریویو عذاب بن جاتا ہے۔

دوسری سب سے عام غلطی برا کمٹ پیغام ہے۔ «fix»، «update»، «changes» یا «wip» جیسے پیغامات مستقبل کے ڈویلپرز کو سیاق و سباق فراہم نہیں کرتے۔ چھ مہینوں میں، کسی کو یاد نہیں رہے گا کہ بالکل کیا درست کیا گیا تھا۔ قاعدہ آسان ہے: تصور کریں کہ ایک سال بعد آپ تاریخ دیکھ رہے ہیں اور ایک مخصوص تبدیلی تلاش کرنے کی کوشش کر رہے ہیں۔

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

چوتھی غلطی خفیہ ڈیٹا کو کمٹ کرنا ہے۔ API چابیاں، پاس ورڈز اور ٹوکنز Git تاریخ میں نہیں آنے چاہئیں۔ اگر کوئی راز پہلے ہی کمٹ ہو چکا ہے، تو اسے نئے کمٹ میں ہٹانا کافی نہیں ہے، بلکہ git filter-branch یا BFG Repo-Cleaner کے ذریعے پوری تاریخ سے حذف کرنا ہوگا۔

کمٹ کے ساتھ کام کرنے کی جدید تکنیکیں

Git کمٹ تاریخ کے انتظام کے لیے اوزار فراہم کرتا ہے۔ سب سے مفید میں سے ایک ہے git commit --amend، جو آخری کمٹ کو نئی تبدیلیوں کے ساتھ مکمل کرنے یا پیغام درست کرنے کی اجازت دیتا ہے۔ یہ آسان ہے اگر ڈویلپر فائل شامل کرنا بھول گیا یا پیغام میں ٹائپنگ کی غلطی کی۔

# آخری کمٹ پیغام درست کریں
git commit --amend -m "fix(auth): correct token validation logic"

# آخری کمٹ میں بھولی ہوئی فائل شامل کریں
git add missed-file.txt
git commit --amend --no-edit

# آخری 3 کمٹ کے لیے انٹرایکٹو ریبیس
git rebase -i HEAD~3

انٹرایکٹو ریبیس تاریخ کو دوبارہ لکھنے کے لیے ایک طاقتور ٹول ہے۔ یہ کمٹ کو یکجا کرنے (squash)، پیغامات تبدیل کرنے (reword)، ترتیب دوبارہ ترتیب دینے (reorder) اور کمٹ حذف کرنے (drop) کی اجازت دیتا ہے۔ تاہم، ریبیس تاریخ کو تبدیل کرتا ہے، اس لیے یہ صرف مقامی کمٹ پر استعمال ہوتا ہے جو ابھی ریموٹ ریپوزٹری میں پش نہیں کیے گئے۔

کمٹ واپس لینے کے دو طریقے ہیں۔ git revert ایک نیا کمٹ بناتا ہے جو پچھلے کی تبدیلیوں کو منسوخ کرتا ہے — ایک محفوظ طریقہ جو تاریخ کو محفوظ رکھتا ہے۔ git reset کمٹ کو تاریخ سے ہٹاتا ہے — خطرناک اگر کمٹ پہلے ہی پش ہو چکے ہیں۔ ٹیم ڈیولپمنٹ میں، شائع شدہ کمٹ کو واپس لینے کے لیے صرف git revert استعمال کیا جاتا ہے۔