شاخهٔ اصلی جلو رفت؛ تغییرهای تو چه می‌شوند؟Main moved forward. What happens to your work?

فرض کن از commit B شاخه گرفتی و دو commit محلی ساختی. هم‌زمان، همکارت main را تا C جلو برده است. هنوز هیچ‌کدام از commitهای تو را push نکرده‌ای و همکارت هم روی آن‌ها حساب نکرده. می‌خواهی کار تو از نسخهٔ تازهٔ main شروع شود، نه از نسخهٔ قدیمی‌تر.

Suppose you branched from commit B and made two local commits. Meanwhile, a teammate advanced main to C. You have not pushed your commits, and nobody else depends on them. You want your work to start from the newer main rather than the older snapshot.

در فصل ۰۶، merge را دیدیم: دو مسیر را نگه می‌دارد و نتیجه را به هم وصل می‌کند. این بار قبل از فرمان، یک گراف کوچک می‌سازیم و شناسههای commitها را ثبت می‌کنیم. بعد می‌پرسیم آیا rebase فقط اشاره‌گر شاخه را جابه‌جا می‌کند یا واقعاً چیز دیگری می‌سازد.

Chapter 06 showed merge preserving two lines and joining their results. This time we will create a small graph and record the commit IDs before running anything. Then we will ask whether rebase merely moves a branch pointer or actually creates something new.

rebase commitها را جابه‌جا نمی‌کندRebase does not move the old commits

در فصل ۰۲ دیدیم یک commit به tree و commit والدش اشاره می‌کند و فراداده هم دارد. پس اگر همان تغییرها این بار بعد از C ثبت شوند، والد فرق می‌کند؛ در نتیجه commit جدید، شناسه جدیدی هم دارد. commitهای قدیمی D و E پاک یا منتقل نمی‌شوند؛ Git تغییرهایشان را یکی‌یکی روی پایهٔ تازه بازپخش می‌کند و commitهای جایگزین D′ و E′ می‌سازد.

Chapter 02 showed that a commit points to a tree and its parent commit, and also carries metadata. If the same changes are recorded after C, the parent differs, so the resulting commits have new IDs. The old D and E are not moved or erased; Git replays their changes one by one on the new base and creates replacement commits D′ and E′.

آزمایش اول: تغییرها را روی main تازه بنشانFirst experiment: replay onto the newer main

برای اینکه نتیجه را بی‌خطر ببینیم، مخزن تازه‌ای می‌سازیم. هر commit فایل جداگانه‌ای می‌سازد تا این آزمایش تعارض نداشته باشد. مخزن باید بدون تغییر باشد؛ اگر دستورهای ساخت پوشه در shell تو فرق دارند، همان کار را با فایل‌ساز خودت انجام بده.

To inspect the result safely, create a fresh repository. Each commit adds a separate file, so this experiment will not conflict. Keep the repository clean; if your shell uses different directory-creation commands, create the same files with your editor.

mkdir rebase-lab && cd rebase-lab
git init -b main
git config user.name 'Nika Example'
git config user.email 'nika@example.test'
printf 'base\n' > README.txt
git add README.txt && git commit -m 'Add base'
git switch -c feature/search
printf 'search\n' > search.txt
git add search.txt && git commit -m 'Add search'
printf 'filters\n' > filters.txt
git add filters.txt && git commit -m 'Add filters'
git switch main
printf 'operations\n' > operations.txt
git add operations.txt && git commit -m 'Add operations note'
git switch feature/search
git log --oneline --graph --decorate --all
git rev-parse feature/search
git rev-parse feature/search~1
git rebase main
git log --oneline --graph --decorate --all
git rev-parse feature/search
git rev-parse feature/search~1
git status --short

قبل از rebase، خروجی log باید یک انشعاب از commit پایه نشان دهد: main روی یادداشت operations است و قابلیت دو commit خودش را دارد. دو شناسه را هم نگه دار؛ یکی برای E و دیگری برای D. بعد از git rebase main، همان نام قابلیت به نوک تازهٔ زنجیره اشاره می‌کند و log خطی می‌شود.

Before rebase, the log should show a split from the base: main ends at the operations note, while feature has its two commits. Keep the two IDs—one for E and one for D. After git rebase main, the feature name points to the new chain’s tip and the visible graph is linear.

* <new-E> (HEAD -> feature/search) Add filters
* <new-D> Add search
* <C> (main) Add operations note
* <B> Add base

