git-commit - クラウドでオンライン

プログラム：

NAME

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

SYNOPSIS

git コミット [-a | --インタラクティブ | --パッチ] [-s] [-v] [-u ] [ - 修正する]
[--dry-run] [(-c | -C | --fixup | --squash) 】
[-F | -m ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= 】
[--日付= ] [--クリーンアップ= ] [ - [ステタスはありません]
[-i | -o] [-S[ ]] [--] [ ...]

DESCRIPTION

インデックスの現在の内容を、ログ メッセージとともに新しいコミットに保存します。
ユーザーが変更を説明します。

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

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

2. を使用して git rm 作業ツリーとインデックスからファイルを削除する前にもう一度実行します。
コミット 指図;

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

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

5. --interactive または --patch スイッチを使用して、 コミット 一つを決めるコマンド
ファイナライズする前に、どのファイルまたはハンクをコミットに含めるかを XNUMX つずつ決定します。
手術。 「インタラクティブ モード」セクションを参照してください。 git-追加(1) 操作方法を学ぶ
これらのモード。

--dry-run オプションを使用すると、いずれかのファイルに含まれる内容の概要を取得できます。
次のコミットでは、同じパラメータのセット (オプションとパス) を指定して上記のようにします。

コミットして直後にミスを見つけた場合でもリカバリーできます。
それで git リセット.

OPTIONS

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

-p、--パッチ
インタラクティブなパッチ選択インターフェイスを使用して、コミットする変更を選択します。 見る
git-追加詳細は（1）。

-C 、 --reuse-message=
既存のコミット オブジェクトを取得し、ログ メッセージと作成者を再利用します。
コミット作成時の情報 (タイムスタンプを含む)。

-c 、 --reedit-message=
いいね -Cしかし、と -c エディターが呼び出され、ユーザーがさらに編集できるようになります。
コミットメッセージ。

--fixup=
rebase --autosquash で使用するコミット メッセージを作成します。 コミットメッセージは、
指定されたコミットの件名行に「fixup!」というプレフィックスを付けます。 見る ギット-
リベース詳細は（1）。

--スカッシュ=
rebase --autosquash で使用するコミット メッセージを作成します。 コミットメッセージ
件名行は、「squash!」という接頭辞が付いた指定されたコミットから取得されます。 できる
追加のコミット メッセージ オプション (-m/-c/-C/-F) とともに使用されます。 見る git-リベース（1）
詳細。

--リセット-作者
-C/-c/--amend オプションとともに使用する場合、または aa が競合した後にコミットする場合
チェリーピックでは、結果として得られるコミットの作成者が現在、
コミッター。 これにより、作成者のタイムスタンプも更新されます。

- 短い
予行演習を行う場合は、短い形式で出力してください。 見る git ステータス（1）
詳細。 --dry-run を意味します。

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

- 磁器
予行演習を行う場合は、出力を磁器対応形式で提供します。 見る git ステータス(1)
詳細については。 --dry-run を意味します。

- 長さ
予行演習を行う場合は、出力を長い形式で提供します。 --dry-run を意味します。

-z、--null
短いまたは磁器のステータス出力を表示する場合は、ステータス出力のエントリを終了します。
LF の代わりに NUL を使用します。 形式が指定されていない場合は、--porcelain 出力形式が暗黙的に指定されます。

-F 、 --file=
指定されたファイルからコミット メッセージを取得します。 使用 - からのメッセージを読むには、
標準入力。

--著者=
コミット作成者をオーバーライドします。 標準の AU Thor を使用して明示的な作成者を指定します。
<[メール保護]> フォーマットします。 さもないとパターンとみなされ使用されます
その作成者による既存のコミットを検索するには (つまり、rev-list --all -i)
--著者= ); コミット作成者は、最初に見つかったコミットからコピーされます。

--日付=
コミットで使用される作成者の日付をオーバーライドします。

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

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

-s、--サインオフ
コミット ログ メッセージの最後にコミッターによる Signed-off-by 行を追加します。 の
サインオフの意味はプロジェクトによって異なりますが、通常はコミッターを認証します。
同じライセンスの下でこの作品を提出する権利を持ち、開発者に同意します
原産地証明書（を参照） http://developercertificate.org/ ）詳細については、のために。

-n、--no-verify
このオプションは、pre-commit フックと commit-msg フックをバイパスします。 こちらも参照 githookとします。

--allow-empty
通常、唯一の親コミットとまったく同じツリーを持つコミットを記録することは、
間違いがあるため、コマンドによってそのようなコミットを行うことができなくなります。 このオプションはバイパスします
安全性が高く、主に外部の SCM インターフェイス スクリプトによって使用されます。

--allow-空のメッセージ
--allow-empty と同様、このコマンドは主に外部 SCM インターフェイス スクリプトによって使用されます。
プラミングを使用せずに空のコミットメッセージを含むコミットを作成できます。
のようなコマンド git コミット ツリーとします。

--クリーンアップ=
このオプションは、指定されたコミット メッセージを事前にクリーンアップする方法を決定します。
コミットしている。 の ストリップ、ホワイトスペース、逐語的、はさみ、またはデフォルトを指定できます。

ストリップ
先頭と末尾の空行、末尾の空白、コメント、および
連続した空行を折りたたむ。

空白
#commentary が削除されない点を除き、ストリップと同じです。

逐語的
メッセージは一切変更しないでください。

はさみ
ホワイトスペースと同じですが、「#」行以降 (および行を含む) がすべて異なります。
------------------------ >8 ------------------------ " というメッセージが表示された場合、切り捨てられます。
編集されることになります。 「#」はcore.commentCharでカスタマイズできます。

デフォルト
メッセージを編集する場合はストリップと同じです。 それ以外の場合は空白。

デフォルトは次の方法で変更できます。 コミット.クリーンアップ 構成変数 (「 ギット-
設定（1））。

-e、--edit
-F を使用するとファイルから、-m を使用するとコマンドラインから、および -m を使用してコミットオブジェクトから取得されたメッセージ
-C は通常、変更されないコミット ログ メッセージとして使用されます。 このオプションを使用すると、さらに次のことを行うことができます
これらのソースから取得したメッセージを編集します。

--編集なし
エディタを起動せずに、選択したコミット メッセージを使用します。 たとえば、git commit
--amend --no-edit は、コミット メッセージを変更せずにコミットを修正します。

--修正
新しいコミットを作成して、現在のブランチの先端を置き換えます。 記録されたツリーは、
通常どおりに準備されます (-i および -o オプションの効果と明示的な指定を含む)
pathspec)、元のコミットからのメッセージが開始点として使用されます。
コマンドラインから他のメッセージが指定されていない場合は、空のメッセージの代わりに
-m、-F、-c などのオプションを使用します。新しいコミットの親と作成者は同じです。
現在のもの (--reset-author オプションでこれを無効にすることができます)。

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

$ git restart --soft HEAD^
$ ... 適切なツリーを見つけるために何か他のことをします ...
$ git commit -c ORIG_HEAD

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

コミットを修正する場合、履歴を書き換えることの影響を理解する必要があります。
はすでに出版されています。 (「上流リベースからの回復」セクションを参照してください) ギット-
リベース（1）。）

--ポストリライトなし
書き換え後のフックをバイパスします。

-i、-include
これまでにステージングされたコンテンツをコミットする前に、パスのコンテンツをステージングします。
コマンドラインでも指定できます。 通常、これは、そうでない限り、望んでいることではありません。
競合するマージを終了します。

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

-u [ ]、-untracked-files [= ]
追跡されていないファイルを表示します。

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

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

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

· 通常の - 追跡されていないファイルとディレクトリを表示します

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

デフォルトは、status.showUntrackedFiles構成を使用して変更できます。
で文書化された変数 git-configとします。

-v、-verbose
HEAD コミットと最後にコミットされるものとの間の統合された差分を表示します。
ユーザーがコミットを説明するのに役立つコミット メッセージ テンプレート。
コミットに含まれる変更。 この diff 出力には接頭辞が付いている行がないことに注意してください。
　 #。 この差分はコミット メッセージの一部ではありません。

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

-q、-quiet
コミット概要メッセージを抑制します。

-ドライラン
コミットは作成しませんが、コミットされるパスのリストを表示します。
ローカルの変更はコミットされずに残され、パスは追跡されません。

- 状態
の出力を含めます git ステータス(1) を使用する場合のコミット メッセージ テンプレート内
エディターでコミットメッセージを準備します。 デフォルトはオンですが、オーバーライドするために使用できます。
構成変数 commit.status。

- ステタスはありません
の出力は含めないでください。 git ステータス(1)使用時のコミットメッセージテンプレート内
デフォルトのコミットメッセージを準備するエディタ。

-S[ ]、--gpg-sign[= 】
GPG 署名コミット。 keyid 引数はオプションであり、デフォルトはコミッタです。
身元; 指定する場合は、スペースを入れずにオプションに固定する必要があります。

--gpg サインなし
Countermand commit.gpgSign 構成変数は、それぞれを強制するように設定されています。
署名されることを約束します。

--
それ以上の引数をオプションとして解釈しないでください。

..。
コマンドラインでファイルが指定されると、コマンドはファイルの内容をコミットします。
すでにステージングされた変更を記録せずに、名前付きファイルを作成します。 これらのファイルの内容
また、以前にステージングされたものに加えて、次のコミットのためにステージングされます。

DATE 書式

GIT_AUTHOR_DATE、GIT_COMMITTER_DATE 環境変数および --date オプション
次の日付形式をサポートしています。

Gitの内部形式
それは、 どこの数です
UNIX エポックからの秒数。 正または負のオフセットです
UTCから。 たとえば、CET (協定世界時より 2 時間進んでいます) は +0200 です。

RFC 2822
RFC 2822 で説明されている標準電子メール形式 (例: Thu, 07 Apr 2005)
22:13:13 +0200。

ISO 8601
ISO 8601 標準で指定された日時 (例: 2005-04-07T22:13:13)。 の
パーサーは、T 文字の代わりにスペースも受け入れます。

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

例

自分の作業を記録する場合、作業ツリー内の変更されたファイルの内容は次のようになります。
「インデックス」と呼ばれるステージング領域に一時的に保存されます。 git 加えます。 ファイルは次のとおりです
インデックス内のみで、作業ツリー内ではなく、最後のコミットの状態に戻ります。
git リセット HEAD を使用 -- 、効果的に元に戻ります git 加えます そして変更を防ぎます
次のコミットへの参加からこのファイルに追加されます。 あるべき状態を構築した後、
これらのコマンド git commit (パス名パラメータなし) を使用して段階的にコミットします。
これまでに上演されたものを記録するために使用されます。 これはコマンドの最も基本的な形式です。
例：

$ 編集 hello.c
$ git rm さようなら.c
$ git add hello.c
$ git コミット

個々の変更の後にファイルをステージングする代わりに、 git commit に通知するように指示できます。
作業ツリーで内容が追跡されているファイルへの変更
対応する git add および git rm。 つまり、この例は次と同じことを行います。
作業ツリーに他に変更がない場合の前述の例:

$ 編集 hello.c
$ rm さようなら.c
$ git commit -a

コマンド git commit -a は、まず作業ツリーを調べ、変更されたことに気づきます。
hello.c を削除し、goodbye.c を削除し、必要な git add と git rm を実行します。

多くのファイルへの変更をステージングした後、変更が記録される順序を変更できます。
git commit にパス名を指定します。 パス名が指定されると、コマンドはコミットを行います。
これは、名前付きパスに加えられた変更のみを記録します。

$ 編集 hello.c hello.h
$ git add hello.c hello.h
$ メイクファイルを編集する
$ git commit メイクファイル

これにより、Makefile への変更を記録するコミットが作成されます。 段階的に行われた変更
hello.c と hello.h は、結果のコミットには含まれません。 ただし、彼らの変化は、
失われたわけではありません。それらはまだ演出されており、単に抑制されているだけです。 上記のシーケンスの後、
行う：

$ git コミット

この XNUMX 番目のコミットでは、期待どおり hello.c と hello.h への変更が記録されます。

マージ後 (開始者によって) git マージ or git プル) 競合のため、きれいに停止します
マージされたパスはコミットされるようにすでにステージングされており、競合したパスは
結合されていない状態のままです。 まずどのパスが競合しているかを確認する必要があります git
status 作業ツリーでそれらを手動で修正した後、結果を次のようにステージングします。
いつもの git 加えます:

$ git ステータス | grep マージ解除
マージされていない: hello.c
$ 編集 hello.c
$ git add hello.c

競合を解決し、結果をステージングした後、 git ls-files -u は言及を停止します。
競合するパス。 完了したら、 git commit を実行して、最後にマージを記録します。

$ git コミット

独自の変更を記録する場合と同様、-a オプションを使用すると入力を省略できます。 XNUMXつ
違いは、マージ解決中に、パス名を指定して git commit を使用できないことです。
マージは次のように記録される必要があるため、変更がコミットされる順序を変更します。
単一のコミット。 実際、このコマンドはパス名を指定すると実行を拒否します (ただし、-i を参照してください)。
オプション）。

考察

必須ではありませんが、コミット メッセージを XNUMX つの短いメッセージで始めることをお勧めします。
変更を要約した (50 文字未満の) 行、その後に空白行、そして
より詳しい説明。 コミットメッセージの最初の空白行までのテキストは、
コミット タイトルとして扱われ、そのタイトルが Git 全体で使用されます。 例えば、 ギット-
フォーマットパッチ(1) コミットを電子メールに変換し、件名にタイトルを使用し、
コミットの残りの部分は本体にあります。

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

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

· パス名は UTF-8 正規化形式 C でエンコードされます。これはツリー オブジェクトに適用されます。
インデックス ファイル、参照名、コマンド ライン引数のパス名、
環境変数と構成ファイル (.git/config (を参照) git-config（1））、 ギグノーレ（5）
git属性（5）と gitモジュール（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 コミット & git コミットツリー コミットログメッセージが与えられた場合に警告を発行します
プロジェクトが
レガシーエンコーディング。 これを行う方法は、.git/config に i18n.commitencoding を含めることです。
次のようなファイル:

[i18n]
コミットエンコーディング = ISO-8859-1

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

2. git ログ, git 表示する, git 非難 そして友人はコミットのエンコーディングヘッダーを確認します
オブジェクトを削除し、特に指定がない限り、ログ メッセージを UTF-8 に再コード化してみます。 あなた
.git/config の i18n.logoutputencoding で目的の出力エンコーディングを指定できます
次のようなファイル:

[i18n]
logoutputencoding = ISO-8859-1

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

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

ENVIRONMENT そして CONFIGURATION 変数

コミット ログ メッセージの編集に使用されるエディタは、GIT_EDITOR から選択されます。
環境変数、core.editor 構成変数、VISUAL 環境
変数、または EDITOR 環境変数 (この順序)。 見る git-var詳細は（1）。

フック

このコマンドは、commit-msg、prepare-commit-msg、コミット前およびコミット後のフックを実行できます。
見る githook（5）詳細については。

onworks.net サービスを使用してオンラインで git-commit を使用する