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

名前

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 の直接の子であり、通常は現在のブランチの先端であり、ブランチはそれを指すように更新されます(ワーキングツリーに関連付けられたブランチがない場合、HEADgit-checkout[1] で説明されているように「デタッチされた」状態になります)。

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

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

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

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

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

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

--dry-run オプションは、上記いずれかによって次のコミットに何が含まれるかの概要を、同じ一連のパラメータ(オプションとパス)を与えることで取得するために使用できます。

コミットを作成してすぐに間違いに気づいた場合、git reset で回復できます。

オプション

-a
--all

変更および削除されたファイルを自動的にステージしますが、Gitにまだ通知されていない新しいファイルには影響しません。

-p
--patch

インタラクティブなパッチ選択インターフェースを使用して、コミットする変更を選択します。git-add[1] を参照してください。

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

既存の <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>

git 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 ステータス出力を表示する際、ファイル名をそのまま出力し、エントリを LF の代わりに NUL で終了させます。フォーマットが指定されていない場合、--porcelain 出力フォーマットを含意します。-z オプションがない場合、「特殊な」文字を含むファイル名は、設定変数 core.quotePath で説明されているように引用符で囲まれます(git-config[1] を参照)。

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

コミットメッセージを <file> から取得します。標準入力からメッセージを読み込むには - を使用します。

--author=<author>

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

--date=<date>

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

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

<msg> をコミットメッセージとして使用します。複数の -m オプションが与えられた場合、それらの値は別々の段落として連結されます。

-m オプションは、-c-C、および -F と同時に使用することはできません。

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

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

-s
--signoff
--no-signoff

コミットログメッセージの最後にコミッターによる Signed-off-by トレーラーを追加します。サインオフの意味は、コミット先のプロジェクトによって異なります。例えば、コミッターがプロジェクトのライセンスの下で作業を提出する権利があることを証明したり、Contributor License Agreement (DCO) のようなコントリビューターの表明に同意したりする場合があります。(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 フックをバイパスします。githooks[5] も参照してください。

--allow-empty

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

--allow-empty-message

git-commit-tree[1] のようなプルーミングコマンドを使用せずに、空のコミットメッセージでコミットを作成します。--allow-empty と同様に、このコマンドは主に外部SCMインターフェーススクリプトで使用するためのものです。

--cleanup=<mode>

提供されたコミットメッセージをコミットする前にどのようにクリーンアップするかを決定します。<mode>stripwhitespaceverbatimscissors、または default のいずれかです。

strip

先頭と末尾の空行、末尾の空白、コメントを削除し、連続する空行を結合します。

whitespace

strip と同じですが、#コメントは削除されません。

verbatim

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

scissors

whitespace と同じですが、メッセージが編集される場合、以下の行から(その行を含めて)すべてが切り捨てられます。「#」は core.commentChar でカスタマイズできます。

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

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

デフォルトは commit.cleanup 設定変数で変更できます(git-config[1] を参照)。

-e
--edit

-F <file><file> から取得したメッセージ、-m <message> でコマンドラインから取得したメッセージ、および -C <commit><commit> から取得したメッセージを、ユーザーがさらに編集できるようにします。

--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

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

既に公開されているコミットを修正する場合、履歴を書き換えることの影響を理解しておく必要があります(git-rebase[1] の「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>]

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

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

可能なオプションは以下の通りです。

no

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

normal

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

all

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

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

-v
--verbose

HEAD コミットとコミットされる内容との間の統一差分を、コミットメッセージテンプレートの下部に表示し、ユーザーがコミットの変更点を思い出してコミットを記述するのに役立ちます。この差分出力の行には # がプレフィックスとして付かないことに注意してください。この差分はコミットメッセージの一部にはなりません。git-config[1]commit.verbose 設定変数を参照してください。

2回指定すると、さらにコミットされる内容とワーキングツリーファイル(つまり、追跡されているファイルのステージされていない変更)との間の統一差分も表示します。

-q
--quiet

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

--dry-run

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

--status

エディタを使用してコミットメッセージを準備する際、git-status[1] の出力をコミットメッセージテンプレートに含めます。デフォルトはオンですが、設定変数 commit.status を上書きするために使用できます。

--no-status

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

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

コミットにGPG署名します。<key-id> はオプションであり、デフォルトはコミッターの識別情報です。指定された場合、スペースなしでオプションに付加する必要があります。--no-gpg-sign は、commit.gpgSign 設定変数と、以前の --gpg-sign の両方を無効にするのに役立ちます。

--

これ以上引数をオプションとして解釈しません。

<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 addgit rm を自動的に実行させることができます。つまり、ワーキングツリーに他の変更がない場合、この例は以前の例と同じことをします。

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

コマンド git commit -a は、まずワーキングツリーを見て、hello.c を変更し、goodbye.c を削除したことを認識し、必要な git addgit 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.chello.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 オプションを参照)。

コミット情報

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

  • 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.0192005-04-07T22:13:13 として扱われます。

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

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

議論

必須ではありませんが、コミットメッセージの冒頭に、変更を要約した短い(50文字以内)1行を書き、その後に空行を挟んで詳細な説明を記述することをお勧めします。コミットメッセージの最初の空行までのテキストはコミットタイトルとして扱われ、そのタイトルはGit全体で利用されます。例えば、git-format-patch[1] はコミットをメールに変換し、件名行にタイトルを、本文に残りのコミットを使用します。

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

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

  • パス名はUTF-8正規化形式Cでエンコードされます。これはツリーオブジェクト、インデックスファイル、リファレンス名、およびコマンドライン引数、環境変数、設定ファイル(.git/configgit-config[1]を参照)、gitignore[5]gitattributes[5]gitmodules[5])内のパス名に適用されます。

    コアレベルでは、Gitはパス名を単に非NULLバイトのシーケンスとして扱っており、パス名のエンコーディング変換は行われないこと(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

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

  2. git loggit showgit 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 config commit.cleanup whitespace を実行します(ただし、この設定を行うと、コミットログテンプレート内の # で始まるヘルプ行は自分で削除する必要があることに注意してください)。

commit.gpgSign

すべてのコミットにGPG署名を行うべきかを指定する真偽値。リベースなどの操作を行う際にこのオプションを使用すると、大量のコミットが署名される可能性があります。GPGパスフレーズを何度も入力するのを避けるためにエージェントを使用すると便利かもしれません。

commit.status

エディタを使用してコミットメッセージを準備する際に、コミットメッセージテンプレートにステータス情報を含めるかどうかを有効/無効にする真偽値。デフォルトは true です。

commit.template

新しいコミットメッセージのテンプレートとして使用するファイルのパス名を指定します。

commit.verbose

git commit で詳細度レベルを指定する真偽値または整数。

フック

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

ファイル

$GIT_DIR/COMMIT_EDITMSG

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

GIT

git[1] スイートの一部

scroll-to-top