این خروجیِ نماینده است؛ شناسه‌ها و شکل کوتاهشان در هر مخزن فرق می‌کند. حالا git rev-parse feature/search و feature/search~1 را با شناسههای قبلی مقایسه کن: معمولاً هر دو تغییر کرده‌اند. برای دیدن محتوای نهایی، git show --stat یا فایل‌ها را بررسی کن. بدون تغییر بودن git status فقط می‌گوید تغییر ثبت‌نشده‌ای باقی نمانده؛ درست بودن رفتار برنامه را ثابت نمی‌کند.

This is representative output; IDs and abbreviated forms vary by repository. Compare the new results of git rev-parse feature/search and feature/search~1 with the saved IDs: normally both changed. Inspect the final files or use git show --stat. A clean git status only proves there are no uncommitted changes; it does not prove the application behaves correctly.

اگر بازپخش به تعارض بخوردWhen replay reaches a conflict

rebase قرار نیست اختلاف معنایی را حدس بزند. تصور کن commit قدیمی می‌خواهد مقدار timeout را از ۱۰ به ۳۰ برساند، اما main همان مقدار را ۶۰ کرده. Git تلاش می‌کند patch قدیمی را روی متن تازه اجرا کند و برای انتخاب نهایی از تو کمک می‌خواهد.

Rebase cannot guess semantic intent. Suppose an old commit changes timeout from 10 to 30, while main changed it to 60. Git tries to apply the old patch to the new text and asks you to decide the final result.

در مخزن آزمایشی جداگانه، فایل را در شاخهٔ قابلیت به ۳۰ و در main به ۶۰ تغییر بده و از هر طرف commit بساز. وقتی روی قابلیت هستی، git rebase main را اجرا کن. برای اینکه تعارض واقعی و قابل‌فهم باشد، هر دو تغییر باید همان خط را از یک پایه تغییر داده باشند؛ این تمرین را روی مخزن واقعی یا کاریِ نیمه‌تمام اجرا نکن.

In a separate disposable repository, change the file to 30 on feature and to 60 on main, committing each side. While on feature, run git rebase main. For a clear conflict, both edits must change the same line from the same base. Do not run this exercise in a real or unfinished working repository.

mkdir rebase-conflict-lab && cd rebase-conflict-lab
git init -b main
git config user.name 'Nika Example'
git config user.email 'nika@example.test'
printf 'timeout=10\n' > settings.txt
git add settings.txt && git commit -m 'Set base timeout'
git switch -c feature/timeout
printf 'timeout=30\n' > settings.txt
git add settings.txt && git commit -m 'Set feature timeout'
git switch main
printf 'timeout=60\n' > settings.txt
git add settings.txt && git commit -m 'Set main timeout'
git switch feature/timeout
git rebase main

CONFLICT (content): Merge conflict in settings.txt
error: could not apply <old-D>... Set timeout to 30

git status
git rebase --show-current-patch
git show HEAD:settings.txt
git show REBASE_HEAD:settings.txt

اول git status را بخوان تا نام فایل‌های حل‌نشده و راهنمای ادامه را ببینی. git rebase --show-current-patch patch همان commitی را نشان می‌دهد که Git نتوانسته بازپخش کند. در این rebase ساده، HEAD نسخهٔ پایهٔ فعلیِ بازپخش‌شده است؛ REBASE_HEAD commit قدیمی‌ای را نشان می‌دهد که Git در حال بازپخش کردنش بود. این شواهد کمک می‌کنند، اما هیچ‌کدام نمی‌گویند مقدار درست محصول ۳۰ است یا ۶۰؛ تصمیم را از نیاز برنامه بگیر.

Start with git status to see unresolved paths and the suggested next step. git rebase --show-current-patch displays the patch Git could not replay. In this simple rebase, HEAD is the current rebased base, while REBASE_HEAD identifies the old commit being replayed. These are evidence, not a product decision: they cannot tell you whether 30 or 60 is correct.

فایل را با مقدار درست اصلاح کن، نشانگرهای تعارض را بردار، سپس فقط همان فایل حل‌شده را ناحیه‌ آماده‌سازی کن. حالا Git می‌داند این نسخه را برای ادامهٔ بازپخش انتخاب کرده‌ای:

Edit the file to the intended value, remove conflict markers, then stage the resolved path. Git can now continue replaying the series:

git diff -- settings.txt
git add settings.txt
git status
git rebase --continue

ممکن است commit بعدی هم تعارض داشته باشد؛ هر patch جداگانه بازپخش می‌شود و هر توقف را دوباره باید بررسی کرد. اگر تصمیم گرفتی کل rebase آزمایشی را کنار بگذاری، git rebase --abort را اجرا کن. اگر --skip بزنی، Git از commit فعلی می‌گذرد و patch همان commit عمداً وارد تاریخچهٔ تازه نمی‌شود؛ این گزینه برای «ردشدن از خطا» نیست. فقط وقتی مطمئنی آن تغییر لازم نیست یا از قبل در پایه هست، skip کن.

