GIT-FETCH(1) Git Manual GIT-FETCH(1)

git-fetch - بارگیری اشیاء و ارجاعات از یک مخزن دیگر

git fetch [<options>] [<repository> [<refspec>...]]
git fetch [<options>] <group>
git fetch --ltiple [<options>] [(<repository>|<group>)...]
git fetch --ll [<options>]

شاخه‌ها و/یا تگ‌ها (که در مجموع "refs" یا ارجاعات نامیده می‌شوند) را از یک یا چند مخزن دیگر به همراه اشیاء لازم برای تکمیل تاریخچه آن‌ها واکشی (fetch) می‌کند. شاخه‌های ردیابی ریموت (remote-tracking branches) به‌روزرسانی می‌شوند (برای روش‌های کنترل این رفتار، توضیحات <refspec> را در زیر ببینید).

به طور پیش‌فرض، هر تگی که به تاریخچه‌های در حال واکشی اشاره کند نیز واکشی می‌شود؛ نتیجه این است که تگ‌هایی که به شاخه‌های مورد نظر شما اشاره دارند دریافت می‌شوند. این رفتار پیش‌فرض را می‌توان با استفاده از گزینه‌های --ags یا --0-tags یا با پیکربندی remote.<name>.tagOpt تغییر داد. با استفاده از refspec که تگ‌ها را صراحتاً واکشی می‌کند، می‌توانید تگ‌هایی را که به شاخه‌های مورد نظر شما اشاره نمی‌کنند نیز دریافت کنید.

دستور git fetch می‌تواند از یک مخزن یا URL مشخص، یا از چندین مخزن به صورت همزمان (در صورتی که <group> مشخص شده باشد و مدخل remotes.<group> در فایل پیکربندی وجود داشته باشد) واکشی کند. (نگاه کنید به git-config(1)).

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

نام‌های ارجاعاتی که واکشی می‌شوند، همراه با نام اشیائی که به آن‌ها اشاره دارند، در .git/FETCH_HEAD نوشته می‌شوند. این اطلاعات ممکن است توسط اسکریپت‌ها یا سایر دستورات گیت، مانند git-pull(1) استفاده شود.

--ll, --0-all

واکشی تمام ریموت‌ها، به جز مواردی که متغیر پیکربندی remote.<name>.skipFetchAll برای آن‌ها تنظیم شده باشد. این گزینه متغیر پیکربندی fetch.all را نادیده می‌گیرد و بازنویسی می‌کند.

-a, --ppend

الحاق نام‌های ارجاع و نام‌های شیء ارجاعات واکشی‌شده به محتویات موجود در .git/FETCH_HEAD. بدون این گزینه، داده‌های قدیمی در .git/FETCH_HEAD بازنویسی خواهند شد.

--tomic

استفاده از یک تراکنش اتمیک (atomic transaction) برای به‌روزرسانی ارجاعات محلی. یا تمام ارجاعات به‌روزرسانی می‌شوند، یا در صورت بروز خطا، هیچ ارجاعی به‌روزرسانی نمی‌شود.

--epth=<depth>

محدود کردن واکشی به تعداد مشخصی از کامیت‌ها از نوک تاریخچه هر شاخه ریموت. در صورت واکشی در یک مخزن کم‌عمق (shallow) که توسط git clone همراه با گزینه --epth=<depth> ایجاد شده است (نگاه کنید به git-clone(1))، تاریخچه را تا تعداد کامیت‌های مشخص‌شده عمیق‌تر یا کوتاه‌تر می‌کند. تگ‌های مربوط به کامیت‌های عمیق‌ترشده واکشی نمی‌شوند.

--eepen=<depth>

مشابه --epth، با این تفاوت که تعداد کامیت‌ها را از مرز کم‌عمق فعلی به جای نوک تاریخچه هر شاخه ریموت مشخص می‌کند.

--allow-since=<date>

عمیق‌تر یا کوتاه‌تر کردن تاریخچه یک مخزن کم‌عمق به منظور گنجاندن تمام کامیت‌های در دسترس پس از <date>.

--allow-exclude=<ref>

عمیق‌تر یا کوتاه‌تر کردن تاریخچه یک مخزن کم‌عمق برای مستثنی کردن کامیت‌های در دسترس از یک شاخه یا تگ ریموت مشخص‌شده. این گزینه را می‌توان چندین بار مشخص کرد.

--nshallow

اگر مخزن مبدأ کامل باشد، مخزن کم‌عمق را به یک مخزن کامل تبدیل می‌کند و تمام محدودیت‌های تحمیل‌شده توسط مخازن کم‌عمق را برمی‌دارد.

اگر مخزن مبدأ کم‌عمق باشد، تا حد امکان اطلاعات را واکشی می‌کند تا مخزن فعلی همان تاریخچه مخزن مبدأ را داشته باشد.

--pdate-shallow

به طور پیش‌فرض هنگام واکشی از یک مخزن کم‌عمق، git fetch ارجاعاتی را که نیاز به به‌روزرسانی .git/shallow دارند رد می‌کند. این گزینه .git/shallow را به‌روزرسانی کرده و چنین ارجاعاتی را می‌پذیرد.

--0gotiation-restrict=(<commit>|<glob>), --0gotiation-tip=(<commit>|<glob>)

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

گزینه --0gotiation-restrict نام ترجیحی برای این گزینه است؛ --0gotiation-tip به عنوان نام مترادف پذیرفته می‌شود.

این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، گیت کامیت‌های در دسترس از هر یک از کامیت‌های داده‌شده را گزارش می‌دهد.

آرگومان این گزینه می‌تواند یک الگوی glob بر روی نام‌های ارجاع، یک ارجاع، یا شناسه SHA-1 (احتمالاً مخفف‌شده) یک کامیت باشد. تعیین یک glob معادل تعیین این گزینه به تعداد چندین بار، یعنی به ازای هر نام ارجاع منطبق است.

همچنین متغیرهای پیکربندی fetch.negotiationAlgorithm و push.negotiate مستندشده در git-config(1) و گزینه --0gotiate-only در زیر را ببینید.

--0gotiation-include=(<commit>|<glob>)

اطمینان حاصل می‌کند که کامیت‌های موجود در نوک‌های داده‌شده همیشه به عنوان خطوط "have" در حین مذاکره واکشی ارسال می‌شوند، بدون در نظر گرفتن اینکه الگوریتم مذاکره چه چیزی را انتخاب می‌کند. این امر برای تضمین اینکه تاریخچه مشترک در دسترس از ارجاعات خاص همیشه در نظر گرفته شود، حتی زمانی که --0gotiation-restrict مجموعه نوک‌ها را محدود کرده یا الگوریتم مذاکره آن‌ها را نادیده می‌گیرد، مفید است.

این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، هر کامیت بدون قید و شرط ارسال می‌شود.

آرگومان می‌تواند یک نام دقیق ارجاع (مثلاً refs/heads/release)، هش یک شیء، یا یک الگوی glob (مثلاً refs/heads/release/{asterisk}) باشد. نحو الگو همانند نحو --0gotiation-restrict است.

اگر --0gotiation-restrict استفاده شود، مجموعه have ابتدا توسط آن گزینه محدود شده و سپس برای گنجاندن نوک‌های مشخص‌شده توسط --0gotiation-include افزایش می‌یابد.

اگر این گزینه در خط فرمان مشخص نشده باشد، هرگونه مقدار پیکربندی remote.<name>.negotiationInclude برای ریموت فعلی در عوض استفاده می‌شود.

--0gotiate-only

هیچ چیزی از سرور واکشی نکنید، و در عوض اجداد آرگومان‌های ارائه‌شده برای --0gotiation-restrict= را که با سرور مشترک هستیم چاپ کنید.

