Branch در Git چیست و چرا استفاده می‌شود؟

Branch در Git یک خط توسعهٔ موازی است: در عمل یک اشاره‌گر متحرک به یک Commit. وقتی Commit جدید می‌زنید، Branch جاری به آن Commit جدید اشاره می‌کند. کتاب Pro Git در «Branches in a Nutshell» تأکید می‌کند که Branch در Git بسیار سبک است — برخلاف تصور کپی کامل پوشه — و همین سبکی باعث می‌شود Branch زدن عادت روزانه باشد نه تشریفات سنگین.

هدف اصلی: آزمایش، فیچر، یا Fix را جدا از خط پایدار (معمولاً main یا master) پیش ببرید تا کار ناتمام، تاریخچهٔ اصلی را ناپایدار نکند. GitHub flow همین ایده را به جریان PR وصل می‌کند: Branch بساز، Commit کن، Review بگیر، Merge کن.

مقالهٔ ۰۷۷ Merge را می‌گوید؛ اینجا خود Branch و چرایی آن است.

پاسخ کوتاه

Branch یعنی مسیر جدا برای Commitها. پیش‌فرض بعد از init/clone معمولاً یک Branch اصلی دارید. برای کار جدید، Branch تازه می‌سازید، روی آن Checkout/Switch می‌کنید، Commit می‌زنید، و بعداً با Merge یا Pull Request به اصلی برمی‌گردانید. بدون Branch، همه روی یک خط می‌نویسند و ریسک شکستن نسخهٔ پایدار و Conflictهای درهم بالا می‌رود.

Branch قول می‌دهد: می‌توانم ایده را امتحان کنم بدون اینکه نسخهٔ مشترک تیم را گروگان بگیرم.

مدل ذهنی ساده

تاریخچهٔ Git یک گراف Commit است. Branch فقط برچسب روی یک گره است. ساخت Branch جدید در حد ساخت یک فایل ارجاع کوچک هزینه دارد. جابه‌جایی بین Branchها Working tree را به محتوای آن Commit می‌رساند (اگر تداخل Uncommitted نباشد).

bash

git branch git branch feature-cart git switch feature-cart # معادل قدیمی‌تر رایج: # git checkout -b feature-cart

دیدن Branchهای Remote:

bash

git branch -a

چرا استفاده می‌شود؟

1. جداسازی کار ناتمام از نسخهٔ قابل Deploy.
2. موازی‌کاری چند نفر روی یک مخزن بدون بازنویسی مداوم کار هم.
3. بازبینی: PR روی یک Branch مشخص diff واضحی می‌دهد.
4. آزمایش پرریسک (refactor بزرگ) با امکان رها کردن Branch.
5. انتشار کنترل‌شده: فقط بعد از Merge وارد main می‌شود.

حتی برای کار انفرادی، Branch جلوی «نصف فیچر روی main» را می‌گیرد و برگشت را ساده‌تر می‌کند.

نام‌گذاری و قراردادهای رایج

قرارداد تیم مهم‌تر از زیبایی نام است. نام باید در فهرست Branchها قابل اسکن باشد و به Issue وصل شود اگر سیستم تیکت دارید.

Branch محلی در برابر Remote

Branch محلی روی ماشین شماست. برای اشتراک، آن را Push می‌کنید تا روی origin ظاهر شود. remote-trackingهایی مثل origin/main عکس آخرین وضعیت دیده‌شده از Remoteاند و با Fetch به‌روز می‌شوند. گیج نشدن بین «من روی main محلی‌ام» و «main روی سرور جلوتر است» مهارت کلیدی است — status و branch -vv کمک می‌کنند.

ارتباط با GitHub flow

طبق GitHub Docs: از Branch برای به‌روزرسانی استفاده کنید، Commit ذخیره کنید، Pull Request برای بحث باز کنید، پس از توافق Merge کنید، و Branch ادغام‌شده را پاک کنید تا فهرست تمیز بماند. Protected Branch روی main معمولاً Push مستقیم را می‌بندد تا همه از مسیر Review بیایند.

