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

نام (NAME)
       git-restore - بازیابی فایل‌های درخت کاری

خلاصه دستور (SYNOPSIS)
       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>...]


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

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

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

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

گزینه‌ها (OPTIONS)
       -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) مراجعه کنید.

مثال‌ها (EXAMPLES)
       توالی زیر به شاخه 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


همچنین ببینید (SEE ALSO)
       git-checkout(1), git-reset(1)

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

Git 2.55.0                        2026-06-29                    GIT-RESTORE(1)