'\" t
.\"     Title: git-pull
.\"    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: دستورات عمومی کاربر
.\"    Source: Git 2.55.0
.\"  Language: Persian
.\"
.TH "GIT\-PULL" "1" "2026\-06\-29" "Git 2\&.55\&.0" "دستورات عمومی کاربر"
.\" -----------------------------------------------------------------
.\" * 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-pull \- دریافت و ادغام تغییرات از یک مخزن دیگر یا یک شاخه محلی
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fBgit\fR \fBpull\fR [\fI<options>\fR] [\fI<repository>\fR [\fI<refspec>\fR\&...]]
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
تغییرات را از یک مخزن دوردست در شاخه فعلی ادغام می‌کند\&.
.sp
ابتدا، \fBgit\fR \fBpull\fR دستور \fBgit\fR \fBfetch\fR را با همان آرگومان‌ها (به‌جز گزینه‌های ادغام) برای واکشی شاخه(های) دوردست اجرا می‌کند\&. سپس تصمیم می‌گیرد که کدام شاخه دوردست را ادغام کند: اگر \fBgit\fR \fBpull\fR را بدون هیچ آرگومانی اجرا کنید، این مورد به‌طور پیش‌فرض شاخه بالادست (upstream) برای شاخه فعلی خواهد بود\&. سپس آن شاخه را در شاخه فعلی ادغام می‌کند\&.
.sp
برای ادغام شاخه دوردست، ۴ گزینه اصلی وجود دارد:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
دستور
\fBgit\fR
\fBpull\fR
\fB\-\-ff\-only\fR
تنها به‌روزرسانی‌های «فست‌فوروارد» (fast\-forward) را انجام می‌دهد: اگر شاخه محلی شما از شاخه دوردست واگرا شده باشد، با شکست مواجه می‌شود\&. این حالت پیش‌فرض است\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
دستور
\fBgit\fR
\fBpull\fR
\fB\-\-rebase\fR
دستور
\fBgit\fR
\fBrebase\fR
را اجرا می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
دستور
\fBgit\fR
\fBpull\fR
\fB\-\-no\-rebase\fR
دستور
\fBgit\fR
\fBmerge\fR
را اجرا می‌کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  4." 4.2
.\}
دستور
\fBgit\fR
\fBpull\fR
\fB\-\-squash\fR
دستور
\fBgit\fR
\fBmerge\fR
\fB\-\-squash\fR
را اجرا می‌کند\&.
.RE
.sp
همچنین می‌توانید گزینه‌های پیکربندی \fBpull\&.rebase\fR، \fBpull\&.squash\fR یا \fBpull\&.ff\fR را با رفتار مورد نظر خود تنظیم کنید\&.
.sp
اگر در طول ادغام یا ری‌بیس با یک تداخل ادغام مواجه شدید که نمی‌خواهید آن را مدیریت کنید، می‌توانید با خیال راحت آن را با \fBgit\fR \fBmerge\fR \fB\-\-abort\fR یا \fBgit\fR \fBrebase\fR \fB\-\-abort\fR لغو کنید\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
\fI<repository>\fR
.RS 4
مخزن «دوردست» (remote) برای پول کردن از آن\&. این مقدار می‌تواند یک نشانی اینترنتی (بخش
GIT URLS
در زیر را ببینید) یا نام یک ریموت باشد (بخش
REMOTES
در زیر را ببینید)\&.
.sp
پیش‌فرض آن بالادست پیکربندی‌شده برای شاخه کنونی، یا
\fBorigin\fR
است\&. برای اطلاعات بیشتر در مورد نحوه پیکربندی بالادست‌ها، بخش
UPSTREAM BRANCHES
در زیر را ببینید\&.
.RE
.PP
\fI<refspec>\fR
.RS 4
کدام شاخه یا سایر ارجاع(ها) واکشی و در شاخه کنونی ادغام شوند؛ برای مثال
\fBmain\fR
در
\fBgit\fR
\fBpull\fR
\fBorigin\fR
\fBmain\fR\&.
پیش‌فرض آن بالادست پیکربندی‌شده برای شاخه کنونی است\&.
.sp
این می‌تواند یک شاخه، تگ یا مجموعه دیگری از ارجاع(ها) باشد\&. برای نحو کامل،
\fI<refspec>\fR
در زیر تحت عنوان «گزینه‌های مربوط به واکشی» را ببینید، و برای نحوه استفاده
\fBgit\fR
\fBpull\fR
از این آرگومان جهت تعیین شاخه دوردستی که باید ادغام شود، بخش
DEFAULT BEHAVIOUR
در زیر را مشاهده کنید\&.
.RE
.PP
\fB\-q\fR, \fB\-\-quiet\fR
.RS 4
این گزینه به هر دو دستور زیربنایی git\-fetch (جهت فرونشاندن گزارش‌ها حین انتقال) و git\-merge (جهت فرونشاندن خروجی حین ادغام) ارسال می‌شود\&.
.RE
.PP
\fB\-v\fR, \fB\-\-verbose\fR
.RS 4
گزینه
\fB\-\-verbose\fR
را به git\-fetch و git\-merge ارسال می‌کند\&.
.RE
.PP
\fB\-\-recurse\-submodules\fR[\fB=\fR(\fByes\fR|\fBon\-demand\fR|\fBno\fR)], \fB\-\-no\-recurse\-submodules\fR
.RS 4
این گزینه کنترل می‌کند که آیا کامیت‌های جدید زیرماژول‌های مقداردهی‌شده باید واکشی شوند و آیا درخت‌های کاری زیرماژول‌های فعال نیز باید به‌روزرسانی شوند یا خیر (ببینید
\fBgit-fetch\fR(1)،
\fBgit-config\fR(1)
و
\fBgitmodules\fR(5))\&.
.sp
اگر بررسی و تحویل (checkout) از طریق ری‌بیس انجام شود، کامیت‌های محلی زیرماژول نیز ری‌بیس می‌شوند\&.
.sp
اگر به‌روزرسانی از طریق ادغام انجام شود، تداخل‌های زیرماژول حل و دریافت (checked out) می‌شوند\&.
.RE
.SS "گزینه‌های مربوط به ادغام (Options related to merging)"
.PP
\fB\-\-commit\fR, \fB\-\-no\-commit\fR
.RS 4
ادغام را انجام داده و نتیجه را کامیت می‌کند\&. از این گزینه می‌توان برای لغو
\fB\-\-no\-commit\fR
استفاده کرد\&. فقط هنگام ادغام کاربرد دارد\&.
.sp
با
\fB\-\-no\-commit\fR
ادغام را انجام داده و درست پیش از ایجاد کامیت ادغام متوقف می‌شود، تا به کاربر فرصت بازبینی و تغییر بیشتر نتیجه ادغام پیش از کامیت کردن داده شود\&.
.sp
توجه داشته باشید که به‌روزرسانی‌های فست‌فوروارد کامیت ادغام ایجاد نمی‌کنند و بنابراین راهی برای متوقف کردن آن ادغام‌ها با
\fB\-\-no\-commit\fR
وجود ندارد\&. از این رو، اگر می‌خواهید مطمئن شوید که شاخه شما توسط دستور ادغام تغییر یا به‌روزرسانی نمی‌شود، از
\fB\-\-no\-ff\fR
همراه با
\fB\-\-no\-commit\fR
استفاده کنید\&.
.RE
.PP
\fB\-\-edit\fR, \fB\-e\fR, \fB\-\-no\-edit\fR
.RS 4
پیش از کامیت کردن یک ادغام مکانیکی موفق، یک ویرایشگر را فراخوانی می‌کند تا پیام ادغام تولیدشده به‌طور خودکار ویرایش شود، تا کاربر بتواند ادغام را توضیح داده و توجیه کند\&. گزینه
\fB\-\-no\-edit\fR
می‌تواند برای پذیرش پیام تولیدشده به‌طور خودکار استفاده شود (این کار عموماً توصیه نمی‌شود)\&.
.sp
اسکریپت‌های قدیمی‌تر ممکن است به رفتار تاریخی عدم اجازه به کاربر برای ویرایش پیام لاگ ادغام وابسته باشند\&. آن‌ها هنگام اجرای
\fBgit\fR
\fBmerge\fR
باز شدن یک ویرایشگر را خواهند دید\&. برای آسان‌تر کردن تطبیق چنین اسکریپت‌هایی با رفتار به‌روزرسانی‌شده، متغیر محیطی
\fBGIT_MERGE_AUTOEDIT\fR
می‌تواند در ابتدای آن‌ها روی
\fBno\fR
تنظیم شود\&.
.RE
.PP
\fB\-\-cleanup=\fR\fI<mode>\fR
.RS 4
این گزینه تعیین می‌کند که پیام ادغام پیش از کامیت چگونه پاک‌سازی شود\&. برای جزئیات بیشتر
\fBgit-commit\fR(1)
را ببینید\&. علاوه بر این، اگر به
\fI<mode>\fR
مقدار
\fBscissors\fR
داده شود، در صورت بروز تداخل ادغام، خط قیچی (scissors) پیش از ارسال به سازوکار کامیت به
\fBMERGE_MSG\fR
اضافه خواهد شد\&.
.RE
.PP
\fB\-\-ff\-only\fR
.RS 4
تنها در صورتی به تاریخچه جدید به‌روزرسانی می‌کند که هیچ تاریخچه محلی واگرایی وجود نداشته باشد\&. زمانی که هیچ روشی برای تطبیق تاریخچه‌های واگرا (از طریق فلگ‌های
\fB\-\-rebase\fR)
ارائه نشده باشد، این حالت پیش‌فرض است\&.
.RE
.PP
\fB\-\-ff\fR, \fB\-\-no\-ff\fR
.RS 4
هنگام ادغام به جای ری‌بیس، مشخص می‌کند که در صورت فرزند بودن تاریخچه ادغام‌شده از تاریخچه کنونی، ادغام چگونه مدیریت شود\&. اگر ادغام درخواست شده باشد،
\fB\-\-ff\fR
حالت پیش‌فرض است مگر اینکه تگ دارای توضیحات (و احتمالاً امضاشده‌ای) ادغام شود که در جایگاه طبیعی خود در سلسله‌مراتب
\fBrefs/tags/\fR
ذخیره نشده است، که در این حالت
\fB\-\-no\-ff\fR
فرض می‌شود\&.
.sp
با
\fB\-\-ff\fR،
در صورت امکان ادغام را به‌صورت فست‌فوروارد حل می‌کند (تنها اشاره‌گر شاخه را مطابق با شاخه ادغام‌شده به‌روزرسانی می‌کند؛ کامیت ادغام ایجاد نمی‌کند)\&. در صورت عدم امکان (زمانی که تاریخچه ادغام‌شده از نوادگان تاریخچه کنونی نباشد)، یک کامیت ادغام ایجاد می‌کند\&.
.sp
با
\fB\-\-no\-ff\fR،
در تمام موارد یک کامیت ادغام ایجاد می‌کند، حتی زمانی که ادغام می‌توانست به‌صورت فست‌فوروارد حل شود\&.
.RE
.PP
\fB\-S\fR[\fI<key\-id>\fR], \fB\-\-gpg\-sign\fR[\fB=\fR\fI<key\-id>\fR], \fB\-\-no\-gpg\-sign\fR
.RS 4
کامیت ادغام حاصل را با GPG امضا می‌کند\&. آرگومان
\fI<key\-id>\fR
اختیاری است و پیش‌فرض آن هویت کامیت‌کننده است؛ در صورت تعیین، باید بدون فاصله به گزینه متصل باشد\&.
\fB\-\-no\-gpg\-sign\fR
برای باطل کردن هم متغیر پیکربندی
\fBcommit\&.gpgSign\fR
و هم گزینه قبلی
\fB\-\-gpg\-sign\fR
مفید است\&.
.RE
.PP
\fB\-\-log\fR[\fB=\fR\fI<n>\fR], \fB\-\-no\-log\fR
.RS 4
علاوه بر نام شاخه‌ها، پیام لاگ را با توضیحات یک‌خطی از حداکثر
\fI<n>\fR
کامیت واقعی که در حال ادغام هستند پر می‌کند\&. همچنین
\fBgit-fmt-merge-msg\fR(1)
را ببینید\&. فقط هنگام ادغام کاربرد دارد\&.
.sp
با
\fB\-\-no\-log\fR
توضیحات یک‌خطی کامیت‌های واقعی در حال ادغام را فهرست نمی‌کند\&.
.RE
.PP
\fB\-\-signoff\fR, \fB\-\-no\-signoff\fR
.RS 4
یک دنباله (trailer)
\fBSigned\-off\-by\fR
توسط کامیت‌کننده در انتهای پیام لاگ کامیت اضافه می‌کند\&. معنای signoff به پروژه‌ای که به آن کامیت می‌کنید بستگی دارد\&. برای مثال، ممکن است گواهی دهد که کامیت‌کننده حق ارسال اثر تحت پروانه پروژه را دارد یا با برخی از بیانیه‌های مشارکت‌کنندگان، مانند «گواهی مبدا توسعه‌دهنده» (Developer Certificate of Origin) موافقت می‌کند\&. (برای نمونه مورد استفاده توسط هسته لینوکس و پروژه‌های گیت،
\m[blue]\fBhttps://developercertificate\&.org\fR\m[]
را ببینید\&.) برای درک نحوه استفاده از signoffها در پروژه‌ای که در آن مشارکت می‌کنید، با مستندات یا راهبری آن پروژه مشورت کنید\&.
.sp
گزینه
\fB\-\-no\-signoff\fR
می‌تواند برای باطل کردن گزینه قبلی
\fB\-\-signoff\fR
در خط فرمان استفاده شود\&.
.sp
گیت یک متغیر پیکربندی برای فعال کردن گزینه خط فرمان
\fB\-\-signoff\fR
به صورت پیش‌فرض ندارد (و نخواهد داشت)؛ برای جزئیات بیشتر ورودی
\fBcommit\&.signoff\fR
را در
\fBgitfaq\fR(7)
ببینید\&.
.RE
.PP
\fB\-\-stat\fR, \fB\-n\fR, \fB\-\-no\-stat\fR
.RS 4
یک diffstat در پایان ادغام نمایش می‌دهد\&. این diffstat همچنین توسط گزینه پیکربندی merge\&.stat کنترل می‌شود\&.
.sp
با
\fB\-n\fR
یا
\fB\-\-no\-stat\fR
در پایان ادغام diffstat نشان داده نمی‌شود\&.
.RE
.PP
\fB\-\-compact\-summary\fR
.RS 4
یک خلاصه فشرده (compact\-summary) در پایان ادغام نمایش می‌دهد\&.
.RE
.PP
\fB\-\-squash\fR, \fB\-\-no\-squash\fR
.RS 4
وضعیت درخت کاری و ایندکس را به‌گونه‌ای تولید می‌کند که گویی یک ادغام واقعی رخ داده است (به‌جز اطلاعات ادغام)، اما در واقع کامیتی ایجاد نمی‌کند،
\fBHEAD\fR
را جابجا نمی‌کند، یا
\fB$GIT_DIR/MERGE_HEAD\fR
را ثبت نمی‌کند (تا باعث شود دستور بعدی
\fBgit\fR
\fBcommit\fR
یک کامیت ادغام ایجاد کند)\&. این به شما امکان می‌دهد تا یک کامیت منفرد بر روی شاخه کنونی بسازید که تأثیر آن همانند ادغام یک شاخه دیگر (یا بیشتر در حالت ادغام چندگانه یا octopus) است\&.
.sp
با
\fB\-\-no\-squash\fR
ادغام را انجام داده و نتیجه را کامیت می‌کند\&. از این گزینه می‌توان برای لغو
\fB\-\-squash\fR
استفاده کرد\&.
.sp
با
\fB\-\-squash\fR،
استفاده از
\fB\-\-commit\fR
مجاز نبوده و ناموفق خواهد بود\&.
.sp
فقط هنگام ادغام کاربرد دارد\&.
.RE
.PP
\fB\-\-verify\fR, \fB\-\-no\-verify\fR
.RS 4
به‌طور پیش‌فرض، قلاب‌های pre\-merge و commit\-msg اجرا می‌شوند\&. وقتی
\fB\-\-no\-verify\fR
داده شود، این قلاب‌ها نادیده گرفته می‌شوند\&. همچنین
\fBgithooks\fR(5)
را ببینید\&. فقط هنگام ادغام کاربرد دارد\&.
.RE
.PP
\fB\-s\fR \fI<strategy>\fR, \fB\-\-strategy=\fR\fI<strategy>\fR
.RS 4
از راهبرد ادغام داده‌شده استفاده می‌کند؛ می‌تواند بیش از یک بار مشخص شود تا به ترتیبی که باید امتحان شوند تعیین گردند\&. اگر گزینه
\fB\-s\fR
مشخص نشود، یک فهرست درونی از راهبردها استفاده می‌شود (\fBort\fR
هنگام ادغام یک سر (head) منفرد، و در غیر این صورت
\fBoctopus\fR)\&.
.RE
.PP
\fB\-X\fR \fI<option>\fR, \fB\-\-strategy\-option=\fR\fI<option>\fR
.RS 4
گزینه خاص راهبرد ادغام را به راهبرد ادغام ارسال می‌کند\&.
.RE
.PP
\fB\-\-verify\-signatures\fR, \fB\-\-no\-verify\-signatures\fR
.RS 4
بررسی و تأیید می‌کند که کامیت رأس شاخه جانبی در حال ادغام با یک کلید معتبر امضا شده باشد، یعنی کلیدی که دارای شناسه کاربری (uid) معتبر است: در مدل اعتماد پیش‌فرض، این بدان معناست که کلید امضاکننده توسط یک کلید مورد اعتماد امضا شده است\&. اگر کامیت رأس شاخه جانبی با کلید معتبر امضا نشده باشد، ادغام لغو می‌شود\&.
.sp
فقط هنگام ادغام کاربرد دارد\&.
.RE
.PP
\fB\-\-summary\fR, \fB\-\-no\-summary\fR
.RS 4
مترادف‌هایی برای
\fB\-\-stat\fR
و
\fB\-\-no\-stat\fR؛
این گزینه‌ها منسوخ شده‌اند و در آینده حذف خواهند شد\&.
.RE
.PP
\fB\-\-autostash\fR, \fB\-\-no\-autostash\fR
.RS 4
به‌طور خودکار پیش از شروع عملیات یک مدخل اندوخته (stash) موقت ایجاد کرده، آن را در ارجاع
\fBMERGE_AUTOSTASH\fR
ثبت می‌کند و پس از پایان عملیات اعمال می‌نماید\&. این بدان معناست که می‌توانید عملیات را روی یک درخت کاری با تغییرات ذخیره‌نشده (dirty) اجرا کنید\&. با این حال با احتیاط استفاده کنید: اعمال نهایی اندوخته پس از یک ادغام موفق ممکن است به تداخل‌های غیرساده منجر شود\&.
.RE
.PP
\fB\-\-allow\-unrelated\-histories\fR
.RS 4
به‌طور پیش‌فرض، دستور
\fBgit\fR
\fBmerge\fR
از ادغام تاریخچه‌هایی که جد مشترکی ندارند خودداری می‌کند\&. از این گزینه می‌توان برای لغو این تدبیر ایمنی هنگام ادغام تاریخچه‌های دو پروژه‌ای که زندگی خود را به‌طور مستقل آغاز کرده‌اند استفاده کرد\&. از آنجا که این یک رویداد بسیار نادر است، هیچ متغیر پیکربندی برای فعال کردن پیش‌فرض آن وجود ندارد یا افزوده نخواهد شد\&.
.sp
فقط هنگام ادغام کاربرد دارد\&.
.RE
.PP
\fB\-r\fR, \fB\-\-rebase\fR[\fB=\fR(\fBtrue\fR|\fBmerges\fR|\fBfalse\fR|\fBinteractive\fR)]
.RS 4
.PP
\fBtrue\fR
.RS 4
پس از واکشی، شاخه کنونی را بر روی شاخه بالادست ری‌بیس می‌کند\&. اگر یک شاخه ردگیری دوردست متناظر با شاخه بالادست وجود داشته باشد و شاخه بالادست از زمان آخرین واکشی ری‌بیس شده باشد، ری‌بیس از آن اطلاعات برای جلوگیری از ری‌بیس تغییرات غیرمحلی استفاده می‌کند\&. این حالت پیش‌فرض است\&.
.RE
.PP
\fBmerges\fR
.RS 4
ری‌بیس با استفاده از
\fBgit\fR
\fBrebase\fR
\fB\-\-rebase\-merges\fR
به‌طوری که کامیت‌های ادغام محلی در ری‌بیس گنجانده شوند (برای جزئیات
\fBgit-rebase\fR(1)
را ببینید)\&.
.RE
.PP
\fBfalse\fR
.RS 4
شاخه بالادست را در شاخه کنونی ادغام می‌کند\&.
.RE
.PP
\fBinteractive\fR
.RS 4
حالت تعاملی ری‌بیس را فعال می‌کند\&.
.RE
.sp
اگر می‌خواهید کاری کنید که
\fBgit\fR
\fBpull\fR
همواره به جای ادغام از
\fB\-\-rebase\fR
استفاده کند،
\fBpull\&.rebase\fR،
\fBbranch\&.\fR\fI<name>\fR\fB\&.rebase\fR
و
\fBbranch\&.autoSetupRebase\fR
را در
\fBgit-config\fR(1)
ببینید\&.
.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
این یک حالت عملیاتی بالقوه
\fIخطرناک\fR
است\&. این حالت تاریخچه را بازنویسی می‌کند، که در صورت انتشار قبلی آن تاریخچه اصلاً خوشایند نخواهد بود\&. از این گزینه استفاده
\fBنکنید\fR
مگر اینکه
\fBgit-rebase\fR(1)
را با دقت مطالعه کرده باشید\&.
.sp .5v
.RE
.RE
.PP
\fB\-\-no\-rebase\fR
.RS 4
این فرم خلاصه
\fB\-\-rebase=false\fR
است\&.
.RE
.SS "گزینه‌های مربوط به واکشی (Options related to fetching)"
.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
از یک تراکنش اتمیک (تجزیه‌ناپذیر) برای به‌روزرسانی مراجع محلی استفاده می‌کند\&. یا تمام مراجع به‌روزرسانی می‌شوند، یا در صورت بروز خطا، هیچ مرجعی به‌روزرسانی نمی‌شود\&.
.RE
.PP
\fB\-\-depth=\fR\fI<depth>\fR
.RS 4
واکشی را به تعداد مشخص‌شده از کامیت‌ها از نوک تاریخچه هر شاخه دوردست محدود می‌کند\&. اگر عمل واکشی در یک مخزن کم‌عمق (\fIshallow\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 (احتمالاً کوتاه‌شده) یک کامیت باشد\&. مشخص کردن یک الگو معادل تعیین این گزینه به دفعات متعدد است، یکی به ازای هر نام مرجع منطبق\&.
.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
از قابلیت کلون جزئی بهره می‌گیرد و درخواست می‌کند که سرور زیرمجموعه‌ای از اشیاء قابل دسترس را بر اساس یک فیلتر شیء داده‌شده ارسال کند\&. هنگام استفاده از
\fB\-\-filter\fR،
مقدار ارائه‌شده در
\fI<filter\-spec>\fR
برای واکشی جزئی استفاده می‌شود\&.
.sp
اگر
\fB\-\-filter=auto\fR
استفاده شود، مشخصات فیلتر به‌طور خودکار با ترکیب مشخصات فیلتر اعلام‌شده توسط سرور برای مخازن دوردست ضامن (promisor remotes) که کلاینت می‌پذیرد تعیین می‌شود (نگاه کنید به
\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\-f\fR, \fB\-\-force\fR
.RS 4
هنگامی که
\fBgit\fR
\fBfetch\fR
با مشخصه مرجع (refspec)
\fI<src>\fR\fB:\fR\fI<dst>\fR
استفاده شود، ممکن است همان‌طور که در بخش
\fI<refspec>\fR
از مستندات
\fBgit-fetch\fR(1)
بحث شده است، از به‌روزرسانی شاخه محلی خودداری کند\&. این گزینه آن بررسی را نادیده می‌گیرد\&.
.RE
.PP
\fB\-k\fR, \fB\-\-keep\fR
.RS 4
بسته (pack) دانلودشده را نگه می‌دارد\&.
.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
واکشی شده باشند، مشمول هرس شدن نیستند\&. با این حال، اگر برچسب‌ها به دلیل یک مشخصه مرجع صریح واکشی شوند (چه در خط فرمان یا در پیکربندی مخزن دوردست، برای مثال اگر مخزن دوردست با گزینه
\fB\-\-mirror\fR
کلون شده باشد)، آنگاه مشمول هرس شدن نیز خواهند بود\&. ارائه گزینه
\fB\-\-prune\-tags\fR
یک حالت کوتاه‌نویسی برای ارائه refspec برچسب است\&.
.RE
.PP
\fB\-\-no\-tags\fR
.RS 4
به‌طور پیش‌فرض، برچسب‌هایی که به اشیاء دانلودشده از مخزن دوردست اشاره می‌کنند واکشی شده و به صورت محلی ذخیره می‌شوند\&. این گزینه دنبال کردن خودکار برچسب را غیرفعال می‌کند\&. رفتار پیش‌فرض برای یک مخزن دوردست را می‌توان با تنظیم
\fBremote\&.\fR\fI<name>\fR\fB\&.tagOpt\fR
مشخص کرد\&. نگاه کنید به
\fBgit-config\fR(1)\&.
.RE
.PP
\fB\-\-refmap=\fR\fI<refspec>\fR
.RS 4
هنگام واکشی مراجع فهرست‌شده در خط فرمان، به جای مقادیر متغیرهای پیکربندی
\fBremote\&.\fR\fI<name>\fR\fB\&.fetch\fR
برای مخزن دوردست، از مشخصه مرجع تعیین‌شده (می‌تواند بیش از یک بار داده شود) برای نگاشت مراجع به شاخه‌های ردگیری دوردست استفاده می‌کند\&. ارائه یک
\fI<refspec>\fR
خالی به گزینه
\fB\-\-refmap\fR
باعث می‌شود گیت مشخصه‌های مرجع پیکربندی‌شده را نادیده بگیرد و کاملاً به مشخصه‌های مرجع ارائه‌شده به‌عنوان آرگومان‌های خط فرمان تکیه کند\&. برای جزئیات به بخش "Configured Remote\-tracking Branches" مراجعه کنید\&.
.RE
.PP
\fB\-t\fR, \fB\-\-tags\fR
.RS 4
علاوه بر هر چیز دیگری که در غیر این صورت واکشی می‌شد، تمام برچسب‌ها را از مخزن دوردست واکشی می‌کند (یعنی واکشی برچسب‌های دوردست
\fBrefs/tags/*\fR
به درون برچسب‌های محلی با همان نام)\&. استفاده از این گزینه به تنهایی برچسب‌ها را مشمول هرس شدن نمی‌کند، حتی اگر
\fB\-\-prune\fR
استفاده شده باشد (هرچند اگر برچسب‌ها مقصد یک مشخصه مرجع صریح نیز باشند ممکن است به هر حال هرس شوند؛ نگاه کنید به
\fB\-\-prune\fR)\&.
.RE
.PP
\fB\-j\fR \fI<n>\fR, \fB\-\-jobs=\fR\fI<n>\fR
.RS 4
تمام انواع واکشی را به طور هم‌زمان تا سقف
\fI<n>\fR
پردازش موازی‌سازی می‌کند\&.
.sp
مقدار 0 از یک پیش‌فرض معقول استفاده خواهد کرد\&.
.sp
اگر گزینه
\fB\-\-multiple\fR
مشخص شده باشد، مخازن دوردست مختلف به‌طور موازی واکشی خواهند شد\&. اگر چندین زیرماژول واکشی شوند، آن‌ها نیز به‌طور موازی واکشی خواهند شد\&. برای کنترل مستقل آن‌ها، از تنظیمات پیکربندی
\fBfetch\&.parallel\fR
و
\fBsubmodule\&.fetchJobs\fR
استفاده کنید (نگاه کنید به
\fBgit-config\fR(1))\&.
.sp
به‌طور معمول، واکشی‌های بازگشتی موازی و چندمخزنه سریع‌تر خواهند بود\&. به‌طور پیش‌فرض واکشی‌ها به‌صورت متوالی و نه موازی انجام می‌شوند\&.
.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\-\-upload\-pack\fR \fI<upload\-pack>\fR
.RS 4
در صورت ارائه، و زمانی که مخزن مورد نظر برای واکشی توسط
\fBgit\fR
\fBfetch\-pack\fR
مدیریت می‌شود، آرگومان
\fB\-\-exec=\fR\fI<upload\-pack>\fR
به دستور ارسال می‌شود تا مسیر غیرپیش‌فرضی را برای دستوری که در طرف مقابل اجرا می‌شود مشخص کند\&.
.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
هنگام برقراری ارتباط با استفاده از نسخه ۲ پروتکل، رشته داده‌شده را به سرور منتقل می‌کند\&. رشته داده‌شده نباید حاوی کاراکتر
\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
به‌طور پیش‌فرض، گیت بررسی می‌کند که آیا شاخه‌ای در حین واکشی با اجبار به‌روزرسانی (force-updated) شده است یا خیر\&. این بررسی را می‌توان از طریق
\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
همچنان قبل از اقدام به به‌روزرسانی فست‌فوروارد، به‌روزرسانی‌های اجباری را بررسی خواهد کرد\&. به
\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
مخزن «دوردستی» که منبع یک عملیات واکشی یا دریافت است\&. این پارامتر می‌تواند یک نشانی اینترنتی (بخش
نشانی‌های گیت (GIT URLS)
در ادامه را ببینید) یا نام یک مخزن دوردست (بخش
مخازن دوردست (REMOTES)
در ادامه را ببینید) باشد\&.
.RE
.PP
\fI<refspec>\fR
.RS 4
مشخص می‌کند که کدام مراجع باید واکشی شوند و کدام مراجع محلی باید به‌روزرسانی گردند\&. هنگامی که هیچ
\fI<refspec>\fR
در خط فرمان مشخص نشود، در عوض مراجع مورد نظر برای واکشی از متغیرهای
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
خوانده می‌شوند (بخش "CONFIGURED REMOTE-TRACKING BRANCHES" را در
\fBgit-fetch\fR(1)
ببینید)\&.
.sp
قالب یک پارامتر
\fI<refspec>\fR
به‌صورت یک علامت مثبت اختیاری
\fB+\fR،
به‌دنبال آن منبع
\fI<src>\fR،
به‌دنبال آن یک دو نقطه
\fB:\fR،
و به‌دنبال آن مقصد
\fI<dst>\fR
است\&. زمانی که
\fI<dst>\fR
خالی باشد می‌توان از دو نقطه صرف‌نظر کرد\&.
\fI<src>\fR
معمولاً یک مرجع (ref) یا یک الگوی سراسری (glob) با یک
\fB*\fR
منفرد است که برای تطبیق مجموعه‌ای از مراجع استفاده می‌شود، اما می‌تواند یک نام شیء هگزادسیمال کاملاً نوشته‌شده نیز باشد\&.
.sp
یک
\fI<refspec>\fR
می‌تواند حاوی یک
\fB*\fR
در
\fI<src>\fR
خود باشد تا تطبیق الگوی ساده را نشان دهد\&. چنین مشخصه مرجعی مانند یک glob عمل می‌کند که با هر مرجع دارای آن الگو مطابقت دارد\&. یک
\fI<refspec>\fR
الگویی باید دقیقاً یک
\fB*\fR
در هر دو بخش
\fI<src>\fR
و
\fI<dst>\fR
داشته باشد\&. این الگو با جایگزین کردن
\fB*\fR
با محتوای تطبیق‌یافته از منبع، مراجع را به مقصد نگاشت می‌کند\&.
.sp
اگر پیشوند
\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
مجاز است یا خیر، به فضای نام مرجعی که به آن واکشی می‌شود، نوع شیء در حال واکشی، و اینکه آیا به‌روزرسانی یک فست‌فوروارد محسوب می‌شود یا خیر بستگی دارد\&. به‌طور کلی، همان قوانینی که برای push اعمال می‌شوند در واکشی نیز برقرارند؛ برای مشاهده این قوانین، به بخش
\fI<refspec>\fR\&.\&.\&.
در
\fBgit-push\fR(1)
مراجعه کنید\&. استثنائات این قوانین که مختص
\fBgit\fR
\fBfetch\fR
هستند در زیر ذکر شده‌اند\&.
.sp
تا نسخه ۲.۲۰ گیت، و برخلاف ارسال با
\fBgit-push\fR(1)،
هرگونه به‌روزرسانی در
\fBrefs/tags/*\fR
بدون علامت
\fB+\fR
در refspec (یا
\fB\-\-force\fR)
پذیرفته می‌شد\&. هنگام واکشی، ما تمام به‌روزرسانی‌های برچسب از مخزن دوردست را بدون تفکیک به‌عنوان واکشی‌های اجباری در نظر می‌گرفتیم\&. از نسخه ۲.۲۰ گیت، واکشی برای به‌روزرسانی
\fBrefs/tags/*\fR
به همان روش ارسال کار می‌کند\&. یعنی هرگونه به‌روزرسانی بدون
\fB+\fR
در refspec (یا
\fB\-\-force\fR)
رد خواهد شد\&.
.sp
برخلاف ارسال با
\fBgit-push\fR(1)،
هرگونه به‌روزرسانی خارج از
\fBrefs/\fR{tags,heads}/*
بدون
\fB+\fR
در refspec (یا
\fB\-\-force\fR)
پذیرفته می‌شود؛ خواه این کار مثلاً جابجایی یک شیء درخت با یک 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
هنگامی که مشخص است شاخه دوردستی که می‌خواهید واکشی کنید به‌طور منظم بازپیچی (rewind) و ری‌بیس می‌شود، انتظار می‌رود که سرشاخه جدید آن از سرشاخه قبلی آن (همان‌طور که در آخرین باری که واکشی کردید در شاخه ردگیری دوردست شما ذخیره شده بود) منشعب نشده باشد\&. در چنین شاخه‌هایی بهتر است از علامت
\fB+\fR
استفاده کنید تا نشان دهید که برای آن‌ها به‌روزرسانی‌های غیرفست‌فوروارد لازم خواهد بود\&. هیچ راهی برای تشخیص یا اعلام اینکه شاخه‌ای در یک مخزن با این رفتار در دسترس قرار خواهد گرفت وجود ندارد؛ کاربر دریافت‌کننده صرفاً باید بداند که این الگوی استفاده مورد انتظار برای آن شاخه است\&.
.sp .5v
.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
تفاوتی وجود دارد میان فهرست کردن چندین
\fI<refspec>\fR
به‌طور مستقیم در خط فرمان
\fBgit\fR
\fBpull\fR
و داشتن چندین مدخل
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
در پیکربندی شما برای یک
\fI<repository>\fR
و اجرای یک دستور
\fBgit\fR
\fBpull\fR
بدون هیچ پارامتر صریح
\fI<refspec>\fR\&.
موارد
\fI<refspec>\fR
که به‌صورت صریح در خط فرمان فهرست شده‌اند، همیشه پس از واکشی در شاخه جاری ادغام می‌شوند\&. به عبارت دیگر، اگر بیش از یک مرجع دوردست را فهرست کنید،
\fBgit\fR
\fBpull\fR
یک ادغام هشت‌پا (Octopus merge) ایجاد خواهد کرد\&. از سوی دیگر، اگر هیچ پارامتر صریح
\fI<refspec>\fR
در خط فرمان فهرست نکنید،
\fBgit\fR
\fBpull\fR
تمام
\fI<refspec>\fRهایی
را که در پیکربندی
\fBremote\&.\fR\fI<repository>\fR\fB\&.fetch\fR
می‌یابد واکشی می‌کند و فقط اولین
\fI<refspec>\fR
یافت‌شده را در شاخه جاری ادغام می‌نماید\&. دلیل این امر این است که ایجاد یک ادغام Octopus از مراجع دوردست به‌ندرت انجام می‌شود، در حالی که ردیابی چندین سرشاخه دوردست به‌صورت یکجا با واکشی بیش از یک مرجع معمولاً مفید است\&.
.sp .5v
.RE
.RE.SH "نشانی‌های گیت (GIT URLS)"
.sp
به‌طور کلی، نشانی‌ها (URL) حاوی اطلاعاتی درباره پروتکل انتقال، نشانی سرور دوردست و مسیر مخزن هستند\&. بسته به پروتکل انتقال، ممکن است برخی از این اطلاعات وجود نداشته باشند\&.
.sp
گیت از پروتکل‌های ssh، git، http و https پشتیبانی می‌کند (علاوه بر این، ftp و ftps می‌توانند برای واکشی استفاده شوند، اما این کار ناکارآمد و منسوخ است؛ از آن‌ها استفاده نکنید)\&.
.sp
انتقال بومی (یعنی نشانی \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 مشخص شود تا از تفسیر نادرست آن به‌عنوان یک نشانی 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) یک فایل باندل مناسب را نیز می‌پذیرند\&. به \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 می‌تواند یک مسیر، یک سرور و مسیر، یا یک رشته دلخواه شبیه نشانی باشد که توسط دستیار دوردست مربوطه فراخوانی‌شده شناسایی می‌شود\&. برای جزئیات به \fBgitremote-helpers\fR(7) مراجعه کنید\&.
.sp
اگر تعداد زیادی مخزن دوردست با نام‌های مشابه وجود دارد و می‌خواهید قالب متفاوتی برای آن‌ها استفاده کنید (به گونه‌ای که نشانی‌های مورداستفاده شما به نشانی‌هایی که کار می‌کنند بازنویسی شوند)، می‌توانید یک بخش پیکربندی به این شکل بسازید:
.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
یک نشانی مانند "work:repo\&.git" یا مانند "host\&.xz:/path/to/repo\&.git" در هر زمینه‌ای که یک نشانی می‌پذیرد به "git://git\&.host\&.xz/repo\&.git" بازنویسی خواهد شد\&.
.sp
اگر می‌خواهید نشانی‌ها را فقط برای ارسال (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
یک نشانی مانند "git://example\&.org/path/to/repo\&.git" برای ارسال‌ها به "ssh://example\&.org/path/to/repo\&.git" بازنویسی می‌شود، اما دریافت‌ها (pull) همچنان از نشانی اصلی استفاده خواهند کرد\&..SH "مخازن دوردست (REMOTES)"
.sp
می‌توان از نام یکی از موارد زیر به‌جای نشانی (URL) به‌عنوان آرگومان \fI<repository>\fR استفاده کرد:
.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 است\&. ارسال به یک مخزن دوردست بر روی تمامی pushurlهای تعریف‌شده، یا در صورت تعریف نشدن pushurl، بر روی تمامی urlهای تعریف‌شده اعمال می‌شود\&. با این حال، در صورت تعریف چندین url، عملیات واکشی (fetch) فقط از اولین url تعریف‌شده واکشی می‌کند\&.
.SS "فایل نام‌گذاری‌شده در \fB$GIT_DIR/remotes\fR (Named file in \fB$GIT_DIR/remotes\fR)"
.sp
می‌توانید نام فایلی را در \fB$GIT_DIR/remotes\fR ارائه دهید\&. نشانی موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد\&. هنگامی که در خط فرمان refspec ارائه ندهید، refspec موجود در این فایل به‌عنوان پیش‌فرض استفاده خواهد شد\&. این فایل باید دارای قالب زیر باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
        URL: one of the above URL formats
        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 (Named file in \fB$GIT_DIR/branches\fR)"
.sp
می‌توانید نام فایلی را در \fB$GIT_DIR/branches\fR ارائه دهید\&. نشانی موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد\&. این فایل باید دارای قالب زیر باشد:
.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
شاخه‌ها در گیت می‌توانند به‌صورت اختیاری یک شاخه دوردست بالادست داشته باشند\&. گیت به‌طور پیش‌فرض از شاخه بالادست برای عملیات‌های راه دور استفاده می‌کند، برای نمونه:
.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
برای ارسال به یک مخزن دوردست متفاوت از مخزنی که از آن دریافت (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،
به شما نشان می‌دهند که از زمان انشعاب شما از آن، چند کامیت به شاخه جاری و بالادست اضافه شده است؛ برای مثال "شاخه شما و
\fIorigin/main\fR
واگرا شده‌اند و به ترتیب دارای ۲ و ۳ کامیت متفاوت هستند"\&.
.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
اولین باری که یک شاخه را ارسال می‌کنید به‌طور خودکار بالادست را تنظیم خواهد کرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
دریافت (checkout) یک شاخه ردگیری دوردست با
\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) یاد می‌شود، مانند "تنظیم اطلاعات ردگیری شاخه"\&.
.sp .5v
.RE.SH "استراتژی‌های ادغام (MERGE STRATEGIES)"
.sp
سازوکار ادغام (دستورات \fBgit\fR \fBmerge\fR و \fBgit\fR \fBpull\fR) امکان انتخاب \fIاستراتژی‌های ادغام\fR پس‌زمینه را با گزینه \fB\-s\fR فراهم می‌کند\&. برخی از استراتژی‌ها همچنین می‌توانند گزینه‌های ویژه خود را دریافت کنند که می‌توان آن‌ها را با دادن آرگومان‌های \fB\-X\fR\fI<option>\fR به \fBgit\fR \fBmerge\fR و/یا \fBgit\fR \fBpull\fR ارسال کرد\&.
.PP
\fBort\fR
.RS 4
این استراتژی پیش‌فرض ادغام هنگام دریافت (pull) یا ادغام یک شاخه است\&. این استراتژی فقط می‌تواند دو سرشاخه را با استفاده از الگوریتم ادغام ۳-طرفه حل کند\&. هنگامی که بیش از یک والد مشترک وجود داشته باشد که بتوان برای ادغام ۳-طرفه از آن استفاده کرد، درختی ادغام‌شده از والدین مشترک ایجاد می‌کند و از آن به‌عنوان درخت مرجع برای ادغام ۳-طرفه بهره می‌برد\&. بر اساس آزمایش‌های انجام‌شده روی کامیت‌های ادغام واقعی برگرفته از تاریخچه توسعه هسته لینوکس ۲.۶، گزارش شده است که این روش منجر به تعارض‌های ادغام کمتر بدون ایجاد ادغام‌های نادرست می‌شود\&. علاوه بر این، این استراتژی می‌تواند ادغام‌های شامل تغییر نام را شناسایی و مدیریت کند\&. این استراتژی از کپی‌های شناسایی‌شده استفاده نمی‌کند\&. نام این الگوریتم یک کوته‌نوشت ("Ostensibly Recursive\(cqs Twin") است و از این واقعیت ناشی می‌شود که به‌عنوان جایگزینی برای الگوریتم پیش‌فرض قبلی نوشته شده است:
\fBrecursive\fR\&.
.sp
در حالتی که مسیر مورد نظر یک زیرماژول است، اگر کامیت زیرماژول استفاده‌شده در یک طرف ادغام، نواده (descendant) کامیت زیرماژول استفاده‌شده در طرف دیگر ادغام باشد، گیت تلاش می‌کند تا به آن نواده فست‌فوروارد کند\&. در غیر این صورت، گیت این حالت را به‌عنوان یک تعارض در نظر می‌گیرد و کامیت زیرماژولی را که نواده کامیت‌های دارای تعارض است (در صورت وجود) به‌عنوان راه‌حل پیشنهاد می‌کند\&.
.sp
استراتژی
\fBort\fR
می‌تواند گزینه‌های زیر را بپذیرد:
.PP
\fBours\fR
.RS 4
این گزینه تکه‌های دارای تعارض (conflicting hunks) را مجبور می‌کند تا با اولویت دادن به نسخه
\fIما (our)\fR
به‌طور خودکار و تمیز حل شوند\&. تغییرات درخت دیگر که با طرف ما تعارضی ندارند، در نتیجه ادغام منعکس می‌شوند\&. برای یک فایل باینری، کل محتوا از طرف ما گرفته می‌شود\&.
.sp
این گزینه نباید با استراتژی ادغام
\fBours\fR
اشتباه گرفته شود؛ آن استراتژی اصلاً به آنچه درخت دیگر شامل می‌شود نگاه نمی‌کند و هر کاری را که درخت دیگر انجام داده دور می‌اندازد و اعلام می‌کند که تاریخچه
\fIما\fR
شامل تمام رویدادهایی است که در آن رخ داده است\&.
.RE
.PP
\fBtheirs\fR
.RS 4
این گزینه برعکس
\fBours\fR
است؛ توجه داشته باشید که بر خلاف
\fBours\fR،
هیچ استراتژی ادغامی به نام
\fBtheirs\fR
وجود ندارد که بتوان این گزینه ادغام را با آن اشتباه گرفت\&.
.RE
.PP
\fBignore\-space\-change\fR, \fBignore\-all\-space\fR, \fBignore\-space\-at\-eol\fR, \fBignore\-cr\-at\-eol\fR
.RS 4
خطوطی را که دارای نوع مشخص‌شده تغییرات در فاصله‌های خالی (whitespace) هستند، به منظور ادغام سه‌طرفه به‌عنوان خطوط بدون تغییر در نظر می‌گیرد\&. تغییرات فاصله‌های خالی که با تغییرات دیگر در یک خط ترکیب شده باشند، نادیده گرفته نمی‌شوند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-b\fR،
\fB\-w\fR،
\fB\-\-ignore\-space\-at\-eol\fR
و
\fB\-\-ignore\-cr\-at\-eol\fR
مراجعه کنید\&.
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر نسخه
\fIآن‌ها (their)\fR
فقط تغییرات فاصله خالی را در یک خط ایجاد کرده باشد، از نسخه
\fIما (our)\fR
استفاده می‌شود؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر نسخه
\fIما\fR
تغییرات فاصله خالی ایجاد کرده باشد اما نسخه
\fIآن‌ها\fR
شامل یک تغییر اساسی باشد، از نسخه
\fIآن‌ها\fR
استفاده می‌شود؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
در غیر این صورت، ادغام به روش معمول پیش می‌رود\&.
.RE
.RE
.PP
\fBrenormalize\fR
.RS 4
این گزینه یک دریافت (check-out) و ثبت (check-in) مجازی از تمام سه مرحله هر فایلی که نیاز به ادغام سه‌طرفه دارد انجام می‌دهد\&. این گزینه برای استفاده هنگام ادغام شاخه‌هایی با فیلترهای پاکسازی متفاوت یا قوانین نرمال‌سازی انتهای خط متفاوت در نظر گرفته شده است\&. برای جزئیات به بخش "Merging branches with differing checkin/checkout attributes" در
\fBgitattributes\fR(5)
مراجعه کنید\&.
.RE
.PP
\fBno\-renormalize\fR
.RS 4
گزینه
\fBrenormalize\fR
را غیرفعال می‌کند\&. این گزینه متغیر پیکربندی
\fBmerge\&.renormalize\fR
را بازنویسی (override) می‌کند\&.
.RE
.PP
\fBfind\-renames\fR[\fB=\fR\fI<n>\fR]
.RS 4
تشخیص تغییر نام را فعال می‌کند و به‌صورت اختیاری آستانه شباهت را تنظیم می‌نماید\&. این حالت پیش‌فرض است\&. این گزینه متغیر پیکربندی
\fBmerge\&.renames\fR
را بازنویسی می‌کند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-\-find\-renames\fR
مراجعه کنید\&.
.RE
.PP
\fBrename\-threshold=\fR\fI<n>\fR
.RS 4
یک مترادف منسوخ‌شده برای
\fBfind\-renames=\fR\fI<n>\fR\&.
.RE
.PP
\fBno\-renames\fR
.RS 4
تشخیص تغییر نام را خاموش می‌کند\&. این گزینه متغیر پیکربندی
\fBmerge\&.renames\fR
را بازنویسی می‌کند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-\-no\-renames\fR
مراجعه کنید\&.
.RE
.PP
\fBhistogram\fR
.RS 4
یک مترادف منسوخ‌شده برای
\fBdiff\-algorithm=histogram\fR\&.
.RE
.PP
\fBpatience\fR
.RS 4
یک مترادف منسوخ‌شده برای
\fBdiff\-algorithm=patience\fR\&.
.RE
.PP
\fBdiff\-algorithm=\fR(\fBhistogram\fR|\fBminimal\fR|\fBmyers\fR|\fBpatience\fR)
.RS 4
از یک الگوریتم تفاضل (diff) متفاوت هنگام ادغام استفاده می‌کند، که می‌تواند به جلوگیری از ادغام‌های نادرست که ناشی از خطوط منطبق کم‌اهمیت هستند (مانند براکت‌های توابع مجزا) کمک کند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-\-diff\-algorithm\fR
مراجعه کنید\&. توجه داشته باشید که
\fBort\fR
به‌طور پیش‌فرض از
\fBdiff\-algorithm=histogram\fR
استفاده می‌کند، در حالی که تفاضل‌های معمولی در حال حاضر به‌طور پیش‌فرض از تنظیمات پیکربندی
\fBdiff\&.algorithm\fR
استفاده می‌نمایند\&.
.RE
.PP
\fBsubtree\fR[\fB=\fR\fI<path>\fR]
.RS 4
این گزینه شکل پیشرفته‌تری از استراتژی
\fIsubtree\fR
است که در آن استراتژی حدس می‌زند دو درخت چگونه باید نسبت به یکدیگر جابجا شوند تا هنگام ادغام با هم تطبیق یابند\&. در عوض، مسیر مشخص‌شده به ابتدای مسیرها اضافه می‌شود (یا از ابتدا حذف می‌شود) تا شکل دو درخت مطابقت پیدا کند\&.
.RE
.RE
.PP
\fBrecursive\fR
.RS 4
این گزینه اکنون مترادفی برای
\fBort\fR
است\&. تا نسخه 2.49.0 یک پیاده‌سازی جایگزین بود، اما در نسخه 2.50.0 تغییر مسیر یافت تا به معنای
\fBort\fR
باشد\&. استراتژی بازگشتی قبلی، استراتژی پیش‌فرض برای حل دو سرشاخه از نسخه v0.99.9k گیت تا نسخه v2.33.0 بود\&.
.RE
.PP
\fBresolve\fR
.RS 4
این استراتژی فقط می‌تواند دو سرشاخه (یعنی شاخه جاری و شاخه دیگری که از آن دریافت کرده‌اید) را با استفاده از یک الگوریتم ادغام ۳-طرفه حل کند\&. این روش تلاش می‌کند تا ابهامات ادغام ضربدری (criss-cross) را با دقت شناسایی کند\&. این استراتژی تغییر نام‌ها را مدیریت نمی‌کند\&.
.RE
.PP
\fBoctopus\fR
.RS 4
این استراتژی موارد با بیش از دو سرشاخه را حل می‌کند، اما از انجام یک ادغام پیچیده که نیاز به حل دستی داشته باشد خودداری می‌ورزد\&. این استراتژی عمدتاً برای دسته‌بندی سرشاخه‌های موضوعی (topic branches) در کنار هم استفاده می‌شود\&. این حالت، استراتژی ادغام پیش‌فرض هنگام دریافت (pull) یا ادغام بیش از یک شاخه است\&.
.RE
.PP
\fBours\fR
.RS 4
این استراتژی هر تعداد سرشاخه را حل می‌کند، اما درخت حاصل از ادغام همیشه همان سرشاخه جاری است و در عمل تمام تغییرات از سایر شاخه‌ها را نادیده می‌گیرد\&. این روش برای جایگزین کردن تاریخچه توسعه قدیمی شاخه‌های فرعی در نظر گرفته شده است\&. توجه داشته باشید که این استراتژی با گزینه
\fB\-Xours\fR
در استراتژی ادغام
\fBort\fR
متفاوت است\&.
.RE
.PP
\fBsubtree\fR
.RS 4
این یک استراتژی اصلاح‌شده از
\fBort\fR
است\&. هنگام ادغام درخت‌های A و B، اگر B متناظر با یک زیردرخت از A باشد، B ابتدا طوری تنظیم می‌شود که با ساختار درختی A مطابقت داشته باشد، به‌جای اینکه درخت‌ها در همان سطح خوانده شوند\&. این تنظیم برای درخت والد مشترک نیز انجام می‌شود\&.
.RE
.sp
در استراتژی‌هایی که از ادغام ۳-طرفه استفاده می‌کنند (از جمله گزینه پیش‌فرض، \fBort\fR)، اگر تغییری در هر دو شاخه ایجاد شود اما بعداً در یکی از شاخه‌ها بازگردانی (revert) شود، آن تغییر در نتیجه ادغام وجود خواهد داشت؛ برخی این رفتار را گیج‌کننده می‌دانند\&. این حالت رخ می‌دهد زیرا هنگام انجام ادغام، فقط سرشاخه‌ها و پایه ادغام (merge base) در نظر گرفته می‌شوند، نه تک‌تک کامیت‌ها\&. بنابراین الگوریتم ادغام، تغییر بازگردانده‌شده را اصلاً به‌عنوان هیچ تغییری در نظر نمی‌گیرد و در عوض نسخه تغییریافته را جایگزین می‌کند\&..SH "رفتار پیش‌فرض (DEFAULT BEHAVIOUR)"
.sp
اغلب افراد از \fBgit\fR \fBpull\fR بدون دادن هیچ پارامتری استفاده می‌کنند\&. از گذشته، این کار معادل اجرای \fBgit\fR \fBpull\fR \fBorigin\fR بوده است\&. با این حال، زمانی که در شاخه \fI<name>\fR هستید و پیکربندی \fBbranch\&.\fR\fI<name>\fR\fB\&.remote\fR وجود داشته باشد، آن مقدار به‌جای \fBorigin\fR استفاده می‌شود\&.
.sp
به منظور تعیین اینکه از چه نشانی‌ای برای واکشی استفاده شود، مقدار متغیر پیکربندی \fBremote\&.\fR\fI<origin>\fR\fB\&.url\fR بررسی می‌شود و اگر چنین متغیری وجود نداشته باشد، مقدار خط \fBURL:\fR در \fB$GIT_DIR/remotes/\fR\fI<origin>\fR استفاده می‌گردد\&.
.sp
به منظور تعیین اینکه هنگام اجرای دستور بدون هیچ پارامتر مشخصه مرجع (refspec) در خط فرمان، کدام شاخه‌های دوردست باید واکشی شوند (و به‌صورت اختیاری در شاخه‌های ردگیری دوردست ذخیره گردند)، مقادیر متغیر پیکربندی \fBremote\&.\fR\fI<origin>\fR\fB\&.fetch\fR بررسی می‌شوند، و اگر مقداری وجود نداشته باشد، \fB$GIT_DIR/remotes/\fR\fI<origin>\fR بررسی شده و خطوط \fBPull:\fR آن استفاده می‌شوند\&. علاوه بر قالب‌های refspec شرح‌داده‌شده در بخش گزینه‌ها، می‌توانید یک refspec با تطبیق الگو (globbing) داشته باشید که به این شکل است:
.sp
.if n \{\
.RS 4
.\}
.nf
refs/heads/*:refs/remotes/origin/*
.fi
.if n \{\
.RE
.\}
.sp
.sp
یک refspec الگویی باید سمت راست (RHS) غیرخالی داشته باشد (یعنی باید آنچه را که واکشی شده در شاخه‌های ردگیری دوردست ذخیره کند)، و سمت چپ و راست آن باید به \fB/*\fR ختم شوند\&. عبارت بالا مشخص می‌کند که تمام شاخه‌های دوردست با استفاده از شاخه‌های ردگیری دوردست در سلسله‌مراتب \fBrefs/remotes/origin/\fR تحت همان نام ردگیری می‌شوند\&.
.sp
قاعده تعیین اینکه کدام شاخه دوردست باید پس از واکشی ادغام شود، به منظور حفظ سازگاری با نسخه‌های پیشین کمی پیچیده است\&.
.sp
اگر مشخصه‌های مرجع (refspecها) به‌طور صریح در خط فرمان \fBgit\fR \fBpull\fR داده شده باشند، همگی آن‌ها ادغام می‌شوند\&.
.sp
هنگامی که هیچ refspecی در خط فرمان داده نشده باشد، \fBgit\fR \fBpull\fR از refspec موجود در پیکربندی یا \fB$GIT_DIR/remotes/\fR\fI<origin>\fR استفاده می‌کند\&. در چنین مواردی، قواعد زیر اعمال می‌شوند:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
اگر پیکربندی
\fBbranch\&.\fR\fI<name>\fR\fB\&.merge\fR
برای شاخه جاری
\fI<name>\fR
وجود داشته باشد، نام شاخه‌ای در سایت دوردست است که ادغام می‌شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
اگر refspec از نوع الگویی (globbing) باشد، چیزی ادغام نمی‌شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
در غیر این صورت، شاخه دوردست مربوط به اولین refspec ادغام می‌شود\&.
.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 pull
$ git pull origin
.fi
.if n \{\
.RE
.\}
.sp
به‌طور معمول، شاخه‌ای که ادغام می‌شود همان
\fBHEAD\fR
مخزن دوردست است، اما این انتخاب توسط گزینه‌های
\fBbranch\&.\fR\fI<name>\fR\fB\&.remote\fR
و
\fBbranch\&.\fR\fI<name>\fR\fB\&.merge\fR
تعیین می‌شود؛ برای جزئیات به
\fBgit-config\fR(1)
مراجعه کنید\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
ادغام شاخه دوردست
\fBnext\fR
در شاخه جاری:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git pull origin next
.fi
.if n \{\
.RE
.\}
.sp
این دستور یک کپی از
\fBnext\fR
را به‌طور موقت در
\fBFETCH_HEAD\fR
قرار می‌دهد و شاخه ردگیری دوردست
\fBorigin/next\fR
را به‌روزرسانی می‌کند\&. همین کار را می‌توان با فراخوانی fetch و merge انجام داد:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git fetch origin
$ git merge origin/next
.fi
.if n \{\
.RE
.\}
.sp
.RE
.sp
اگر یک عملیات دریافت (pull) انجام دادید که منجر به تعارض‌های پیچیده شد و مایلید از اول شروع کنید، می‌توانید با \fBgit\fR \fBreset\fR وضعیت را بازیابی نمایید\&.
.SH "امنیت (SECURITY)"
.sp
پروتکل‌های fetch و push طوری طراحی نشده‌اند که از سرقت داده‌های مخزن دیگر که قصد اشتراک‌گذاری آن‌ها وجود نداشته جلوگیری کنند\&. اگر داده‌های خصوصی دارید که باید از یک همتای (peer) مخرب محافظت شوند، بهترین گزینه این است که آن‌ها را در مخزن دیگری ذخیره کنید\&. این مورد هم برای کلاینت‌ها و هم برای سرورها صدق می‌کند\&. به‌ویژه، فضاهای نام روی یک سرور برای کنترل دسترسی خواندن مؤثر نیستند؛ شما باید فقط به کلاینت‌هایی دسترسی خواندن به یک فضای نام را بدهید که برای دسترسی خواندن به کل مخزن به آن‌ها اعتماد دارید\&.
.sp
بردار‌های حمله شناخته‌شده به شرح زیر هستند:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
قربانی خطوط "have" را ارسال می‌کند که شناسه (ID) اشیایی را که در اختیار دارد و صریحاً قصد اشتراک‌گذاری آن‌ها نبوده اما در صورت داشتن آن‌ها توسط همتا می‌توان برای بهینه‌سازی انتقال استفاده کرد، اعلام می‌نماید\&. مهاجم شناسه شیء X را برای سرقت انتخاب کرده و یک مرجع به X ارسال می‌کند، اما نیازی به ارسال محتوای X ندارد زیرا قربانی از قبل آن را دارد\&. اکنون قربانی بر این باور است که مهاجم شیء X را دارد و بعداً محتوای X را برای مهاجم پس می‌فرستد\&. (این حمله برای یک کلاینت ساده‌ترین حالت برای اجرا روی یک سرور است، با ایجاد مرجعی به X در فضای نامی که کلاینت به آن دسترسی دارد و سپس واکشی آن\&. محتمل‌ترین راه برای اجرای آن توسط سرور روی یک کلاینت، "ادغام" X در یک شاخه عمومی است به این امید که کاربر کارهای اضافی روی این شاخه انجام داده و بدون توجه به ادغام، آن را به سرور ارسال کند\&.)
.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 "اشکالات (BUGS)"
.sp
در حال حاضر استفاده از \fB\-\-recurse\-submodules\fR فقط می‌تواند کامیت‌های جدید را در زیرماژول‌هایی که از قبل دریافت (check out) شده‌اند واکشی کند\&. هنگامی که مثلاً بالادست یک زیرماژول جدید را در کامیت‌های تازه واکشی‌شده پروژه اصلی اضافه کرده باشد، خود زیرماژول نمی‌تواند واکشی شود و این امر دریافت آن زیرماژول را بعداً بدون نیاز به انجام مجدد واکشی غیرممکن می‌سازد\&. انتظار می‌رود این مشکل در نسخه آینده گیت برطرف شود\&.
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-fetch\fR(1)، \fBgit-merge\fR(1)، \fBgit-config\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)