اشتباه‌های رایج

• کار طولانی روی یک Branch غول بدون همگام‌سازی با main → Merge دردناک.
• چند موضوع بی‌ربط روی یک Branch → Review سخت.
• ماندن روی Detached HEAD بدون دانستن (Checkout روی hash خام).
• حذف Branch محلی در حالی که کار Pushنشده فقط آنجا بود.
• نام‌های مبهم مثل test و new.

برای مدیر محصول

«روی برنچ است» یعنی هنوز وارد خط اصلی نشده و ممکن است در Review یا Conflict بماند. تاریخ تحویل را به Merge شدن گره بزنید نه فقط به «کد نوشته شد». تعداد Branchهای باز قدیمی نشانهٔ کار نیمه‌تمام یا ترس از Merge است — موضوع مدیریتی است نه فقط فنی.

حداقل دستورات روزمره

bash

git switch main git pull git switch -c feature-xyz # ... edit, add, commit ... git push -u origin feature-xyz

همین کافی است تا وارد جریان مدرن شوید؛ استراتژی‌های پیچیده‌تر (Git Flow کلاسیک و غیره) فقط وقتی درد واقعی مقیاس دارید لازم می‌شوند.

جمع‌بندی

Branch اشاره‌گر سبک به Commit است که خط موازی کار می‌سازد. استفاده از آن برای جداسازی ریسک، موازی‌کاری و Review است. نام روشن، عمر کوتاه، و همگام‌سازی منظم با پایه، Branch را از آشوب نجات می‌دهد. قدم بعد: فهم Merge و Conflict.

عمر Branch و هزینهٔ Merge

هرچه Branch بیشتر از main دور بماند، احتمال Conflict و فراموشی زمینه بیشتر می‌شود. تیم‌های پربازده معمولاً Branchهای یک تا چند روزه دارند نه ماه‌بلند. اگر فیچر بزرگ است، آن را به تکه‌های قابل Merge بشکنید یا با feature flag ادغام تدریجی کنید.

همگام‌سازی منظم: هر روز یا حداقل چندبار در هفته main را در Branch خود Merge/Rebase کنید تا درد پایان کار کمتر شود.

Protected branch و سیاست‌ها

روی هاست می‌توانید Push مستقیم به main را ببندید، Review اجباری کنید، و وضعیت CI سبز بخواهید. این سیاست‌ها Branch را از «پیشنهاد اختیاری» به «مسیر اجباری کیفیت» تبدیل می‌کنند. بدون سیاست، حتی بهترین آموزش Branch در فشار زمان دور زده می‌شود.

برای تیم دو نفره هم Protection سبک مفید است؛ نه به‌خاطر بوروکراسی، به‌خاطر جلوگیری از اشتباه نیمه‌شب.

Branch و محیط‌ها

بعضی سازمان‌ها Branch را با محیط یکی می‌گیرند (مثلاً develop→Staging). این مدل کار می‌کند ولی می‌تواند طولانی و سنگین شود. مدل ساده‌تر GitHub flow: main پایدار، فیچرها کوتاه، Deploy از main یا Tag. انتخاب را با اندازهٔ تیم و نیاز Release هم‌تراز کنید؛ کپی کور Git Flow کلاسیک برای استارتاپ سه‌نفره اغلب زیاد است.

مهم: نام Branch جایگزین Environment واقعی و config جدا نیست. مقالهٔ ۰۴۸ را برای محیط‌ها ببینید.

پاکسازی Branchها

• بعد از Merge، Branch Remote را حذف کنید (دکمه در UI یا فرمان Push حذف).
• محلی هم پاک کنید تا switch اشتباه نروید.
• Branchهای رهاشدهٔ قدیمی را دوره‌ای مرور کنید: یا تمامش کنید یا صریح archive/حذف.
• قبل از حذف، مطمئن شوید کار Pushنشده ندارید.

