'\" t
.\"     Title: git-push
.\"    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\-PUSH" "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-push \- به‌روزرسانی ارجاع‌های دوردست همراه با اشیاء مرتبط
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fBgit\fR \fBpush\fR [\fB\-\-all\fR | \fB\-\-branches\fR | \fB\-\-mirror\fR | \fB\-\-tags\fR] [\fB\-\-follow\-tags\fR] [\fB\-\-atomic\fR] [\fB\-n\fR | \fB\-\-dry\-run\fR] [\fB\-\-receive\-pack=\fR\fI<git\-receive\-pack>\fR]
         [\fB\-\-repo=\fR\fI<repository>\fR] [\fB\-f\fR | \fB\-\-force\fR] [\fB\-d\fR | \fB\-\-delete\fR] [\fB\-\-prune\fR] [\fB\-q\fR | \fB\-\-quiet\fR] [\fB\-v\fR | \fB\-\-verbose\fR]
         [\fB\-u\fR | \fB\-\-set\-upstream\fR] [\fB\-o\fR \fI<string>\fR | \fB\-\-push\-option=\fR\fI<string>\fR]
         [\fB\-\-\fR[\fBno\-\fR]\fBsigned\fR | \fB\-\-signed=\fR(\fBtrue\fR|\fBfalse\fR|\fBif\-asked\fR)]
         [\fB\-\-force\-with\-lease\fR[\fB=\fR\fI<refname>\fR[\fB:\fR\fI<expect>\fR]] [\fB\-\-force\-if\-includes\fR]]
         [\fB\-\-no\-verify\fR] [\fI<repository>\fR [\fI<refspec>\fR\&...]]
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
یک یا چند شاخه، برچسب یا سایر ارجاع‌ها را در یک یا چند مخزن دوردست از مخزن محلی شما به‌روزرسانی می‌کند و تمام داده‌های لازم را که از قبل روی مخزن دوردست وجود ندارند ارسال می‌نماید\&.
.sp
ساده‌ترین روش برای ارسال، استفاده از دستور \fBgit\fR \fBpush\fR \fI<remote>\fR \fI<branch>\fR است\&. دستور \fBgit\fR \fBpush\fR \fBorigin\fR \fBmain\fR شاخه محلی \fBmain\fR را به شاخه \fBmain\fR در مخزن دوردست با نام \fBorigin\fR ارسال می‌کند\&.
.sp
همچنین می‌توانید با استفاده از یک گروه مخزن دوردست (remote group)، به‌طور همزمان به چندین مخزن دوردست ارسال انجام دهید\&. یک گروه مخزن دوردست، فهرستی نام‌گذاری‌شده از مخازن دوردست است که از طریق \fBremotes\&.\fR\fI<name>\fR در پیکربندی گیت شما تنظیم می‌شود:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git config remotes\&.all\-remotes "origin gitlab backup"
.fi
.if n \{\
.RE
.\}
.sp
سپس دستور \fBgit\fR \fBpush\fR \fBall\-remotes\fR به نوبت به \fBorigin\fR، \fBgitlab\fR و \fBbackup\fR ارسال انجام می‌دهد، گویی که \fBgit\fR \fBpush\fR را برای هر یک به صورت جداگانه اجرا کرده باشید\&. ارسال به هر مخزن دوردست به‌طور مستقل با استفاده از پیکربندی نگاشت ارسال (push mapping) مخصوص به خود انجام می‌شود\&. یک مدخل \fBremotes\&.\fR\fI<group>\fR در فایل پیکربندی وجود دارد\&. (به \fBgit-config\fR(1) مراجعه کنید)\&.
.sp
مقدار پیش‌فرض آرگومان \fI<repository>\fR، مخزن بالادست (upstream) برای شاخه جاری است، یا اگر بالادستی پیکربندی نشده باشد، برابر با \fBorigin\fR خواهد بود\&.
.sp
برای تصمیم‌گیری درباره اینکه کدام شاخه‌ها، برچسب‌ها یا سایر ارجاع‌ها ارسال شوند، Git به ترتیب اولویت از موارد زیر استفاده می‌کند:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
آرگومان(های)
\fI<refspec>\fR
(مشخصه ارجاع) (برای مثال
\fBmain\fR
در
\fBgit\fR
\fBpush\fR
\fBorigin\fR
\fBmain\fR) یا گزینه‌های
\fB\-\-all\fR،
\fB\-\-mirror\fR یا
\fB\-\-tags\fR
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
پیکربندی
\fBremote\&.\fR\fI<name>\fR\fB\&.push\fR
برای مخزنی که به آن ارسال می‌شود
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
پیکربندی
\fBpush\&.default\fR\&.
مقدار پیش‌فرض
\fBpush\&.default=simple\fR
است که به شاخه‌ای با همان نام شاخه جاری ارسال می‌کند\&. برای اطلاعات بیشتر درباره
\fBpush\&.default\fR
به بخش
CONFIGURATION
در زیر مراجعه کنید\&.
.RE
.sp
بسته به اینکه \fBpush\&.default\fR روی چه مقداری تنظیم شده باشد، اگر بالادست (upstream) را برای شاخه جاری تنظیم نکرده باشید ممکن است اجرای \fBgit\fR \fBpush\fR با شکست مواجه شود\&. برای اطلاعات بیشتر در مورد نحوه تنظیم و استفاده از بالادست‌ها به بخش «شاخه‌های بالادست (UPSTREAM BRANCHES)» در زیر مراجعه کنید\&.
.sp
می‌توانید با تنظیم \fIقلاب‌ها (hooks)\fR در یک مخزن، کاری کنید که با هر بار ارسال (push) به آن، رویدادهای سفارشی مدنظرتان اجرا شوند\&. به مستندات \fBgit-receive-pack\fR(1) مراجعه کنید\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
\fI<repository>\fR
.RS 4
مخزن «دوردست» (remote) که مقصد عملیات ارسال (push) است\&. این پارامتر می‌تواند یک نشانی اینترنتی (URL) باشد (بخش
GIT URLS
در زیر را ببینید)، نام یک مخزن دوردست (بخش
REMOTES
در زیر را ببینید)، یا نام یک گروه دوردست (بخش
REMOTE GROUPS
در زیر را ببینید)\&.
.RE
.PP
\fI<refspec>\fR\&.\&.\&.
.RS 4
مشخص می‌کند کدام ارجاع مقصد با کدام شیء منبع به‌روزرسانی شود\&.
.sp
قالب یک مشخصه ارجاع (refspec) به‌صورت [\fB+\fR]\fI<src>\fR[\fB:\fR\fI<dst>\fR] است، برای مثال
\fBmain\fR،
\fBmain:other\fR، یا
\fBHEAD^:refs/heads/main\fR\&.
.sp
بخش
\fI<src>\fR
اغلب نام شاخهٔ محلی برای ارسال است، اما می‌تواند هر «عبارت SHA\-1» دلخواهی باشد (ببینید
\fBgitrevisions\fR(7))\&.
.sp
بخش
\fI<dst>\fR
مشخص می‌کند چه ارجاعی در سمت دوردست به‌روزرسانی شود\&. این مقدار باید نام یک شاخه، برچسب، یا ارجاع دیگری باشد، نه یک عبارت دلخواه\&.
.sp
علامت
\fB+\fR
اختیاری است و عملکردی مشابه
\fB\-\-force\fR
دارد\&.
.sp
می‌توانید یک مشخصه ارجاع را با استفاده از شکل کاملاً بسط‌یافته بنویسید (برای مثال
\fBrefs/heads/main:refs/heads/main\fR) که دقیقاً منبع و مقصد را مشخص می‌کند، یا با شکلی کوتاه‌تر (برای مثال
\fBmain\fR
یا
\fBmain:other\fR)\&. در ادامه قوانینی برای چگونگی بسط مشخصه‌های ارجاع و همچنین سایر شکل‌های ویژه مختلف مشخصه ارجاع آورده شده است:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fI<src>\fR
بدون
\fB:\fR\fI<dst>\fR
به این معنی است که همان ارجاع مشابه
\fI<src>\fR
به‌روزرسانی شود، مگر آنکه پیکربندی
\fBremote\&.\fR\fI<repository>\fR\fB\&.push\fR
مقدار
\fI<dst>\fR
متفاوتی را مشخص کرده باشد\&. برای مثال، اگر
\fBmain\fR
یک شاخه باشد، آن‌گاه مشخصه ارجاع
\fBmain\fR
به
\fBmain:refs/heads/main\fR
بسط می‌یابد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fI<dst>\fR
به‌طور بدون ابهام به ارجاعی در مخزن دوردست <repository> اشاره کند، آن‌گاه به همان ارجاع بسط داده می‌شود\&. برای مثال، اگر
\fBv1\&.0\fR
یک برچسب در مخزن دوردست باشد، آن‌گاه
\fBHEAD:v1\&.0\fR
به
\fBHEAD:refs/tags/v1\&.0\fR
بسط می‌یابد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fI<src>\fR
به ارجاعی که با
\fBrefs/heads/\fR
یا
\fBrefs/tags/\fR
شروع می‌شود تبدیل شود، آن پیشوند به ابتدای <dst> اضافه می‌شود\&. برای مثال، اگر
\fBmain\fR
یک شاخه باشد، آن‌گاه
\fBmain:other\fR
به
\fBmain:refs/heads/other\fR
بسط می‌یابد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
مشخصه ارجاع ویژه
\fB:\fR
(یا
\fB+:\fR
برای اجازه دادن به به‌روزرسانی‌های بدون جلوبردن سریع (non\-fast\-forward)) به Git دستور می‌دهد تا شاخه‌های «منطبق» را ارسال کند: به ازای هر شاخه‌ای که در سمت محلی وجود دارد، اگر شاخه‌ای با همان نام از قبل در سمت دوردست وجود داشته باشد، سمت دوردست به‌روزرسانی می‌شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fI<src>\fR
می‌تواند شامل یک
\fB*\fR
برای نشان دادن یک تطابق الگوی ساده باشد\&. این کار مانند یک glob عمل می‌کند که با هر ارجاعِ منطبق با الگو مطابقت می‌یابد\&. فقط باید یک
\fB*\fR
در هر دو بخش
\fI<src>\fR
و
\fI<dst>\fR
وجود داشته باشد\&. این ویژگی با جایگزین کردن * با محتوای تطبیق‌یافته از منبع، ارجاع‌ها را به مقصد نگاشت می‌کند\&. برای مثال،
\fBrefs/heads/*:refs/heads/*\fR
تمام شاخه‌ها را ارسال خواهد کرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
یک مشخصه ارجاع که با
\fB^\fR
شروع می‌شود، یک مشخصه ارجاع منفی است\&. این مشخصه ارجاع‌هایی را برای مستثنی شدن مشخص می‌کند\&. یک ارجاع در صورتی منطبق در نظر گرفته می‌شود که حداقل با یک مشخصه ارجاع مثبت مطابقت داشته باشد و با هیچ مشخصه ارجاع منفی مطابقت نداشته باشد\&. مشخصه‌های ارجاع منفی می‌توانند مشخصه‌های ارجاع الگویی باشند\&. آن‌ها فقط باید شامل یک
\fI<src>\fR
باشند\&. نام‌های شیء هگزادسیمال کاملاً نوشته‌شده نیز پشتیبانی نمی‌شوند\&. برای مثال،
\fBgit\fR
\fBpush\fR
\fBorigin\fR
\*(Aqrefs/heads/*\*(Aq \*(Aq^refs/heads/dev\-*\*(Aq تمام شاخه‌ها را به جز آن‌هایی که با
\fBdev\-\fR
شروع می‌شوند ارسال خواهد کرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر
\fI<src>\fR
خالی باشد، ارجاع
\fI<dst>\fR
را از مخزن دوردست حذف می‌کند\&. برای مثال،
\fBgit\fR
\fBpush\fR
\fBorigin\fR
\fB:dev\fR
شاخهٔ
\fBdev\fR
را حذف خواهد کرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBtag\fR
\fI<tag>\fR
به
\fBrefs/tags/\fR\fI<tag>\fR\fB:refs/tags/\fR\fI<tag>\fR
بسط می‌یابد\&. این از نظر فنی یک نحو ویژه برای
\fBgit\fR
\fBpush\fR
است و یک مشخصه ارجاع نیست، زیرا در
\fBgit\fR
\fBpush\fR
\fBorigin\fR
\fBtag\fR
\fBv1\&.0\fR
آرگومان‌های
\fBtag\fR
و
\fBv1\&.0\fR
جدا از هم هستند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر مشخصه ارجاع نتواند بدون ابهام بسط یابد، با خطایی که نشان می‌دهد چه چیزی تلاش شده است متوقف می‌شود و بسته به پیکربندی
\fBadvice\&.pushUnqualifiedRefname\fR
(ببینید
\fBgit-config\fR(1)) پیشنهاد می‌دهد که ممکن است می‌خواستید به کدام فضای نام refs/ ارسال کنید\&.
.RE
.RE
.sp
همهٔ به‌روزرسانی‌ها مجاز نیستند: برای جزئیات بخش PUSH RULES را در زیر ببینید\&.
.PP
\fB\-\-all\fR, \fB\-\-branches\fR
.RS 4
ارسال همه شاخه‌ها (یعنی ارجاع‌های زیر
\fBrefs/heads/\fR)؛ همراه با سایر <refspec> قابل استفاده نیست\&.
.RE
.PP
\fB\-\-prune\fR
.RS 4
شاخه‌های دوردستی را که فاقد همتای محلی هستند حذف می‌کند\&. برای مثال شاخه دوردست
\fBtmp\fR
در صورتی که شاخه محلی با همین نام دیگر وجود نداشته باشد، حذف خواهد شد\&. این گزینه همچنین از مشخصه‌های ارجاع (refspecs) تبعیت می‌کند، مثلاً
\fBgit\fR
\fBpush\fR
\fB\-\-prune\fR
\fBremote\fR
\fBrefs/heads/*:refs/tmp/*\fR
اطمینان حاصل می‌کند که ارجاع دوردست
\fBrefs/tmp/foo\fR
در صورت عدم وجود
\fBrefs/heads/foo\fR
حذف خواهد شد\&.
.RE
.PP
\fB\-\-mirror\fR
.RS 4
به جای نام بردن هر ارجاع برای ارسال، مشخص می‌کند که تمام ارجاع‌های زیر
\fBrefs/\fR
(که شامل، ولی نه محدود به
\fBrefs/heads/\fR،
\fBrefs/remotes/\fR
و
\fBrefs/tags/\fR
است) در مخزن دوردست آینه‌سازی (mirror) شوند\&. ارجاع‌های محلی تازه ایجادشده به سمت دوردست ارسال می‌شوند، ارجاع‌های محلی به‌روزرسانی‌شده به‌صورت اجباری در سمت دوردست به‌روزرسانی خواهند شد، و ارجاع‌های حذف‌شده از سمت دوردست پاک می‌شوند\&. اگر گزینه پیکربندی
\fBremote\&.\fR\fI<remote>\fR\fB\&.mirror\fR
تنظیم شده باشد، این حالت پیش‌فرض است\&.
.RE
.PP
\fB\-n\fR, \fB\-\-dry\-run\fR
.RS 4
همه کارها را به جز ارسال واقعی به‌روزرسانی‌ها انجام می‌دهد (اجرای آزمایشی)\&.
.RE
.PP
\fB\-\-porcelain\fR
.RS 4
خروجی قابل خواندن برای ماشین تولید می‌کند\&. خط وضعیت خروجی برای هر ارجاع با تب (tab) جدا شده و به جای stderr به stdout فرستاده می‌شود\&. نام‌های نمادین کامل ارجاع‌ها ارائه خواهد شد\&.
.RE
.PP
\fB\-d\fR, \fB\-\-delete\fR
.RS 4
تمام ارجاع‌های ذکرشده از مخزن دوردست حذف می‌شوند\&. این معادل قرار دادن یک دو نقطه (:) در ابتدای تمام ارجاع‌ها است\&.
.RE
.PP
\fB\-\-tags\fR
.RS 4
علاوه بر مشخصه‌های ارجاعی (refspecs) که صراحتاً در خط فرمان ذکر شده‌اند، تمام ارجاع‌های زیر
\fBrefs/tags\fR
ارسال می‌شوند\&.
.RE
.PP
\fB\-\-follow\-tags\fR
.RS 4
تمام ارجاع‌هایی را که بدون این گزینه ارسال می‌شدند ارسال می‌کند، و همچنین تگ‌های دارای یادداشت (annotated tags) در
\fBrefs/tags\fR
را که در دوردست وجود ندارند اما به کامیت‌هایی (commit-ish) اشاره می‌کنند که از طریق ارجاع‌های در حال ارسال قابل دستیابی هستند، ارسال می‌کند\&. این رفتار را می‌توان با متغیر پیکربندی
\fBpush\&.followTags\fR
نیز مشخص کرد\&. برای اطلاعات بیشتر،
\fBpush\&.followTags\fR
را در
\fBgit-config\fR(1)
ببینید\&.
.RE
.PP
\fB\-\-signed\fR, \fB\-\-no\-signed\fR, \fB\-\-signed=\fR(\fBtrue\fR|\fBfalse\fR|\fBif\-asked\fR)
.RS 4
امضای GPG برای درخواست ارسال به‌منظور به‌روزرسانی ارجاع‌ها در سمت گیرنده، تا امکان بررسی آن توسط قلاب‌ها (hooks) و/یا ثبت در گزارش فراهم شود\&. مقادیر ممکن عبارتند از:
.PP
\fBfalse\fR, \fB\-\-no\-signed\fR
.RS 4
هیچ تلاشی برای امضا انجام نخواهد شد\&.
.RE
.PP
\fBtrue\fR, \fB\-\-signed\fR
.RS 4
اگر سرور از ارسال‌های امضاشده پشتیبانی نکند، ارسال با شکست مواجه خواهد شد\&.
.RE
.PP
\fBif\-asked\fR
.RS 4
تنها در صورتی امضا می‌شود که سرور از ارسال‌های امضاشده پشتیبانی کند\&. همچنین در صورت شکست فراخوانی واقعی
\fBgpg\fR
\fB\-\-sign\fR
ارسال با شکست مواجه خواهد شد\&. برای جزئیات در سمت گیرنده،
\fBgit-receive-pack\fR(1)
را ببینید\&.
.RE
.RE
.PP
\fB\-\-atomic\fR, \fB\-\-no\-atomic\fR
.RS 4
در صورت وجود، از یک تراکنش اتمیک (atomic transaction) در سمت دوردست استفاده می‌کند\&. یا تمام ارجاع‌ها به‌روزرسانی می‌شوند، یا در صورت بروز خطا، هیچ ارجاعی به‌روزرسانی نخواهد شد\&. اگر سرور از ارسال‌های اتمیک پشتیبانی نکند، ارسال با شکست مواجه خواهد شد\&.
.RE
.PP
\fB\-o\fR \fI<option>\fR, \fB\-\-push\-option=\fR\fI<option>\fR
.RS 4
رشته داده‌شده را به سرور منتقل می‌کند، که آن را به قلاب pre\-receive و همچنین post\-receive ارسال می‌نماید\&. رشته داده‌شده نباید شامل نویسه
\fINUL\fR
یا
\fILF\fR
باشد\&. هنگامی که چندین
\fB\-\-push\-option=\fR\fI<option>\fR
داده شود، همگی به همان ترتیبی که در خط فرمان ذکر شده‌اند به سمت دیگر فرستاده می‌شوند\&. در صورتی که هیچ
\fB\-\-push\-option=\fR\fI<option>\fR
از خط فرمان داده نشود، مقادیر متغیر پیکربندی
\fBpush\&.pushOption\fR
به‌جای آن استفاده می‌شود\&.
.RE
.PP
\fB\-\-receive\-pack=\fR\fI<git\-receive\-pack>\fR, \fB\-\-exec=\fR\fI<git\-receive\-pack>\fR
.RS 4
مسیر برنامه
\fIgit\-receive\-pack\fR
در سمت دوردست\&. گاهی هنگام ارسال به یک مخزن دوردست از طریق ssh و زمانی که برنامه را در دایرکتوری موجود در
\fB$PATH\fR
پیش‌فرض ندارید، مفید است\&.
.RE
.PP
\fB\-\-force\-with\-lease\fR, \fB\-\-no\-force\-with\-lease\fR, \fB\-\-force\-with\-lease=\fR\fI<refname>\fR, \fB\-\-force\-with\-lease=\fR\fI<refname>\fR\fB:\fR\fI<expect>\fR
.RS 4
معمولاً،
\fBgit\fR
\fBpush\fR
از به‌روزرسانی ارجاع دوردستی که جد (ancestor) ارجاع محلیِ استفاده‌شده برای بازنویسی آن نباشد، خودداری می‌کند\&.
.sp
این گزینه در صورتی که مقدار فعلی ارجاع دوردست همان مقدار مورد انتظار باشد، این محدودیت را لغو می‌کند\&. در غیر این صورت
\fBgit\fR
\fBpush\fR
با شکست مواجه می‌شود\&.
.sp
تصور کنید باید چیزی را که قبلاً منتشر کرده‌اید بازپایه‌ریزی (rebase) کنید\&. برای جایگزین کردن تاریخچه‌ای که قبلاً منتشر کرده‌اید با تاریخچه بازپایه‌ریزی‌شده، باید قانون «الزام به جلوبردن سریع» (must fast\-forward) را دور بزنید\&. اگر در زمان بازپایه‌ریزی شما، فرد دیگری کارهای خود را بر روی تاریخچه اصلی شما بنا کرده باشد، نوک شاخه در دوردست ممکن است با کامیت آن‌ها به جلو رفته باشد، و ارسال کورکورانه با
\fB\-\-force\fR
باعث از دست رفتن کار آن‌ها خواهد شد\&.
.sp
این گزینه به شما امکان می‌دهد اعلام کنید انتظار دارید تاریخچه‌ای که در حال به‌روزرسانی آن هستید همان چیزی باشد که بازپایه‌ریزی کرده‌اید و می‌خواهید جایگزین کنید\&. اگر ارجاع دوردست همچنان به کامیتی اشاره می‌کند که شما مشخص کرده‌اید، می‌توانید مطمئن باشید که هیچ فرد دیگری تغییری در ارجاع ایجاد نکرده است\&. این مانند گرفتن یک «اجاره / پیمان» (lease) روی ارجاع بدون قفل کردن صریح آن است، و ارجاع دوردست تنها در صورتی به‌روزرسانی می‌شود که «اجاره / پیمان» همچنان معتبر باشد\&.
.sp
\fB\-\-force\-with\-lease\fR
به‌تنهایی و بدون مشخص کردن جزئیات، با الزام به اینکه مقدار فعلی ارجاع‌های دوردست برابر با شاخه ردیاب دوردستی (remote\-tracking branch) باشد که برای آن‌ها داریم، از تمام ارجاع‌های دوردستی که قرار است به‌روزرسانی شوند محافظت می‌کند\&.
.sp
\fB\-\-force\-with\-lease=\fR\fI<refname>\fR،
بدون مشخص کردن مقدار مورد انتظار، در صورتی که
\fI<refname>\fR
قرار باشد به‌روزرسانی شود، (به‌تنهایی) از آن محافظت می‌کند؛ با الزام به اینکه مقدار فعلی آن برابر با شاخه ردیاب دوردستی باشد که برای آن داریم\&.
.sp
\fB\-\-force\-with\-lease=\fR\fI<refname>\fR\fB:\fR\fI<expect>\fR
در صورتی که
\fI<refname>\fR
قرار باشد به‌روزرسانی شود، (به‌تنهایی) از آن محافظت می‌کند؛ با الزام به اینکه مقدار فعلی آن برابر با مقدار مشخص‌شده
\fI<expect>\fR
باشد (که مجاز است با شاخه ردیاب دوردستی که برای refname داریم متفاوت باشد، یا حتی هنگام استفاده از این قالب نیازی به داشتن چنین شاخه ردیاب دوردستی نداریم)\&. اگر
\fI<expect>\fR
رشته خالی باشد، در این صورت ارجاع نام‌برده‌شده نباید از قبل وجود داشته باشد\&.
.sp
توجه داشته باشید که تمام حالت‌ها به جز
\fB\-\-force\-with\-lease=\fR\fI<refname>\fR\fB:\fR\fI<expect>\fR
که مقدار فعلی مورد انتظار ارجاع را صراحتاً مشخص می‌کند، همچنان آزمایشی هستند و با کسب تجربه بیشتر از این ویژگی، ممکن است معناشناسی آن‌ها تغییر کند\&.
.sp
\fB\-\-no\-force\-with\-lease\fR
تمام موارد قبلی
\fB\-\-force\-with\-lease\fR
در خط فرمان را لغو خواهد کرد\&.
.sp
یک نکته کلی درباره ایمنی: ارائه این گزینه بدون مقدار مورد انتظار، یعنی به صورت
\fB\-\-force\-with\-lease\fR
یا
\fB\-\-force\-with\-lease=\fR\fI<refname>\fR،
با هر چیزی که به طور ضمنی
\fBgit\fR
\fBfetch\fR
را در پس‌زمینه روی مخزن دوردستِ مقصد اجرا می‌کند (برای نمونه اجرای
\fBgit\fR
\fBfetch\fR
\fBorigin\fR
روی مخزن شما در یک cronjob)، تداخل بسیار نامناسبی ایجاد می‌کند\&.
.sp
محافظتی که این گزینه نسبت به
\fB\-\-force\fR
ارائه می‌دهد این است که اطمینان حاصل می‌کند تغییرات بعدی که کار شما بر پایه آن‌ها نبوده است پایمال (clobber) نشوند، اما اگر فرآیندی در پس‌زمینه در حال به‌روزرسانی ارجاع‌ها باشد، این حفاظت به سادگی بی‌اثر می‌شود\&. ما هیچ چیزی جز اطلاعات ردیابی دوردست نداریم که به عنوان معیار اکتشافی برای ارجاع‌هایی که انتظار می‌رود دیده‌اید و مایل به بازنویسی آن‌ها هستید به آن اتکا کنیم\&.
.sp
اگر ویرایشگر شما یا سامانه دیگری
\fBgit\fR
\fBfetch\fR
را در پس‌زمینه برای شما اجرا می‌کند، یک راه برای کاهش این اثر این است که صرفاً یک دوردست (remote) دیگر تنظیم کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
git remote add origin\-push $(git config remote\&.origin\&.url)
git fetch origin\-push
.fi
.if n \{\
.RE
.\}
.sp
اکنون هنگامی که فرآیند پس‌زمینه
\fBgit\fR
\fBfetch\fR
\fBorigin\fR
را اجرا می‌کند، ارجاع‌ها روی
\fBorigin\-push\fR
به‌روزرسانی نخواهند شد، و بنابراین دستوراتی مانند:
.sp
.if n \{\
.RS 4
.\}
.nf
git push \-\-force\-with\-lease origin\-push
.fi
.if n \{\
.RE
.\}
.sp
با شکست مواجه خواهند شد مگر اینکه به‌صورت دستی
\fBgit\fR
\fBfetch\fR
\fBorigin\-push\fR
را اجرا کنید\&. البته این روش نیز در صورت اجرای چیزی که
\fBgit\fR
\fBfetch\fR
\fB\-\-all\fR
را اجرا کند کاملاً بی‌اثر می‌شود؛ در آن صورت باید یا آن را غیرفعال کنید یا کار خسته‌کننده‌تری مانند این انجام دهید:
.sp
.if n \{\
.RS 4
.\}
.nf
git fetch              # update \*(Aqmaster\*(Aq from remote
git tag base master    # mark our base point
git rebase \-i master   # rewrite some commits
git push \-\-force\-with\-lease=master:base master:master
.fi
.if n \{\
.RE
.\}
.sp
یعنی یک تگ
\fBbase\fR
برای نسخه‌هایی از کد بالادست که دیده‌اید و مایل به بازنویسی آن‌ها هستید ایجاد کنید، سپس تاریخچه را بازنویسی نمایید، و در نهایت در صورتی که نسخه دوردست همچنان روی
\fBbase\fR
باشد، تغییرات را با اجبار به
\fBmaster\fR
ارسال کنید، صرف‌نظر از اینکه
\fBremotes/origin/master\fR
محلی شما در پس‌زمینه به چه چیزی به‌روزرسانی شده است\&.
.sp
به عنوان روش جایگزین، مشخص کردن
\fB\-\-force\-if\-includes\fR
به عنوان یک گزینه کمکی همراه با
\fB\-\-force\-with\-lease\fR[\fB=\fR\fI<refname>\fR]
(یعنی بدون مشخص کردن اینکه ارجاع در سمت دوردست دقیقاً باید به چه کامیتی اشاره کند، یا از کدام ارجاع‌ها در سمت دوردست محافظت می‌شود) در زمان «ارسال» (push)، قبل از اجازه دادن به به‌روزرسانی اجباری بررسی خواهد کرد که آیا به‌روزرسانی‌های ارجاع‌های ردیاب دوردست که ممکن است به طور ضمنی در پس‌زمینه به‌روز شده باشند، به صورت محلی ادغام شده‌اند یا خیر\&.
.RE
.PP
\fB\-f\fR, \fB\-\-force\fR
.RS 4
معمولاً،
\fBgit\fR
\fBpush\fR
از به‌روزرسانی شاخه‌ای که نیاکان کامیت در حال ارسال نیست خودداری می‌کند\&.
.sp
این فلگ آن بررسی، سایر بررسی‌های ایمنی در PUSH RULES در زیر، و بررسی‌های
\fB\-\-force\-with\-lease\fR
را غیرفعال می‌کند\&. این گزینه می‌تواند باعث شود مخزن دوردست کامیت‌هایی را از دست بدهد؛ با احتیاط از آن استفاده کنید\&.
.sp
توجه داشته باشید که
\fB\-\-force\fR
برای تمام ارجاع‌های در حال ارسال اعمال می‌شود، بنابراین استفاده از آن هنگامی که
\fBpush\&.default\fR
روی
\fBmatching\fR
تنظیم شده باشد یا با چندین مقصد ارسال که با
\fBremote\&.\fR\fI<name>\fR\fB\&.push\fR
پیکربندی شده‌اند، ممکن است ارجاع‌هایی غیر از شاخه جاری را بازنویسی کند (از جمله ارجاع‌های محلی که کاملاً عقب‌تر از همتای دوردست خود هستند)\&. برای اجبار ارسال تنها به یک شاخه، از یک
\fB+\fR
در ابتدای مشخصه ارجاع (refspec) برای ارسال استفاده کنید (به عنوان مثال
\fBgit\fR
\fBpush\fR
\fBorigin\fR
\fB+master\fR
برای اجبار ارسال به شاخه
\fBmaster\fR)\&.
برای جزئیات بیشتر بخش
\fI<refspec>\fR\&.\&.\&.
در بالا را ببینید\&.
.RE
.PP
\fB\-\-force\-if\-includes\fR, \fB\-\-no\-force\-if\-includes\fR
.RS 4
به‌روزرسانی را تنها در صورتی اجبار می‌کند که نوک ارجاع ردیابی دوردست به‌صورت محلی ادغام شده باشد\&.
.sp
این گزینه بررسی‌ای را فعال می‌کند که بررسی می‌نماید آیا نوک ارجاع ردیابی دوردست از یکی از مدخل‌های «reflog» شاخه محلی که برای بازنویسی بر پایه آن بوده قابل دستیابی است یا خیر\&. این بررسی با رد کردن به‌روزرسانی اجباری در صورتی که چنین نباشد، تضمین می‌کند که هرگونه به‌روزرسانی از سمت دوردست به‌صورت محلی ادغام شده باشد\&.
.sp
اگر این گزینه بدون تعیین
\fB\-\-force\-with\-lease\fR
ارسال شود، یا همراه با
\fB\-\-force\-with\-lease=\fR\fI<refname>\fR\fB:\fR\fI<expect>\fR
مشخص شود، یک «no\-op» (بی‌اثر) خواهد بود\&.
.sp
مشخص کردن
\fB\-\-no\-force\-if\-includes\fR
این رفتار را غیرفعال می‌کند\&.
.RE
.PP
\fB\-\-repo=\fR\fI<repository>\fR
.RS 4
این گزینه معادل آرگومان
\fI<repository>\fR
است\&. اگر هر دو مشخص شده باشند، آرگومان خط فرمان اولویت دارد\&.
.RE
.PP
\fB\-u\fR, \fB\-\-set\-upstream\fR
.RS 4
به ازای هر شاخه‌ای که به‌روز است یا با موفقیت ارسال شده است، یک ارجاع بالادست (ردیابی) اضافه می‌کند که توسط دستور بدون آرگومان
\fBgit-pull\fR(1)
و سایر دستورها استفاده می‌شود\&. برای اطلاعات بیشتر،
\fBbranch\&.\fR\fI<name>\fR\fB\&.merge\fR
را در
\fBgit-config\fR(1)
ببینید\&.
.RE
.PP
\fB\-\-thin\fR, \fB\-\-no\-thin\fR
.RS 4
این گزینه‌ها به
\fBgit-send-pack\fR(1)
پاس داده می‌شوند\&. یک انتقال باریک (thin transfer) مقدار داده‌های ارسالی را به میزان قابل توجهی کاهش می‌دهد هنگامی که فرستنده و گیرنده اشیاء مشترک زیادی داشته باشند\&. مقدار پیش‌فرض
\fB\-\-thin\fR
است\&.
.RE
.PP
\fB\-q\fR, \fB\-\-quiet\fR
.RS 4
تمام خروجی‌ها را سرکوب می‌کند، از جمله فهرست ارجاع‌های به‌روزرسانی‌شده، مگر اینکه خطایی رخ دهد\&. وضعیت پیشرفت به جریان خطای استاندارد گزارش نمی‌شود\&.
.RE
.PP
\fB\-v\fR, \fB\-\-verbose\fR
.RS 4
اجرا با نمایش جزئیات کامل\&.
.RE
.PP
\fB\-\-progress\fR
.RS 4
وضعیت پیشرفت به‌طور پیش‌فرض در صورت متصل بودن به یک ترمینال روی جریان خطای استاندارد گزارش می‌شود، مگر اینکه
\fB\-q\fR
مشخص شده باشد\&. این فلگ وضعیت پیشرفت را حتی اگر جریان خطای استاندارد به یک ترمینال هدایت نشده باشد اجبار می‌کند\&.
.RE
.PP
\fB\-\-no\-recurse\-submodules\fR, \fB\-\-recurse\-submodules=\fR(\fBcheck\fR|\fBon\-demand\fR|\fBonly\fR|\fBno\fR)
.RS 4
می‌تواند برای اطمینان از این مورد استفاده شود که تمام کامیت‌های زیرماژول استفاده‌شده توسط بازبینی‌های در حال ارسال، روی یک شاخه ردیابی دوردست در دسترس باشند\&. مقادیر ممکن عبارتند از:
.PP
\fBcheck\fR
.RS 4
گیت بررسی خواهد کرد که تمام کامیت‌های زیرماژول تغییریافته در بازبینی‌های در حال ارسال، روی حداقل یکی از دوردست‌های زیرماژول در دسترس باشند\&. در صورت مفقود بودن هر کامیت، عملیات ارسال لغو شده و با وضعیت غیرصفر خارج می‌شود\&.
.RE
.PP
\fBon\-demand\fR
.RS 4
تمام زیرماژول‌هایی که در بازبینی‌های در حال ارسال تغییر کرده‌اند ارسال خواهند شد\&. اگر
\fBon\-demand\fR
نتواند تمام بازبینی‌های لازم را ارسال کند، عملیات نیز لغو شده و با وضعیت غیرصفر خارج می‌شود\&.
.RE
.PP
\fBonly\fR
.RS 4
تمام زیرماژول‌ها ارسال خواهند شد در حالی که ابرپروژه (superproject) ارسال‌نشده باقی می‌ماند\&.
.RE
.PP
\fBno\fR
.RS 4
متغیر پیکربندی
\fBpush\&.recurseSubmodules\fR
را در زمانی که نیازی به بازگشت در زیرماژول‌ها نیست لغو می‌کند\&. مشابه استفاده از
\fB\-\-no\-recurse\-submodules\fR
است\&.
.RE
.sp
هنگام استفاده از
\fBon\-demand\fR
یا
\fBonly\fR،
اگر یک زیرماژول دارای پیکربندی
\fBpush\&.recurseSubmodules=\fR(\fBon\-demand\fR|\fBonly\fR)
یا
\fBsubmodule\&.recurse\fR
باشد، بازگشت بیشتری رخ خواهد داد\&. در این حالت، با
\fBonly\fR
مانند
\fBon\-demand\fR
رفتار می‌شود\&.
.RE
.PP
\fB\-\-verify\fR, \fB\-\-no\-verify\fR
.RS 4
قلاب pre\-push را تغییر وضعیت می‌دهد (ببینید
\fBgithooks\fR(5))\&.
حالت پیش‌فرض
\fB\-\-verify\fR
است که به قلاب این امکان را می‌دهد تا از ارسال جلوگیری کند\&. با
\fB\-\-no\-verify\fR،
قلاب به‌طور کامل دور زده می‌شود\&.
.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
.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
نام یکی از موارد زیر می‌تواند به عنوان آرگومان \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) را از خط فرمان حذف کنید زیرا هر یک از آن‌ها حاوی یک مشخصه ارجاع هستند که گیت به‌طور پیش‌فرض از آن استفاده خواهد کرد\&.
.SS "مخزن دوردست نام‌گذاری‌شده در فایل پیکربندی"
.sp
می‌توانید نام یک مخزن دوردست را که پیش‌تر با استفاده از \fBgit\-remote\fR(1)، \fBgit\-config\fR(1) یا حتی با ویرایش دستی فایل \fB$GIT_DIR/config\fR پیکربندی کرده‌اید، مشخص کنید\&. نشانی (URL) این مخزن دوردست برای دسترسی به مخزن استفاده خواهد شد\&. اگر در خط فرمان مشخصه ارجاعی را ارائه ندهید، مشخصه ارجاع این مخزن دوردست به‌طور پیش‌فرض استفاده خواهد شد\&. مدخل مربوطه در فایل پیکربندی به این صورت خواهد بود:
.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) موجود در این فایل برای دسترسی به مخزن استفاده خواهد شد\&. اگر در خط فرمان مشخصه ارجاعی را ارائه ندهید، مشخصه ارجاع موجود در این فایل به عنوان پیش‌فرض استفاده خواهد شد\&. این فایل باید قالب زیر را داشته باشد:
.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"
.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
بسته به عملیات، اگر مشخصه ارجاعی را در خط فرمان ارائه ندهید، گیت از یکی از مشخصه‌های ارجاع زیر استفاده خواهد کرد\&. \fI<branch>\fR نام این فایل در \fB$GIT_DIR/branches\fR است و مقدار پیش‌فرض \fI<head>\fR برابر با \fBmaster\fR می‌باشد\&.
.sp
\fBgit fetch\fR استفاده می‌کند از:
.sp
.if n \{\
.RS 4
.\}
.nf
        refs/heads/<head>:refs/heads/<branch>
.fi
.if n \{\
.RE
.\}
.sp
.sp
\fBgit push\fR استفاده می‌کند از:
.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،
به شما نشان می‌دهند که از زمان انشعاب گرفتن از شاخه بالادست، چه تعداد کامیت به شاخه جاری شما و شاخه بالادست اضافه شده است؛ برای مثال "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
در نخستین باری که یک شاخه را ارسال می‌کنید، شاخه بالادست را به‌طور خودکار تنظیم خواهد کرد\&.
.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 "گروه‌های دوردست (REMOTE GROUPS)"
.sp
یک گروه دوردست، فهرستی نام‌گذاری‌شده از مخازن دوردست است که از طریق \fBremotes\&.\fR\fI<name>\fR در پیکربندی گیت شما تنظیم می‌شود:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git config remotes\&.all\-remotes "r1 r2 r3"
.fi
.if n \{\
.RE
.\}
.sp
هنگامی که یک نام گروه به عنوان آرگومان \fI<repository>\fR داده می‌شود، ارسال به نوبت برای هر یک از مخازن دوردستِ عضو گروه انجام می‌گیرد\&. اصل حاکم این است که:
.sp
.if n \{\
.RS 4
.\}
.nf
git push <options> all\-remotes <args>
.fi
.if n \{\
.RE
.\}
.sp
دقیقاً معادل است با:
.sp
.if n \{\
.RS 4
.\}
.nf
git push <options> r1 <args>
git push <options> r2 <args>
\&.\&.\&.
git push <options> rN <args>
.fi
.if n \{\
.RE
.\}
.sp
که در آن r1، r2، \&...، rN اعضای \fBall\-remotes\fR هستند\&. هیچ رفتار خاصی اضافه یا حذف نمی‌شود \(em گروه صرفاً یک میانبر برای اجرای جداگانه همان دستور push در برابر هر مخزن دوردست عضو است\&.
.sp
هنگام ارسال به گروهی متشکل از بیش از یک مخزن دوردست، گیت به ترتیب برای هر مخزن دوردست عضو یک زیرفرآیند مجزای \fBgit\fR \fBpush\fR ایجاد می‌کند\&. هر زیرفرآیند همان پرچم‌ها و مشخصه‌های ارجاع مربوط به فراخوانی اولیه را دریافت می‌کند\&. این بدان معناست که نگاشت‌های ارسال اختصاصی هر مخزن دوردست که از طریق \fBremote\&.\fR\fI<name>\fR\fB\&.push\fR پیکربندی شده‌اند و حالت آینه‌ای (\fBremote\&.\fR\fI<name>\fR\fB\&.mirror\fR) به‌طور مستقل برای هر مخزن دوردست ارزیابی می‌شوند، و یک مخزن دوردست آینه‌ای در گروه نمی‌تواند بر رفتار ارسال سایر مخازن دوردست غیرآینه‌ای در همان گروه تأثیر بگذارد\&.
.sp
گزینه \fB\-\-atomic\fR برای ارسال‌های گروهی پشتیبانی نمی‌شود، زیرا اتمیک بودن (اتمام یکپارچه) تنها در قالب یک اتصال انتقال واحد به یک مخزن دوردست منفرد قابل تضمین است\&. اگر \fB\-\-atomic\fR همراه با یک نام گروه ترکیب شود، گیت فراخوانی را با یک خطا رد خواهد کرد\&.
.sp
اگر هر یک از مخازن دوردستِ عضو با شکست مواجه شود، خواه به دلیل رد شدن ارسال (مانند یک به‌روزرسانی غیر fast\-forward یا هوک سمت سرور که یک ارجاع را رد می‌کند) یا خطای اتصال (مانند عدم وجود مخزن، شکست در احراز هویت، یا در دسترس نبودن شبکه)، گیت خطا را گزارش داده و به ارسال به باقی مخازن دوردست در گروه ادامه می‌دهد\&. در صورتی که ارسال به هر یک از اعضا ناموفق باشد، کد خروج کلی غیرصفر خواهد بود\&.
.sp
این بدان معناست که کاربر مسئول اطمینان از معقول بودن توالی ارسال‌های جداگانه است\&. اگر \fBgit\fR \fBpush\fR \fBr1\fR برای مجموعه‌ای معین از گزینه‌ها و آرگومان‌ها با شکست مواجه شود، آن‌گاه \fBgit\fR \fBpush\fR \fBall\-remotes\fR نیز هنگام رسیدن به r1 به همان شیوه با شکست مواجه خواهد شد\&. ارسال گروهی کار خاصی برای به موفقیت رساندن یک ارسالِ انفرادیِ ناموفق انجام نمی‌دهد\&.
.SH "خروجی (OUTPUT)"
.sp
خروجی «git push» به روش انتقال مورد استفاده بستگی دارد؛ این بخش خروجی را هنگام ارسال بر روی پروتکل گیت (چه به صورت محلی و چه از طریق ssh) توضیح می‌دهد\&.
.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> \et <from>:<to> \et <summary> (<reason>)
.fi
.if n \{\
.RE
.\}
.sp
.sp
وضعیت ارجاع‌های به‌روز تنها در صورتی نمایش داده می‌شود که گزینه \fB\-\-porcelain\fR یا \fB\-\-verbose\fR استفاده شده باشد\&.
.PP
\fI<flag>\fR
.RS 4
یک نویسه تک که نشان‌دهنده وضعیت ارجاع است:
.PP
(space)
.RS 4
برای یک جلوبردن سریع (fast\-forward) که با موفقیت ارسال شده است؛
.RE
.PP
\fB+\fR
.RS 4
برای یک به‌روزرسانی اجباری موفق؛
.RE
.PP
\fB\-\fR
.RS 4
برای یک ارجاع با موفقیت حذف‌شده؛
.RE
.PP
\fB*\fR
.RS 4
برای یک ارجاع جدید که با موفقیت ارسال شده است؛
.RE
.PP
!
.RS 4
برای ارجاعی که رد شده یا ارسال آن ناموفق بوده است؛ و
.RE
.PP
\fB=\fR
.RS 4
برای ارجاعی که به‌روز بوده و نیازی به ارسال نداشته است\&.
.RE
.RE
.PP
\fI<summary>\fR
.RS 4
برای یک ارجاع با موفقیت ارسال‌شده، خلاصه، مقادیر قدیم و جدید ارجاع را در قالبی مناسب برای استفاده به عنوان آرگومان برای
\fBgit\fR
\fBlog\fR
نشان می‌دهد (این مقدار در بیشتر موارد
\fI<old>\fR\fB\&.\&.\fR\fI<new>\fR
است و برای به‌روزرسانی‌های اجباری جلوبردن غیرسریع،
\fI<old>\fR\fB\&.\&.\&.\fR\fI<new>\fR
می‌باشد)\&.
.sp
برای یک به‌روزرسانی ناموفق، جزئیات بیشتری ارائه می‌شود:
.PP
rejected
.RS 4
گیت اصلاً تلاشی برای ارسال ارجاع نکرد، معمولاً به این دلیل که یک جلوبردن سریع (fast\-forward) نیست و شما به‌روزرسانی را اجبار نکرده‌اید\&.
.RE
.PP
remote rejected
.RS 4
سمت دوردست به‌روزرسانی را رد کرد\&. معمولاً به دلیل وجود یک قلاب (hook) در سمت دوردست ایجاد می‌شود، یا به این دلیل که مخزن دوردست یکی از گزینه‌های ایمنی زیر را فعال دارد:
\fBreceive\&.denyCurrentBranch\fR
(برای ارسال‌ها به شاخه‌ای که دریافت/بررسی شده است)،
\fBreceive\&.denyNonFastForwards\fR
(برای به‌روزرسانی‌های اجباری جلوبردن غیرسریع)،
\fBreceive\&.denyDeletes\fR
یا
\fBreceive\&.denyDeleteCurrent\fR\&. به
\fBgit-config\fR(1)
مراجعه کنید\&.
.RE
.PP
remote failure
.RS 4
سمت دوردست به‌روزرسانی موفق ارجاع را گزارش نکرد، شاید به دلیل خطای موقت در سمت دوردست، قطعی در اتصال شبکه یا سایر خطاهای گذرا\&.
.RE
.RE
.PP
from
.RS 4
نام ارجاع محلی در حال ارسال، منهای پیشوند
\fBrefs/\fR\fI<type>\fR\fB/\fR
آن\&. در صورت حذف، نام ارجاع محلی حذف می‌شود\&.
.RE
.PP
to
.RS 4
نام ارجاع دوردست در حال به‌روزرسانی، منهای پیشوند
\fBrefs/\fR\fI<type>\fR\fB/\fR
آن\&.
.RE
.PP
reason
.RS 4
توضیحی خوانا برای انسان\&. در مورد ارجاع‌های با موفقیت ارسال‌شده، نیازی به توضیح نیست\&. برای یک ارجاع ناموفق، دلیل شکست توصیف می‌شود\&.
.RE
.SH "قوانین ارسال (PUSH RULES)"
.sp
به عنوان یک قابلیت ایمنی، دستور \fBgit\fR \fBpush\fR تنها انواع خاصی از به‌روزرسانی‌ها را مجاز می‌داند تا از دست رفتن تصادفی داده‌ها در مخزن دوردست جلوگیری شود\&.
.sp
از آنجا که شاخه‌ها و برچسب‌ها برای کاربردهای متفاوتی در نظر گرفته شده‌اند، قوانین ایمنی برای ارسال به یک شاخه با قوانین ارسال به یک برچسب متفاوت است\&. در قوانین زیر «به‌روزرسانی» به معنای هرگونه تغییر به جز حذف و ایجاد است\&. حذف و ایجاد همیشه مجاز است، مگر زمانی که توسط پیکربندی یا قلاب‌ها ممنوع شده باشد\&.
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
اگر مقصد ارسال یک
\fBشاخه\fR
(\fBrefs/heads/*\fR)
باشد: تنها به‌روزرسانی‌های جلوبردن سریع (fast\-forward) مجاز هستند، به این معنی که مقصد باید یک نیا (ancestor) از کامیت مبدأ باشد\&. مبدأ باید یک کامیت باشد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
اگر مقصد ارسال یک
\fBبرچسب\fR
(\fBrefs/tags/*\fR)
باشد: تمامی به‌روزرسانی‌ها رد خواهند شد\&. مبدأ می‌تواند هر شیئی باشد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
اگر مقصد ارسال شاخه یا برچسب نباشد:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر مبدأ یک شیء درخت (tree) یا بلاب (blob) باشد، هرگونه به‌روزرسانی رد خواهد شد
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر مبدأ یک شیء برچسب یا کامیت باشد، هر به‌روزرسانی جلوبردن سریع (fast\-forward) مجاز است، حتی در مواردی که آنچه به جلو برده می‌شود یک کامیت نیست، بلکه یک شیء برچسب است که برحسب اتفاق به کامیت جدیدی اشاره دارد که جلوبردن سریعِ کامیتی است که آخرین برچسب (یا کامیت) جایگزین‌شده به آن اشاره می‌کرد\&. جایگزین کردن یک برچسب با یک برچسب کاملاً متفاوت نیز در صورتی که به همان کامیت اشاره کند مجاز است، و همچنین ارسال یک برچسب پوسته‌کنده (peeled tag)، یعنی ارسال کامیتی که شیء برچسب موجود به آن اشاره دارد، یا یک شیء برچسب جدید که یک کامیت موجود به آن اشاره می‌کند\&.
.RE
.RE
.sp
شما می‌توانید این قوانین را با ارسال \fB\-\-force\fR یا با افزودن \fB+\fR اختیاری در ابتدای یک مشخصه ارجاع (refspec) نادیده بگیرید\&. تنها استثناها این است که هیچ مقداری از اجبار کردن باعث نخواهد شد یک شاخه شیئی غیر از کامیت را بپذیرد، و اجبار کردن باعث نخواهد شد مخزن دوردست ارسالی را بپذیرد که برای رد آن پیکربندی شده است\&.
.sp
قلاب‌ها و پیکربندی نیز می‌توانند این قوانین را لغو کرده یا اصلاح کنند؛ برای نمونه \fBreceive\&.denyNonFastForwards\fR و \fBreceive\&.denyDeletes\fR را در \fBgit-config\fR(1) و \fBpre\-receive\fR و \fBupdate\fR در \fBgithooks\fR(5) ببینید\&.
.SH "نکته‌ای درباره جلوبردن‌های سریع (NOTE ABOUT FAST\-FORWARDS)"
.sp
هنگامی که یک به‌روزرسانی، شاخه‌ای (یا به‌طور کلی‌تر، یک ارجاع) را که به کامیت A اشاره می‌کرد تغییر می‌دهد تا به کامیت دیگری مانند B اشاره کند، این عملیات اگر و تنها اگر B نواده‌ای از A باشد، یک به‌روزرسانی جلوبردن سریع (fast\-forward) نامیده می‌شود\&.
.sp
در یک به‌روزرسانی جلوبردن سریع از A به B، مجموعه کامیت‌هایی که کامیت اولیه A بر پایه آن‌ها ساخته شده بود، زیرمجموعه‌ای از کامیت‌هایی است که کامیت جدید B بر روی آن‌ها بنا شده است\&. از این رو، هیچ تاریخچه‌ای از دست نمی‌رود\&.
.sp
در مقابل، یک به‌روزرسانی جلوبردن غیرسریع (non\-fast\-forward) تاریخچه را از بین خواهد برد\&. برای نمونه، فرض کنید شما و فرد دیگری کار را از کامیت یکسان X آغاز کرده‌اید، و شما تاریخچه‌ای ساخته‌اید که به کامیت B می‌رسد، در حالی که فرد دیگر تاریخچه‌ای منتهی به کامیت A ساخته است\&. این تاریخچه به این شکل است:
.sp
.if n \{\
.RS 4
.\}
.nf
      B
     /
 \-\-\-X\-\-\-A
.fi
.if n \{\
.RE
.\}
.sp
.sp
همچنین فرض کنید آن فرد دیگر پیش‌تر تغییرات منتهی به A را به مخزن اصلی که شما دو نفر کامیت اولیه X را از آن دریافت کرده بودید، ارسال (push) کرده است\&.
.sp
ارسالِ انجام‌شده توسط فرد دیگر، شاخه‌ای را که به کامیت X اشاره می‌کرد به‌روزرسانی کرده تا به کامیت A اشاره کند\&. این یک جلوبردن سریع (fast\-forward) است\&.
.sp
اما اگر شما برای ارسال تلاش کنید، سعی خواهید کرد شاخه را (که اکنون به A اشاره دارد) با کامیت B به‌روزرسانی نمایید\&. این عملیات جلوبردن سریع \fIنخواهد بود\fR\&. اگر چنین کاری می‌کردید، تغییرات ایجادشده توسط کامیت A از دست می‌رفت، زیرا از این پس همگان کار را بر پایه B ادامه می‌دادند\&.
.sp
این دستور به‌طور پیش‌فرض اجازه به‌روزرسانی غیرسریع را نمی‌دهد تا از چنین از دست رفتن تاریخچه‌ای جلوگیری کند\&.
.sp
اگر نمی‌خواهید کار خودتان (تاریخچه از X به B) یا کار فرد دیگر (تاریخچه از X به A) را از دست بدهید، باید ابتدا تاریخچه را از مخزن واکشی (fetch) کنید، تاریخچه‌ای بسازید که شامل تغییرات انجام‌شده توسط هر دو طرف باشد، و سپس نتیجه را ارسال (push) کنید\&.
.sp
می‌توانید دستور "git pull" را اجرا کنید، تداخل‌های احتمالی را برطرف نمایید، و نتیجه را با "git push" ارسال کنید\&. دستور "git pull" یک کامیت ادغام C بین کامیت‌های A و B ایجاد خواهد کرد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
      B\-\-\-C
     /   /
 \-\-\-X\-\-\-A
.fi
.if n \{\
.RE
.\}
.sp
.sp
به‌روزرسانی A با کامیت ادغام حاصل‌شده، به‌صورت جلوبردن سریع خواهد بود و ارسال (push) شما پذیرفته می‌شود\&.
.sp
به عنوان روش دیگر، می‌توانید با استفاده از \fBgit\fR \fBpull\fR \fB\-\-rebase\fR تغییرات خود بین X و B را بر روی A بازپایه‌ریزی (rebase) کرده و نتیجه را ارسال (push) نمایید\&. این بازپایه‌ریزی یک کامیت جدید D ایجاد می‌کند که تغییرات بین X و B را بر روی A بنا می‌سازد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
      B   D
     /   /
 \-\-\-X\-\-\-A
.fi
.if n \{\
.RE
.\}
.sp
.sp
مجدداً، به‌روزرسانی A با این کامیت یک جلوبردن سریع خواهد بود و ارسال شما پذیرفته می‌شود\&.
.sp
وضعیت رایج دیگری نیز وجود دارد که ممکن است هنگام تلاش برای ارسال (push) با رد شدن به دلیل جلوبردن غیرسریع مواجه شوید، و این حالت حتی زمانی که به مخزنی ارسال می‌کنید که هیچ‌کس دیگری به آن ارسال نمی‌کند نیز امکان‌پذیر است\&. پس از این‌که خودتان کامیت A را ارسال کردید (در تصویر نخست این بخش)، آن را با \fBgit\fR \fBcommit\fR \fB\-\-amend\fR جایگزین می‌کنید تا کامیت B تولید شود، و سپس تلاش می‌کنید آن را ارسال کنید چون فراموش کرده‌اید که پیش‌تر A را ارسال کرده بودید\&. در چنین حالتی، و تنها اگر مطمئن هستید که در این فاصله هیچ‌کس کامیت قبلی شما یعنی A را واکشی (fetch) نکرده است (و ساخت کار خود را بر روی آن آغاز نکرده است)، می‌توانید \fBgit\fR \fBpush\fR \fB\-\-force\fR را برای رونویسی روی آن اجرا کنید\&. به عبارت دیگر، \fBgit\fR \fBpush\fR \fB\-\-force\fR روشی است که برای مواردی در نظر گرفته شده که شما واقعاً قصد دارید تاریخچه را از دست بدهید\&.
.SH "مثال‌ها (EXAMPLES)"
.PP
\fBgit\fR \fBpush\fR
.RS 4
مانند
\fBgit\fR
\fBpush\fR
\fI<remote>\fR
عمل می‌کند، که در آن <remote> ریموتِ شاخه فعلی است (یا اگر هیچ ریموتی برای شاخه فعلی پیکربندی نشده باشد،
\fBorigin\fR
است)\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR
.RS 4
بدون پیکربندی اضافی، در صورتی که شاخه بالادست (upstream) پیکربندی‌شده (متغیر پیکربندی
\fBbranch\&.\fR\fI<name>\fR\fB\&.merge\fR)
هم‌نام با شاخه فعلی باشد، شاخه فعلی را به آن ارسال می‌کند، و در غیر این صورت بدون ارسال با خطا خارج می‌شود\&.
.sp
رفتار پیش‌فرض این دستور هنگامی که هیچ
\fI<refspec>\fR
(مشخصه ارجاع) مشخص نشده باشد را می‌توان با تنظیم گزینه
\fBpush\fR
مربوط به ریموت، یا متغیر پیکربندی
\fBpush\&.default\fR
تعیین کرد\&.
.sp
برای نمونه، جهت تعیین رفتار پیش‌فرض برای ارسال تنها شاخه فعلی به
\fBorigin\fR
از دستور زیر استفاده کنید:
\fBgit\fR
\fBconfig\fR
\fBremote\&.origin\&.push\fR
\fBHEAD\fR\&.
هر
\fI<refspec>\fR
معتبری (مانند موارد موجود در مثال‌های زیر) می‌تواند به‌عنوان مقدار پیش‌فرض برای
\fBgit\fR
\fBpush\fR
\fBorigin\fR
پیکربندی شود\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fB:\fR
.RS 4
شاخه‌های «منطبق» ("matching") را به
\fBorigin\fR
ارسال می‌کند\&. برای توضیحات درباره شاخه‌های «منطبق»، به بخش
\fI<refspec>\fR
در بخش
OPTIONS
(گزینه‌ها) در بالا مراجعه کنید\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fBmaster\fR
.RS 4
ارجاعی را که با
\fBmaster\fR
در مخزن مبدأ مطابقت دارد می‌یابد (به احتمال زیاد
\fBrefs/heads/master\fR
را پیدا می‌کند)، و همان ارجاع را (مثلاً
\fBrefs/heads/master\fR)
در مخزن
\fBorigin\fR
با آن به‌روزرسانی می‌کند\&. اگر
\fBmaster\fR
در سمت ریموت وجود نداشته باشد، ایجاد خواهد شد\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fBHEAD\fR
.RS 4
روشی سودمند برای ارسال شاخه فعلی به شاخه‌ای با همان نام روی ریموت\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBmothership\fR \fBmaster:satellite/master\fR \fBdev:satellite/dev\fR
.RS 4
از ارجاع مبدأ که با
\fBmaster\fR
مطابقت دارد (مثلاً
\fBrefs/heads/master\fR)
استفاده می‌کند تا ارجاع مطابق با
\fBsatellite/master\fR
(به احتمال زیاد
\fBrefs/remotes/satellite/master\fR)
را در مخزن
\fBmothership\fR
به‌روزرسانی نماید؛ و همین کار را برای
\fBdev\fR
و
\fBsatellite/dev\fR
نیز انجام می‌دهد\&.
.sp
برای بررسی مفاهیم تطبیق، به بخش شرح‌دهنده
\fI<refspec>\fR\&.\&.\&.
در بالا مراجعه کنید\&.
.sp
این کار برای شبیه‌سازی اجرای
\fBgit\fR
\fBfetch\fR
روی
\fBmothership\fR
با استفاده از
\fBgit\fR
\fBpush\fR
است که در جهت معکوس اجرا می‌شود تا کارهای انجام‌شده روی
\fBsatellite\fR
ادغام شوند، و اغلب زمانی لازم است که فقط امکان برقراری ارتباط یک‌طرفه را دارید (یعنی satellite می‌تواند با ssh به mothership متصل شود اما mothership نمی‌تواند اتصال به satellite را آغاز کند زیرا دومی پشت فایروال قرار دارد یا sshd را اجرا نمی‌کند)\&.
.sp
پس از اجرای این دستور
\fBgit\fR
\fBpush\fR
روی دستگاه
\fBsatellite\fR،
شما با ssh به
\fBmothership\fR
متصل می‌شوید و در آنجا
\fBgit\fR
\fBmerge\fR
را اجرا می‌کنید تا شبیه‌سازی اجرای
\fBgit\fR
\fBpull\fR
روی
\fBmothership\fR
جهت دریافت تغییرات ایجادشده روی
\fBsatellite\fR
کامل شود\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fBHEAD:master\fR
.RS 4
شاخه فعلی را به ارجاع ریموت منطبق با
\fBmaster\fR
در مخزن
\fBorigin\fR
ارسال می‌کند\&. این شکل برای ارسال شاخه فعلی بدون نیاز به در نظر گرفتن نام محلی آن بسیار مناسب است\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fBmaster:refs/heads/experimental\fR
.RS 4
شاخه
\fBexperimental\fR
را در مخزن
\fBorigin\fR
با رونوشت برداشتن از شاخه فعلی
\fBmaster\fR
ایجاد می‌کند\&. این فرم فقط زمانی لازم است که بخواهید شاخه یا تگ جدیدی را در مخزن ریموت بسازید در حالی که نام محلی و نام ریموت با یکدیگر تفاوت دارند؛ در غیر این صورت، نام ارجاع به تنهایی کافی خواهد بود\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fB:experimental\fR
.RS 4
ارجاعی را که با
\fBexperimental\fR
در مخزن
\fBorigin\fR
مطابقت دارد می‌یابد (مثلاً
\fBrefs/heads/experimental\fR)
و آن را حذف می‌کند\&.
.RE
.PP
\fBgit\fR \fBpush\fR \fBorigin\fR \fB+dev:master\fR
.RS 4
شاخه master در مخزن origin را با شاخه dev به‌روزرسانی می‌کند و اجازه به‌روزرسانی‌های جلوبردن غیرسریع (non\-fast\-forward) را می‌دهد\&.
\fBاین کار می‌تواند کامیت‌های ارجاع‌داده‌نشده را به‌صورت معلق (dangling) در مخزن origin باقی بگذارد\&.\fR
وضعیت زیر را در نظر بگیرید که در آن یک جلوبردن سریع امکان‌پذیر نیست:
.sp
.if n \{\
.RS 4
.\}
.nf
            o\-\-\-o\-\-\-o\-\-\-A\-\-\-B  origin/master
                     \e
                      X\-\-\-Y\-\-\-Z  dev
.fi
.if n \{\
.RE
.\}
.sp
دستور فوق مخزن origin را به صورت زیر تغییر می‌دهد:
.sp
.if n \{\
.RS 4
.\}
.nf
                      A\-\-\-B  (unnamed branch)
                     /
            o\-\-\-o\-\-\-o\-\-\-X\-\-\-Y\-\-\-Z  master
.fi
.if n \{\
.RE
.\}
.sp
کامیت‌های A و B دیگر به شاخه‌ای با نام نمادین تعلق نخواهند داشت و بنابراین غیرقابل دسترس خواهند بود\&. به این ترتیب، این کامیت‌ها با اجرای دستور
\fBgit\fR
\fBgc\fR
در مخزن origin حذف خواهند شد\&.
.RE
.SH "امنیت (SECURITY)"
.sp
پروتکل‌های fetch و push برای جلوگیری از سرقت داده‌هایی از مخزن طرف مقابل که قصد به‌اشتراک‌گذاری آن‌ها نبوده است طراحی نشده‌اند\&. اگر داده‌های خصوصی دارید که باید از یک همتای مخرب محافظت شوند، بهترین گزینه شما ذخیره آن‌ها در یک مخزن دیگر است\&. این امر هم برای کلاینت‌ها و هم برای سرورها صدق می‌کند\&. به‌ویژه، فضاهای نام (namespaces) روی یک سرور برای کنترل دسترسی خواندن کارآمد نیستند؛ شما فقط باید دسترسی خواندن به یک فضای نام را به کلاینت‌هایی اعطا کنید که برای دسترسی خواندن به کل مخزن به آن‌ها اعتماد دارید\&.
.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 در فضای نامی که کلاینت به آن دسترسی دارد و سپس fetch کردن آن\&. محتمل‌ترین روش برای اجرای آن توسط سرور روی کلاینت این است که X را در یک شاخه عمومی «ادغام» (merge) کند و امیدوار باشد که کاربر کارهای بیشتری روی این شاخه انجام داده و بدون متوجه شدن ادغام، آن را به سرور 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
\fBpush\&.autoSetupRemote\fR
.RS 4
اگر روی
\fBtrue\fR
تنظیم شود، در push پیش‌فرض وقتی هیچ ردیابی بالادستی (upstream tracking) برای شاخه جاری وجود ندارد،
\fB\-\-set\-upstream\fR
را فرض می‌کند؛ این گزینه با گزینه‌های
\fBpush\&.default\fR
شامل
\fBsimple\fR،
\fBupstream\fR و
\fBcurrent\fR اعمال می‌شود\&. این گزینه زمانی مفید است که بخواهید به‌طور پیش‌فرض شاخه‌های جدید به دوردست پیش‌فرض push شوند (مانند رفتار
\fBpush\&.default=current\fR) و همچنین بخواهید ردیابی بالادست تنظیم شود\&. جریان‌های کاری که بیشترین احتمال بهره‌مندی از این گزینه را دارند جریان‌های کاری متمرکز
\fBsimple\fR
هستند که در آن‌ها انتظار می‌رود تمام شاخه‌ها نام یکسانی در دوردست داشته باشند\&.
.RE
.PP
\fBpush\&.default\fR
.RS 4
اقدامی را که
\fBgit\fR
\fBpush\fR
در صورت مشخص نشدن مشخصه ارجاع (refspec) (چه از خط فرمان، پیکربندی، یا جای دیگر) باید انجام دهد، مشخص می‌کند\&. مقادیر مختلف برای جریان‌های کاری خاص مناسب هستند؛ برای مثال، در یک جریان کاری کاملاً متمرکز (یعنی منبع fetch با مقصد push برابر است)، مقدار
\fBupstream\fR
احتمالاً همان چیزی است که می‌خواهید\&. مقادیر ممکن عبارتند از:
.PP
\fBnothing\fR
.RS 4
هیچ چیزی را push نکن (با خطا خارج شو) مگر اینکه مشخصه ارجاع (refspec) داده شده باشد\&. این گزینه در درجه اول برای افرادی است که می‌خواهند با صراحت همیشگی از اشتباهات جلوگیری کنند\&.
.RE
.PP
\fBcurrent\fR
.RS 4
شاخه جاری را برای به‌روزرسانی شاخه‌ای با همان نام در سمت دریافت‌کننده push کن\&. در هر دو جریان کاری متمرکز و غیرمتمرکز کار می‌کند\&.
.RE
.PP
\fBupstream\fR
.RS 4
شاخه جاری را به شاخه‌ای که تغییراتش معمولاً در شاخه جاری ادغام می‌شود (که
\fB@\fR{upstream}
نامیده می‌شود) push کن\&. این حالت تنها زمانی معنی دارد که به همان مخزنی push می‌کنید که معمولاً از آن pull می‌کنید (یعنی جریان کاری متمرکز)\&.
.RE
.PP
\fBtracking\fR
.RS 4
این یک مترادف منسوخ‌شده برای
\fBupstream\fR
است\&.
.RE
.PP
\fBsimple\fR
.RS 4
شاخه جاری را با همان نام در دوردست push کن\&.
.sp
این حالت مستلزم آن است که مخزن دوردستی که باید به آن push شود شناخته‌شده باشد\&. هنگام push کردن مجدد به همان دوردستی که از آن pull می‌کنید، شاخه جاری باید یک شاخه ردیابی بالادست با همان نام نیز داشته باشد\&.
.sp
این حالت از نسخه گیت ۲\&.۰ حالت پیش‌فرض است، و امن‌ترین گزینه مناسب برای مبتدیان است\&.
.RE
.PP
\fBmatching\fR
.RS 4
تمام شاخه‌هایی که در هر دو طرف نام یکسانی دارند را push کن\&. این کار باعث می‌شود مخزنی که به آن push می‌کنید، مجموعه شاخه‌هایی را که ارسال خواهند شد به خاطر بسپارد (مثلاً اگر همیشه فقط
\fBmaint\fR
و
\fBmaster\fR
را به آنجا push کنید و نه شاخه دیگری را، مخزنی که به آن push می‌کنید این دو شاخه را خواهد داشت و شاخه‌های محلی
\fBmaint\fR
و
\fBmaster\fR
شما به آنجا push خواهند شد)\&.
.sp
برای استفاده مؤثر از این حالت، باید مطمئن شوید که قبل از اجرای
\fBgit\fR
\fBpush\fR،
\fIهمه\fR
شاخه‌هایی که قصد ارسالشان را دارید آماده push شدن باشند، زیرا هدف اصلی این حالت این است که به شما امکان دهد تمام شاخه‌ها را یک‌باره push کنید\&. اگر معمولاً کار روی یک شاخه را تمام کرده و نتیجه را push می‌کنید، در حالی که شاخه‌های دیگر ناتمام هستند، این حالت برای شما مناسب نیست\&. همچنین این حالت برای push کردن به یک مخزن متمرکز مشترک مناسب نیست، چرا که افراد دیگر ممکن است شاخه‌های جدیدی در آنجا اضافه کنند، یا نوک شاخه‌های موجود را خارج از کنترل شما به‌روزرسانی نمایند\&.
.sp
این گزینه قبلاً پیش‌فرض بود، اما از گیت ۲\&.۰ به بعد چنین نیست (\fBsimple\fR
پیش‌فرض جدید است)\&.
.RE
.RE
.PP
\fBpush\&.followTags\fR
.RS 4
اگر روی true تنظیم شود، گزینه
\fB\-\-follow\-tags\fR
را به‌طور پیش‌فرض فعال می‌کند\&. می‌توانید این پیکربندی را در زمان push با مشخص کردن
\fB\-\-no\-follow\-tags\fR
لغو کنید\&.
.RE
.PP
\fBpush\&.gpgSign\fR
.RS 4
می‌تواند روی یک مقدار بولی (boolean)، یا رشته
\fBif\-asked\fR
تنظیم شود\&. مقدار true باعث می‌شود تمام pushها با GPG امضا شوند، گویی
\fB\-\-signed\fR
به
\fBgit-push\fR(1)
داده شده است\&. رشته
\fBif\-asked\fR
باعث می‌شود در صورت پشتیبانی سرور، pushها امضا شوند، گویی
\fB\-\-signed=if\-asked\fR
به
\fBgit\fR
\fBpush\fR
ارسال شده است\&. مقدار false می‌تواند مقداری از یک فایل پیکربندی با اولویت پایین‌تر را لغو کند\&. یک فلگ صریح خط فرمان همیشه این گزینه پیکربندی را لغو می‌کند (override می‌نماید)\&.
.RE
.PP
\fBpush\&.pushOption\fR
.RS 4
هنگامی که هیچ آرگومان
\fB\-\-push\-option=\fR\fI<option>\fR
از خط فرمان داده نشده باشد،
\fBgit\fR
\fBpush\fR
به‌گونه‌ای رفتار می‌کند که گویی هر
\fI<option>\fR
از این متغیر به‌صورت
\fB\-\-push\-option=\fR\fI<option>\fR
داده شده است\&.
.sp
این یک متغیر چندمقداری است، و از یک مقدار خالی می‌توان در یک فایل پیکربندی با اولویت بالاتر (مانند
\fB\&.git/config\fR
در یک مخزن) برای پاک کردن مقادیر به ارث رسیده از فایل‌های پیکربندی با اولویت پایین‌تر (مانند
\fB$HOME/\&.gitconfig\fR)
استفاده کرد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
مثال:

/etc/gitconfig
  push\&.pushoption = a
  push\&.pushoption = b

~/\&.gitconfig
  push\&.pushoption = c

repo/\&.git/config
  push\&.pushoption =
  push\&.pushoption = b

این تنظیم تنها منجر به b خواهد شد (a و c پاک می‌شوند)\&.
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
\fBpush\&.recurseSubmodules\fR
.RS 4
می‌تواند
\fBcheck\fR،
\fBon\-demand\fR،
\fBonly\fR
یا
\fBno\fR
باشد، با رفتاری مشابه
\fBpush\fR
\fB\-\-recurse\-submodules\fR\&. اگر تنظیم نشده باشد، به‌طور پیش‌فرض
\fBno\fR
استفاده می‌شود، مگر اینکه
\fBsubmodule\&.recurse\fR
تنظیم شده باشد (که در این صورت مقدار
\fBtrue\fR
به معنی
\fBon\-demand\fR
خواهد بود)\&.
.RE
.PP
\fBpush\&.useForceIfIncludes\fR
.RS 4
اگر روی
\fBtrue\fR
تنظیم شود، معادل مشخص کردن
\fB\-\-force\-if\-includes\fR
به‌عنوان یک گزینه برای
\fBgit-push\fR(1)
در خط فرمان است\&. افزودن
\fB\-\-no\-force\-if\-includes\fR
در زمان push این تنظیم پیکربندی را لغو می‌کند\&.
.RE
.PP
\fBpush\&.negotiate\fR
.RS 4
اگر روی
\fBtrue\fR
تنظیم شود، تلاش می‌کند اندازه بسته (packfile) ارسال‌شده را با دورهایی از مذاکره که در آن کلاینت و سرور سعی در یافتن کامیت‌های مشترک دارند کاهش دهد\&. اگر
\fBfalse\fR
باشد، گیت تنها به اعلان ارجاع (ref advertisement) سرور برای یافتن کامیت‌های مشترک اتکا خواهد کرد\&.
.RE
.PP
\fBpush\&.useBitmaps\fR
.RS 4
اگر روی
\fBfalse\fR
تنظیم شود، استفاده از نگاشت‌های بیتی (bitmaps) را برای
\fBgit\fR
\fBpush\fR
غیرفعال می‌کند حتی اگر
\fBpack\&.useBitmaps\fR
روی
\fBtrue\fR
باشد، بدون اینکه مانع استفاده سایر عملیات‌های گیت از نقشه‌های بیتی شود\&. مقدار پیش‌فرض
\fBtrue\fR
است\&.
.RE
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)