Git
日本語 ▾ トピック ▾ 最新バージョン ▾ git-commit は 2.46.1 で最後に更新されました

名前

git-commit - リポジトリへの変更を記録する

概要

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>…​]

説明

インデックスの現在の内容と、変更を説明する指定されたログメッセージを含む新しいコミットを作成します。新しいコミットは HEAD の直接の子であり、通常は現在のブランチの先端です。ブランチはそれを指すように更新されます（作業ツリーに関連付けられたブランチがない場合、HEAD はgit-checkout[1]で説明されているように「デタッチ」されます）。

コミットする内容は、いくつかの方法で指定できます。

  1. git-add[1]を使用して、commitコマンドを使用する前に、変更をインデックスに段階的に「追加」する（注：変更されたファイルも「追加」する必要があります）。

  2. git-rm[1]を使用して、作業ツリーとインデックスからファイルを削除してから、再びcommitコマンドを使用する。

  3. commitコマンドに引数としてファイルをリストする（--interactiveまたは--patchスイッチなし）。この場合、コミットはインデックスにステージングされた変更を無視し、代わりにリストされたファイルの現在の内容（すでに Git に認識されている必要があります）を記録します。

  4. commitコマンドで-aスイッチを使用して、既知のファイル（つまり、すでにインデックスにリストされているすべてのファイル）からの変更を自動的に「追加」し、作業ツリーから削除されたインデックス内のファイルを自動的に「rm」してから、実際のコミットを実行します。

  5. commitコマンドで--interactiveまたは--patchスイッチを使用して、操作を完了する前に、インデックスの内容に加えて、どのファイルまたはハンクをコミットの一部にするかを1つずつ決定します。これらのモードの操作方法については、git-add[1]の「インタラクティブモード」セクションを参照してください。

--dry-runオプションを使用すると、同じパラメータ（オプションとパス）を指定して、次のコミットに含まれる内容の概要を取得できます。

コミットを行った直後に間違いを見つけた場合は、git resetで復旧できます。

オプション

-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>を「修正」する新しいコミットを作成します。プレーンな--fixup=<commit>は、<commit>の内容を変更するが、ログメッセージはそのままにする「fixup!」コミットを作成します。--fixup=amend:<commit>も同様ですが、<commit>のログメッセージも「amend!」コミットのログメッセージで置き換える「amend!」コミットを作成します。--fixup=reword:<commit>は、<commit>のログメッセージを独自のログメッセージで置き換えるが、<commit>の内容には変更を加えない「amend!」コミットを作成します。

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

--fixup=amend:<commit>によって作成されたコミットも同様ですが、件名の代わりに「amend!」が接頭辞として付けられます。<commit>のログメッセージは「amend!」コミットのログメッセージにコピーされ、エディタで開かれて調整できます。git rebase --autosquashが「amend!」コミットを<commit>にスカッシュすると、<commit>のログメッセージは「amend!」コミットからの調整されたログメッセージに置き換えられます。--allow-empty-messageが指定されていない場合、「amend!」コミットのログメッセージが空であるとエラーになります。

--fixup=reword:<commit>は、--fixup=amend:<commit> --onlyの短縮形です。ログメッセージのみを含む「amend!」コミットを作成します（インデックスにステージングされた変更は無視します）。git rebase --autosquashによってスカッシュされると、他の変更を加えることなく、<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オプションを使用した場合、または競合するcherry-pickの後にコミットする場合は、結果のコミットの作成者がコミッターに属することを宣言します。これにより、作成者のタイムスタンプも更新されます。

--short

ドライランを実行する場合、出力を短い形式で表示します。詳細については、git-status[1]を参照してください。--dry-runを暗示します。

--branch

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

--porcelain

ドライランを実行する場合、出力をporcelain対応形式で表示します。詳細については、git-status[1]を参照してください。--dry-runを暗示します。

--long

ドライランを実行する場合、出力を長い形式で表示します。--dry-runを暗示します。

-z
--null

shortまたはporcelainステータス出力を表示する場合、ファイル名をそのまま出力し、LFの代わりにNULでエントリを終了します。形式が指定されていない場合は、--porcelain出力形式を暗示します。-zオプションがない場合、「異常な」文字を含むファイル名は、構成変数core.quotePathで説明されているように引用符で囲まれます（git-config[1]を参照）。

-F <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 オプションは、-c、-C、および -F と排他的です。

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

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

-s
--signoff
--no-signoff

コミットログメッセージの末尾に、コミッターによる Signed-off-by トレーラーを追加します。サインオフの意味は、コミット先のプロジェクトによって異なります。たとえば、コミッターがプロジェクトのライセンスに基づいて作業を提出する権利を持っていること、または開発者の原産地証明などの貢献者の表明に同意することを証明する場合があります。（Linux カーネルと Git プロジェクトで使用されている https://developercertificate.org を参照してください。）サインオフがそのプロジェクトでどのように使用されているかを理解するには、貢献先のプロジェクトのドキュメントまたはリーダーシップを参照してください。

--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 と同じですが、#commentary は削除されません。

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 オプションと明示的な pathspec の効果を含みます）、-m、-F、-c などのオプションを使用してコマンドラインから他のメッセージが指定されていない場合は、空のメッセージではなく、元のコミットからのメッセージが開始点として使用されます。新しいコミットは、現在のコミットと同じ親と作者を持ちます（--reset-author オプションでこれを無効にできます）。

これは、ほぼ同等のものです。

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

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

既に公開されているコミットを修正する場合は、履歴を書き換えることの意味を理解する必要があります。（git-rebase[1] の「UPSTREAM REBASE からの回復」セクションを参照してください。）

--no-post-rewrite

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

-i
--include