Detached HEAD به زبان ساده

وقتی مستقیم روی یک Commit (نه Branch) Checkout کنید، در وضعیت Detached HEAD هستید. Commitهای جدید ممکن است گم‌شده به نظر برسند مگر Branch از آن‌ها بسازید. برای کار روزمره روی نام Branch بمانید؛ سراغ Checkout هش فقط برای کاوش بروید.

bash

git switch -c recover-work

شاخص‌های سلامت Branching در تیم

1. تعداد Branchهای باز قدیمی‌تر از N روز.
2. متوسط زمان از اولین Commit تا Merge.
3. درصد Merge بدون Conflict شدید.
4. تعداد Push مستقیم به main (باید نزدیک صفر باشد اگر ممنوع است).

این شاخص‌ها را بدون ابزار پیچیده هم می‌توان دستی شمرد. بهبودشان معمولاً با آموزش و قوانین کوچک است نه با خرید ابزار جدید.

استراتژی‌های نام‌دار — چه وقت پیچیدگی بخریم؟

Git Flow کلاسیک (feature/develop/release/hotfix) برای تیم‌های با چند نسخهٔ موازی و Release سنگین طراحی شد. GitHub flow ساده‌تر است و برای تحویل پیوسته مناسب‌تر. Trunk-based با Branchهای بسیار کوتاه و feature flag هم خانوادهٔ دیگری است.

اشتباه رایج: کپی Git Flow کامل برای سه نفر بدون نیاز Release موازی. پیچیدگی Branch باید با پیچیدگی انتشار هم‌خوان باشد. اول ساده شروع کنید؛ وقتی درد واقعی دیدید شاخه اضافه کنید.

Branch و Code Ownership

Branch جایگزین مالکیت کد نیست. اگر همه روی فایل یکسان Branchهای بلند بسازند، Conflict ساختاری است. تقسیم کار، ماژولار بودن، و قرارداد API گاهی مهم‌تر از نام Branch است. Branch درد را کم می‌کند نه معماری بد را.

در Review، به مرز Branch نگاه کنید: آیا این Branch یک داستان کاربر را تمام می‌کند یا تکه‌ای ناتمام است که main را ناپایدار می‌کند؟

ابزار دیداری برای فهم Branch

bash

git log --oneline --graph --decorate --all

این فرمان گراف ساده در ترمینال می‌سازد. UIهای GitHub و IDE همان گراف را زیباتر نشان می‌دهند. یک‌بار گراف را برای تیم روی پروژکتور توضیح دهید؛ فهم مشترک از واگرایی، نصف تعارض‌های مفهومی را کم می‌کند.

Diagram پیشنهادی همین مقاله را در مستندات داخلی‌تان هم بکشید: main افقی، feature کوتاه، Merge برگشتی.

Branch در کار فردی عمیق

حتی تنها، برای آزمایش کتابخانهٔ جدید Branch بسازید. اگر entourage شد، دور بیندازید؛ اگر خوب بود Merge کنید. این عادت ترس از خراب کردن را کم می‌کند و بایگانی آزمایش‌ها را تمیز نگه می‌دارد.

برای بازنویسی بزرگ، Branch بلند اجتناب‌ناپذیر می‌شود؛ آن را با Mergeهای میانی از main زنده نگه دارید و در صورت امکان پشت feature flag Merge کنید.

خطاهای انسانی و بازیابی

• Commit روی main به‌جای feature: می‌توان از HEAD Branch جدید ساخت و main را به عقب برگرداند — با احتیاط اگر Push شده.
• حذف اشتباه Branch محلی: اگر Commitها هنوز در reflog باشند قابل بازیابی‌اند.
• هم‌نامی Branch محلی و مفهومی متفاوت Remote: با branch -vv وضعیت را ببینید.

