GIT-CHECKOUT(1) دستورات عمومی کاربر GIT-CHECKOUT(1)
´

git-checkout - جابه‌جایی میان شاخه‌ها یا بازیابی فایل‌های درخت کاری

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
git checkout <tree-ish> [--] <pathspec>...
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

دستور git checkout دارای دو حالت اصلی است:

1.جابه‌جایی شاخه‌ها (Switch branches)، با git checkout <branch>
2.بازیابی نسخه متفاوتی از یک فایل (Restore a different version of a file)، برای نمونه با git checkout <commit> <filename> یا git checkout <filename>

برای چگونگی تصمیم‌گیری گیت در انتخاب هریک از این دو حالت، بخش «ابهام‌زدایی از آرگومان‌ها (ARGUMENT DISAMBIGUATION)» در ادامه را ببینید.

git checkout [<branch>]

جابه‌جایی به <branch>. این کار شاخه فعلی را روی <branch> تنظیم کرده و فایل‌ها را در دایرکتوری کاری شما به‌روزرسانی می‌کند. در صورتی که تغییرات کامیت‌نشده‌ای در فایل‌هایی وجود داشته باشد که محتوای آن‌ها میان <branch> و کامیت فعلی شما متفاوت است، عملیات دریافت (checkout) با شکست مواجه می‌شود. در غیر این صورت، تغییرات کامیت‌نشده حفظ خواهند شد.

اگر <branch> یافت نشود، اما دقیقاً در یک ریموت شاخه ردیابی با نام منطبق وجود داشته باشد (آن را <remote> می‌نامیم) و گزینه --no-guess مشخص نشده باشد، معادل دستور زیر در نظر گرفته می‌شود:

$ git checkout -b <branch> --track <remote>/<branch>

اجرای git checkout بدون تعیین یک شاخه، هیچ اثری ندارد مگر آنکه اطلاعات ردیابی شاخه فعلی را چاپ کند.

git checkout -b <new-branch> [<start-point>]

شاخه جدیدی به نام <new-branch> می‌سازد، آن را از <start-point> (به‌طور پیش‌فرض کامیت فعلی) آغاز می‌کند، و شاخه جدید را دریافت (checkout) می‌نماید؛ می‌توانید از گزینه‌های --track یا --no-track برای تنظیم اطلاعات ردیابی بالادست (upstream) شاخه استفاده کنید.

اگر در دریافت <new-branch> خطایی رخ دهد، برای نمونه اگر دریافت کامیت <start-point> باعث رونویسی تغییرات کامیت‌نشده شما شود، این عملیات با شکست مواجه خواهد شد.

git checkout -B <branch> [<start-point>]

مشابه گزینه -b است، با این تفاوت که اگر شاخه از قبل وجود داشته باشد، به جای شکست خوردن، <branch> را به نقطه شروع بازنشانی (reset) می‌کند.

git checkout --detach [<branch>], git checkout [--detach] <commit>

مشابه دستور git checkout <branch> است، با این تفاوت که به جای اشاره دادن HEAD به شاخه، HEAD را به شناسه کامیت اشاره می‌دهد. برای اطلاعات بیشتر بخش «سر جداشده (DETACHED HEAD)» در ادامه را ببینید.

حذف کردن <branch> باعث جدا شدن HEAD در نوک (tip) شاخه فعلی می‌شود.

git checkout <tree-ish> [--] <pathspec>..., git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]

فایل‌ها و/یا دایرکتوری‌های مشخص‌شده را با نسخه برگرفته از کامیت یا درخت داده‌شده جایگزین کرده و آن‌ها را به ایندکس (که به عنوان "staging area" یا ناحیه مرحله‌بندی نیز شناخته می‌شود) اضافه می‌کند.

برای نمونه، دستور git checkout main file.txt فایل file.txt را با نسخه موجود در شاخه main جایگزین خواهد کرد.

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>..., git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]

فایل‌ها و/یا دایرکتوری‌های تعیین‌شده را با نسخه موجود در ایندکس جایگزین می‌کند.

