گیت پیشرفته و کنترل تغییر آگاه از انتشار

وقتی cherry-pick موفق است اما backport هنوز قابل قبول نیست

روی main ابتدا یک refactor انجام شده و بعد یک bugfix آمده است. شاخهٔ release/1.4 خط قدیمی‌تری را پشتیبانی می‌کند و درخواست شده همان bugfix به آن منتقل شود. cherry-pick بدون conflict تمام می‌شود؛ از دید Git عملیات موفق بوده است. با این حال، تست رفتاری روی target line شکست می‌خورد، چون bugfix به بخشی از refactor وابسته بوده که روی release/1.4 وجود ندارد.

این دقیقاً مسئلهٔ این درس است: command success را با release evidence اشتباه نکن. خروجی اصلی تو Release-Aware Change Control Record v1 است؛ رکوردی که source commit، target line، ancestry و prerequisiteهای مرتبط، روش انتقال یا reversal، evidence رفتاری، وضعیت tag، مرز version policy، rollback/reversal limit، residual risk و تصمیم انسانی را کنار هم نگه می‌دارد.

هدف این نیست که همیشه merge، rebase یا cherry-pick را انتخاب کنی. هدف این است که بتوانی بگویی چرا یک روش برای همین target و همین claim مناسب است، چه evidenceی آن را پشتیبانی می‌کند و چه چیزی هنوز ثابت نشده است.

سه مسیر، یک استاندارد پذیرش

اگر در Foundation هستی، اول source/target، ancestry و مفهوم transfer/reversal را صریح می‌سازی و بعد وارد case می‌شوی. اگر در Repair هستی، فقط به اولین تمایز خراب برمی‌گردی؛ مثلاً اگر cherry-pick را درست اجرا می‌کنی اما clean apply را معادل compatibility می‌گیری، تمرین روی evidence رفتاری target line متمرکز می‌شود.

در Experienced / Fast Path توضیح syntax کوتاه‌تر است، اما artifact و evidence bar حذف نمی‌شوند. سابقهٔ کار با release branch مجوز این نیست که branch name، tag name، merge success یا intuition تیم را جای evidence بگذاری.

قبل از ادامه سه سؤال را جواب بده: source commit دقیقاً کدام است؟ target ref و ancestry relevant آن چیست؟ اگر عملیات Git موفق شد، کدام check مستقل هنوز می‌تواند تصمیم تو را رد کند؟ اگر پاسخ سوم را نداری، گیت release-aware هنوز شکل نگرفته است.

مدل ذهنی: change، history، release marker و runtime evidence یکی نیستند

چهار لایه را جدا نگه دار:

1. Change content: patch یا تغییر منطقی‌ای که می‌خواهی منتقل یا معکوس کنی.
2. History relationship: commitها و ancestry روی source و target. merge histories را join می‌کند، rebase commitها را روی base دیگری دوباره اعمال می‌کند و cherry-pick change یک commit موجود را به context فعلی اعمال و commit جدیدی ثبت می‌کند. این تفاوت‌ها دربارهٔ history/change relationship هستند، نه رتبه‌بندی جهانی روش‌ها.
3. Release marker: tag می‌تواند یک object/commit را مشخص کند. این فقط می‌گوید ref به کجا اشاره می‌کند؛ نمی‌گوید artifact ساخته، منتشر یا deploy شده است.
4. Behavior/operation evidence: تست، build یا observation مربوط به state هدف. این evidence باید به همان target state bind باشد.

revert نیز در همین مدل محدود است: Git commit جدیدی می‌سازد که effect تغییر قبلی را در history معکوس می‌کند. اگر تغییر قبلی database، پیام، فایل خارجی یا service دیگری را عوض کرده باشد، Git به‌تنهایی آن side effect را برنمی‌گرداند.

پس هر نتیجه باید بگوید «دربارهٔ کدام لایه حرف می‌زنم؟» و «evidence من تا کجا می‌رسد؟».

ساخت Release-Aware Change Control Record v1

رکورد را از state قابل مشاهده به تصمیم بساز:

1. Source: source commit و locator آن را ثبت کن. فقط ticket یا message کافی نیست.
2. Target: target ref، target tip و ancestry evidence مرتبط را ثبت کن. نام release/1.4 به‌تنهایی compatibility policy نیست.
3. Dependency boundary: بنویس fix به کدام prerequisite، refactor، API یا behavior assumption وابسته است و این فرض را چگونه بررسی کرده‌ای.
4. Candidate method: merge، rebase، cherry-pick، reconstruction، revert یا ترکیب محدود دیگری را با rationale انتخاب کن. method باید از context بیاید، نه از ترجیح شخصی.
5. Git result: نتیجهٔ operation را ثبت کن، اما آن را evidence کامل ننام.
6. Target-line verification: check مستقل روی target state اجرا و state/fingerprint آن را ثبت کن.
7. Version-policy boundary: فقط اگر پروژه صریحاً SemVer را پذیرفته و public API مشخص دارد، patch/minor/major reasoning را به همان policy وصل کن. در غیر این صورت «قابل استنتاج نیست» یک پاسخ معتبرتر از حدس است.
8. Release marker: tag پیشنهادی را resolve کن و target واقعی آن را ثبت کن. tag وجود دارد ≠ release رخ داده است.
9. Reversal/rollback boundary: بگو Git-level reversal چه چیزی را برمی‌گرداند و چه external stateی بیرون از آن است.
10. Decision: یکی از ACCEPT، MODIFY، REJECT یا BOUNDED_DEFER را همراه با residual risk و non-claim ثبت کن.