reflog دوست شماست، ولی تا ابد نگه نمی‌دارد. مهم‌ترین بیمه همچنان Push منظم به Remote است.

Branch و انتشار تدریجی محصول

گاهی محصول نمی‌تواند منتظر اتمام کامل یک فیچر بزرگ بماند. الگوی سالم: شکستن به Branchهای کوچک قابل Merge، یا Merge پشت feature flag تا کد در main باشد ولی برای کاربر خاموش. این کار عمر Branch را کوتاه و ریسک Merge را کم می‌کند.

Product Owner باید بداند «Merge شده» با «برای کاربر فعال است» یکی نیست اگر flag خاموش باشد. واژگان را در تیم یکی کنید تا وضعیت اسپرینت گمراه‌کننده نباشد.

برای هات‌فیکس Production، Branch کوتاه از تگ/Commit منتشرشده بسازید، Fix را بزنید، با مسیر اضطراری ولی همچنان Review سریع Merge کنید، و بعد به main برگردانید تا واگرایی نماند.

سند یک‌صفحه‌ای «چه Branchهایی داریم و عمر مجازشان چیست» از ده‌ها بحث تکراری جلوگیری می‌کند.

جدول تصمیم: روی کدام Branch کار کنم؟

اگر نمی‌دانید کدام ردیفید، اول main را به‌روز کنید و یک feature بسازید. انتخاب غلط Branch معمولاً قابل جبران است؛ کار بدون Branch روی main مشترک کمتر بخشیده می‌شود.

نام Branch را با شمارهٔ تیکت پیوند بدهید تا در گزارش‌ها ردیابی شود. این کار کوچک برای PMO و پشتیبانی طلاست.

Branch به‌عنوان واحد گفتگو نه فقط واحد کد

هر Branch باز یک موضوع باز در ذهن تیم است. زیاد بودن Branchهای کهنه مثل زیاد بودن جلسهٔ نیمه‌تمام است: توجه را خرد می‌کند. محدود کردن WIP در سطح Branch (مثلاً بیش از N Branch فعال برای هر نفر) به تمرکز کمک می‌کند.

در گزارش به ذی‌نفع، به‌جای فهرست Branchها، فهرست PRها و وضعیت Merge را نشان دهید. Branch جزئیات پیاده‌سازی است؛ PR واحد تصمیم محصولی-فنی است.

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

در یک جمله: Branch ارزان ساخته می‌شود؛ گران مدیریت‌نشده می‌ماند. ساختنش را آزاد، نگهداشتنش را منضبط کنید.

حالا که خط موازی را فهمیدید، مقالهٔ Merge نشان می‌دهد چطور دوباره به یک خط امن برگردید.

یادداشت پایانی Branch

Branch را زود بسازید، کوتاه نگه دارید، زیاد همگام کنید، و بعد از Merge پاک کنید. اگر این چهار فعل عادت شود، نیازی به چارچوب پیچیده ندارید. وقتی انتشار چندنسخه‌ای یا تیم‌های متعدد واقعاً درد ساخت، آن‌وقت استراتژی نام‌دار را با آگاهی انتخاب کنید — نه از روی مد.

برای ادامه، Merge را تمرین کنید تا برگشت به main بدون ترس باشد؛ سپس PR را به‌عنوان لایهٔ گفتگو روی همین Branch ببینید.

این انضباط کوچک همان چیزی است که Branch را از فهرست شلوغ نام‌ها به ابزار تصمیم روزانه تبدیل می‌کند.

منابع و مراجع

• Pro Git — Branches in a Nutshell — https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
• Pro Git — Basic Branching and Merging — https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
• git-branch documentation — https://git-scm.com/docs/git-branch
• GitHub Docs — GitHub flow — https://docs.github.com/en/get-started/using-github/github-flow
• GitHub Docs — About Git — https://docs.github.com/en/get-started/using-git/about-git