برای نمونه، اگر کامیتی را چک‌اوت کنید، فایل file.txt را ویرایش نمایید، و سپس متوجه شوید که آن تغییرات اشتباه بوده‌اند، دستور git checkout file.txt تمامی تغییرات مرحله‌بندی‌نشده (unstaged) در file.txt را دور می‌اندازد.

اگر فایل دارای تعارض در ادغام (merge conflict) باشد و شما هنوز دستور git add file.txt (یا معادل آن) را برای علامت‌گذاری به عنوان رفع تعارض اجرا نکرده باشید، این دستور با شکست مواجه می‌شود. می‌توانید از گزینه -f استفاده کنید تا به جای شکست، ورودی‌های ادغام‌نشده نادیده گرفته شوند؛ از --ours یا --theirs برای جایگزینی آن‌ها با نسخه یک سمت خاص از ادغام استفاده نمایید؛ یا از گزینه -m برای جایگزینی آن‌ها با نتیجه اولیه ادغام دارای تعارض بهره ببرید.

git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

مشابه دو حالت پیشین است، اما به شما امکان می‌دهد از رابط تعاملی برای مشاهده خروجی "diff" و انتخاب تکه‌هایی (hunks) که مایلید در نتیجه استفاده شوند، بهره ببرید. برای توضیحات گزینه --patch به ادامه متن مراجعه کنید.

-q, --quiet

حالت ساکت؛ جلوگیری از نمایش پیام‌های بازخورد.

--progress, --no-progress

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

-f, --force

هنگام جابه‌جایی شاخه‌ها، حتی اگر ایندکس یا درخت کاری با HEAD متفاوت باشد و حتی اگر فایل‌های ردیابی‌نشده‌ای بر سر راه باشند، عملیات را ادامه می‌دهد. از این گزینه برای دور انداختن تغییرات محلی و هرگونه فایل یا دایرکتوری ردیابی‌نشده که مانع کار هستند استفاده می‌شود.

هنگام دریافت مسیرها از ایندکس، در صورت وجود ورودی‌های ادغام‌نشده با شکست مواجه نمی‌شود؛ در عوض، ورودی‌های ادغام‌نشده نادیده گرفته می‌شوند.

--ours, --theirs

هنگام دریافت مسیرها از ایندکس، مرحله ۲ (ours) یا ۳ (theirs) را برای مسیرهای ادغام‌نشده دریافت می‌کند.

توجه داشته باشید که هنگام اجرای git rebase و git pull --rebase، ممکن است ours و theirs جابه‌جا به نظر برسند؛ --ours نسخه موجود در شاخه‌ای را ارائه می‌دهد که تغییرات بر روی آن بازپایه‌ریزی (rebase) می‌شوند، در حالی که --theirs نسخه موجود در شاخه‌ای را ارائه می‌دهد که کارهای در حال بازپایه‌ریزی شما را در بر دارد.

دلیل این امر این است که rebase در گردش کاری به کار می‌رود که تاریخچه موجود در ریموت را به عنوان تاریخچه مرجع و مشترک تلقی می‌کند، و کارهای انجام‌شده روی شاخه‌ای را که بازپایه‌ریزی می‌کنید به عنوان کارهای شخص ثالث در نظر می‌گیرد که باید یکپارچه شوند، و شما در طول بازپایه‌ریزی موقتاً نقش نگه‌دارنده تاریخچه مرجع را به عهده می‌گیرید. به عنوان نگه‌دارنده تاریخچه مرجع، شما باید تاریخچه ریموت را به عنوان ours (یعنی "تاریخچه مرجع مشترک ما")، و کارهایی را که روی شاخه جانبی خود انجام داده‌اید به عنوان theirs (یعنی "کار یکی از مشارکت‌کنندگان روی آن") در نظر بگیرید.

-b <new-branch>

شاخه جدیدی به نام <new-branch> می‌سازد، آن را از <start-point> آغاز می‌کند، و شاخه حاصل را دریافت (checkout) می‌نماید؛ برای جزئیات به git-branch(1) مراجعه کنید.

-B <new-branch>

مشابه گزینه -b است، با این تفاوت که اگر شاخه از قبل وجود داشته باشد، به جای شکست خوردن، <branch> را به نقطه شروع بازنشانی (reset) می‌کند.

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

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

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

