GIT-SWITCH(1) Git Manual GIT-SWITCH(1)

git-switch - جابه‌جایی میان شاخه‌ها

git switch [<options>] [--no-guess] <branch>
git switch [<options>] --detach [<start-point>]
git switch [<options>] (-c|-C) <new-branch> [<start-point>]
git switch [<options>] --orphan <new-branch>

جابه‌جایی به یک شاخهٔ مشخص‌شده. درخت کاری (working tree) و نمایه (index) به‌روزرسانی می‌شوند تا با شاخه مطابقت داشته باشند. تمامی کامیت‌های جدید به نوک (tip) این شاخه اضافه خواهند شد.

به‌صورت اختیاری می‌توان یک شاخهٔ جدید با استفاده از -c یا -C ایجاد کرد، یا به‌صورت خودکار از یک شاخهٔ ریموت هم‌نام ایجاد نمود (نگاه کنید به --guess)، و یا با --detach درخت کاری را هم‌زمان با جابه‌جایی، از هر شاخه‌ای جدا کرد.

جابه‌جایی شاخه‌ها نیازی به خالی و تمیز بودن نمایه و درخت کاری ندارد (یعنی عدم وجود تفاوت در مقایسه با HEAD). با این حال، اگر این عملیات منجر به از بین رفتن تغییرات محلی شود لغو خواهد شد، مگر آنکه با --discard-changes یا --merge دستور دیگری داده شده باشد.

<branch>

شاخه برای جابه‌جایی به آن.

<new-branch>

نام برای شاخهٔ جدید.

<start-point>

نقطهٔ شروع برای شاخهٔ جدید. مشخص کردن یک <start-point> به شما امکان می‌دهد تا شاخه‌ای را بر مبنای نقطه‌ای دیگر از تاریخچه، به‌جز جایی که HEAD در حال حاضر به آن اشاره دارد بسازید. (یا در مورد --detach، امکان بررسی و جدا شدن از نقطه‌ای دیگر را فراهم می‌کند.)

می‌توانید از ساختار @{-<N>} برای اشاره به <N>-امین شاخه یا کامیتی که قبلاً با استفاده از عملیات git switch یا git checkout به آن جابه‌جا شده‌اید استفاده کنید. همچنین می‌توانید - را مشخص نمایید که مترادف با @{-1} است. این اغلب برای جابه‌جایی سریع میان دو شاخه، یا لغو جابه‌جایی اشتباه شاخه استفاده می‌شود.

به عنوان یک حالت ویژه، می‌توانید از <rev-a>...<rev-b> به عنوان میان‌بری برای پایهٔ ادغام (merge base) میان <rev-a> و <rev-b> استفاده کنید، مشروط بر اینکه دقیقاً یک پایهٔ ادغام وجود داشته باشد. می‌توانید حداکثر یکی از <rev-a> و <rev-b> را حذف کنید که در این صورت پیش‌فرض آن HEAD خواهد بود.

-c <new-branch>, --create <new-branch>

پیش از جابه‌جایی به شاخه، شاخهٔ جدیدی به نام <new-branch> با شروع از <start-point> ایجاد می‌کند. این از نظر تراکنشی معادل موارد زیر است: 
$ git branch <new-branch>
$ git switch <new-branch>

بدین معنا که شاخه بازنشانی/ایجاد نمی‌شود مگر آنکه git switch موفقیت‌آمیز باشد (برای مثال، هنگامی که شاخه در درخت کاری دیگری در حال استفاده است، نه تنها شاخهٔ فعلی یکسان می‌ماند، بلکه شاخه به نقطهٔ شروع نیز بازنشانی نمی‌شود).

-C <new-branch>, --force-create <new-branch>

مشابه --create است، با این تفاوت که اگر <new-branch> از قبل وجود داشته باشد، به <start-point> بازنشانی خواهد شد. این یک میان‌بر کاربردی برای موارد زیر است: 
$ git branch -f _<new-branch>_
$ git switch _<new-branch>_

-d, --detach

