کامیت کردن — چیست، قوانین قالب‌بندی و کار با 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) تشکیل می‌دهند که در آن هر کامیت جدید به قبلی ارجاع می‌دهد. این امکان حرکت در تاریخچه، لغو تغییرات و تحلیل تکامل پایگاه کد را فراهم می‌کند. درک ساختار DAG گیت — اساس کار پیشرفته با کامیت‌هاست.

چگونه تغییرات را به درستی کامیت کنیم

فرآیند کامیت در Git از دو مرحله تشکیل شده است: افزودن تغییرات به منطقه مرحله‌بندی (ایندکس) و ایجاد کامیت. منطقه مرحله‌بندی به توسعه‌دهنده اجازه می‌دهد انتخاب کند کدام تغییرات وارد کامیت شوند، حتی اگر فایل‌های زیادی در دایرکتوری کاری تغییر کرده باشند.

قاعده اتمی بودن — اصل کلیدی یک کامیت خوب. هر کامیت باید شامل یک تغییر منطقی باشد. اگر توسعه‌دهنده باگی را رفع و کد را بازنویسی می‌کند — این دو کامیت جداگانه هستند. کامیت‌های اتمی بازبینی کد، بازگردانی تغییرات و تحلیل تاریخچه را ساده می‌کنند.

قبل از کامیت کردن ارزش بررسی دارد: آیا در کد خروجی اشکال‌زدایی، بلوک‌های توضیح شده یا تغییرات اتفاقی باقی نمانده است. برای این کار از دستور git diff --cached استفاده می‌شود که نشان می‌دهد دقیقاً چه چیزی وارد کامیت می‌شود. بررسی اضافی از طریق git status لیست فایل‌های منطقه مرحله‌بندی را نمایش می‌دهد.

• تغییرات را بررسی کن — git diff --cached نشان می‌دهد چه چیزی وارد کامیت می‌شود
• کیفیت را بررسی کن — کد باید قبل از کامیت لینتر و تست‌ها را پاس کند
• پیام بنویس — توضیح قابل فهم هدف تغییر
• مرحله‌بندی شده را بررسی کن — git status لیست فایل‌ها را تأیید می‌کند

قوانین نوشتن پیام‌های کامیت

پیام کامیت — مستندسازی تغییر برای توسعه‌دهندگان آینده است. پیام خوب به سؤالات پاسخ می‌دهد: چه چیزی تغییر کرده و چرا. قرارداد کامیت‌های متعارف (تیم انگولار، ۲۰۱۶) برای بسیاری از پروژه‌ها به استاندارد تبدیل شده و فرمت را مشخص می‌کند: نوع(حوزه): توضیحات.

پیام کامیت خوب از عنوان (حداکثر ۵۰ کاراکتر) و بدنه (اختیاری، حداکثر ۷۲ کاراکتر در هر خط) تشکیل شده است. عنوان به حالت امری نوشته می‌شود: «Add» نه «Added» یا «Adds». حروف بزرگ و نقطه در انتهای عنوان استفاده نمی‌شود — این قرارداد بین‌المللی 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

# بازنویسی تعاملی برای ۳ کامیت آخر
git rebase -i HEAD~3

بازنویسی تعاملی — ابزار قدرتمندی برای بازنویسی تاریخچه. امکان ادغام کامیت‌ها (squash)، تغییر پیام‌ها (reword)، تغییر ترتیب (reorder) و حذف کامیت‌ها (drop) را فراهم می‌کند. با این حال rebase تاریخچه را تغییر می‌دهد، بنابراین فقط برای کامیت‌های محلی که هنوز به مخزن راه دور ارسال نشده‌اند اعمال می‌شود.

برای لغو کامیت‌ها دو رویکرد وجود دارد. git revert یک کامیت جدید ایجاد می‌کند که تغییرات قبلی را لغو می‌کند — روشی امن که تاریخچه را حفظ می‌کند. git reset کامیت‌ها را از تاریخچه حذف می‌کند — خطرناک اگر کامیت‌ها قبلاً ارسال شده‌اند. در توسعه تیمی فقط از git revert برای لغو کامیت‌های منتشر شده استفاده می‌شود.