یک بار Git جلو رفت؛ بار دوم مکث کردGit moved forward once, then paused

در فصل ۰۵ دیدیم دو شاخه می‌توانند از یک commit شروع شوند و هرکدام اشاره‌گر مستقلی داشته باشند. حالا وقت برگرداندن یک مسیر به شاخهٔ اصلی است. اول پیش‌بینی کن: اگر شاخهٔ قابلیت فقط یک commit جلوتر باشد و main هیچ commit تازه‌ای نداشته باشد، آیا Git باید commit جدیدی بسازد؟

Chapter 05 showed two branches starting at one commit, each with its own ref. Now we need to bring one line back to the main branch. Predict first: if feature is one commit ahead and main has not added a commit, must Git create a new commit?

برای آزمایش، مخزن جداگانه می‌سازیم. یک شاخه جلو می‌رود؛ بعد main آن را merge می‌کند. فایل اصلی را نگاه کن، اما مهم‌تر از آن، شناسهها و شکل گراف را بخوان.

We’ll use a separate repository. One branch advances, then main merges it. Inspect the file, but more importantly, compare commit IDs and graph shape.

mkdir merge-lab && cd merge-lab
git init -b main
git config user.name 'Nika Example'
git config user.email 'nika@example.test'
printf 'سلام\n' > greeting.txt
git add greeting.txt
git commit -m 'Add greeting'
git switch -c feature/welcome
printf 'سلام به همه\n' > greeting.txt
git add greeting.txt
git commit -m 'Improve greeting'
git switch main
git rev-parse HEAD
git rev-parse feature/welcome
git merge feature/welcome
git log --oneline --graph --decorate --all

قبل از merge، main نیاکان مستقیم feature/welcome است؛ شاخه‌ها از هم جدا نشده‌اند. merge پیش‌فرض فقط اشاره‌گر شاخهٔ جاری را به commit جلوتر می‌برد. اگر دو شناسه آخر را بعد از merge مقایسه کنی، main و قابلیت روی یک commit‌اند و commit سومی ساخته نشده است. این حرکت مستقیم را fast-forward می‌گوییم.

Before merging, main is a direct ancestor of feature/welcome; the tips have not diverged. The default merge simply advances the current branch ref to the descendant. Afterward, the two refs resolve to the same commit, and no third commit was created. That direct move is a fast-forward.

وقتی هر دو شاخه جلو رفته‌اندWhen both branches have advanced

حالا شکل سخت‌تر را بسازیم. بعد از C1، main روی C2 تغییر مستقلی می‌دهد و قابلیت هم روی C3 تغییر خودش را. هیچ‌کدام نیاکان دیگری نیست. Git برای ساخت نتیجه باید بفهمد هر طرف از نقطهٔ مشترک چه تغییری داده است.

Now create the harder shape. After C1, main makes an independent change at C2 and feature makes its own at C3. Neither tip is an ancestor of the other. To build a result, Git must determine what each side changed since their shared point.

git switch -c feature/notes
printf 'notes enabled\n' > notes.txt
git add notes.txt
git commit -m 'Add notes'
git switch main
printf 'release=1\n' > release.txt
git add release.txt
git commit -m 'Record release'
git merge-base main feature/notes
git merge feature/notes
git rev-list --parents -n 1 HEAD
git log --oneline --graph --decorate --all

در این مثال تغییرها به فایل‌های جدا می‌رسند، پس می‌توانند بی‌تعارض کنار هم قرار بگیرند. چون نوک‌ها واگرا شده‌اند، Git commit تازه‌ای می‌سازد که دو والد دارد: نوک قبلی main و نوک feature. git rev-list --parents -n 1 HEAD یک شناسه برای merge commit و دو شناسه والد نشان می‌دهد.

Here the changes touch different files, so Git can combine them without conflict. Because the tips diverged, Git creates a new commit with two parents: the former main tip and the feature tip. git rev-list --parents -n 1 HEAD prints the merge commit ID followed by its two parent IDs.

این نقطهٔ مشترک را merge base می‌نامیم. در گراف‌های ساده یک merge base روشن داریم؛ تاریخچه‌های پیچیده‌تر ممکن است چند بهترین merge base داشته باشند و الگوریتم پیش‌فرض آن‌ها را هم مدیریت می‌کند. فعلاً لازم نیست در آن پیچیدگی فرو برویم. نکتهٔ امروز این است: Git فقط دو فایل آخر را کنار هم نمی‌گذارد؛ تغییرهای هر دو را از پایهٔ مشترک می‌سنجد.

That shared point is the merge base. Simple graphs have one obvious base; more complex histories can have multiple best merge bases, which the default strategy can handle. We do not need that complexity yet. The key idea is that Git does not merely compare two final files—it evaluates both sides' changes from their common base.

