شاخه‌ها ارزان‌اند؛ فاصله‌ای که می‌سازند نهBranches are cheap; the distance they create is not

فصل ۵ نشان داد شاخه در Git یک اشاره‌گر سبک به commit است، نه یک کپی کامل از پوشه. پس چرا دوازده شاخهٔ زنده برای تیم دردسر شده؟ هزینهٔ اصلی روی دیسک نیست؛ در تفاوت‌هایی است که آدم‌ها باید بعداً کنار هم بگذارند.

Chapter 5 showed that a Git branch is a lightweight pointer to a commit, not a full copy of the directory. So why are twelve active branches hurting this team? The main cost is not on disk; it is the divergence people must reconcile later.

هر شاخه‌ای که کار مستقل روی آن ادامه دارد، ممکن است از شاخهٔ اصلی commitهای تازه را نبیند. تغییر نام یک تابع، جابه‌جایی فایل یا اصلاح یک قرارداد API می‌تواند در این مدت در جای دیگری اتفاق بیفتد. وقتی دو مسیر دوباره merge می‌شوند، Git بخش‌هایی را که می‌تواند ترکیب می‌کند؛ اما نمی‌داند دو تغییر از نظر محصول با هم سازگارند یا نه. فصل‌های ۶ و ۷ ابزار ادغام را یاد دادند؛ این فصل دربارهٔ کم‌کردن هزینه و انتخاب زمان ادغام است.

Any branch with ongoing independent work may miss new commits on the main line. A function rename, file move, or API contract change can happen elsewhere in the meantime. When the paths meet again, Git combines what it can, but it cannot know whether the two changes make sense together as a product. Chapters 6 and 7 taught the integration tools; this chapter is about reducing integration cost and choosing when to integrate.

این به معنی «هر merge سخت است» نیست. Git می‌تواند merge را بدون تعارض انجام دهد، اما تست یکپارچه، ترتیب انتشار و رفتار ترکیب‌شده هنوز مسئولیت ماست. سؤال بهتر این است: فاصلهٔ شاخه‌ها چقدر باشد که هزینهٔ هماهنگی و ریسک تغییر، از سود جداسازی بیشتر نشود؟

This does not mean every merge is difficult. Git may merge without conflicts, but integration tests, release order, and combined behavior remain our responsibility. A better question is: how far apart can branches get before coordination cost and change risk outweigh the value of isolation?

قبل از اسم الگوها، مسئلهٔ تیم را اندازه بگیرBefore naming models, measure the team's problem

اگر فقط بپرسیم «Git Flow بهتر است یا trunk-based؟» هنوز اطلاعات کافی نداریم. اول ببینیم تیم چه چیزی را باید هماهنگ کند. یک محصول وب که روزی چند بار منتشر می‌شود، مسئله‌ای متفاوت از کتابخانه‌ای دارد که دو نسخهٔ قبلی‌اش هنوز پشتیبانی می‌شوند.

If we only ask “Is Git Flow or trunk-based better?”, we do not yet have enough information. First look at what the team must coordinate. A web product deployed several times a day has a different problem from a library that still supports two previous versions.

برای trunk-based، یک شاخهٔ نسخه‌ انتشار موقت با کاربرد روشن الزاماً تناقض نیست؛ برای نمونه، تیم می‌تواند از trunk نسخه را آماده کند و مدت کوتاهی آن را تثبیت کند. مرز اصلی این است که آیا شاخه‌های طولانیِ توسعه به مسیر عادی تبدیل شده‌اند یا نه. هیچ جدول امتیازی جای گفت‌وگوی تیم دربارهٔ پاسخ همین سؤال‌ها را نمی‌گیرد.

A temporary release branch with a clear purpose does not automatically contradict trunk-based development; for example, a team may cut one from trunk to stabilize a release briefly. The key question is whether long-lived development branches have become the normal path. No scoring table can replace the team's discussion of these questions.

trunk-based: زود ادغام کن، بازخورد را زود بگیرTrunk-based: integrate early and get feedback early

در تیم پنج‌نفره، شاید قابلیت شاخهها هفته‌ها از هم خبر نداشته باشند. در trunk-based، مرکز یکپارچه‌سازی همان `main` یا trunk است و تغییرها مرتب به آن برمی‌گردند. بعضی تیم‌های کوچک مستقیم commit می‌کنند؛ تیم‌های دیگر برای بازبینی و CI شاخهٔ کوتاه‌عمر می‌سازند. «همه مستقیم روی main بنویسند» تعریف این روش نیست.

