نویسنده: WKFGo Editorial · تاریخ انتشار · آخرین ویرایش

Branch per Task چیست؟

در الگوی Branch per Task، برای هر واحد کار قابل تحویل یک شاخه کوتاه‌عمر Git ساخته می‌شود و نام شاخه شناسه تسک را حمل می‌کند. commit، pull request، نتیجه CI و وضعیت تحویل به همان شناسه وصل می‌شوند تا بتوان از نیاز محصول تا تغییر کد را ردیابی کرد.

این الگو به معنی «برای هر کار ریز یک branch» نیست. اگر یک تسک چند تغییر مستقل و قابل انتشار دارد، باید شکسته شود؛ اگر چند commit یک هدف واحد دارند، یک شاخه کافی است.

قرارداد نام‌گذاری

یک قالب ساده و قابل پردازش انتخاب کنید:

feature/TASK-442-payment-retry
fix/TASK-517-jalali-date-filter
chore/TASK-601-upgrade-sdk

بخش ضروری شناسه تسک است؛ توضیح کوتاه برای انسان مفید است. نام شخص، تاریخ یا عبارت‌هایی مثل final-fix ردیابی پایداری نمی‌سازند.

برای incident یا hotfix نیز قرارداد جدا اما هم‌خانواده داشته باشید:

hotfix/INC-83-checkout-timeout

۱. تسک را آماده کنید

هدف، معیار پذیرش، ریسک و وابستگی روشن باشند. شاخه‌ای که از تسک مبهم شروع می‌شود، معمولاً pull request بزرگ و رفت‌وبرگشت زیاد می‌سازد.

۲. شاخه را از مبنای درست بسازید

تیم مشخص کند شاخه از main، release branch یا شاخه دیگری ایجاد می‌شود. مبنای اشتباه conflict و تغییر ناخواسته وارد PR می‌کند.

۳. کامیت‌های منسجم بسازید

هر کامیت یک تغییر قابل توضیح داشته باشد و در صورت سیاست تیم شناسه تسک را در پیام نگه دارد. کامیت‌های بسیار بزرگ بازبینی را سخت و کامیت‌های صرفاً «fix» تاریخچه را بی‌ارزش می‌کنند.

۴. زود push و draft PR ایجاد کنید

Draft PR دید زودهنگام درباره جهت تغییر و CI می‌دهد. لازم نیست تا پایان کامل کار صبر کنید؛ اما درخواست review رسمی فقط وقتی معیارها و تست‌ها آماده‌اند ارسال شود.

۵. وضعیت را همگام کنید

ساخت شاخه می‌تواند تسک را «در حال انجام»، ایجاد PR آن را «در بازبینی» و merge موفق آن را «آماده انتشار» کند. خودکارسازی نباید وضعیت کسب‌وکاری را کورکورانه ببندد؛ merge کد همیشه به معنی تحویل به کاربر نیست.

۶. پس از merge شاخه را حذف کنید

شاخه کوتاه‌عمر باید بعد از ادغام پاک شود. retention طولانی برای شاخه merge‌شده فهرست را شلوغ و انتخاب مبنا را پرخطا می‌کند؛ تاریخچه در commit و PR باقی می‌ماند.

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

نشانه‌های شاخه بیش از حد بزرگ:

چند هدف محصولی مستقل دارد؛
review بیش از چند روز طول می‌کشد؛
تغییرات refactor و قابلیت اصلی مخلوط‌اند؛
rollback بخشی از آن ممکن نیست؛
فایل‌های زیادی بدون رابطه روشن تغییر کرده‌اند.

نشانه شاخه بیش از حد ریز: چند branch فقط برای تغییراتی ساخته شده‌اند که بدون یکدیگر قابل تست یا انتشار نیستند. معیار، واحد ارزش و قابلیت review است؛ نه تعداد خط ثابت.

اتصال خودکار Git و ابزار مدیریت پروژه

Webhook می‌تواند شناسه را از نام branch، پیام commit یا عنوان PR استخراج کند. اتصال باید این رخدادها را ثبت کند:

شاخه ساخته شد؛
commit جدید متصل شد؛
PR باز، draft یا آماده review شد؛
CI شکست یا موفق شد؛
review درخواست تغییر یا تأیید داد؛
PR merge یا بسته شد؛
نسخه شامل commit منتشر شد.

در WKFGo می‌توان commit و pull request را به تسک وصل کرد تا گزارش تحویل از داده Git استفاده کند. توکن اتصال باید حداقل مجوز لازم داشته باشد و payload webhook اعتبارسنجی شود.

استثناهای لازم

تغییر اضطراری: شاخه hotfix با incident و بازبینی پس از رخداد؛ bypass بی‌ردپا مجاز نیست.

کار اکتشافی: spike زمان‌دار می‌تواند branch داشته باشد، اما خروجی آن تصمیم یا prototype است و نباید بدون معیار محصول merge شود.

تغییر چند مخزن: یک شناسه تسک روی چند شاخه از مخزن‌های مختلف؛ هر درخواست ادغام مستقل و وابستگی انتشار روشن باشد.

کار گروهی: چند نفر می‌توانند روی یک branch همکاری کنند، اما force-push و مالکیت review باید قرارداد مشخص داشته باشد.

امنیت و محافظت شاخه

شاخه اصلی protected باشد؛
merge بدون CI و review لازم محدود شود؛
secret scanning و dependency check متناسب با ریسک اجرا شوند؛
توکن bot امکان بیش از نیاز نداشته باشد؛
حذف branch یا force-push روی شاخه مشترک ثبت و محدود شود؛
متن تسک و درخواست ادغام داده غیرقابل اعتماد محسوب شود، به‌ویژه برای عامل‌های هوش مصنوعی.

معیارهای سلامت جریان

زمان از شروع تسک تا اولین PR؛
زمان انتظار review و زمان فعال اصلاح؛
اندازه درخواست ادغام و تعداد فایل تغییرکرده؛
درصد درخواست‌های ادغام دارای شناسه معتبر تسک؛
نرخ شکست CI پیش از merge؛
شاخه‌های stale بدون فعالیت؛
تغییرهای merge‌شده بدون release قابل ردیابی؛
تعداد بازگشت یا hotfix پس از انتشار.

هدف، merge بیشتر نیست. جریان باید تغییر کوچک، قابل آزمون و قابل بازگشت تولید کند.

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

یک branch بلندمدت برای کل epic؛
نام شاخه بدون شناسه تسک؛
بستن خودکار تسک بلافاصله پس از merge؛
PR بزرگ شامل refactor نامرتبط؛
نگه‌داشتن صدها شاخه merge‌شده؛
دورزدن review در hotfix بدون post-review؛
دادن توکن Git با دسترسی مدیرکل به integration؛
ساخت شاخه پیش از روشن‌شدن معیار پذیرش.

آیا این روش با trunk-based development سازگار است؟

بله، اگر شاخه‌ها کوتاه‌عمر باشند و مرتب با trunk همگام شوند. Branch per task الزاماً به GitFlow و شاخه‌های طولانی نیاز ندارد.

شناسه تسک در branch کافی است یا commit هم لازم دارد؟

branch برای اتصال معمول کافی است، اما شناسه در PR و در بعضی تیم‌ها commit، تاریخچه را پس از حذف شاخه مقاوم‌تر می‌کند. قرارداد را بر اساس ابزار تعیین کنید.

merge یعنی تسک Done است؟

نه همیشه. ممکن است انتشار، آزمون پذیرش یا rollout باقی مانده باشد. وضعیت‌های «merge‌شده» و «تحویل‌شده» را در صورت نیاز جدا کنید.

قدم بعدی

قرارداد نام‌گذاری را روی یک مخزن و یک تیم آزمایش کنید. پس از دو هفته، شاخه‌های بی‌تسک، درخواست‌های ادغام بزرگ و زمان بازبینی را اندازه بگیرید. برای قواعد کیفیت پیش از ادغام، راهنمای استاندارد کدنویسی را ببینید.

منابع دست‌اول و روش راستی‌آزمایی

این فهرست برای بررسی بیشتر است؛ لینک‌های داخل متن، منبع ادعای مشخص همان بخش‌اند.