Git Branch چیست؟ خط موازی توسعه بدون کپی پروژه
Branch در Git فقط یک اشارهگر سبک به Commit است؛ چرا موازیکاری بدون کپی پوشه ممکن میشود، تفاوت local و remote-tracking، با Pro Git Branching.
بنیانگذار و مهندس محصول
مشکل کلاسیک قبل از Branch واقعی: برای آزمایش یک فیچر، کل پوشه را کپی میکردید و بعد نمیدانستید کدام تغییر را برگردانید. در Git، Branch در اساس یک اشارهگر متحرک سبک به یک Commit است (معمولاً زیر refs/heads/). Pro Git فصل Git Branching را با همین سبکی باز میکند: ساخت Branch تقریباً آنی است چون کپی کامل تاریخچه لازم نیست.
مقالهٔ ۰۷۶ معرفی اولیه بود؛ اینجا زاویهٔ مسئلهمحور است: Branch کدام درد همکاری را حل میکند، local با remote-tracking چه فرقی دارد، و سیاستهای رایج (trunk-based، Git Flow سادهشده) کجا میشکنند.
پاسخ کوتاه
Branch نامی است روی یک Commit؛ با هر Commit جدید روی آن Branch، اشارهگر جلو میرود. HEAD معمولاً میگوید الان روی کدام Branch هستید. ایجاد feature/login یعنی از یک نقطهٔ مشترک مسیر جدا برای کار، بدون دست زدن به main تا وقتی Merge یا Rebase کنید. روی Remote، Branchهای origin/* بازتاب وضعیت سرورند نه کپی جادویی جدا از مدل داده.
Branch مجوز آزمایش است: خراب کردن آزمایشی روی خط جدا ارزانتر از خراب کردن main است.
مدل ذهنی: گراف Commit + برچسب نام
تاریخچه یک گراف جهتدار از Commitهاست. Branch فقط برچسب روی یک گره است. پاک کردن Branch (اگر Commitها از جای دیگر قابل دسترس نباشند) ممکن است آن کار را «غیرقابلدسترس» کند — به همین دلیل قبل از حذف، Merge یا اطمینان از Push مهم است.
bash
git branch # لیست محلی git switch -c feature/x # ساخت و جابهجایی git branch -d feature/x # حذف امن اگر Merge شده
git switch و git restore در نسخههای جدیدتر نقش checkout را شفافتر کردهاند: switch برای Branch، restore برای فایل.
چه مسئلهای را در تیم حل میکند؟
- جداسازی کار ناتمام از خط پایدار (main/master).
- Review قبل از ورود به خط مشترک (همراه PR — ۲۰۸).
- امکان کار چند نفر روی یک مخزن بدون overwrite خام.
- آزمایش ریسکی (refactor بزرگ) با قابلیت دور انداختن Branch.
بدون Branch، یا همه مستقیم روی main مینویسند (تاریخچه شلوغ و خطرناک)، یا به کپی پوشه برمیگردند.
Local، Remote-tracking، Upstream
| نوع | مثال | نقش |
|---|---|---|
| Local branch | feature/x | جایی که Commit میزنید |
| Remote-tracking | origin/main | عکس آخرین Fetch از Remote |
| Upstream | feature/x → origin/feature/x | پیشفرض Push/Pull |
Fetch فقط remote-tracking را بهروز میکند؛ Branch محلی شما خودکار جلو نمیرود مگر Merge/Rebase/Pull. این جداسازی عمدی است تا کنترل داشته باشید.
سیاستهای رایج بدون تعصب
Trunk-based ساده
Branchهای کوتاهعمر، ادغام مکرر به main، تکیه به CI و Feature flag. مناسب تیمهایی با تست خوب.
Feature branch + PR
هر موضوع یک Branch و یک Pull Request. رایج روی GitHub. عمر Branch اگر زیاد شود، Conflict انباشته میشود — با بهروز کردن از main مدیریت کنید.
Release / hotfix
خطوط جدا برای تثبیت نسخه. مفید وقتی چند نسخهٔ پشتیبانیشده دارید؛ برای تیم کوچک ممکن است سنگین باشد.
هیچ الگوی واحدی «بهترین» نیست؛ معیار: طول عمر Branch، سرعت Review، و کیفیت main سبز.
نامگذاری و بهداشت
- نام معنادار: feature/…، fix/…، chore/… مطابق قرارداد تیم.
- Branch مرده را بعد از Merge حذف کنید تا لیست آلوده نشود.
- مستقیم Commit روی main را با Branch protection محدود کنید (۲۲۰).
- از Branchهای شخصی بلندمدت بدون همگامسازی با main بپرهیزید.
اشتباههای رایج
- کار طولانی روی Branch بدون Fetch/Merge از main — Conflict روز آخر.
- یکیگرفتن Branch با Fork؛ Fork کپی مخزن روی حساب دیگر است.
- حذف Branch Remote در حالی که همکار هنوز روی آن کار میکند.
- نامهای مبهم مثل test، new، asdf.
- Force push روی Branch مشترک بدون هماهنگی.
سناریو: فیچر بلندمدت در برابر همگامسازی
Branch سههفتهای بدون Merge از main معمولاً روز ادغام را جهنمی میکند. راهحلها: ادغام/rebase مکرر از main، شکستن فیچر به PRهای کوچکتر، یا Feature flag تا بتوان زودتر به main برگرداند. خودِ Branch مشکل نیست؛ عمر مدیریتنشده مشکل است.
شاخص هشدار: Conflictهای تکراری روی همان فایلها، یا ترس تیم از Merge کردن. در آن نقطه سیاست Branch را بازبینی کنید نه فقط مهارت فرد را.
HEAD detached یعنی چه؟
وقتی مستقیماً یک Commit را checkout میکنید بهجای Branch، در حالت detached HEAD هستید: میتوانید بازرسی کنید، ولی Commitهای جدید ممکن است بدون Branch بهراحتی گم شوند. برای کار روزمره روی نام Branch بمانید؛ detached را برای بازرسی تاریخچه یا ساخت Tag نگه دارید.
bash
git switch main git switch --detach v1.2.0 # بازرسی تگ git switch -c hotfix/from-tag # اگر باید کار کنید، Branch بسازید
Remote branch را چطور «ببینیم»؟
بعد از Fetch، origin/feature/x را میبینید ولی برای کار معمولاً Branch محلی با upstream میسازید:
bash
git fetch origin git switch feature/x # اگر tracking از قبل تنظیم شده # یا: git switch -c feature/x --track origin/feature/x
Upstream و وضعیت ahead/behind
git status -sb اغلب میگوید ahead 2, behind 1: یعنی دو Commit محلی دارید که Remote ندارد و Remote یک Commit دارد که شما Merge/Rebase نکردهاید. این اعداد نقشهٔ همگامسازیاند نه خطا.
bash
git status -sb git rev-list --left-right --count @{u}...HEAD
حذف امن Branch
git branch -d اگر Merge نشده باشد مقاومت میکند؛ -D اجباری است و خطرناکتر. روی Remote: git push origin --delete feature/x. قبل از حذف، مطمئن شوید کار در main یا جای دیگر محفوظ است.
Branch protection روی main حذف تصادفی خط پایدار را سخت میکند؛ برای Branchهای فیچر معمولاً حذف آزاد است.
مدل ذهنی برای لید فنی: هزینهٔ Branch باز
هر Branch باز یک تعهد ناتمام است: Conflict آینده، زمینهٔ ذهنی، و گاهی محیط Deploy جدا. لید خوب تعداد WIP را محدود میکند — نه با ممنوعیت Branch، بلکه با کوچک کردن دامنه و اتمام. داشبورد PRهای باز قدیمیتر از N روز سیگنال فرآیندی است.
در تیمهای trunk-based، Branchها ساعتی/روزی زندگی میکنند. در تیمهایی با Releaseهای سنگین، عمر طولانیتر با هزینهٔ همگامسازی پذیرفته میشود. عدد جادویی جهانی وجود ندارد؛ متریک عمر و نرخ Conflict را اندازه بگیرید.
Naming ضدالگو
- fix، fix2، final-fix بدون شماره Issue.
- نام شخصی فقط (ali) بدون موضوع.
- کپی نام فایل یا «asdf».
- استفاده از کاراکترها و فاصلههای دردسرساز در شِل.
قرارداد ساده بهتر از قرارداد پیچیدهٔ اجرانشده است. در README یا CONTRIBUTING سه پیشوند مجاز بنویسید و همان را نگه دارید.
سوالات متداول
چند Branch همزمان طبیعی است؟
به تعداد کارهای موازی فعال بستگی دارد. ده Branch نیمهکاره معمولاً بوی WIP بیصاحب میدهد.
main یا master؟
نام پیشفرض قرارداد است؛ بسیاری مخازن به main مهاجرت کردهاند. مهم ثبات در تیم و تنظیم origin است.
آیا Branch فضای دیسک زیاد میگیرد؟
خود اشارهگر ناچیز است؛ Commitهای جدید محتوا اضافه میکنند — مثل هر تاریخچه. کپی کامل پروژه نیست.
خلاصه
Branch اشارهگر سبک روی Commit است که خط موازی توسعه میسازد. مسئلهٔ اصلیاش جدا کردن آزمایش و کار ناتمام از خط پایدار و فراهم کردن بستر Review است. سیاست نامگذاری، عمر کوتاه، و همگامسازی با main هزینهٔ Conflict را پایین میآورد.
بعدی: Merge چطور خطوط را به هم وصل میکند (۲۰۶) و وقتی خودکار نمیشود چه میشود (۲۰۷).
منابع و مراجع
- Pro Git — Git Branching — https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
- git-branch documentation — https://git-scm.com/docs/git-branch
- git-switch documentation — https://git-scm.com/docs/git-switch
- GitHub Docs — About branches — https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches
- GitHub Docs — Managing branches — https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository
نویسنده
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.