جابه‌جایی به یک کامیت برای بازبینی و آزمایش‌های دورانداختنی. برای جزئیات به بخش "DETACHED HEAD" در git-checkout(1) مراجعه کنید.

--guess, --no-guess

اگر <branch> یافت نشود اما یک شاخهٔ ردیابی در دقیقاً یک ریموت (که آن را <remote> می‌نامیم) با نام منطبق وجود داشته باشد، معادل دستور زیر تلقی می‌شود: 
$ git switch -c <branch> --track <remote>/<branch>

اگر شاخه در چند ریموت وجود داشته باشد و یکی از آن‌ها توسط متغیر پیکربندی checkout.defaultRemote مشخص شده باشد، برای ابهام‌زدایی از آن استفاده خواهیم کرد؛ حتی اگر <branch> در بین تمام ریموت‌ها یکتا نباشد. برای نمونه آن را به checkout.defaultRemote=origin تنظیم کنید تا در صورت مبهم بودن <branch> اما موجود بودن در ریموت origin، شاخهٔ ریموت همواره از آنجا دریافت شود. همچنین به checkout.defaultRemote در git-config(1) نگاه کنید.

گزینهٔ --guess رفتار پیش‌فرض است. از --no-guess برای غیرفعال کردن آن استفاده کنید.

رفتار پیش‌فرض را می‌توان از طریق متغیر پیکربندی checkout.guess تنظیم کرد.

-f, --force

نام مستعاری برای --discard-changes.

--discard-changes

حتی در صورت وجود تفاوت میان نمایه یا درخت کاری با HEAD عملیات را ادامه می‌دهد. هم نمایه و هم درخت کاری بازیابی می‌شوند تا با هدف جابه‌جایی مطابقت پیدا کنند. اگر --recurse-submodules مشخص شده باشد، محتوای زیرماژول‌ها نیز بازیابی می‌شود تا با هدف جابه‌جایی مطابقت یابد. این گزینه برای دور ریختن تغییرات محلی استفاده می‌شود.

-m, --merge

اگر تغییرات محلی روی یک یا چند فایل داشته باشید که بین شاخهٔ فعلی و شاخه‌ای که به آن جابه‌جا می‌شوید متفاوت باشند، دستور معمولاً برای حفظ تغییرات شما در بستر اصلی، از جابه‌جایی شاخه‌ها خودداری می‌کند. با این حال با این گزینه، تغییرات محلیِ دارای تداخل، به‌طور خودکار پیش از جابه‌جایی ذخیره (stash) شده و پس از آن مجدداً اعمال می‌شوند. اگر تغییرات محلی با تفاوت‌های میان شاخه‌ها هم‌پوشانی نداشته باشند، جابه‌جایی بدون ذخیره‌سازی انجام می‌شود. اگر اعمال مجدد تغییرات ذخیره‌شده منجر به تداخل شود، این مدخل در فهرست تغییرات ذخیره‌شده (stash list) باقی می‌ماند. پس از اتمام کار، تداخل‌ها را برطرف کرده و git stash drop را اجرا کنید، یا پیش از اجرای بعدیِ git stash pop جهت اعمال مجدد تغییرات، درخت کاری را پاک کنید (برای نمونه با git reset --hard).

--conflict=<style>

مشابه گزینهٔ --merge در بالا است، اما نحوهٔ نمایش قطعات دارای تداخل (conflicting hunks) را تغییر می‌دهد و متغیر پیکربندی merge.conflictStyle را لغو می‌کند. مقادیر ممکن عبارتند از merge (پیش‌فرض)، diff3 و zdiff3.

-q, --quiet

حالت بی‌صدا، پیام‌های بازخورد را سرکوب می‌کند.

--progress, --no-progress

وضعیت پیشرفت به‌طور پیش‌فرض زمانی که به یک ترمینال متصل باشد روی جریان خطای استاندارد گزارش می‌شود، مگر اینکه --quiet مشخص شده باشد. این فلگ گزارش پیشرفت را حتی در صورت عدم اتصال به ترمینال و صرف‌نظر از --quiet فعال می‌سازد.

