git-commit - آنلاین در ابر

برنامه:

نام

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

خلاصه

دستگاه گوارش مرتکب شدن [-a | --تعاملی | --patch] [-s] [-v] [-u ] [--اصلاح]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -m ] [--بازنشانی-نویسنده] [--اجازه دادن-خالی]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--تاریخ= ] [--پاکسازی= ] [--[هیچ وضعیت]
[-i | -o] [-S[ ]] [--] [ ...]

شرح

محتویات فعلی ایندکس را در یک commit جدید به همراه یک پیام گزارش از طرف ذخیره می کند
کاربر در حال توصیف تغییرات

محتوایی که باید اضافه شود را می توان به چند روش مشخص کرد:

1. با استفاده از دستگاه گوارش اضافه کردن برای افزودن تدریجی تغییرات به شاخص قبل از استفاده از مرتکب شدن
دستور (توجه: حتی فایل های اصلاح شده باید "اضافه شوند").

2. با استفاده از دستگاه گوارش rm برای حذف فایل ها از درخت کار و فهرست، دوباره قبل از
با استفاده از مرتکب شدن فرمان؛

3. با فهرست کردن فایل ها به عنوان آرگومان های مرتکب شدن دستور، در این صورت commit خواهد شد
تغییرات ایجاد شده در ایندکس را نادیده بگیرید و در عوض محتوای فعلی را ثبت کنید
فایل های فهرست شده (که باید قبلاً برای Git شناخته شده باشند)؛

4. با استفاده از سوئیچ -a با مرتکب شدن دستور به طور خودکار "افزودن" تغییرات از همه
فایل های شناخته شده (یعنی همه فایل هایی که قبلاً در فهرست فهرست شده اند) و به صورت خودکار
فایل‌های "rm" در فهرستی که از درخت کار حذف شده‌اند و سپس اجرا کنید
تعهد واقعی؛

5. با استفاده از سوئیچ های --interactive یا --patch با مرتکب شدن دستور برای تصمیم گیری
توسط یکی که فایل ها یا هانک ها باید بخشی از commit باشند، قبل از نهایی کردن
عمل. بخش "حالت تعاملی" را ببینید git-add(1) برای یادگیری نحوه کار کردن
این حالت ها

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

اگر متعهد شوید و بلافاصله پس از آن اشتباهی را پیدا کنید، می توانید از آن خلاص شوید
آن را با دستگاه گوارش تنظیم مجدد.

OPTIONS

-a، --همه
دستور را بگویید که فایل هایی که اصلاح و حذف شده اند را به صورت خودکار مرحله بندی کند، اما
فایل های جدیدی که به Git نگفته اید تحت تأثیر قرار نمی گیرند.

-p، --patch
از رابط انتخاب پچ تعاملی برای انتخاب تغییراتی که باید انجام شوند استفاده کنید. دیدن
git-add(1) برای جزئیات.

-C ، --reuse-message=
یک شی commit موجود را بگیرید و از پیام log و نویسنده مجددا استفاده کنید
اطلاعات (از جمله مهر زمانی) هنگام ایجاد commit.

-ج ، --reedit-message=
پسندیدن -C، اما با -c ویرایشگر فراخوانی می شود تا کاربر بتواند بیشتر آن را ویرایش کند
ارتکاب پیام

--تثبیت=
یک پیام commit برای استفاده با rebase --autosquash بسازید. پیام commit خواهد شد
خط موضوع از commit مشخص شده با پیشوند "fixup!" باشد. دیدن git-
تخفیف(1) برای جزئیات.

کدو حلوایی =
یک پیام commit برای استفاده با rebase --autosquash بسازید. پیام commit
خط موضوع از commit مشخص شده با پیشوند "squash!" گرفته شده است. می تواند باشد
با گزینه های پیام commit اضافی (-m/-c/-C/-F) استفاده می شود. دیدن git-rebase(1) برای
جزئیات.

--بازنشانی-نویسنده
هنگامی که با گزینه های -C/-c/--amend استفاده می شود، یا هنگام انجام پس از تضاد aa
cherry-pick، اعلام کنید که نویسندگی commit حاصل اکنون متعلق به
مرتکب این همچنین مهر زمانی نویسنده را تجدید می کند.

--کوتاه
هنگام اجرای خشک، خروجی را در قالب کوتاه ارائه دهید. دیدن وضعیت git(1) برای
جزئیات. دلالت بر --dry-run دارد.

--شاخه
اطلاعات شعبه و ردیابی را حتی در قالب کوتاه نشان دهید.

--ظروف چینی
هنگام اجرای خشک کردن، خروجی را در قالبی آماده کنید. دیدن وضعیت git(1)
برای جزئیات دلالت بر --dry-run دارد.

--طولانی
هنگام اجرای خشک، خروجی را با فرمت طولانی ارائه دهید. دلالت بر --dry-run دارد.

-z، --null
هنگام نمایش خروجی وضعیت کوتاه یا چینی، ورودی‌های خروجی وضعیت را خاتمه دهید
با NUL، به جای LF. اگر هیچ فرمتی داده نشود، به معنای فرمت خروجی --porcelain است.

-اف ، --file=
پیام commit را از فایل داده شده بگیرید. استفاده کنید - برای خواندن پیام از
ورودی استاندارد

--نویسنده=
نویسنده commit را لغو کنید. یک نویسنده صریح را با استفاده از استاندارد AU Thor مشخص کنید
<[ایمیل محافظت شده]> قالب. در غیر این صورت یک الگو فرض می شود و استفاده می شود
برای جستجوی یک commit موجود توسط آن نویسنده (به عنوان مثال rev-list --all -i
--نویسنده= ) سپس نویسنده commit از اولین چنین commit یافت شده کپی می شود.

--تاریخ=
تاریخ نویسنده استفاده شده در commit را نادیده بگیرید.

-m ، --پیام=
داده شده را استفاده کنید به عنوان پیام commit. اگر چندین گزینه -m داده شود، آنها
مقادیر به عنوان پاراگراف های جداگانه به هم متصل می شوند.

-t ، --قالب=
هنگام ویرایش پیام commit، ویرایشگر را با محتویات فایل داده شده شروع کنید.
متغیر پیکربندی commit.template اغلب برای دادن این گزینه استفاده می شود
به طور ضمنی به فرمان این مکانیسم می تواند توسط پروژه هایی که می خواهند راهنمایی کنند استفاده شود
شرکت کنندگان با نکاتی در مورد اینکه به چه ترتیبی در پیام بنویسند. اگر
کاربر بدون ویرایش پیام از ویرایشگر خارج می شود، commit لغو می شود. این هیچ
هنگامی که یک پیام با ابزارهای دیگر داده می شود، به عنوان مثال با گزینه های -m یا -F، تأثیر می گذارد.

-s، --signoff
خط Signed-off-by توسط committer را در انتهای پیام commit log اضافه کنید. در
معنای signoff به پروژه بستگی دارد، اما معمولاً آن متعهد را تأیید می کند
حق ارسال این اثر را تحت همان مجوز دارد و با یک توسعه دهنده موافقت می کند
گواهی مبدا (نگاه کنید به http://developercertificate.org/ برای اطلاعات بیشتر).

-n، --no-verify
این گزینه قلاب های pre-commit و commit-msg را دور می زند. همچنین ببینید githooks(5).

--اجازه-خالی
معمولاً ضبط یک commit که دقیقاً همان درخت commit والد آن را دارد، a است
اشتباه است و دستور شما را از انجام چنین تعهدی باز می دارد. این گزینه دور می زند
ایمنی، و در درجه اول برای استفاده توسط اسکریپت های رابط SCM خارجی است.

--allow-empty-message
مانند --allow-empty این دستور در درجه اول برای استفاده توسط اسکریپت های رابط SCM خارجی است.
این به شما امکان می دهد بدون استفاده از لوله کشی یک commit با یک پیام commit خالی ایجاد کنید
دستوراتی مانند git-commit-tree(1).

--پاکسازی=
این گزینه تعیین می کند که چگونه پیام commit ارائه شده باید قبل از آن پاک شود
متعهد شدن در می تواند نوار، فضای خالی، کلمه به کلمه، قیچی یا پیش فرض باشد.

نوار
خطوط خالی پیشرو و دنباله دار، فضای خالی انتهایی، تفسیر و
خطوط خالی متوالی را جمع کنید.

فضای سفید
همان نوار به جز #نظر حذف نمی شود.

تحت اللفظی
به هیچ وجه پیام را تغییر ندهید.

قیچی
مانند فضای خالی، با این تفاوت که همه چیز از (و شامل) خط "#
------------------------> 8 ----------------------- اگر پیام کوتاه شود
قرار است ویرایش شود "#" را می توان با core.commentChar سفارشی کرد.

به طور پیش فرض
اگر قرار است پیام ویرایش شود، مانند نوار است. در غیر این صورت فضای خالی.

پیش فرض را می توان با commit.cleanup متغیر پیکربندی (نگاه کنید به git-
پیکربندی(1).

-e، --edit
پیام گرفته شده از فایل با -F، خط فرمان با -m، و از commit شی با
-C معمولاً به عنوان پیام گزارش commit بدون تغییر استفاده می شود. این گزینه به شما امکان می دهد بیشتر
پیام گرفته شده از این منابع را ویرایش کنید.

-- بدون ویرایش
از پیام commit انتخاب شده بدون راه اندازی ویرایشگر استفاده کنید. مثلا git commit
--amend --no-edit یک commit را بدون تغییر پیام commit آن اصلاح می کند.

--اصلاح
با ایجاد یک commit جدید، نوک شاخه فعلی را جایگزین کنید. درخت ثبت شده است
طبق معمول (شامل اثر گزینه های -i و -o و صریح) تهیه شده است
pathspec)، و پیام commit اصلی به عنوان نقطه شروع استفاده می شود،
به جای یک پیام خالی، زمانی که هیچ پیام دیگری از خط فرمان مشخص نشده است
از طریق گزینه هایی مانند -m، -F، -c، و غیره. commit جدید دارای همان پدر و مادر و نویسنده است.
گزینه فعلی (گزینه --reset-author می تواند این را متضاد کند).

معادل تقریبی برای:

بازنشانی git $ --soft HEAD^
$ ... کار دیگری انجام دهید تا درخت مناسب را پیدا کنید ...
$ git commit -c ORIG_HEAD

اما می تواند برای اصلاح یک تعهد ادغام استفاده شود.

اگر یک تعهد را اصلاح کنید، باید پیامدهای بازنویسی تاریخ را درک کنید
قبلا منتشر شده است. (به بخش "بازیابی از UPSTREAM REBASE" مراجعه کنید git-
تخفیف(1).)

--بدون بازنویسی
قلاب پس از بازنویسی را دور بزنید.

-من شامل می کنم
قبل از انجام یک commit از محتویات مرحله‌ای تا کنون، محتویات مسیرها را مرحله‌بندی کنید
در خط فرمان نیز داده شده است. معمولاً این چیزی نیست که شما می خواهید مگر اینکه باشید
انعقاد ادغام متناقض

-o، --فقط
با در نظر گرفتن محتویات درخت کاری به روز شده مسیرهای مشخص شده، یک تعهد ایجاد کنید
خط فرمان، بدون توجه به محتوایی که برای مسیرهای دیگر مرحله بندی شده است.
این حالت پیش فرض عملکرد است دستگاه گوارش مرتکب شدن اگر مسیری در آن داده شود
خط فرمان که در این صورت می توان این گزینه را حذف کرد. اگر این گزینه مشخص شده باشد
با --اصلاح، پس نیازی به تعیین مسیر نیست که می توان از آن برای اصلاح استفاده کرد
آخرین کامیت بدون انجام تغییراتی که قبلاً انجام شده است.

-u[ ]، --untracked-files[= ]
نمایش فایل های ردیابی نشده

پارامتر حالت اختیاری است (پیش‌فرض به تمام) و برای تعیین دسته بندی استفاده می شود
فایل های ردیابی نشده هنگامی که -u استفاده نمی شود، پیش فرض است طبیعی، یعنی ردیابی نشده را نشان می دهد
فایل ها و دایرکتوری ها

گزینه های ممکن عبارتند از:

· نه - نمایش هیچ فایل ردیابی نشده

· طبیعی - فایل ها و دایرکتوری های ردیابی نشده را نشان می دهد

· تمام - همچنین فایل های فردی را در فهرست های ردیابی نشده نشان می دهد.

پیش فرض را می توان با استفاده از پیکربندی status.showUntrackedFiles تغییر داد
متغیر مستند شده در گیت(1).

-v، -- پرحرف
تفاوت یکپارچه بین تعهد HEAD و آنچه در انتهای آن متعهد می شود را نشان دهید
الگوی پیام commit برای کمک به کاربر برای توصیف commit با یادآوری چه
تغییراتی که commit دارد. توجه داشته باشید که این خروجی تفاوت خطوط آن را پیشوند ندارد
با #. این تفاوت بخشی از پیام commit نخواهد بود.

اگر دو بار مشخص شد، علاوه بر این، تفاوت یکپارچه بین آنچه باید متعهد شود را نشان دهید
و فایل های درخت کاری، یعنی تغییرات بدون مرحله به فایل های ردیابی شده.

-q، --آرام
پیام خلاصه commit را سرکوب کنید.

-- خشک اجرا شود
یک commit ایجاد نکنید، بلکه لیستی از مسیرهایی که قرار است متعهد شوند را نشان دهید
تغییرات محلی که بدون تعهد رها می شوند و مسیرهایی که پیگیری نمی شوند.

--وضعیت
شامل خروجی از وضعیت git(1) در قالب پیام commit هنگام استفاده از یک
ویرایشگر برای آماده کردن پیام commit. پیش‌فرض روشن است، اما می‌توان از آن برای لغو استفاده کرد
متغیر پیکربندی commit.status.

--هیچ وضعیت
خروجی را درج نکنید وضعیت git(1) در قالب پیام commit هنگام استفاده
یک ویرایشگر برای آماده کردن پیام commit پیش فرض.

-S[ ]، --gpg-sign[= ]
GPG-sign متعهد می شود. آرگومان keyid اختیاری است و به صورت پیش فرض روی committer قرار می گیرد
هویت؛ اگر مشخص شده باشد، باید بدون فاصله به گزینه چسبیده شود.

--no-gpg-sign
متغیر پیکربندی Countermand commit.gpgSign که برای اجبار هر یک تنظیم شده است
متعهد به امضا شدن

--
هیچ استدلال دیگری را به عنوان گزینه تفسیر نکنید.

...
هنگامی که فایل‌ها در خط فرمان داده می‌شوند، دستور محتویات آن را commit می‌کند
فایل‌های نام‌گذاری شده، بدون ثبت تغییرات قبلاً انجام شده. محتویات این فایل ها
همچنین برای commit بعدی در بالای آنچه قبلاً اجرا شده است، اجرا می شوند.

تاریخ فرمها

متغیرهای محیطی GIT_AUTHOR_DATE، GIT_COMMITTER_DATE و گزینه --date
از فرمت های تاریخ زیر پشتیبانی کنید:

فرمت داخلی Git
این است ، جایی که تعداد است
چند ثانیه از دوران یونیکس. جبران مثبت یا منفی است
از UTC به عنوان مثال CET (که 2 ساعت جلوتر از UTC است) +0200 است.

RFC 2822
قالب استاندارد ایمیل همانطور که توسط RFC 2822 توضیح داده شده است، به عنوان مثال پنجشنبه، 07 آوریل 2005
22:13:13 +0200.

ISO 8601
زمان و تاریخ مشخص شده توسط استاندارد ISO 8601، به عنوان مثال 2005-04-07T22:13:13. در
تجزیه کننده یک فاصله را به جای کاراکتر T نیز می پذیرد.

توجه داشته باشید
علاوه بر این، بخش تاریخ در قالب های زیر پذیرفته می شود: YYYY.MM.DD،
MM/DD/YYYY و DD.MM.YYYY.

مثال ها

هنگام ضبط کار خود، محتویات فایل های اصلاح شده در درخت کاری شما هستند
به طور موقت در یک منطقه مرحله بندی به نام "شاخص" با ذخیره می شود دستگاه گوارش اضافه کردن. یک فایل می تواند باشد
فقط در شاخص اما نه در درخت کاری به آخرین commit بازگشت
با git reset HEAD -- ، که به طور موثر برمی گردد دستگاه گوارش اضافه کردن و از تغییرات جلوگیری می کند
به این فایل از شرکت در commit بعدی. پس از ساختن دولت به
به صورت تدریجی با این دستورات، git commit (بدون هیچ پارامتر نام مسیر)
برای ضبط آنچه تاکنون به صحنه رفته است استفاده می شود. این ابتدایی ترین شکل دستور است.
یک مثال:

$ ویرایش hello.c
$ git rm خداحافظ.c
$ git اضافه کنید hello.c
$ git commit

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

$ ویرایش hello.c
$ rm خداحافظ.c
$ git commit -a

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

پس از انجام تغییرات در بسیاری از فایل‌ها، می‌توانید ترتیب ثبت تغییرات را تغییر دهید.
با دادن نام مسیر به git commit. هنگامی که نام مسیر داده می شود، دستور یک commit می کند
که فقط تغییرات ایجاد شده در مسیرهای نامگذاری شده را ثبت می کند:

$ ویرایش hello.c hello.h
$ git اضافه کنید hello.c hello.h
$ ویرایش Makefile
$ git commit Makefile

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

$ git commit

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

پس از یک ادغام (ابتدا توسط دستگاه گوارش ادغام کردن or دستگاه گوارش کشیدن) به دلیل درگیری متوقف می شود، تمیز
مسیرهای ادغام شده قبلاً برای شما آماده شده است و مسیرهایی که با هم تضاد دارند، هستند
در حالت ادغام نشده باقی مانده است. ابتدا باید بررسی کنید که کدام مسیرها در تضاد هستند دستگاه گوارش
وضعیت و پس از تثبیت دستی آنها در درخت کاری خود، نتیجه را به صورت مرحله بندی می کنید
معمول با دستگاه گوارش اضافه کردن:

وضعیت git $ | grep ادغام نشد
unmerged: hello.c
$ ویرایش hello.c
$ git اضافه کنید hello.c

پس از رفع تضادها و مرحله بندی نتیجه، git ls-files -u ذکر را متوقف می کند
مسیر متضاد وقتی کارتان تمام شد، git commit را اجرا کنید تا در نهایت ادغام ضبط شود:

$ git commit

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

بحث

اگرچه لازم نیست، اما ایده خوبی است که پیام commit را با یک کوتاه شروع کنید
(کمتر از 50 کاراکتر) خطی که تغییرات را خلاصه می کند، به دنبال آن یک خط خالی و سپس a
توضیحات کامل تر متن تا اولین خط خالی در یک پیام commit است
به عنوان عنوان commit در نظر گرفته می شود و این عنوان در سراسر Git استفاده می شود. مثلا، git-
قالب-پچ(1) یک commit را به ایمیل تبدیل می کند و از عنوان آن در خط موضوع و
بقیه ارتکاب در بدن است.

Git تا حدودی رمزگذاری کاراکتر آگنوستیک است.

· محتویات اشیاء blob دنباله های تفسیر نشده بایت هستند. وجود ندارد
ترجمه رمزگذاری در سطح اصلی

· نام مسیرها در فرم عادی سازی UTF-8 C کدگذاری شده است. این برای اشیاء درختی اعمال می شود.
فایل فهرست، نام های ref، و همچنین نام مسیرها در آرگومان های خط فرمان،
متغیرهای محیط و فایل‌های پیکربندی (git/config. (نگاه کنید به گیت(1) ، gitignore(5)
ویژگی های gitat(5) و gitmodules(5).

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

· پیام های گزارش commit معمولاً در UTF-8 رمزگذاری می شوند، اما سایر رمزگذاری های ASCII توسعه یافته
نیز پشتیبانی می شوند. این شامل ISO-8859-x، CP125x و بسیاری دیگر است، اما نه
کدگذاری چند بایتی UTF-16/32، EBCDIC و CJK (GBK، Shift-JIS، Big5، EUC-x، CP9xx
و غیره).

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

1. دستگاه گوارش مرتکب شدن و دستگاه گوارش commit-tree اگر پیغام commit log به آن داده شود، اخطار می دهد
مانند یک رشته معتبر UTF-8 به نظر نمی رسد، مگر اینکه به صراحت بگویید پروژه شما از a استفاده می کند
رمزگذاری قدیمی راه برای گفتن این است که i18n.commitencoding در git/config
فایل، مانند این:

[i18n]
commitencoding = ISO-8859-1

اشیاء Commit ایجاد شده با تنظیم بالا مقدار i18n.commitencoding را ثبت می کنند
در هدر رمزگذاری آن این برای کمک به افرادی است که بعداً به آنها نگاه می کنند. فقدان
این هدر نشان می دهد که پیام commit log در UTF-8 کدگذاری شده است.

2. دستگاه گوارش ورود به سیستم, دستگاه گوارش نشان, دستگاه گوارش سرزنش و دوستان به سربرگ رمزگذاری یک commit نگاه می کنند
شی، و سعی کنید پیام ورود به سیستم را مجدداً در UTF-8 کدگذاری کنید، مگر اینکه طور دیگری مشخص شده باشد. شما
می تواند کدگذاری خروجی مورد نظر را با i18n.logoutputencoding در git/config.
فایل، مانند این:

[i18n]
کدگذاری خروجی = ISO-8859-1

اگر این متغیر پیکربندی را ندارید، مقدار i18n.commitencoding است
به جای استفاده می شود

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

محیط زیست و پیکربندی متغیرها

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

قلاب

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

از git-commit آنلاین با استفاده از خدمات onworks.net استفاده کنید