تعارض یعنی نیتِ لازم را Git نمی‌داندA conflict means Git lacks the intent it needs

تا وقتی دو تغییر در بخش‌های جدا باشند، Git معمولاً می‌تواند هر دو را نگه دارد. اما اگر main یک خط را «سلام به محصول» و قابلیت همان خط را «سلام به مهندسی» کند، کدام‌یک باید نسخهٔ نهایی باشد؟ این سؤال فنی نیست؛ تصمیم محصول است.

When changes affect separate regions, Git can usually retain both. But if main changes one line to “Hello product” and feature changes that same line to “Hello engineering,” which should the final version say? That is a product decision, not a technical fact.

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

Git is not broken. The merge machinery can compare changes against the base, but it does not know the team's contract or the meaning of the text. When edits are incompatible, Git stops rather than choosing arbitrarily.

حل تعارض: اول قصد، بعد ویرایشResolve a conflict: intent before editing

تعارض را در یک مخزن دورریختنی می‌سازیم. قبل از merge، git status باید بدون تغییر باشد؛ این کار احتمال گیرکردن تغییرهای نامرتبط را کم می‌کند و abort را قابل‌پیش‌بینی‌تر نگه می‌دارد. اگر پروژهٔ واقعی داری، اول تغییرها را commit کن؛ merge را روی پوشهٔ نیمه‌کاره امتحان نکن.

We’ll create a conflict in a disposable repository. Before merging, git status should be clean; this reduces the chance that unrelated work becomes entangled and makes abort more predictable. In a real project, commit your work first—do not experiment on a half-finished tree.

printf 'سلام به تیم\n' > greeting.txt
git add greeting.txt
git commit -m 'Add shared greeting'
git switch -c feature/product
printf 'سلام به تیم محصول\n' > greeting.txt
git add greeting.txt
git commit -m 'Address product team'
git switch main
printf 'سلام به تیم مهندسی\n' > greeting.txt
git add greeting.txt
git commit -m 'Address engineering team'
git status --short
git merge feature/product

پیام CONFLICT (content) و Automatic merge failed یعنی Git ترکیب نهایی را ثبت نکرده و merge هنوز در جریان است. این خطا نمی‌گوید کدام جمله بهتر است. فایل را باز کن و قبل از دست‌زدن به نشانگرها تصمیم بگیر: آیا باید محصول، مهندسی، یا هر دو در متن باشند؟

A CONFLICT (content) message and Automatic merge failed mean Git did not record a final combination and the merge is still in progress. The error does not say which sentence is better. Open the file and decide before touching markers: should the message address product, engineering, or both?

<<<<<<< HEAD
سلام به تیم مهندسی
=======
سلام به تیم محصول
>>>>>>> feature/product

در این merge مشخص، بخش بالای ======= نسخهٔ ours یعنی main فعلی است؛ بخش پایین نسخهٔ theirs یعنی feature/product. نشانگرها دستور Git نیستند؛ متن راهنما هستند که باید از نسخهٔ نهایی حذف شوند. انتخاب یک طرف هم همیشه جواب نیست: شاید جملهٔ درست «سلام به تیم محصول و مهندسی» باشد.

In this merge, the section above ======= is ours—the current main branch; below it is theirs—feature/product. Markers are not Git commands; they are guidance that must not remain in the final version. Choosing one side is not always right: perhaps the intended line is “Hello product and engineering teams.”

فایل را به جملهٔ موردنظر تبدیل کن؛ سپس خودت دوباره بخوانش، نشانگرها را جست‌وجو کن و بعد ناحیه‌ آماده‌سازی کن:

Edit the file to the intended sentence; then read it back, search for leftover markers, and only then stage it:

printf 'سلام به تیم محصول و مهندسی\n' > greeting.txt
git diff --check
git diff -- greeting.txt
git add greeting.txt
git status
git diff --cached
git merge --continue
git status --short --branch
git log --oneline --graph --decorate --all

پس از git add، مسیر از ناحیه‌ آماده‌سازیهای unmerged به یک رد عادی ناحیه‌ آماده‌سازی 0 می‌رود. git merge --continue merge commit را کامل می‌کند؛ git commit هم می‌تواند آن را تمام کند. قبل از ادامه، diff آماده‌شده را بازبینی کن. موفقیت یعنی هم فایل نهایی قصد را نشان بدهد، هم وضعیت از حالت merge بیرون آمده باشد.

After git add, the path moves from unmerged index entries to one ordinary stage-0 entry. git merge --continue completes the merge commit; git commit can complete it too. Review the staged diff first. Success means the file expresses the intended result and status no longer reports a merge in progress.

