چگونه یک پیام کامیت مناسب را در گیت بنویسیم(راهنمای کامل)

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

یک کامیت خوب، نشان‌دهنده حرفه‌ای بودن و همکاری موثر است. پیام‌های بی‌فایده مانند کد تمام شد یا به ناهار رفتم، نه‌تنها تاریخچه پروژه را شلوغ می‌کند، بلکه هیچ کمکی به دیگران نمی‌کند. پس در دفعات بعدی که کامیت انجام می‌دهید، از خودتان بپرسید که آیا این پیام به کسی کمک می‌کند تا متوجه شود که چه تغییراتی انجام شده است و دلیل این تغییرات چه بوده است؟! اگر جواب خیر بود شاید بهتر باشد که کمی بیشتر در کامیت زدن دقت کنید و راجب این موضوع فکر کنید.

📍بیشتر بخوانید: آموزش استفاده از Git

آنچه در ادامه خواهید خواند:

اشتباهاتی که هنگام کامیت زدن باید از آن اجتناب کرد
اهمیت نظم و وضوح در کامیت ها
چگونه تاریخچه کامیت ها را مرتب کنیم؟
ادغام کامیت ها با استفادعه از squash
قوانین نوشتن یک پیام کامیت مناسب
روش‌های Angular برای نوشتن پیام‌های کامیت
سوالات متداول
جمع بندی

اشتباهاتی که هنگام کامیت زدن باید از آن اجتناب کرد

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

برای مثال، فرض کنید که یک توسعه‌دهنده در حال ساخت یک فروشگاه اینترنتی است. کاری که نباید انجام دهد این است که:

تغییرات مربوط به صفحه‌ی محصولات را در یک کامیت جداگانه ثبت کند.
تغییرات مربوط به سبد خرید را در کامیت دیگری اضافه کند.
تمامی تغییرات مربوط به سیستم پرداخت را در کامیت سوم اعمال کند.

این روش نه‌تنها تاریخچه‌ی پروژه را شلوغ و نامرتب می‌کند، بلکه باعث می‌شود که دیگران نتوانند به‌راحتی ارتباط بین این تغییرات را درک کنند. در عوض، بهتر است که تغییرات مرتبط با یک ویژگی یا وظیفه‌ی خاص در یک کامیت واحد ثبت شوند.

🔶برای ادامه مطالعه و یادگیری: نحوه نصب Git در سرور مجازی اوبونتو

این کار نه‌تنها خوانایی تاریخچه‌ی کامیت‌ها را بهبود می‌بخشد، بلکه همکاری تیمی را ساده‌تر می‌کند.

# Committing changes to header.js separately 
git add header.js 
git commit -m "Improve header layout" 
# Committing changes to footer.js separately 
git add footer.js 
git commit -m "Optimize footer design"

اهمیت نظم و وضوح در کامیت ها

با بررسی تاریخچه Git، می‌توان فهمید که کامیت‌های نامرتب و پراکنده، به‌ویژه با افزایش تعداد آن‌ها، می‌توانند باعث شلوغی و سردرگمی شوند. کامیت‌ها باید واضح، مختصر و در قالب واحدهای منطقی سازمان‌دهی شوند. برای مثال، پس از اتمام بخش‌هایی مانند چیدمان (Layout)، هدر (Header) و فوتر (Footer)، بهتر است تغییرات مرتبط با این بخش‌ها در یک کامیت واحد ادغام شوند و سپس به مخزن ارسال شوند.

این روش نه‌تنها تاریخچه پروژه را تمیز و خوانا نگه می‌دارد، بلکه به دیگران کمک می‌کند تا به‌راحتی تغییرات را دنبال کنند و ارتباط بین آن‌ها را درک کنند. در غیر این صورت، کامیت‌های پراکنده و نامرتب می‌توانند مانند قطعات پازلی باشند که هیچ‌کس نمی‌تواند تصویر کامل را ببیند!

# Staging changes to both header.js and footer.js 
git add header.js footer.js 
# Committing related changes together 
git commit -m "Enhance UI: Header and Footer Improvements"

