وقتی یک شاخه می‌سازیم، کپی کجاست؟When we create a branch, where is the copy?

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

The previous chapter showed commits as nodes in a graph. In a repository with one commit, we’ll inspect the current branch and create another. Predict first: will a new file appear? Will the commit ID change?

mkdir branch-pointer-lab
Set-Location branch-pointer-lab
git init -b main
git config user.name 'Nika Example'
git config user.email 'nika@example.test'
'v1' | Out-File -Encoding utf8 app.txt
git add app.txt
git commit -m "Add first version"
git rev-parse refs/heads/main
git branch experiment
git show-ref --heads
3a91c208ed61424d9fdd16f7998c378b52c04b6c refs/heads/experiment
3a91c208ed61424d9fdd16f7998c378b52c04b6c refs/heads/main

در ویندوز PowerShell این نمونهٔ ساخت فایل کار می‌کند؛ در Bash می‌توانی به‌جایش printf 'v1\n' > app.txt بنویسی. دو شناسهٔ کنار refs/heads/main و refs/heads/experiment باید برابر باشند. هنوز commit تازه‌ای نساخته‌ایم؛ فقط یک نام دیگر برای همان نقطهٔ گراف ساخته شده است.

The file-creation line works in PowerShell; in Bash, use printf 'v1\n' > app.txt instead. The IDs beside refs/heads/main and refs/heads/experiment should match. No commit was created: Git added another name for the same graph position.

commit بعدی، کدام نام را جلو می‌برد؟Which name moves when we make the next commit?

تا اینجا هر دو شاخه هم‌مکان‌اند. حالا روی experiment می‌رویم و تغییر کوچکی commit می‌کنیم. سؤال دقیق این است: آیا Git شاخهٔ دیگر را هم جلو می‌برد، یا فقط اشاره‌گر شاخهٔ جاری را؟

So far both branches occupy the same point. Switch to experiment and commit a small change. The precise question is: does Git advance both names, or only the ref for the current branch?

git switch experiment
git symbolic-ref HEAD
'v2 from experiment' | Out-File -Encoding utf8 app.txt
git add app.txt
git commit -m "Try alternate version"
git show-ref --heads
git log --oneline --graph --decorate --all
b7c4e11 (HEAD -> experiment) Try alternate version
3a91c20 (main) Add first version

بعد از switch، خروجی git symbolic-ref HEAD باید refs/heads/experiment باشد. بعد از commit، شناسهٔ آزمایش تغییر می‌کند و main روی C1 می‌ماند. commit جدید C2 فرزند C1 است؛ «جدا شدن شاخه‌ها» یعنی دو اشاره‌گر اکنون نوک‌های متفاوتی از گراف را نام می‌برند.

After switching, git symbolic-ref HEAD should print refs/heads/experiment. After the commit, experiment’s ID changes while main stays at C1. C2 is a child of C1; the branches have diverged in the sense that their refs now name different graph tips.

HEAD دقیقاً کجا ایستاده؟Where exactly is HEAD pointing?

سه نام را از هم جدا کنیم: commitها عکس فوریهای گراف‌اند؛ شاخهها اشاره‌گرهایی هستند که نوک‌های موردعلاقه را نام می‌برند؛ HEAD نشان می‌دهد checkout فعلی از کدام اشاره‌گر یا commit شروع شده است. معمولاً HEAD به شاخه اشاره می‌کند، نه اینکه خودش «شاخه» باشد.

Keep three names distinct: commits are snapshots in the graph; branches are refs naming tips; HEAD identifies the ref or commit currently checked out. Normally HEAD points to a branch—it is not itself the branch.

git symbolic-ref HEAD
git rev-parse HEAD
git rev-parse refs/heads/main
git show-ref --heads

symbolic-ref نام کامل شاخهٔ متصل به HEAD را می‌دهد؛ rev-parse شناسهٔ commit حلشده را. در حالت عادی، دو فرمان دوم برای شاخهٔ فعلی یک شناسه می‌دهند. برای دیدن اشاره‌گرها از show-ref استفاده کن، نه اینکه فرض کنی هر شاخه حتماً یک فایل معمولی در .git/refs/heads دارد؛ Git می‌تواند اشاره‌گرها را در packed-refs هم ذخیره کند.

symbolic-ref prints the full branch name attached to HEAD; rev-parse prints the resolved commit ID. In the normal state, the latter two commands match for the current branch. Use show-ref to inspect refs rather than assuming each branch must be a loose file under .git/refs/heads; Git can store refs in packed-refs too.

اگر HEAD به شاخه اشاره نکند چه؟What if HEAD does not name a branch?

گاهی می‌خواهی یک commit قدیمی را فقط بررسی کنی. git switch --detach <commit> این کار را می‌کند: HEAD مستقیماً به commit می‌رسد. می‌توانی فایل‌ها را ببینی یا حتی commit بسازی؛ اما commit تازه اشاره‌گر شاخه‌ای را جلو نمی‌برد، چون شاخه‌ای انتخاب نشده است.

Sometimes you only want to inspect an older commit. git switch --detach <commit> checks it out with HEAD pointing directly to that commit. You can inspect files or even commit, but no branch ref advances because no branch is selected.

