سلام دوستان، در این مطلب قصد دارم به چند روش بهتر برای استفاده از گیت به صورت موثرتر بپردازم. گیت؟ بله، همان گیتی که قبلاً با آن آشنا هستید.
آیا شما یکی از آن دسته افراد هستید که برنچ ایجاد می‌کنند و سپس فراموش می‌کنند چرا وجود دارند؟ آیا همیشه باید به دنبال تغییرات فایل بگردید تا یک Commit را درک کنید؟ در ادامه چند نکته به شما خواهم گفت.
چرا باید استانداردها را دنبال کنم؟
1. وضوح و درک
2. همکاری و تیم‌کاری
3. راحتی در ناوبری و نگهداری
4. مستندسازی و انتقال دانش
5. کیفیت پروژه
6. لیست تغییرات خودکار
7. بهینه‌سازی CI/CD
پیش از مطالعه
هر زیربخش زیر عنوان‌های "اصول نام‌گذاری برنچ" و "اصول پیام Commit" به ترتیب به عنوان قواعد پایه، میانی و پیشرفته مرتب شده‌اند.
شما می‌توانید به هر سطح قوانین بر اساس مورد استفاده و ارتباط مناسب دنبال کنید؛ با این حال پیشنهاد می‌شود که تا سطح قوانین میانی پیش بروید.
اصول نام‌گذاری شاخه
1. نام‌های توصیفی: یک شاخه با نام مناسب، مفهومی فوری از هدف آن را ارائه می‌دهد. به جای نام‌های عمومی، انتخاب کنید.
feature/login
bugfix/navbar-overflow
2. استفاده از خط تیره: از خط تیره برای جدا کردن کلمات (یا kebab case) در نام شاخه استفاده کنید، این باعث خوانایی می‌شود.
bugfix/fix-login-issue
3. کاراکترهای الفبایی کوچک عددی:فقط از کاراکترهای الفبایی کوچک (a-z، 0-9) و خط تیره استفاده کنید. از علائم نگارشی، فاصله، آندرلاین، یا هر کاراکتر ویژه دیگری هنگام ممکن اجتناب کنید.
4. اجتناب از خطوط خطازی غیرضروری:از خطوط غیرضروری مثل خطوط پشت سر هم یا پایانی اجتناب کنید.
feat/new--login
5. کوتاه و موثر: نام‌های شاخه را ساده نگه دارید. هر چند توصیفی باشند، باید کافی مختصر باشند تا هدف را به یک نگاه درک کنید.
پیشوند یا نوع
پیشوند دادن به شاخه‌ها کمک می‌کند تا بر اساس هدف آنها سازماندهی شوند. این نه تنها وضوح را افزایش می‌دهد بلکه به اتوماسیون جریان‌های کاری کمک می‌کند.
برخی از پیشوندهای رایج نوع شاخه و کاربردهای آنها عبارتند از:
- feature/:برای توسعه ویژگی‌های جدید.
- bugfix/: برای رفع اشکالات در کد. اغلب به همراه یک مسئله ایجاد می‌شود.
- hotfix/:
برای رفع اشکالات حیاتی در محصول.
- release/: برای آماده‌سازی یک نسخه جدید، معمولاً برای انجام وظایفی مانند لمس‌های آخر و بازبینی‌ها.
- docs/:برای نوشتن، اصلاح یا اصلاح مستندات.
شامل شماره تیکت
اگر پروژه شما از یک سیستم پیگیری issue مانند Jira استفاده می‌کند یا اگر بر اساس issue
GitHub یا یک ابزار مشابه دیگر بازبینی می‌شود، اضافه کردن توکن مسئله به نام شاخه امکان پیگیری آن را آسان می‌کند. مثال: feature/PROJ-123-footer-links
متن کامیت ها
<type>([optional scope]): <description> # subject [optional body] [optional footer(s)]
کامیت‌ها رو با لحن دستوری بسازید.
برای نشون دادن کار کامیت با یه فعل شروع کنید.
مثال: به جای "fix: Fixed bug #67" از "fix: Fix bug #67" استفاده کنید.
سعی کنید موضوع رو زیر 50 کاراکتر جا بدید تا تو ابزارهای مختلف گیت، مثل git log --oneline، خوانا باشه. نقطه انتهایی و کلمات/симبل های اضافه رو حذف کنید.
خیلی ساده، موضوع رو با حرف بزرگ شروع کنید
یک پیشوند "نوع" در موضوع میتونه نوع تغییرات داخل کامیت رو نشون بده. بعضی از انواع رایج عبارتند از:
feat:: برای خلاصه سازی یه قابلیت جدید در کد.fix:: برای نشون دادن رفع یه باگ.build:, chore:, ci:, style:, refactor:.میتونید با اضافه کردن یه "اسکوپ" داخل پرانتز به نوع کامیت، اطلاعات زمینه‌ای بیشتری بدید. مثلا:
feat(parser): Add the ability to parse arrays.
میتونید با گذاشتن یه خط خالی بعد از موضوع، یه "بدنه" به پیام اضافه کنید تا توضیحات بیشتری بدید.
بدنه رو به چند خط تقسیم کنید که هر کدوم از 72 کاراکتر رو رد نکنه.
یک پاورقی برای انتقال اطلاعات اضافی مربوط به کامیت، مانند بازبینی‌کننده، تأیید کننده و غیره، استفاده می‌شود. مثال:
Signed-off-by: Alice <alice@example.com>
تغییر اساسی (Breaking Change): تغییر اساسی به تغییرات نسبتاً مهمی در کد اشاره می‌کند که می‌تواند با اضافه کردن علامت "!" بعد از نوع/محدوده یا اضافه کردن آن با بدن یا به عنوان پاورقی نشان داده شود.
chore!: drop support for Nod BREAKING CHANGE: use JavaScript features not available in Node 6
