Main و Master Branch در Git: چیست و چرا به شاخه اصلی نیاز داریم

Main / Master Branch در Git چیست

Main Branch (یا Master — بسته به تنظیمات مخزن) — شاخه پیش‌فرضی است که هنگام مقداردهی اولیه هر مخزن Git ایجاد می‌شود. این شاخه اصلی پروژه است و کد آماده برای استقرار در تولید را شامل می‌شود.

برخلاف develop که کار روزانه با ویژگی‌های جدید در آن جریان دارد، main ویترین پروژه است. هر نسخه از کد در main یک چرخه کامل را طی کرده است: توسعه در شاخه feature، ادغام در develop، آماده‌سازی انتشار در شاخه release و آزمایش نهایی. فقط پس از آن تغییرات وارد main می‌شوند.

اصل کلیدی: main همیشه باید پایدار باشد. اگر خطایی در main کشف شود، به معنای hotfix فوری است که باید خارج از نوبت منتشر شود. بنابراین در پروژه‌های حرفه‌ای، main با قوانین محافظت از شاخه (branch protection rules) از تغییرات تصادفی محافظت می‌شود.

به گفته Git Book, main یک شاخه خاص با ویژگی‌های ویژه نیست، بلکه یک ارجاع معمولی به commit است که طبق قرارداد اصلی در نظر گرفته می‌شود. Git در سطح سیستم بین main و هر شاخه دیگری تفاوتی قائل نمی‌شود.

انتقال از master به main

از لحاظ تاریخی، شاخه پیش‌فرض در Git master نام داشت. در ژوئن 2020، جنبش Black Lives Matter توجه را به اصطلاحات master و slave در صنعت IT جلب کرد. GitHub انتقال به اصطلاح main را برای شاخه پیش‌فرض اعلام کرد.

از اکتبر 2020، تمام مخازن جدید در GitHub با شاخه main ایجاد می‌شوند. GitLab و Bitbucket نیز پشتیبانی از main را به عنوان نام پیش‌فرض پیاده‌سازی کردند. Git 2.28 (ژوئیه 2020) گزینه init.defaultBranch را برای تنظیم نام شاخه پیش‌فرض اضافه کرد.

از نظر فنی، تغییر نام شاخه موجود از master به main یک عملیات ساده است. مشکل اصلی به‌روزرسانی تمام ارجاعات در تنظیمات CI/CD، مستندات و مخازن محلی توسعه‌دهندگان است.

برای تغییر نام شاخه در مخزن موجود، اجرا کنید:

# تغییر نام محلی master به main
git branch -m master main

# به‌روزرسانی مخزن راه دور
git push -u origin main

# حذف master قدیمی روی سرور
git push origin --delete master

# به‌روزرسانی HEAD روی سرور
# (از طریق رابط وب GitHub: Settings → Branches → Default branch)

نقش main در Git Flow و GitHub Flow

Git Flow و GitHub Flow نقش شاخه main را متفاوت تعریف می‌کنند. انتخاب مدل به اندازه تیم، دفعات انتشار و الزامات پایداری کد بستگی دارد.

برای توسعه موبایل، استاندارد Git Flow است، زیرا انتشار اپلیکیشن در App Store و Google Play چرخه‌های انتشار ثابتی دارد. GitHub Flow بیشتر برای پروژه‌های وب با امکان استقرار چند بار در روز مناسب است.

GitHub Flow — رویکرد ساده‌شده

در GitHub Flow شاخه develop وجود ندارد. تمام شاخه‌های feature مستقیماً از main ایجاد می‌شوند و پس از اتمام از طریق Pull Request به آن ادغام می‌شوند. هر ادغام در main به طور خودکار استقرار در تولید را آغاز می‌کند. این مدل نیاز به اتوماسیون بالای تست و انضباط تیمی دارد.

در GitHub Flow شاخه develop وجود ندارد. تمام شاخه‌های feature مستقیماً از main ایجاد می‌شوند و پس از اتمام از طریق Pull Request به آن ادغام می‌شوند. هر ادغام در main به طور خودکار استقرار در تولید را آغاز می‌کند. این مدل نیاز به اتوماسیون بالای تست و انضباط تیمی دارد.

محافظت از شاخه main

Branch protection برای main — یک تنظیم اجباری در هر پروژه تجاری است. بدون آن، یک push تصادفی می‌تواند کد ناقص را به تولید بفرستد یا اپلیکیشن در حال کار را برای همه کاربران خراب کند.