-t, --track[ (direct|inherit)]

هنگام ساخت یک شاخهٔ جدید، پیکربندی بالادست ("upstream") را تنظیم می‌کند. -c به‌طور ضمنی در نظر گرفته می‌شود. برای جزئیات به --track در git-branch(1) مراجعه کنید.

اگر گزینهٔ -c داده نشود، نام شاخهٔ جدید از شاخهٔ ردیابی‌شدهٔ ریموت مشتق می‌شود؛ بدین صورت که بخش محلیِ refspec پیکربندی‌شده برای ریموت مربوطه بررسی شده و سپس بخش ابتدایی تا "*" حذف می‌شود. این کار به ما می‌گوید که هنگام شاخه‌بندی از origin/hack (یا remotes/origin/hack، یا حتی refs/remotes/origin/hack) از hack به عنوان شاخهٔ محلی استفاده کنیم. اگر نام داده‌شده فاقد اسلش باشد، یا حدس زدن بالا منجر به نامی خالی شود، حدس زدن لغو می‌شود. در چنین حالتی می‌توانید صریحاً نامی را با -c مشخص کنید.

--no-track

پیکربندی بالادست ("upstream") را تنظیم نمی‌کند، حتی اگر متغیر پیکربندی branch.autoSetupMerge برابر با true باشد.

--orphan <new-branch>

یک شاخهٔ متولدنشدهٔ (unborn) جدید به نام <new-branch> می‌سازد. تمامی فایل‌های ردیابی‌شده حذف می‌شوند.

--ignore-other-worktrees

هنگامی که ارجاع (ref) مورد نظر قبلاً توسط درخت کاری دیگری تحویل گرفته شده باشد، git switch از جابه‌جایی امتناع می‌کند. این گزینه باعث می‌شود که در هر صورت آن ارجاع را تحویل بگیرد. به بیان دیگر، ارجاع می‌تواند توسط بیش از یک درخت کاری نگه‌داری شود.

--recurse-submodules, --no-recurse-submodules

استفاده از --recurse-submodules محتوای تمامی زیرماژول‌های فعال را مطابق با کامیت ثبت‌شده در پروژهٔ اصلی (superproject) به‌روزرسانی می‌کند. اگر هیچ مقداری (یا --no-recurse-submodules) استفاده نشود، درخت‌های کاری زیرماژول‌ها به‌روزرسانی نخواهند شد. درست مانند git-submodule(1)، این کار HEAD زیرماژول‌ها را جدا (detach) خواهد کرد.

دستور زیر به شاخهٔ "master" جابه‌جا می‌شود:

$ git switch master

پس از کار در شاخهٔ اشتباه، جابه‌جایی به شاخهٔ درست با دستور زیر انجام می‌شود:

$ git switch mytopic

با این حال، ممکن است شاخهٔ "اشتباه" شما و شاخهٔ درست "mytopic" در فایل‌هایی که به‌صورت محلی تغییر داده‌اید تفاوت داشته باشند؛ در این صورت جابه‌جایی بالا با چنین خطایی مواجه خواهد شد:

$ git switch mytopic
error: You have local changes to 'frotz'; not switching branches.

می‌توانید فلگ -m را به دستور بدهید که تغییرات محلی شما را به شاخهٔ جدید منتقل خواهد کرد:

$ git switch -m mytopic
Applied autostash.
Switched to branch 'mytopic'
The following paths have local changes:
M       frotz

پس از جابه‌جایی، اصلاحات محلی دوباره اعمال می‌شوند و در فایل نمایهٔ شما ثبت نمی‌شوند، بنابراین git diff به شما نشان می‌دهد چه تغییراتی از نوک شاخهٔ جدید ایجاد کرده‌اید.

برای بازگشت به شاخهٔ قبلی پیش از جابه‌جایی به mytopic (یعنی شاخهٔ "master"):

$ git switch -

می‌توانید یک شاخهٔ جدید را از هر کامیتی توسعه دهید. برای مثال، به "HEAD~3" جابه‌جا شوید و شاخهٔ "fixup" را بسازید:

