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

git-restore - بازیابی فایل‌های درخت کاری

git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>...
git restore [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>...]

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

همچنین از این دستور می‌توان برای بازیابی محتوا در ایندکس با گزینه --staged، یا بازیابی هم‌زمان درخت کاری و ایندکس با گزینه‌های --staged --worktree استفاده کرد.

به‌طور پیش‌فرض، اگر --staged مشخص شود، محتویات از HEAD بازیابی می‌شوند، در غیر این صورت از ایندکس بازیابی خواهند شد. برای بازیابی از یک کامیت متفاوت از --source استفاده کنید.

برای آگاهی از تفاوت‌های میان این سه دستور، به بخش «Reset, restore and revert» در git(1) مراجعه کنید.

-s <tree>, --source=<tree>

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

در صورت عدم تعیین، چنانچه --staged مشخص شده باشد محتویات از HEAD و در غیر این صورت از ایندکس بازیابی می‌شوند.

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

-p, --patch

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

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

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

--inter-hunk-context=<n>

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

-W, --worktree, -S, --staged

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

-q, --quiet

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

--progress, --no-progress

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

--ours, --theirs

هنگام بازیابی فایل‌ها در درخت کاری از ایندکس، از مرحله ۲ (ours) یا ۳ (theirs) برای مسیرهای ادغام‌نشده استفاده می‌کند. این گزینه را نمی‌توان هنگام دریافت مسیرها از یک tree-ish (یعنی با گزینه --source) استفاده کرد.

توجه داشته باشید که در طول اجرای git rebase و git pull --rebase، ممکن است ours و theirs جابه‌جا به نظر برسند. برای جزئیات به توضیح همین گزینه‌ها در git-checkout(1) مراجعه کنید.

-m, --merge

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

--conflict=<style>

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

--ignore-unmerged

هنگام بازیابی فایل‌ها روی درخت کاری از ایندکس، در صورت وجود ورودی‌های ادغام‌نشده و عدم تعیین هیچ‌یک از گزینه‌های --ours، --theirs، --merge یا --conflict، عملیات را متوقف نمی‌کند. مسیرهای ادغام‌نشده روی درخت کاری دست‌نخورده باقی می‌مانند.

--ignore-skip-worktree-bits

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

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

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

--overlay, --no-overlay

در حالت هم‌پوشانی (overlay)، هرگز فایل‌ها را هنگام بازیابی حذف نمی‌کند. در حالت بدون هم‌پوشانی (no-overlay)، فایل‌های ردیابی‌شده‌ای را که در <tree> مربوط به --source=<tree> ظاهر نمی‌شوند حذف می‌کند تا آن‌ها را دقیقاً با <tree> مطابقت دهد. حالت پیش‌فرض، حالت no-overlay است.

--pathspec-from-file=<file>

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

--pathspec-file-nul

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

--

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

<pathspec>...

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

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

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

$ git switch master
$ git restore --source master~2 Makefile  (1)
$ rm -f hello.c
$ git restore hello.c                     (2)
1. استخراج یک فایل از کامیتی دیگر
2. بازیابی hello.c از ایندکس

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

$ git restore '*.c'

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

برای بازیابی تمام فایل‌های دایرکتوری فعلی:

$ git restore .

یا برای بازیابی تمام فایل‌های درخت کاری با جادوی top در pathspec (به gitglossary(7) مراجعه کنید):

$ git restore :/

برای بازیابی یک فایل در ایندکس به گونه‌ای که با نسخه موجود در HEAD مطابقت پیدا کند (این معادل استفاده از git-reset(1) است):

$ git restore --staged hello.c

یا می‌توانید هم ایندکس و هم درخت کاری را بازیابی کنید (این معادل استفاده از git-checkout(1) است):

$ git restore --source=HEAD --staged --worktree hello.c

یا فرم کوتاه آن که کاربردی‌تر ولی کمتر خواناست:

$ git restore -s@ -SW hello.c

git-checkout(1), git-reset(1)

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

2026-06-29 Git 2.55.0