--no-track

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

--guess, --no-guess

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

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

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

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

-l

لاگ ارجاع (reflog) شاخه جدید را ایجاد می‌کند؛ برای جزئیات به git-branch(1) مراجعه فرمایید.

-d, --detach

به جای دریافت یک شاخه برای کار روی آن، یک کامیت را برای بازبینی و آزمایش‌های دورریختنی دریافت می‌کند. این رفتار پیش‌فرض دستور git checkout <commit> است هنگامی که <commit> نام یک شاخه نباشد. برای جزئیات بیشتر به بخش «سر جداشده (DETACHED HEAD)» در ادامه مراجعه کنید.

--orphan <new-branch>

شاخه جدید متولدنشده‌ای (unborn) به نام <new-branch> ایجاد می‌کند که از <start-point> آغاز شده و به آن جابه‌جا می‌شود. نخستین کامیت ساخته‌شده روی این شاخه جدید والدی نخواهد داشت و ریشه یک تاریخچه جدید خواهد بود که کاملاً از تمامی شاخه‌ها و کامیت‌های دیگر منفصل است.

ایندکس و درخت کاری طوری تنظیم می‌شوند که گویی پیش‌تر دستور git checkout <start-point> را اجرا کرده‌اید. این به شما امکان می‌دهد با اجرای ساده git commit -a برای ساختن کامیت ریشه، تاریخچه جدیدی را آغاز کنید که مجموعه‌ای از مسیرهای مشابه با <start-point> را ثبت می‌نماید.

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

اگر می‌خواهید یک تاریخچه منفصل را شروع کنید که مجموعه‌ای از مسیرها را کاملاً متفاوت با مسیرهای <start-point> ثبت می‌کند، باید بلافاصله پس از ایجاد شاخه یتیم (orphan)، با اجرای دستور git rm -rf . از بالاترین سطح درخت کاری، ایندکس و درخت کاری را پاک کنید. پس از آن آماده خواهید بود تا با کپی کردن فایل‌ها از جای دیگر، استخراج یک فایل تاربال و غیره، فایل‌های جدید خود را آماده کرده و درخت کاری را دوباره پر نمایید.

--ignore-skip-worktree-bits

در حالت دریافت تنک (sparse checkout)، دستور git checkout -- <path>... تنها ورودی‌هایی را به‌روزرسانی می‌کند که با <paths> و الگوهای تنک در $GIT_DIR/info/sparse-checkout مطابقت داشته باشند. این گزینه الگوهای تنک را نادیده گرفته و تمامی فایل‌های موجود در <path>... را بازمی‌گرداند.

-m, --merge

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

هنگام دریافت مسیرها از ایندکس، این گزینه به شما امکان می‌دهد ادغام دارای تعارض را در مسیرهای مشخص‌شده بازسازی کنید. این گزینه را نمی‌توان هنگام دریافت مسیرها از یک tree-ish استفاده کرد.

--conflict=<style>

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

-p, --patch

انتخاب تعاملی تکه‌ها (hunks) در تفاوت میان <tree-ish> (یا در صورت عدم تعیین، ایندکس) و درخت کاری. تکه‌های انتخاب‌شده سپس به‌صورت معکوس بر روی درخت کاری (و در صورت مشخص شدن <tree-ish>، بر روی ایندکس) اعمال می‌شوند.

این بدان معناست که می‌توانید از دستور git checkout -p برای دور ریختن انتخابی ویرایش‌ها از درخت کاری فعلی خود استفاده کنید. برای یادگیری نحوه کار با حالت --patch، به بخش "Interactive Mode" در git-add(1) مراجعه نمایید.

توجه داشته باشید که این گزینه به‌طور پیش‌فرض از حالت بدون هم‌پوشانی (no overlay) استفاده می‌کند (همچنین گزینه --overlay را ببینید)، و در حال حاضر از حالت هم‌پوشانی (overlay) پشتیبانی نمی‌کند.

-U<n>, --unified=<n>