سه نسخهٔ حل‌نشده در ناحیه‌ آماده‌سازی کجا هستند؟Where do the three unresolved versions live?

وقتی نشانگر را در فایل می‌بینی، شاید فکر کنی Git فقط یک متن مبهم روی دیسک گذاشته. در واقع ناحیه‌ آماده‌سازی هم تا زمان حل، نسخه‌های جداگانه را نگه می‌دارد. با git ls-files -u می‌توانی ببینی هر مسیر چه ردهای unmerged دارد.

When you see markers in a file, it may look as if Git left only one ambiguous text on disk. In fact, the index retains separate versions until resolution. git ls-files -u shows the unmerged entries for each path.

git ls-files -u
100644 15ab... 1	greeting.txt
100644 91cd... 2	greeting.txt
100644 6ef0... 3	greeting.txt
git show :1:greeting.txt
git show :2:greeting.txt
git show :3:greeting.txt

سه شناسهٔ متفاوت نشان می‌دهد Git نسخهٔ پایه، ours و theirs را حفظ کرده است؛ هر سه مربوط به یک مسیرند. بعد از حل و git add، git ls-files -u برای آن مسیر دیگر چیزی چاپ نمی‌کند. این فقط می‌گوید ناحیه‌ آماده‌سازی آن مسیر unmerged نیست؛ درست‌بودن معنایی متن را باید خودت بازبینی کنی.

Three different IDs show that Git retained the base, ours, and theirs for one path. After resolving and running git add, git ls-files -u prints nothing for that path. This proves the index is no longer unmerged; you must still review whether the text is semantically correct.

تعارض همیشه دو متن کنار هم نیستA conflict is not always two text blocks

فرض کن main یک سیاست را اصلاح می‌کند و شاخهٔ دیگر همان فایل را حذف می‌کند. اینجا نشانگرهای سه‌خطی داخل فایل کافی نیستند؛ سؤال انسانی این است که آیا فایل هنوز لازم است؟ Git نمی‌تواند این تصمیم را از تاریخچه حدس بزند.

Suppose main updates a policy while another branch deletes the same file. Three text-marker lines cannot express this decision. The human question is whether the file is still needed—a decision Git cannot infer from history.

git status
git ls-files -u
git show :1:policy.txt
git show :2:policy.txt
git show :3:policy.txt

در این نمونه فرض کرده‌ایم ours فایل را تغییر داده و theirs حذفش کرده؛ ناحیه‌ آماده‌سازی 1 و 2 وجود دارند، اما ناحیه‌ آماده‌سازی 3 ممکن است اصلاً نباشد. نبودن ناحیه‌ آماده‌سازی یعنی آن سمت برای این مسیر فایل نداشته؛ فرمان git show :3:policy.txt پس شکست می‌خورد. در حالت برعکس، ناحیه‌ آماده‌سازی 2 غایب می‌شود. همیشه خروجی ls-files -u را بخوان، نه اینکه وجود هر سه را فرض بگیری.

Here we assume ours modified the file and theirs deleted it: stages 1 and 2 exist, but stage 3 may be absent. A missing stage means that side had no file at this path, so git show :3:policy.txt fails. In the reverse case, stage 2 is absent. Read ls-files -u; never assume all three exist.

اگر تصمیم این است که نسخهٔ اصلاح‌شده بماند، فایل را بازبینی و با git add policy.txt ثبت کن. اگر باید حذف بماند، git rm policy.txt را بزن. هر دو فرمان به Git می‌گویند «این تصمیم نهایی من برای ناحیه‌ آماده‌سازی است»؛ هیچ‌کدام جای تصمیم را نمی‌گیرند.

If the decision is to keep the revised file, review it and stage it with git add policy.txt. If deletion is intended, use git rm policy.txt. Either tells Git “this is my final index decision”; neither makes the decision for you.

اگر تصمیم نداریم، یا کار اشتباه پیش رفتWhen you cannot decide—or the merge went wrong

وسط تعارض لازم نیست قهرمان‌بازی دربیاوری. اگر هنوز تصمیم درست را نمی‌دانی، وضعیت را ثبت کن و در صورت نیاز merge را لغو کن. مهم این است که بفهمی Git کجا متوقف شده و کدام تصمیم را از انسان می‌خواهد.

You do not have to rush through a conflict. If the tree was clean before the merge and you do not have a decision yet, you can abort the in-progress merge. But if you had unfinished work, do not treat abort as a guaranteed rewind button.

git status
git merge --abort
git status --short --branch
git log --oneline --graph --decorate --all

