'\" t
.\"     Title: git-commit
.\"    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\-COMMIT" "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-commit \- ثبت تغییرات در مخزن
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fBgit\fR \fBcommit\fR [\fB\-a\fR | \fB\-\-interactive\fR | \fB\-\-patch\fR] [\fB\-s\fR] [\fB\-v\fR] [\fB\-u\fR[\fI<mode>\fR]] [\fB\-\-amend\fR]
           [\fB\-\-dry\-run\fR] [(\fB\-c\fR | \fB\-C\fR | \fB\-\-squash\fR) \fI<commit>\fR | \fB\-\-fixup\fR [(\fBamend\fR|\fBreword\fR)\fB:\fR]\fI<commit>\fR]
           [\fB\-F\fR \fI<file>\fR | \fB\-m\fR \fI<msg>\fR] [\fB\-\-reset\-author\fR] [\fB\-\-allow\-empty\fR]
           [\fB\-\-allow\-empty\-message\fR] [\fB\-\-no\-verify\fR] [\fB\-e\fR] [\fB\-\-author=\fR\fI<author>\fR]
           [\fB\-\-date=\fR\fI<date>\fR] [\fB\-\-cleanup=\fR\fI<mode>\fR] [\fB\-\-\fR[\fBno\-\fR]\fBstatus\fR]
           [\fB\-i\fR | \fB\-o\fR] [\fB\-\-pathspec\-from\-file=\fR\fI<file>\fR [\fB\-\-pathspec\-file\-nul\fR]]
           [(\fB\-\-trailer\fR \fI<token>\fR[(\fB=\fR|\fB:\fR)\fI<value>\fR])\&...] [\fB\-S\fR[\fI<keyid>\fR]]
           [\fB\-\-\fR] [\fI<pathspec>\fR\&...]
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
یک کامیت جدید شامل محتویات فعلی ایندکس و پیام گزارش ارائه‌شده برای توصیف تغییرات ایجاد می‌کند\&. کامیت جدید فرزند مستقیم HEAD است، که معمولاً نوک شاخه فعلی می‌باشد، و شاخه به‌روزرسانی می‌شود تا به آن اشاره کند (مگر اینکه هیچ شاخه‌ای با درخت کاری مرتبط نباشد، که در این صورت همان‌طور که در \fBgit-checkout\fR(1) شرح داده شده است، \fBHEAD\fR در وضعیت «جداشده» (detached) قرار دارد)\&.
.sp
محتوایی که قرار است کامیت شود را می‌توان به چندین روش مشخص کرد:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
با استفاده از
\fBgit-add\fR(1)
برای «اضافه کردن» گام‌به‌گام تغییرات به ایندکس پیش از استفاده از دستور
\fBcommit\fR
(توجه: حتی فایل‌های تغییریافته نیز باید «اضافه» شوند)؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
با استفاده از
\fBgit-rm\fR(1)
برای حذف فایل‌ها از درخت کاری و ایندکس، مجدداً پیش از استفاده از دستور
\fBcommit\fR؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
با فهرست کردن فایل‌ها به عنوان آرگومان‌های دستور
\fBcommit\fR
(بدون گزینه‌های
\fB\-\-interactive\fR
یا
\fB\-\-patch\fR)،
که در این حالت کامیت، تغییرات آماده‌سازی‌شده (استیج‌شده) در ایندکس را نادیده می‌گیرد و در عوض محتوای فعلی فایل‌های فهرست‌شده را (که باید از قبل برای گیت شناخته‌شده باشند) ثبت می‌کند؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  4." 4.2
.\}
با استفاده از گزینه
\fB\-a\fR
همراه با دستور
\fBcommit\fR
برای «اضافه کردن» خودکار تغییرات از تمام فایل‌های شناخته‌شده (یعنی تمام فایل‌هایی که از قبل در ایندکس فهرست شده‌اند) و «حذف کردن» خودکار فایل‌هایی از ایندکس که از درخت کاری حذف شده‌اند، و سپس انجام کامیت واقعی؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 5.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  5." 4.2
.\}
با استفاده از گزینه‌های
\fB\-\-interactive\fR
یا
\fB\-\-patch\fR
همراه با دستور
\fBcommit\fR
برای تصمیم‌گیری تک‌به‌تک در مورد اینکه کدام فایل‌ها یا قطعه‌تغییرها (hunks) علاوه بر محتویات ایندکس باید بخشی از کامیت باشند، پیش از نهایی کردن عملیات\&. بخش \(lqInteractive Mode\(rq در
\fBgit-add\fR(1)
را ببینید تا با نحوه کار با این حالت‌ها آشنا شوید\&.
.RE
.sp
گزینه \fB\-\-dry\-run\fR می‌تواند برای دریافت خلاصه‌ای از آنچه که طبق هر یک از روش‌های بالا با دادن همان مجموعه پارامترها (گزینه‌ها و مسیرها) در کامیت بعدی گنجانده می‌شود، استفاده شود\&.
.sp
اگر یک کامیت ایجاد کردید و بلافاصله پس از آن متوجه اشتباهی شدید، می‌توانید با استفاده از \fBgit\fR \fBreset\fR آن را برگردانید و اصلاح کنید\&.
.SH "گزینه‌ها (OPTIONS)"
.PP
\fB\-a\fR, \fB\-\-all\fR
.RS 4
به‌طور خودکار فایل‌هایی را که تغییر یافته یا حذف شده‌اند آماده‌سازی (استیج) می‌کند، اما فایل‌های جدیدی که به گیت معرفی نکرده‌اید تحت تأثیر قرار نمی‌گیرند\&.
.RE
.PP
\fB\-p\fR, \fB\-\-patch\fR
.RS 4
استفاده از رابط تعاملی انتخاب وصله (patch) برای انتخاب تغییراتی که باید کامیت شوند\&. برای جزئیات به
\fBgit-add\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-U\fR\fI<n>\fR, \fB\-\-unified=\fR\fI<n>\fR
.RS 4
تولید diff با
\fI<n>\fR
خط زمینه (context)\&. تعداد خطوط زمینه در حالت پیش‌فرض برابر با
\fBdiff\&.context\fR
یا ۳ (در صورت تنظیم نشدن متغیر پیکربندی) است\&. (گزینه
\fB\-U\fR
بدون
\fI<n>\fR
به‌دلیل یک تصادف تاریخی، بی‌صدا به عنوان مترادفی برای
\fB\-p\fR
پذیرفته می‌شود)\&.
.RE
.PP
\fB\-\-inter\-hunk\-context=\fR\fI<n>\fR
.RS 4
نمایش زمینه بین قطعه‌های diff، تا سقف تعداد خطوط مشخص‌شده در
\fI<number>\fR
که در نتیجه قطعه‌های نزدیک به یکدیگر را ادغام می‌کند\&. مقدار پیش‌فرض برابر با
\fBdiff\&.interHunkContext\fR
یا در صورت تنظیم نشدن گزینه پیکربندی، 0 است\&.
.RE
.PP
\fB\-C\fR \fI<commit>\fR, \fB\-\-reuse\-message=\fR\fI<commit>\fR
.RS 4
یک شیء
\fI<commit>\fR
موجود را می‌گیرد و هنگام ایجاد کامیت، از پیام گزارش و اطلاعات نویسندگی (از جمله برچسب زمانی) آن مجدداً استفاده می‌کند\&.
.RE
.PP
\fB\-c\fR \fI<commit>\fR, \fB\-\-reedit\-message=\fR\fI<commit>\fR
.RS 4
مانند
\fB\-C\fR،
اما با
\fB\-c\fR
ویرایشگر باز می‌شود تا کاربر بتواند پیام کامیت را بیشتر ویرایش کند\&.
.RE
.PP
\fB\-\-fixup=\fR[(\fBamend\fR|\fBreword\fR)\fB:\fR]\fI<commit>\fR
.RS 4
یک کامیت جدید ایجاد می‌کند که در صورت اعمال با
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR،
کامیت
\fI<commit>\fR
را «اصلاح» (fix up) می‌کند\&. حالت ساده
\fB\-\-fixup=\fR\fI<commit>\fR
یک کامیت «!fixup» ایجاد می‌کند که محتوای
\fI<commit>\fR
را تغییر می‌دهد اما به پیام گزارش آن دست نمی‌زند\&.
\fB\-\-fixup=amend:\fR\fI<commit>\fR
مشابه است اما یک کامیت «!amend» ایجاد می‌کند که پیام گزارش
\fI<commit>\fR
را نیز با پیام گزارش کامیت «!amend» جایگزین می‌کند\&.
\fB\-\-fixup=reword:\fR\fI<commit>\fR
یک کامیت «!amend» ایجاد می‌کند که پیام گزارش
\fI<commit>\fR
را با پیام گزارش خود جایگزین می‌کند اما تغییری در محتوای
\fI<commit>\fR
ایجاد نمی‌کند\&.
.sp
کامیتی که توسط حالت ساده
\fB\-\-fixup=\fR\fI<commit>\fR
ایجاد می‌شود دارای عنوانی متشکل از «!fixup» به‌همراه عنوان
\fI<commit>\fR
است، و به‌طور ویژه توسط
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR
شناسایی می‌شود\&. گزینه
\fB\-m\fR
می‌تواند برای تکمیل پیام گزارش کامیت ایجادشده استفاده شود، اما توضیحات اضافی پس از آن‌که کامیت «!fixup» توسط
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR
در
\fI<commit>\fR
ترکیب (squash) شد، دور ریخته می‌شود\&.
.sp
کامیتی که توسط
\fB\-\-fixup=amend:\fR\fI<commit>\fR
ایجاد می‌شود مشابه است اما عنوان آن با پیشوند «!amend» شروع می‌شود\&. پیام گزارش
\fI<commit>\fR
در پیام گزارش کامیت «!amend» کپی شده و در یک ویرایشگر باز می‌شود تا اصلاح و بازبینی شود\&. هنگامی که
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR
کامیت «!amend» را در
\fI<commit>\fR
ترکیب (squash) می‌کند، پیام گزارش
\fI<commit>\fR
با پیام گزارش اصلاح‌شده کامیت «!amend» جایگزین می‌شود\&. خالی بودن پیام گزارش کامیت «!amend» خطا محسوب می‌شود مگر این‌که
\fB\-\-allow\-empty\-message\fR
مشخص شده باشد\&.
.sp
\fB\-\-fixup=reword:\fR\fI<commit>\fR
کوتاه‌شده‌ای برای
\fB\-\-fixup=amend:\fR\fI<commit>\fR
\fB\-\-only\fR
است\&. این گزینه یک کامیت «!amend» را تنها با یک پیام گزارش ایجاد می‌کند (و هرگونه تغییری را که در ایندکس استیج شده باشد نادیده می‌گیرد)\&. هنگامی که توسط
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR
ترکیب (squash) می‌شود، پیام گزارش
\fI<commit>\fR
را بدون ایجاد هیچ تغییر دیگری جایگزین می‌کند\&.
.sp
هیچ‌کدام از کامیت‌های «!fixup» یا «!amend» هنگام اعمال توسط
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR،
نویسنده
\fI<commit>\fR
را تغییر نمی‌دهند\&. برای جزئیات به
\fBgit-rebase\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-\-squash=\fR\fI<commit>\fR
.RS 4
یک پیام کامیت برای استفاده با
\fBgit\fR
\fBrebase\fR
\fB\-\-autosquash\fR
می‌سازد\&. عنوان پیام کامیت از کامیت مشخص‌شده همراه با پیشوند "squash! " گرفته می‌شود\&. می‌تواند همراه با گزینه‌های اضافی پیام کامیت (\fB\-m\fR/\fB\-c\fR/\fB\-C\fR/\fB\-F\fR) استفاده شود\&. برای جزئیات به
\fBgit-rebase\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-\-reset\-author\fR
.RS 4
هنگامی که با گزینه‌های
\fB\-C\fR/\fB\-c\fR/\fB\-\-amend\fR
استفاده شود، یا هنگام کامیت کردن پس از یک cherry\-pick دارای تداخل، اعلام می‌کند که نویسندگی کامیت حاصل اکنون به کامیت‌کننده تعلق دارد\&. این کار همچنین برچسب زمانی نویسنده را تجدید می‌کند\&.
.RE
.PP
\fB\-\-short\fR
.RS 4
هنگام اجرای آزمایشی (dry\-run)، خروجی را در قالب کوتاه ارائه می‌دهد\&. برای جزئیات به
\fBgit-status\fR(1)
مراجعه کنید\&. متضمن گزینه
\fB\-\-dry\-run\fR
است\&.
.RE
.PP
\fB\-\-branch\fR
.RS 4
اطلاعات شاخه و ردیابی را حتی در قالب کوتاه نمایش می‌دهد\&. برای جزئیات به
\fBgit-status\fR(1)
مراجعه کنید\&.
.RE
.PP
\fB\-\-porcelain\fR
.RS 4
هنگام اجرای آزمایشی (dry\-run)، خروجی را در قالبی مناسب برای اسکریپت‌ها (porcelain) ارائه می‌دهد\&. برای جزئیات به
\fBgit-status\fR(1)
مراجعه کنید\&. متضمن گزینه
\fB\-\-dry\-run\fR
است\&.
.RE
.PP
\fB\-\-long\fR
.RS 4
هنگام اجرای آزمایشی (dry\-run)، خروجی را در قالب بلند ارائه می‌دهد\&. این خروجی پیش‌فرض
\fBgit-status\fR(1)
است\&. متضمن گزینه
\fB\-\-dry\-run\fR
است\&.
.RE
.PP
\fB\-z\fR, \fB\-\-null\fR
.RS 4
هنگام نمایش خروجی
\fBshort\fR
یا
\fBporcelain\fR
در
\fBgit-status\fR(1)،
نام فایل را عیناً چاپ می‌کند و مدخل‌ها را به‌جای
\fILF\fR،
با
\fINUL\fR
پایان می‌دهد\&. اگر قالبی مشخص نشده باشد، متضمن قالب خروجی
\fB\-\-porcelain\fR
است\&. بدون گزینه
\fB\-z\fR،
نام فایل‌های دارای نویسه‌های «نامعمول» همان‌طور که برای متغیر پیکربندی
\fBcore\&.quotePath\fR
توضیح داده شده است، داخل کوتیشن قرار می‌گیرند (به
\fBgit-config\fR(1)
مراجعه کنید)\&.
.RE
.PP
\fB\-F\fR \fI<file>\fR, \fB\-\-file=\fR\fI<file>\fR
.RS 4
پیام کامیت را از
\fI<file>\fR
می‌گیرد\&. برای خواندن پیام از ورودی استاندارد (standard input) از
\fI\-\fR
استفاده کنید\&.
.RE
.PP
\fB\-\-author=\fR\fI<author>\fR
.RS 4
نویسنده کامیت را بازنویسی می‌کند\&. یک نویسنده مشخص را با استفاده از قالب استاندارد
\fBA\fR
\fBU\fR
\fBThor\fR
<author@example\&.com>
تعیین کنید\&. در غیر این صورت
\fI<author>\fR
به‌عنوان یک الگو در نظر گرفته می‌شود و برای جستجوی یک کامیت موجود توسط آن نویسنده استفاده می‌شود (یعنی
\fBgit\fR
\fBrev\-list\fR
\fB\-\-all\fR
\fB\-i\fR
\fB\-\-author=\fR\fI<author>\fR)؛
سپس نویسنده کامیت از اولین کامیتِ پیدا شده کپی می‌شود\&.
.RE
.PP
\fB\-\-date=\fR\fI<date>\fR
.RS 4
تاریخ نویسنده استفاده‌شده در کامیت را بازنویسی می‌کند\&.
.RE
.PP
\fB\-m\fR \fI<msg>\fR, \fB\-\-message=\fR\fI<msg>\fR
.RS 4
از
\fI<msg>\fR
به عنوان پیام کامیت استفاده می‌کند\&. اگر چندین گزینه
\fB\-m\fR
داده شود، مقادیر آن‌ها به عنوان بندهای جداگانه به یکدیگر متصل می‌شوند\&.
.sp
گزینه
\fB\-m\fR
با گزینه‌های
\fB\-c\fR،
\fB\-C\fR
و
\fB\-F\fR
هم‌زمان قابل استفاده نیست (مانعة‌الجمع است)\&.
.RE
.PP
\fB\-t\fR \fI<file>\fR, \fB\-\-template=\fR\fI<file>\fR
.RS 4
هنگام ویرایش پیام کامیت، ویرایشگر را با محتویات موجود در
\fI<file>\fR
باز می‌کند\&. متغیر پیکربندی
\fBcommit\&.template\fR
اغلب برای اعمال ضمنی این گزینه به دستور استفاده می‌شود\&. این سازوکار می‌تواند توسط پروژه‌هایی که مایلند مشارکت‌کنندگان را با راهنمایی‌هایی درباره این‌که چه متنی را به چه ترتیبی در پیام بنویسند هدایت کنند، به کار رود\&. اگر کاربر بدون ویرایش پیام از ویرایشگر خارج شود، کامیت لغو خواهد شد\&. در صورتی که پیام از راه‌های دیگری مانند گزینه‌های
\fB\-m\fR
یا
\fB\-F\fR
ارائه شده باشد، این گزینه تأثیری ندارد\&.
.RE
.PP
\fB\-s\fR, \fB\-\-signoff\fR, \fB\-\-no\-signoff\fR
.RS 4
یک تریلر (دنباله)
\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\-\-trailer\fR \fI<token>\fR[(\fB=\fR|\fB:\fR)\fI<value>\fR]
.RS 4
یک جفت (\fI<token>\fR,
\fI<value>\fR)
را مشخص می‌کند که باید به‌عنوان یک تریلر (دنباله) اعمال شود\&. (مثلاً
\fBgit\fR
\fBcommit\fR
\fB\-\-trailer\fR
"Signed\-off\-by:C
\fBO\fR
\fBMitter\fR
\fB\e\fR
<committer@example\&.com>"
\fB\-\-trailer\fR
"Helped\-by:C
\fBO\fR
\fBMitter\fR
\fB\e\fR
<committer@example\&.com>"
تریلر (دنباله)
\fBSigned\-off\-by\fR
و تریلر (دنباله)
\fBHelped\-by\fR
را به پیام کامیت اضافه می‌کند\&.) متغیرهای پیکربندی
\fBtrailer\&.*\fR
(\fBgit-interpret-trailers\fR(1))
می‌توانند برای تعیین این‌که آیا تریلر تکراری حذف شود، هر تریلر در کجای توالی تریلرها قرار گیرد، و سایر جزئیات استفاده شوند\&.
.RE
.PP
\fB\-n\fR, \fB\-\-verify\fR, \fB\-\-no\-verify\fR
.RS 4
قلاب‌های
\fBpre\-commit\fR
و
\fBcommit\-msg\fR
را دور می‌زند\&. همچنین
\fBgithooks\fR(5)
را ببینید\&.
.RE
.PP
\fB\-\-allow\-empty\fR
.RS 4
معمولاً ثبت کامیتی که دقیقاً همان درخت کامیت والد یگانه خود را دارد یک اشتباه است، و این دستور از ایجاد چنین کامیتی جلوگیری می‌کند\&. این گزینه این سازوکار ایمنی را دور می‌زند و کاربرد اصلی آن برای اسکریپت‌های واسط SCM خارجی است\&.
.RE
.PP
\fB\-\-allow\-empty\-message\fR
.RS 4
یک کامیت با پیام کامیت خالی بدون استفاده از دستورات لوله‌کشی (plumbing) مانند
\fBgit-commit-tree\fR(1)
ایجاد می‌کند\&. همانند
\fB\-\-allow\-empty\fR،
این دستور در درجه اول برای استفاده توسط اسکریپت‌های واسط SCM خارجی است\&.
.RE
.PP
\fB\-\-cleanup=\fR\fI<mode>\fR
.RS 4
نحوه پاک‌سازی پیام کامیت ارائه‌شده قبل از کامیت کردن را تعیین می‌کند\&.
\fI<mode>\fR
می‌تواند
\fBstrip\fR،
\fBwhitespace\fR،
\fBverbatim\fR،
\fBscissors\fR
یا
\fBdefault\fR
باشد\&.
.PP
\fBstrip\fR
.RS 4
خطوط خالی ابتدا و انتها، فاصله‌های خالی انتهایی و خطوط توضیحات را حذف می‌کند و خطوط خالی متوالی را یکی می‌کند\&.
.RE
.PP
\fBwhitespace\fR
.RS 4
همانند
\fBstrip\fR
است، با این تفاوت که خطوط توضیحات با # حذف نمی‌شوند\&.
.RE
.PP
\fBverbatim\fR
.RS 4
پیام را به هیچ وجه تغییر نمی‌دهد\&.
.RE
.PP
\fBscissors\fR
.RS 4
همانند
\fBwhitespace\fR
است، با این تفاوت که اگر قرار است پیام ویرایش شود، همه‌چیز از خط زیر (و شامل آن) به بعد بریده و حذف می‌شود\&. کاراکتر "#" می‌تواند با
\fBcore\&.commentChar\fR
شخصی‌سازی شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
# \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- >8 \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
.fi
.if n \{\
.RE
.\}
.RE
.PP
\fBdefault\fR
.RS 4
اگر قرار است پیام ویرایش شود، همانند
\fBstrip\fR
است؛ در غیر این صورت
\fBwhitespace\fR
می‌باشد\&.
.RE
.sp
حالت پیش‌فرض می‌تواند با متغیر پیکربندی
\fBcommit\&.cleanup\fR
تغییر کند (ببینید:
\fBgit-config\fR(1))\&.
.RE
.PP
\fB\-e\fR, \fB\-\-edit\fR
.RS 4
به کاربر امکان می‌دهد پیامی را که از
\fI<file>\fR
با
\fB\-F\fR \fI<file>\fR،
از خط فرمان با
\fB\-m\fR \fI<message>\fR
و از
\fI<commit>\fR
با
\fB\-C\fR \fI<commit>\fR
گرفته شده است، بیشتر ویرایش کند\&.
.RE
.PP
\fB\-\-no\-edit\fR
.RS 4
از پیام کامیت انتخاب‌شده بدون باز کردن ویرایشگر استفاده می‌کند\&. برای مثال،
\fBgit\fR \fBcommit\fR \fB\-\-amend\fR \fB\-\-no\-edit\fR
یک کامیت را بدون تغییر پیام کامیت آن اصلاح می‌کند\&.
.RE
.PP
\fB\-\-amend\fR
.RS 4
نوک شاخه کنونی را با ایجاد یک کامیت جدید جایگزین می‌کند\&. درخت ثبت‌شده طبق معمول آماده می‌شود (شامل تأثیر گزینه‌های
\fB\-i\fR
و
\fB\-o\fR
و pathspec صریح)، و در صورتی که هیچ پیام دیگری از خط فرمان از طریق گزینه‌هایی مانند
\fB\-m\fR،
\fB\-F\fR،
\fB\-c\fR
و غیره مشخص نشده باشد، پیام کامیت اصلی به جای یک پیام خالی به عنوان نقطه شروع استفاده می‌شود\&. کامیت جدید دارای همان والدین و نویسنده‌ای است که کامیت فعلی دارد (گزینه
\fB\-\-reset\-author\fR
می‌تواند این رفتار را لغو کند)\&.
.sp
این گزینه تقریباً معادل دستورات زیر است:
.sp
.if n \{\
.RS 4
.\}
.nf
        $ git reset \-\-soft HEAD^
        $ \&.\&.\&. do something else to come up with the right tree \&.\&.\&.
        $ git commit \-c ORIG_HEAD
.fi
.if n \{\
.RE
.\}
.sp
اما می‌تواند برای اصلاح یک کامیت ادغام (merge commit) نیز استفاده شود\&.
.sp
اگر کامیتی را که قبلاً منتشر شده است اصلاح می‌کنید، باید پیامدهای بازنویسی تاریخچه را درک کنید\&. (بخش "RECOVERING FROM UPSTREAM REBASE" را در
\fBgit-rebase\fR(1)
ببینید\&.)
.RE
.PP
\fB\-\-no\-post\-rewrite\fR
.RS 4
قلاب
\fBpost\-rewrite\fR
را دور می‌زند\&.
.RE
.PP
\fB\-i\fR, \fB\-\-include\fR
.RS 4
قبل از ایجاد کامیت از محتویات استیج‌شده تا این لحظه، محتویات مسیرهای ارائه‌شده در خط فرمان را نیز آماده‌سازی (استیج) می‌کند\&. این معمولاً چیزی نیست که می‌خواهید، مگر اینکه در حال نهایی کردن یک ادغام دارای تداخل باشید\&.
.RE
.PP
\fB\-o\fR, \fB\-\-only\fR
.RS 4
با در نظر گرفتن محتوای به‌روزشده درخت کاری در مسیرهای مشخص‌شده در خط فرمان و نادیده گرفتن هرگونه محتوای استیج‌شده برای سایر مسیرها، یک کامیت ایجاد می‌کند\&. در صورتی که هر مسیری در خط فرمان مشخص شده باشد، این حالتِ عملکرد پیش‌فرض
\fBgit\fR \fBcommit\fR
است که در این صورت می‌توان این گزینه را حذف کرد\&. اگر این گزینه به همراه
\fB\-\-amend\fR
مشخص شود، نیازی به تعیین مسیر نیست، که می‌توان از آن برای اصلاح آخرین کامیت بدون کامیت کردن تغییراتی که قبلاً استیج شده‌اند استفاده کرد\&. در صورت استفاده همراه با
\fB\-\-allow\-empty\fR
نیز نیازی به مسیرها نیست و یک کامیت خالی ایجاد خواهد شد\&.
.RE
.PP
\fB\-\-pathspec\-from\-file=\fR\fI<file>\fR
.RS 4
الگوی مسیر (pathspec) را به جای آرگومان‌های خط فرمان در
\fI<file>\fR
ارسال می‌کند\&. اگر
\fI<file>\fR
دقیقاً
\fB\-\fR
باشد، از ورودی استاندارد استفاده می‌شود\&. عناصر pathspec با
\fILF\fR
یا
\fICR\fR/\fILF\fR
از یکدیگر جدا می‌شوند\&. عناصر pathspec می‌توانند همان‌طور که برای متغیر پیکربندی
\fBcore\&.quotePath\fR
توضیح داده شده نقل‌قول شوند (ببینید:
\fBgit-config\fR(1))\&. همچنین
\fB\-\-pathspec\-file\-nul\fR
و گزینه سراسری
\fB\-\-literal\-pathspecs\fR
را ببینید\&.
.RE
.PP
\fB\-\-pathspec\-file\-nul\fR
.RS 4
تنها همراه با
\fB\-\-pathspec\-from\-file\fR
معنادار است\&. عناصر pathspec با نویسه
\fINUL\fR
جدا می‌شوند و تمام نویسه‌های دیگر به صورت تحت‌اللفظی در نظر گرفته می‌شوند (شامل خطوط جدید و نقل‌قول‌ها)\&.
.RE
.PP
\fB\-u\fR[\fI<mode>\fR], \fB\-\-untracked\-files\fR[\fB=\fR\fI<mode>\fR]
.RS 4
فایل‌های ردگیری‌نشده را نمایش می‌دهد\&.
.sp
پارامتر
\fI<mode>\fR
اختیاری است (پیش‌فرض آن
\fBall\fR
است) و برای مشخص کردن نحوه برخورد با فایل‌های ردگیری‌نشده به کار می‌رود؛ زمانی که
\fB\-u\fR
استفاده نشود، حالت پیش‌فرض
\fBnormal\fR
است، یعنی نمایش فایل‌ها و دایرکتوری‌های ردگیری‌نشده\&.
.sp
گزینه‌های ممکن عبارتند از:
.PP
\fBno\fR
.RS 4
هیچ فایل ردگیری‌نشده‌ای را نشان نمی‌دهد
.RE
.PP
\fBnormal\fR
.RS 4
فایل‌ها و دایرکتوری‌های ردگیری‌نشده را نشان می‌دهد
.RE
.PP
\fBall\fR
.RS 4
همچنین فایل‌های مجزا در دایرکتوری‌های ردگیری‌نشده را نشان می‌دهد\&.
.RE
.sp
تمام نگارش‌های معمول برای مقدار بولی
\fBtrue\fR
به عنوان
\fBnormal\fR
و
\fBfalse\fR
به عنوان
\fBno\fR
در نظر گرفته می‌شوند\&. این پیش‌فرض می‌تواند با استفاده از متغیر پیکربندی
\fBstatus\&.showUntrackedFiles\fR
مستندشده در
\fBgit-config\fR(1)
تغییر داده شود\&.
.RE
.PP
\fB\-v\fR, \fB\-\-verbose\fR
.RS 4
تفاوت یکپارچه (unified diff) بین کامیت
\fBHEAD\fR
و آنچه قرار است کامیت شود را در انتهای الگوی پیام کامیت نمایش می‌دهد تا با یادآوری تغییرات موجود در کامیت، به کاربر در توصیف کامیت کمک کند\&. توجه داشته باشید که خطوط این خروجی diff دارای پیشوند # نیستند\&. این diff بخشی از پیام کامیت نخواهد بود\&. متغیر پیکربندی
\fBcommit\&.verbose\fR
را در
\fBgit-config\fR(1)
ببینید\&.
.sp
اگر دو بار مشخص شود، علاوه بر این، تفاوت یکپارچه بین آنچه کامیت خواهد شد و فایل‌های درخت کاری، یعنی تغییرات استیج‌نشده فایل‌های ردگیری‌شده را نمایش می‌دهد\&.
.RE
.PP
\fB\-q\fR, \fB\-\-quiet\fR
.RS 4
پیام خلاصه کامیت را سرکوب می‌کند (نمایش نمی‌دهد)\&.
.RE
.PP
\fB\-\-dry\-run\fR
.RS 4
کامیتی ایجاد نمی‌کند، اما فهرستی از مسیرهایی که قرار است کامیت شوند، مسیرهایی با تغییرات محلی که کامیت‌نشده باقی می‌مانند و مسیرهایی که ردگیری‌نشده هستند را نمایش می‌دهد\&.
.RE
.PP
\fB\-\-status\fR
.RS 4
هنگام استفاده از یک ویرایشگر برای آماده‌سازی پیام کامیت، خروجی
\fBgit-status\fR(1)
را در الگوی پیام کامیت قرار می‌دهد\&. این گزینه به طور پیش‌فرض روشن است، اما می‌تواند برای لغو متغیر پیکربندی
\fBcommit\&.status\fR
استفاده شود\&.
.RE
.PP
\fB\-\-no\-status\fR
.RS 4
هنگام استفاده از یک ویرایشگر برای آماده‌سازی پیام کامیت پیش‌فرض، خروجی
\fBgit-status\fR(1)
را در الگوی پیام کامیت قرار نمی‌دهد\&.
.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\-\-\fR
.RS 4
هیچ‌یک از آرگومان‌های بعدی را به عنوان گزینه تفسیر نمی‌کند\&.
.RE
.PP
\fI<pathspec>\fR\&.\&.\&.
.RS 4
هنگامی که
\fI<pathspec>\fR
در خط فرمان داده می‌شود، محتویات فایل‌هایی را که با pathspec مطابقت دارند بدون ثبت تغییراتی که قبلاً به ایندکس اضافه شده‌اند کامیت می‌کند\&. محتویات این فایل‌ها علاوه بر آنچه از قبل آماده‌سازی شده است، برای کامیت بعدی نیز آماده‌سازی (استیج) می‌شوند\&.
.sp
برای جزئیات بیشتر، مدخل
\fIpathspec\fR
را در
\fBgitglossary\fR(7)
ببینید\&.
.RE
.SH "مثال‌ها (EXAMPLES)"
.sp
هنگام ثبت کارهای خود، محتوای فایل‌های تغییریافته در درخت کاری شما با دستور \fBgit\fR \fBadd\fR موقتاً در یک ناحیه آماده‌سازی موسوم به «ایندکس» (index) ذخیره می‌شود\&. یک فایل می‌تواند با دستور \fBgit\fR \fBrestore\fR \fB\-\-staged\fR \fI<file>\fR تنها در ایندکس (و نه در درخت کاری) به حالت آخرین کامیت بازگردانده شود، که عملاً اثر \fBgit\fR \fBadd\fR را خنثی کرده و از قرار گرفتن تغییرات این فایل در کامیت بعدی جلوگیری می‌کند\&. پس از ایجاد تدریجی وضعیتی که باید کامیت شود با این دستورات، از \fBgit\fR \fBcommit\fR (بدون هیچ پارامتر مسیر فایل) برای ثبت هر آنچه تا کنون آماده‌سازی شده است، استفاده می‌شود\&. این ابتدایی‌ترین شکل این دستور است\&. یک مثال:
.sp
.if n \{\
.RS 4
.\}
.nf
$ edit hello\&.c
$ git rm goodbye\&.c
$ git add hello\&.c
$ git commit
.fi
.if n \{\
.RE
.\}
.sp
.sp
به جای آماده‌سازی فایل‌ها پس از هر تغییر جداگانه، می‌توانید به \fBgit\fR \fBcommit\fR بگویید که تغییرات فایل‌هایی که محتوای آن‌ها در درخت کاری شما ردگیری می‌شود را متوجه شده و دستورات متناظر \fBgit\fR \fBadd\fR و \fBgit\fR \fBrm\fR را برای شما انجام دهد\&. به این ترتیب، اگر تغییر دیگری در درخت کاری شما وجود نداشته باشد، این مثال همان کار مثال قبلی را انجام می‌دهد:
.sp
.if n \{\
.RS 4
.\}
.nf
$ edit hello\&.c
$ rm goodbye\&.c
$ git commit \-a
.fi
.if n \{\
.RE
.\}
.sp
.sp
دستور \fBgit\fR \fBcommit\fR \fB\-a\fR ابتدا به درخت کاری شما نگاه می‌کند، متوجه می‌شود که \fBhello\&.c\fR را تغییر داده‌اید و \fBgoodbye\&.c\fR را حذف کرده‌اید، و اقدامات لازم \fBgit\fR \fBadd\fR و \fBgit\fR \fBrm\fR را برای شما انجام می‌دهد\&.
.sp
پس از آماده‌سازی تغییرات چندین فایل، می‌توانید با دادن نام مسیرها به \fBgit\fR \fBcommit\fR، ترتیبی که تغییرات در آن ثبت می‌شوند را تغییر دهید\&. هنگامی که نام مسیرها داده می‌شود، این دستور کامیتی ایجاد می‌کند که تنها تغییرات اعمال‌شده روی مسیرهای مشخص‌شده را ثبت می‌کند:
.sp
.if n \{\
.RS 4
.\}
.nf
$ edit hello\&.c hello\&.h
$ git add hello\&.c hello\&.h
$ edit Makefile
$ git commit Makefile
.fi
.if n \{\
.RE
.\}
.sp
.sp
این دستور کامیتی می‌سازد که تغییرات \fBMakefile\fR را ثبت می‌کند\&. تغییرات آماده‌سازی‌شده برای \fBhello\&.c\fR و \fBhello\&.h\fR در کامیت حاصل گنجانده نمی‌شوند\&. با این حال، تغییرات آن‌ها از دست نرفته است \(em آن‌ها همچنان آماده‌سازی‌شده هستند و صرفاً به عقب افتاده‌اند\&. پس از توالی بالا، اگر دستور زیر را اجرا کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git commit
.fi
.if n \{\
.RE
.\}
.sp
.sp
این کامیت دوم همان‌طور که انتظار می‌رود، تغییرات روی \fBhello\&.c\fR و \fBhello\&.h\fR را ثبت خواهد کرد\&.
.sp
پس از اینکه یک ادغام (که توسط \fBgit\fR \fBmerge\fR یا \fBgit\fR \fBpull\fR آغاز شده) به دلیل تداخل‌ها متوقف شود، مسیرهایی که بدون تداخل ادغام شده‌اند از قبل برای کامیت شدن توسط شما آماده‌سازی می‌شوند و مسیرهایی که دچار تداخل هستند در وضعیت ادغام‌نشده باقی می‌مانند\&. شما باید ابتدا با \fBgit\fR \fBstatus\fR بررسی کنید کدام مسیرها تداخل دارند و پس از رفع دستی آن‌ها در درخت کاری خود، نتیجه را طبق معمول با \fBgit\fR \fBadd\fR آماده‌سازی کنید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git status | grep unmerged
unmerged: hello\&.c
$ edit hello\&.c
$ git add hello\&.c
.fi
.if n \{\
.RE
.\}
.sp
.sp
پس از حل تداخل‌ها و آماده‌سازی نتیجه، دستور \fBgit\fR \fBls\-files\fR \fB\-u\fR دیگر مسیر دارای تداخل را ذکر نخواهد کرد\&. وقتی کارتان تمام شد، \fBgit\fR \fBcommit\fR را اجرا کنید تا در نهایت ادغام ثبت شود:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git commit
.fi
.if n \{\
.RE
.\}
.sp
.sp
همانند حالت ثبت تغییرات خودتان، می‌توانید از گزینه \fB\-a\fR برای صرفه‌جویی در تایپ استفاده کنید\&. یک تفاوت این است که در هنگام حل تداخل‌های ادغام، نمی‌توانید از \fBgit\fR \fBcommit\fR به همراه نام مسیرها برای تغییر ترتیب کامیت شدن تغییرات استفاده کنید، زیرا ادغام باید به عنوان یک کامیت واحد ثبت شود\&. در واقع، این دستور در صورت دریافت نام مسیرها از اجرا خودداری می‌کند (البته گزینه \fB\-i\fR را ببینید)\&.
.SH "اطلاعات کامیت (COMMIT INFORMATION)"
.sp
اطلاعات مؤلف و کامیت‌کننده در صورت تنظیم بودن، از متغیرهای محیطی زیر گرفته می‌شود:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBGIT_AUTHOR_NAME\fR
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBGIT_AUTHOR_EMAIL\fR
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBGIT_AUTHOR_DATE\fR
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBGIT_COMMITTER_NAME\fR
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBGIT_COMMITTER_EMAIL\fR
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fBGIT_COMMITTER_DATE\fR
.RE
.sp
(نکته: کاراکترهای «<»، «>» و «\en» حذف می‌شوند)
.sp
نام مؤلف و کامیت‌کننده بنا بر عرف شکلی از نام شخصی است (یعنی نامی که دیگر افراد شما را با آن خطاب می‌کنند)، هرچند گیت قالب خاصی را تحمیل یا الزامی نمی‌کند\&. هر کاراکتر یونیکد دلخواهی با رعایت محدودیت‌های ذکرشده در بالا می‌تواند استفاده شود\&. این نام هیچ تأثیری بر احراز هویت ندارد؛ برای آن، متغیر \fBcredential\&.username\fR را در \fBgit-config\fR(1) ببینید\&.
.sp
در صورتی که (برخی از) این متغیرهای محیطی تنظیم نشده باشند، اطلاعات از موارد پیکربندی \fBuser\&.name\fR و \fBuser\&.email\fR، یا در صورت عدم وجود، از متغیر محیطی \fBEMAIL\fR، یا در صورت تنظیم نبودن آن، از نام کاربری سیستم و نام میزبانی که برای ایمیل‌های ارسالی استفاده می‌شود (که از \fB/etc/mailname\fR گرفته شده و در صورت عدم وجود آن فایل، به نام میزبان کاملاً واجد شرایط بازمی‌گردد) اخذ می‌شود\&.
.sp
گزینه‌های \fBauthor\&.name\fR و \fBcommitter\&.name\fR و گزینه‌های ایمیل متناظر آن‌ها در صورت تنظیم بودن، بر \fBuser\&.name\fR و \fBuser\&.email\fR اولویت دارند و خودشان توسط متغیرهای محیطی بازنویسی می‌شوند\&.
.sp
کاربرد معمول این است که فقط متغیرهای \fBuser\&.name\fR و \fBuser\&.email\fR تنظیم شوند؛ گزینه‌های دیگر برای موارد استفاده پیچیده‌تر ارائه شده‌اند\&.
.SH "قالب‌های تاریخ (DATE FORMATS)"
.sp
متغیرهای محیطی \fBGIT_AUTHOR_DATE\fR و \fBGIT_COMMITTER_DATE\fR از قالب‌های تاریخ زیر پشتیبانی می‌کنند:
.PP
قالب داخلی گیت (Git internal format)
.RS 4
به صورت
\fI<unix\-timestamp>\fR
\fI<time\-zone\-offset>\fR
است، که در آن
\fI<unix\-timestamp>\fR
تعداد ثانیه‌ها از مبدأ یونیکس (UNIX epoch) است\&.
\fI<time\-zone\-offset>\fR
یک انحراف مثبت یا منفی از زمان هماهنگ جهانی (UTC) است\&. به عنوان مثال CET (که ۱ ساعت جلوتر از UTC است)
\fB+0100\fR
می‌باشد\&.
.sp
امن‌تر است که پیش از
\fI<unix\-timestamp>\fR
نویسه
\fB@\fR
قرار داده شود
(مثلاً
\fB@0\fR
\fB+0000\fR)،
که گیت را وادار می‌کند آن را به عنوان یک برچسب زمانی خام تفسیر کند\&. این کار برای مقادیر کمتر از ۱۰۰٬۰۰۰٬۰۰۰ (که کمتر از ۹ رقم دارند) الزامی است تا از اشتباه گرفته شدن با سایر قالب‌های تاریخ مانند
\fBYYYYMMDD\fR
جلوگیری شود\&.
.RE
.PP
RFC 2822
.RS 4
قالب استاندارد تاریخ مطابق با توضیحات RFC 2822، برای مثال
\fBThu\fR,
\fB07\fR
\fBApr\fR
\fB2005\fR
\fB22:13:13\fR
\fB+0200\fR\&.
.RE
.PP
ISO 8601
.RS 4
زمان و تاریخ مشخص‌شده توسط استاندارد ISO 8601، برای مثال
\fB2005\-04\-07T22:13:13\fR\&.
تجزیه‌کننده همچنین به جای کاراکتر
\fBT\fR
فاصله را نیز می‌پذیرد\&. بخش‌های کسری ثانیه نادیده گرفته می‌شوند، برای مثال
\fB2005\-04\-07T22:13:13\&.019\fR
به عنوان
\fB2005\-04\-07T22:13:13\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
علاوه بر این، بخش تاریخ در قالب‌های زیر نیز پذیرفته می‌شود:
\fBYYYY\&.MM\&.DD\fR,
\fBMM/DD/YYYY\fR
و
\fBDD\&.MM\&.YYYY\fR\&.
.sp .5v
.RE
.RE
.sp
علاوه بر تشخیص تمام قالب‌های تاریخ فوق، گزینه \fB\-\-date\fR تلاش خواهد کرد سایر قالب‌های تاریخ انسان‌محورتر، مانند تاریخ‌های نسبی نظیر «yesterday» یا «last Friday at noon» را نیز درک و تفسیر کند\&.
.SH "بررسی و توضیحات تکمیلی (DISCUSSION)"
.sp
اگرچه الزامی نیست، اما ایده خوبی است که پیام کامیت با یک سطر کوتاه (حداکثر ۵۰ نویسه) آغاز شود که تغییرات را خلاصه می‌کند، و پس از آن یک سطر خالی و سپس توضیح کامل‌تر و دقیق‌تری آورده شود\&. متن تا اولین سطر خالی در پیام کامیت، به عنوان عنوان کامیت در نظر گرفته می‌شود و این عنوان در سراسر گیت مورد استفاده قرار می‌گیرد\&. به عنوان مثال، \fBgit-format-patch\fR(1) یک کامیت را به ایمیل تبدیل می‌کند، و از این عنوان در سطر موضوع (Subject) و از بقیه پیام کامیت در بدنه نامه استفاده می‌کند\&.
.sp
گیت تا حدودی نسبت به کدگذاری نویسه‌ها (character encoding) بی‌تفاوت (مستقل) است\&.
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
محتوای شیءهای blob دنباله‌هایی از بایت‌ها هستند که تفسیر نمی‌شوند\&. هیچ تبدیل کدگذاری در سطح هسته وجود ندارد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
نام‌های مسیر با قالب تصحیح شکل C یونیکد (UTF\-8 normalization form C) کدگذاری می‌شوند\&. این امر برای شیءهای درخت، فایل ایندکس، نام‌های ارجاع، و همچنین نام‌های مسیر در آرگومان‌های خط فرمان، متغیرهای محیطی و فایل‌های پیکربندی (\fB\&.git/config\fR
(ببینید
\fBgit-config\fR(1))،
\fBgitignore\fR(5)،
\fBgitattributes\fR(5)
و
\fBgitmodules\fR(5))
اعمال می‌شود\&.
.sp
توجه داشته باشید که گیت در سطح هسته با نام‌های مسیر صرفاً به عنوان دنباله‌ای از بایت‌های غیر NUL رفتار می‌کند و هیچ تبدیل کدگذاری برای نام مسیرها وجود ندارد (به جز در مک و ویندوز)\&. بنابراین، استفاده از نام‌های مسیر غیر ASCII حتی در پلتفرم‌ها و سیستم‌های فایلی که از کدگذاری‌های قدیمی ASCII گسترش‌یافته استفاده می‌کنند نیز اکثراً کار خواهد کرد\&. با این حال، مخازن ایجادشده در چنین سیستم‌هایی روی سیستم‌های مبتنی بر UTF\-8 (مانند لینوکس، مک، ویندوز) به درستی کار نخواهند کرد و برعکس\&. علاوه بر این، بسیاری از ابزارهای مبتنی بر گیت صرفاً فرض می‌کنند که نام‌های مسیر UTF\-8 هستند و در نمایش صحیح سایر کدگذاری‌ها ناموفق خواهند بود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
پیام‌های وقایع‌نگاری کامیت معمولاً با UTF\-8 کدگذاری می‌شوند، اما سایر کدگذاری‌های ASCII گسترش‌یافته نیز پشتیبانی می‌شوند\&. این شامل ISO\-8859\-x، CP125x و بسیاری موارد دیگر است، اما
\fIنه\fR
UTF\-16/32، EBCDIC و کدگذاری‌های چندبایتی CJK (مانند GBK، Shift\-JIS، Big5، EUC\-x، CP9xx و غیره)\&.
.RE
.sp
اگرچه توصیه می‌کنیم که پیام‌های وقایع‌نگاری کامیت با UTF\-8 کدگذاری شوند، اما هم هسته و هم لایه کاربری گیت (Git Porcelain) به گونه‌ای طراحی شده‌اند که UTF\-8 را به پروژه‌ها تحمیل نکنند\&. اگر همه مشارکت‌کنندگان یک پروژه خاص استفاده از کدگذاری‌های قدیمی را راحت‌تر بدانند، گیت آن را منع نمی‌کند\&. با این وجود، چند نکته وجود دارد که باید در نظر داشته باشید\&.
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
دستورات
\fBgit\fR
\fBcommit\fR
و
\fBgit\fR
\fBcommit\-tree\fR
در صورتی که پیام وقایع‌نگاری کامیت داده‌شده به آن‌ها شبیه یک رشته معتبر UTF\-8 نباشد هشدار صادر می‌کنند، مگر اینکه صریحاً اعلام کنید که پروژه شما از یک کدگذاری قدیمی استفاده می‌کند\&. روش اعلام این موضوع، قرار دادن
\fBi18n\&.commitEncoding\fR
در فایل
\fB\&.git/config\fR
است، مانند این:
.sp
.if n \{\
.RS 4
.\}
.nf
[i18n]
        commitEncoding = ISO\-8859\-1
.fi
.if n \{\
.RE
.\}
.sp
شیءهای کامیت ایجادشده با تنظیمات فوق، مقدار
\fBi18n\&.commitEncoding\fR
را در هدر
\fBencoding\fR
خود ثبت می‌کنند\&. این کار برای کمک به افراد دیگری است که بعداً به آن‌ها نگاه می‌کنند\&. عدم وجود این هدر به این معنی است که پیام وقایع‌نگاری کامیت با UTF\-8 کدگذاری شده است\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
دستورات
\fBgit\fR
\fBlog\fR،
\fBgit\fR
\fBshow\fR،
\fBgit\fR
\fBblame\fR
و نظایر آن‌ها هدر
\fBencoding\fR
یک شیء کامیت را بررسی می‌کنند و سعی می‌کنند پیام وقایع‌نگاری را به UTF\-8 بازکدگذاری کنند مگر اینکه خلاف آن مشخص شده باشد\&. می‌توانید کدگذاری خروجی مورد نظر را با
\fBi18n\&.logOutputEncoding\fR
در فایل
\fB\&.git/config\fR
مشخص کنید، مانند این:
.sp
.if n \{\
.RS 4
.\}
.nf
[i18n]
        logOutputEncoding = ISO\-8859\-1
.fi
.if n \{\
.RE
.\}
.sp
اگر این متغیر پیکربندی را نداشته باشید، مقدار
\fBi18n\&.commitEncoding\fR
به جای آن استفاده می‌شود\&.
.RE
.sp
توجه داشته باشید که ما عمداً تصمیم گرفتیم هنگام ایجاد یک کامیت، پیام وقایع‌نگاری کامیت را برای تحمیل UTF\-8 در سطح شیء کامیت مجدداً کدگذاری نکنیم، زیرا بازکدگذاری به UTF\-8 لزوماً یک عملیات بازگشت‌پذیر نیست\&.
.SH "متغیرهای محیطی و پیکربندی (ENVIRONMENT AND CONFIGURATION VARIABLES)"
.sp
ویرایشگر مورداستفاده برای ویرایش پیام وقایع‌نگاری کامیت به ترتیب از متغیر محیطی \fBGIT_EDITOR\fR، متغیر پیکربندی \fBcore\&.editor\fR، متغیر محیطی \fBVISUAL\fR، یا متغیر محیطی \fBEDITOR\fR انتخاب خواهد شد\&. برای جزئیات بیشتر به \fBgit-var\fR(1) مراجعه کنید\&.
.sp
تمام موارد بالاتر از این سطر در این بخش از مستندات \fBgit-config\fR(1) برگرفته نشده است\&. محتوایی که در ادامه می‌آید همان مواردی است که در آنجا یافت می‌شود:
.PP
\fBcommit\&.cleanup\fR
.RS 4
این تنظیم، مقدار پیش‌فرض گزینه
\fB\-\-cleanup\fR
در
\fBgit\fR
\fBcommit\fR
را بازنویسی می‌کند\&. تغییر دادن پیش‌فرض زمانی می‌تواند مفید باشد که همیشه می‌خواهید سطرهایی را که با نویسه توضیح (
\fBcore\&.commentChar\fR،
پیش‌فرض #) شروع می‌شوند در پیام وقایع‌نگاری خود نگه دارید؛ در این صورت دستور
\fBgit\fR
\fBconfig\fR
\fBcommit\&.cleanup\fR
\fBwhitespace\fR
را اجرا می‌کنید (توجه داشته باشید که اگر این کار را انجام دهید، باید سطرهای راهنما را که با نویسه توضیح در قالب پیام کامیت شروع می‌شوند، خودتان حذف کنید)\&.
.RE
.PP
\fBcommit\&.gpgSign\fR
.RS 4
یک مقدار بولی (boolean) برای تعیین اینکه آیا همه کامیت‌ها باید با GPG امضا شوند یا خیر\&. استفاده از این گزینه هنگام انجام عملیاتی مانند بازنشانی پایه (rebase) می‌تواند منجر به امضا شدن تعداد زیادی کامیت شود\&. ممکن است استفاده از یک عامل احراز هویت (agent) برای جلوگیری از تایپ چندباره گذرواژه GPG مناسب باشد\&.
.RE
.PP
\fBcommit\&.status\fR
.RS 4
یک مقدار بولی برای فعال/غیرفعال کردن گنجاندن اطلاعات وضعیت در قالب پیام کامیت هنگام استفاده از یک ویرایشگر برای آماده‌سازی پیام کامیت\&. مقدار پیش‌فرض
\fBtrue\fR
است\&.
.RE
.PP
\fBcommit\&.template\fR
.RS 4
تعیین نام مسیر فایلی که به عنوان قالب برای پیام‌های کامیت جدید استفاده شود\&.
.RE
.PP
\fBcommit\&.verbose\fR
.RS 4
یک مقدار بولی یا عدد صحیح (int) برای تعیین سطح پرگویی (verbosity) در
\fBgit\fR
\fBcommit\fR\&.
.RE
.SH "قلاب‌ها (HOOKS)"
.sp
این دستور می‌تواند قلاب‌های \fBcommit\-msg\fR، \fBprepare\-commit\-msg\fR، \fBpre\-commit\fR، \fBpost\-commit\fR و \fBpost\-rewrite\fR را اجرا کند\&. برای اطلاعات بیشتر \fBgithooks\fR(5) را ببینید\&.
.SH "فایل‌ها (FILES)"
.PP
\fB$GIT_DIR/COMMIT_EDITMSG\fR
.RS 4
این فایل حاوی پیام کامیتِ مربوط به یک کامیت در حال انجام است\&. اگر
\fBgit\fR
\fBcommit\fR
قبل از ایجاد یک کامیت به دلیل خطا خارج شود، هر پیام کامیتی که توسط کاربر ارائه شده باشد (مثلاً در یک نشست ویرایشگر) در این فایل در دسترس خواهد بود، اما با اجرای بعدی دستور
\fBgit\fR
\fBcommit\fR
بازنویسی خواهد شد\&.
.RE
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-add\fR(1), \fBgit-rm\fR(1), \fBgit-mv\fR(1), \fBgit-merge\fR(1), \fBgit-commit-tree\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)