چرا clean apply می‌تواند گمراه‌کننده باشد

cherry-pick change معرفی‌شده توسط commit موجود را روی current context اعمال می‌کند. اگر patch از نظر متن و context قابل اعمال باشد، عملیات می‌تواند بدون conflict تمام شود. اما این success دربارهٔ dependencyهای رفتاری یا compatibility contract چیزی اضافه نمی‌کند.

در case مرکزی، refactor روی main یک helper جدید ساخته است. bugfix بعدی فقط فایل مصرف‌کننده را تغییر می‌دهد تا از آن helper استفاده کند. روی main همه‌چیز pass است. روی release line قدیمی، خود bugfix می‌تواند clean apply شود، ولی helper در target ancestry نیست؛ بنابراین runtime/test failure تازه آشکار می‌شود. اولین promotion نامعتبر این است: «patch cleanly applied → backport compatible».

همین منطق برای merge و rebase هم برقرار است. Git می‌تواند history operation را درست انجام دهد، ولی release acceptance هنوز به target-specific evidence نیاز دارد. روش انتقال فقط یک بخش record است.

نمودار این درس چنین توالی‌ای دارد: source/target boundary → ancestry/dependency check → candidate method → Git result → target behavior evidence → version/tag boundary → reversal limit → human decision. هیچ پیکانی از «operation succeeded» مستقیماً به ACCEPT نمی‌رود.

مثال کارشده: bugfix وابسته به refactor

فرض کن main این history را دارد: یک commit پایه، سپس refactorی که helper normalize_code را اضافه کرده، و بعد bugfixی که service.py را به استفاده از آن helper تغییر داده است. release/1.4 از خط قدیمی‌تر آمده و helper را ندارد.

در نگاه اول، cherry-pick کردن bugfix جذاب است: change کوچک است و Git ممکن است بدون conflict آن را اعمال کند. اما record قبل از decision باید دو چیز را جدا ثبت کند: Git operation result و target-line behavior result. اگر تست release با missing dependency شکست بخورد، clean apply دیگر نمی‌تواند evidence پذیرش باشد.

حالا چند راه ممکن وجود دارد: prerequisite را هم منتقل کنی، fix را برای release line بازسازی کنی، integration دیگری انجام دهی، یا change را defer/reject کنی. هیچ‌کدام فقط به‌خاطر نام method درست نیستند. باید ببینی target line چه scope و compatibility boundary دارد و کدام گزینه کمترین claim اضافه و کافی‌ترین evidence را می‌دهد.

در fixture آموزشی، project هیچ policy صریحی برای SemVer/public API اعلام نمی‌کند. بنابراین حتی اگر tag شبیه v1.4.1 باشد، record حق ندارد صرفاً از شکل نام نتیجه بگیرد که change حتماً PATCH است. همچنین candidate tag عمداً ممکن است به commit قبل از fix اشاره کند؛ باید target واقعی tag را بررسی کنی.

چهار shortcut که باید متوقف شوند

«Cherry-pick clean بود، پس backport امن است.» repair: dependency boundary و target-specific behavior را بررسی کن.

«Revert شد، پس سیستم rollback شد.» repair: Git-tracked state را از database/file/message/service side effects جدا کن و recovery obligation بیرونی را صریح بنویس.

«Tag درست اسم‌گذاری شده، پس همین نسخه deploy شده.» repair: tag target را resolve کن و deployment/publication evidence را جدا نگه دار. این درس tag را deployment record فرض نمی‌کند.

«این bugfix است، پس SemVer یعنی PATCH.» repair: اول بررسی کن آیا پروژه SemVer را صریحاً پذیرفته و public API را تعریف کرده است. بدون آن authority، version bump را infer نکن.

«AI یا tool گفت low risk است.» suggestion می‌تواند probe بسازد، اما acceptance باید به evidence قابل بازبینی و تصمیم انسانی وصل باشد.

برای مهندس باتجربه: policy تیم را حفظ کن، claim boundary را هم حفظ کن

ممکن است تیم تو release branch، maintenance branch، trunk، merge queue یا backport bot داشته باشد. این درس workflow واحدی را تحمیل نمی‌کند. invariantهای زیر باید در هر workflow قابل بازیابی باشند:

• source و target دقیق؛
• ancestry و prerequisite boundary قابل بازرسی؛
• method با rationale context-specific؛
• target-line verification مستقل از Git success؛
• tag target جدا از release/deployment evidence؛
• version policy فقط با authority صریح؛
• reversal boundary جدا از operational rollback؛
• residual risk و human decision روشن.