git merge --abort تلاش می‌کند وضعیت قبل از merge را بازسازی کند. اگر تغییرهای محلیِ ثبت‌نشده هنگام شروع داشته‌ای—به‌خصوص اگر بعد از آغاز merge آن‌ها را دستکاری کرده باشی—ممکن است بازسازی کامل ممکن نباشد. برای همین پیش‌بررسی مهم است: git status، و اگر در کار واقعی چیزی ناتمام است، اول آن را جداگانه ثبت یا حفظ کن.

git merge --abort tries to reconstruct the pre-merge state. If you had uncommitted changes when it began—especially if you edited them further after the merge started—Git may not be able to reconstruct everything. That is why the pre-check matters: inspect git status, and preserve unfinished real work separately before merging.

تمرین‌ها: از پیش‌بینی گراف تا تصمیم انسانیExercises: from graph prediction to human decisions

در تمرین‌ها اول گراف را نگاه کن، بعد متن فایل را. بعضی سؤال‌ها اصلاً تعارض ندارند و فقط با حرکت شاخه حل می‌شوند؛ بعضی‌ها merge commit می‌سازند و بعضی‌ها واقعاً به تصمیم انسانی نیاز دارند.

Predict before opening the solution. The exercises move from reading a graph to incidents where Git evidence and product decisions must be separated.

پروژهٔ کوچک: سه تصمیم برای یک محصولMini-project: three integration decisions for one product

mkdir merge-project && cd merge-project
git init -b main
git config user.name 'Nika Example'
git config user.email 'nika@example.test'
printf 'سلام به تیم\n' > greeting.txt
printf 'قانون نسخه: پایدار بماند\n' > policy.txt
printf 'شروع\n' > README.txt
git add .
git commit -m 'Create product docs'

git switch -c feature/changelog
printf 'v1: انتشار آزمایشی\n' > CHANGELOG.txt
git add CHANGELOG.txt && git commit -m 'Add changelog'
git switch main
git switch -c feature/quickstart
printf '۱. نصب\n۲. اجرا\n' > QUICKSTART.txt
git add QUICKSTART.txt && git commit -m 'Add quickstart'
git switch main
git merge feature/changelog
git log --oneline --graph --decorate --all
git merge feature/quickstart
git rev-list --parents -n 1 HEAD
git log --oneline --graph --decorate --all

git switch -c feature/product-greeting
printf 'سلام به تیم محصول\n' > greeting.txt
git add greeting.txt && git commit -m 'Address product team'
git switch main
git switch -c feature/engineering-greeting
printf 'سلام به تیم مهندسی\n' > greeting.txt
git add greeting.txt && git commit -m 'Address engineering team'
git switch main
git merge feature/product-greeting
git merge feature/engineering-greeting
git status
git ls-files -u
git show :1:greeting.txt
git show :2:greeting.txt
git show :3:greeting.txt

printf 'سلام به تیم محصول و مهندسی\n' > greeting.txt
git diff --check
git add greeting.txt
git diff --cached
git merge --continue
git status --short --branch
git log --oneline --graph --decorate --all

git switch -c feature/policy-update
printf 'قانون نسخه: پایدار بماند؛ انتشار فقط پس از بازبینی\n' > policy.txt
git add policy.txt && git commit -m 'Clarify release policy'
git switch main
git switch -c feature/remove-old-policy
git rm policy.txt
git commit -m 'Remove obsolete policy'
git switch main
git merge feature/policy-update
git merge feature/remove-old-policy
git status
git ls-files -u
git show :1:policy.txt
git show :2:policy.txt

git add policy.txt
git diff --cached
git merge --continue
git status --short --branch
git log --oneline --graph --decorate --all
git show HEAD:policy.txt

merge دو خط تاریخ را نگه می‌دارد؛ قدم بعدی چه می‌شود؟Merge preserves both lines—what comes next?

merge هر دو مسیر تاریخ را نگه می‌دارد و یک نقطهٔ اتصال می‌سازد. فصل بعد راه دیگری را می‌بیند: تغییرهای یک مسیر را دوباره روی پایهٔ تازه می‌سازیم؛ کاری که ظاهر گراف را عوض می‌کند و شناسهٔ commitها را هم تغییر می‌دهد.

You can now distinguish a fast-forward from a merge commit, locate the merge base, and read a conflict as an unresolved decision rather than Git malfunction. A merge joins two lines of history with a multi-parent commit.

فصل ۰۷ سؤال تازه‌ای می‌پرسد: اگر به‌جای وصل‌کردن دو مسیر، commitهای خودمان را روی پایهٔ جدید دوباره اجرا کنیم چه می‌شود؟ جواب، rebase است—و چون commit از والدش شناسه می‌گیرد، شناسهها عوض می‌شوند.

Chapter 07 asks a different question: what if instead of joining two lines, we replay our commits onto a new base? That is rebase—and because a commit’s ID depends on its parent, the IDs change.

نقشهٔ سریع mergeQuick merge reference