تولید تفاوت‌ها (diff) با <n> خط از متن پیرامون (context). تعداد خطوط بستر به‌طور پیش‌فرض برابر با diff.context یا ۳ در صورت تنظیم نشدن متغیر پیکربندی است. (گزینه -U بدون <n> به دلیل یک تصادف تاریخی، به‌صورت بی‌صدا به عنوان مترادفی برای -p پذیرفته می‌شود).

--inter-hunk-context=<n>

نمایش بستر میان تکه‌های diff تا تعداد خطوط مشخص‌شده در <number>، که بدین ترتیب تکه‌هایی را که به یکدیگر نزدیک هستند ترکیب می‌کند. مقدار پیش‌فرض آن diff.interHunkContext یا 0 در صورت تنظیم نشدن این گزینه در پیکربندی است.

--ignore-other-worktrees

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

--overwrite-ignore, --no-overwrite-ignore

رونویسی بی‌صدا روی فایل‌های نادیده‌گرفته‌شده (ignored) هنگام جابه‌جایی شاخه‌ها. این رفتار پیش‌فرض است. از گزینه --no-overwrite-ignore برای لغو عملیات در زمانی که شاخه جدید شامل فایل‌های نادیده‌گرفته‌شده است استفاده کنید.

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

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

--overlay, --no-overlay

در حالت پیش‌فرضِ پوشش‌دهی (overlay)، دستور git checkout هرگز فایل‌ها را از ایندکس یا درخت کاری حذف نمی‌کند. با تعیین گزینه --no-overlay، فایل‌هایی که در ایندکس و درخت کاری وجود دارند اما در <tree-ish> حاضر نیستند، حذف می‌شوند تا دقیقاً با <tree-ish> مطابقت پیدا کنند.

--pathspec-from-file=<file>

مشخصه مسیر (pathspec) به جای آرگومان‌های خط فرمان، از طریق <file> ارسال می‌شود. اگر <file> دقیقاً - باشد، ورودی استاندارد به کار گرفته می‌شود. عناصر مشخصه مسیر با LF یا CR/LF از یکدیگر جدا می‌شوند. عناصر مشخصه مسیر می‌توانند همان‌گونه که برای متغیر پیکربندی core.quotePath توضیح داده شده درون نقل‌قول قرار گیرند (به git-config(1) مراجعه فرمایید). همچنین گزینه‌های --pathspec-file-nul و گزینه سراسری --literal-pathspecs را ببینید.

--pathspec-file-nul

تنها همراه با --pathspec-from-file معنادار است. عناصر مشخصه مسیر با نویسه NUL جدا می‌شوند و با سایر نویسه‌ها کاملاً لفظی (شامل خطوط جدید و نقل‌قول‌ها) رفتار می‌شود.

<branch>

شاخه مورد نظر برای دریافت؛ اگر به یک شاخه اشاره کند (یعنی نامی که وقتی "refs/heads/" در ابتدای آن قرار می‌گیرد یک ارجاع معتبر باشد)، آن شاخه دریافت می‌شود. در غیر این صورت، اگر به یک کامیت معتبر ارجاع دهد، HEAD شما در وضعیت "جداشده" (detached) قرار می‌گیرد و شما دیگر روی هیچ شاخه‌ای نخواهید بود (برای جزئیات به بخش زیر مراجعه کنید).

می‌توانید از ساختار @{-N} برای ارجاع به N-امین شاخه/کامیتِ قبلیِ دریافت‌شده با دستور "git checkout" استفاده نمایید. همچنین می‌توانید - را مشخص کنید که مترادف با @{-1} است.

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

<new-branch>

نام شاخه جدید.

<start-point>

نام کامیتی که شاخه جدید از آنجا آغاز می‌شود؛ برای جزئیات به git-branch(1) مراجعه فرمایید. پیش‌فرض آن HEAD است.

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

<tree-ish>

درختی که دریافت از آن انجام می‌شود (زمانی که مسیرها مشخص شده باشند). در صورت عدم تعیین، از ایندکس استفاده خواهد شد.

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

--

از تفسیر آرگومان‌های بعدی به عنوان گزینه جلوگیری می‌کند.

<pathspec>...