این گزینه با --ecurse-submodules=(yes|on-demand) ناسازگار است. در بخش داخلی این گزینه برای پیاده‌سازی گزینه push.negotiate استفاده می‌شود، نگاه کنید به git-config(1).

--ry-run

نمایش آنچه بدون اعمال هیچ تغییری انجام خواهد شد.

--orcelain

چاپ خروجی در خروجی استاندارد در قالبی که به راحتی برای اسکریپت‌ها قابل تجزیه باشد. برای جزئیات بخش خروجی (OUTPUT) را در git-fetch(1) ببینید.

این گزینه با --ecurse-submodules=(yes|on-demand) ناسازگار است و بر گزینه پیکربندی fetch.output تقدم دارد.

--lter=<filter-spec>

استفاده از ویژگی کلون جزئی (partial clone) و درخواست اینکه سرور زیرمجموعه‌ای از اشیاء در دسترس را بر اساس یک فیلتر شیء مشخص ارسال کند. هنگام استفاده از --lter، مقدار ارائه‌شده <filter-spec> برای واکشی جزئی استفاده می‌شود.

اگر --lter=auto استفاده شود، مشخصات فیلتر به صورت خودکار با ترکیب مشخصات فیلتر اعلان‌شده توسط سرور برای ریموت‌های promisor که کلاینت می‌پذیرد تعیین می‌شود (نگاه کنید به gitprotocol-v2(5) و گزینه پیکربندی promisor.acceptFromServer در git-config(1)).

برای جزئیات درباره تمام مشخصات فیلتر موجود دیگر، گزینه --lter=<filter-spec> در git-rev-list(1) را ببینید.

برای مثال، --lter=blob:none تمامی blobها (محتوای فایل‌ها) را تا زمانی که توسط گیت مورد نیاز باشند فیلتر می‌کند. همچنین، --lter=blob:limit=<size> تمام blobهای با اندازه حداقل <size> را فیلتر خواهد کرد.

--504ite-fetch-head

نوشتن فهرست ارجاعات ریموت واکشی‌شده در فایل FETCH_HEAD مستقیماً زیر $GIT_DIR. این رفتار پیش‌فرض است. ارسال --0-write-fetch-head از خط فرمان به گیت می‌گوید که این فایل را ننویسد. تحت گزینه --ry-run، این فایل هرگز نوشته نمی‌شود.

-f, --rce

هنگامی که git fetch همراه با refspec به صورت <src>:<dst> استفاده شود، ممکن است همان‌طور که در بخش <refspec> در زیر بحث شده است از به‌روزرسانی شاخه محلی خودداری کند. این گزینه آن بررسی را لغو می‌کند.

-k, --ep

نگه‌داشتن بسته (pack) بارگیری‌شده.

--ltiple

امکان تعیین چندین آرگومان <repository> و <group>. هیچ <refspec> نباید مشخص شود.

--uto-maintenance, --0-auto-maintenance, --uto-gc, --0-auto-gc

اجرای دستور git maintenance run --uto در پایان کار جهت انجام نگهداری خودکار مخزن در صورت نیاز. این گزینه به صورت پیش‌فرض فعال است.

--288aph, --0-write-commit-graph

نوشتن یک commit-graph پس از واکشی. این گزینه تنظیم پیکربندی fetch.writeCommitGraph را نادیده می‌گیرد و بازنویسی می‌کند.

--refetch

تغییر refspec پیکربندی‌شده برای قرار دادن تمام ارجاعات در فضای نام refs/prefetch/. تسک prefetch را در git-maintenance(1) ببینید.

-p, --rune

قبل از واکشی، هرگونه ارجاع ردیابی ریموت را که دیگر در ریموت وجود ندارد حذف کنید. تگ‌ها در صورتی که فقط به دلیل دنبال کردن خودکار پیش‌فرض تگ‌ها یا به دلیل گزینه --ags واکشی شده باشند، مشمول هرس (pruning) نمی‌شوند. با این حال، اگر تگ‌ها به دلیل یک refspec صریح واکشی شوند (چه در خط فرمان و چه در پیکربندی ریموت، برای مثال اگر ریموت با گزینه --rror کلون شده باشد)، آن‌گاه مشمول هرس خواهند شد. تعیین گزینه --rune-tags روشی کوتاه برای ارائه refspec تگ است.

برای جزئیات بیشتر بخش «هرس کردن شاخه‌ها» (PRUNING) را در زیر ببینید.

-P, --rune-tags

قبل از واکشی، در صورت فعال بودن --rune، هرگونه تگ محلی را که دیگر در ریموت وجود ندارد حذف کنید. این گزینه باید با احتیاط بیشتری استفاده شود، زیرا برخلاف --rune هرگونه ارجاع محلی (تگ محلی) ایجادشده را حذف خواهد کرد. این گزینه یک روش کوتاه برای ارائه refspec صریح تگ به همراه --rune است، بحث مربوط به آن را در مستنداتش ببینید.

برای جزئیات بیشتر بخش «هرس کردن شاخه‌ها» (PRUNING) را در زیر ببینید.

-n, --0-tags

به طور پیش‌فرض، تگ‌هایی که به اشیاء بارگیری‌شده از مخزن ریموت اشاره می‌کنند واکشی و به صورت محلی ذخیره می‌شوند. این گزینه این دنبال کردن خودکار تگ‌ها را غیرفعال می‌کند. رفتار پیش‌فرض برای یک ریموت را می‌توان با تنظیم remote.<name>.tagOpt مشخص کرد. نگاه کنید به git-config(1).

--efetch

به جای مذاکره با سرور برای جلوگیری از انتقال کامیت‌ها و اشیاء مرتبط که قبلاً به صورت محلی وجود دارند، این گزینه تمام اشیاء را همان‌طور که یک کلون تازه انجام می‌دهد واکشی می‌کند. از این گزینه برای اعمال مجدد فیلتر کلون جزئی از پیکربندی یا با استفاده از --lter= هنگامی که تعریف فیلتر تغییر کرده است استفاده کنید. نگهداری خودکار پس از واکشی، یکپارچه‌سازی بسته‌های پایگاه داده اشیاء را برای حذف هرگونه شیء تکراری انجام خواهد داد.

--efmap=<refspec>

هنگام واکشی ارجاعات ذکرشده در خط فرمان، به جای مقادیر متغیرهای پیکربندی remote.<name>.fetch برای مخزن ریموت، از refspec مشخص‌شده (می‌تواند بیش از یک بار داده شود) برای نگاشت ارجاعات به شاخه‌های ردیابی ریموت استفاده کنید. ارائه یک <refspec> خالی به گزینه --efmap باعث می‌شود گیت refspecهای پیکربندی‌شده را نادیده بگیرد و کاملاً به refspecهای ارائه‌شده به عنوان آرگومان‌های خط فرمان اتکا کند. برای جزئیات بخش «شاخه‌های ردیابی ریموت پیکربندی‌شده» را ببینید.

-t, --ags

