آلیس push کرد؛ باب هنوز چیزی نمی‌بیندAlice pushed; Bob still sees nothing

فصل ۰۷ همه‌چیز را داخل یک مخزن نگه داشت: اشاره‌گرهای main و feature محلی بودند. حالا سه نسخه داریم: یک مخزن مرکزی به نام server.git و دو clone به نام‌های alice و bob. فرض کن آلیس commit تازه‌ای بسازد و push کند. قبل از اینکه باب فرمانی اجرا کند، فایل او عوض می‌شود؟ شاخه محلی main او جلو می‌رود؟

Chapter 07 kept everything inside one repository: main and feature were local refs. Now we have three copies: a central repository named server.git and two clones named alice and bob. Suppose Alice creates and pushes a commit. Before Bob runs a command, do his files change? Does his local main advance?

نه. push آلیس اشاره‌گرهای مخزن راه دور را به‌روزرسانی می‌کند. clone باب مستقل است؛ تا وقتی از مخزن راه دور خبر نگیرد، حتی نمی‌داند commit تازه‌ای وجود دارد. امروز سه واژه را از هم جدا می‌کنیم: fetch برای گرفتن خبر و شیءها، انتخاب آگاهانه برای واردکردن تغییر به شاخهٔ خودمان، و push برای فرستادن commitها.

No. Alice’s push updates refs in the remote repository. Bob’s clone is independent; until it contacts the remote, it does not know that the new commit exists. We will separate three actions: fetch objects and information, intentionally integrate changes into our branch, and push commits outward.

«مخزن راه دور» نام یک مخزن است؛ «origin» فقط اسم رایج آنA remote names a repository; origin is only a common name

داخل clone باب، تنظیماتی هست که می‌گوید آدرس نسخهٔ مشترک کجاست و اشاره‌گرهایش چطور در این مخزن محلی ثبت شوند. Git به این مقصد یک نام کوتاه می‌دهد؛ origin قرارداد رایج clone است، نه واژه‌ای رزروشده و نه نام خود GitHub.

Bob’s clone stores configuration describing where the shared copy lives and how its refs map into this local repository. Git gives that destination a short name. origin is the conventional name created by clone, not a reserved keyword and not the name of GitHub itself.

در بخش بعد پوشه‌های آزمایش را می‌سازیم؛ فعلاً این فرمان‌ها را فقط به‌عنوان نمونهٔ تنظیمات یک clone بخوان. وقتی به مرحلهٔ ساخت رسیدی، آن‌ها را در پوشهٔ bob/ اجرا کن. این فرمان‌ها فقط تنظیمات محلی را می‌خوانند و چیزی push یا fetch نمی‌کنند. آدرس‌های fetch و push را مقایسه کن. اگر token اشتباهی داخل URL است، آن را در خروجی یا تصویر پخش نکن و آدرس را امن اصلاح کن.

We create the lab folders in the next section; for now, read these as a sample of one clone’s configuration. When you reach the setup, run them inside bob/. They only read local settings; they do not push or fetch. Compare fetch and push URLs. If a token was accidentally embedded in a URL, do not share it in output or screenshots; replace the URL safely.

git remote -v
git remote show origin

origin  ../server.git (fetch)
origin  ../server.git (push)

* remote origin
  Fetch URL: ../server.git
  Push  URL: ../server.git
  HEAD branch: main
  Remote branch:
    main tracked

در این آزمایش، آدرس نسبی است چون همه‌چیز روی یک دیسک است. در کار واقعی ممکن است HTTPS یا SSH ببینی. git remote show origin بدون گزینهٔ -n معمولاً از مخزن راه دور هم اطلاعات می‌پرسد؛ اگر شبکه یا دسترسی مشکل داشته باشد ممکن است خطا بدهد. خروجی می‌گوید Git چه تنظیم و چه اطلاعاتی دارد؛ تضمین نمی‌کند push مجاز است یا مخزن راه دور در همین لحظه بی‌خطاست.

The URL is relative because our lab lives on one disk. In real work, you may see HTTPS or SSH. Without -n, git remote show origin normally queries the remote; network or access problems can make it fail. The output describes configuration and known information, not whether pushing is authorized or the remote is currently healthy.

fetch خبر را می‌آورد، اما main باب را جلو نمی‌بردFetch brings the news, but does not advance Bob’s main