A later commit may conflict too: each patch is replayed separately, so inspect each pause. To abandon the entire test rebase, run git rebase --abort. If you run --skip, Git skips the current commit and its patch is intentionally absent from the new history. This is not a way to skip an error; use it only when you know the change is unnecessary or already present in the base.

وقتی چند commit محلی را برای بازبینی مرتب می‌کنیTidying a local series for review

چند روز روی یک قابلیت کار کرده‌ای: اول یک commit با پیام WIP، بعد یک رفع ایراد کوچک، بعد یک اصلاح پیام مستندات. حالا قبل از اینکه تاریخچه را با تیم به اشتراک بگذاری، می‌خواهی پیام‌ها روشن باشند و اصلاح کوچک کنار commit اصلی‌اش بیاید. git rebase -i فهرست commitهای محلی را برایت باز می‌کند تا ترتیب و دستور هر کدام را انتخاب کنی.

You have worked on a feature for a few days: a WIP commit, a small fix, then a documentation correction. Before sharing the history, you want clear messages and the small fix folded into its original commit. git rebase -i opens the local commit list so you can choose each action and its order.

این فرمان چهار commit بعد از پایه را فهرست می‌کند. قبل از اجرا، پوشه‌ کاری را بدون تغییر کن و یک اشاره‌گر پشتیبان بساز؛ rebase تعاملی تاریخچه را عوض می‌کند. فهرست todo از قدیمی به جدید است: سطر بالاتر زودتر بازپخش می‌شود. اگر ترتیب را تغییر بدهی، معنای patchهای بعدی هم ممکن است تغییر کند و تعارض تازه‌ای بسازد.

This command lists the four commits after the base. Before running it, clean the working tree and create a backup ref; interactive rebase rewrites history. The todo list runs oldest to newest: the top row is replayed first. Reordering can change how later patches apply and may create new conflicts.

git switch feature/search
git status --short
git branch backup/feature-search-before-rebase
git rebase -i HEAD~4

pick    a1b2c3d Add search parser
fixup   b2c3d4e Handle empty input
reword  c3d4e5f WIP: add filter option
pick    d4e5f6a Add parser tests

این فقط نمونهٔ شکل فهرست است؛ Git شناسه و پیام واقعی مخزن تو را می‌گذارد. fixup تغییر commit را در قبلی ادغام و پیام خودش را دور می‌اندازد. اگر می‌خواهی پیام‌ها را ترکیب یا ویرایش کنی، squash همان تغییرها را جمع می‌کند اما ویرایش پیام نهایی را پیشنهاد می‌دهد. reword فقط پیام را عوض می‌کند؛ drop commit را از سری حذف می‌کند؛ و edit وسط کار مکث می‌کند تا بتوانی commit را تغییر بدهی یا تقسیم کنی.

This illustrates the todo shape; Git supplies the real IDs and messages. fixup folds a commit into the previous one and discards its message. squash also combines the changes but lets you edit the resulting message. reword changes only the message; drop removes a commit from the series; and edit pauses so you can amend or split it.

وقتی یک commit قدیمی را reword، fixup یا جابه‌جا می‌کنی، commitهای بعد از آن هم روی والد جدید ساخته می‌شوند. بنابراین شناسه همهٔ فرزندان آن نقطه عوض می‌شود، حتی اگر patchشان دست‌نخورده مانده باشد. پس بعد از پایان، فقط به پیام‌های log نگاه نکن: تست‌ها را اجرا کن، diff را بخوان و نتیجهٔ برنامه را بررسی کن.

When an earlier commit is reworded, fixed up, or moved, later commits are rebuilt on new parents. Their IDs change even if their patches did not. Afterward, do more than read the log: run tests, inspect the diff, and verify application behavior.

merge و rebase: دو پاسخ به دو نیازMerge and rebase: two answers to different needs

در فصل ۰۶، merge راه حفظ دو مسیر واقعی بود: Git نتیجه را می‌ساخت و معمولاً commitی با دو والد اضافه می‌کرد. rebase همان تغییرها را با والدهای تازه بازپخش می‌کند و یک زنجیرهٔ خطی می‌سازد. یکی «درست» و دیگری «غلط» نیست؛ مهم است بدانی تاریخچه قرار است چه چیزی را برای خوانندهٔ بعدی نگه دارد.

