'" t
."     Title: git-fetch
."    Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
." Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net>
."      Date: 2026-06-29
."    Manual: Git Manual
."    Source: Git 2.55.0
."  Language: English
."
.TH "GIT\-FETCH" "1" "2026\-06\-29" "Git 2\&.55\&.0" "Git Manual"
." -----------------------------------------------------------------
." * Define some portability stuff
." -----------------------------------------------------------------
." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
." http://bugs.debian.org/507673
." http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
." -----------------------------------------------------------------
." * set default formatting
." -----------------------------------------------------------------
." disable hyphenation
.nh
." disable justification (adjust text to left margin only)
.ad l
." -----------------------------------------------------------------
." * MAIN CONTENT STARTS HERE *
." -----------------------------------------------------------------
.SH "نام (NAME)"
git-fetch \- بارگیری اشیاء و ارجاعات از یک مخزن دیگر
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fBgit\fR \fBfetch\fR [\fI<options>\fR] [\fI<repository>\fR [\fI<refspec>\fR\&...]]
\fBgit\fR \fBfetch\fR [\fI<options>\fR] \fI<group>\fR
\fBgit\fR \fBfetch\fR \fB\-\-\multiple\fR [\fI<options>\fR] [(\fI<repository>\fR|\fI<group>\fR)\&...]
\fBgit\fR \fBfetch\fR \fB\-\-\all\fR [\fI<options>\fR]
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
شاخه‌ها و/یا تگ‌ها (که در مجموع "refs" یا ارجاعات نامیده می‌شوند) را از یک یا چند مخزن دیگر به همراه اشیاء لازم برای تکمیل تاریخچه آن‌ها واکشی (fetch) می‌کند\&. شاخه‌های ردیابی ریموت (remote-tracking branches) به‌روزرسانی می‌شوند (برای روش‌های کنترل این رفتار، توضیحات \fI<refspec>\fR را در زیر ببینید)\&.
.sp
به طور پیش‌فرض، هر تگی که به تاریخچه‌های در حال واکشی اشاره کند نیز واکشی می‌شود؛ نتیجه این است که تگ‌هایی که به شاخه‌های مورد نظر شما اشاره دارند دریافت می‌شوند\&. این رفتار پیش‌فرض را می‌توان با استفاده از گزینه‌های \fB\-\-\tags\fR یا \fB\-\-\no\-tags\fR یا با پیکربندی \fBremote\&.\fR\fI<name>\fR\fB\&.tagOpt\fR تغییر داد\&. با استفاده از refspec که تگ‌ها را صراحتاً واکشی می‌کند، می‌توانید تگ‌هایی را که به شاخه‌های مورد نظر شما اشاره نمی‌کنند نیز دریافت کنید\&.
.sp
دستور \fBgit\fR \fBfetch\fR می‌تواند از یک مخزن یا URL مشخص، یا از چندین مخزن به صورت همزمان (در صورتی که \fI<group>\fR مشخص شده باشد و مدخل \fBremotes\&.\fR\fI<group>\fR در فایل پیکربندی وجود داشته باشد) واکشی کند\&. (نگاه کنید به \fBgit-config\fR(1))\&.
.sp
هنگامی که هیچ ریموتی مشخص نشده باشد، به طور پیش‌فرض ریموت \fBorigin\fR استفاده خواهد شد، مگر اینکه یک شاخه بالادست برای شاخه فعلی پیکربندی شده باشد\&.
.sp
نام‌های ارجاعاتی که واکشی می‌شوند، همراه با نام اشیائی که به آن‌ها اشاره دارند، در \fB\&.git/FETCH_HEAD\fR نوشته می‌شوند\&. این اطلاعات ممکن است توسط اسکریپت‌ها یا سایر دستورات گیت، مانند \fBgit-pull\fR(1) استفاده شود\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
\fB\-\-\all\fR, \fB\-\-\no\-all\fR
.RS 4
واکشی تمام ریموت‌ها، به جز مواردی که متغیر پیکربندی
\fBremote\&.\fR\fI<name>\fR\fB\&.skipFetchAll\fR
برای آن‌ها تنظیم شده باشد\&. این گزینه متغیر پیکربندی
\fBfetch\&.all\fR
را نادیده می‌گیرد و بازنویسی می‌کند\&.
.RE
.PP
\fB\-a\fR, \fB\-\-\append\fR
.RS 4
الحاق نام‌های ارجاع و نام‌های شیء ارجاعات واکشی‌شده به محتویات موجود در
\fB\&.git/FETCH_HEAD\fR\&.
بدون این گزینه، داده‌های قدیمی در
\fB\&.git/FETCH_HEAD\fR
بازنویسی خواهند شد\&.
.RE
.PP
\fB\-\-\atomic\fR
.RS 4
استفاده از یک تراکنش اتمیک (atomic transaction) برای به‌روزرسانی ارجاعات محلی\&. یا تمام ارجاعات به‌روزرسانی می‌شوند، یا در صورت بروز خطا، هیچ ارجاعی به‌روزرسانی نمی‌شود\&.
.RE
.PP
\fB\-\-\depth=\fR\fI<depth>\fR
.RS 4
محدود کردن واکشی به تعداد مشخصی از کامیت‌ها از نوک تاریخچه هر شاخه ریموت\&. در صورت واکشی در یک مخزن
\fIکم‌عمق (shallow)\fR
که توسط
\fBgit\fR
\fBclone\fR
همراه با گزینه
\fB\-\-\depth=\fR\fI<depth>\fR
ایجاد شده است (نگاه کنید به
\fBgit-clone\fR(1))،
تاریخچه را تا تعداد کامیت‌های مشخص‌شده عمیق‌تر یا کوتاه‌تر می‌کند\&. تگ‌های مربوط به کامیت‌های عمیق‌ترشده واکشی نمی‌شوند\&.
.RE
.PP
\fB\-\-\deepen=\fR\fI<depth>\fR
.RS 4
مشابه
\fB\-\-\depth\fR،
با این تفاوت که تعداد کامیت‌ها را از مرز کم‌عمق فعلی به جای نوک تاریخچه هر شاخه ریموت مشخص می‌کند\&.
.RE
.PP
\fB\-\-\shallow\-since=\fR\fI<date>\fR
.RS 4
عمیق‌تر یا کوتاه‌تر کردن تاریخچه یک مخزن کم‌عمق به منظور گنجاندن تمام کامیت‌های در دسترس پس از
\fI<date>\fR\&.
.RE
.PP
\fB\-\-\shallow\-exclude=\fR\fI<ref>\fR
.RS 4
عمیق‌تر یا کوتاه‌تر کردن تاریخچه یک مخزن کم‌عمق برای مستثنی کردن کامیت‌های در دسترس از یک شاخه یا تگ ریموت مشخص‌شده\&. این گزینه را می‌توان چندین بار مشخص کرد\&.
.RE
.PP
\fB\-\-\unshallow\fR
.RS 4
اگر مخزن مبدأ کامل باشد، مخزن کم‌عمق را به یک مخزن کامل تبدیل می‌کند و تمام محدودیت‌های تحمیل‌شده توسط مخازن کم‌عمق را برمی‌دارد\&.
.sp
اگر مخزن مبدأ کم‌عمق باشد، تا حد امکان اطلاعات را واکشی می‌کند تا مخزن فعلی همان تاریخچه مخزن مبدأ را داشته باشد\&.
.RE
.PP
\fB\-\-\update\-shallow\fR
.RS 4
به طور پیش‌فرض هنگام واکشی از یک مخزن کم‌عمق،
\fBgit\fR
\fBfetch\fR
ارجاعاتی را که نیاز به به‌روزرسانی
\fB\&.git/shallow\fR
دارند رد می‌کند\&. این گزینه
\fB\&.git/shallow\fR
را به‌روزرسانی کرده و چنین ارجاعاتی را می‌پذیرد\&.
.RE
.PP
\fB\-\-\negotiation\-restrict=\fR(\fI<commit>\fR|\fI<glob>\fR), \fB\-\-\negotiation\-tip=\fR(\fI<commit>\fR|\fI<glob>\fR)
.RS 4
به طور پیش‌فرض، گیت کامیت‌های در دسترس از تمام ارجاعات محلی را به سرور گزارش می‌دهد تا کامیت‌های مشترک را برای کاهش اندازه packfile دریافتی پیدا کند\&. در صورت تعیین، گیت تنها کامیت‌های در دسترس از نوک‌های (tips) داده‌شده را گزارش خواهد داد\&. این امر برای افزایش سرعت واکشی‌ها زمانی که کاربر می‌داند کدام ارجاع محلی احتمالاً کامیت‌های مشترکی با ارجاع ریموت در حال واکشی دارد، مفید است\&.
.sp
گزینه
\fB\-\-\negotiation\-restrict\fR
نام ترجیحی برای این گزینه است؛
\fB\-\-\negotiation\-tip\fR
به عنوان نام مترادف پذیرفته می‌شود\&.
.sp
این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، گیت کامیت‌های در دسترس از هر یک از کامیت‌های داده‌شده را گزارش می‌دهد\&.
.sp
آرگومان این گزینه می‌تواند یک الگوی glob بر روی نام‌های ارجاع، یک ارجاع، یا شناسه SHA\-1 (احتمالاً مخفف‌شده) یک کامیت باشد\&. تعیین یک glob معادل تعیین این گزینه به تعداد چندین بار، یعنی به ازای هر نام ارجاع منطبق است\&.
.sp
همچنین متغیرهای پیکربندی
\fBfetch\&.negotiationAlgorithm\fR
و
\fBpush\&.negotiate\fR
مستندشده در
\fBgit-config\fR(1)
و گزینه
\fB\-\-\negotiate\-only\fR
در زیر را ببینید\&.
.RE
.PP
\fB\-\-\negotiation\-include=\fR(\fI<commit>\fR|\fI<glob>\fR)
.RS 4
اطمینان حاصل می‌کند که کامیت‌های موجود در نوک‌های داده‌شده همیشه به عنوان خطوط "have" در حین مذاکره واکشی ارسال می‌شوند، بدون در نظر گرفتن اینکه الگوریتم مذاکره چه چیزی را انتخاب می‌کند\&. این امر برای تضمین اینکه تاریخچه مشترک در دسترس از ارجاعات خاص همیشه در نظر گرفته شود، حتی زمانی که
\fB\-\-\negotiation\-restrict\fR
مجموعه نوک‌ها را محدود کرده یا الگوریتم مذاکره آن‌ها را نادیده می‌گیرد، مفید است\&.
.sp
این گزینه ممکن است بیش از یک بار مشخص شود؛ در این صورت، هر کامیت بدون قید و شرط ارسال می‌شود\&.
.sp
آرگومان می‌تواند یک نام دقیق ارجاع (مثلاً
\fBrefs/heads/release\fR)،
هش یک شیء، یا یک الگوی glob (مثلاً
\fBrefs/heads/release/\fR{asterisk})
باشد\&. نحو الگو همانند نحو
\fB\-\-\negotiation\-restrict\fR
است\&.
.sp
اگر
\fB\-\-\negotiation\-restrict\fR
استفاده شود، مجموعه have ابتدا توسط آن گزینه محدود شده و سپس برای گنجاندن نوک‌های مشخص‌شده توسط
\fB\-\-\negotiation\-include\fR
افزایش می‌یابد\&.
.sp
اگر این گزینه در خط فرمان مشخص نشده باشد، هرگونه مقدار پیکربندی
\fBremote\&.\fR\fI<name>\fR\fB\&.negotiationInclude\fR
برای ریموت فعلی در عوض استفاده می‌شود\&.
.RE
.PP
\fB\-\-\negotiate\-only\fR
.RS 4
هیچ چیزی از سرور واکشی نکنید، و در عوض اجداد آرگومان‌های ارائه‌شده برای
\fB\-\-\negotiation\-restrict=\fR
را که با سرور مشترک هستیم چاپ کنید\&.
.sp
این گزینه با
\fB\-\-\recurse\-submodules=\fR(\fByes\fR|\fBon\-demand\fR)
ناسازگار است\&. در بخش داخلی این گزینه برای پیاده‌سازی گزینه
\fBpush\&.negotiate\fR
استفاده می‌شود، نگاه کنید به
\fBgit-config\fR(1)\&.
.RE
.PP
\fB\-\-\dry\-run\fR
.RS 4
نمایش آنچه بدون اعمال هیچ تغییری انجام خواهد شد\&.
.RE
.PP
\fB\-\-\porcelain\fR
.RS 4
چاپ خروجی در خروجی استاندارد در قالبی که به راحتی برای اسکریپت‌ها قابل تجزیه باشد\&. برای جزئیات بخش خروجی (OUTPUT) را در
\fBgit-fetch\fR(1)
ببینید\&.
.sp
این گزینه با
\fB\-\-\recurse\-submodules=\fR(\fByes\fR|\fBon\-demand\fR)
ناسازگار است و بر گزینه پیکربندی
\fBfetch\&.output\fR
تقدم دارد\&.
.RE
.PP
\fB\-\-\filter=\fR\fI<filter\-spec>\fR
.RS 4
استفاده از ویژگی کلون جزئی (partial clone) و درخواست اینکه سرور زیرمجموعه‌ای از اشیاء در دسترس را بر اساس یک فیلتر شیء مشخص ارسال کند\&. هنگام استفاده از
\fB\-\-\filter\fR،
مقدار ارائه‌شده
\fI<filter\-spec>\fR
برای واکشی جزئی استفاده می‌شود\&.
.sp
اگر
\fB\-\-\filter=auto\fR
استفاده شود، مشخصات فیلتر به صورت خودکار با ترکیب مشخصات فیلتر اعلان‌شده توسط سرور برای ریموت‌های promisor که کلاینت می‌پذیرد تعیین می‌شود (نگاه کنید به
\fBgitprotocol-v2\fR(5)
و گزینه پیکربندی
\fBpromisor\&.acceptFromServer\fR
در
\fBgit-config\fR(1))\&.
.sp
برای جزئیات درباره تمام مشخصات فیلتر موجود دیگر، گزینه
\fB\-\-\filter=\fR\fI<filter\-spec>\fR
در
\fBgit-rev-list\fR(1)
را ببینید\&.
.sp
برای مثال،
\fB\-\-\filter=blob:none\fR
تمامی blobها (محتوای فایل‌ها) را تا زمانی که توسط گیت مورد نیاز باشند فیلتر می‌کند\&. همچنین،
\fB\-\-\filter=blob:limit=\fR\fI<size>\fR
تمام blobهای با اندازه حداقل
\fI<size>\fR
را فیلتر خواهد کرد\&.
.RE
.PP
\fB\-\-\write\-fetch\-head\fR, \fB\-\-\no\-write\-fetch\-head\fR
.RS 4
نوشتن فهرست ارجاعات ریموت واکشی‌شده در فایل
\fBFETCH_HEAD\fR
مستقیماً زیر
\fB$GIT_DIR\fR\&.
این رفتار پیش‌فرض است\&. ارسال
\fB\-\-\no\-write\-fetch\-head\fR
از خط فرمان به گیت می‌گوید که این فایل را ننویسد\&. تحت گزینه
\fB\-\-\dry\-run\fR،
این فایل هرگز نوشته نمی‌شود\&.
.RE
.PP
\fB\-f\fR, \fB\-\-\force\fR
.RS 4
هنگامی که
\fBgit\fR
\fBfetch\fR
همراه با refspec به صورت
\fI<src>\fR\fB:\fR\fI<dst>\fR
استفاده شود، ممکن است همان‌طور که در بخش
\fI<refspec>\fR
در زیر بحث شده است از به‌روزرسانی شاخه محلی خودداری کند\&. این گزینه آن بررسی را لغو می‌کند\&.
.RE
.PP
\fB\-k\fR, \fB\-\-\keep\fR
.RS 4
نگه‌داشتن بسته (pack) بارگیری‌شده\&.
.RE
.PP
\fB\-\-\multiple\fR
.RS 4
امکان تعیین چندین آرگومان
\fI<repository>\fR
و
\fI<group>\fR\&.
هیچ
\fI<refspec>\fR
نباید مشخص شود\&.
.RE
.PP
\fB\-\-\auto\-maintenance\fR, \fB\-\-\no\-auto\-maintenance\fR, \fB\-\-\auto\-gc\fR, \fB\-\-\no\-auto\-gc\fR
.RS 4
اجرای دستور
\fBgit\fR
\fBmaintenance\fR
\fBrun\fR
\fB\-\-\auto\fR
در پایان کار جهت انجام نگهداری خودکار مخزن در صورت نیاز\&. این گزینه به صورت پیش‌فرض فعال است\&.
.RE
.PP
\fB\-\-\write\-commit\-graph\fR, \fB\-\-\no\-write\-commit\-graph\fR
.RS 4
نوشتن یک commit\-graph پس از واکشی\&. این گزینه تنظیم پیکربندی
\fBfetch\&.writeCommitGraph\fR
را نادیده می‌گیرد و بازنویسی می‌کند\&.
.RE
.PP
\fB\-\-\prefetch\fR
.RS 4
تغییر refspec پیکربندی‌شده برای قرار دادن تمام ارجاعات در فضای نام
\fBrefs/prefetch/\fR\&.
تسک
\fBprefetch\fR
را در
\fBgit-maintenance\fR(1)
ببینید\&.
.RE
.PP
\fB\-p\fR, \fB\-\-\prune\fR
.RS 4
قبل از واکشی، هرگونه ارجاع ردیابی ریموت را که دیگر در ریموت وجود ندارد حذف کنید\&. تگ‌ها در صورتی که فقط به دلیل دنبال کردن خودکار پیش‌فرض تگ‌ها یا به دلیل گزینه
\fB\-\-\tags\fR
واکشی شده باشند، مشمول هرس (pruning) نمی‌شوند\&. با این حال، اگر تگ‌ها به دلیل یک refspec صریح واکشی شوند (چه در خط فرمان و چه در پیکربندی ریموت، برای مثال اگر ریموت با گزینه
\fB\-\-\mirror\fR
کلون شده باشد)، آن‌گاه مشمول هرس خواهند شد\&. تعیین گزینه
\fB\-\-\prune\-tags\fR
روشی کوتاه برای ارائه refspec تگ است\&.
.sp
برای جزئیات بیشتر بخش «هرس کردن شاخه‌ها» (PRUNING) را در زیر ببینید\&.
.RE
.PP
\fB\-P\fR, \fB\-\-\prune\-tags\fR
.RS 4
قبل از واکشی، در صورت فعال بودن
\fB\-\-\prune\fR،
هرگونه تگ محلی را که دیگر در ریموت وجود ندارد حذف کنید\&. این گزینه باید با احتیاط بیشتری استفاده شود، زیرا برخلاف
\fB\-\-\prune\fR
هرگونه ارجاع محلی (تگ محلی) ایجادشده را حذف خواهد کرد\&. این گزینه یک روش کوتاه برای ارائه refspec صریح تگ به همراه
\fB\-\-\prune\fR
است، بحث مربوط به آن را در مستنداتش ببینید\&.
.sp
برای جزئیات بیشتر بخش «هرس کردن شاخه‌ها» (PRUNING) را در زیر ببینید\&.
.RE
.PP
\fB\-n\fR, \fB\-\-\no\-tags\fR
.RS 4
به طور پیش‌فرض، تگ‌هایی که به اشیاء بارگیری‌شده از مخزن ریموت اشاره می‌کنند واکشی و به صورت محلی ذخیره می‌شوند\&. این گزینه این دنبال کردن خودکار تگ‌ها را غیرفعال می‌کند\&. رفتار پیش‌فرض برای یک ریموت را می‌توان با تنظیم
\fBremote\&.\fR\fI<name>\fR\fB\&.tagOpt\fR
مشخص کرد\&. نگاه کنید به
\fBgit-config\fR(1)\&.
.RE
.PP
\fB\-\-\refetch\fR
.RS 4
به جای مذاکره با سرور برای جلوگیری از انتقال کامیت‌ها و اشیاء مرتبط که قبلاً به صورت محلی وجود دارند، این گزینه تمام اشیاء را همان‌طور که یک کلون تازه انجام می‌دهد واکشی می‌کند\&. از این گزینه برای اعمال مجدد فیلتر کلون جزئی از پیکربندی یا با استفاده از
\fB\-\-\filter=\fR
هنگامی که تعریف فیلتر تغییر کرده است استفاده کنید\&. نگهداری خودکار پس از واکشی، یکپارچه‌سازی بسته‌های پایگاه داده اشیاء را برای حذف هرگونه شیء تکراری انجام خواهد داد\&.
.RE
.PP
\fB\-\-\refmap=\fR\fI<refspec>\fR
.RS 4
هنگام واکشی ارجاعات ذکرشده در خط فرمان، به جای مقادیر متغیرهای پیکربندی
\fBremote\&.\fR\fI<name>\fR\fB\&.fetch\fR
برای مخزن ریموت، از refspec مشخص‌شده (می‌تواند بیش از یک بار داده شود) برای نگاشت ارجاعات به شاخه‌های ردیابی ریموت استفاده کنید\&. ارائه یک
\fI<refspec>\fR
خالی به گزینه
\fB\-\-\refmap\fR
باعث می‌شود گیت refspecهای پیکربندی‌شده را نادیده بگیرد و کاملاً به refspecهای ارائه‌شده به عنوان آرگومان‌های خط فرمان اتکا کند\&. برای جزئیات بخش «شاخه‌های ردیابی ریموت پیکربندی‌شده» را ببینید\&.
.RE
.PP
\fB\-t\fR, \fB\-\-\tags\fR
.RS 4
واکشی تمام تگ‌ها از ریموت (یعنی واکشی تگ‌های ریموت
\fBrefs/tags/*\fR
در تگ‌های محلی با همان نام)، علاوه بر هر چیز دیگری که در غیر این صورت واکشی می‌شد\&. استفاده از این گزینه به تنهایی تگ‌ها را مشمول هرس نمی‌کند، حتی اگر
\fB\-\-\prune\fR
استفاده شود (اگرچه ممکن است تگ‌ها در صورتی که مقصد یک refspec صریح باشند به هر حال هرس شوند؛ گزینه
\fB\-\-\prune\fR
را ببینید)\&.
.RE
.PP
\fB\-\-\recurse\-submodules\fR[\fB=\fR(\fByes\fR|\fBon\-demand\fR|\fBno\fR)]
.RS 4
کنترل اینکه آیا و تحت چه شرایطی کامیت‌های جدید زیرماژول‌ها نیز باید واکشی شوند\&. هنگام پیمایش بازگشتی در زیرماژول‌ها،
\fBgit\fR
\fBfetch\fR
همیشه تلاش می‌کند زیرماژول‌های "تغییریافته" را واکشی کند، یعنی زیرماژولی که دارای کامیت‌هایی است که توسط یک کامیت ابرپروژه (superproject) تازه واکشی‌شده ارجاع داده شده‌اند اما در کلون محلی زیرماژول وجود ندارند\&. یک زیرماژول تغییریافته تا زمانی که به صورت محلی مثلاً در
\fB$GIT_DIR/modules/\fR
حضور داشته باشد می‌تواند واکشی شود (نگاه کنید به
\fBgitsubmodules\fR(7))؛
اگر بالادست یک زیرماژول جدید اضافه کند، آن زیرماژول تا زمانی که کلون نشود (مثلاً توسط
\fBgit\fR
\fBsubmodule\fR
\fBupdate\fR)
نمی‌تواند واکشی شود\&.
.sp
هنگامی که روی
\fBon\-demand\fR
تنظیم شود، فقط زیرماژول‌های تغییریافته واکشی می‌شوند\&. هنگامی که روی
\fByes\fR
تنظیم شود، تمام زیرماژول‌های پرشده واکشی می‌شوند و زیرماژول‌هایی که هم پرنشده و هم تغییریافته هستند نیز واکشی می‌گردند\&. هنگامی که روی
\fBno\fR
تنظیم شود، زیرماژول‌ها هرگز واکشی نمی‌شوند\&.
.sp
در صورت عدم تعیین، این گزینه از مقدار
\fBfetch\&.recurseSubmodules\fR
در صورت تنظیم بودن استفاده می‌کند (نگاه کنید به
\fBgit-config\fR(1))،
و در صورت عدم تنظیم پیش‌فرض آن
\fBon\-demand\fR
است\&. هنگامی که این گزینه بدون هیچ مقداری استفاده شود، پیش‌فرض آن
\fByes\fR
خواهد بود\&.
.RE
.PP
\fB\-j\fR \fI<n>\fR, \fB\-\-\jobs=\fR\fI<n>\fR
.RS 4
موازی‌سازی تمام اشکال واکشی تا سقف
\fI<n>\fR
شغل (job) در یک زمان\&.
.sp
مقدار 0 از یک پیش‌فرض منطقی استفاده خواهد کرد\&.
.sp
اگر گزینه
\fB\-\-\multiple\fR
مشخص شده باشد، ریموت‌های مختلف به صورت موازی واکشی خواهند شد\&. اگر چندین زیرماژول واکشی شوند، آن‌ها به صورت موازی واکشی می‌شوند\&. برای کنترل مستقل آن‌ها، از تنظیمات پیکربندی
\fBfetch\&.parallel\fR
و
\fBsubmodule\&.fetchJobs\fR
استفاده کنید (نگاه کنید به
\fBgit-config\fR(1))\&.
.sp
به طور معمول، واکشی‌های بازگشتی و چندریموتی موازی سریع‌تر خواهند بود\&. به طور پیش‌فرض، واکشی‌ها به صورت متوالی انجام می‌شوند، نه به صورت موازی\&.
.RE
.PP
\fB\-\-\no\-recurse\-submodules\fR
.RS 4
غیرفعال کردن واکشی بازگشتی زیرماژول‌ها (این همان اثر استفاده از گزینه
\fB\-\-\recurse\-submodules=no\fR
را دارد)\&.
.RE
.PP
\fB\-\-\set\-upstream\fR
.RS 4
اگر ریموت با موفقیت واکشی شد، ارجاع بالادست (ردیابی) را اضافه کنید که توسط
\fBgit-pull\fR(1)
بدون آرگومان و سایر دستورات استفاده می‌شود\&. برای اطلاعات بیشتر، گزینه‌های
\fBbranch\&.\fR\fI<name>\fR\fB\&.merge\fR
و
\fBbranch\&.\fR\fI<name>\fR\fB\&.remote\fR
در
\fBgit-config\fR(1)
را ببینید\&.
.RE
.PP
\fB\-\-\submodule\-prefix=\fR\fI<path>\fR
.RS 4
پیشوند دادن
\fI<path>\fR
به مسیرهای چاپ‌شده در پیام‌های آگاهی‌بخش مانند "Fetching submodule foo"\&. این گزینه به صورت داخلی هنگام پیمایش بازگشتی روی زیرماژول‌ها استفاده می‌شود\&.
.RE
.PP
\fB\-\-\recurse\-submodules\-default=\fR(\fByes\fR|\fBon\-demand\fR)
.RS 4
این گزینه به صورت داخلی برای ارائه موقت یک مقدار پیش‌فرض غیرمنفی برای گزینه
\fB\-\-\recurse\-submodules\fR
استفاده می‌شود\&. تمام روش‌های دیگر پیکربندی واکشی بازگشتی زیرماژول (مانند تنظیمات موجود در
\fBgitmodules\fR(5)
و
\fBgit-config\fR(1))
این گزینه را لغو می‌کنند، همان‌طور که تعیین صریح
\fB\-\-\fR[\fBno\-\fR]\fBrecurse\-submodules\fR
آن را بازنویسی می‌کند\&.
.RE
.PP
\fB\-u\fR, \fB\-\-\update\-head\-ok\fR
.RS 4
به طور پیش‌فرض
\fBgit\fR
\fBfetch\fR
از به‌روزرسانی head که متناظر با شاخه فعلی است خودداری می‌کند\&. این پرچم آن بررسی را غیرفعال می‌نماید\&. این صرفاً برای استفاده داخلی جهت ارتباط
\fBgit\fR
\fBpull\fR
با
\fBgit\fR
\fBfetch\fR
است، و مگر اینکه در حال پیاده‌سازی Porcelain خودتان باشید، قرار نیست از آن استفاده کنید\&.
.RE
.PP
\fB\-\-\upload\-pack\fR \fI<upload\-pack>\fR
.RS 4
هنگامی که داده شود، و مخزنی که باید از آن واکشی انجام شود توسط
\fBgit\fR
\fBfetch\-pack\fR
مدیریت شود، گزینه
\fB\-\-\exec=\fR\fI<upload\-pack>\fR
به دستور ارسال می‌شود تا مسیر غیرپیش‌فرضی را برای دستور اجراشده در سمت دیگر تعیین کند\&.
.RE
.PP
\fB\-q\fR, \fB\-\-\quiet\fR
.RS 4
ارسال
\fB\-\-\quiet\fR
به
\fBgit\-fetch\-pack\fR
و ساکت کردن سایر دستورات گیت استفاده‌شده در داخل\&. روند پیشرفت کار به جریان خطای استاندارد گزارش داده نمی‌شود\&.
.RE
.PP
\fB\-v\fR, \fB\-\-\verbose\fR
.RS 4
حالت پرگو (verbose)\&.
.RE
.PP
\fB\-\-\progress\fR
.RS 4
وضعیت پیشرفت به طور پیش‌فرض روی جریان خطای استاندارد گزارش می‌شود زمانی که به یک ترمینال متصل باشد، مگر اینکه
\fB\-q\fR
مشخص شده باشد\&. این پرچم وضعیت پیشرفت را حتی اگر جریان خطای استاندارد به ترمینال هدایت نشده باشد اجبار می‌کند\&.
.RE
.PP
\fB\-o\fR \fI<option>\fR, \fB\-\-\server\-option=\fR\fI<option>\fR
.RS 4
ارسال رشته داده‌شده به سرور در هنگام برقراری ارتباط با استفاده از نسخه پروتکل 2\&. رشته داده‌شده نباید حاوی کاراکتر
\fINUL\fR
یا
\fILF\fR
باشد\&. مدیریت گزینه‌های سرور توسط سرور، از جمله موارد ناشناخته، وابسته به سرور است\&. هنگامی که چندین
\fB\-\-\server\-option=\fR\fI<option>\fR
داده شود، همه آن‌ها به ترتیبی که در خط فرمان ذکر شده‌اند به طرف دیگر ارسال می‌شوند\&. هنگامی که هیچ
\fB\-\-\server\-option=\fR\fI<option>\fR
از خط فرمان داده نشود، مقادیر متغیر پیکربندی
\fBremote\&.\fR\fI<name>\fR\fB\&.serverOption\fR
در عوض استفاده می‌شوند\&.
.RE
.PP
\fB\-\-\show\-forced\-updates\fR
.RS 4
به طور پیش‌فرض، گیت بررسی می‌کند که آیا یک شاخه در حین واکشی به صورت اجباری به‌روزرسانی شده است یا خیر\&. این ویژگی را می‌توان از طریق
\fBfetch\&.showForcedUpdates\fR
غیرفعال کرد، اما گزینه
\fB\-\-\show\-forced\-updates\fR
تضمین می‌کند که این بررسی انجام پذیرد\&. نگاه کنید به
\fBgit-config\fR(1)\&.
.RE
.PP
\fB\-\-\no\-show\-forced\-updates\fR
.RS 4
به طور پیش‌فرض، گیت بررسی می‌کند که آیا یک شاخه در حین واکشی به صورت اجباری به‌روزرسانی شده است یا خیر\&. گزینه
\fB\-\-\no\-show\-forced\-updates\fR
را ارسال کنید یا
\fBfetch\&.showForcedUpdates\fR
را به false تنظیم نمایید تا به دلایل کارایی از این بررسی صرف‌نظر شود\&. در صورت استفاده در حین
\fBgit\-pull\fR،
گزینه
\fB\-\-\ff\-only\fR
همچنان قبل از اقدام به به‌روزرسانی سرراست (fast-forward)، به‌روزرسانی‌های اجباری را بررسی خواهد کرد\&. نگاه کنید به
\fBgit-config\fR(1)\&.
.RE
.PP
\fB\-4\fR, \fB\-\-\ipv4\fR
.RS 4
استفاده تنها از آدرس‌های IPv4، و نادیده گرفتن آدرس‌های IPv6\&.
.RE
.PP
\fB\-6\fR, \fB\-\-\ipv6\fR
.RS 4
استفاده تنها از آدرس‌های IPv6، و نادیده گرفتن آدرس‌های IPv4\&.
.RE
.PP
\fI<repository>\fR
.RS 4
مخزن "ریموت" که مبدأ عملیات واکشی یا pull است\&. این پارامتر می‌تواند یک URL (بخش
«آدرس‌های اینترنتی گیت»
در زیر را ببینید) یا نام یک ریموت (بخش
«مخازن ریموت»
در زیر را ببینید) باشد\&.
.RE
.PP
\fI<group>\fR
.RS 4
نامی که به فهرستی از مخازن به عنوان مقدار
\fBremotes\&.\fR\fI<group>\fR
در فایل پیکربندی اشاره دارد\&. (نگاه کنید به
\fBgit-config\fR(1))\&.
.RE
.PP
\fI<refspec>\fR
.RS 4
مشخص می‌کند کدام ارجاعات باید واکشی شوند و کدام ارجاعات محلی باید به‌روزرسانی گردند\&. هنگامی که هیچ
\fI<refspec>\fR
در خط فرمان ظاهر نشود، ارجاعات مورد نظر برای واکشی در عوض از متغیرهای
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
خوانده می‌شوند (بخش
«شاخه‌های ردیابی ریموت پیکربندی‌شده»
در زیر را ببینید)\&.
.sp
قالب پارامتر
\fI<refspec>\fR
شامل یک علامت مثبت اختیاری
\fB+\fR،
به دنبال آن مبدأ
\fI<src>\fR،
سپس دو نقطه
\fB:\fR،
و سپس مقصد
\fI<dst>\fR
است\&. هنگامی که
\fI<dst>\fR
خالی باشد می‌توان دو نقطه را حذف کرد\&.
\fI<src>\fR
به طور معمول یک ارجاع، یا یک الگوی glob با یک
\fB*\fR
واحد است که برای تطبیق با مجموعه‌ای از ارجاعات استفاده می‌شود، اما می‌تواند یک نام شیء هگزادسیمال کامل نیز باشد\&.
.sp
یک
\fI<refspec>\fR
ممکن است حاوی یک
\fB*\fR
در
\fI<src>\fR
خود باشد تا تطابق الگوی ساده را نشان دهد\&. چنین refspecی مانند یک glob عمل می‌کند که با هر ارجاع منطبق با الگو تطابق دارد\&. یک الگوی
\fI<refspec>\fR
باید یک و تنها یک
\fB*\fR
در هر دو بخش
\fI<src>\fR
و
\fI<dst>\fR
داشته باشد\&. این الگو ارجاعات را با جایگزینی
\fB*\fR
با محتوای منطبق‌شده از مبدأ به مقصد نگاشت می‌کند\&.
.sp
اگر یک refspec دارای پیشوند
\fB^\fR
باشد، به عنوان یک refspec منفی تفسیر خواهد شد\&. چنین refspecی به جای تعیین اینکه کدام ارجاعات واکشی شوند یا کدام ارجاعات محلی به‌روزرسانی گردند، در عوض ارجاعات مستثنی‌شده را مشخص می‌کند\&. یک ارجاع در صورتی منطبق در نظر گرفته می‌شود که حداقل با یک refspec مثبت تطابق داشته باشد و با هیچ refspec منفی تطابق نداشته باشد\&. refspecهای منفی می‌توانند برای محدود کردن دامنه یک الگوی refspec مفید باشند تا ارجاعات خاصی را شامل نشود\&. خود refspecهای منفی نیز می‌توانند الگوی refspec باشند\&. با این حال، آن‌ها تنها می‌توانند حاوی
\fI<src>\fR
باشند و مقصدی
\fI<dst>\fR
را مشخص نمی‌کنند\&. نام‌های شیء هگزادسیمال کامل نیز پشتیبانی نمی‌شوند\&.
.sp
عبارت
\fBtag\fR
\fI<tag>\fR
معادل
\fBrefs/tags/\fR\fI<tag>\fR\fB:refs/tags/\fR\fI<tag>\fR
است؛ این عبارت واکشی همه‌چیز را تا تگ داده‌شده درخواست می‌کند\&.
.sp
ارجاع ریموت منطبق با
\fI<src>\fR
واکشی می‌شود، و اگر
\fI<dst>\fR
یک رشته خالی نباشد، تلاش می‌شود تا ارجاع محلی منطبق با آن به‌روزرسانی شود\&.
.sp
اینکه آیا این به‌روزرسانی بدون
\fB\-\-\force\fR
مجاز است یا خیر، به فضای نام ارجاعی که به آن واکشی می‌شود، نوع شیء در حال واکشی و اینکه آیا به‌روزرسانی یک fast\-forward در نظر گرفته می‌شود بستگی دارد\&. به طور کلی، همان قوانینی که هنگام push اعمال می‌شوند برای fetch نیز اعمال می‌گردند؛ برای آگاهی از این قوانین بخش
\fI<refspec>\fR\&.\&.\&.
در
\fBgit-push\fR(1)
را ببینید\&. استثنائات خاص این قوانین برای
\fBgit\fR
\fBfetch\fR
در زیر ذکر شده است\&.
.sp
تا نسخه 2\&.20 گیت، و برخلاف زمان ارسال با
\fBgit-push\fR(1)،
هرگونه به‌روزرسانی برای
\fBrefs/tags/*\fR
بدون
\fB+\fR
در refspec (یا
\fB\-\-\force\fR)
پذیرفته می‌شد\&. هنگام واکشی، ما تمام به‌روزرسانی‌های تگ از یک ریموت را بدون تفکیک به عنوان واکشی‌های اجباری در نظر می‌گرفتیم\&. از نسخه 2\&.20 گیت، واکشی برای به‌روزرسانی
\fBrefs/tags/*\fR
همانند زمان push کار می‌کند\&. یعنی هرگونه به‌روزرسانی بدون
\fB+\fR
در refspec (یا
\fB\-\-\force\fR)
رد خواهد شد\&.
.sp
برخلاف زمان ارسال با
\fBgit-push\fR(1)،
هرگونه به‌روزرسانی خارج از
\fBrefs/\fR{tags,heads}/*
بدون
\fB+\fR
در refspec (یا
\fB\-\-\force\fR)
پذیرفته می‌شود، چه این تغییر جابجایی مثلاً یک شیء tree به جای blob باشد، یا یک کامیت برای کامیت دیگری که کامیت قبلی را به عنوان جد خود ندارد و غیره\&.
.sp
برخلاف زمان ارسال با
\fBgit-push\fR(1)،
هیچ پیکربندی وجود ندارد که این قوانین را اصلاح کند، و هیچ قلابی مانند
\fBpre\-fetch\fR
مشابه با قلاب
\fBpre\-receive\fR
وجود ندارد\&.
.sp
همانند ارسال با
\fBgit-push\fR(1)،
تمام قوانین توصیف‌شده در بالا درباره آنچه به عنوان به‌روزرسانی مجاز نیست، می‌توانند با افزودن یک علامت
\fB+\fR
اختیاری در ابتدای یک refspec (یا استفاده از گزینه خط فرمان
\fB\-\-\force\fR)
نادیده گرفته و بازنویسی شوند\&. تنها استثنا در این مورد این است که هیچ مقداری از اجبار باعث نمی‌شود فضای نام
\fBrefs/heads/*\fR
یک شیء غیرکامیت را بپذیرد\&.
.if n {\
.sp
.\}
.RS 4
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBنکته\fR
.ps -1
.br
هنگامی که مشخص است شاخه ریموتی که می‌خواهید واکشی کنید به طور مرتب به عقب برگردانده شده و rebase می‌شود، انتظار می‌رود که نوک جدید آن از نوک قبلی خود (همان‌طور که در آخرین واکشی در شاخه ردیابی ریموت شما ذخیره شده است) منشعب نشده باشد\&. در چنین شرایطی مایل خواهید بود از علامت
\fB+\fR
استفاده کنید تا نشان دهید برای چنین شاخه‌هایی به‌روزرسانی‌های غیر fast\-forward مورد نیاز خواهد بود\&. هیچ راهی برای تشخیص یا اعلام اینکه شاخه‌ای با این رفتار در مخزن در دسترس قرار خواهد گرفت وجود ندارد؛ کاربر واکشی‌کننده صرفاً باید بداند که این الگوی استفاده مورد انتظار برای شاخه است\&.
.sp .5v
.RE
.RE
.PP
\fB\-\-\stdin\fR
.RS 4
خواندن refspecها، هر خط یکی، از stdin علاوه بر مواردی که به عنوان آرگومان ارائه شده‌اند\&. قالب "tag
\fI<name>\fR"
پشتیبانی نمی‌شود\&.
.RE
.SH "آدرس‌های اینترنتی گیت (GIT URLS)"
.sp
به طور کلی، URLها حاوی اطلاعاتی درباره پروتکل انتقال، آدرس سرور ریموت و مسیر مخزن هستند\&. بسته به پروتکل انتقال، ممکن است برخی از این اطلاعات وجود نداشته باشند\&.
.sp
گیت از پروتکل‌های ssh، git، http و https پشتیبانی می‌کند (علاوه بر این، ftp و ftps می‌توانند برای واکشی استفاده شوند، اما این روش ناکارآمد و منسوخ است؛ از آن‌ها استفاده نکنید)\&.
.sp
انتقال بومی (یعنی URL با \fBgit://\fR) هیچ احراز هویتی انجام نمی‌دهد و باید در شبکه‌های ناامن با احتیاط استفاده شود\&.
.sp
نحو‌های زیر ممکن است با آن‌ها استفاده شوند:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBssh://\fR[\fI<user>\fR\fB@\fR]\fI<host>\fR[\fB:\fR\fI<port>\fR]\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBgit://\fR\fI<host>\fR[\fB:\fR\fI<port>\fR]\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBhttp\fR[\fBs\fR]\fB://\fR\fI<host>\fR[\fB:\fR\fI<port>\fR]\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBftp\fR[\fBs\fR]\fB://\fR\fI<host>\fR[\fB:\fR\fI<port>\fR]\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
همچنین می‌توان از یک نحو جایگزین شبیه به scp با پروتکل ssh استفاده کرد:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
[\fI<user>\fR\fB@\fR]\fI<host>\fR\fB:/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
این نحو تنها زمانی شناسایی می‌شود که هیچ اسلشی قبل از اولین دونقطه وجود نداشته باشد\&. این به تمایز یک مسیر محلی که حاوی دونقطه است کمک می‌کند\&. برای مثال، مسیر محلی \fBfoo:bar\fR می‌تواند به عنوان یک مسیر مطلق یا \fB\&./foo:bar\fR مشخص شود تا از تفسیر اشتباه آن به عنوان یک URL مبتنی بر ssh جلوگیری گردد\&.
.sp
پروتکل‌های ssh و git علاوه بر این از بسط \fB~\fR\fI<username>\fR پشتیبانی می‌کنند:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBssh://\fR[\fI<user>\fR\fB@\fR]\fI<host>\fR[\fB:\fR\fI<port>\fR]\fB/~\fR\fI<user>\fR\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBgit://\fR\fI<host>\fR[\fB:\fR\fI<port>\fR]\fB/~\fR\fI<user>\fR\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
[\fI<user>\fR\fB@\fR]\fI<host>\fR\fB:~\fR\fI<user>\fR\fB/\fR\fI<path\-to\-git\-repo>\fR
.RE
.sp
برای مخازن محلی که به صورت بومی نیز توسط گیت پشتیبانی می‌شوند، می‌توان از نحوهای زیر استفاده کرد:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fB/path/to/repo\&.git/\fR
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fBfile:///path/to/repo\&.git/\fR
.RE
.sp
این دو نحو عمدتاً معادل هستند، به جز زمان کلون کردن، که در آن نحو اول گزینه \fB\-\-\local\fR را به همراه دارد\&. برای جزئیات \fBgit-clone\fR(1) را ببینید\&.
.sp
دستورات \fBgit\fR \fBclone\fR، \fBgit\fR \fBfetch\fR و \fBgit\fR \fBpull\fR، اما نه \fBgit\fR \fBpush\fR، یک فایل باندل (bundle) مناسب را نیز می‌پذیرند\&. نگاه کنید به \fBgit-bundle\fR(1)\&.
.sp
هنگامی که گیت نحوه کار با یک پروتکل انتقال خاص را نمی‌داند، تلاش می‌کند از دستیار ریموت \fBremote\-\fR\fI<transport>\fR در صورت وجود استفاده کند\&. برای درخواست صریح یک دستیار ریموت، می‌توان از نحو زیر استفاده کرد:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
\fI<transport>\fR\fB::\fR\fI<address>\fR
.RE
.sp
که در آن \fI<address>\fR ممکن است یک مسیر، یک سرور و مسیر، یا یک رشته دلخواه شبیه به URL باشد که توسط دستیار ریموت فراخوانی‌شده شناسایی می‌شود\&. برای جزئیات \fBgitremote-helpers\fR(7) را ببینید\&.
.sp
اگر تعداد زیادی مخزن ریموت با نام‌های مشابه وجود دارد و می‌خواهید از قالب متفاوتی برای آن‌ها استفاده کنید (به طوری که URLهایی که استفاده می‌کنید به URLهای فعال بازنویسی شوند)، می‌توانید یک بخش پیکربندی به شکل زیر ایجاد کنید:
.sp
.if n {\
.RS 4
.\}
.nf
        [url "\fI<actual\-url\-base>\fR"]
                insteadOf = \fI<other\-url\-base>\fR
.fi
.if n {\
.RE
.\}
.sp
.sp
به عنوان مثال با این تنظیمات:
.sp
.if n {\
.RS 4
.\}
.nf
        [url "git://git\&.host\&.xz/"]
                insteadOf = host\&.xz:/path/to/
                insteadOf = work:
.fi
.if n {\
.RE
.\}
.sp
.sp
یک URL مانند "work:repo\&.git" یا مانند "host\&.xz:/path/to/repo\&.git" در هر زمینه‌ای که یک URL دریافت می‌کند، به "git://git\&.host\&.xz/repo\&.git" بازنویسی خواهد شد\&.
.sp
اگر می‌خواهید URLها را فقط برای push بازنویسی کنید، می‌توانید بخش پیکربندی را به شکل زیر ایجاد کنید:
.sp
.if n {\
.RS 4
.\}
.nf
        [url "\fI<actual\-url\-base>\fR"]
                pushInsteadOf = \fI<other\-url\-base>\fR
.fi
.if n {\
.RE
.\}
.sp
.sp
به عنوان مثال با این تنظیم:
.sp
.if n {\
.RS 4
.\}
.nf
        [url "ssh://example\&.org/"]
                pushInsteadOf = git://example\&.org/
.fi
.if n {\
.RE
.\}
.sp
.sp
یک URL مانند "git://example\&.org/path/to/repo\&.git" برای عملیات‌های push به "ssh://example\&.org/path/to/repo\&.git" بازنویسی خواهد شد، اما عملیات‌های pull همچنان از URL اصلی استفاده خواهند کرد\&.
.SH "مخازن ریموت (REMOTES)"
.sp
می‌توان از نام یکی از موارد زیر به عنوان آرگومان \fI<repository>\fR به جای یک URL استفاده کرد:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
یک ریموت در فایل پیکربندی گیت:
\fB$GIT_DIR/config\fR،
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
یک فایل در دایرکتوری
\fB$GIT_DIR/remotes\fR،
یا
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
یک فایل در دایرکتوری
\fB$GIT_DIR/branches\fR\&.
.RE
.sp
تمامی این موارد همچنین به شما امکان می‌دهند refspec را از خط فرمان حذف کنید زیرا هر کدام شامل یک refspec هستند که گیت به طور پیش‌فرض از آن استفاده خواهد کرد\&.
.SS "ریموت نام‌گذاری‌شده در فایل پیکربندی (Named remote in configuration file)"
.sp
می‌توانید نام ریموتی را ارائه دهید که قبلاً با استفاده از \fBgit-remote\fR(1)، \fBgit-config\fR(1) یا حتی با ویرایش دستی فایل \fB$GIT_DIR/config\fR پیکربندی کرده‌اید\&. از URL این ریموت برای دسترسی به مخزن استفاده خواهد شد\&. هنگامی که یک refspec در خط فرمان ارائه نمی‌کنید، refspec این ریموت به طور پیش‌فرض استفاده می‌شود\&. مدخل در فایل پیکربندی به این صورت خواهد بود:
.sp
.if n {\
.RS 4
.\}
.nf
        [remote "<name>"]
                url = <URL>
                pushurl = <pushurl>
                push = <refspec>
                fetch = <refspec>
.fi
.if n {\
.RE
.\}
.sp
.sp
آرگومان \fI<pushurl>\fR تنها برای عملیات‌های push استفاده می‌شود\&. اختیاری است و پیش‌فرض آن \fI<URL>\fR است\&. ارسال (push) به یک ریموت بر تمام pushurlهای تعریف‌شده یا تمام urlهای تعریف‌شده در صورت عدم وجود pushurl تأثیر می‌گذارد\&. با این حال، دستور fetch در صورت تعریف چندین url، تنها از اولین url تعریف‌شده واکشی خواهد کرد\&.
.SS "فایل نام‌گذاری‌شده در \fB$GIT_DIR/remotes\fR"
.sp
می‌توانید نام فایلی را در \fB$GIT_DIR/remotes\fR مشخص کنید\&. از URL موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد\&. refspec موجود در این فایل هنگامی که در خط فرمان refspec ارائه نکنید به عنوان پیش‌فرض استفاده می‌شود\&. این فایل باید قالب زیر را داشته باشد:
.sp
.if n {\
.RS 4
.\}
.nf
        URL: یکی از قالب‌های URL بالا
        Push: <refspec>
        Pull: <refspec>
.fi
.if n {\
.RE
.\}
.sp
.sp
خطوط \fBPush:\fR توسط \fBgit\fR \fBpush\fR استفاده می‌شوند و خطوط \fBPull:\fR توسط \fBgit\fR \fBpull\fR و \fBgit\fR \fBfetch\fR به کار می‌روند\&. ممکن است چندین خط \fBPush:\fR و \fBPull:\fR برای نگاشت‌های شاخه اضافی مشخص شوند\&.
.SS "فایل نام‌گذاری‌شده در \fB$GIT_DIR/branches\fR"
.sp
می‌توانید نام فایلی را در \fB$GIT_DIR/branches\fR مشخص کنید\&. از URL موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد\&. این فایل باید قالب زیر را داشته باشد:
.sp
.if n {\
.RS 4
.\}
.nf
        <URL>#<head>
.fi
.if n {\
.RE
.\}
.sp
.sp
آرگومان \fI<URL>\fR الزامی است؛ #\fI<head>\fR اختیاری است\&.
.sp
بسته به نوع عملیات، اگر refspec را در خط فرمان ارائه نکنید، گیت از یکی از refspecهای زیر استفاده خواهد کرد\&. \fI<branch>\fR نام این فایل در \fB$GIT_DIR/branches\fR است و پیش‌فرض \fI<head>\fR برابر با \fBmaster\fR می‌باشد\&.
.sp
دستور git fetch استفاده می‌کند از:
.sp
.if n {\
.RS 4
.\}
.nf
        refs/heads/<head>:refs/heads/<branch>
.fi
.if n {\
.RE
.\}
.sp
.sp
دستور git push استفاده می‌کند از:
.sp
.if n {\
.RS 4
.\}
.nf
        HEAD:refs/heads/<head>
.fi
.if n {\
.RE
.\}
.sp
.SH "شاخه‌های بالادست (UPSTREAM BRANCHES)"
.sp
شاخه‌ها در گیت می‌توانند به صورت اختیاری دارای یک شاخه ریموت بالادست (upstream) باشند\&. گیت به طور پیش‌فرض از شاخه بالادست برای عملیات‌های ریموت استفاده می‌کند، به عنوان مثال:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
این شاخه پیش‌فرض برای
\fBgit\fR
\fBpull\fR
یا
\fBgit\fR
\fBfetch\fR
بدون آرگومان است\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
این شاخه پیش‌فرض برای
\fBgit\fR
\fBpush\fR
بدون آرگومان است، با برخی استثناها\&. برای مثال، می‌توانید از گزینه
\fBbranch\&.\fR\fI<name>\fR\fB\&.pushRemote\fR
برای push کردن به ریموتی متفاوت از ریموتی که از آن pull می‌کنید استفاده نمایید، و به طور پیش‌فرض با
\fBpush\&.default=simple\fR
شاخه بالادستی که پیکربندی می‌کنید باید همان نام را داشته باشد\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
دستورات مختلف، از جمله
\fBgit\fR
\fBcheckout\fR
و
\fBgit\fR
\fBstatus\fR،
به شما نشان می‌دهند که چه تعداد کامیت از زمان انشعاب به شاخه فعلی و بالادست شما اضافه شده است، برای مثال "Your branch and
\fIorigin/main\fR
have diverged, and have 2 and 3 different commits each respectively"\&.
.RE
.sp
شاخه بالادست در \fB\&.git/config\fR، در فیلدهای "\fBremote\fR" و "\fBmerge\fR" ذخیره می‌شود\&. به عنوان مثال، اگر شاخه بالادست \fBmain\fR برابر با \fBorigin/main\fR باشد:
.sp
.if n {\
.RS 4
.\}
.nf
[branch "main"]
   remote = origin
   merge = refs/heads/main
.fi
.if n {\
.RE
.\}
.sp
.sp
می‌توانید با دستور \fBgit\fR \fBpush\fR \fB\-\-\set\-upstream\fR \fI<remote>\fR \fI<branch>\fR یک شاخه بالادست را صراحتاً تنظیم کنید، اما گیت معمولاً بالادست را به طور خودکار برای شما تنظیم می‌کند، برای مثال:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
هنگامی که یک مخزن را کلون می‌کنید، گیت به طور خودکار شاخه بالادست را برای شاخه پیش‌فرض تنظیم می‌کند\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
اگر گزینه پیکربندی
\fBpush\&.autoSetupRemote\fR
را تنظیم کرده باشید،
\fBgit\fR
\fBpush\fR
در اولین باری که شاخه‌ای را push می‌کنید، بالادست را به طور خودکار تنظیم خواهد کرد\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
چک‌اوت کردن یک شاخه ردیابی ریموت با
\fBgit\fR
\fBcheckout\fR
\fI<branch>\fR
به طور خودکار یک شاخه محلی با آن نام ایجاد کرده و بالادست را به شاخه ریموت تنظیم می‌کند\&.
.RE
.if n {\
.sp
.\}
.RS 4
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBنکته\fR
.ps -1
.br
.sp
گاهی از شاخه‌های بالادست به عنوان "اطلاعات ردیابی" (tracking information) یاد می‌شود، مانند "set the branch\(cqs tracking information"\&.
.sp .5v
.RE
.SH "شاخه‌های ردیابی ریموت پیکربندی‌شده (CONFIGURED REMOTE\-TRACKING BRANCHES)"
.sp
شما اغلب با یک مخزن ریموت یکسان از طریق واکشی منظم و مکرر تعامل دارید\&. به منظور پیگیری روند پیشرفت چنین مخزن ریموتی، \fBgit\fR \fBfetch\fR به شما امکان می‌دهد متغیرهای پیکربندی \fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR را تنظیم کنید\&.
.sp
به طور معمول چنین متغیری ممکن است به شکل زیر باشد:
.sp
.if n {\
.RS 4
.\}
.nf
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
.fi
.if n {\
.RE
.\}
.sp
.sp
این پیکربندی به دو روش استفاده می‌شود:
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
هنگامی که
\fBgit\fR
\fBfetch\fR
بدون مشخص کردن شاخه‌ها و/یا تگ‌ها برای واکشی در خط فرمان اجرا می‌شود (مانند
\fBgit\fR
\fBfetch\fR
\fBorigin\fR
یا
\fBgit\fR
\fBfetch\fR)،
مقادیر
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
به عنوان refspecها استفاده می‌شوند \(em آن‌ها مشخص می‌کنند کدام ارجاعات باید واکشی شوند و کدام ارجاعات محلی باید به‌روزرسانی گردند\&. مثال بالا تمام شاخه‌های موجود در
\fBorigin\fR
(یعنی هر ارجاعی که با سمت چپ مقدار، یعنی
\fBrefs/heads/*\fR
تطابق دارد) را واکشی کرده و شاخه‌های ردیابی ریموت مربوطه را در سلسله‌مراتب
\fBrefs/remotes/origin/*\fR
به‌روزرسانی می‌کند\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
هنگامی که
\fBgit\fR
\fBfetch\fR
با شاخه‌ها و/یا تگ‌های صریح برای واکشی در خط فرمان اجرا می‌شود (مانند
\fBgit\fR
\fBfetch\fR
\fBorigin\fR
\fBmaster\fR)،
مقادیر
\fI<refspec>\fRs
داده‌شده در خط فرمان تعیین می‌کنند چه مواردی باید واکشی شوند (مثلاً
\fBmaster\fR
در مثال، که یک خلاصه برای
\fBmaster:\fR
است، که به نوبه خود به این معنی است که "شاخه
\fBmaster\fR
را واکشی کن اما من صراحتاً نمی‌گویم کدام شاخه ردیابی ریموت با آن به‌روزرسانی شود")، و دستور مثال
\fIتنها\fR
شاخه
\fBmaster\fR
را واکشی خواهد کرد\&. مقادیر
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
تعیین می‌کنند کدام شاخه ردیابی ریموت (در صورت وجود) به‌روزرسانی شود\&. هنگامی که به این شیوه استفاده شود، مقادیر
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
هیچ اثری در تصمیم‌گیری درباره اینکه
\fIچه چیزی\fR
واکشی شود ندارند (یعنی زمانی که خط فرمان refspecها را فهرست می‌کند، این مقادیر به عنوان refspec استفاده نمی‌شوند)؛ آن‌ها تنها با ایفای نقش یک نگاشت، برای تعیین اینکه ارجاعات واکشی‌شده در
\fIکجا\fR
ذخیره شوند استفاده می‌شوند\&.
.RE
.sp
استفاده اخیر از مقادیر \fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR می‌تواند با ارائه پارامتر(های) \fB\-\-\refmap=\fR\fI<refspec>\fR در خط فرمان لغو و بازنویسی شود\&.
.SH "هرس کردن شاخه‌ها (PRUNING)"
.sp
گیت دارای یک رفتار پیش‌فرض برای حفظ داده‌ها است مگر اینکه صراحتاً دور ریخته شوند؛ این امر به نگه‌داشتن ارجاعات محلی به شاخه‌هایی در ریموت‌ها که خودشان آن شاخه‌ها را حذف کرده‌اند نیز تسری می‌یابد\&.
.sp
در صورت رها شدن و انباشته شدن، این ارجاعات کهنه ممکن است عملکرد را در مخازن بزرگ و پرکار با جابجایی زیاد شاخه‌ها تضعیف کنند، و به عنوان مثال خروجی دستوراتی مانند \fBgit\fR \fBbranch\fR \fB\-a\fR \fB\-\-\contains\fR \fI<commit>\fR را بی‌جهت طولانی کنند، و همچنین بر هر چیز دیگری که با مجموعه کامل ارجاعات شناخته‌شده کار می‌کند تأثیر بگذارند\&.
.sp
این ارجاعات ردیابی ریموت را می‌توان به صورت یک‌باره با یکی از دستورات زیر حذف کرد:
.sp
.if n {\
.RS 4
.\}
.nf
# در حین واکشی
$ git fetch \-\-\prune <name>

# فقط هرس کن، واکشی انجام نده
$ git remote prune <name>
.fi
.if n {\
.RE
.\}
.sp
.sp
برای هرس ارجاعات به عنوان بخشی از گردش کار عادی خود بدون نیاز به یادآوری اجرای آن، \fBfetch\&.prune\fR را به صورت سراسری، یا \fBremote\&.\fR\fI<name>\fR\fB\&.prune\fR را برای هر ریموت در پیکربندی تنظیم کنید\&. نگاه کنید به \fBgit-config\fR(1)\&.
.sp
اینجا جایی است که موضوع پیچیده‌تر و خاص‌تر می‌شود\&. ویژگی هرس در واقع به شاخه‌ها اهمیتی نمی‌دهد، بلکه ارجاعات محلی \(<\-\-\>\) ریموت را به عنوان تابعی از refspec ریموت هرس می‌کند (بخش‌های \fI<refspec>\fR و «شاخه‌های ردیابی ریموت پیکربندی‌شده» در بالا را ببینید)\&.
.sp
بنابراین اگر refspec برای ریموت شامل مثلاً \fBrefs/tags/*:refs/tags/*\fR باشد، یا شما به صورت دستی دستوری مانند \fBgit\fR \fBfetch\fR \fB\-\-\prune\fR \fI<name>\fR "refs/tags/*:refs/tags/*" را اجرا کنید، این شاخه‌های ردیابی ریموت کهنه نیستند که حذف می‌شوند، بلکه هر تگ محلی که در ریموت وجود ندارد حذف خواهد شد\&.
.sp
این ممکن است آن چیزی نباشد که انتظار دارید؛ یعنی می‌خواهید ریموت \fI<name>\fR را هرس کنید، اما همچنین صراحتاً تگ‌ها را از آن واکشی نمایید، بنابراین هنگام واکشی از آن تمام تگ‌های محلی خود را حذف می‌کنید، که بیشتر آن‌ها ممکن است در وهله اول از ریموت \fI<name>\fR نیامده باشند\&.
.sp
بنابراین هنگام استفاده از این ویژگی با یک refspec مانند \fBrefs/tags/*:refs/tags/*\fR، یا هر refspec دیگری که ممکن است ارجاعات از چندین ریموت را به یک فضای نام محلی یکسان نگاشت کند، بسیار مراقب باشید\&.
.sp
از آنجا که به‌روز نگه داشتن شاخه‌ها و تگ‌ها در ریموت یک مورد کاربرد رایج است، گزینه \fB\-\-\prune\-tags\fR را می‌توان همراه با \fB\-\-\prune\fR برای هرس تگ‌های محلی که در ریموت وجود ندارند، و به‌روزرسانی اجباری تگ‌هایی که متفاوت هستند ارائه کرد\&. هرس تگ‌ها را می‌توان با \fBfetch\&.pruneTags\fR یا \fBremote\&.\fR\fI<name>\fR\fB\&.pruneTags\fR در پیکربندی نیز فعال کرد\&. نگاه کنید به \fBgit-config\fR(1)\&.
.sp
گزینه \fB\-\-\prune\-tags\fR معادل اعلام \fBrefs/tags/*:refs/tags/*\fR در refspecهای ریموت است\&. این می‌تواند منجر به برخی رفتارهای به ظاهر عجیب شود:
.sp
.if n {\
.RS 4
.\}
.nf
# هر دوی این دستورات تگ‌ها را واکشی می‌کنند
$ git fetch \-\-\no\-tags origin \*(Aqrefs/tags/*:refs/tags/*\*(Aq
$ git fetch \-\-\no\-tags \-\-\prune\-tags origin
.fi
.if n {\
.RE
.\}
.sp
.sp
دلیل اینکه هنگام ارائه بدون \fB\-\-\prune\fR یا نسخه‌های پیکربندی آن خطا نمی‌دهد، انعطاف‌پذیری نسخه‌های پیکربندی‌شده و حفظ نگاشت ۱ به ۱ بین عملکرد پرچم‌های خط فرمان و گزینه‌های پیکربندی است\&.
.sp
بسیار منطقی است که برای مثال \fBfetch\&.pruneTags=true\fR در \fB~\&/.gitconfig\fR پیکربندی شود تا هر زمان که \fBgit\fR \fBfetch\fR \fB\-\-\prune\fR اجرا می‌شود تگ‌ها هرس شوند، بدون اینکه هر بار فراخوانی \fBgit\fR \fBfetch\fR بدون \fB\-\-\prune\fR به یک خطا تبدیل شود\&.
.sp
هرس کردن تگ‌ها با \fB\-\-\prune\-tags\fR هنگام واکشی یک URL به جای یک ریموت نام‌گذاری‌شده نیز کار می‌کند\&. تمام موارد زیر تگ‌هایی را که در origin یافت نمی‌شوند هرس می‌کنند:
.sp
.if n {\
.RS 4
.\}
.nf
$ git fetch origin \-\-\prune \-\-\prune\-tags
$ git fetch origin \-\-\prune \*(Aqrefs/tags/*:refs/tags/*\*(Aq
$ git fetch <url\-of\-origin> \-\-\prune \-\-\prune\-tags
$ git fetch <url\-of\-origin> \-\-\prune \*(Aqrefs/tags/*:refs/tags/*\*(Aq
.fi
.if n {\
.RE
.\}
.sp
.SH "خروجی (OUTPUT)"
.sp
خروجی "git fetch" بستگی به روش انتقال مورد استفاده دارد؛ این بخش خروجی را هنگام واکشی بر روی پروتکل گیت (چه به صورت محلی یا از طریق ssh) و پروتکل هوشمند Smart HTTP شرح می‌دهد\&.
.sp
وضعیت واکشی در قالب جدول خروجی داده می‌شود، که در آن هر خط نشان‌دهنده وضعیت یک ارجاع واحد است\&. هر خط به این شکل است:
.sp
.if n {\
.RS 4
.\}
.nf
 <flag> <summary> <from> \-> <to> [<reason>]
.fi
.if n {\
.RE
.\}
.sp
.sp
هنگام استفاده از \fB\-\-\porcelain\fR، قالب خروجی طوری طراحی شده است که به راحتی برای ماشین‌ها قابل تجزیه باشد\&. در مقایسه با قالب‌های خروجی خوانا برای انسان، این قالب به جای خطای استاندارد در خروجی استاندارد چاپ می‌شود\&. هر خط به شکل زیر است:
.sp
.if n {\
.RS 4
.\}
.nf
<flag> <old\-object\-id> <new\-object\-id> <local\-reference>
.fi
.if n {\
.RE
.\}
.sp
.sp
وضعیت ارجاعات به‌روز (up-to-date) تنها در صورتی نشان داده می‌شود که گزینه \fB\-\-\verbose\fR استفاده شده باشد\&.
.sp
در حالت خروجی فشرده (compact)، که با متغیر پیکربندی fetch\&.output مشخص می‌شود، اگر تمام رشته \fI<from>\fR یا \fI<to>\fR در رشته دیگر یافت شود، در رشته دیگر با \fB*\fR جایگزین خواهد شد\&. به عنوان مثال، \fBmaster\fR \fB\-\fR> \fBorigin/master\fR تبدیل می‌شود به \fBmaster\fR \fB\-\fR> \fBorigin/*\fR\&.
.PP
flag
.RS 4
یک نویسه تک که وضعیت ارجاع را نشان می‌دهد:
.PP
(space)
.RS 4
برای یک fast\-forward با موفقیت واکشی‌شده؛
.RE
.PP
\fB+\fR
.RS 4
برای یک به‌روزرسانی اجباری موفق؛
.RE
.PP
\fB\-\fR
.RS 4
برای یک ارجاع با موفقیت هرس‌شده؛
.RE
.PP
\fBt\fR
.RS 4
برای یک به‌روزرسانی موفق تگ؛
.RE
.PP
\fB*\fR
.RS 4
برای یک ارجاع جدید با موفقیت واکشی‌شده؛
.RE
.PP
!
.RS 4
برای ارجاعی که رد شد یا به‌روزرسانی آن شکست خورد؛ و
.RE
.PP
\fB=\fR
.RS 4
برای ارجاعی که به‌روز بود و نیازی به واکشی نداشت\&.
.RE
.RE
.PP
summary
.RS 4
برای یک ارجاع با موفقیت واکشی‌شده، خلاصه مقادیر قدیمی و جدید ارجاع را در قالبی مناسب برای استفاده به عنوان آرگومان در
\fBgit\fR
\fBlog\fR
نشان می‌دهد (این در بیشتر موارد به صورت
\fI<old>\fR\fB\&.\&.\fR\fI<new>\fR
و برای به‌روزرسانی‌های اجباری غیر fast\-forward به صورت
\fI<old>\fR\fB\&.\&.\&.\fR\fI<new>\fR
است)\&.
.RE
.PP
from
.RS 4
نام ارجاع ریموت که از آن واکشی می‌شود، منهای پیشوند
\fBrefs/\fR\fI<type>\fR\fB/\fR
آن\&. در صورت حذف، نام ارجاع ریموت "(none)" است\&.
.RE
.PP
to
.RS 4
نام ارجاع محلی که در حال به‌روزرسانی است، منهای پیشوند
\fBrefs/\fR\fI<type>\fR\fB/\fR
آن\&.
.RE
.PP
reason
.RS 4
یک توضیح خوانا برای انسان\&. در مورد ارجاعاتی که با موفقیت واکشی شده‌اند، نیازی به توضیح نیست\&. برای یک ارجاع ناموفق، دلیل شکست شرح داده می‌شود\&.
.RE
.SH "مثال‌ها (EXAMPLES)"
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
به‌روزرسانی شاخه‌های ردیابی ریموت:
.sp
.if n {\
.RS 4
.\}
.nf
$ git fetch origin
.fi
.if n {\
.RE
.\}
.sp
دستور فوق تمام شاخه‌ها را از فضای نام ریموت
\fBrefs/heads/\fR
کپی کرده و آن‌ها را در فضای نام محلی
\fBrefs/remotes/origin/\fR
ذخیره می‌کند، مگر اینکه از گزینه
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
برای تعیین یک refspec غیرپیش‌فرض استفاده شده باشد\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
استفاده صریح از refspecها:
.sp
.if n {\
.RS 4
.\}
.nf
$ git fetch origin +seen:seen maint:tmp
.fi
.if n {\
.RE
.\}
.sp
این دستور شاخه‌های
\fBseen\fR
و
\fBtmp\fR
را در مخزن محلی با واکشی از شاخه‌های (به ترتیب)
\fBseen\fR
و
\fBmaint\fR
از مخزن ریموت به‌روزرسانی (یا در صورت لزوم ایجاد) می‌کند\&.
.sp
شاخه
\fBseen\fR
حتی اگر fast\-forward نباشد به‌روزرسانی خواهد شد، زیرا دارای پیشوند علامت مثبت است؛ شاخه
\fBtmp\fR
این‌گونه نخواهد بود\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04'\(bu\h'+03'\c
.\}
.el {\
.sp -1
.IP \(bu 2.3
.\}
مشاهده شاخه یک ریموت، بدون پیکربندی ریموت در مخزن محلی شما:
.sp
.if n {\
.RS 4
.\}
.nf
$ git fetch git://git\&.kernel\&.org/pub/scm/git/git\&.git maint
$ git log FETCH_HEAD
.fi
.if n {\
.RE
.\}
.sp
دستور اول شاخه
\fBmaint\fR
را از مخزن در
\fBgit://git\&.kernel\&.org/pub/scm/git/git\&.git\fR
واکشی می‌کند و دستور دوم از
\fBFETCH_HEAD\fR
برای بررسی شاخه با
\fBgit-log\fR(1)
استفاده می‌کند\&. اشیاء واکشی‌شده در نهایت توسط خانه‌داری داخلی گیت حذف خواهند شد (نگاه کنید به
\fBgit-gc\fR(1))\&.
.RE
.SH "امنیت (SECURITY)"
.sp
پروتکل‌های fetch و push طوری طراحی نشده‌اند که مانع از دزدیدن داده‌هایی از مخزن دیگر توسط یک طرف شوند که قرار نبوده به اشتراک گذاشته شوند\&. اگر داده‌های خصوصی دارید که باید از یک همتای مخرب محافظت شوند، بهترین گزینه ذخیره آن در یک مخزن دیگر است\&. این مورد هم برای کلاینت‌ها و هم برای سرورها صدق می‌کند\&. به ویژه، فضاهای نام روی یک سرور برای کنترل دسترسی خواندن مؤثر نیستند؛ شما فقط باید دسترسی خواندن به یک فضای نام را به کلاینت‌هایی اعطا کنید که به آن‌ها برای دسترسی خواندن به کل مخزن اعتماد دارید\&.
.sp
بردارهای حمله شناخته‌شده به شرح زیر هستند:
.sp
.RS 4
.ie n {\
\h'-04' 1.\h'+01'\c
.\}
.el {\
.sp -1
.IP "  1." 4.2
.\}
قربانی خطوط "have" را ارسال می‌کند که شناسه‌های اشیائی را که در اختیار دارد و صراحتاً قصد به اشتراک‌گذاری آن‌ها را نداشته اما در صورت در اختیار داشتن آن‌ها توسط طرف مقابل می‌توانند برای بهینه‌سازی انتقال استفاده شوند، اعلان می‌کند\&. مهاجم یک شناسه شیء X را برای سرقت انتخاب کرده و یک ارجاع به X ارسال می‌کند، اما نیازی به ارسال محتوای X ندارد زیرا قربانی از قبل آن را دارد\&. اکنون قربانی باور می‌کند که مهاجم X را دارد، و بعداً محتوای X را برای مهاجم پس می‌فرستد\&. (انجام این حمله برای کلاینت روی سرور ساده‌ترین روش است، با ایجاد یک ارجاع به X در فضای نامی که کلاینت به آن دسترسی دارد و سپس واکشی آن\&. محتمل‌ترین روش برای انجام آن توسط سرور روی کلاینت، "ادغام" X در یک شاخه عمومی و امیدواری به این است که کاربر کارهای بیشتری روی این شاخه انجام داده و بدون توجه به ادغام، آن را به سرور push کند)\&.
.RE
.sp
.RS 4
.ie n {\
\h'-04' 2.\h'+01'\c
.\}
.el {\
.sp -1
.IP "  2." 4.2
.\}
همانند شماره ۱، مهاجم یک شناسه شیء X را برای سرقت انتخاب می‌کند\&. قربانی شیء Y را که مهاجم از قبل دارد ارسال می‌کند، و مهاجم به دروغ ادعا می‌کند که X را دارد و نه Y را، بنابراین قربانی Y را به عنوان یک دلتا نسبت به X ارسال می‌کند\&. این دلتا بخش‌هایی از X را که شبیه به Y هستند برای مهاجم آشکار می‌سازد\&.
.RE
.SH "پیکربندی (CONFIGURATION)"
.sp
تمام موارد زیر این خط در این بخش به طور گزینشی از مستندات \fBgit-config\fR(1) گنجانده شده است\&. محتوا همان چیزی است که در آنجا یافت می‌شود:
.PP
\fBfetch\&.recurseSubmodules\fR
.RS 4
این گزینه کنترل می‌کند که آیا
\fBgit\fR
\fBfetch\fR
(و واکشی زیرین در
\fBgit\fR
\fBpull\fR)
به صورت بازگشتی در زیرماژول‌های پرشده واکشی کند یا خیر\&. این گزینه می‌تواند روی یک مقدار بولی یا روی
\fBon\-demand\fR
تنظیم شود\&. تنظیم آن روی یک مقدار بولی رفتار fetch و pull را تغییر می‌دهد تا در صورت تنظیم روی true به طور بدون قید و شرط در زیرماژول‌ها پیمایش بازگشتی انجام دهد یا در صورت تنظیم روی false اصلاً پیمایش بازگشتی انجام ندهد\&. هنگامی که روی
\fBon\-demand\fR
تنظیم شود، fetch و pull تنها زمانی در یک زیرماژول پرشده پیمایش بازگشتی انجام می‌دهند که ابرپروژه آن کامیتی را بازیابی کند که ارجاع زیرماژول را به‌روزرسانی می‌نماید\&. پیش‌فرض آن
\fBon\-demand\fR
است، یا در صورت تنظیم بودن، مقدار
\fBsubmodule\&.recurse\fR
خواهد بود\&.
.RE
.PP
\fBfetch\&.fsckObjects\fR
.RS 4
اگر روی true تنظیم شود، git\-fetch\-pack تمام اشیاء واکشی‌شده را بررسی خواهد کرد\&. برای آگاهی از آنچه بررسی می‌شود به
\fBtransfer\&.fsckObjects\fR
مراجعه کنید\&. مقدار پیش‌فرض
\fBfalse\fR
است\&. در صورت عدم تنظیم، مقدار
\fBtransfer\&.fsckObjects\fR
در عوض استفاده می‌شود\&.
.RE
.PP
\fBfetch\&.fsck\&.\fR\fI<msg\-id>\fR
.RS 4
همانند
\fBfsck\&.\fR\fI<msg\-id>\fR
عمل می‌کند، اما توسط
\fBgit-fetch-pack\fR(1)
به جای
\fBgit-fsck\fR(1)
استفاده می‌شود\&. برای جزئیات مستندات
\fBfsck\&.\fR\fI<msg\-id>\fR
را ببینید\&.
.RE
.PP
\fBfetch\&.fsck\&.skipList\fR
.RS 4
همانند
\fBfsck\&.skipList\fR
عمل می‌کند، اما توسط
\fBgit-fetch-pack\fR(1)
به جای
\fBgit-fsck\fR(1)
استفاده می‌شود\&. برای جزئیات مستندات
\fBfsck\&.skipList\fR
را ببینید\&.
.RE
.PP
\fBfetch\&.unpackLimit\fR
.RS 4
اگر تعداد اشیاء واکشی‌شده بر روی انتقال بومی گیت کمتر از این حد باشد، اشیاء در فایل‌های شیء مجزا (loose) بازگشایی می‌شوند\&. با این حال اگر تعداد اشیاء دریافتی برابر یا بیشتر از این حد باشد، بسته دریافتی پس از افزودن هرگونه پایه دلتای مفقود، به عنوان یک pack ذخیره می‌شود\&. ذخیره بسته حاصل از یک push می‌تواند عملیات push را به ویژه در سیستم‌های فایل کند سریع‌تر به پایان برساند\&. در صورت عدم تنظیم، مقدار
\fBtransfer\&.unpackLimit\fR
در عوض استفاده می‌شود\&.
.RE
.PP
\fBfetch\&.prune\fR
.RS 4
اگر true باشد، fetch به طور خودکار به گونه‌ای عمل می‌کند که گویی گزینه
\fB\-\-\prune\fR
در خط فرمان داده شده است\&. همچنین
\fBremote\&.\fR\fI<name>\fR\fB\&.prune\fR
و بخش «هرس کردن شاخه‌ها» (PRUNING) در
\fBgit-fetch\fR(1)
را ببینید\&.
.RE
.PP
\fBfetch\&.pruneTags\fR
.RS 4
اگر true باشد، fetch در هنگام هرس به طور خودکار به گونه‌ای رفتار می‌کند که گویی refspec به صورت
\fBrefs/tags/*:refs/tags/*\fR
ارائه شده است، در صورتی که قبلاً تنظیم نشده باشد\&. این امر امکان تنظیم هم این گزینه و هم
\fBfetch\&.prune\fR
را برای حفظ نگاشت ۱ به ۱ با ارجاعات بالادست فراهم می‌کند\&. همچنین
\fBremote\&.\fR\fI<name>\fR\fB\&.pruneTags\fR
و بخش «هرس کردن شاخه‌ها» (PRUNING) در
\fBgit-fetch\fR(1)
را ببینید\&.
.RE
.PP
\fBfetch\&.all\fR
.RS 4
اگر true باشد، fetch تلاش خواهد کرد تمام ریموت‌های موجود را به‌روزرسانی کند\&. این رفتار می‌تواند با ارسال
\fB\-\-\no\-all\fR
یا با تعیین صریح یک یا چند ریموت برای واکشی لغو و بازنویسی شود\&. مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fBfetch\&.output\fR
.RS 4
نحوه چاپ وضعیت به‌روزرسانی ارجاع را کنترل می‌کند\&. مقادیر معتبر عبارتند از
\fBfull\fR
و
\fBcompact\fR\&.
مقدار پیش‌فرض
\fBfull\fR
است\&. برای جزئیات بخش خروجی (OUTPUT) در
\fBgit-fetch\fR(1)
را ببینید\&.
.RE
.PP
\fBfetch\&.negotiationAlgorithm\fR
.RS 4
نحوه ارسال اطلاعات مربوط به کامیت‌ها در مخزن محلی را هنگام مذاکره درباره محتویات packfile ارسالی توسط سرور کنترل می‌کند\&. روی
\fBconsecutive\fR
تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌های متوالی را پیمایش کرده و هر یک را بررسی می‌کند\&. روی
\fBskipping\fR
تنظیم کنید تا از الگوریتمی استفاده شود که کامیت‌ها را با هدف همگرایی سریع‌تر نادیده می‌گیرد (skip می‌کند)، اما ممکن است منجر به یک packfile بزرگ‌تر از حد لازم شود؛ یا روی
\fBnoop\fR
تنظیم کنید تا اصلاً هیچ اطلاعاتی ارسال نشود، که تقریباً به طور قطع منجر به یک packfile بزرگ‌تر از حد لازم خواهد شد، اما از مرحله مذاکره صرف‌نظر می‌کند\&. روی
\fBdefault\fR
تنظیم کنید تا تنظیمات انجام‌شده قبلی لغو شده و از رفتار پیش‌فرض استفاده شود\&. پیش‌فرض معمولاً
\fBconsecutive\fR
است، اما اگر
\fBfeature\&.experimental\fR
برابر با
\fBtrue\fR
باشد، آن‌گاه پیش‌فرض
\fBskipping\fR
خواهد بود\&. مقادیر ناشناخته باعث بروز خطا در
\fBgit\fR
\fBfetch\fR
خواهند شد\&.
.sp
همچنین گزینه‌های
\fB\-\-\negotiate\-only\fR
و
\fB\-\-\negotiation\-restrict\fR
در
\fBgit-fetch\fR(1)
را ببینید\&.
.RE
.PP
\fBfetch\&.showForcedUpdates\fR
.RS 4
روی
\fBfalse\fR
تنظیم کنید تا
\fB\-\-\no\-show\-forced\-updates\fR
در دستورات
\fBgit-fetch\fR(1)
و
\fBgit-pull\fR(1)
فعال شود\&. مقدار پیش‌فرض
\fBtrue\fR
است\&.
.RE
.PP
\fBfetch\&.parallel\fR
.RS 4
حداکثر تعداد عملیات واکشی را که می‌توانند به طور همزمان به صورت موازی اجرا شوند مشخص می‌کند (زیرماژول‌ها، یا ریموت‌ها هنگامی که گزینه
\fB\-\-\multiple\fR
در
\fBgit-fetch\fR(1)
فعال باشد)\&.
.sp
مقدار 0 پیش‌فرضی منطقی تعیین خواهد کرد\&. در صورت عدم تنظیم، پیش‌فرض آن 1 است\&.
.sp
برای زیرماژول‌ها، این تنظیم می‌تواند با استفاده از تنظیم پیکربندی
\fBsubmodule\&.fetchJobs\fR
بازنویسی شود\&.
.RE
.PP
\fBfetch\&.writeCommitGraph\fR
.RS 4
روی true تنظیم کنید تا پس از هر دستور
\fBgit\fR
\fBfetch\fR
که یک pack-file را از یک ریموت بارگیری می‌کند، یک commit\-graph نوشته شود\&. با استفاده از گزینه
\fB\-\-\split\fR،
اکثر اجراها یک فایل commit\-graph بسیار کوچک بر روی فایل(های) commit\-graph موجود ایجاد می‌کنند\&. گاهی اوقات این فایل‌ها ادغام می‌شوند و نوشتن ممکن است بیشتر طول بکشد\&. داشتن یک فایل commit\-graph به‌روز به عملکرد بسیاری از دستورات گیت کمک می‌کند، از جمله
\fBgit\fR
\fBmerge\-base\fR،
\fBgit\fR
\fBpush\fR
\fB\-f\fR
و
\fBgit\fR
\fBlog\fR
\fB\-\-\graph\fR\&.
مقدار پیش‌فرض
\fBfalse\fR
است\&.
.RE
.PP
\fBfetch\&.bundleURI\fR
.RS 4
این مقدار یک URI را برای بارگیری داده‌های شیء گیت از یک bundle URI قبل از انجام واکشی افزایشی از سرور اصلی گیت ذخیره می‌کند\&. این شبیه به نحوه رفتار گزینه
\fB\-\-\bundle\-uri\fR
در
\fBgit-clone\fR(1)
است\&. دستور
\fBgit\fR
\fBclone\fR
\fB\-\-\bundle\-uri\fR
مقدار
\fBfetch\&.bundleURI\fR
را در صورتی که bundle URI ارائه‌شده حاوی فهرست باندلی باشد که برای واکشی‌های افزایشی سازماندهی شده است تنظیم خواهد کرد\&.
.sp
اگر این مقدار را تغییر دهید و مخزن شما دارای مقدار
\fBfetch\&.bundleCreationToken\fR
باشد، آن‌گاه پیش از واکشی از bundle URI جدید، آن مقدار
\fBfetch\&.bundleCreationToken\fR
را حذف کنید\&.
.RE
.PP
\fBfetch\&.bundleCreationToken\fR
.RS 4
هنگام استفاده از
\fBfetch\&.bundleURI\fR
برای واکشی افزایشی از یک فهرست باندل که از روش ابتکاری "\fBcreationToken\fR" استفاده می‌کند، این مقدار پیکربندی حداکثر مقدار
\fBcreationToken\fR
باندل‌های بارگیری‌شده را ذخیره می‌کند\&. این مقدار برای جلوگیری از بارگیری باندل‌ها در آینده در صورتی که
\fBcreationToken\fR
اعلان‌شده اکیداً بزرگ‌تر از این مقدار نباشد استفاده می‌شود\&.
.sp
مقادیر توکن ایجاد توسط ارائه‌دهنده‌ای که bundle URI خاص را ارائه می‌دهد انتخاب می‌شوند\&. اگر URI را در
\fBfetch\&.bundleURI\fR
تغییر دادید، حتماً قبل از واکشی مقدار
\fBfetch\&.bundleCreationToken\fR
را حذف کنید\&.
.RE
.SH "اشکالات (BUGS)"
.sp
استفاده از \fB\-\-\recurse\-submodules\fR تنها می‌تواند کامیت‌های جدید را در زیرماژول‌هایی واکشی کند که به صورت محلی مثلاً در \fB$GIT_DIR/modules/\fR حضور دارند\&. اگر بالادست یک زیرماژول جدید اضافه کند، آن زیرماژول تا زمانی که کلون نشود (مثلاً توسط \fBgit\fR \fBsubmodule\fR \fBupdate\fR) قابل واکشی نیست\&. انتظار می‌رود این مشکل در نسخه‌های آینده گیت برطرف شود\&.
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-pull\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)