مسیرهای تحت تأثیر عملیات را محدود می‌کند.

برای جزئیات بیشتر، به مدخل pathspec در gitglossary(7) مراجعه کنید.

به‌طور معمول، HEAD به یک شاخه نام‌گذاری‌شده ارجاع دارد (مانند master). در همین حال، هر شاخه به یک کامیت مشخص اشاره می‌کند. بیایید مخزنی با سه کامیت را در نظر بگیریم که روی یکی از آن‌ها برچسب خورده و شاخه master دریافت شده است:

           HEAD (refers to branch 'master')
            |
            v
a---b---c  branch 'master' (refers to commit 'c')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

هنگامی که کامیتی در این وضعیت ایجاد می‌شود، شاخه به‌روزرسانی می‌شود تا به کامیت جدید اشاره کند. به طور دقیق‌تر، git commit یک کامیت جدید به نام d ایجاد می‌کند که والد آن کامیت c است، و سپس شاخه master را به‌روزرسانی می‌کند تا به کامیت جدید d اشاره کند. در این حالت، HEAD همچنان به شاخه master اشاره دارد و بنابراین اکنون به‌طور غیرمستقیم به کامیت d ارجاع می‌دهد:

$ edit; git add; git commit
               HEAD (refers to branch 'master')
                |
                v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

گاهی اوقات مفید است که بتوانید کامیتی را دریافت کنید که در نوک (tip) هیچ شاخه نام‌گذاری‌شده‌ای قرار ندارد، یا حتی کامیت جدیدی بسازید که توسط هیچ شاخه نام‌گذاری‌شده‌ای ارجاع داده نشده باشد. بیایید ببینیم چه اتفاقی می‌افتد اگر کامیت b را دریافت کنیم (در اینجا دو روش انجام این کار نشان داده شده است):

$ git checkout v2.0  # or
$ git checkout master^^
   HEAD (refers to commit 'b')
    |
    v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

توجه داشته باشید که صرف‌نظر از اینکه از کدام دستور چک‌اوت استفاده کنیم، HEAD اکنون مستقیماً به کامیت b اشاره دارد. این وضعیت به عنوان قرار داشتن در حالت سر جداشده (HEAD جداشده) شناخته می‌شود. این حالت به سادگی به این معناست که HEAD به یک کامیت مشخص اشاره دارد، در مقابل اینکه به یک شاخه نام‌گذاری‌شده ارجاع دهد. بیایید ببینیم هنگام ایجاد یک کامیت چه رخ می‌دهد:

$ edit; git add; git commit
     HEAD (refers to commit 'e')
      |
      v
      e
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

اکنون کامیت جدیدی به نام e وجود دارد، اما تنها توسط HEAD ارجاع داده می‌شود. البته می‌توانیم در این وضعیت یک کامیت دیگر نیز اضافه کنیم:

$ edit; git add; git commit
         HEAD (refers to commit 'f')
          |
          v
      e---f
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

در واقع، ما می‌توانیم تمام عملیات‌های معمول گیت را انجام دهیم. اما بیایید ببینیم وقتی شاخه master را چک‌اوت می‌کنیم چه رخ می‌دهد:

$ git checkout master
               HEAD (refers to branch 'master')
      e---f     |
     /          v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

بسیار مهم است که درک کنیم در این نقطه هیچ چیزی به کامیت f ارجاع ندارد. در نهایت کامیت f (و در نتیجه کامیت e) توسط فرآیند روتین جمع‌آوری زباله (garbage collection) در گیت حذف خواهد شد، مگر اینکه پیش از رخ دادن آن، ارجاعی به آن ایجاد نماییم. اگر هنوز از کامیت f جابه‌جا نشده‌ایم، هر یک از دستورات زیر یک ارجاع به آن ایجاد می‌کند:

