تغییرهای پشته‌ای

بازبینی تغییرهای بزرگ سخت است. آن‌ها را به گام‌های کوچکی تقسیم کنید که روی هم ساخته می‌شوند، مثلاً API، بعد صفحه‌ای که از آن استفاده می‌کند، بعد مستندات، تا بازبین‌ها یکی‌یکی بررسی کنند. این یک **پشته** است: زنجیره‌ای از شاخه‌ها که هرکدام از روی قبلی شروع می‌شود. ```diagram type: history title: پشته‌ای از سه شاخه روی main start: main --- branch main | accent branch api | | from A branch ui | | from B branch docs | | from C commit A main | پایه commit B api | نقطهٔ API | info درخواست ادغام ۱: api → main commit C ui | صفحهٔ رابط | info درخواست ادغام ۲: ui → api commit D docs | مستندات | info درخواست ادغام ۳: docs → ui ``` ## ساختن یک پشته ```bash zev stack add api # شاخه‌ای تازه روی جایی که هستید، و رویش می‌روید # …کامیت… zev stack add ui # بعدی، روی api # …کامیت… zev stack # کل پشته: هر شاخه، کامیت‌هایش، جایی که هستید ``` ```text Stack api on main, newest on top ▶ ui 1 commit: UI page (you're here) api 1 commit: API endpoint main ``` `zev stack up`، `down`، `top` و `bottom` روی آن جابه‌جا می‌شوند. ## تغییر یک شاخهٔ پایینی: zev stack restack بازبینی در `api` اصلاحی می‌خواهد. پایین بروید، اصلاح را کامیت کنید و `zev stack restack` را اجرا کنید. zev هر شاخهٔ بالاتر را روی نسخهٔ تازهٔ شاخهٔ زیرش rebase می‌کند و فقط کامیت‌های خود آن شاخه را دوباره اعمال می‌کند. این همان گامی است که در Git با دست خراب می‌شود: rebase کردن `docs` پس از تغییر `ui`، کامیت‌های قدیمی `ui` را دوباره می‌آورد، مگر این‌که `git rebase --onto` یادتان بماند. ```bash zev stack bottom # …اصلاح و کامیت… zev stack restack ✓ ui is back on top of api ✓ docs is back on top of ui ``` کل restack یک عملیات است، پس یک `zev undo` همه‌اش را برمی‌گرداند. اگر شاخه‌ای تعارض داشته باشد، restack همان‌جا می‌ایستد و می‌گوید کدام شاخه و چه باید کرد. هر چه پایین‌تر است restack‌شده می‌ماند. ## بازبینی: zev stack push ```bash zev stack push ✓ #12 api → main opened ✓ #13 ui → api opened ✓ #14 docs → ui opened ``` هر شاخه push می‌شود و درخواست ادغام خودش را می‌گیرد که به شاخهٔ زیرش نشانه رفته، پس هرکدام فقط تغییر خودش را نشان می‌دهد. توضیح هرکدام کل پشته را فهرست می‌کند و نشان می‌دهد کدام را می‌بینید. پس از تغییرها دوباره push کنید تا همان درخواست‌ها به‌روز شوند: zev فهرست پشتهٔ خودش را جایگزین می‌کند و هر چه بالای آن نوشته‌اید می‌ماند. ## ادغام از پایین: zev stack sync اول درخواست ادغام پایینی را ادغام کنید. بعد: ```bash zev stack sync ✓ api is merged into main: taken out of the stack zev stack push ✓ #13 ui → main retargeted ``` `sync` شاخهٔ پایه را pull می‌کند، شاخه‌های ادغام‌شده را از پشته بیرون می‌آورد (و در رایانهٔ شما پاکشان می‌کند) و بقیه را روی پایه restack می‌کند. push بعدی درخواست ادغام بعدی را به `main` نشانه می‌رود. تا خالی شدن پشته تکرار کنید. ## دستورها ```text zev stack پشته‌ای که رویش هستید zev stack add <name> شاخه‌ای تازه روی این یکی zev stack up | down | top | bottom zev stack restack هر شاخه دوباره روی زیرینش zev stack sync pull پایه، کنار گذاشتن ادغام‌شده‌ها، restack zev stack push push همه، هرکدام یک درخواست ادغام zev stack remove [<name>] بیرون آوردن شاخه از پشته (شاخه می‌ماند) zev stack list همهٔ پشته‌های این‌جا ``` همه‌شان `--json` و `--brief` را می‌پذیرند. یک عامل می‌تواند کار خودش را به پشته‌ای بازبینی‌پذیر تقسیم کند و وضعیت پشته را در یک خط بخواند: ```text $ zev stack --brief stack api on main: api(2) > ui*(1,restack) > docs(1) ``` ## تفاوتش با Git Git تکه‌ها را دارد (`branch`، `rebase --onto`، ابزاری جدا برای باز کردن درخواست ادغام) اما چیزی ندارد که بداند این شاخه‌ها به هم تعلق دارند. ترتیب را خودتان نگه می‌دارید، هر شاخه را با دست rebase می‌کنید، پس از هر ادغام مقصد درخواست‌ها را با دست عوض می‌کنید، و یک rebase اشتباه کامیت‌ها را تکراری می‌کند. در zev پشته بخشی از مخزن است، restack همهٔ شاخه‌ها را یک‌جا و درست جابه‌جا می‌کند، و push و sync درخواست‌های ادغام را همگام نگه می‌دارند. همچنین ببینید: [شاخه‌ها و ادغام](/docs/fa/branches)، [هر کاری را برگردانید](/docs/fa/undo).