برای دیدن تفاوت، دقیقاً سه پوشه می‌سازیم: alice/، bob/ و server.git. آلیس مخزن اولیه را می‌سازد و اولین push را انجام می‌دهد؛ بعد باب clone می‌گیرد. مخزن bare محل نگهداری شیءها و اشاره‌گرهای مشترک است و برخلاف clone معمولی پوشه‌ کاری ندارد، اما Git می‌تواند از آن clone بگیرد و به آن push کند.

To see the distinction, create exactly three directories: alice/, bob/, and server.git. Alice creates the initial repository and makes the first push; Bob clones afterward. The bare repository stores shared objects and refs without an ordinary working tree, but Git can clone from it and accept pushes.

mkdir git-remote-lab && cd git-remote-lab
git init -b main alice
cd alice
git config user.name 'Nika Example'
git config user.email nika@example.test
printf 'شروع پروژه\n' > README.txt
git add README.txt
git commit -m 'Create project'
cd ..
git init --bare server.git
git --git-dir=server.git symbolic-ref HEAD refs/heads/main
cd alice
git remote add origin ../server.git
git push -u origin main
cd ..
git clone server.git bob

حالا آلیس یک فایل را عوض می‌کند و commit را به مخزن مشترک می‌فرستد. چون clone آلیس از شاخهٔ main گرفته شده و upstream معمول دارد، git push بدون آرگومان در این آزمایش مقصد و شاخه را از تنظیمات می‌فهمد. در یک مخزن دیگر ممکن است این پیش‌فرض‌ها فرق کند؛ بعداً رابطهٔ upstream را جدا می‌بینیم.

Alice now changes a file and sends the commit to the shared repository. Her clone has the usual upstream configured for main, so argument-less git push knows the destination in this lab. Other repositories may have different defaults; we will inspect the upstream relationship shortly.

cd alice
printf 'یادداشت آلیس\n' > alice.txt
git add alice.txt
git commit -m 'Add Alice note'
git push

حالا قبل از اجرای هر فرمان شبکه‌ای در باب، دو شناسه را یادداشت کن. این مقایسه نشان می‌دهد clone باب از آخرین ارتباطش با مخزن راه دور چه می‌داند و شاخه محلی خودش کجاست:

Before Bob runs any network command, record two IDs. This comparison shows what his clone knows from its last contact with the remote and where his local branch points:

cd ../bob
git status -sb
git rev-parse main
git rev-parse origin/main
git log --oneline --graph --decorate --all

قبل از fetch، معمولاً main و origin/main به یک commit می‌رسند؛ اما هیچ‌کدام commit آلیس را نام نمی‌برند. حالا فقط خبر را بگیر:

Before fetch, main and origin/main usually resolve to the same commit, and neither names Alice’s new commit. Now fetch only the remote state:

git fetch origin
git rev-parse main
git rev-parse origin/main
git log --oneline --graph --decorate --all
git status -sb

From ../server
   <old>..<new>  main  -> origin/main

خط main -> origin/main شاهد اصلی است: Git شیءهای لازم را گرفته و اشاره‌گر رهگیریِ مخزن راه دور باب را جلو برده. شناسه main محلی هنوز همان قبلی است و فایل‌های باب هم عوض نشده‌اند. git fetch معمولاً FETCH_HEAD را هم می‌نویسد. این فرمان خبر را می‌آورد، نه اینکه خودش تصمیم بگیرد تغییر را در شاخه کاری تو ادغام کند.

The line main -> origin/main is the key evidence: Git fetched the required objects and advanced Bob’s remote-tracking ref. Local main still has its old ID, and Bob’s files have not changed. git fetch also normally writes FETCH_HEAD. Fetch brings the news; it does not decide to integrate it into your working branch.

upstream یک رابطهٔ محلی است، نه فرمان مخفی سرورAn upstream is a local relationship, not a server command

باب حالا دو اشاره‌گر را می‌بیند: main خودش و origin/main که fetch تازه به‌روزش کرده. برای اینکه Git بداند مقایسه و pull پیش‌فرض را با کدام اشاره‌گر انجام دهد، شاخه محلی می‌تواند upstream داشته باشد. clone معمولاً این رابطه را از همان اول تنظیم می‌کند.

Bob now sees two refs: his main and origin/main, updated by the last fetch. A local branch can have an upstream so Git knows which ref to compare against and use for a default pull. Clone normally sets this relationship up.