$ git checkout -b foo  # or "git switch -c foo"  (1)
$ git branch foo                                 (2)
$ git tag foo                                    (3)
1. یک شاخه جدید به نام foo ایجاد می‌کند که به کامیت f اشاره دارد، و سپس HEAD را به‌روزرسانی می‌کند تا به شاخه foo ارجاع دهد. به عبارت دیگر، پس از این دستور دیگر در وضعیت سر جداشده (detached HEAD) نخواهیم بود.
2. به طور مشابه یک شاخه جدید به نام foo ایجاد می‌کند که به کامیت f اشاره دارد، اما HEAD را در وضعیت جداشده باقی می‌گذارد.
3. یک برچسب (tag) جدید به نام foo ایجاد می‌کند که به کامیت f اشاره دارد، و HEAD را در وضعیت جداشده باقی می‌گذارد.

اگر از کامیت f دور شده باشیم، ابتدا باید نام شیء (object name) آن را بازیابی کنیم (معمولاً با استفاده از git reflog)، و سپس می‌توانیم ارجاعی به آن ایجاد نماییم. برای مثال، برای مشاهده دو کامیت آخری که HEAD به آن‌ها اشاره داشته است، می‌توانیم از یکی از این دستورات استفاده کنیم:

$ git reflog -2 HEAD # or
$ git log -g -2 HEAD

هنگامی که دستور git checkout <something> را اجرا می‌کنید، گیت تلاش می‌کند تا حدس بزند که آیا <something> به عنوان یک شاخه، یک کامیت یا مجموعه‌ای از فایل(ها) در نظر گرفته شده است، و سپس به آن شاخه یا کامیت جابه‌جا می‌شود، یا فایل‌های مشخص‌شده را بازیابی می‌کند.

در صورت وجود هرگونه ابهام، گیت با <something> به عنوان یک شاخه یا کامیت رفتار می‌کند، اما می‌توانید از دو خط تیره -- استفاده کنید تا گیت را مجبور سازد که پارامتر را به عنوان فهرستی از فایل‌ها و/یا دایرکتوری‌ها در نظر بگیرد، مانند زیر:

git checkout -- file.txt

دنباله دستورات زیر شاخه master را دریافت می‌کند، فایل Makefile را به دو بازبینی قبل برمی‌گرداند، فایل hello.c را به اشتباه حذف می‌کند، و آن را دوباره از ایندکس بازیابی می‌نماید.

$ git checkout master             (1)
$ git checkout master~2 Makefile  (2)
$ rm -f hello.c
$ git checkout hello.c            (3)
1. تغییر شاخه
2. برداشتن یک فایل از کامیتی دیگر
3. بازیابی hello.c از ایندکس

اگر می‌خواهید تمام فایل‌های منبع C را از ایندکس خارج کرده و دریافت کنید، می‌توانید بنویسید:

$ git checkout -- '*.c'

به نقل‌قول‌های اطراف *.c دقت کنید. فایل hello.c نیز دریافت خواهد شد، حتی اگر دیگر در درخت کاری وجود نداشته باشد، زیرا الگوی انطباق فایل (globbing) برای مطابقت با ورودی‌های موجود در ایندکس استفاده می‌شود (نه در درخت کاری توسط شل).

اگر شاخه‌ای با نام نامناسب hello.c داشته باشید، این مرحله با دستور تعویض به آن شاخه اشتباه گرفته می‌شود. در عوض باید بنویسید:

$ git checkout -- hello.c

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

$ git checkout mytopic

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

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

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

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

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

هنگامی که گزینه --merge (-m) داده می‌شود و تغییرات محلی با تغییرات شاخه‌ای که قصد تعویض به آن را داریم هم‌پوشانی داشته باشند، تغییرات در استش ذخیره شده و پس از تعویض شاخه دوباره اعمال می‌شوند. اگر این فرآیند به تعارض منجر شود، ورودی استش ذخیره شده و پیامی چاپ می‌شود:

$ git checkout -m mytopic
Your local changes are stashed, however applying them
resulted in conflicts.  You can either resolve the conflicts
and then discard the stash with "git stash drop", or, if you
do not want to resolve them now, run "git reset --hard" and
apply the local changes later by running "git stash pop".

تمام موارد زیر این خط در این بخش به‌طور انتخابی از مستندات 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.guess

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

checkout.workers

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

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

checkout.thresholdForParallelism

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

git-switch(1), git-restore(1)

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

2026-06-29 Git 2.55.0