مقدمه
دانستن دستورات گیت تنها نیمی از مسیر است؛ نیم دیگر، دانستن چگونگی استفاده از
این دستورات به شیوه‌ای حرفه‌ای و موثر است. کیفیت کامیت‌های شما تاثیر مستقیمی بر سلامت، خوانایی و
قابلیت نگهداری پروژه در بلندمدت دارد. یک تاریخچه کامیت تمیز و معنادار مانند یک داستان واضح و
روشن از روند توسعه پروژه شماست، در حالی که یک تاریخچه آشفته و مبهم، همکاران شما (و خود شما در
آینده) را سردرگم خواهد کرد.
در این درس، مجموعه‌ای از مهم‌ترین توصیه‌ها و بهترین روش‌ها برای ساختن کامیت‌هایی را بررسی
می‌کنیم که به سادگی قابل فهم، پیگیری و مدیریت باشند.
قانون اول: کامیت‌های اتمی (Atomic) بسازید
یک کامیت باید یک واحد منطقی و کامل از تغییر را نمایندگی کند. به این نوع کامیت،
«اتمی» می‌گویند. این یعنی هر کامیت باید فقط یک کار مشخص را انجام دهد.
- مثال خوب: «رفع باگ نمایش نام کاربری در پروفایل» یا «افزودن قابلیت آپلود آواتار».
- مثال بد: «رفع باگ پروفایل و تغییر رنگ‌بندی سایت و به‌روزرسانی مستندات». این کامیت سه
تغییر منطقی نامرتبط را در خود جای داده است.
چرا کامیت اتمی مهم است؟
- درک آسان‌تر تاریخچه: با یک نگاه به تاریخچه، دقیقاً می‌فهمید هر تغییر چه زمانی و با چه
هدفی انجام شده است.
- اشکال‌زدایی (Debug) ساده‌تر: اگر یک باگ در پروژه ایجاد شود، با ابزارهایی مانند git
bisect می‌توانید به سرعت کامیت دقیق مسبب باگ را پیدا کنید. این کار زمانی که کامیت‌ها
بزرگ و نامرتبط هستند تقریباً غیرممکن است.
- بازگردانی (Revert) راحت‌تر: اگر یک قابلیت جدید باعث بروز مشکل شود، می‌توانید به راحتی
همان یک کامیت اتمی را revert کنید، بدون اینکه روی سایر بخش‌های کد تاثیری بگذارید.
برای ساخت کامیت‌های اتمی، از قدرت Staging Area استفاده کنید. فقط فایل‌های مربوط به یک
تغییر منطقی را add کرده و کامیت کنید، سپس به سراغ تغییر بعدی بروید.
قانون دوم: پیام‌های کامیت خوب بنویسید
یک کامیت فقط به اندازه پیامش خوب است. پیام کامیت، پنجره شما به ذهن توسعه‌دهنده در زمان ایجاد
تغییر است. یک استاندارد پذیرفته‌شده برای نوشتن پیام کامیت وجود دارد که شامل یک عنوان کوتاه و یک
بدنه توضیحی (اختیاری) است.
عنوان (Subject)
- کوتاه و مختصر باشد (حدود ۵۰ کاراکتر): ابزارهای گیت مانند git log --oneline و
رابط کاربری گیت‌هاب برای این طول بهینه شده‌اند.
- از حالت امری (Imperative Mood) استفاده کنید: پیام شما باید مانند یک دستور باشد. مثلاً
بنویسید «Add feature» به جای «Added feature» یا «Adding feature». تصور کنید پیام شما جمله
زیر را کامل می‌کند: «If applied, this commit will... [your subject line]».
- حرف اول را با حرف بزرگ شروع کنید و در انتهای آن نقطه نگذارید.
بدنه (Body)
- عنوان را با یک خط خالی از بدنه جدا کنید. این کار برای ابزارهای گیت حیاتی است.
- در بدنه، به سوالات «چه چیزی» و «چرا» پاسخ دهید، نه
«چگونه». کد خود گویای «چگونه» است. توضیح دهید که این کامیت چه مشکلی را حل می‌کند و چرا این
تغییر ضروری بوده است.
- طول هر خط را به حدود ۷۲ کاراکتر محدود کنید تا در ترمینال‌های مختلف به راحتی خوانده شود.
- اگر از سیستم مدیریت پروژه (مانند Jira یا GitHub Issues) استفاده می‌کنید، شماره تیکت مربوطه
را در انتهای پیام ذکر کنید (مثلاً Resolves: #123).
در اینجا یک الگوی عالی برای یک پیام کامیت استاندارد آورده شده است:
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Further paragraphs come after blank lines.
- Bullet points are okay, too
Resolves: #123
قانون سوم: کارهای نیمه‌تمام را کامیت نکنید
هر کامیت باید پروژه را در یک وضعیت پایدار و قابل اجرا رها کند. این یعنی کد شما
باید بدون خطا کامپایل شود و تست‌های اصلی باید با موفقیت اجرا شوند (اگر تست دارید). این بدان معنا
نیست که یک قابلیت باید ۱۰۰٪ کامل باشد، اما کامیتی که ثبت می‌کنید نباید پروژه را خراب
(break) کند.
این قانون برای کار تیمی حیاتی است. اگر هم‌تیمی شما برنچ شما را دریافت کند، باید بتواند روی یک
پایه کد سالم و بدون مشکل کار خود را ادامه دهد. اگر نیاز به تغییر زمینه کاری دارید اما کارتان
برای کامیت کردن آماده نیست، از دستور git stash استفاده کنید که در درس‌های آینده با آن
آشنا خواهیم شد.