In the five-person team, feature branches may go weeks without seeing one another. In trunk-based development, `main` or trunk is the integration center and changes return to it frequently. Some small teams commit directly; others use short-lived branches for review and CI. “Everyone writes directly to main” is not the definition.

به‌جای کارکردن روی یک قابلیت کامل تا روز انتشار، تغییر را به قدم‌های کوچک و سازگار می‌شکنیم. هر قدم سریع ساخته و تست می‌شود؛ اگر قابلیت هنوز آمادهٔ استفاده نیست، گاهی قابلیت flag کمک می‌کند کد در trunk باشد اما رفتار برای کاربران فعال نشود. flag خودکار امنیت نمی‌سازد: باید حالت روشن و خاموش را تست کرد و flag موقت را بعداً حذف کرد.

Instead of developing an entire feature until release day, we split it into small, compatible steps. Each step is built and tested quickly. If a feature is not ready for users, a feature flag may let the code live on trunk while the behavior stays disabled. A flag is not automatic safety: test both states and remove temporary flags later.

طرف دیگر انتخاب هم واقعی است: ادغام پرتکرار، مشکل ناسازگاری را زودتر آشکار می‌کند، اما بار CI و مسئولیت سبز نگه‌داشتن trunk را بالا می‌برد. شاخهٔ کوتاه‌عمر هم هنوز ممکن است تعارض داشته باشد؛ فقط معمولاً فاصلهٔ زمانی کمتری برای انباشته‌شدن تغییرها دارد.

The other side of the trade-off is real: frequent integration exposes incompatibility sooner, but increases CI load and the responsibility to keep trunk green. A short-lived branch can still conflict; it simply has less time to accumulate unrelated change.

GitHub Flow: مسیر سبکِ شاخه و PRGitHub Flow: a lightweight branch-and-PR path

حالا فرض کن تیم برای هر تغییر به بازبینی همکار نیاز دارد. GitHub Flow مسیر ساده‌ای برای آن می‌دهد: شاخه بساز، commit و push کن، PR باز کن، بازخورد و بررسیها را بگیر، merge کن و شاخهٔ تمام‌شده را حذف کن. این گردش کار میزبانی‌شده است؛ قانون تازه‌ای در مدل شیءهای Git نیست.

Now suppose every change needs a teammate's review. GitHub Flow offers a lightweight path: create a branch, commit and push, open a PR, get feedback and checks, merge, then delete the finished branch. It is a hosted collaboration workflow, not a new rule in Git's object model.

در راهنمای رسمی GitHub Flow، جریان با شاخه کوتاه و توصیفی، commit/push، PR برای بازخورد، رسیدگی به نظرها، merge بعد از تأیید و پاک‌کردن شاخه ادغام‌شده توضیح داده می‌شود. بررسی یا تعداد بازبینیها به تنظیم مخزن بستگی دارد؛ PR به‌تنهایی تضمین نمی‌کند چیزی تست شده باشد. دیگر میزبان‌ها هم گردش‌های شبیه به آن دارند، ولی نام و جزئیات UI ممکن است فرق کند.

GitHub's official GitHub Flow guide describes a short, descriptive branch, commits and pushes, a PR for feedback, addressing review comments, merging after approval, and deleting the merged branch. Checks and review counts depend on repository settings; a PR alone does not guarantee that anything was tested. Other hosts offer similar workflows, though UI names and details vary.

یک سؤال مهم دربارهٔ انتشار باقی می‌ماند: merge شد، پس چه کسی یا چه چیزی نسخه را منتشر می‌کند؟ بعضی تیم‌ها با هر merge به main انتشار می‌دهند؛ بعضی انتشار را دستی یا در بازه‌های مشخص انجام می‌دهند. GitHub Flow خودش به‌تنهایی روش استقرار را تحمیل نمی‌کند.

One release question remains: it merged, so who or what deploys it? Some teams deploy every merge to main; others deploy manually or on a schedule. GitHub Flow does not itself prescribe a deployment model.

Git Flow: شاخه‌ها با نقش انتشار تعریف می‌شوندGit Flow: branches have release-oriented roles

برای تیمی که چند خط کار و انتشار نسخه‌ای دارد، مسیر سبک شاخه→PR شاید به‌تنهایی برنامهٔ انتشار را نشان ندهد. مدل کلاسیک Git Flow این نقش‌ها را جدا می‌کند: `main` برای نسخه‌های منتشرشده، `develop` برای جمع‌شدن کار نسخهٔ بعد، `feature/*` برای قابلیت، `release/*` برای تثبیت و `hotfix/*` برای رفع فوری نسخهٔ زنده.

