セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
- 2.50.1 変更なし
-
2.50.0
2025-06-16
- 2.49.1 変更なし
-
2.49.0
2025-03-14
- 2.46.2 → 2.48.2 変更なし
-
2.46.1
2024-09-13
- 2.45.1 → 2.46.0 変更なし
-
2.45.0
2024-04-29
- 2.43.2 → 2.44.4 変更なし
-
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
概要
gitcommit[-a|--interactive|--patch] [-s] [-v] [-u[<mode>]] [--amend] [--dry-run] <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オプションを使用すると、すべての既知のファイル(つまり、すでにインデックスにリストされているすべてのファイル)からの変更を自動的に「追加」し、作業ツリーから削除されたインデックス内のファイルを自動的に「rm」し、その後実際のコミットを実行します。 -
commitコマンドで--interactiveまたは--patchオプションを使用すると、操作を確定する前に、インデックス内のコンテンツに加えて、どのファイルまたはハンクをコミットの一部にするかを1つずつ決定します。これらのモードの操作方法については、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>-
gitrebase--autosquashで適用されたときに <commit> を「修正」する新しいコミットを作成します。単純な--fixup=<commit> は、<commit> の内容を変更するがログメッセージは変更しない「fixup!」コミットを作成します。--fixup=amend:<commit> も同様ですが、<commit> のログメッセージを「amend!」コミットのログメッセージで置き換える「amend!」コミットを作成します。--fixup=reword:<commit> は、<commit> のログメッセージを自身のログメッセージで置き換えるが、<commit> の内容には変更を加えない「amend!」コミットを作成します。単純な
--fixup=<commit> によって作成されたコミットは、「fixup!」に <commit> のタイトルが続くタイトルを持ち、gitrebase--autosquashによって特別に認識されます。-mオプションを使用して作成されたコミットのログメッセージを補足できますが、「fixup!」コミットがgitrebase--autosquashによって <commit> にスカッシュされると、追加のコメントは破棄されます。--fixup=amend:<commit> で作成されたコミットも同様ですが、そのタイトルには「amend!」が接頭辞として付加されます。<commit> のログメッセージは「amend!」コミットのログメッセージにコピーされ、エディタで開かれるため、修正できます。gitrebase--autosquashが「amend!」コミットを <commit> にスカッシュすると、<commit> のログメッセージは「amend!」コミットから修正されたログメッセージに置き換えられます。--allow-empty-messageが指定されていない限り、「amend!」コミットのログメッセージが空であることはエラーです。--fixup=reword:<commit> は--fixup=amend:<commit>--onlyの略記です。これは、ログメッセージのみの「amend!」コミットを作成します(インデックスにステージされた変更は無視されます)。gitrebase--autosquashによってスカッシュされると、他の変更を加えることなく <commit> のログメッセージを置き換えます。「fixup!」コミットも「amend!」コミットも、
gitrebase--autosquashによって適用された場合、<commit> の作成者を変更しません。詳細については、git-rebase[1] を参照してください。 --squash=<commit>-
gitrebase--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> はパターンと見なされ、その著者による既存のコミットを検索するために使用されます(つまり、
gitrev-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トレーラーを追加します。サインオフの意味は、コミットするプロジェクトによって異なります。たとえば、コミッターがプロジェクトのライセンスに基づいて作業を提出する権利を持っていること、またはDeveloper Certificate of Originなどのコントリビューター表現に同意することを証明する場合があります。(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-
エディターを起動せずに、選択したコミットメッセージを使用します。たとえば、
gitcommit--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] の「RECOVERING FROM UPSTREAM REBASE」セクションを参照してください)。
--no-post-rewrite-
post-rewriteフックをバイパスします。 -i--include-
これまでにステージされた内容からコミットを作成する前に、コマンドラインで与えられたパスの内容もステージします。これは、競合したマージを完了する場合を除いて、通常は望ましくありません。
-o--only-
コマンドラインで指定されたパスの更新された作業ツリーの内容を取得してコミットを作成し、他のパス用にステージングされた内容は無視します。コマンドラインにパスが指定されている場合、これが
gitcommitのデフォルトの動作モードであり、このオプションは省略できます。このオプションが--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> はオプションで、コミッターの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 オプションを使用して入力の手間を省くことができます。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,07Apr200522: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文字以内)単一行で始め、その後に空行を挟んで、より詳細な説明を続けるのが良い習慣です。コミットメッセージの最初の空行までのテキストはコミットタイトルとして扱われ、そのタイトルは 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 ポーセレンの両方は、プロジェクトに UTF-8 を強制しないように設計されています。特定のプロジェクトのすべての参加者がレガシーエンコーディングを使用する方が便利だと感じた場合、Git はそれを禁止しません。ただし、いくつか留意すべき点があります。
-
gitcommitとgitcommit-treeは、与えられたコミットログメッセージが有効な UTF-8 文字列に見えない場合、明示的にプロジェクトがレガシーエンコーディングを使用していると指定しない限り、警告を発します。これを指定するには、.git/configファイルにi18n.commitEncodingを次のように設定します。[i18n] commitEncoding = ISO-8859-1
上記の設定で作成されたコミットオブジェクトは、
encodingヘッダーにi18n.commitEncodingの値を記録します。これは、後でそれらを見る他の人々を助けるためです。このヘッダーがない場合、コミットログメッセージは UTF-8 でエンコードされていることを意味します。 -
gitlog、gitshow、gitblameなどのコマンドは、コミットオブジェクトの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-
この設定は
gitcommitの--cleanupオプションのデフォルトを上書きします。デフォルトを変更することは、コミットログメッセージにコメント文字(core.commentChar、デフォルトは#)で始まる行を常に保持したい場合に便利です。その場合、gitconfigcommit.cleanupwhitespaceを実行します(この場合、コミットログテンプレートのコメント文字で始まるヘルプ行は自分で削除する必要があることに注意してください)。 commit.gpgSign-
すべてのコミットを GPG 署名するかどうかを指定するブール値。リベースなどの操作でこのオプションを使用すると、多数のコミットが署名される可能性があります。GPG パスフレーズを何度も入力するのを避けるために、エージェントを使用すると便利です。
commit.status-
コミットメッセージを作成するためにエディタを使用する場合、コミットメッセージテンプレートにステータス情報を含めるかどうかを有効/無効にするブール値。デフォルトは
trueです。 commit.template-
新しいコミットメッセージのテンプレートとして使用するファイルのパス名を指定します。
commit.verbose-
gitcommitの詳細度レベルを指定するブール値または整数。
フック
このコマンドは、commit-msg、prepare-commit-msg、pre-commit、post-commit、および post-rewrite フックを実行できます。詳細については、githooks[5] を参照してください。
GIT
git[1]スイートの一部