برای دیدن این رابطه git branch -vv را اجرا کن. کروشهٔ [origin/main] upstream را معرفی می‌کند؛ علامت‌هایی مثل ahead و behind نسبت به آخرین اطلاعاتی‌اند که در clone داری. اگر از آخرین fetch مدت زیادی گذشته باشد، این شمارش نمی‌گوید مخزن راه دور همین حالا چه وضعی دارد.

Run git branch -vv to see the relationship. The bracketed [origin/main] names the upstream; ahead and behind counts use the information currently stored in your clone. If you have not fetched recently, those counts do not tell you the remote’s live state.

* main  1a2b3c4 [origin/main: behind 1] Create project

اگر شاخه‌ای را از اشاره‌گر رهگیریِ مخزن راه دور بسازی، Git معمولاً upstream را تنظیم می‌کند: git switch -c feature/notes --track origin/feature/notes. اگر شاخه از قبل هست، رابطه را با git branch --set-upstream-to=origin/main main تنظیم می‌کنی. این فرمان تنظیمات مخزن خودت را تغییر می‌دهد، نه چیزی را روی server.

When you create a branch from a remote-tracking ref, Git normally sets its upstream: git switch -c feature/notes --track origin/feature/notes. For an existing branch, use git branch --set-upstream-to=origin/main main. This changes local repository configuration, not the server.

push شاخهٔ تو را به مخزن مشترک می‌فرستدPush sends your branch to the shared repository

باب تغییر آلیس را fetch و بعد از دیدن گراف، با git merge --ff-only origin/main به main خودش آورده است. حالا می‌خواهد یک شاخهٔ تازه برای یادداشت‌ها بسازد و همان شاخه را برای همکارش منتشر کند. قبل از push حدس بزن: آیا مخزن راه دور هم خودبه‌خود همهٔ شاخه‌های محلی باب را دارد؟

Bob fetched Alice’s change, inspected the graph, then used git merge --ff-only origin/main to advance his main. Now he wants to create and publish a new branch for notes. Before pushing, predict: does the remote automatically have every branch in Bob’s clone?

git switch main
git merge --ff-only origin/main
git status -sb

نه؛ شاخهٔ تازه فقط در clone باب است تا آن را صریحاً push کنی. -u (یا --set-upstream) علاوه بر push موفق، upstream را هم برای شاخهٔ محلی تنظیم می‌کند. از این به بعد ابزارهایی مثل status و فرمان‌های بدون آرگومان می‌توانند آن رابطه را به‌کار ببرند.

No. The new branch exists only in Bob’s clone until he explicitly pushes it. -u (or --set-upstream) sets the local branch’s upstream after a successful push. Commands such as status and some argument-less operations can then use that relationship.

git switch -c feature/notes
printf 'نکتهٔ باب\n' > bob.txt
git add bob.txt
git commit -m 'Add Bob note'
git push -u origin feature/notes
git branch -vv

اگر push موفق باشد، Git روی مخزن راه دور شاخهٔ feature/notes می‌سازد و upstream محلی را به origin/feature/notes پیوند می‌دهد. این خروجی ثابت می‌کند شاخه به مقصد نام‌برده رسیده؛ ثابت نمی‌کند کسی آن را بازبینی کرده یا آمادهٔ ادغام است. بعد از اولین push هم می‌توانی صریح بمانی: git push origin feature/notes.

On success, Git creates feature/notes at the remote and links the local branch’s upstream to origin/feature/notes. This proves the branch reached the named destination; it does not prove anyone reviewed it or that it is ready to merge. You can keep being explicit on later pushes with git push origin feature/notes.

اگر شاخه upstream ندارد، git push ساده ممکن است مقصد را حدس نزند یا طبق تنظیمات تو رفتار متفاوتی داشته باشد. برای اولین انتشار، نام مخزن راه دور و شاخه را بنویس و -u را فقط وقتی می‌خواهی رابطه ثبت شود اضافه کن. شاخهٔ جاری را با git branch --show-current تأیید کن؛ اشتباه‌گرفتن نام شاخه می‌تواند تغییر را به مقصد دیگری بفرستد.

Without an upstream, plain git push may not infer a destination or may follow your configuration. For the first publication, name the remote and branch, adding -u if you want the relationship recorded. Confirm the current branch with git branch --show-current; a wrong branch name can send changes somewhere unintended.