$ git switch -c fixup HEAD~3
Switched to a new branch 'fixup'

اگر می‌خواهید شاخهٔ جدیدی را از یک شاخهٔ ریموت با همان نام آغاز کنید:

$ git switch new-topic
Branch `new-topic` set up to track remote branch `new-topic` from `origin`
Switched to a new branch `new-topic`

برای تحویل گرفتن کامیت HEAD~3 جهت بررسی یا آزمایش موقت بدون ایجاد یک شاخهٔ جدید:

$ git switch --detach HEAD~3
HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

اگر مشخص شد آنچه انجام داده‌اید ارزش نگه‌داری دارد، همواره می‌توانید نام جدیدی برای آن ایجاد کنید (بدون نیاز به ترک شاخه):

$ git switch -c good-surprises

تمامی موارد زیر این خط در این بخش به‌طور گزینشی از مستندات git-config(1) برگرفته شده‌اند. محتوا همان چیزی است که در آنجا یافت می‌شود:

checkout.defaultRemote

هنگامی که دستور git checkout <something> یا git switch <something> را اجرا می‌کنید و تنها یک ریموت دارید، ممکن است به‌طور ضمنی به تحویل گرفتن و ردیابی مواردی مانند origin/<something> برگردد. این ویژگی به محض اینکه بیش از یک ریموت با ارجاع <something> داشته باشید، از کار می‌افتد. این تنظیم امکان تعیین نام یک ریموت ترجیحی را فراهم می‌سازد که همیشه در ابهام‌زدایی برنده شود. کاربرد معمول آن تنظیم روی origin است.

در حال حاضر این مورد توسط git-switch(1) و git-checkout(1) استفاده می‌شود، زمانی که git checkout <something> یا git switch <something> شاخهٔ <something> را روی ریموت دیگری تحویل بگیرد، و همچنین توسط git-worktree(1) زمانی که git worktree add به یک شاخهٔ ریموت ارجاع می‌دهد. این تنظیم ممکن است در آینده برای سایر دستورات مشابه checkout یا قابلیت‌های دیگر استفاده شود.

checkout.guess

مقدار پیش‌فرض را برای گزینهٔ --guess یا --no-guess در git checkout و git switch ارائه می‌دهد. به git-switch(1) و git-checkout(1) نگاه کنید.

checkout.workers

تعداد پردازش‌های موازی (کارگرها) برای به‌روزرسانی درخت کاری. پیش‌فرض یک است، یعنی اجرای متوالی. در صورت تنظیم روی مقداری کمتر از یک، گیت به اندازهٔ تعداد هسته‌های منطقی موجود کارگر به کار خواهد گرفت. این تنظیم و checkout.thresholdForParallelism روی تمام دستوراتی که عملیات checkout را انجام می‌دهند اثر می‌گذارند؛ مانند checkout، clone، reset، sparse-checkout و غیره.

یادداشت (Note)
عملیات موازی checkout معمولاً عملکرد بهتری برای مخازن واقع در درایوهای SSD یا روی NFS فراهم می‌آورد. برای مخازن روی دیسک‌های چرخان و/یا سیستم‌هایی با تعداد هستهٔ اندک، روش پیش‌فرضِ checkout متوالی اغلب عملکرد بهتری دارد. اندازه و سطح فشرده‌سازی یک مخزن نیز ممکن است بر میزان کارایی نگارش موازی اثر بگذارد.

checkout.thresholdForParallelism

هنگام اجرای checkout موازی با تعداد اندکی فایل، هزینهٔ راه‌اندازی زیرپردازش‌ها و ارتباطات میان‌پردارشی ممکن است از مزایای موازی‌سازی فراتر رود. این تنظیم به شما اجازه می‌دهد تا حداقل تعداد فایل‌هایی را که باید برای آن‌ها checkout موازی انجام شود تعیین کنید. مقدار پیش‌فرض ۱۰۰ است.

git-checkout(1), git-branch(1)

بخشی از مجموعهٔ git(1)

2026-06-29 Git 2.55.0