واکشی تمام تگ‌ها از ریموت (یعنی واکشی تگ‌های ریموت refs/tags/* در تگ‌های محلی با همان نام)، علاوه بر هر چیز دیگری که در غیر این صورت واکشی می‌شد. استفاده از این گزینه به تنهایی تگ‌ها را مشمول هرس نمی‌کند، حتی اگر --rune استفاده شود (اگرچه ممکن است تگ‌ها در صورتی که مقصد یک refspec صریح باشند به هر حال هرس شوند؛ گزینه --rune را ببینید).

--ecurse-submodules[=(yes|on-demand|no)]

کنترل اینکه آیا و تحت چه شرایطی کامیت‌های جدید زیرماژول‌ها نیز باید واکشی شوند. هنگام پیمایش بازگشتی در زیرماژول‌ها، git fetch همیشه تلاش می‌کند زیرماژول‌های "تغییریافته" را واکشی کند، یعنی زیرماژولی که دارای کامیت‌هایی است که توسط یک کامیت ابرپروژه (superproject) تازه واکشی‌شده ارجاع داده شده‌اند اما در کلون محلی زیرماژول وجود ندارند. یک زیرماژول تغییریافته تا زمانی که به صورت محلی مثلاً در $GIT_DIR/modules/ حضور داشته باشد می‌تواند واکشی شود (نگاه کنید به gitsubmodules(7))؛ اگر بالادست یک زیرماژول جدید اضافه کند، آن زیرماژول تا زمانی که کلون نشود (مثلاً توسط git submodule update) نمی‌تواند واکشی شود.

هنگامی که روی on-demand تنظیم شود، فقط زیرماژول‌های تغییریافته واکشی می‌شوند. هنگامی که روی yes تنظیم شود، تمام زیرماژول‌های پرشده واکشی می‌شوند و زیرماژول‌هایی که هم پرنشده و هم تغییریافته هستند نیز واکشی می‌گردند. هنگامی که روی no تنظیم شود، زیرماژول‌ها هرگز واکشی نمی‌شوند.

در صورت عدم تعیین، این گزینه از مقدار fetch.recurseSubmodules در صورت تنظیم بودن استفاده می‌کند (نگاه کنید به git-config(1))، و در صورت عدم تنظیم پیش‌فرض آن on-demand است. هنگامی که این گزینه بدون هیچ مقداری استفاده شود، پیش‌فرض آن yes خواهد بود.

-j <n>, --jobs=<n>

موازی‌سازی تمام اشکال واکشی تا سقف <n> شغل (job) در یک زمان.

مقدار 0 از یک پیش‌فرض منطقی استفاده خواهد کرد.

اگر گزینه --ltiple مشخص شده باشد، ریموت‌های مختلف به صورت موازی واکشی خواهند شد. اگر چندین زیرماژول واکشی شوند، آن‌ها به صورت موازی واکشی می‌شوند. برای کنترل مستقل آن‌ها، از تنظیمات پیکربندی fetch.parallel و submodule.fetchJobs استفاده کنید (نگاه کنید به git-config(1)).

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

--0-recurse-submodules

غیرفعال کردن واکشی بازگشتی زیرماژول‌ها (این همان اثر استفاده از گزینه --ecurse-submodules=no را دارد).

--t-upstream

اگر ریموت با موفقیت واکشی شد، ارجاع بالادست (ردیابی) را اضافه کنید که توسط git-pull(1) بدون آرگومان و سایر دستورات استفاده می‌شود. برای اطلاعات بیشتر، گزینه‌های branch.<name>.merge و branch.<name>.remote در git-config(1) را ببینید.

--bmodule-prefix=<path>

پیشوند دادن <path> به مسیرهای چاپ‌شده در پیام‌های آگاهی‌بخش مانند "Fetching submodule foo". این گزینه به صورت داخلی هنگام پیمایش بازگشتی روی زیرماژول‌ها استفاده می‌شود.

--ecurse-submodules-default=(yes|on-demand)

این گزینه به صورت داخلی برای ارائه موقت یک مقدار پیش‌فرض غیرمنفی برای گزینه --ecurse-submodules استفاده می‌شود. تمام روش‌های دیگر پیکربندی واکشی بازگشتی زیرماژول (مانند تنظیمات موجود در gitmodules(5) و git-config(1)) این گزینه را لغو می‌کنند، همان‌طور که تعیین صریح --[no-]recurse-submodules آن را بازنویسی می‌کند.

-u, --pdate-head-ok

به طور پیش‌فرض git fetch از به‌روزرسانی head که متناظر با شاخه فعلی است خودداری می‌کند. این پرچم آن بررسی را غیرفعال می‌نماید. این صرفاً برای استفاده داخلی جهت ارتباط git pull با git fetch است، و مگر اینکه در حال پیاده‌سازی Porcelain خودتان باشید، قرار نیست از آن استفاده کنید.

--pload-pack <upload-pack>

هنگامی که داده شود، و مخزنی که باید از آن واکشی انجام شود توسط git fetch-pack مدیریت شود، گزینه --\xec=<upload-pack> به دستور ارسال می‌شود تا مسیر غیرپیش‌فرضی را برای دستور اجراشده در سمت دیگر تعیین کند.

-q, --quiet

ارسال --quiet به git-fetch-pack و ساکت کردن سایر دستورات گیت استفاده‌شده در داخل. روند پیشرفت کار به جریان خطای استاندارد گزارش داده نمی‌شود.

-v, --

حالت پرگو (verbose).

--rogress

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

-o <option>, --rver-option=<option>

ارسال رشته داده‌شده به سرور در هنگام برقراری ارتباط با استفاده از نسخه پروتکل 2. رشته داده‌شده نباید حاوی کاراکتر NUL یا LF باشد. مدیریت گزینه‌های سرور توسط سرور، از جمله موارد ناشناخته، وابسته به سرور است. هنگامی که چندین --rver-option=<option> داده شود، همه آن‌ها به ترتیبی که در خط فرمان ذکر شده‌اند به طرف دیگر ارسال می‌شوند. هنگامی که هیچ --rver-option=<option> از خط فرمان داده نشود، مقادیر متغیر پیکربندی remote.<name>.serverOption در عوض استفاده می‌شوند.

--ow-forced-updates

به طور پیش‌فرض، گیت بررسی می‌کند که آیا یک شاخه در حین واکشی به صورت اجباری به‌روزرسانی شده است یا خیر. این ویژگی را می‌توان از طریق fetch.showForcedUpdates غیرفعال کرد، اما گزینه --ow-forced-updates تضمین می‌کند که این بررسی انجام پذیرد. نگاه کنید به git-config(1).

--0-show-forced-updates

به طور پیش‌فرض، گیت بررسی می‌کند که آیا یک شاخه در حین واکشی به صورت اجباری به‌روزرسانی شده است یا خیر. گزینه --0-show-forced-updates را ارسال کنید یا fetch.showForcedUpdates را به false تنظیم نمایید تا به دلایل کارایی از این بررسی صرف‌نظر شود. در صورت استفاده در حین git-pull، گزینه ---only همچنان قبل از اقدام به به‌روزرسانی سرراست (fast-forward)، به‌روزرسانی‌های اجباری را بررسی خواهد کرد. نگاه کنید به git-config(1).

-4, --ipv4

استفاده تنها از آدرس‌های IPv4، و نادیده گرفتن آدرس‌های IPv6.

-6, --ipv6

استفاده تنها از آدرس‌های IPv6، و نادیده گرفتن آدرس‌های IPv4.

<repository>

مخزن "ریموت" که مبدأ عملیات واکشی یا pull است. این پارامتر می‌تواند یک URL (بخش «آدرس‌های اینترنتی گیت» در زیر را ببینید) یا نام یک ریموت (بخش «مخازن ریموت» در زیر را ببینید) باشد.

<group>

نامی که به فهرستی از مخازن به عنوان مقدار remotes.<group> در فایل پیکربندی اشاره دارد. (نگاه کنید به git-config(1)).

<refspec>

مشخص می‌کند کدام ارجاعات باید واکشی شوند و کدام ارجاعات محلی باید به‌روزرسانی گردند. هنگامی که هیچ <refspec> در خط فرمان ظاهر نشود، ارجاعات مورد نظر برای واکشی در عوض از متغیرهای remote.<repository>.fetch خوانده می‌شوند (بخش «شاخه‌های ردیابی ریموت پیکربندی‌شده» در زیر را ببینید).

قالب پارامتر <refspec> شامل یک علامت مثبت اختیاری +، به دنبال آن مبدأ <src>، سپس دو نقطه :، و سپس مقصد <dst> است. هنگامی که <dst> خالی باشد می‌توان دو نقطه را حذف کرد. <src> به طور معمول یک ارجاع، یا یک الگوی glob با یک * واحد است که برای تطبیق با مجموعه‌ای از ارجاعات استفاده می‌شود، اما می‌تواند یک نام شیء هگزادسیمال کامل نیز باشد.

یک <refspec> ممکن است حاوی یک * در <src> خود باشد تا تطابق الگوی ساده را نشان دهد. چنین refspecی مانند یک glob عمل می‌کند که با هر ارجاع منطبق با الگو تطابق دارد. یک الگوی <refspec> باید یک و تنها یک * در هر دو بخش <src> و <dst> داشته باشد. این الگو ارجاعات را با جایگزینی * با محتوای منطبق‌شده از مبدأ به مقصد نگاشت می‌کند.

اگر یک refspec دارای پیشوند ^ باشد، به عنوان یک refspec منفی تفسیر خواهد شد. چنین refspecی به جای تعیین اینکه کدام ارجاعات واکشی شوند یا کدام ارجاعات محلی به‌روزرسانی گردند، در عوض ارجاعات مستثنی‌شده را مشخص می‌کند. یک ارجاع در صورتی منطبق در نظر گرفته می‌شود که حداقل با یک refspec مثبت تطابق داشته باشد و با هیچ refspec منفی تطابق نداشته باشد. refspecهای منفی می‌توانند برای محدود کردن دامنه یک الگوی refspec مفید باشند تا ارجاعات خاصی را شامل نشود. خود refspecهای منفی نیز می‌توانند الگوی refspec باشند. با این حال، آن‌ها تنها می‌توانند حاوی <src> باشند و مقصدی <dst> را مشخص نمی‌کنند. نام‌های شیء هگزادسیمال کامل نیز پشتیبانی نمی‌شوند.

عبارت tag <tag> معادل refs/tags/<tag>:refs/tags/<tag> است؛ این عبارت واکشی همه‌چیز را تا تگ داده‌شده درخواست می‌کند.

ارجاع ریموت منطبق با <src> واکشی می‌شود، و اگر <dst> یک رشته خالی نباشد، تلاش می‌شود تا ارجاع محلی منطبق با آن به‌روزرسانی شود.

اینکه آیا این به‌روزرسانی بدون --rce مجاز است یا خیر، به فضای نام ارجاعی که به آن واکشی می‌شود، نوع شیء در حال واکشی و اینکه آیا به‌روزرسانی یک fast-forward در نظر گرفته می‌شود بستگی دارد. به طور کلی، همان قوانینی که هنگام push اعمال می‌شوند برای fetch نیز اعمال می‌گردند؛ برای آگاهی از این قوانین بخش <refspec>... در git-push(1) را ببینید. استثنائات خاص این قوانین برای git fetch در زیر ذکر شده است.

تا نسخه 2.20 گیت، و برخلاف زمان ارسال با git-push(1)، هرگونه به‌روزرسانی برای refs/tags/* بدون + در refspec (یا --rce) پذیرفته می‌شد. هنگام واکشی، ما تمام به‌روزرسانی‌های تگ از یک ریموت را بدون تفکیک به عنوان واکشی‌های اجباری در نظر می‌گرفتیم. از نسخه 2.20 گیت، واکشی برای به‌روزرسانی refs/tags/* همانند زمان push کار می‌کند. یعنی هرگونه به‌روزرسانی بدون + در refspec (یا --rce) رد خواهد شد.

برخلاف زمان ارسال با git-push(1)، هرگونه به‌روزرسانی خارج از refs/{tags,heads}/* بدون + در refspec (یا --rce) پذیرفته می‌شود، چه این تغییر جابجایی مثلاً یک شیء tree به جای blob باشد، یا یک کامیت برای کامیت دیگری که کامیت قبلی را به عنوان جد خود ندارد و غیره.

برخلاف زمان ارسال با git-push(1)، هیچ پیکربندی وجود ندارد که این قوانین را اصلاح کند، و هیچ قلابی مانند pre-fetch مشابه با قلاب pre-receive وجود ندارد.

همانند ارسال با git-push(1)، تمام قوانین توصیف‌شده در بالا درباره آنچه به عنوان به‌روزرسانی مجاز نیست، می‌توانند با افزودن یک علامت + اختیاری در ابتدای یک refspec (یا استفاده از گزینه خط فرمان --rce) نادیده گرفته و بازنویسی شوند. تنها استثنا در این مورد این است که هیچ مقداری از اجبار باعث نمی‌شود فضای نام refs/heads/* یک شیء غیرکامیت را بپذیرد. {.sp


نکته
هنگامی که مشخص است شاخه ریموتی که می‌خواهید واکشی کنید به طور مرتب به عقب برگردانده شده و rebase می‌شود، انتظار می‌رود که نوک جدید آن از نوک قبلی خود (همان‌طور که در آخرین واکشی در شاخه ردیابی ریموت شما ذخیره شده است) منشعب نشده باشد. در چنین شرایطی مایل خواهید بود از علامت + استفاده کنید تا نشان دهید برای چنین شاخه‌هایی به‌روزرسانی‌های غیر fast-forward مورد نیاز خواهد بود. هیچ راهی برای تشخیص یا اعلام اینکه شاخه‌ای با این رفتار در مخزن در دسترس قرار خواهد گرفت وجود ندارد؛ کاربر واکشی‌کننده صرفاً باید بداند که این الگوی استفاده مورد انتظار برای شاخه است.

--din

خواندن refspecها، هر خط یکی، از stdin علاوه بر مواردی که به عنوان آرگومان ارائه شده‌اند. قالب "tag <name>" پشتیبانی نمی‌شود.

به طور کلی، URLها حاوی اطلاعاتی درباره پروتکل انتقال، آدرس سرور ریموت و مسیر مخزن هستند. بسته به پروتکل انتقال، ممکن است برخی از این اطلاعات وجود نداشته باشند.

گیت از پروتکل‌های ssh، git، http و https پشتیبانی می‌کند (علاوه بر این، ftp و ftps می‌توانند برای واکشی استفاده شوند، اما این روش ناکارآمد و منسوخ است؛ از آن‌ها استفاده نکنید).

انتقال بومی (یعنی URL با git://) هیچ احراز هویتی انجام نمی‌دهد و باید در شبکه‌های ناامن با احتیاط استفاده شود.

نحو‌های زیر ممکن است با آن‌ها استفاده شوند:

{•
•
ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
{•
•
git://<host>[:<port>]/<path-to-git-repo>
{•
•
http[s]://<host>[:<port>]/<path-to-git-repo>
{•
•
ftp[s]://<host>[:<port>]/<path-to-git-repo>

همچنین می‌توان از یک نحو جایگزین شبیه به scp با پروتکل ssh استفاده کرد:

{•
•
[<user>@]<host>:/<path-to-git-repo>

این نحو تنها زمانی شناسایی می‌شود که هیچ اسلشی قبل از اولین دونقطه وجود نداشته باشد. این به تمایز یک مسیر محلی که حاوی دونقطه است کمک می‌کند. برای مثال، مسیر محلی foo:bar می‌تواند به عنوان یک مسیر مطلق یا ./foo:bar مشخص شود تا از تفسیر اشتباه آن به عنوان یک URL مبتنی بر ssh جلوگیری گردد.

پروتکل‌های ssh و git علاوه بر این از بسط ~<username> پشتیبانی می‌کنند:

{•
•
ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
{•
•
git://<host>[:<port>]/~<user>/<path-to-git-repo>
{•
•
[<user>@]<host>:~<user>/<path-to-git-repo>

برای مخازن محلی که به صورت بومی نیز توسط گیت پشتیبانی می‌شوند، می‌توان از نحوهای زیر استفاده کرد:

{•
•
/path/to/repo.git/
{•
•
file:///path/to/repo.git/

این دو نحو عمدتاً معادل هستند، به جز زمان کلون کردن، که در آن نحو اول گزینه --ne(1) را ببینید.

دستورات git clone، git fetch و git pull، اما نه git push، یک فایل باندل (bundle) مناسب را نیز می‌پذیرند. نگاه کنید به git-bundle(1).

هنگامی که گیت نحوه کار با یک پروتکل انتقال خاص را نمی‌داند، تلاش می‌کند از دستیار ریموت remote-<transport> در صورت وجود استفاده کند. برای درخواست صریح یک دستیار ریموت، می‌توان از نحو زیر استفاده کرد:

{•
•
<transport>::<address>

که در آن <address> ممکن است یک مسیر، یک سرور و مسیر، یا یک رشته دلخواه شبیه به URL باشد که توسط دستیار ریموت فراخوانی‌شده شناسایی می‌شود. برای جزئیات gitremote-helpers(7) را ببینید.

اگر تعداد زیادی مخزن ریموت با نام‌های مشابه وجود دارد و می‌خواهید از قالب متفاوتی برای آن‌ها استفاده کنید (به طوری که URLهایی که استفاده می‌کنید به URLهای فعال بازنویسی شوند)، می‌توانید یک بخش پیکربندی به شکل زیر ایجاد کنید:

{.RS 4

[url "<actual-url-base>"]
        insteadOf = <other-url-base>
{.RE

به عنوان مثال با این تنظیمات:

{.RS 4

[url "git://git.host.xz/"]
        insteadOf = host.xz:/path/to/
        insteadOf = work:
{.RE

یک URL مانند "work:repo.git" یا مانند "host.xz:/path/to/repo.git" در هر زمینه‌ای که یک URL دریافت می‌کند، به "git://git.host.xz/repo.git" بازنویسی خواهد شد.

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

{.RS 4

[url "<actual-url-base>"]
        pushInsteadOf = <other-url-base>
{.RE

به عنوان مثال با این تنظیم:

{.RS 4

[url "ssh://example.org/"]
        pushInsteadOf = git://example.org/
{.RE

یک URL مانند "git://example.org/path/to/repo.git" برای عملیات‌های push به "ssh://example.org/path/to/repo.git" بازنویسی خواهد شد، اما عملیات‌های pull همچنان از URL اصلی استفاده خواهند کرد.

می‌توان از نام یکی از موارد زیر به عنوان آرگومان <repository> به جای یک URL استفاده کرد:

{•
•
یک ریموت در فایل پیکربندی گیت: $GIT_DIR/config،
{•
•
یک فایل در دایرکتوری $GIT_DIR/remotes، یا
{•
•
یک فایل در دایرکتوری $GIT_DIR/branches.

تمامی این موارد همچنین به شما امکان می‌دهند refspec را از خط فرمان حذف کنید زیرا هر کدام شامل یک refspec هستند که گیت به طور پیش‌فرض از آن استفاده خواهد کرد.

می‌توانید نام ریموتی را ارائه دهید که قبلاً با استفاده از git-remote(1)، git-config(1) یا حتی با ویرایش دستی فایل $GIT_DIR/config پیکربندی کرده‌اید. از URL این ریموت برای دسترسی به مخزن استفاده خواهد شد. هنگامی که یک refspec در خط فرمان ارائه نمی‌کنید، refspec این ریموت به طور پیش‌فرض استفاده می‌شود. مدخل در فایل پیکربندی به این صورت خواهد بود:

{.RS 4

[remote "<name>"]
        url = <URL>
        pushurl = <pushurl>
        push = <refspec>
        fetch = <refspec>
{.RE

آرگومان <pushurl> تنها برای عملیات‌های push استفاده می‌شود. اختیاری است و پیش‌فرض آن <URL> است. ارسال (push) به یک ریموت بر تمام pushurlهای تعریف‌شده یا تمام urlهای تعریف‌شده در صورت عدم وجود pushurl تأثیر می‌گذارد. با این حال، دستور fetch در صورت تعریف چندین url، تنها از اولین url تعریف‌شده واکشی خواهد کرد.

می‌توانید نام فایلی را در $GIT_DIR/remotes مشخص کنید. از URL موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد. refspec موجود در این فایل هنگامی که در خط فرمان refspec ارائه نکنید به عنوان پیش‌فرض استفاده می‌شود. این فایل باید قالب زیر را داشته باشد:

{.RS 4

URL: یکی از قالب‌های URL بالا
Push: <refspec>
Pull: <refspec>
{.RE

خطوط Push: توسط git push استفاده می‌شوند و خطوط Pull: توسط git pull و git fetch به کار می‌روند. ممکن است چندین خط Push: و Pull: برای نگاشت‌های شاخه اضافی مشخص شوند.

می‌توانید نام فایلی را در $GIT_DIR/branches مشخص کنید. از URL موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد. این فایل باید قالب زیر را داشته باشد:

{.RS 4

<URL>#<head>
{.RE

آرگومان <URL> الزامی است؛ #<head> اختیاری است.

بسته به نوع عملیات، اگر refspec را در خط فرمان ارائه نکنید، گیت از یکی از refspecهای زیر استفاده خواهد کرد. <branch> نام این فایل در $GIT_DIR/branches است و پیش‌فرض <head> برابر با master می‌باشد.

دستور git fetch استفاده می‌کند از:

{.RS 4

refs/heads/<head>:refs/heads/<branch>
{.RE

دستور git push استفاده می‌کند از:

{.RS 4

HEAD:refs/heads/<head>
{.RE

شاخه‌ها در گیت می‌توانند به صورت اختیاری دارای یک شاخه ریموت بالادست (upstream) باشند. گیت به طور پیش‌فرض از شاخه بالادست برای عملیات‌های ریموت استفاده می‌کند، به عنوان مثال:

{•
•
این شاخه پیش‌فرض برای git pull یا git fetch بدون آرگومان است.
{•
•
این شاخه پیش‌فرض برای git push بدون آرگومان است، با برخی استثناها. برای مثال، می‌توانید از گزینه branch.<name>.pushRemote برای push کردن به ریموتی متفاوت از ریموتی که از آن pull می‌کنید استفاده نمایید، و به طور پیش‌فرض با push.default=simple شاخه بالادستی که پیکربندی می‌کنید باید همان نام را داشته باشد.
{•
•
دستورات مختلف، از جمله git checkout و git status، به شما نشان می‌دهند که چه تعداد کامیت از زمان انشعاب به شاخه فعلی و بالادست شما اضافه شده است، برای مثال "Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively".

شاخه بالادست در .git/config، در فیلدهای "remote" و "merge" ذخیره می‌شود. به عنوان مثال، اگر شاخه بالادست main برابر با origin/main باشد:

{.RS 4

[branch "main"]
   remote = origin
   merge = refs/heads/main
{.RE

می‌توانید با دستور git push --t-upstream <remote> <branch> یک شاخه بالادست را صراحتاً تنظیم کنید، اما گیت معمولاً بالادست را به طور خودکار برای شما تنظیم می‌کند، برای مثال:

{•
•
هنگامی که یک مخزن را کلون می‌کنید، گیت به طور خودکار شاخه بالادست را برای شاخه پیش‌فرض تنظیم می‌کند.
{•
•
اگر گزینه پیکربندی push.autoSetupRemote را تنظیم کرده باشید، git push در اولین باری که شاخه‌ای را push می‌کنید، بالادست را به طور خودکار تنظیم خواهد کرد.
{•
•
چک‌اوت کردن یک شاخه ردیابی ریموت با git checkout <branch> به طور خودکار یک شاخه محلی با آن نام ایجاد کرده و بالادست را به شاخه ریموت تنظیم می‌کند.
{.sp

نکته

گاهی از شاخه‌های بالادست به عنوان "اطلاعات ردیابی" (tracking information) یاد می‌شود، مانند "set the branch’s tracking information".

شما اغلب با یک مخزن ریموت یکسان از طریق واکشی منظم و مکرر تعامل دارید. به منظور پیگیری روند پیشرفت چنین مخزن ریموتی، git fetch به شما امکان می‌دهد متغیرهای پیکربندی remote.<repository>.fetch را تنظیم کنید.

به طور معمول چنین متغیری ممکن است به شکل زیر باشد:

{.RS 4

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
{.RE

این پیکربندی به دو روش استفاده می‌شود:

{•
•
هنگامی که git fetch بدون مشخص کردن شاخه‌ها و/یا تگ‌ها برای واکشی در خط فرمان اجرا می‌شود (مانند git fetch origin یا git fetch)، مقادیر remote.<repository>.fetch به عنوان refspecها استفاده می‌شوند — آن‌ها مشخص می‌کنند کدام ارجاعات باید واکشی شوند و کدام ارجاعات محلی باید به‌روزرسانی گردند. مثال بالا تمام شاخه‌های موجود در origin (یعنی هر ارجاعی که با سمت چپ مقدار، یعنی refs/heads/* تطابق دارد) را واکشی کرده و شاخه‌های ردیابی ریموت مربوطه را در سلسله‌مراتب refs/remotes/origin/* به‌روزرسانی می‌کند.
{•
•
هنگامی که git fetch با شاخه‌ها و/یا تگ‌های صریح برای واکشی در خط فرمان اجرا می‌شود (مانند git fetch origin master)، مقادیر <refspec>s داده‌شده در خط فرمان تعیین می‌کنند چه مواردی باید واکشی شوند (مثلاً master در مثال، که یک خلاصه برای master: است، که به نوبه خود به این معنی است که "شاخه master را واکشی کن اما من صراحتاً نمی‌گویم کدام شاخه ردیابی ریموت با آن به‌روزرسانی شود")، و دستور مثال تنها شاخه master را واکشی خواهد کرد. مقادیر remote.<repository>.fetch تعیین می‌کنند کدام شاخه ردیابی ریموت (در صورت وجود) به‌روزرسانی شود. هنگامی که به این شیوه استفاده شود، مقادیر remote.<repository>.fetch هیچ اثری در تصمیم‌گیری درباره اینکه چه چیزی واکشی شود ندارند (یعنی زمانی که خط فرمان refspecها را فهرست می‌کند، این مقادیر به عنوان refspec استفاده نمی‌شوند)؛ آن‌ها تنها با ایفای نقش یک نگاشت، برای تعیین اینکه ارجاعات واکشی‌شده در کجا ذخیره شوند استفاده می‌شوند.

استفاده اخیر از مقادیر remote.<repository>.fetch می‌تواند با ارائه پارامتر(های) --efmap=<refspec> در خط فرمان لغو و بازنویسی شود.

گیت دارای یک رفتار پیش‌فرض برای حفظ داده‌ها است مگر اینکه صراحتاً دور ریخته شوند؛ این امر به نگه‌داشتن ارجاعات محلی به شاخه‌هایی در ریموت‌ها که خودشان آن شاخه‌ها را حذف کرده‌اند نیز تسری می‌یابد.

در صورت رها شدن و انباشته شدن، این ارجاعات کهنه ممکن است عملکرد را در مخازن بزرگ و پرکار با جابجایی زیاد شاخه‌ها تضعیف کنند، و به عنوان مثال خروجی دستوراتی مانند git branch -a --ontains <commit> را بی‌جهت طولانی کنند، و همچنین بر هر چیز دیگری که با مجموعه کامل ارجاعات شناخته‌شده کار می‌کند تأثیر بگذارند.

این ارجاعات ردیابی ریموت را می‌توان به صورت یک‌باره با یکی از دستورات زیر حذف کرد:

{.RS 4

# در حین واکشی
$ git fetch --rune
<name>
# فقط هرس کن، واکشی انجام نده
$ git remote prune <name>
{.RE

برای هرس ارجاعات به عنوان بخشی از گردش کار عادی خود بدون نیاز به یادآوری اجرای آن، fetch.prune را به صورت سراسری، یا remote.<name>.prune را برای هر ریموت در پیکربندی تنظیم کنید. نگاه کنید به git-config(1).

اینجا جایی است که موضوع پیچیده‌تر و خاص‌تر می‌شود. ویژگی هرس در واقع به شاخه‌ها اهمیتی نمی‌دهد، بلکه ارجاعات محلی --> ریموت را به عنوان تابعی از refspec ریموت هرس می‌کند (بخش‌های <refspec> و «شاخه‌های ردیابی ریموت پیکربندی‌شده» در بالا را ببینید).

بنابراین اگر refspec برای ریموت شامل مثلاً refs/tags/*:refs/tags/* باشد، یا شما به صورت دستی دستوری مانند git fetch --rune
<name> "refs/tags/*:refs/tags/*" را اجرا کنید، این شاخه‌های ردیابی ریموت کهنه نیستند که حذف می‌شوند، بلکه هر تگ محلی که در ریموت وجود ندارد حذف خواهد شد.

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

بنابراین هنگام استفاده از این ویژگی با یک refspec مانند refs/tags/*:refs/tags/*، یا هر refspec دیگری که ممکن است ارجاعات از چندین ریموت را به یک فضای نام محلی یکسان نگاشت کند، بسیار مراقب باشید.

از آنجا که به‌روز نگه داشتن شاخه‌ها و تگ‌ها در ریموت یک مورد کاربرد رایج است، گزینه --rune-tags
را می‌توان همراه با --rune
برای هرس تگ‌های محلی که در ریموت وجود ندارند، و به‌روزرسانی اجباری تگ‌هایی که متفاوت هستند ارائه کرد. هرس تگ‌ها را می‌توان با fetch.pruneTags یا remote.<name>.pruneTags در پیکربندی نیز فعال کرد. نگاه کنید به git-config(1).

گزینه --rune-tags
معادل اعلام refs/tags/*:refs/tags/* در refspecهای ریموت است. این می‌تواند منجر به برخی رفتارهای به ظاهر عجیب شود:

{.RS 4

# هر دوی این دستورات تگ‌ها را واکشی می‌کنند
$ git fetch --0-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --0-tags --rune-tags
origin
{.RE

دلیل اینکه هنگام ارائه بدون --rune
یا نسخه‌های پیکربندی آن خطا نمی‌دهد، انعطاف‌پذیری نسخه‌های پیکربندی‌شده و حفظ نگاشت ۱ به ۱ بین عملکرد پرچم‌های خط فرمان و گزینه‌های پیکربندی است.

بسیار منطقی است که برای مثال fetch.pruneTags=true در ~/.gitconfig پیکربندی شود تا هر زمان که git fetch --rune
اجرا می‌شود تگ‌ها هرس شوند، بدون اینکه هر بار فراخوانی git fetch بدون --rune
به یک خطا تبدیل شود.

هرس کردن تگ‌ها با --rune-tags
هنگام واکشی یک URL به جای یک ریموت نام‌گذاری‌شده نیز کار می‌کند. تمام موارد زیر تگ‌هایی را که در origin یافت نمی‌شوند هرس می‌کنند:

{.RS 4

$ git fetch origin --rune
--rune-tags
$ git fetch origin --rune
'refs/tags/*:refs/tags/*'
$ git fetch <url-of-origin> --rune
--rune-tags
$ git fetch <url-of-origin> --rune
'refs/tags/*:refs/tags/*'
{.RE

خروجی "git fetch" بستگی به روش انتقال مورد استفاده دارد؛ این بخش خروجی را هنگام واکشی بر روی پروتکل گیت (چه به صورت محلی یا از طریق ssh) و پروتکل هوشمند Smart HTTP شرح می‌دهد.

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

{.RS 4

<flag> <summary> <from> -> <to> [<reason>]
{.RE

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

{.RS 4

<flag> <old-object-id> <new-object-id> <local-reference>
{.RE

وضعیت ارجاعات به‌روز (up-to-date) تنها در صورتی نشان داده می‌شود که گزینه -- استفاده شده باشد.

در حالت خروجی فشرده (compact)، که با متغیر پیکربندی fetch.output مشخص می‌شود، اگر تمام رشته <from> یا <to> در رشته دیگر یافت شود، در رشته دیگر با * جایگزین خواهد شد. به عنوان مثال، master -> origin/master تبدیل می‌شود به master -> origin/*.

flag

یک نویسه تک که وضعیت ارجاع را نشان می‌دهد:

(space)

برای یک fast-forward با موفقیت واکشی‌شده؛

+

برای یک به‌روزرسانی اجباری موفق؛

-

برای یک ارجاع با موفقیت هرس‌شده؛

t

برای یک به‌روزرسانی موفق تگ؛

*

برای یک ارجاع جدید با موفقیت واکشی‌شده؛

!

برای ارجاعی که رد شد یا به‌روزرسانی آن شکست خورد؛ و

=

برای ارجاعی که به‌روز بود و نیازی به واکشی نداشت.

summary

برای یک ارجاع با موفقیت واکشی‌شده، خلاصه مقادیر قدیمی و جدید ارجاع را در قالبی مناسب برای استفاده به عنوان آرگومان در git log نشان می‌دهد (این در بیشتر موارد به صورت <old>..<new> و برای به‌روزرسانی‌های اجباری غیر fast-forward به صورت <old>...<new> است).

from

نام ارجاع ریموت که از آن واکشی می‌شود، منهای پیشوند refs/<type>/ آن. در صورت حذف، نام ارجاع ریموت "(none)" است.

to

نام ارجاع محلی که در حال به‌روزرسانی است، منهای پیشوند refs/<type>/ آن.

reason

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

{•
•
به‌روزرسانی شاخه‌های ردیابی ریموت:

{.RS 4

$ git fetch origin
{.RE

دستور فوق تمام شاخه‌ها را از فضای نام ریموت refs/heads/ کپی کرده و آن‌ها را در فضای نام محلی refs/remotes/origin/ ذخیره می‌کند، مگر اینکه از گزینه remote.<repository>.fetch برای تعیین یک refspec غیرپیش‌فرض استفاده شده باشد.

{•
•
استفاده صریح از refspecها:

{.RS 4

$ git fetch origin +seen:seen maint:tmp
{.RE

این دستور شاخه‌های seen و tmp را در مخزن محلی با واکشی از شاخه‌های (به ترتیب) seen و maint از مخزن ریموت به‌روزرسانی (یا در صورت لزوم ایجاد) می‌کند.

شاخه seen حتی اگر fast-forward نباشد به‌روزرسانی خواهد شد، زیرا دارای پیشوند علامت مثبت است؛ شاخه tmp این‌گونه نخواهد بود.

{•
•
مشاهده شاخه یک ریموت، بدون پیکربندی ریموت در مخزن محلی شما:

{.RS 4

$ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD
{.RE

دستور اول شاخه maint را از مخزن در git://git.kernel.org/pub/scm/git/git.git واکشی می‌کند و دستور دوم از FETCH_HEAD برای بررسی شاخه با git-log(1) استفاده می‌کند. اشیاء واکشی‌شده در نهایت توسط خانه‌داری داخلی گیت حذف خواهند شد (نگاه کنید به git-gc(1)).

پروتکل‌های fetch و push طوری طراحی نشده‌اند که مانع از دزدیدن داده‌هایی از مخزن دیگر توسط یک طرف شوند که قرار نبوده به اشتراک گذاشته شوند. اگر داده‌های خصوصی دارید که باید از یک همتای مخرب محافظت شوند، بهترین گزینه ذخیره آن در یک مخزن دیگر است. این مورد هم برای کلاینت‌ها و هم برای سرورها صدق می‌کند. به ویژه، فضاهای نام روی یک سرور برای کنترل دسترسی خواندن مؤثر نیستند؛ شما فقط باید دسترسی خواندن به یک فضای نام را به کلاینت‌هایی اعطا کنید که به آن‌ها برای دسترسی خواندن به کل مخزن اعتماد دارید.

بردارهای حمله شناخته‌شده به شرح زیر هستند:

{ 1.
1.
قربانی خطوط "have" را ارسال می‌کند که شناسه‌های اشیائی را که در اختیار دارد و صراحتاً قصد به اشتراک‌گذاری آن‌ها را نداشته اما در صورت در اختیار داشتن آن‌ها توسط طرف مقابل می‌توانند برای بهینه‌سازی انتقال استفاده شوند، اعلان می‌کند. مهاجم یک شناسه شیء X را برای سرقت انتخاب کرده و یک ارجاع به X ارسال می‌کند، اما نیازی به ارسال محتوای X ندارد زیرا قربانی از قبل آن را دارد. اکنون قربانی باور می‌کند که مهاجم X را دارد، و بعداً محتوای X را برای مهاجم پس می‌فرستد. (انجام این حمله برای کلاینت روی سرور ساده‌ترین روش است، با ایجاد یک ارجاع به X در فضای نامی که کلاینت به آن دسترسی دارد و سپس واکشی آن. محتمل‌ترین روش برای انجام آن توسط سرور روی کلاینت، "ادغام" X در یک شاخه عمومی و امیدواری به این است که کاربر کارهای بیشتری روی این شاخه انجام داده و بدون توجه به ادغام، آن را به سرور push کند).
{ 2.
2.
همانند شماره ۱، مهاجم یک شناسه شیء X را برای سرقت انتخاب می‌کند. قربانی شیء Y را که مهاجم از قبل دارد ارسال می‌کند، و مهاجم به دروغ ادعا می‌کند که X را دارد و نه Y را، بنابراین قربانی Y را به عنوان یک دلتا نسبت به X ارسال می‌کند. این دلتا بخش‌هایی از X را که شبیه به Y هستند برای مهاجم آشکار می‌سازد.

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

fetch.recurseSubmodules

این گزینه کنترل می‌کند که آیا git fetch (و واکشی زیرین در git pull) به صورت بازگشتی در زیرماژول‌های پرشده واکشی کند یا خیر. این گزینه می‌تواند روی یک مقدار بولی یا روی on-demand تنظیم شود. تنظیم آن روی یک مقدار بولی رفتار fetch و pull را تغییر می‌دهد تا در صورت تنظیم روی true به طور بدون قید و شرط در زیرماژول‌ها پیمایش بازگشتی انجام دهد یا در صورت تنظیم روی false اصلاً پیمایش بازگشتی انجام ندهد. هنگامی که روی on-demand تنظیم شود، fetch و pull تنها زمانی در یک زیرماژول پرشده پیمایش بازگشتی انجام می‌دهند که ابرپروژه آن کامیتی را بازیابی کند که ارجاع زیرماژول را به‌روزرسانی می‌نماید. پیش‌فرض آن on-demand است، یا در صورت تنظیم بودن، مقدار submodule.recurse خواهد بود.

fetch.fsckObjects

اگر روی true تنظیم شود، git-fetch-pack تمام اشیاء واکشی‌شده را بررسی خواهد کرد. برای آگاهی از آنچه بررسی می‌شود به transfer.fsckObjects مراجعه کنید. مقدار پیش‌فرض false است. در صورت عدم تنظیم، مقدار transfer.fsckObjects در عوض استفاده می‌شود.

fetch.fsck.<msg-id>

همانند fsck.<msg-id> عمل می‌کند، اما توسط git-fetch-pack(1) به جای git-fsck(1) استفاده می‌شود. برای جزئیات مستندات fsck.<msg-id> را ببینید.

fetch.fsck.skipList

همانند fsck.skipList عمل می‌کند، اما توسط git-fetch-pack(1) به جای git-fsck(1) استفاده می‌شود. برای جزئیات مستندات fsck.skipList را ببینید.

fetch.unpackLimit

اگر تعداد اشیاء واکشی‌شده بر روی انتقال بومی گیت کمتر از این حد باشد، اشیاء در فایل‌های شیء مجزا (loose) بازگشایی می‌شوند. با این حال اگر تعداد اشیاء دریافتی برابر یا بیشتر از این حد باشد، بسته دریافتی پس از افزودن هرگونه پایه دلتای مفقود، به عنوان یک pack ذخیره می‌شود. ذخیره بسته حاصل از یک push می‌تواند عملیات push را به ویژه در سیستم‌های فایل کند سریع‌تر به پایان برساند. در صورت عدم تنظیم، مقدار transfer.unpackLimit در عوض استفاده می‌شود.

fetch.prune

اگر true باشد، fetch به طور خودکار به گونه‌ای عمل می‌کند که گویی گزینه --rune در خط فرمان داده شده است. همچنین remote.<name>.prune و بخش «هرس کردن شاخه‌ها» (PRUNING) در git-fetch(1) را ببینید.

fetch.pruneTags

اگر true باشد، fetch در هنگام هرس به طور خودکار به گونه‌ای رفتار می‌کند که گویی refspec به صورت refs/tags/*:refs/tags/* ارائه شده است، در صورتی که قبلاً تنظیم نشده باشد. این امر امکان تنظیم هم این گزینه و هم fetch.prune را برای حفظ نگاشت ۱ به ۱ با ارجاعات بالادست فراهم می‌کند. همچنین remote.<name>.pruneTags و بخش «هرس کردن شاخه‌ها» (PRUNING) در git-fetch(1) را ببینید.

fetch.all

اگر true باشد، fetch تلاش خواهد کرد تمام ریموت‌های موجود را به‌روزرسانی کند. این رفتار می‌تواند با ارسال --0-all یا با تعیین صریح یک یا چند ریموت برای واکشی لغو و بازنویسی شود. مقدار پیش‌فرض false است.

fetch.output

نحوه چاپ وضعیت به‌روزرسانی ارجاع را کنترل می‌کند. مقادیر معتبر عبارتند از full و compact. مقدار پیش‌فرض full است. برای جزئیات بخش خروجی (OUTPUT) در git-fetch(1) را ببینید.

fetch.negotiationAlgorithm

نحوه ارسال اطلاعات مربوط به کامیت‌ها در مخزن محلی را هنگام مذاکره درباره محتویات packfile ارسالی توسط سرور کنترل می‌کند. روی consecutive تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌های متوالی را پیمایش کرده و هر یک را بررسی می‌کند. روی skipping تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌ها را با هدف همگرایی سریع‌تر نادیده می‌گیرد (skip می‌کند)، اما ممکن است منجر به یک packfile بزرگ‌تر از حد لازم شود؛ یا روی noop تنظیم کنید تا اصلاً هیچ اطلاعاتی ارسال نشود، که تقریباً به طور قطع منجر به یک packfile بزرگ‌تر از حد لازم خواهد شد، اما از مرحله مذاکره صرف‌نظر می‌کند. روی default تنظیم کنید تا تنظیمات انجام‌شده قبلی لغو شده و از رفتار پیش‌فرض استفاده شود. پیش‌فرض معمولاً consecutive است، اما اگر feature.experimental برابر با true باشد، آن‌گاه پیش‌فرض skipping خواهد بود. مقادیر ناشناخته باعث بروز خطا در git fetch خواهند شد.

همچنین گزینه‌های --0gotiate-only و --0gotiation-restrict در git-fetch(1) را ببینید.

fetch.showForcedUpdates

روی false تنظیم کنید تا --0-show-forced-updates در دستورات git-fetch(1) و git-pull(1) فعال شود. مقدار پیش‌فرض true است.

fetch.parallel

حداکثر تعداد عملیات واکشی را که می‌توانند به طور همزمان به صورت موازی اجرا شوند مشخص می‌کند (زیرماژول‌ها، یا ریموت‌ها هنگامی که گزینه --ltiple در git-fetch(1) فعال باشد).

مقدار 0 پیش‌فرضی منطقی تعیین خواهد کرد. در صورت عدم تنظیم، پیش‌فرض آن 1 است.

برای زیرماژول‌ها، این تنظیم می‌تواند با استفاده از تنظیم پیکربندی submodule.fetchJobs بازنویسی شود.

fetch.writeCommitGraph

روی true تنظیم کنید تا پس از هر دستور git fetch که یک pack-file را از یک ریموت بارگیری می‌کند، یک commit-graph نوشته شود. با استفاده از گزینه --lit، اکثر اجراها یک فایل commit-graph بسیار کوچک بر روی فایل(های) commit-graph موجود ایجاد می‌کنند. گاهی اوقات این فایل‌ها ادغام می‌شوند و نوشتن ممکن است بیشتر طول بکشد. داشتن یک فایل commit-graph به‌روز به عملکرد بسیاری از دستورات گیت کمک می‌کند، از جمله git merge-base، git push -f و git log --aph. مقدار پیش‌فرض false است.

fetch.bundleURI

این مقدار یک URI را برای بارگیری داده‌های شیء گیت از یک bundle URI قبل از انجام واکشی افزایشی از سرور اصلی گیت ذخیره می‌کند. این شبیه به نحوه رفتار گزینه --ri در git-clone(1) است. دستور git clone --ri مقدار fetch.bundleURI را در صورتی که bundle URI ارائه‌شده حاوی فهرست باندلی باشد که برای واکشی‌های افزایشی سازماندهی شده است تنظیم خواهد کرد.

اگر این مقدار را تغییر دهید و مخزن شما دارای مقدار fetch.bundleCreationToken باشد، آن‌گاه پیش از واکشی از bundle URI جدید، آن مقدار fetch.bundleCreationToken را حذف کنید.

fetch.bundleCreationToken

هنگام استفاده از fetch.bundleURI برای واکشی افزایشی از یک فهرست باندل که از روش ابتکاری "creationToken" استفاده می‌کند، این مقدار پیکربندی حداکثر مقدار creationToken باندل‌های بارگیری‌شده را ذخیره می‌کند. این مقدار برای جلوگیری از بارگیری باندل‌ها در آینده در صورتی که creationToken اعلان‌شده اکیداً بزرگ‌تر از این مقدار نباشد استفاده می‌شود.

مقادیر توکن ایجاد توسط ارائه‌دهنده‌ای که bundle URI خاص را ارائه می‌دهد انتخاب می‌شوند. اگر URI را در fetch.bundleURI تغییر دادید، حتماً قبل از واکشی مقدار fetch.bundleCreationToken را حذف کنید.

استفاده از --ecurse-submodules تنها می‌تواند کامیت‌های جدید را در زیرماژول‌هایی واکشی کند که به صورت محلی مثلاً در $GIT_DIR/modules/ حضور دارند. اگر بالادست یک زیرماژول جدید اضافه کند، آن زیرماژول تا زمانی که کلون نشود (مثلاً توسط git submodule update) قابل واکشی نیست. انتظار می‌رود این مشکل در نسخه‌های آینده گیت برطرف شود.

git-pull(1)

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

2026-06-29 Git 2.55.0