در این فصل فقط شاخهها را منتشر کردیم. tag اشاره‌گر جداگانه‌ای است و انتشارش را می‌توان جداگانه کنترل کرد؛ در فصل ۱۱ سراغ tag و push کردن آن می‌رویم.

This chapter published branches only. Tags are separate refs whose publication can be controlled separately; Chapter 11 covers tags and pushing them.

pull را باز کن: اول fetch، بعد یک انتخاب برای ادغامUnpack pull: fetch first, then choose an integration

آلیس تغییر تازه‌ای push کرده و باب می‌خواهد سریع sync شود. git pull فقط یک اسم دیگر برای fetch نیست؛ اول fetch می‌کند، بعد اشاره‌گر انتخاب‌شده را با شاخه جاری ادغام می‌کند. اینکه ادغام با fast-forward، merge یا rebase انجام شود به گزینه‌ها و تنظیمات Git بستگی دارد.

Alice pushed another change and Bob wants to sync. git pull is not just another name for fetch: it fetches first, then integrates the selected ref into the current branch. Whether integration uses fast-forward, merge, or rebase depends on options and configuration.

برای شاخه‌ای که فقط عقب مانده و commit محلی جداگانه ندارد، git pull --ff-only انتخاب محافظه‌کارانه‌ای است: اگر fast-forward ممکن نباشد، متوقف می‌شود تا اول تاریخچه را ببینی. وقتی شاخه‌ها واگرا شده‌اند، می‌توانی بعد از بررسی با git pull --no-rebase merge کنی یا با git pull --rebase commitهای محلی را روی پایهٔ تازه بازپخش کنی. دومی همان ملاحظهٔ فصل ۰۷ را دارد: commitهای محلی را بازنویسی می‌کند.

For a branch that is simply behind with no separate local commits, git pull --ff-only is a conservative choice: it stops if a fast-forward is impossible, giving you a chance to inspect the graph. When histories diverge, you can inspect and then use git pull --no-rebase to merge or git pull --rebase to replay local commits onto the new base. The latter has Chapter 07’s caveat: it rewrites local commits.

push باب رد شد؛ این شکست نیست، یک هشدار محافظتی استBob’s push was rejected; that is protection, not a crash

باب و آلیس هر دو از یک commit شروع کرده‌اند. آلیس commit خودش را push می‌کند؛ باب هم قبل از fetch یک commit مستقل می‌سازد. وقتی باب push می‌زند، نوک مخزن راه دور دیگر نیاکان commit او نیست. Git معمولاً push عادی را رد می‌کند تا commit آلیس از شاخهٔ مشترک کنار نرود.

Alice and Bob started from one commit. Alice pushes her change while Bob creates an independent commit before fetching. When Bob pushes, the remote tip is no longer an ancestor of his commit. Git normally rejects the push so Alice’s commit is not displaced from the shared branch.

به‌جای force، ابتدا fetch کن و بعد گراف و تفاوت commitها را بخوان. حالا باید هر دو خط را در یک تاریخچهٔ جدید جمع کنی؛ بسته به سیاست تیم، merge یا rebase انتخاب می‌شود. چون این آزمایش commit باب هنوز خصوصی است، می‌توانی rebase را تمرین کنی؛ برای شاخهٔ مشترک اول هماهنگ شو. بعد از ادغام تست کن و سپس push عادی را دوباره انجام بده.

Instead of forcing, fetch first and inspect the graph and commits. Then combine both lines in a new history; the team’s policy determines whether to merge or rebase. Since Bob’s commit is still private in this exercise, you can practice rebase; coordinate before rewriting a shared branch. Test after integration, then retry a normal push.

در دستورهای آزمایش، باب را از شاخهٔ feature/notes به main برمی‌گردانیم. این commit آزمایشی روی شاخهٔ خودش می‌ماند؛ اینجا فقط main را برای ساختن واگرایی تازه بررسی می‌کنیم.

In the experiment, Bob switches from feature/notes back to main. The test commit remains on its own branch; here we use main to create a separate divergence scenario.

git fetch origin
git status -sb
git log --oneline --graph --decorate --all
git show --stat HEAD
git show --stat origin/main

