git-commit(1)

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)されます)。

コミットするコンテンツは、いくつかの方法で指定できます:

git-add(1) を使用して、「commit」コマンドを使用する前にインデックスに変更を段階的に「追加」(add)します(注: 「変更」されたファイルも「add」コマンドで「追加」するが必要があります)。
再び「commit」コマンドを使用する前に、 git-rm(1) を使用して、作業ツリーとインデックスからファイルを削除します。
「commit」コマンドの引数としてファイルをリストします(--interactive や --patch スイッチがない場合)。この場合、そのコミットはインデックスにステージングされた変更を無視し、代わりにリストされたファイル(これらはすでに Git に知られている必要があります)の現在のコンテンツを記録します
「commit」コマンドで -a スイッチを使用して、すべての既知のファイル(つまり、すでにインデックスにリストされているすべてのファイル)からの変更を自動的に「add」(追加)し、作業ツリーから削除されたインデックス内のファイルを自動的に「rm」(削除)してから、実際のコミットを実行します
「commit」コマンドで --interactive または --patch スイッチを使用して、操作を完了する前に、インデックスの内容に加えて、どのファイルまたはハンクをコミットの一部にするかを1つずつ決定します。これらのモードの操作方法については、 git-add(1)の「Interactive Mode」セクションを参照してください。

--dry-run オプションは、同じパラメーターのセット(オプションとパス)を指定することにより、次のコミットにて上記のいずれかに含まれるものの要約を取得するために使用できます。

コミットを行い、その直後に間違いを見つけた場合は、「git reset」を使用してそれから回復できます。

OPTIONS

-a

--all

変更および削除されたファイルを自動的にステージングするようにコマンドに指示しますが、Gitに通知していない新しいファイルは影響を受けません。

-p

--patch

対話的なパッチ選択インターフェイスを使用して、コミットする変更を選択します。詳細については、git-add(1) を参照してください。

-C <commit>

--reuse-message=<commit>

既存のコミットオブジェクトを取得し、コミットを作成するときにログメッセージと作者情報(タイムスタンプを含む)を再利用します。

-c <commit>

--reedit-message=<commit>

-C と同様ですが、 -c を使用するとエディターが呼び出されるため、ユーザーはコミットメッセージをさらに編集できます。

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

git rebase --autosquash を適用すると <commit> を「fixes up」(修正)する新しいコミットを作成します。プレーンな --fixup=<commit> は「fixup!」コミットを作成します。これは <commit> の内容を変更しますが、ログメッセージは変更されません。 --fixup=amend:<commit> も同様ですが、「amend!」コミットを作成します。これにより <commit> のログメッセージも「amend!」コミットのログメッセージに置き換えられます。 --fixup=reword:<commit> は「amend!」コミットを作成します。これは <commit> のログメッセージを独自のログメッセージに置き換える「amend!」コミットを作成しますが、 <commit> の内容は変更しません。

プレーンな --fixup=<commit> によって作成されたコミットは、 fixup! に <commit> の件名行が続く件名を作り、これは git rebase --autosquash によって特別に認識されます。 -m オプションは、作成されたコミットのログメッセージを補足するために使用できますが、「fixup!」コミットが git rebase --autosquash によって <commit> に押しつぶされる(squash)と、追加のコメントは破棄されます。

--fixup=amend:<commit> によって作成されたコミットは似ていますが、その件名には代わりに amend! というプレフィックスが付いています。 <commit> のログメッセージが「amend!」コミットのログメッセージにコピーされ、エディターで開いた時に調整できます。 git rebase --autosquash が「fixup!」を押しつぶす(squash)とき <commit> にコミットすると、 <commit> のログメッセージは「amend!」コミットからの修正されたログメッセージに置き換えられます。「amend!」コミットのログメッセージが空であることは、 --allow-empty-message が指定されていない限りエラーとなります。

--fixup=reword:<commit> は --fixup=amend:<commit> --only の省略形です。これはログメッセージのみで「amend!」コミットを作成します(インデックスにステージングされた変更は無視します)。 git rebase --autosquash によって押しつぶされる(squash)と、他の変更を加えることなく、 <commit> のログメッセージを置き換えます。