For a team with several work and release lines, a lightweight branch-to-PR path may not show the release plan by itself. The classic Git Flow model assigns distinct roles: `main` for released versions, `develop` for assembling the next release, `feature/*` for features, `release/*` for stabilization, and `hotfix/*` for urgent fixes to a live version.

برای نسخه‌ انتشار، تیم وقتی develop به ترکیب موردنظر رسید `release/*` می‌سازد، کارهای تثبیت و نسخه‌گذاری را آنجا انجام می‌دهد، خروجی را در main با نسخهٔ مشخص tag می‌کند و اصلاح‌های نسخه‌ انتشار را به develop هم برمی‌گرداند. برای اصلاح فوری، نقطهٔ شروع نسخهٔ واقعاً منتشرشده است؛ بعد از آماده‌شدن، تغییر باید هم نسخهٔ زنده را اصلاح کند و هم به خط توسعه برگردد. اگر شاخهٔ نسخه‌ انتشار باز است، مسیر برگشت باید طبق سیاست تیم مشخص شود تا fix گم نشود.

For a release, the team cuts `release/*` once develop contains the intended scope, performs stabilization and versioning there, tags the released result on main, and brings release fixes back to develop. A hotfix starts from the actually released version; once ready, it must fix the live line and return to ongoing development. If a release branch is open, the team must define the back-merge path so the fix is not lost.

این مدل می‌تواند برای محصول نسخه‌ای، چند نسخهٔ پشتیبانی‌شده یا هماهنگی تثبیت رسمی مفید باشد. بهایش هم روشن است: شاخه‌ها و mergeهای بیشتر، تصمیم‌های بیشتر دربارهٔ اینکه هر fix کجا برود، و احتمال عقب‌ماندن خط‌ها از هم. اگر عملاً همیشه main را منتشر می‌کنی و نسخهٔ بعدی جداگانه‌ای نداری، develop و نسخه‌ انتشارهای دائمی ممکن است تشریفات بی‌فایده بسازند.

This model can help with versioned products, several supported versions, or formal stabilization. Its costs are also real: more branches and merges, more decisions about where each fix belongs, and more chances for lines to drift. If you always release main and have no separately assembled next version, permanent develop and release branches may add ceremony without value.

نام‌گذاری شاخهها قابلیت ویژه‌ای در Git ایجاد نمی‌کند؛ همهٔ آن‌ها همان شاخههای معمولی‌اند. نقش را توافق تیم تعریف می‌کند. اگر می‌خواهی مسیر دقیق مدل اولیه را ببینی، مقالهٔ اصلی Vincent Driessen را بخوان؛ Git Flow کلاسیک را با همین فرض ببین، نه به‌عنوان پیش‌فرض Git یا الزام هر مخزن.

Branch names do not create special behavior in Git; they are ordinary branches. The team agreement gives them their roles. For the original model, see Vincent Driessen's original article; treat classic Git Flow as a model, not a Git default or a requirement for every repository.

سه الگو را با نیاز مقایسه کن، نه با محبوبیتCompare the models by need, not popularity

هیچ‌کدام وعدهٔ خودکارِ کیفیت، تست یا انتشار امن نمی‌دهند. تفاوت اصلی در این است که خط ادغام کجا قرار می‌گیرد، کار چند وقت جدا می‌ماند و انتشار چطور کنترل می‌شود.

None automatically promises quality, tests, or safe releases. The main differences are where integration happens, how long work stays separate, and how releases are controlled.

این‌ها هم الزاماً انتخاب‌های کاملاً جدا نیستند. تیم می‌تواند trunk-based کار کند، PR را برای بازبینی به‌کار ببرد، و برای یک انتشار مشخص شاخهٔ موقت بسازد. اسم روش به‌اندازهٔ قواعد واقعی مهم نیست: کجا ادغام می‌کنیم، چه چیزی اجازهٔ merge دارد، انتشار از کدام commit است و fix فوری کجا می‌رود؟

These are not always mutually exclusive choices. A team can work trunk-based, use PRs for review, and cut a temporary branch for a specific release. The label matters less than the actual rules: where do we integrate, what can merge, which commit gets released, and where does an urgent fix go?

چهار تیم، چهار مسئلهٔ متفاوتFour teams, four different problems

بیایید اسم الگوها را کنار بگذاریم و از مسئله شروع کنیم. انتخاب زیر نسخهٔ نهایی برای همه نیست؛ فرض‌هایی است که هر تیم باید با تجربه و دادهٔ خودش امتحان کند.

Let's set the labels aside and start with the problem. The choices below are not universal prescriptions; they are hypotheses each team should test against its own experience and data.