اگر بعد از fetch دیدی دو شاخه واگرا هستند، حالا انتخاب روشن است. برای merge کنترل‌شده: git merge origin/main و حل هر تعارض؛ برای بازپخش commitهای خصوصی باب: git rebase origin/main. بعد از هرکدام، تست و log را بررسی کن و push معمولی بزن. --force راهی برای ردشدن از این بررسی نیست.

If the fetch shows divergence, the choice is now informed. For a controlled merge, use git merge origin/main and resolve any conflicts; to replay Bob’s private commits, use git rebase origin/main. After either, test, inspect the log, then make a normal push. --force is not a substitute for this investigation.

# from the lab parent, enter alice/ · both clones currently share the same main
cd alice
printf 'new work from Alice\n' >> alice.txt
git add alice.txt
git commit -m 'Add Alice update'
git push origin main

# from alice/, switch to Bob's sibling clone before fetching
cd ../bob
git switch main
printf 'new work from Bob\n' >> bob.txt
git add bob.txt
git commit -m 'Add Bob update'
git push origin main

# bob/ · the push is rejected; now inspect and integrate
git fetch origin
git log --oneline --graph --decorate --all
git merge origin/main
git show --stat --oneline HEAD
git push origin main

# from bob/, return to alice/ to learn about Bob's accepted commit
cd ../alice
git fetch origin
git log --oneline --graph --decorate --all
git merge --ff-only origin/main

در این آزمایش، اولین push آلیس موفق می‌شود. push باب باید رد شود، چون commit او از commit تازهٔ مخزن راه دور فرزند نشده. بعد از fetch، هر دو فایل را جداگانه می‌بینی؛ merge آن دو مسیر را وصل می‌کند، سپس push باب مخزن راه دور را به‌صورت fast-forward جلو می‌برد. در پایان آلیس باید fetch کند تا از commit باب باخبر شود.

In this experiment, Alice’s first push succeeds. Bob’s push should be rejected because his commit is not a descendant of the remote’s new commit. After fetching, both files are present; merge joins the lines, then Bob’s push fast-forwards the remote. Alice must fetch afterward to learn about Bob’s commit.

force-with-lease حصار است؛ مجوز بی‌فکری نیستforce-with-lease is a guard, not permission to stop thinking

فصل ۰۷ mechanism بازنویسی را نشان داد: بعد از rebase، commitهای تازه شناسههای تازه دارند. اگر تاریخچه را پیش‌تر push کرده‌ای، push عادی آن جایگزینی را رد می‌کند. --force-with-lease فقط در یک شاخهٔ دورریختنی کمک می‌کند بفهمی مخزن راه دور از زمانی که آخرین بار وضعیتش را گرفتی جلو رفته یا نه.

Chapter 07 showed the rewrite mechanism: rebasing creates new commit IDs. If you already pushed the old history, a normal push rejects its replacement. On a disposable branch, --force-with-lease helps detect whether the remote moved since your last recorded view.

آزمایش را فقط در cloneهای تازه و دورریختنی همین درس انجام بده. آلیس شاخهٔ آزمایشی می‌سازد و push می‌کند؛ باب آن را fetch می‌کند، commit را با پیام تازه amend می‌کند، اما هنوز fetch دیگری نمی‌زند. آلیس روی commit اصلی یک commit جدید push می‌کند. حالا اشاره‌گری که باب آخرین بار از مخزن راه دور دیده با اشاره‌گر واقعی فرق دارد:

Run this only in fresh, disposable clones for this lesson. Alice creates and pushes a test branch. Bob fetches it, amends the commit message, and does not fetch again. Alice then pushes another commit on top of the original. Bob’s last-seen remote ref now differs from the actual remote:

git switch -c scratch/lease main
printf 'lease test base\n' > lease.txt
git add lease.txt
git commit -m 'Create lease test'
git push -u origin scratch/lease

git fetch origin
git switch -c scratch/lease --track origin/scratch/lease
git commit --amend -m 'Rewrite disposable lease commit'

git switch scratch/lease
printf 'Alice advanced the remote\n' > alice-lease.txt
git add alice-lease.txt
git commit -m 'Advance lease test'
git push origin scratch/lease

حالا Bob می‌تواند گراف محلی خودش را ببیند و lease را امتحان کند:

Bob can now inspect his local graph and test the lease:

git log --oneline --graph --decorate --all
git push --force-with-lease origin scratch/lease

