نکته هایی درباره Git - قسمت اول

سلام به همه!
امروز می‌خواهم چند نکتهٔ کاربردی برای استفادهٔ مؤثرتر از Git با شما به اشتراک بگذارم. همان Git معروف که احتمالاً همین حالا هم با آن کار می‌کنید؛ همان یار همیشگی کدنویسی که همکاری در پروژه را برای ما مثل آب خوردن می‌کند.

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

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

• من بخش‌های مربوط به «قواعد نام‌گذاری شاخه‌ها» و «قواعد نوشتن پیام کامیت» را در سه سطح پایه، متوسط و پیشرفته دسته‌بندی کرده‌ام.

• می‌توانید تا هر سطحی که نیاز دارید پیش بروید، اما توصیه می‌کنم دست‌کم سطح متوسط را رعایت کنید تا بهترین نتیجه را بگیرید.

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

چرا باید استانداردها را رعایت کنیم؟

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

همکاری و کار تیمی: پیام‌های دقیق باعث می‌شوند همهٔ اعضای تیم روی یک خط باشند و کار گروهی روان‌تر پیش برود.

سهولت پیمایش و نگهداشت: رعایت استانداردها جابه‌جایی در کد و نگهداری پروژه را راحت‌تر و کم‌دردسرتر می‌کند.

مستندسازی و انتقال دانش: یک پیام کامیت خوب مثل یک یادداشت کوچک است که تازه‌واردها را سریع با تاریخچهٔ پروژه آشنا می‌کند.

کیفیت پروژه: شیوه‌های یکپارچه باعث می‌شود کیفیت و پایداری پروژه بالاتر برود.

گزارش تغییرات خودکار: با رعایت الگوها، می‌توانید گزارش تغییرات (Changelog) را به‌صورت خودکار تولید کنید و کار مدیریت انتشار را ساده کنید.

بهینه‌سازی CI/CD: پیام‌های روشن می‌توانند فرایندهای «یکپارچه‌سازی» و «استقرار مداوم» را بهبود دهند و زمینهٔ لازم برای ابزارهای خودکار را فراهم کنند.

اشکال‌زدایی و حل مشکلات: وقتی مشکل پیش می‌آید، پیام‌های استاندارد کمک می‌کنند سریع علت پیدا شود و رفع اشکال آسان‌تر شود.

مسئولیت‌پذیری: پیام شفاف مشخص می‌کند چه کسی چه تغییری داده و چرا، و این یک لایهٔ مسئولیت‌پذیری به پروژه اضافه می‌کند.

یکپارچگی بین پروژه‌ها: رعایت الگوهای ثابت باعث می‌شود جابه‌جایی بین پروژه‌ها آسان باشد و تاریخچهٔ آنها سریع درک شود.

قواعد نام‌گذاری شاخه‌ها (Branch Naming Conventions)

نام‌های توصیفی: یک شاخه با نام درست و دقیق، فوراً هدف خود را به مخاطب منتقل می‌کند. به‌جای نام‌های کلی و مبهم، نامی انتخاب کنید که شفافیت داشته باشد.

مثال:

feature/login
bugfix/navbar-overflow

استفاده از خط تیره (Hyphen): برای جدا کردن کلمات در نام شاخه‌ها از خط تیره استفاده کنید (فرمت kebab-case). این کار خوانایی را افزایش می‌دهد.

مثال:

bugfix/fix-login-issue

این روش بسیار خواناتر از نمونه‌های زیر است:

bugfix/fixLoginIssue
bugfix/fix_login_issue

حروف کوچک و کاراکترهای الفبایی-عددی: تنها از حروف کوچک انگلیسی (a-z)، اعداد (0-9) و خط تیره استفاده کنید. از نشانه‌گذاری‌ها، فاصله، آندرلاین یا کاراکترهای خاص تا حد امکان پرهیز کنید.