در تیم چهارم، کنترل رسمی را با تعداد شاخه اشتباه نگیر. بازبینی اجباری، بررسیهای لازم، محدودیت push و ثبت انتشار ممکن است روی یک شاخهٔ اصلی هم برقرار باشد. گاهی مدل چندخطی ارزش دارد؛ گاهی فقط کار را سخت می‌کند. الزام ممیزی باید با شاهدی که ممیز می‌خواهد شروع شود، نه با کپی‌کردن نمودار Git Flow.

For the fourth team, do not confuse formal control with branch count. Required reviews, checks, push restrictions, and release records can exist on a single main line. A multi-line model may sometimes be valuable; sometimes it only adds friction. Start from the evidence an audit requires, not by copying a Git Flow diagram.

حفاظت شاخه و CI، نگهبان مسیرند نه جایگزین سیاستBranch protection and CI guard the path; they are not the policy

اگر قرار است main همیشه قابل‌استقرار بماند، یا نسخه‌ انتشار فقط بعد از بررسی مشخص جلو برود، توافق شفاهی کافی نیست. می‌توانیم بخشی از آن را با CI و تنظیمات مخزن enforce کنیم. اما تنظیمی که نمی‌دانیم دقیقاً چه می‌کند، خودش می‌تواند مسیر همکاری را قفل کند.

If main should remain deployable, or a release may proceed only after specific checks, a verbal agreement may not be enough. CI and repository settings can enforce parts of the policy. But a setting whose behavior we do not understand can also block collaboration.

در GitHub، حفاظت شاخه می‌تواند بازبینی لازم، وضعیت بررسی لازم، حل گفت‌وگوهای باز، محدودیت push یا الزام به به‌روز بودن شاخه را تنظیم کند. merge queue هم برای شاخه‌های پرترافیک می‌تواند PRها را روی وضعیت تازهٔ مقصد و صف موجود دوباره بررسی کند. اینکه کدام قابلیت برای مخزن قابل‌دسترس است و چه ruleای برنده می‌شود، به تنظیمات و سطح دسترسی مخزن بستگی دارد؛ رفتار جاری را در مستندات همان میزبان بررسی کن.

On GitHub, branch protection can require reviews, status checks, resolved conversations, restrict pushes, or require a branch to be up to date. A merge queue can recheck PRs against the current target and queued changes for a busy branch. Availability and applicable rules depend on repository configuration and permissions; check the host's current documentation for the behavior that applies to your repository.

برای مخزنی که PR زیادی به main می‌فرستد، شرط «شاخه به‌روز باشد» ممکن است افراد را مجبور کند بارها update و CI را دوباره اجرا کنند. merge queue می‌تواند بخشی از این صف‌بندی را خودکار کند، اما صف، زمان اجرا و شکست بررسی هنوز هزینه دارند. ابزار، مسئلهٔ ظرفیت را حذف نمی‌کند؛ فقط ترتیب و قاعدهٔ ورود را روشن‌تر می‌کند.

For a repository with many PRs targeting main, an “up to date” requirement may make people repeatedly update branches and rerun CI. A merge queue can automate some of that serialization, but queue time, CI time, and failed checks still cost something. The tool does not erase the capacity problem; it makes ordering and entry rules clearer.

یک تصمیم کوچک‌تر از «انتخاب دائمی مدل»A smaller decision than “choose a model forever”

به تیم پنج‌نفره برگردیم. به‌جای پاک‌کردن همهٔ شاخه‌ها یا مهاجرت نمایشی، یک آزمایش محدود طراحی می‌کنیم: دو هفته تغییرهای معمول را کوچک‌تر کنیم، عمر شاخهها را ثبت کنیم و زمان انتظار برای merge و CI را ببینیم.

Return to the five-person team. Instead of deleting every branch or staging a dramatic migration, design a bounded experiment: for two weeks, make ordinary changes smaller, record branch lifetime, and observe merge and CI wait time.

از این داده‌ها سه چیز را می‌پرسیم: چند شاخه بیش از زمان توافق‌شده زنده ماند؟ چند بار لازم شد تغییرهای main را دیرهنگام بیاوریم؟ چند بار بررسی یا بازبینی معطل ماند؟ اگر جواب‌ها بدتر شدند، علت را از سیاست جدا کن: شاید CI کند است، شاید کارها بزرگ‌اند، شاید مالک بازبینی معلوم نیست. عوض‌کردن اسم مدل بدون رفع علت، مسئله را حل نمی‌کند.

