セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット作成
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
ガイド
- gitattributes
- コマンドラインインターフェースの慣例
- 日々のGit
- よくある質問 (FAQ)
- 用語集
- フック
- gitignore
- gitmodules
- リビジョン
- サブモジュール
- チュートリアル
- ワークフロー
- すべてのガイド...
管理
プルーミングコマンド
-
2.49.0
2025-03-14
- 2.46.2 → 2.48.1 変更なし
-
2.46.1
2024-09-13
- 2.45.1 → 2.46.0 変更なし
-
2.45.0
2024-04-29
- 2.43.2 → 2.44.3 変更なし
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.38.1 → 2.42.4 変更なし
-
2.38.0
2022-10-02
- 2.35.1 → 2.37.7 変更なし
-
2.35.0
2022-01-24
- 2.34.1 → 2.34.8 変更なし
-
2.34.0
2021-11-15
- 2.33.1 → 2.33.8 変更なし
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 変更なし
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 変更なし
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 変更なし
-
2.30.0
2020-12-27
- 2.27.1 → 2.29.3 変更なし
-
2.27.0
2020-06-01
- 2.25.2 → 2.26.3 変更なし
-
2.25.1
2020-02-17
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 変更なし
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 変更なし
-
2.23.0
2019-08-16
- 2.21.1 → 2.22.5 変更なし
-
2.21.0
2019-02-24
- 2.17.0 → 2.20.5 変更なし
-
2.16.6
2019-12-06
- 2.14.6 → 2.15.4 変更なし
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
- 2.8.6 変更なし
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
- 2.5.6 変更なし
-
2.4.12
2017-05-05
- 2.3.10 変更なし
-
2.2.3
2015-09-04
- 2.1.4 変更なし
-
2.0.5
2014-12-17
概要
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] で説明されているように「デタッチされた」状態になります)。
コミットする内容は、いくつかの方法で指定できます。
-
git-add[1] を使用して、
commit
コマンドを使用する前にインデックスに変更を段階的に「追加」する(注: 変更されたファイルも「追加」する必要があります)。 -
git-rm[1] を使用して、
commit
コマンドを使用する前に、ワーキングツリーとインデックスからファイルを削除する。 -
commit
コマンドに引数としてファイルをリストする(--interactive
または--patch
スイッチなし)。この場合、コミットはインデックスにステージされた変更を無視し、代わりにリストされたファイル(Gitに既に認識されている必要がある)の現在の内容を記録します。 -
commit
コマンドで-a
スイッチを使用して、すべての既知のファイル(つまり、インデックスに既にリストされているすべてのファイル)からの変更を自動的に「追加」し、ワーキングツリーから削除されたインデックス内のファイルを自動的に「削除」してから、実際のコミットを実行する。 -
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> は
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 <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
、つまり追跡されていないファイルとディレクトリを表示します。可能なオプションは以下の通りです。
論理値
true
の通常の綴りはすべてnormal
として、false
はno
として解釈されます。デフォルトは、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 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
オプションを使用して入力の手間を省くことができます。ただし、マージ解決中は、変更が単一のコミットとして記録されるべきであるため、パス名を使用して 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
オプションは、「昨日」や「先週金曜日の正午」のような、より人間中心の相対的な日付形式も解釈しようとします。
議論
必須ではありませんが、コミットメッセージの冒頭に、変更を要約した短い(50文字以内)1行を書き、その後に空行を挟んで詳細な説明を記述することをお勧めします。コミットメッセージの最初の空行までのテキストはコミットタイトルとして扱われ、そのタイトルはGit全体で利用されます。例えば、git-format-patch[1] はコミットをメールに変換し、件名行にタイトルを、本文に残りのコミットを使用します。
Gitはある程度、文字エンコーディングに依存しません。
-
ブロブオブジェクトの内容は、解釈されないバイトシーケンスです。コアレベルでのエンコーディング変換はありません。
-
パス名はUTF-8正規化形式Cでエンコードされます。これはツリーオブジェクト、インデックスファイル、リファレンス名、およびコマンドライン引数、環境変数、設定ファイル(
.git/config
(git-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はそれを禁止しません。ただし、いくつかの点に留意する必要があります。
-
git commit
およびgit commit-tree
は、コミットログメッセージが有効なUTF-8文字列に見えない場合、プロジェクトがレガシーエンコーディングを使用していることを明示的に指定しない限り、警告を発します。これを指定する方法は、.git/config
ファイルにi18n.commitEncoding
を次のように設定することです。[i18n] commitEncoding = ISO-8859-1
上記の設定で作成されたコミットオブジェクトは、
i18n.commitEncoding
の値をそのencoding
ヘッダーに記録します。これは、後でそれらを見る他の人々を助けるためです。このヘッダーがない場合、コミットログメッセージはUTF-8でエンコードされていることを意味します。 -
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 config commit.cleanup whitespace
を実行します(ただし、この設定を行うと、コミットログテンプレート内の#
で始まるヘルプ行は自分で削除する必要があることに注意してください)。 -
commit.gpgSign
-
すべてのコミットにGPG署名を行うべきかを指定する真偽値。リベースなどの操作を行う際にこのオプションを使用すると、大量のコミットが署名される可能性があります。GPGパスフレーズを何度も入力するのを避けるためにエージェントを使用すると便利かもしれません。
-
commit.status
-
エディタを使用してコミットメッセージを準備する際に、コミットメッセージテンプレートにステータス情報を含めるかどうかを有効/無効にする真偽値。デフォルトは
true
です。 -
commit.template
-
新しいコミットメッセージのテンプレートとして使用するファイルのパス名を指定します。
-
commit.verbose
-
git commit
で詳細度レベルを指定する真偽値または整数。
フック
このコマンドは、commit-msg
、prepare-commit-msg
、pre-commit
、post-commit
、および post-rewrite
の各フックを実行できます。詳細については、githooks[5] を参照してください。
GIT
git[1] スイートの一部