در تئوری، ممکن است این ایده ساده به نظر برسد، اما در عمل نیاز به نظم و برنامه‌ریزی دارد. به همین دلیل، یک روش خوب این است که یک شاخه خصوصی (Private Branch) برای کامیت‌های موقت ایجاد شود و تغییرات قبل از ادغام در شاخه اصلی، در این شاخه ثبت شوند. این کار با استفاده از تکنیک Squash (ادغام کامیت‌ها) انجام می‌شود.

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

سناریوهای کاربردی:

زمانی که در وسط کدنویسی هستید و نیاز به یک استراحت کوتاه دارید.
وقتی می‌خواهید برای شام بروید و نمی‌خواهید تغییرات فعلی را از دست بدهید.
یا حتی زمانی که می‌خواهید کار روزانه خود را تمام کنید و تغییرات را ذخیره کنید.

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

commit [commit-hash] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
WIP 
commit [commit-hash] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
commiting before i eventually lose my files 
commit [commit-hash] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
about to go for dinner commit [commit-hash] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
toilet time!

در محیط‌های collaborative (همکاری تیمی)، نام‌گذاری شاخه‌های خصوصی به شکلی واضح و مشخص، از اهمیت بالایی برخوردار است. زیرا کامیت‌های موقت و آزمایشی نباید به اشتباه در شاخه‌های عمومی (Public Branches) ظاهر شوند.

توسعه‌دهندگان می‌توانند با انتخاب نام‌های واضح برای شاخه‌های خصوصی یا از طریق ارتباط مستقیم با اعضای تیم، این موضوع را شفاف کنند که محتوای این شاخه‌ها برای کارهای جاری و اصلی مناسب نیستند. یک مثال خوب برای نام‌گذاری شاخه خصوصی می‌تواند این باشد:.


private/do-not-use-this

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

📍بیشتر بخوانید: نکته‌هایی که باید در پروفایل GitHub خود رعایت کنید

فرض کنید در حال کار روی پروژه‌ی یک فروشگاه اینترنتی هستید و شما به عنوان توسعه‌دهنده فرانت‌اند، مسئول پیاده‌سازی بخش سبد خرید هستید. روند کار شما به این شکل پیش می‌رود:

بهبود ظاهر سبد خرید با CSS: کار خود را با بهبود استایل‌های بخش سبد خرید شروع می‌کنید و تغییرات را در یک کامیت ثبت می‌کنید.
اضافه کردن قابلیت‌های جاوااسکریپت: سپس، برای افزودن تعاملات دینامیک، کدهای جاوااسکریپت را به سبد خرید اضافه می‌کنید و این تغییرات را نیز در یک کامیت جداگانه ثبت می‌کنید.
رفع مشکل تراز متن: در حین کار، متوجه می‌شوید که تراز متن در بخش سبد خرید به درستی نمایش داده نمی‌شود. پس از رفع این مشکل، تغییرات را در یک کامیت جدید ذخیره می‌کنید.
رفع باگ مربوط به شمارنده محصولات: در ادامه، باگی در رفتار شمارنده محصولات هنگام اضافه کردن آیتم‌ها به سبد خرید شناسایی می‌کنید و آن را به سرعت رفع می‌کنید. این اصلاحیه نیز در یک کامیت جداگانه ثبت می‌شود.
افزودن انیمیشن بارگذاری: در نهایت، برای بهبود تجربه کاربری، یک انیمیشن بارگذاری به دکمه تسویه حساب اضافه می‌کنید و این تغییر را نیز در یک کامیت نهایی ثبت می‌کنید.

حالا اگر به تاریخچه Git نگاهی بیندازید، با لیستی از کامیت‌های پراکنده مواجه می‌شوید که هر کدام بخشی از کار را توصیف می‌کنند. اما آیا این روش بهترین راه برای ثبت تغییرات است؟

commit [commit-hash-1] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
Enhance CSS presentation of cart section 
commit [commit-hash-2] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
Introduce Javascript functionality to cart 
commit [commit-hash-3] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
Refine CSS to resolve text alignment issue 
commit [commit-hash-4] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] 
Fix counter bug related to cart behavior 
commit [commit-hash-5] 
Author: Your Name <your.email@example.com> 
Date: [Timestamp] Incorporate loading animation for checkout button