push باید رد شود، چون origin/scratch/lease در clone باب هنوز به commitی اشاره می‌کند که قبل از push تازهٔ آلیس دیده بود. این شاهد، حفاظ lease را در این تنظیم معمول نشان می‌دهد؛ برای تنظیم‌های fetch پس‌زمینهٔ غیرمعمول تضمین مطلق نیست. اگر خروجی unexpectedly موفق شد، ادامه نده: این مخزن فقط آزمایشی است، وضعیت مخزن راه دور را بررسی کن و فهم علت را به‌جای تکرار فرمان در اولویت بگذار.

The push should be rejected because Bob’s local origin/scratch/lease still names the commit he saw before Alice’s latest push. This demonstrates the lease guard in the usual setup; it is not an absolute guarantee under unusual background-fetch configurations. If the push unexpectedly succeeds, stop: this repository is disposable. Inspect the remote and understand why instead of repeating the command.

اگر lease رد شد، فوراً fetch نکن که فقط اشاره‌گر رهگیریِ مخزن راه دور را به‌روز کنی و بعد همان force را تکرار کنی؛ ممکن است آن‌وقت lease با مقدار تازه موافق شود، درحالی‌که تو هنوز تغییر آلیس را وارد نکرده‌ای. اول وضعیت واقعی مخزن راه دور را بشناس، تغییرها را ادغام کن و با هم‌تیمی هماهنگ شو. lease از حدس کهنه محافظت می‌کند، نه از تصمیم آگاهانهٔ اشتباه یا همهٔ تنظیم‌های غیرمعمول fetch در پس‌زمینه.

If the lease is rejected, do not simply fetch to refresh the tracking ref and retry the same force; the lease may then match even though you have not integrated Alice’s change. First inspect the remote state, integrate the work, and coordinate with your teammate. A lease guards against a stale assumption, not an informed but wrong choice or every unusual background-fetch setup.

شاخهٔ مخزن راه دور حذف شده، اما ردّش در clone تو ماندهThe remote branch is gone, but your clone still remembers it

آلیس شاخهٔ feature/notes را که باب push کرده از مخزن راه دور حذف می‌کند. باب قبلاً آن را fetch کرده و هنوز در git branch -r نام origin/feature/notes را می‌بیند. آیا حذف مخزن راه دور شکست خورده؟ نه؛ باب فقط هنوز خبر حذف را نگرفته است.

Alice deletes the feature/notes branch Bob pushed. Bob fetched it earlier and still sees origin/feature/notes in git branch -r. Did the remote deletion fail? No; Bob has not fetched the deletion yet.

این بار باب قبل از حذف، اشاره‌گر را fetch می‌کند تا واقعاً نسخهٔ رهگیریِ مخزن راه دور داشته باشد. بعد از حذف، fetch معمولی ممکن است اشاره‌گر stale را نگه دارد؛ برای پاک‌کردن نام قدیمی از git fetch --prune origin استفاده کن. این پاک‌سازی، شاخه محلی feature/notes را حذف نمی‌کند و فرمان حذف شاخه روی سرور هم نیست؛ فقط نام محلیِ ازمدافتاده را تمیز می‌کند.

Bob fetches the ref before deletion so he has a remote-tracking copy. After deletion, a normal fetch may retain the stale name; use git fetch --prune origin to clean it up. This does not delete Bob’s local feature/notes branch and does not issue a deletion to the server; it removes only the stale local tracking name.

# from alice/, switch to bob/ and record the remote branch
cd ../bob
git fetch origin
git branch -r

# switch back to alice/ and delete the published branch
cd ../alice
git push origin --delete feature/notes

# return to bob/, confirm it is stale, then prune
cd ../bob
git branch -r
git fetch --prune origin
git branch -r
git branch --list feature/notes

اگر Git نام شاخه را اشتباه می‌گیرد، قبل از prune می‌توانی git remote prune --dry-run origin را اجرا کنی تا ببیند چه اشاره‌گرهایی را stale می‌داند، بدون اینکه پاکشان کند. نکتهٔ پیشرفته: prune بر اساس refspec تنظیم‌شده عمل می‌کند؛ اگر tagها را با refspec ویژه در فضای نام مشترک fetch کرده‌ای، prune ممکن است tagهای محلی بیشتری از انتظار حذف کند. با --prune-tags بی‌فکر بازی نکن.