اگر سیستم داخلی همین fields را با نام‌های دیگری ثبت می‌کند، artifact می‌تواند mirror آن باشد؛ معنا نباید گم شود.

merge، rebase، cherry-pick و reconstruction؛ trade-off بدون dogma

Merge وقتی مناسب است که join کردن histories با policy و هدف target هماهنگ باشد. مزیت یا هزینهٔ آن از context پروژه می‌آید؛ موفقیت merge behavioral acceptance نیست.

Rebase commitها را روی base دیگری reapply می‌کند و ancestry را بازنویسی می‌کند. برای بعضی historyهای local مفید است و برای بعضی shared/release histories نامناسب؛ این درس هیچ حکم جهانی نمی‌دهد.

Cherry-pick برای انتقال change commitهای انتخاب‌شده مفید است، اما dependencyهای خارج از patch می‌توانند پنهان بمانند. clean apply فقط یک observation است.

Reconstruction/minimal backport گاهی اجازه می‌دهد bugfix را بدون refactor بزرگ بازسازی کنی. این گزینه هم باید با test و rationale target-specific دفاع شود؛ «کمتر بودن diff» به‌تنهایی safety نیست.

Revert یک ابزار history-level reversal است. اگر incident operational side effect دارد، record باید plan دیگری برای آن state ثبت کند.

Lab و تمرین مستقل

در FND010-LAB1 fixture محلی را بساز. repository شامل main، release/1.4، tagهای محلی، تست deterministic و یک marker مصنوعی برای external state است. هیچ remote، credential یا production system وجود ندارد.

برای S2، ابتدا source commit و target ancestry را capture کن. یک candidate transfer را بررسی کن و نتیجهٔ Git را جدا از test نتیجه ثبت کن. اگر clean cherry-pick شکست رفتاری دارد، آن observation را پنهان نکن. روش اصلاح را خودت انتخاب کن؛ oracle یک command sequence واحد را تحمیل نمی‌کند، ولی target behavior، rationale، tag target، version-policy boundary و reversal limitation باید قابل بررسی باشند.

برای S5، fixture دوم target line را یک commit عقب‌تر می‌برد، fix را قابل reconstruction نگه می‌دارد و candidate tag را روی ancestor اشتباه قرار می‌دهد. strategy را از case اول کپی نکن؛ ancestry و evidence را دوباره بساز.

evidence package حداقلی

Release-Aware Change Control Record v1 باید حداقل این موارد را داشته باشد: source commit، target ref/tip، ancestry evidence، dependency assumption و proof/probe آن، candidate method و rationale، Git operation result، target behavior evidence، version-policy applicability، proposed tag و resolved target آن، reversal/rollback boundary، external-state observation، residual risk، human decision، non-claim و support disclosure.

Evidence باید بتواند تصمیم را رد کند. «بدون conflict بود»، «CI سبز بود» یا «tag وجود دارد» فقط وقتی کافی هستند که claim دقیقاً در همان boundary باشد. اگر claim گسترده‌تر است، probe گسترده‌تری لازم است.

اگر evidence ناقص است، BOUNDED_DEFER می‌تواند از false certainty بهتر باشد؛ باید دقیقاً بگوید چه تصمیمی به تعویق افتاده و چه evidenceی برای بستن آن لازم است.

ارزیابی از retrieval تا transfer

S1 مفهوم source/target، transfer method، revert boundary، tag و version-policy applicability را در یک case کوتاه جدا می‌کند.

S2 بخش مرکزی Release-Aware Change Control Record v1 را از Lab می‌سازد و هر conclusion blocking را به locator/evidence وصل می‌کند.

S3 اولین promotion نامعتبر از Git success به compatibility/release claim را پیدا می‌کند و probe متمایزکننده می‌دهد.

S4 یکی از ACCEPT، MODIFY، REJECT یا BOUNDED_DEFER را با rationale، limitation و non-claim انتخاب می‌کند.

S5 همان evidence bar را در history متفاوت اعمال می‌کند؛ copy کردن commandهای case قبلی کافی نیست.

چهار dimension بحرانی‌اند و با میانگین جبران نمی‌شوند: state/history correctness، evidence traceability، human judgment/limitation disclosure و transfer.

منابع و مرز freshness

معنای فنی cherry-pick، rebase، merge، revert و tag در این درس به مستندات رسمی Git محدود است. claimهای version impact فقط به Semantic Versioning 2.0.0 محدود می‌شوند و تنها وقتی اعمال می‌شوند که پروژه SemVer و public API را صریحاً تعریف کرده باشد.

research map درس در 2026-09-02 ثبت شده و command-specific منابع Git برای 2026-10-17 review_due دارند. در 2026-09-07 همین source set دوباره با منابع رسمی کنترل شد و claim boundary جدیدی اضافه نشد. اگر source materially تغییر کند، review_due برسد یا متن درس claim فنی جدیدی بیرون از این map بسازد، source verification باید دوباره انجام شود.

الزام Release-Aware Change Control Record v1 یک curriculum design rule است، نه ادعایی که Git یک release-management policy جهانی تحمیل می‌کند.