git-commit

コマンド名

「git-commit」：リポジトリへの変更を記録

概要

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
           [--dry-run] [(-c | -C | --fixup | --squash) <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]]
           [-S[<keyid>]] [--] [<pathspec>…]

説明

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

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

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

with git reset. --dry-runオプションを使用すると、同じパラメーターセット（オプションとパス）を指定することで、次のコミットで上記のいずれかに含まれるものの概要を取得できます。
コミットを行い、その直後に間違いを見つけた場合、「gitreset」を使用してそれからリカバリーできます。

オプション

-a
--all

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

-p
--patch

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

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

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

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

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

--fixup=<commit>

rebase --autosquashで使用するコミットメッセージを作成します。コミットメッセージは「fixup！」というプレフィックスが付いた、指定されたコミットの件名になります。詳細については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 のステータス出力を表示する場合、ファイル名を逐語的に出力し、「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

コミットログメッセージの最後にコミッターによるサインオフラインを追加します。サインオフの意味はプロジェクトによって異なりますが、通常はコミッターが同じライセンスの下でこのワークを提出する権利を持っており、オリジナル証明書に同意することを証明します（詳細についてはhttp://developercertificate.org/を参照）。

-n
--no-verify

このオプションは「pre-commit」フックと「commit-msg」フックをバイパスします。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

「#commentary」が削除されないことを除いて、stripと同じです。

verbatim

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

scissors

メッセージを編集する場合、以下のラインから（およびそれを含む）すべてが切り捨てられることを除いて、空白と同じです。「#」は「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

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

すでに公開されているコミットを修正する場合、履歴の書き換えの影響を理解しておく必要があります（git-rebase[1]の「アップストリームリベースからのリカバリー」セクションを参照してください）。

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

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

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

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

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

デフォルトはgit-config[1]に記載されている「status.showUntrackedFiles」構成変数を使用して変更できます。

-v
--verbose

ヘッドコミットとコミットメッセージテンプレートの下部にコミットされる内容との統一された差分を表示し、ユーザーがコミットの変更内容を思い出すことでコミットの説明ができるようにします。この差分出力にはラインの前に＃が付いていないことに注意してください。この差分はコミットメッセージの一部にはなりません。git-config[1]のcommit.verbose 構成変数を参照してください。

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

-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]のパススペックエントリを参照してください。

例

自分のワークを記録する場合、ワークツリー内の変更されたファイルの内容は「gitadd」を使用して「インデックス」と呼ばれるステージング領域に一時的に保存されます。ファイルはインデックス内でのみ、ワークツリー内ではなく、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 を実行するようにgit commitに指示できます。つまり、この例ではワークツリーに他の変更がない場合、前の例と同じように機能します。

$ 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 への変更を記録します。

コンフリクトが原因でマージ（「gitmerge」または「gitpull」によって開始）が停止した後、クリーンにマージされたパスは既にステージングされてコミットされ、コンフリクトしたパスはマージされていない状態のままになります。最初にどのパスが「git status」とコンフリクトしているかを確認する必要があります。ワークツリーを手動で修正した後、通常どおり「gitadd」を使用して結果をステージングします。

$ 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

（「nb “<“」、「 “>”」、「”\ n”」は削除されます）

作成者とコミッターの名前は慣例により、何らかの形式の個人名（つまり他の人があなたを参照する名前）になりますが、Gitは特定の形式を強制または要求しません。上記の制約に従い、任意のユニコードを使用できます。この名前は認証には影響しません。そのためには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 環境変数、および--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として扱われます。

注記 さらに、日付部分は、YYYY.MM.DD、MM/DD/YYYY、DD.MM.YYYYの形式でも受け入れられます。

議論

必須ではありませんが、変更を要約したシングルショートライン（50文字未満）でコミットメッセージを開始し、その後に空白ラインと詳細な説明を続けることをお勧めします。コミットメッセージの最初の空白ラインまでのテキストはコミットタイトルとして扱われ、そのタイトルはGit全体で使用されます。例えば、git-format-patch[1]はコミットを電子メールに変換し、件名のタイトルと本文の残りのコミットを使用します。

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

    • ブロブオブジェクトの内容はバイトの解釈されていないシーケンスとなります。コアレベルでのエンコーディング変換はありません。
    • パス名は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. 「gitcommit」と「gitcommit-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への再コーディングは必ずしも元に戻せるような操作ではないため、コミットが行われた時にコミットログメッセージを再コーディングしないことを選択したことに注意してください。

環境と構成の変数

コミットログメッセージの編集に使用されるエディターはGIT_EDITOR環境変数、「core.editor」構成変数、VISUAL環境変数、またはEDITOR環境変数から（この順序で）選択されます。詳細についてはgit-var[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]パッケージソフトの一部

git公式ドキュメント

commit