「fixup!」や「amend!」といったコミットは、 git rebase --autosquash で適用したときに <commit> の作者は変更しません。詳しくは git-rebase(1) を参照してください。

--squash=<commit>

rebase --autosquash で使用するコミットメッセージを作成します。コミットメッセージの件名行は、プレフィックスが "squash! " と指定されたコミットから取得されます。追加のコミットメッセージオプション(-m/-c/-C/-F)とともに使用できます。詳細については、 git-rebase(1) を参照してください。

--reset-author

-C/-c/--amend オプションとともに使用する場合、または競合するチェリーピックの後にコミットする場合は、結果のコミットの作者がコミッターに属することを宣言します。これにより、作者のタイムスタンプも更新されます。

--short

ドライランを行うときに、出力を短い形式で提供します。詳細については、 git-status(1) を参照してください。 --dry-run の指定を含んでいます。

--branch

短い形式でもブランチと追跡情報を表示します。

--porcelain

ドライランを行うときに、磁器コマンド対応の形式で出力を提供します。詳細については、 git-status(1) を参照してください。 --dry-run の指定を含んでいます。

--long

ドライランを行うときに、出力を長い形式で提供します。 --dry-run の指定を含んでいます。

-z

--null

short または porcelain ステータス出力を表示する場合は、ファイル名をそのまま(verbatim)出力し、LFではなくNULでエントリを終了します。フォーマットが指定されていない場合は、 --porcelain 出力フォーマットを意味します。 -z オプションを指定しない場合、構成変数 core.quotePath で説明されているように、「異常な」文字を含むファイル名がクォートされます(git-config(1) 参照)。

-F <file>

--file=<file>

指定されたファイルからコミットメッセージを取得します。<file>に - を使用すると、標準入力からメッセージを読み取ります。

--author=<author>

コミット作者をオーバーライドします。標準の A U Thor <author@example.com> 形式を使用して明示的な作者を指定します。それ以外の場合、 <author> はパターンであると見なされ、その作者による既存のコミットを検索するために使用され(つまり、 rev-list --all -i --author=<author>)、そして、コミットの作者は、最初に見つかったそのようなコミットからコピーされます。

--date=<date>

コミットで使用された作者の日付を上書きします。

-m <msg>

--message=<msg>

指定された<msg>をコミットメッセージとして使用します。複数の -m オプションが指定されている場合、それらの値は個別の段落として連結されます(訳注: 各段落は空行で区切られます。つまり、最初の -m のがコミットタイトル、 2つ目以降がコミット本文扱いになります)。

-m オプションは、 -c 、 -C 、 -F と相互に排他的(mutually exclusive)です。

-t <file>

--template=<file>

コミットメッセージを編集するときは、指定されたファイルの内容でエディターを起動します。 commit.template 構成変数は、このオプションをコマンドに暗黙的に与えるためによく使用されます。このメカニズムは、メッセージに何をどの順序で書き込むかについてのヒントを参加者に案内したいプロジェクトで使用できます。ユーザーがメッセージを編集せずにエディターを終了すると、コミットは中止(abort)されます。これは、メッセージが他の手段、例えば -m または -F オプションを使用して提供された場合には効果がありません。

-s

--signoff

--no-signoff