これまでのステージングされたコンテンツからコミットを作成する前に、コマンドラインで指定されたパスの内容もステージングします。これは、競合するマージを完了する場合を除いて、通常は必要なものではありません。

-o
--only

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

--pathspec-from-file=<file>

Pathspec は、コマンドライン引数の代わりに <file> で渡されます。<file> が正確に - である場合、標準入力が使用されます。Pathspec の要素は、LF または CR/LF で区切られます。Pathspec の要素は、設定変数 core.quotePath で説明されているように引用符で囲むことができます（git-config[1] を参照）。 --pathspec-file-nul とグローバルの --literal-pathspecs も参照してください。

--pathspec-file-nul

--pathspec-from-file でのみ意味があります。Pathspec の要素は NUL 文字で区切られ、他のすべての文字は文字どおりに解釈されます（改行と引用符を含む）。

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

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

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

指定可能なオプションは次のとおりです。

  • no - 追跡されていないファイルを表示しない

  • normal - 追跡されていないファイルとディレクトリを表示する

  • all - 追跡されていないディレクトリ内の個々のファイルも表示する。

ブール値 true の通常のスペルはすべて normal として解釈され、false は no として解釈されます。デフォルトは、git-config[1] で説明されている status.showUntrackedFiles 設定変数を使用して変更できます。

-v
--verbose

ユーザーがコミットの内容を説明するのに役立つように、コミットメッセージテンプレートの下部に、HEAD コミットとコミットされるものの間の統合 diff を表示します。この diff 出力には、行の先頭に # が付いていないことに注意してください。この diff はコミットメッセージの一部になりません。git-config[1] の commit.verbose 設定変数を参照してください。

2回指定すると、コミットされるものとワークツリーファイル（つまり、追跡されているファイルへのステージングされていない変更）の間の統合 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>…​

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

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

例

自分の作業を記録する場合、ワーキングツリー内の変更されたファイルの内容は、git add を使用して「インデックス」と呼ばれるステージング領域に一時的に保存されます。ファイルは、インデックス内でのみ、ワーキングツリー内ではなく、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

この2回目のコミットは、予想どおり 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 オプションを使用して入力を省くことができます。1つの違いは、マージ解決中には、変更がコミットされる順序を変更するために、パス名付きで git commit を使用できないことです。これは、マージを単一のコミットとして記録する必要があるためです。実際、パス名が指定された場合、コマンドは実行を拒否します（ただし、-i オプションを参照してください）。

コミット情報

作者およびコミッターの情報は、設定されている場合、以下の環境変数から取得されます。

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 変数のみを設定することです。他のオプションは、より複雑なユースケースのために提供されています。

日付形式

GIT_AUTHOR_DATE および GIT_COMMITTER_DATE 環境変数は、次の日付形式をサポートしています。

Git 内部形式

これは <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 として扱われます。

注意
 さらに、日付部分は、次の形式でも受け入れられます：YYYY.MM.DD、MM/DD/YYYY および DD.MM.YYYY。

上記の日付形式をすべて認識することに加えて、--date オプションは、「昨日」や「先週の金曜日の正午」のような相対日付など、より人間中心的な他の日付形式も理解しようとします。

議論

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

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

  • blob オブジェクトの内容は、解釈されないバイトのシーケンスです。コアレベルではエンコーディングの変換はありません。

  • パス名は UTF-8 正規化形式 C でエンコードされます。これは、ツリーオブジェクト、インデックスファイル、参照名、およびコマンドライン引数、環境変数、構成ファイル (.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 はそれを禁止しません。ただし、注意すべき点がいくつかあります。

  1. git commit および git commit-tree は、コミットログメッセージが有効な UTF-8 文字列のように見えない場合、警告を発行します。ただし、プロジェクトでレガシーエンコーディングを使用することを明示的に示す場合を除きます。これを示す方法は、.git/config ファイルに i18n.commitEncoding を次のように記述することです。

    [i18n]
	commitEncoding = ISO-8859-1

    上記の設定で作成されたコミットオブジェクトは、encoding ヘッダーに i18n.commitEncoding の値を記録します。これは、後でそれを見る他の人々を支援するためです。このヘッダーがない場合は、コミットログメッセージが UTF-8 でエンコードされていることを意味します。

  2. git log、git show、git blame などのコマンドは、コミットオブジェクトの encoding ヘッダーを参照し、特に指定がない限り、ログメッセージを UTF-8 に再エンコードしようとします。.git/config ファイルで i18n.logOutputEncoding を次のように指定することで、目的の出力エンコーディングを指定できます。

    [i18n]
	logOutputEncoding = ISO-8859-1

    この構成変数がない場合、代わりに i18n.commitEncoding の値が使用されます。

コミットオブジェクトレベルで UTF-8 を強制するために、コミット時にコミットログメッセージを再エンコードしないことを意図的に選択したことに注意してください。これは、UTF-8 への再エンコードが必ずしも可逆的な操作ではないためです。

環境変数および構成変数

コミットログメッセージの編集に使用されるエディターは、GIT_EDITOR 環境変数、core.editor 構成変数、VISUAL 環境変数、または EDITOR 環境変数（この順序）から選択されます。詳細については、git-var[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 での詳細レベルを指定するブール値または整数です。git-commit[1] を参照してください。

フック

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

ファイル

$GIT_DIR/COMMIT_EDITMSG

このファイルには、進行中のコミットのコミットメッセージが含まれています。git commit がコミットを作成する前にエラーで終了した場合、ユーザーによって提供されたコミットメッセージ（例：エディターセッション内）はこのファイルで利用可能になりますが、次の git commit の呼び出しによって上書きされます。

関連項目

git-add[1]、 git-rm[1]、 git-mv[1]、 git-merge[1]、 git-commit-tree[1]

GIT

git[1] スイートの一部

scroll-to-top