• Require pull request — push مستقیم به main ممنوع است. همه تغییرات از طریق PR با بازبینی.
• Require approvals — حداقل 2 تأیید برای ادغام در main (در صورت خطای یک بازبین).
• Require status checks — تمام بررسی‌های CI/CD باید قبل از ادغام موفق باشند.
• Require up-to-date — PR باید بر اساس آخرین commit main باشد.
• Include administrators — محافظت حتی برای صاحبان مخزن اعمال می‌شود.
• Require signed commits — تمام commit‌ها در main باید با کلید GPG امضا شوند.

تنظیم هر شش قانون — استانداردی برای پروژه‌های موبایل با مخاطبان ۱۰,۰۰۰+ کاربر است. برای پروژه‌های کوچک، سه قانون اول کافی است.

مقایسه سطوح محافظت برای انواع پروژه‌ها

سطح محافظت main به مقیاس پروژه بستگی دارد. یک استارتاپ می‌تواند با حداقل محافظت کار کند، در حالی که اپلیکیشن enterprise به حداکثر محدودیت‌ها نیاز دارد.

انتشارات و برچسب‌ها در main

برچسب‌زنی (tagging) — عملی ایجاد ارجاعات نام‌گذاری شده به commit‌های خاص در main است. هر برچسب با نسخه اپلیکیشن منتشرشده به تولید مطابقت دارد. این امکان را فراهم می‌کند که به سرعت به هر انتشار قبلی برای اشکال‌زدایی یا Patch切换 کنید.

استاندارد نام‌گذاری برچسب‌ها در توسعه موبایل — SemVer (Semantic Versioning): v1.2.3، که شماره اول نسخه اصلی (breaking changes)، دوم — نسخه فرعی (ویژگی‌های جدید)، سوم — patch (رفع اشکال) است.

برچسب پس از ادغام شاخه release در main ایجاد می‌شود. این commit سپس در CI/CD ساخته می‌شود، امضا می‌شود و به فروشگاه اپلیکیشن ارسال می‌شود. اگر در برچسب خطایی کشف شود، یک شاخه hotfix از آن برچسب ایجاد می‌شود.

# ایجاد برچسب انتشار حاشیه‌نویسی شده
git tag -a v2.4.1 -m "Release version 2.4.1"

# ارسال برچسب به سرور
git push origin v2.4.1

# مشاهده تمام برچسب‌ها در مخزن
git tag -l "v2.*"

# ایجاد شاخه hotfix از برچسب خاص
git checkout -b hotfix/crash-fix v2.4.1

سلسله‌مراتب شاخه‌های Git Flow

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

• Main (سطح 1) — شاخه ریشه، فقط شامل نسخه‌های انتشار است. هنگام مقداردهی اولیه مخزن ایجاد می‌شود.
• Develop (سطح 2) — در شروع پروژه از main ایجاد می‌شود. شامل کد یکپارچه تمام ویژگی‌هاست.
• Feature (سطح 3) — از develop ایجاد می‌شود. توسعه ایزوله ویژگی‌های جداگانه.
• Release (سطح 2) — از develop ایجاد می‌شود. آماده‌سازی انتشار خاص برای عرضه.
• Hotfix (سطح 2) — از main ایجاد می‌شود. رفع فوری اشکالات بحرانی تولید.

قانون مهم: feature هرگز مستقیماً در main ادغام نمی‌شود. feature → develop → release → main — زنجیره صحیح ادغام است. نقض این قانون کل مدل Git Flow را بی‌معنی می‌کند.

نمونه دستورات کار با main

سناریو را در نظر بگیرید: تیم آماده‌سازی انتشار v2.5.0 را تکمیل کرده است. شاخه release بررسی و آماده ادغام در main است. پس از ادغام، برچسب ایجاد و انتشار منتشر می‌شود.

# تغییر به main و به‌روزرسانی
git checkout main
git pull origin main

# ادغام شاخه release تأیید شده
git merge --no-ff release/2.5.0

# ایجاد برچسب انتشار
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# ارسال main و برچسب به سرور
git push origin main --tags

پرچم --no-ff (no fast-forward) ایجاد commit ادغام را تضمین می‌کند، حتی اگر ادغام می‌توانست با جابجایی ساده اشاره‌گر انجام شود. این اطلاعات را حفظ می‌کند که تغییرات از شاخه release آمده‌اند، که تحلیل تاریخچه را ساده‌تر می‌کند.

کار با hotfix از طریق main

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

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

# ایجاد شاخه hotfix از main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# رفع اشکال و commit
git add src/fix/
git commit -m "Fix crash on login screen"

# ادغام hotfix به main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# ادغام hotfix همچنین به develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# حذف شاخه hotfix
git branch -d hotfix/2.5.1-crash-fix