Ask three things of the data: how many branches outlived the agreed window? How often did we bring main changes in late? How often were checks or reviews blocked? If results are poor, separate the cause from the label: CI may be slow, tasks may be too large, or review ownership unclear. Renaming the model without fixing the cause will not help.

تغییر سیاست را هم مثل تغییر کد بازبینی کن: یک نفر متن را بنویسد، بقیه با یک سناریوی واقعی آن را قدم‌به‌قدم اجرا کنند، و بعد از مدتی نتیجه را بسنجند. سیاستی که در صفحهٔ wiki زیباست اما هنگام اصلاح فوری معلوم نمی‌کند fix به کدام شاخه برود، هنوز سیاست کامل نیست.

Review a policy like a code change: one person drafts it, others walk through a real scenario step by step, and the team measures results later. A policy that looks neat in a wiki but cannot say where a hotfix goes is not complete yet.

پروژهٔ کوچک: سیاست شاخه‌بندی تیم شش‌نفرهMini-project: a branching policy for a six-person team

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

Now you are responsible for the team's agreement. Six people build one web product, release to production weekly, have CI, and work on several unfinished features at once. Sometimes they must ship an urgent hotfix to the live version. These facts do not automatically select a model; you must create a policy the team can actually follow.

یک سند یک‌صفحه‌ای بنویس. قبل از نوشتن، تصمیم بگیر آیا نسخه‌ انتشار شاخه کوتاه لازم است، آیا ادغام از راه PR انجام می‌شود، و قابلیت ناتمام چطور از کاربران پنهان می‌ماند. بعد دست‌کم دو گزینهٔ دیگر را کنار انتخابت بگذار و هزینه‌ای را که آگاهانه می‌پذیری بنویس. «سریع‌تر است» بدون توضیح CI، بازبینی و انتشار، دلیل کافی نیست.

Write a one-page policy. Before drafting, decide whether a short release branch is needed, whether integration goes through PRs, and how unfinished features stay hidden from users. Then compare at least two alternatives and name the cost you knowingly accept. “It is faster” is not enough without explaining CI, review, and release behavior.

پیش‌نویس را با دو سناریو امتحان کن: یک قابلیت سه‌روزه که هنوز برای کاربر روشن نیست، و یک خطای امنیتی در نسخهٔ production وقتی main چند تغییر ناتمام دارد. اگر برای هر کدام نتوانستی بگویی شاخه از کجا می‌آید، چه کسی چه چیزی را بررسی می‌کند، کجا merge می‌شود و نتیجه چطور دوباره verify می‌شود، جای خالی را در سند پیدا کرده‌ای.

Test the draft against two scenarios: a three-day feature that is not yet user-ready, and a security bug in production while main contains unfinished work. If you cannot say where each branch starts, who checks what, where it merges, and how the result is verified again, you have found a gap in the policy.

مدرک پایان پروژه فقط فایل سیاست نیست: دو نفر دیگر باید بتوانند با خواندنش هر دو سناریو را بدون حدس اجرا کنند. سیاست خوب قرار نیست اختلاف‌نظر را حذف کند؛ کاری می‌کند اختلاف قبل از production دیده شود و تصمیم بعدی معلوم باشد.

The project's proof is not just the policy document: two other people should be able to walk through both scenarios without guessing. A good policy does not eliminate disagreement; it makes disagreement visible before production and clarifies the next decision.

تمرین‌ها: به‌جای انتخاب شعار، سیاست طراحی کنExercises: design policies instead of choosing slogans

در این فصل جواب‌ها فرمان Git نیستند. باید از روی نیاز تیم، هزینهٔ ادغام، سرعت انتشار و کیفیت CI استدلال کنی. اگر دو راه هر دو منطقی‌اند، فرقشان را توضیح بده؛ لازم نیست برای هر سناریو یک «برندهٔ مطلق» بسازی.

For each case, first say what you do not yet know. Then state a proposal, its cost, and its success condition. The answers below model reasoning; they are not the only acceptable choices.

هر سیاستی انتخاب کنی، نوبت همکاری با آدم‌هاستWhichever policy you choose, collaboration with people comes next

هر سیاست شاخه‌بندی که انتخاب کنی، در نهایت یک آدم باید تغییر آدم دیگری را بفهمد و بررسی کند. فصل بعد از گراف فاصله می‌گیرد و وارد خودِ همکاری می‌شود: commit خوب، درخواست ادغام خوب و بازبینی قابل اعتماد.

Choosing a branching policy does not finish the collaboration problem; it reveals how changes are presented to others. The next chapter turns to pull requests and code review: how to prepare commits and explanations that let a teammate review with confidence, ask the right questions, and see risk before merge.

مرور سریع این فصلQuick reference