نام (NAME)

git-commit - ثبت تغییرات در مخزن

خلاصه دستور (SYNOPSIS)

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<mode>]] [--amend]
           [--dry-run] [(-c | -C | --squash) <commit> | --fixup [(amend|reword):]<commit>]
           [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
           [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
           [--date=<date>] [--cleanup=<mode>] [--[no-]status]
           [-i | -o] [--pathspec-from-file=<file> [--pathspec-file-nul]]
           [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
           [--] [<pathspec>...]

توضیحات (DESCRIPTION)

یک کامیت جدید شامل محتویات فعلی ایندکس و پیام گزارش ارائه‌شده برای توصیف تغییرات ایجاد می‌کند. کامیت جدید فرزند مستقیم HEAD است، که معمولاً نوک شاخه فعلی می‌باشد، و شاخه به‌روزرسانی می‌شود تا به آن اشاره کند (مگر اینکه هیچ شاخه‌ای با درخت کاری مرتبط نباشد، که در این صورت همان‌طور که در git-checkout(1) شرح داده شده است، HEAD در وضعیت «جداشده» (detached) قرار دارد).

محتوایی که قرار است کامیت شود را می‌توان به چندین روش مشخص کرد:

گزینه --dry-run می‌تواند برای دریافت خلاصه‌ای از آنچه که طبق هر یک از روش‌های بالا با دادن همان مجموعه پارامترها (گزینه‌ها و مسیرها) در کامیت بعدی گنجانده می‌شود، استفاده شود.

اگر یک کامیت ایجاد کردید و بلافاصله پس از آن متوجه اشتباهی شدید، می‌توانید با استفاده از git reset آن را برگردانید و اصلاح کنید.

گزینه‌ها (OPTIONS)

-a, --all

-p, --patch

-U<n>, --unified=<n>

--inter-hunk-context=<n>

-C <commit>, --reuse-message=<commit>

-c <commit>, --reedit-message=<commit>

--fixup=[(amend|reword):]<commit>

--squash=<commit>

--reset-author

--short

--branch

--porcelain

--long

-z, --null

-F <file>, --file=<file>

--author=<author>

--date=<date>

-m <msg>, --message=<msg>

-t <file>, --template=<file>

-s, --signoff, --no-signoff

--trailer <token>[(=|:)<value>]

-n, --verify, --no-verify

--allow-empty

--allow-empty-message

--cleanup=<mode>

# ------------------------ >8 ------------------------

-e, --edit

--no-edit

--amend

$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD

--no-post-rewrite

-i, --include

-o, --only

--pathspec-from-file=<file>

--pathspec-file-nul

-u[<mode>], --untracked-files[=<mode>]

-v, --verbose

-q, --quiet

--dry-run

--status

--no-status

-S[<key-id>], --gpg-sign[=<key-id>], --no-gpg-sign

--

<pathspec>...

مثال‌ها (EXAMPLES)

هنگام ثبت کارهای خود، محتوای فایل‌های تغییریافته در درخت کاری شما با دستور git add موقتاً در یک ناحیه آماده‌سازی موسوم به «ایندکس» (index) ذخیره می‌شود. یک فایل می‌تواند با دستور git restore --staged <file> تنها در ایندکس (و نه در درخت کاری) به حالت آخرین کامیت بازگردانده شود، که عملاً اثر git add را خنثی کرده و از قرار گرفتن تغییرات این فایل در کامیت بعدی جلوگیری می‌کند. پس از ایجاد تدریجی وضعیتی که باید کامیت شود با این دستورات، از git commit (بدون هیچ پارامتر مسیر فایل) برای ثبت هر آنچه تا کنون آماده‌سازی شده است، استفاده می‌شود. این ابتدایی‌ترین شکل این دستور است. یک مثال:

$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit

به جای آماده‌سازی فایل‌ها پس از هر تغییر جداگانه، می‌توانید به git commit بگویید که تغییرات فایل‌هایی که محتوای آن‌ها در درخت کاری شما ردگیری می‌شود را متوجه شده و دستورات متناظر git add و git rm را برای شما انجام دهد. به این ترتیب، اگر تغییر دیگری در درخت کاری شما وجود نداشته باشد، این مثال همان کار مثال قبلی را انجام می‌دهد:

$ edit hello.c
$ rm goodbye.c
$ git commit -a

دستور git commit -a ابتدا به درخت کاری شما نگاه می‌کند، متوجه می‌شود که hello.c را تغییر داده‌اید و goodbye.c را حذف کرده‌اید، و اقدامات لازم git add و git rm را برای شما انجام می‌دهد.

پس از آماده‌سازی تغییرات چندین فایل، می‌توانید با دادن نام مسیرها به git commit، ترتیبی که تغییرات در آن ثبت می‌شوند را تغییر دهید. هنگامی که نام مسیرها داده می‌شود، این دستور کامیتی ایجاد می‌کند که تنها تغییرات اعمال‌شده روی مسیرهای مشخص‌شده را ثبت می‌کند:

$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile

این دستور کامیتی می‌سازد که تغییرات Makefile را ثبت می‌کند. تغییرات آماده‌سازی‌شده برای hello.c و hello.h در کامیت حاصل گنجانده نمی‌شوند. با این حال، تغییرات آن‌ها از دست نرفته است — آن‌ها همچنان آماده‌سازی‌شده هستند و صرفاً به عقب افتاده‌اند. پس از توالی بالا، اگر دستور زیر را اجرا کنید:

$ git commit

این کامیت دوم همان‌طور که انتظار می‌رود، تغییرات روی hello.c و hello.h را ثبت خواهد کرد.

پس از اینکه یک ادغام (که توسط git merge یا git pull آغاز شده) به دلیل تداخل‌ها متوقف شود، مسیرهایی که بدون تداخل ادغام شده‌اند از قبل برای کامیت شدن توسط شما آماده‌سازی می‌شوند و مسیرهایی که دچار تداخل هستند در وضعیت ادغام‌نشده باقی می‌مانند. شما باید ابتدا با git status بررسی کنید کدام مسیرها تداخل دارند و پس از رفع دستی آن‌ها در درخت کاری خود، نتیجه را طبق معمول با git add آماده‌سازی کنید:

$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c

پس از حل تداخل‌ها و آماده‌سازی نتیجه، دستور git ls-files -u دیگر مسیر دارای تداخل را ذکر نخواهد کرد. وقتی کارتان تمام شد، git commit را اجرا کنید تا در نهایت ادغام ثبت شود:

$ git commit

همانند حالت ثبت تغییرات خودتان، می‌توانید از گزینه -a برای صرفه‌جویی در تایپ استفاده کنید. یک تفاوت این است که در هنگام حل تداخل‌های ادغام، نمی‌توانید از git commit به همراه نام مسیرها برای تغییر ترتیب کامیت شدن تغییرات استفاده کنید، زیرا ادغام باید به عنوان یک کامیت واحد ثبت شود. در واقع، این دستور در صورت دریافت نام مسیرها از اجرا خودداری می‌کند (البته گزینه -i را ببینید).

اطلاعات کامیت (COMMIT INFORMATION)

اطلاعات مؤلف و کامیت‌کننده در صورت تنظیم بودن، از متغیرهای محیطی زیر گرفته می‌شود:

(نکته: کاراکترهای «<»، «>» و «\n» حذف می‌شوند)

نام مؤلف و کامیت‌کننده بنا بر عرف شکلی از نام شخصی است (یعنی نامی که دیگر افراد شما را با آن خطاب می‌کنند)، هرچند گیت قالب خاصی را تحمیل یا الزامی نمی‌کند. هر کاراکتر یونیکد دلخواهی با رعایت محدودیت‌های ذکرشده در بالا می‌تواند استفاده شود. این نام هیچ تأثیری بر احراز هویت ندارد؛ برای آن، متغیر credential.username را در git-config(1) ببینید.

در صورتی که (برخی از) این متغیرهای محیطی تنظیم نشده باشند، اطلاعات از موارد پیکربندی user.name و user.email، یا در صورت عدم وجود، از متغیر محیطی EMAIL، یا در صورت تنظیم نبودن آن، از نام کاربری سیستم و نام میزبانی که برای ایمیل‌های ارسالی استفاده می‌شود (که از /etc/mailname گرفته شده و در صورت عدم وجود آن فایل، به نام میزبان کاملاً واجد شرایط بازمی‌گردد) اخذ می‌شود.

گزینه‌های author.name و committer.name و گزینه‌های ایمیل متناظر آن‌ها در صورت تنظیم بودن، بر user.name و user.email اولویت دارند و خودشان توسط متغیرهای محیطی بازنویسی می‌شوند.

کاربرد معمول این است که فقط متغیرهای user.name و user.email تنظیم شوند؛ گزینه‌های دیگر برای موارد استفاده پیچیده‌تر ارائه شده‌اند.

قالب‌های تاریخ (DATE FORMATS)

متغیرهای محیطی GIT_AUTHOR_DATE و GIT_COMMITTER_DATE از قالب‌های تاریخ زیر پشتیبانی می‌کنند:

قالب داخلی گیت (Git internal format)

RFC 2822

ISO 8601

علاوه بر تشخیص تمام قالب‌های تاریخ فوق، گزینه --date تلاش خواهد کرد سایر قالب‌های تاریخ انسان‌محورتر، مانند تاریخ‌های نسبی نظیر «yesterday» یا «last Friday at noon» را نیز درک و تفسیر کند.

بررسی و توضیحات تکمیلی (DISCUSSION)

اگرچه الزامی نیست، اما ایده خوبی است که پیام کامیت با یک سطر کوتاه (حداکثر ۵۰ نویسه) آغاز شود که تغییرات را خلاصه می‌کند، و پس از آن یک سطر خالی و سپس توضیح کامل‌تر و دقیق‌تری آورده شود. متن تا اولین سطر خالی در پیام کامیت، به عنوان عنوان کامیت در نظر گرفته می‌شود و این عنوان در سراسر گیت مورد استفاده قرار می‌گیرد. به عنوان مثال، git-format-patch(1) یک کامیت را به ایمیل تبدیل می‌کند، و از این عنوان در سطر موضوع (Subject) و از بقیه پیام کامیت در بدنه نامه استفاده می‌کند.

گیت تا حدودی نسبت به کدگذاری نویسه‌ها (character encoding) بی‌تفاوت (مستقل) است.

اگرچه توصیه می‌کنیم که پیام‌های وقایع‌نگاری کامیت با UTF-8 کدگذاری شوند، اما هم هسته و هم لایه کاربری گیت (Git Porcelain) به گونه‌ای طراحی شده‌اند که UTF-8 را به پروژه‌ها تحمیل نکنند. اگر همه مشارکت‌کنندگان یک پروژه خاص استفاده از کدگذاری‌های قدیمی را راحت‌تر بدانند، گیت آن را منع نمی‌کند. با این وجود، چند نکته وجود دارد که باید در نظر داشته باشید.

[i18n]
        commitEncoding = ISO-8859-1

[i18n]
        logOutputEncoding = ISO-8859-1

توجه داشته باشید که ما عمداً تصمیم گرفتیم هنگام ایجاد یک کامیت، پیام وقایع‌نگاری کامیت را برای تحمیل UTF-8 در سطح شیء کامیت مجدداً کدگذاری نکنیم، زیرا بازکدگذاری به UTF-8 لزوماً یک عملیات بازگشت‌پذیر نیست.

متغیرهای محیطی و پیکربندی (ENVIRONMENT AND CONFIGURATION VARIABLES)

ویرایشگر مورداستفاده برای ویرایش پیام وقایع‌نگاری کامیت به ترتیب از متغیر محیطی GIT_EDITOR، متغیر پیکربندی core.editor، متغیر محیطی VISUAL، یا متغیر محیطی EDITOR انتخاب خواهد شد. برای جزئیات بیشتر به git-var(1) مراجعه کنید.

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

commit.cleanup

commit.gpgSign

commit.status

commit.template

commit.verbose

قلاب‌ها (HOOKS)

این دستور می‌تواند قلاب‌های commit-msg، prepare-commit-msg، pre-commit، post-commit و post-rewrite را اجرا کند. برای اطلاعات بیشتر githooks(5) را ببینید.

فایل‌ها (FILES)

$GIT_DIR/COMMIT_EDITMSG

همچنین ببینید (SEE ALSO)

git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)

گیت (GIT)

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