Chapter 06 used merge to preserve two real lines: Git combines the result and usually adds a two-parent commit. Rebase replays the changes with new parents and creates a linear series. Neither is inherently right or wrong; choose based on what the history should communicate to the next reader.

انتخاب به تیم، نوع شاخه و چیزی که می‌خواهید تاریخچه ثبت کند بستگی دارد. برای شاخهٔ کوتاه و خصوصی، مرتب‌کردن محلی معمولاً کم‌هزینه است. برای شاخه‌ای که چند نفر روی آن کار می‌کنند، اول دربارهٔ بازنویسی هماهنگ شو؛ شاید حفظ تاریخچه با merge مناسب‌تر باشد.

The choice depends on the team, branch, and what the history should record. Tidying a short private branch is usually low-cost. If several people use the branch, coordinate before rewriting; preserving it with merge may be a better fit.

قانون طلایی از سازوکار می‌آید، نه از شعارThe golden rule follows from the mechanism, not a slogan

تا اینجا شاخهٔ ما خصوصی بود. حالا تصور کن همکارت commit قدیمی E را دریافت کرده و شاخه خودش به آن اشاره می‌کند. تو rebase می‌کنی و شاخهٔ خودت به E′ می‌رسد. همکارت هنوز E را دارد؛ Git نمی‌تواند اشاره‌گر او را از راه دور حدس بزند یا جابه‌جا کند.

So far the branch was private. Now imagine a teammate fetched old commit E and has a branch pointing to it. You rebase and your branch now points to E′. Your teammate still has E; Git cannot guess or move their ref remotely.

پس «هیچ‌وقت چیزی را که push کرده‌ای rebase نکن» قانون مطلق Git نیست؛ نکته این است که آیا کسی دیگر به همان شناسهها تکیه کرده؟ اگر نه، بازنویسی ممکن است با هماهنگی درست باشد. اگر بله، قبل از تغییر تاریخچه با هم‌تیمی‌ها توافق کن، وضعیت شاخه را روشن کن و برای ادغام مجدد برنامه داشته باش. push معمولی معمولاً تغییر غیر fast-forward را نمی‌پذیرد؛ زورزدن بدون هماهنگی می‌تواند commitهای تازهٔ دیگران را از نوک شاخه کنار بزند.

“Never rebase anything you pushed” is not a universal Git law. The key question is whether someone else depends on those IDs. If nobody does, a rewrite may be acceptable with coordination. If they do, agree first, identify the exact branch state, and plan how to integrate everyone’s work. A normal push generally rejects a non-fast-forward update; forcing it without coordination can displace teammates’ newer commits.

در فصل ۰۸ دربارهٔ مخزن‌های راه دور و push دقیق‌تر کار می‌کنیم. فعلاً نام --force-with-lease را بشناس: برخلاف --force کور، بررسی می‌کند اشاره‌گر دوردست هنوز در وضعیتی باشد که انتظار داری؛ اگر از زمان بررسی تو عوض شده باشد، push را رد می‌کند. این یک حفاظ مفید است، نه جایگزین هماهنگی یا تضمین کامل؛ تغییر پنهان یا برداشت نادرست از وضعیت مخزن راه دور هنوز می‌تواند مسئله‌ساز شود.

Chapter 08 will cover remotes and pushing properly. For now, recognize --force-with-lease: unlike blind --force, it checks that the remote ref is still at the value you expect and rejects the update if it has changed. It is a useful guard, not a substitute for coordination or a complete guarantee; hidden updates or a mistaken view of the remote can still cause trouble.

وقتی rebase آن‌طور که انتظار داشتی پیش نمی‌رودWhen rebase does not go as expected

اگر rebase گیج‌کننده شد، دنبال «دستور نجات جادویی» نگرد. اول ببین Git در حال بازپخش کدام commit است، روی چه پایه‌ای و فایل الان چه شکلی شده. بعد تصمیم بگیر ادامه بدهی، رد کنی یا کل عملیات را لغو کنی.

If the operation pauses, do not delete history or reset blindly. First identify the current branch and patch. During a rebase, each stop message is evidence about the current step.

تمرین‌ها: از پیش‌بینی تا تصمیم تیمیExercises: from prediction to team decisions

تمرین‌های این بخش بیشتر از شکل دستور دربارهٔ پیامدند. قبل از اجرا پیش‌بینی کن کدام commitها شناسهٔ تازه می‌گیرند، گراف چه شکلی می‌شود و اگر این تاریخ قبلاً با تیم مشترک شده باشد چه کسی ممکن است آسیب ببیند.