اگر این تغییرات نیاز باشد به همراه سایر کامیت‌های مرتبط با فروشگاه اینترنتی در شاخه اصلی ادغام شوند، فرآیند بازبینی (Review) می‌تواند به چالشی بزرگ تبدیل شود.

چگونه تاریخچه کامیت ها را مرتب کنیم؟

اولین قدم این است که به شاخه‌ی feature خود سوئیچ کنید:

# Checkout the feature branch named feature/cart-section 
git checkout feature/cart-section

ادغام کامیت ها با استفادعه از squash

# Write your detailed commit message
git commit -v -m "Feat: Create the Cart Feature with a Nice Animation 
Enhanced the CSS layout of the cart section, addressing text 
alignment issues and refining the layout for improved aesthetics
and readability. "

در مرحله بعد، تمامی کامیت‌های موجود در شاخه‌ی private/do-not-use-this را با استفاده از یک پیام کامیت واحد، در شاخه‌ی feature/cart-section ادغام (Squash) کنید.

# Merge and squash all commits from the private branch to the feature branch using a single commit 
git merge - squash private/do-not-use-this

کردن کامیت ها باید یک پیام کامیت واضح و توصیفی بنویسید الین پایم باید بخ گونه ای نوشته باشد که Squash پس از ادغام و تغییرات اناجم شده را به صورت مامل توضیخ دهد و به دیگران کمک کند تا به راختی متوجه شوند جه کاری انجان شده است.

# Write your detailed commit message
git commit -v -m "Feat: Create the Cart Feature with a Nice Animation
Enhanced the CSS layout of the cart section, addressing text 
alignment issues and refining the layout for improved aesthetics 
and readability. "

🔶برای ادامه مطالعه و یادگیری: اکشن‌های جدید GitHub برای استقرار سریع و بهینه در App Platform

قوانین نوشتن یک پیام کامیت مناسب

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

قانون اول: محدود کردن موضوع به 50 کاراگتر (حداکثر)

هنگام نوشتن خط موضوع (Subject Line) پیام کامیت، بهتر است آن را مختصر و متمرکز نگه دارید. خط موضوع به عنوان یک خلاصه سریع از هدف کامیت عمل می‌کند و باید حداکثر تا ۵۰ کاراکتر محدود شود.

اگر در محدود کردن موضوع به ۵۰ کاراکتر مشکل دارید، این ممکن است نشان‌دهنده عدم وضوح در هدف کامیت باشد. پیام‌های کامیت باید واضح، مختصر و به‌گونه‌ای باشند که به تنهایی مفهوم را برسانند. با رعایت این محدودیت، شما مجبور می‌شوید مهم‌ترین اطلاعات را اولویت‌بندی کنید، که این کار درک تغییرات را برای تیم و خودتان در آینده آسان‌تر می‌کند.

قانون دوم: فقط حرف اول خط موضوع را بزرگ بنویسید

هنگام نوشتن پیام کامیت، از حالت عنوان‌نویسی (Title Case) استفاده کنید و فقط حرف اول خط موضوع را بزرگ بنویسید، درست مانند یک جمله کوتاه. بقیه متن پیام، از جمله جزئیات اضافی، باید با حروف کوچک نوشته شود.

قانون سوم: در پایان خط نقطه نگذارید

دلیل عدم استفاده از نقطه در پایان خط موضوع، بخشی تاریخی و بخشی دیگر برای حفظ یک سبک یکسان است. این قرارداد، خط موضوع را به عنوان یک عنوان یا دستور در نظر می‌گیرد، به همین دلیل از حالت امری (Imperative Mood) استفاده می‌شود (مثلاً «Add feature» یا «Fix bug» به جای «Added feature» یا «Fixed bug»). حذف نقطه در پایان خط موضوع به تقویت این قرارداد کمک می‌کند و خطوط موضوع را مختصر نگه می‌دارد.

git commit -v -m "Create the Cart Feature with a Nice Animation"