コミット・ログ・メッセージの最後に、コミッターによる「Signed-off-by」トレーラーを追加します。 signoff(訳注: 一般には手紙の(末尾の)署名)の意味は、コミットしているプロジェクトによって異なります。たとえば、コミッターがプロジェクトのライセンスに基づいて作品を提出する権利を持っていることを証明したり、開発者の原産地証明書などの寄稿者の代表に同意したりする場合があります(LinuxカーネルおよびGitプロジェクトで使用されるものについては、 https://developercertificate.org を参照してください)。プロジェクトでsignoffがどのように使用されるかを理解するには、貢献しているプロジェクトのドキュメントまたはリーダーシップ(leadership)を参照してください。

コマンドラインで --no-signoff オプションを使用すると、それ以前の --signoff オプションを無効にすることができます。

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

トレーラーとして適用する必要がある<token>と<value>のペアを指定します。 (例: git commit --trailer "Signed-off-by:C O Mitter \ <committer@example.com>" --trailer "Helped-by:C O Mitter \ <committer@example.com>" は「コミットメッセージへ「Signed-off-by」トレーラーと「Helped-by」トレーラーを追加します。)） trailer.* 構成変数(git-interpret-trailers(1))を使用して、重複したトレーラーを省略するかどうか、各トレーラーがトレーラー群の何処に表示されるかや、その他の詳細を定義できます。

-n

--[no-]verify

デフォルトでは、 pre-commit および commit-msg フックが実行されます。 --no-verify または -n のいずれかが指定された場合、これらのフックはバイパスされます。 githooks(5) も参照してください。

--allow-empty

通常、唯一の親コミットとまったく同じツリーを持つコミットを記録することは間違いであり、コマンドはそのようなコミットを行うことを防ぎます。このオプションはその安全装置をバイパスします。主に外部SCMインターフェイススクリプトで使用するためのものです。

--allow-empty-message

--allow-empty と同様に、このコマンドは主に外部SCMインターフェイススクリプトで使用されます。あなたは git-commit-tree(1) のような配管コマンドを使用せずに、空のコミットメッセージでコミットを作成できます。

--cleanup=<mode>

このオプションは、提供されたコミット・メッセージをコミットする前にクリーンアップする方法を決定します。 <mode> は、 strip または whitespace または verbatim または scissors または default にすることができます。

strip

先頭と末尾の空行の削除と、行末の空白を削除と、コメントの削除を行い、連続する空行を折りたたみます。

whitespace

#コメントが削除されないことを除いて、strip と同一です。

verbatim

メッセージは一切変更しません。

scissors

メッセージを編集する場合は、以下に示した切り取り線の行からの(そしてその行を含む)すべてが切り捨てられることを除いて、 whitespace と同じです。 # は core.commentChar でカスタマイズできます。

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

default

メッセージを編集する場合は strip と同一です。それ以外の場合は whitespace と同一です。

デフォルトは、 commit.cleanup 構成変数によって変更できます(git-config(1) 参照)。

-e

--edit

-F を使用してファイルから取得したメッセージや、 -m を使用してコマンドラインから取得したメッセージや、 -C を使用してコミットオブジェクトから取得したメッセージは、通常、編集不可のコミットログメッセージとして使用されます。このオプションを使用すると、これらのソースから取得したメッセージをさらに編集できます。

--no-edit

エディターを起動せずに、選択したコミットメッセージを使用します。たとえば、 git commit --amend --no-edit は、コミットメッセージを変更せずにコミットを修正します。

--amend

新しいコミットを作成して、現在のブランチの先端を置き換えます。記録されたツリーは通常どおりに準備され(-i および -o オプションと明示的なパススペックの効果を含む)、空のメッセージではなく、元のコミットからのメッセージが開始点として使用されます。他のメッセージは、コマンドラインから -m, -F, -c などのオプションを介して指定します。新しいコミットには、現在のものと同じ親と作者があります(--reset-author オプションはこれを打ち消すことができます)。

これは、以下とおおむね同じです:

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

ただし、マージコミットを修正(amend)するために使用できます。

すでに公開されているコミットを修正する場合、あなたは履歴の書き換えの影響を理解する必要があります。 (git-rebase(1) の「RECOVERING FROM UPSTREAM REBASE」セクションを参照してください。)

--no-post-rewrite

post-rewriteフックをバイパスします。

-i

--include

これまでにステージングされたコンテンツからコミットを行う前に、コマンドラインで指定されたパスのコンテンツもステージングします。あなたが競合するマージを終了させるのでない限り、これは通常、あなたが希望することはないでしょう。

-o

--only

他のパス用にステージングされたコンテンツを無視して、コマンドラインで指定されたパスの更新された作業ツリーのコンテンツを取得してコミットします。これは、コマンドラインでパスが指定されている場合の「git commit」のデフォルトの動作モードです。この場合、このオプションは省略できます。このオプションを`--amend` と一緒に指定する場合、パスを指定する必要はありません。これを使用すると、すでにステージングされている変更をコミットせずに最後のコミットを修正できます。 --allow-empty パスと一緒に使用する場合もパスは必要ではなく、空のコミットが作成されます。

--pathspec-from-file=<file>

パススペックは、コマンドライン引数の代わりに`<file>で渡されます。 `<file> が正確に - の場合、標準入力が使用されます。パススペック要素は、LFまたはCR/LFで区切られます。パススペック要素は、構成変数 core.quotePath で説明されているようにクォートできます(git-config(1) 参照)。 --pathspec-file-nul およびグローバル --literal-pathspecs も参照してください。

--pathspec-file-nul

--pathspec-from-file 指定時のみ意味があります。パススペック要素はNUL文字で区切られ、他のすべての文字は文字通りに解釈されます(改行と引用符を含む)。

-u[<mode>]

--untracked-files[=<mode>]

追跡されていないファイル(untracked files)を表示します。

modeパラメーターはオプション(デフォルトは「all」)であり、追跡されていないファイルの処理を指定するために使用されます。 -u を使用しない場合、デフォルトは「normal」です。つまり、追跡されていないファイルとディレクトリを表示します。

可能なオプションは以下のとおりです:

no - 追跡されていないファイルを表示します
normal - 追跡されていないファイルとディレクトリを表示します
all - 追跡されてないディレクトリ内の個々のファイルも表示します。

ブール値 true の通常のスペルはすべて normal として解釈され、 false は no として解釈されます。デフォルトは、 git-config(1) に記載されている status.showUntrackedFiles 構成変数を使用して変更できます。

-v

--verbose

HEADコミットとコミットメッセージテンプレートの下部にコミットされる内容とのunified diffを表示して、ユーザーがコミットの変更内容を思い出させることでコミットを説明できるようにします。注意: このdiff出力には、接頭辞 # が付いた行がないことに注意してください。このdiffは、コミットメッセージの一部にはなりません。 git-config(1) の commit.verbose 構成変数を参照してください。

2回指定した場合は、コミットされるものとワークツリーファイルの間のunified diff、つまり、追跡されたファイルへのステージングされていない変更を追加で表示します。

-q

--quiet

コミット要約メッセージを抑制します。

--dry-run

コミットを作成しません。ただし、コミットされるパス、コミットされないままになるローカル変更のあるパス、および追跡されないパスのリストを表示します。

--status

エディターを使用してコミットメッセージを準備する場合は、 git-status(1) の出力をコミットメッセージテンプレートに含めます。デフォルトはオンではありますが、構成変数 commit.status での指定をオーバーライドするために使用できます。

--no-status

エディターを使用してデフォルトのコミットメッセージを準備する場合は、 git-status(1) の出力をコミットメッセージテンプレートに含めません。

-S[<keyid>]

--gpg-sign[=<keyid>]

--no-gpg-sign

GPG署名コミット。 keyid 引数はオプションであり、デフォルトでコミッターIDになります。指定する場合は、スペースなしでオプションに固定する必要があります。 --no-gpg-sign は、commit.gpgSign 構成変数と、これより前で指定された --gpg-sign の両方を打ち消すのに役立ちます。

--

これ以降の引数をオプションとして解釈しないでください。

<pathspec>…

コマンドラインでパススペックが指定されている場合、インデックスにすでに追加されている変更を記録せずに、パススペックにマッチするファイルの内容をコミットします。これらのファイルの内容は、これより前にステージングされたものに加えて、次のコミットのためにもステージングされます。

詳細については、 gitglossary(7)の「pathspec」エントリを参照してください。

EXAMPLES

自分の作業を記録する場合、作業ツリー内の変更されたファイルの内容は、「git add」を使用して「インデックス」と呼ばれるステージング領域に一時的に保存されます。ファイルは、インデックス内でのみ、作業ツリー内ではなく、 git restore --staged <file> を使用して最後のコミットのファイルに戻すことができます。これにより、 git add が効果的に元に戻され、このファイルへの変更を次のコミットに関わらわせないようにします。これらのコマンドを使用して増加的にコミットする状態を構築した後、 git commit (パス名パラメーターなし)を使用して、これまでにステージングされたものを記録します。これは、このコマンドの最も基本的な形式です。例:

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

個々の変更の後にファイルをステージングする代わりに、作業ツリーで内容が追跡されているファイルへの変更を通知し、対応する git add と git rm を実行するように`gitcommit`に指示できます。つまり、以下の例は、作業ツリーに他の変更がない場合、上記の例と同じように機能します:

$ 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

この2番目のコミットは、期待どおりに hello.c と hello.h への変更を記録します。

競合が原因でマージ(「git merge」または「git pull」によって開始）が停止(stop)した後では、クリーンにマージされたパスはすでにステージングされてコミットされ、競合したパスはマージされていない状態のままになります。最初に、「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

作者とコミッターの情報は、以下の環境変数から取得されます(設定されてる場合):

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

(注: "<" と ">" と "\n" は取り除きます)

作者とコミッター名は、慣例により、個人名(つまり、他の人間があなたを参照する名前)の形式ですが、Gitは特定の形式を強制または要求しません。上記の制約に従って、任意のUnicodeを使用できます。この名前は認証には影響しません。認証には影響させるためには、 git-config(1)の credential.username 変数を参照してください。

これらの環境変数(の一部)が設定されていない場合、情報は構成アイテム 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

これは <unix-timestamp> <time-zone-offset> です。ここで <unix-timestamp> はUNIXエポックからの秒数で、 <time-zone-offset> はUTCからの正または負のオフセットです。たとえば、CET(UTCより1時間進んでる)は +0100 です。

RFC 2822

RFC 2822で説明されている標準の日付形式。たとえば、 Thu, 07 Apr 2005 22:13:13 +0200

ISO 8601

ISO 8601規格で指定されている日時(例: 2005-04-07T22:13:13)。パーサは、 T 文字の代わりにスペースも受け入れます。秒の小数部分は無視されます。たとえば、 2005-04-07T22:13:13.019 は 2005-04-07T22:13:13 として扱われます。

Note	日付部分は、上記に加えて、 `YYYY.MM.DD` または `MM/DD/YYYY` または `DD.MM.YYYY` 形式が受け入れられます。

上記のすべての日付形式を認識することに加えて、 --date オプションは、 "yesterday" や "last Friday at noon" など、より人間よりの日付形式も理解しようとします。

DISCUSSION

必須ではありませんが、変更を要約した1行の短い(50文字以下の)行でコミット・メッセージを開始し、その後に空行を続け、さらに詳細な説明を続けることをお勧めします。コミット・メッセージの最初の空行までのテキストはコミット・タイトルとして扱われ、そのタイトルはGit全体で使用されます。たとえば、 git-format-patch(1) はコミットを電子メールに変換し、コミット・タイトルをメール件名に使い、残りのコミット・メッセージをメール本文に使います。

Gitは、ある程度までは文字エンコードに依存しません。

ブロブオブジェクトの内容は、解釈されていないバイトのシーケンスです。コアレベルでのエンコーディング変換はありません。
パス名はUTF-8正規化形式C(UTF-8 normalization form C)でエンコードされます。これは、ツリーオブジェクト、インデックスファイル、ref名、およびコマンドライン引数、環境変数、構成ファイル( .git/config (git-config(1) 参照) と gitignore(5) と gitattributes(5) と gitmodules(5)) のパス名に適用されます。

コアレベルのGitは、パス名を単に非NULバイトのシーケンスとして扱い、パス名をエンコードする変換はありません(MacとWindowsを除く)。したがって、非ASCIIパス名の使用は、レガシー拡張ASCIIエンコーディングを使用するプラットフォームやファイルシステムでもほとんど機能します。ただし、そのようなシステムで作成されたリポジトリは、UTF-8ベースのシステム(Linux、Mac、Windowsなど)では正しく機能しません。その逆も同様です。さらに、多くのGitベースのツールは、パス名がUTF-8であると単純に想定しており、他のエンコーディングを正しく表示できません。
コミット・ログ・メッセージは通常UTF-8でエンコードされますが、他の拡張ASCIIエンコードもサポートされています。これには、ISO-8859-xやCP125xなどが含まれます。しかし、 UTF-16/32 や EBCDIC や CJK マルチバイトエンコーディング(GBK、Shift-JIS、Big5、EUC-x、CP9xxなど)は含まれません。

我々はコミットログメッセージをUTF-8でエンコードすることをお勧めしますが、コアとGit Porcelainはどちらも、プロジェクトでUTF-8を強制しないように設計されています。特定のプロジェクトのすべての参加者がレガシーエンコーディングを使用する方が便利だと感じた場合、Gitはそれを禁止しません。ただし、覚えておくべきことがいくつかあります。

git commit と git commit-tree は、プロジェクトがレガシーエンコーディングを使用していることを明示的に指定しない限り、与えられたコミットログメッセージが有効なUTF-8文字列のように見えない場合に警告を発します。明示的に指定する方法は、以下のように、 .git/config ファイルに i18n.commitEncoding を含めることです。
```
[i18n]
        commitEncoding = ISO-8859-1
```
上記の設定で作成されたコミットオブジェクトは、 encoding ヘッダーに i18n.commitEncoding の値を記録します。これは、後でそれらを見る他の人々を助けるためです。このヘッダーがないということは、コミットログメッセージがUTF-8でエンコードされていることを意味します。
git log や git show や git blame とその仲間たちは、コミットオブジェクトの encoding ヘッダーを見て、特に指定がない限り、ログメッセージをUTF-8に再コーディングしようとします。あなたは以下のように、 .git/config ファイルの i18n.logOutputEncoding を使用して目的の出力エンコーディングを指定できます。
```
[i18n]
        logOutputEncoding = ISO-8859-1
```
この構成変数がない場合は、代わりに i18n.commitEncoding の値が使用されます。

注意: UTF-8への再コーディングは必ずしも可逆的な操作ではないため、我々はコミットが行われたときにコミットログメッセージを再コーディングしないことを意図的に選択したことに注意してください。

ENVIRONMENT AND CONFIGURATION VARIABLES

コミットログメッセージの編集に使用されるエディターは、 GIT_EDITOR 環境変数または core.editor 構成変数または VISUAL 環境変数または EDITOR 環境変数から(この順序で)選択されます。詳細については、 git-var(1) を参照してください。

このセクションのこの行より上にあるものはすべて、 git-config(1) ドキュメントには含まれていません。以下の内容に関しては、git-config(1) ドキュメントにあるものと同一です。

commit.cleanup: この設定は、 git commit の --cleanup オプションのデフォルトを上書きします。詳細については、 git-commit(1) を参照してください。デフォルトを変更すると、コメント文字 # で始まる行をログメッセージに常に残しておきたい場合に役立ちます。その場合は、 git config commit.cleanup whitespace を実行します(注意:これを行う場合は、コミットログテンプレートの # で始まるヘルプ行を自分で削除する必要があることに注意してください)。
commit.gpgSign: すべてのコミットをGPG署名する必要があるかどうかを指定するブール値。リベースなどの操作を行うときにこのオプションを使用すると、多数のコミットが署名される可能性があります。エージェントを使用して、GPGパスフレーズの入力を省略するようにすると便利な場合があります。
commit.status: エディタを使用してコミットメッセージを準備するときに、コミットメッセージテンプレートにステータス情報を含めることを有効/無効にするブール値。デフォルトはtrueです。
commit.template: 新しいコミットメッセージのテンプレートとして使用するファイルのパス名を指定します。
commit.verbose: git commit でverboseレベルを指定するブール値またはint。 git-commit(1) を参照してください。

HOOKS

このコマンドは、 commit-msg フックと、 prepare-commit-msg フックと、 pre-commit フックと、 post-commit フックと、 post-rewrite フックを実行できます。詳細については、 githooks(5) を参照してください。

FILES

$GIT_DIR/COMMIT_EDITMSG: このファイルには、進行中のコミットのコミットメッセージが含まれています。コミットを作成する前にエラーが原因で gitc ommit が終了した場合、ユーザーによって提供されたコミットメッセージ(エディターセッションなど)は全てこのファイルに残りますが、次の git commit の呼び出しによって上書きされます。

GIT

Part of the git(1) suite

git-commit(1) Manual Page

NAME