پرهیز از خط تیرهٔ اضافی: خط تیره‌های پشت‌سرهم یا در ابتدا/انتهای نام شاخه، غیرضروری و نادرست‌اند.

مثال بد:

feat/new--login--

کوتاه و مؤثر: نام شاخه باید ساده و در عین حال گویا باشد؛ به‌گونه‌ای که هدف آن با یک نگاه مشخص شود.

پیش‌وند یا نوع شاخه‌ها (Prefix or Type)

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

در ادامه، پیش‌وندهای رایج شاخه‌ها و کاربرد هر یک آمده است:

• feature/: برای توسعه قابلیت‌های جدید.
  مثال:

feature/new-dashboard  
feature/user-profile-page  
feature/new-feature  

• bugfix/: برای رفع اشکالات کد که معمولاً به یک issue مرتبط هستند.
  مثال:

bugfix/login-error  
bugfix/incorrect-calculation  

• hotfix/: برای رفع فوری و حیاتی اشکالات در محیط تولید (Production).
  مثال:

hotfix/memory-leak  
hotfix/urgent-security-patch  

• release/: برای آماده‌سازی نسخه‌های جدید، معمولاً برای اصلاحات نهایی و بازبینی‌ها.
  مثال:

release/version-1.0.0  
release/2.1.0-final  

• docs/: برای نوشتن، ویرایش یا اصلاح مستندات.
  مثال:

docs/update-api-docs  
docs/installation-guide  

• chore/: برای وظایف روزمره و نگهداری که عملکرد کد را تغییر نمی‌دهند، مانند به‌روزرسانی وابستگی‌ها.
  مثال:

chore/dependency-update  
chore/refactor-build-scripts  
chore/update-dependencies  

• test/: برای افزودن یا به‌روزرسانی تست‌ها.
  مثال:

test/add-unit-tests  
test/fix-integration-tests  

• style/: برای تغییراتی که عملکرد کد را تحت تأثیر قرار نمی‌دهند ولی قالب‌بندی و استایل کد را بهبود می‌بخشند، مثل اصلاح تورفتگی‌ها یا قواعد نگارشی.
  مثال:

style/code-cleanup  
style/fix-indentation  

• perf/: برای بهبودهای عملکردی.
  مثال:

perf/optimize-loading-time  
perf/reduce-memory-usage  

• revert/: برای بازگرداندن تغییرات قبلی.
  مثال:

revert/feature-branch-name  
revert/hotfix-issue-123  

• refactor/: برای بازسازی کد بدون تغییر عملکرد، با هدف بهبود ساختار یا خوانایی.
  مثال:

refactor/optimize-helpers  

• experiment/: برای قابلیت‌ها یا تغییرات آزمایشی که هنوز در مرحله تست هستند.
  مثال:

experiment/new-algorithm-test  

• build/: برای تغییرات در فرایند ساخت یا پیکربندی پروژه.
  مثال:

build/update-webpack-config  

افزودن شماره تیکت‌ها

اگر پروژهٔ شما از سیستم‌های پیگیری مسائل مانند Jira، GitHub Issues یا ابزارهای مشابه استفاده می‌کند، بهتر است شماره تیکت مربوطه را در نام شاخه وارد کنید. این کار دنبال کردن و ارجاع به تسک‌های مرتبط را ساده‌تر می‌کند.

مثال:

feature/PROJ-123-footer-links

نتیجه گیری

رعایت یک الگوی ثابت برای نام‌گذاری شاخه‌ها باعث می‌شود همه اعضای تیم به‌سرعت هدف هر شاخه را بفهمند و روند توسعه روان‌تر شود. همچنین، این کار یکپارچگی با فرایندهای CI/CD و ابزارهای خودکار را آسان‌تر کرده و به نگهداری یک مخزن مرتب و سازمان‌یافته کمک می‌کند.

پایان قسمت اول ...

با افتخار ترجمه شده از

https://substack.com/home/post/p-146876210?utm_campaign=post&utm_medium=web