قانون چهارم: بین خط و بدنه پیام یک خط خالی بگذارید

شاید این قانون در نگاه اول عجیب به نظر برسد، اما دلیل عملی و کاربردی پشت آن وجود دارد. بسیاری از توسعه‌دهندگان از رابط‌های خط فرمان (Command-Line) برای کار با Git استفاده می‌کنند، که معمولاً قابلیت خودکار برای شکستن خطوط متن (Word Wrapping) ندارند. به همین دلیل، قوانین فرمت‌دهی خاصی ایجاد شده‌اند تا پیام‌های کامیت به شکلی یکسان و خوانا نمایش داده شوند.

با قرار دادن یک خط خالی بین خط موضوع و بدنه پیام، می‌توانید اطمینان حاصل کنید که پیام‌های کامیت به درستی نمایش داده می‌شوند و خواندن آن‌ها برای دیگران (و حتی خودتان در آینده) آسان‌تر می‌شود.

git commit -v -m "Create the Cart Feature with a Nice Animation
Body...

قانون پنجم: متن بدنه پیام را در 72 کاراکتر بشکنید

رعایت این قانون به معنای شکستن خودکار کلمات (Word Wrapping) نیست، بلکه به این دلیل است که کاربران خط فرمان (Command-Line) ممکن است متن‌های طولانی‌تر از ۷۲ کاراکتر را به صورت ناقص مشاهده کنند.

در بیشتر مواقع، پیام‌های کامیت طولانی‌تر از ۷۲ کاراکتر خواهند بود. در چنین مواردی، بهتر است متن را در ۷۲ کاراکتر بشکنید و جمله را در خط بعدی ادامه دهید، همان‌طور که در مثال زیر نشان داده شده است:

git commit -v -m "Create the Cart Feature with a Nice Animation 
Enhanced the CSS layout of the cart section, addressing text 
alignment issues and refining the layout for improved aesthetics 
and readability."

📍بیشتر بخوانید: Gitea چیست؟ میزبانی بدون دردسر سورس کد سازمانی

قانون ششم: از حالت امری Imperative Mood استفاده کنید

یک روش ارزشمند برای نوشتن پیام‌های کامیت این است که آن‌ها را به گونه‌ای بنویسید که گویی کامیت، پس از اعمال، یک اقدام خاص را انجام می‌دهد. به عبارت دیگر، پیام کامیت باید جمله «اگر این کامیت اعمال شود، …» را به طور منطقی کامل کند.

برای مثال، به جای این:
git commit -m "Fixed the bug on the layout page"

از این استفاده کنید:
git commit -m "Fix the bug on the layout page"

در واقع، اگر این کامیت اعمال شود، باگ صفحه چیدمان را رفع می‌کند.

قانون هفتم: توضیح دهید چه و چرا، اما نه چگونه

پیام‌های کامیت باید بر روی «چه چیزی تغییر کرده» و «چرا این تغییر انجام شده» تمرکز کنند، نه روی «چگونه این تغییر پیاده‌سازی شده است». توسعه‌دهندگانی که می‌خواهند بدانند کد چگونه نوشته شده، می‌توانند مستقیماً به کد مراجعه کنند.

در عوض، بهتر است توضیح دهید:

چرا این تغییر انجام شده است؟ (مثلاً «برای بهبود تجربه کاربری و جلوگیری از نمایش نادرست عناصر»)

چه چیزی تغییر کرده است؟ (مثلاً «رفع باگ در صفحه چیدمان»)

نکته: برای نشان‌دادن موارد لیست‌شده (Bullet Points)، از خط تیره (-) یا ستاره (*) به همراه یک فاصله استفاده کنید. همچنین، برای بهبود خوانایی، از تورفتگی (Hanging Indent) استفاده کنید.

روش‌های Angular برای نوشتن پیام‌های کامیت

Angular یکی از نمونه‌های برجسته در استفاده از روش‌های مؤثر برای نوشتن پیام‌های کامیت است. تیم Angular استفاده از پیشوندهای خاصی را برای ساختاردهی به پیام‌های کامیت توصیه می‌کند. این پیشوندها شامل موارد زیر هستند:

chore: برای تغییرات کوچک و کارهای جانبی
docs: برای تغییرات مربوط به مستندات
style: برای تغییرات مرتبط با استایل‌ها (بدون تأثیر روی منطق کد)
feat: برای اضافه کردن ویژگی‌های جدید
fix: برای رفع باگ‌ها
refactor: برای بازنویسی یا بهبود کد بدون تغییر رفتار آن
test: برای اضافه کردن یا تغییر تست‌ها

با استفاده از این پیشوندها، تاریخچه کامیت‌ها به یک منبع ارزشمند تبدیل می‌شود که به راحتی می‌تواند ماهیت هر تغییر را توضیح دهد.

نکات کلیدی

ارتباط واضح و معنادار: پیام‌های کامیت باید داستانی را روایت کنند که «چه چیزی» تغییر کرده و «چرا» این تغییر انجام شده است. نیازی به توضیح «چگونگی» انجام تغییر نیست، زیرا این اطلاعات را می‌توان مستقیماً از کد استخراج کرد.
تاریخچه کامیت به عنوان یک منبع مشترک: تاریخچه کامیت‌ها نه‌تنها برای دیگر اعضای تیم، بلکه برای خود شما در آینده نیز مفید خواهد بود. بنابراین، سعی کنید پیام‌هایی بنویسید که اطلاعاتی مختصر، واضح و سازگار ارائه دهند.

علاقه‌مند به یادگیری بیشتر در مورد Git و تبدیل شدن به یک متخصص کنترل نسخه؟
می‌توانید از منابع آموزشی عالی در این زمینه استفاده کنید.

سوالات متداول:

در ادامه به سوالاتی که امکان دارد در این زمینه برای شما بدون پاسخ بماند، جواب‌های کوتاه اما مفیدی داده‌ایم که با استفاده از آن می‌توانید به سوال خود پاسخ صحیحی را بدهید.

چرا نوشتن پیام های کامیت واضح اهمیت زیادی دارد؟

پاسخ: پیام‌های کامیت واضح به دیگران (و خودتان در آینده) کمک می‌کنند تا تغییرات را به راحتی درک کنند و تاریخچه پروژه را بهتر دنبال کنند.

چگونه یک پیام کامیت خوب بنویسیم؟

پاسخ: از خط موضوع کوتاه (حداکثر ۵۰ کاراکتر) استفاده کنید، حالت امری به کار ببرید (مثلاً «Fix bug» به جای «Fixed bug»)، و توضیح دهید «چه» تغییر کرده و «چرا».

آیا باید از پیشوند ها در پیام های کامیت استفاده کنیم؟

پاسخ: بله، پیشوندهایی مانند feat: (برای ویژگی‌های جدید)، fix: (برای رفع باگ) و docs: (برای مستندات) به سازمان‌دهی تاریخچه کامیت‌ها کمک می‌کنند.

چرا باید خط موضوع و بدنه پیام کامیت را جدا کنیم؟

پاسخ: این کار باعث بهبود خوانایی پیام‌ها می‌شود، به ویژه برای کسانی که از رابط‌های خط فرمان استفاده می‌کنند.

آیا باید چگونگی انجام تغییرات را در پیام کامیت بنویسیم؟

پاسخ: خیر، فقط چه تغییر کرده و چرا را توضیح دهید. چگونگی را می‌توان از خود کد فهمید.

📍مطالعه بیشتر: مقایسه Git و GitHub

جمع بندی

نوشتن پیام‌های کامیت خوب، یکی از مهارت‌های کلیدی برای هر توسعه‌دهنده است. این پیام‌ها نه‌تنها به دیگران کمک می‌کنند تا تغییرات را درک کنند، بلکه برای خود شما در آینده نیز مفید خواهند بود. با رعایت قوانین ساده‌ای مانند استفاده از خط موضوع کوتاه، حالت امری، و توضیح «چه» و «چرا»، می‌توانید تاریخچه کامیت‌های خود را به یک منبع ارزشمند تبدیل کنید.

برچسب‌ها:commit git github گیت

تغییرات اخیر