git switch --detach main
git symbolic-ref -q HEAD
git status --short --branch
'temporary probe' | Out-File -Encoding utf8 probe.txt
git add probe.txt
git commit -m "Temporary detached experiment"
git rev-parse HEAD
git switch -c rescue/probe

در حالت جداشده، git symbolic-ref -q HEAD خروجی ندارد و با کد غیرصفر تمام می‌شود؛ اینجا یعنی HEAD symbolic نیست، نه اینکه مخزن خراب شده. فرمان آخر را بلافاصله بعد از commit اجرا کن تا شاخه روی همان commit ساخته شود. اگر قبلاً به شاخهٔ دیگری رفته‌ای، باید شناسهٔ commit را از شواهد مطمئن پیدا کنی و با git branch rescue/probe COMMIT_ID نام‌گذاری‌اش کنی؛ این فصل بازیابی آن شناسه را تضمین نمی‌کند.

In detached state, git symbolic-ref -q HEAD prints nothing and exits non-zero: HEAD is not symbolic, not broken. Run the final command immediately after the commit so the branch starts there. If you already switched away, identify the commit ID from reliable evidence and name it with git branch rescue/probe COMMIT_ID; this chapter does not guarantee recovery of that ID.

ساختن، رفتن، نام‌گذاری و کنارگذاشتن شاخهCreate, switch, rename, and retire branches

وقتی مدل اشاره‌گر روشن شد، فرمان‌ها دیگر فهرستی برای حفظ‌کردن نیستند. هرکدام پاسخی به یک وضعیت‌اند: ساختن نام، انتخاب شاخهٔ کاری، مرتب‌کردن نام‌ها، یا حذف اشاره‌گری که دیگر لازم نیست.

Once the ref model is clear, commands are not a list to memorize. Each answers a situation: create a name, select working branch, tidy a name, or remove an unneeded ref.

-d و -D یکی نیستند: دومی بررسی ادغام‌شدن را نادیده می‌گیرد و اشاره‌گر را به‌زور حذف می‌کند. این کار فایل‌های پروژه را از worktree جاری پاک نمی‌کند؛ اما ممکن است commitهای منحصربه‌فرد دیگر شاخهٔ نام‌داری نداشته باشند. اگر دربارهٔ ارزششان مطمئن نیستی، حذف نکن. -D را فقط در مخزن دورریختنی این فصل آزمایش کن.

-d and -D differ: the latter skips the merged check and force-deletes the ref. It does not remove files from the current worktree, but unique commits may lose their branch name. If unsure whether they matter, keep the branch. Try -D only in this chapter’s disposable repository.

وقتی Git اجازهٔ حرکت نمی‌دهد، اول شاهد را بخوانWhen Git refuses a move, read the evidence first

اگر Git اجازهٔ جابه‌جایی یا حذف شاخه را نمی‌دهد، اول پیامش را بخوان. بیشتر وقت‌ها دارد از کاری محافظت می‌کند که هنوز به جایی نرسیده، یا پوشهٔ کاری اجازهٔ جابه‌جایی امن نمی‌دهد. زور زدن با گزینهٔ اجباری باید آخرین تصمیم باشد، نه اولین واکنش.

A branch error usually does not mean Git is broken; often it is protecting a change or a name. Instead of forcing the operation, identify which condition is not met.

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

قبل از جواب هر تمرین، گراف را خیلی ساده بکش: اسم شاخه کجاست؟ HEAD به چه چیزی اشاره می‌کند؟ commit بعدی کدام اسم را جلو می‌برد؟ همین سه علامت بیشتر سؤال‌های شاخه را بدون حفظ دستور حل می‌کنند.

Predict first, then test in a disposable repository when useful. Open each solution to compare the reasoning with the result; commit IDs in your repository will differ.

پروژهٔ کوچک: آزمایش موازی بدون کپی پوشهMini-project: parallel experiments without copying a folder

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

A team needs to compare two implementations of a function. It should not duplicate the folder or jump into merging before learning it. Create two paths from one starting point, document the graph, retire one experiment only in a disposable repo, and retain the other.

دو مسیر ساخته شد؛ حالا چطور دوباره به هم می‌رسند؟Two paths exist—how do they come together?

حالا دو اسم می‌توانند به دو مسیر متفاوت در همان گراف برسند. سؤال طبیعی بعدی این است: وقتی هر دو مسیر تغییر مفید دارند، چطور دوباره به هم می‌رسند؟ فصل بعد دقیقاً از همین نقطه شروع می‌شود.

You now know why a branch is not a project copy, why commits advance only the current branch ref, and why HEAD can be detached. The team’s next question remains: how do we bring a good change back, and what if two people changed the same area?

فصل بعد سراغ merge می‌رویم: fast-forward را واقعاً اجرا می‌کنیم، merge commit را از گراف می‌خوانیم و تعارض را به‌عنوان نتیجهٔ طبیعی دو مسیر بررسی می‌کنیم—نه نشانهٔ خراب‌شدن Git.

Next, we will actually merge: perform a fast-forward, read a merge commit in the graph, and treat conflicts as a natural result of two lines of work—not evidence that Git is broken.

نقشهٔ سریع شاخه‌هاQuick branch reference