If you are unsure what Git considers stale, run git remote prune --dry-run origin first; it reports candidates without deleting them. Advanced note: pruning follows configured refspecs. If tags are explicitly fetched into a shared namespace, pruning may remove more local tags than expected. Do not add --prune-tags casually.

حالا همین مدل را روی GitHub ببینNow map the same model onto GitHub

آزمایش bare مخزن آفلاین بود، اما مدل عوض نمی‌شود: GitHub یا GitLab میزبانیِ مخزن راه دور است؛ clone تو همچنان اشاره‌گرها محلی و تنظیمات مخزن راه دور خودش را دارد. اسم origin هنوز قراردادی است و می‌توانی مخزن راه دور دیگری مثل upstream هم داشته باشی.

The bare-repository lab was offline, but the model is unchanged: GitHub or GitLab hosts a remote; your clone still has its own local refs and remote configuration. origin remains conventional, and you can add another remote such as upstream.

برای افزودن URL، اول مطمئن شو در پوشهٔ مخزن درست هستی و مخزن راه دور فعلی را بررسی کن. اگر origin از قبل وجود دارد، به‌جای تکرار add، همان URL را با git remote set-url اصلاح کن یا مخزن راه دور دوم را با نام مناسب اضافه کن.

Before adding a URL, confirm you are in the right repository and inspect existing remotes. If origin already exists, update it with git remote set-url or add a second remote under a suitable name instead of repeating add.

git remote add origin https://github.com/OWNER/REPOSITORY.git
git remote -v
git fetch origin

برای GitHub، HTTPS برای عملیات نوشتن به روش احراز هویت پشتیبانی‌شده نیاز دارد؛ رمز حساب را در prompt گیت وارد نکن. از روش فعلی مورد تأیید GitHub مثل اعتبارنامه helper یا SSH key استفاده کن و secret را در URL، تاریخچهٔ shell، فایل پروژه یا screenshot نگذار. موفقیت fetch فقط دسترسی خواندن را نشان می‌دهد؛ برای push ممکن است مجوز نوشتن جدا لازم باشد.

GitHub requires a supported authentication method for HTTPS writes; do not use your account password at Git’s prompt. Use a currently supported method such as a credential helper or SSH key, and keep secrets out of URLs, shell history, project files, and screenshots. A successful fetch proves read access only; pushing may require separate write permission.

اگر origin از قبل هست، این‌ها شواهد مفیدند: git remote -v برای URL تنظیم‌شده، git remote show origin برای شاخه‌ها و وضعیت قابل‌مشاهده، و git ls-remote origin برای اشاره‌گرهایی که مخزن راه دور اکنون اعلام می‌کند. هیچ‌کدام به‌تنهایی نشان نمی‌دهد کدام commit در فایل‌های پوشه‌ کاری تو checkout شده است.

If origin already exists, useful checks include git remote -v for configured URLs, git remote show origin for branches and observed status, and git ls-remote origin for refs the remote currently advertises. None alone tells you which commit is checked out in your working tree.

وقتی حرف‌زدن با مخزن راه دور به مشکل می‌خوردWhen communication with a remote goes wrong

وقتی ارتباط با مخزن راه دور به مشکل می‌خورد، سه چیز را یکی نکن: شاخهٔ محلی تو، آخرین خبری که با fetch گرفته‌ای، و شاخه‌ای که واقعاً روی مخزن مشترک است. اول مشخص کن کدام‌شان عقب یا جلو است؛ بعد تصمیم بگیر چه کاری لازم است.

Read an error as a clue, not an invitation to try random flags. First identify whether the problem is the URL, authentication, write permission, refspec, or divergent history.

تمرین‌ها: از اشاره‌گر محلی تا تصمیم دوهم‌تیمیExercises: from local refs to two-developer decisions

در هر تمرین سه نقطه را جدا نگه دار: شاخهٔ محلی، اشاره‌گر رهگیری مخزن راه دور و شاخهٔ واقعی روی مخزن مشترک. اگر این سه را یکی فرض کنی، fetch و push شبیه رفتارهای تصادفی به نظر می‌رسند؛ اگر جداشان کنی، جواب تقریباً همیشه از روی گراف پیدا می‌شود.

Before opening each solution, name the clone and the ref that changes. “I update the remote” is not precise enough; identify the ref and what remains unchanged.