Write a short answer before opening each solution. The goal is not to memorize rebase options; it is to use the graph, Git’s messages, and your teammates’ state to decide whether it is safe to continue.

پروژهٔ کوچک: از شاخهٔ شلوغ تا سری آمادهٔ بازبینیMini-project: from a messy branch to a reviewable series

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

Nika built a private search feature, but its history contains temporary notes and small corrections. She asks you to prepare it for review without silently changing the final content. Do this in a disposable repository; the goal is to tidy history, not publish or push it.

پروژه باید چهار commit محلی داشته باشد: پیاده‌سازی parser، اصلاح edge case، پیام موقت برای فیلترها، و تست‌ها. قبل از ویرایش todo، ابتدا نام شاخه و پاک‌بودن مخزن را بررسی کن. سپس یک اشاره‌گر پشتیبان بساز و شناسه نوک شاخه و tree فعلی را یادداشت کن:

Create four local commits: parser implementation, an edge-case fix, a temporary filter message, and tests. Before editing the todo, verify the branch name and clean state. Create a backup ref and record the current tip and tree:

git status --short
git branch --show-current
git branch backup/search-before-review
git rev-parse HEAD
git rev-parse HEAD^{tree}
git log --oneline --reverse main..HEAD

حالا git rebase -i main را باز کن. ترتیب commitها را با وابستگی واقعی‌شان بررسی کن؛ پیام موقت را با reword به پیامی روشن تبدیل کن و اصلاح edge case را با fixup یا squash کنار parser بگذار. اگر از squash استفاده کردی، پیام نهایی را طوری بنویس که هر دو تغییر را توضیح دهد. هر تغییری در ترتیب را با تست‌ها توجیه کن؛ برای «زیباترشدن گراف» dependency را نشکن.

Now open git rebase -i main. Check the real dependency order; use reword to replace the temporary message and fixup or squash to fold the edge-case correction into the parser commit. With squash, write a message that describes both changes. Justify any reordering with tests; do not break dependencies merely to make the graph look prettier.

پس از پایان، این شواهد را جمع کن:

When it finishes, collect this evidence:

git status --short
git log --oneline --graph --decorate --all
git rev-parse HEAD
git rev-parse HEAD^{tree}
git diff --exit-code backup/search-before-review HEAD
git diff --stat backup/search-before-review HEAD
git show --stat --oneline HEAD

tree نوک شاخه جدید را با مقدار ثبت‌شده مقایسه کن. اگر هدف فقط مرتب‌کردن commitها بوده، tree نهایی باید همان باشد؛ git diff --exit-code backup/search-before-review HEAD در صورت برابری treeها خروجی خالی و exit وضعیت صفر می‌دهد. بعد تعداد و پیام commitها را در گراف بخوان و تست برنامه را اجرا کن. اگر محتوا فرق دارد، تفاوت را ببین و علتش را بفهم؛ برابری در یک آزمایش هم به‌تنهایی صحت معنایی برنامه را ثابت نمی‌کند.

Compare the new tip’s tree with the saved value. If the goal was only to reorganize commits, the final tree should be identical; git diff --exit-code backup/search-before-review HEAD is silent and exits zero when the trees match. Then review the graph and commit messages, and run the application tests. If content differs, inspect and explain it; identical trees in one experiment still do not prove semantic correctness.

اشاره‌گر پشتیبان را تا وقتی بازبینی تمام نشده نگه دار. این اشاره‌گر تغییر ثبت‌نشده‌ای را پوشش نمی‌دهد و خودبه‌خود نسخهٔ منتشرشده نمی‌سازد. اگر چیزی از بین رفته یا tree عوض شده، اول علت را بررسی کن؛ پروژه به push یا حذف اشاره‌گر پشتیبان نیاز ندارد.

Keep the backup ref until review is complete. It does not protect uncommitted changes or publish a copy elsewhere. If something is missing or the tree changed, investigate first; this project requires neither pushing nor deleting the backup ref.

این بار همه‌چیز محلی بودEverything so far was local

تا اینجا همهٔ تغییرها روی یک ماشین بودند. حالا یک مخزن دیگر وارد داستان می‌شود و اسم‌هایی مثل origin/main ظاهر می‌شوند. فصل بعد کاری می‌کند که fetch، pull و push از حالت جادو بیرون بیایند.

In this chapter, main and feature were refs in the same repository. We have not contacted a second repository or pushed anything. Chapter 08 adds a remote and distinguishes names such as origin/main from local main; then we can connect local rewriting to real collaboration and pushing.

مرور کوتاهQuick reference