پروژهٔ کوچک: دو توسعه‌دهنده، یک bare مخزن راه دورMini-project: two developers, one bare remote

با دو clone نقش دو هم‌تیمی را بازی می‌کنی. عمداً اجازه می‌دهیم push نفر دوم رد شود تا به جای force کردن، همان کاری را انجام دهی که در تیم واقعی لازم است: خبر تازه را بگیری، گراف را بخوانی، تغییر هر دو طرف را بفهمی و بعد راه ادغام را انتخاب کنی.

Nika and Sam work from a shared repository. Each must make an independent commit; one pushes and the other is rejected. They inspect history, preserve both changes, and finish with both clones at the same result. The goal is to reason about refs and show evidence, not recite commands.

در یک پوشهٔ خالی مخزن اولیه بساز، آن را به server.git bare تبدیل کن و دو clone با نام‌های nika و sam بساز. در هر دو clone نام و ایمیل محلی آزمایشی تنظیم کن. فایل‌ها را جدا نگه دار تا اختلاف از تاریخچه باشد نه تعارض بی‌ربط محتوایی.

In an empty folder, create a seed repository, clone it bare as server.git, then make nika and sam clones. Set test-only names and emails in each clone. Keep edits in separate files so the lesson is about history divergence, not an unrelated content conflict.

یکی commit خود را push کند. نفر دوم بدون fetch، commit مستقلی روی main بسازد و push کند؛ باید رد شدن معمول non-fast-forward را ببیند. قبل از هر ادغام، این چهار مدرک را تحویل بده:

One developer pushes a commit. The other makes an independent main commit without fetching and attempts to push; observe the normal non-fast-forward rejection. Before integrating, collect these four pieces of evidence:

git remote -v
git branch -vv
git status -sb
git log --oneline --graph --decorate --all

حالا fetch کن، تغییرهای هر طرف را با git show بخوان و با تیم تصمیم بگیر merge یا rebase مناسب است. در این پروژه commit بازندهٔ push هنوز در clone خودش است؛ آن را با reset یا force کنار نگذار. بعد از ادغام، تست سادهٔ فایل‌ها را اجرا و push عادی را تکرار کن.

Fetch, inspect each side with git show, and choose merge or rebase intentionally. The rejected commit still exists in its clone; do not discard it with reset or force. After integrating, run a simple file check and retry a normal push.

در پایان، نفر دیگر fetch کند، گراف و اشاره‌گرها را ببیند و ادغام نهایی را انجام دهد. پروژه وقتی تمام است که هر دو clone بتوانند شناسه commit نهایی مشترک را نشان دهند، فایل هر دو توسعه‌دهنده حاضر باشد و پوشه‌ کاری بدون تغییر باشد. اگر شاخه آزمایشی را از مخزن راه دور حذف می‌کنید، clone دیگر باید prune کند و تفاوت شاخه محلی با اشاره‌گر رهگیریِ مخزن راه دور را ثبت کند.

Finally, the other developer fetches, inspects refs and graph, and integrates. The project is complete when both clones identify the same final shared commit, both developers’ files exist, and the working trees are clean. If you delete a test branch remotely, have the other clone prune it and record the difference between local and remote-tracking refs.

حالا می‌توانیم تاریخچه را به اشتراک بگذاریمNow we can share history

حالا می‌دانی «اشتراک تاریخچه» یعنی چه و fetch دقیقاً کدام نام‌های محلی را تازه می‌کند. سؤال بعدی خطرناک‌تر است: وقتی می‌گویی «برگرد عقب»، دقیقاً می‌خواهی کدام بخش را برگردانی؟

We have seen which refs are local and remote-tracking, how to fetch updates, integrate deliberately, and why a non-fast-forward push is rejected. Commits now travel between clones. The next dangerous question is: “How do I undo this?” Chapter 09 shows several answers because “undo” can mean several different things.

مرور کوتاهQuick reference

اگر در مخزن‌های راه دور گیج شدی، به جای حفظ دستورها این سه اسم را روی کاغذ بنویس: main من، origin/main من، main روی مخزن مشترک. بعد هر دستور را ببین کدام‌یک را می‌خواند یا تغییر می‌دهد.

Official fetch documentation, pull documentation, and push documentation cover the details. For a hosted remote, see GitHub’s official guide to managing remote repositories.