commit

NAME名

git-commit - Record changes to the repositorygit-commit - リポジトリへの変更を記録する

SYNOPSIS概要

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] [-S[<keyid>]] [--] [<file>…]

DESCRIPTION説明

Create a new commit containing the current contents of the index and the given log message describing the changes. The new commit is a direct child of HEAD, usually the tip of the current branch, and the branch is updated to point to it (unless no branch is associated with the working tree, in which case HEAD is "detached" as described in git-checkout[1]).現在のインデックスの内容と変更を説明するログメッセージを含む新しいコミットを作成します。新しいコミットはHEADの直接の子で、通常は現在のブランチの先端です。ブランチがそれを指すように更新されます（ブランチが作業ツリーに関連付けられていない場合、gitで説明されているようにHEADは「切り離されます」- チェックアウト[1]）。

The content to be committed can be specified in several ways:コミットするコンテンツは、いくつかの方法で指定できます。

by using git-add[1] to incrementally "add" changes to the index before using the commit command (Note: even modified files must be "added");使用して、[1]のgitを加算使用する前に、増分インデックスに変更を「追加」するためにコミットコマンドを（注：さえ変更されたファイルが「追加」されなければなりません）。
by using git-rm[1] to remove files from the working tree and the index, again before using the commit command;使用してのgit-RMを[1]を再び使用する前に、作業ツリーとインデックスからファイルを削除するにはコミットコマンドを。
by listing files as arguments to the commit command (without --interactive or --patch switch), in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git);ファイルをcommitコマンドの引数として一覧表示することによって（--interactiveまたは--patchスイッチなしで）、その場合、コミットはインデックスにステージングされた変更を無視し、代わりに一覧表示されたファイルの現在の内容を記録します。 Git）に;
by using the -a switch with the commit command to automatically "add" changes from all known files (i.e. all files that are already listed in the index) and to automatically "rm" files in the index that have been removed from the working tree, and then perform the actual commit;commitコマンドで-aスイッチを使用して、すべての既知のファイル（つまり、既にインデックスに登録されているすべてのファイル）からの変更を自動的に「追加」し、作業ツリーから削除されたインデックス内のファイルを自動的に「rm」します。その後、実際のコミットを実行します。
by using the --interactive or --patch switches with the commit command to decide one by one which files or hunks should be part of the commit in addition to contents in the index, before finalizing the operation. See the “Interactive Mode” section of git-add[1] to learn how to operate these modes.--interactiveまたは--patchをcommitコマンドと一緒に使用して、操作を完了する前に、インデックスの内容に加えてどのファイルまたはハンクをコミットの一部にするかを1つずつ決定します。これらのモードの操作方法については、git-add [1]の「インタラクティブモード」の節を参照してください。

The --dry-run option can be used to obtain a summary of what is included by any of the above for the next commit by giving the same set of parameters (options and paths).この--dry-runオプションを使用して、同じパラメータセット（オプションとパス）を指定することで、次のコミットのために上記のいずれかに含まれるものの概要を取得できます。

If you make a commit and then find a mistake immediately after that, you can recover from it with git reset.コミットした直後に間違いを見つけた場合は、git resetを使ってそれから回復することができます。

OPTIONSオプション

-a

--all - すべて

Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.変更および削除されたファイルを自動的にステージングするようにコマンドに指示しますが、Gitに通知されていない新しいファイルは影響を受けません。

-p

--patch - パッチ

Use the interactive patch selection interface to chose which changes to commit. See git-add[1] for details.対話型パッチ選択インタフェースを使用して、コミットする変更を選択してください。詳細はgit-add [1]を見てください。

-C <commit> -C <コミット>

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

Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit.既存のコミットオブジェクトを取り、コミットを作成するときにログメッセージと作成者情報（タイムスタンプを含む）を再利用します。

-c <commit>

--reedit-message=<commit> --reedit-message = <コミット>

Like -C, but with -c the editor is invoked, so that the user can further edit the commit message.-Cと似ていますが-c、エディタを使用して呼び出されるため、ユーザーはコミットメッセージをさらに編集できます。

--fixup=<commit> --fixup = <commit>

Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase[1] for details.で使用するためのコミットメッセージを作成しrebase --autosquashます。コミットメッセージは、指定されたコミットの件名に "fixup！"という接頭辞を付けたものになります。詳細はgit-rebase [1]を見てください。

--squash=<commit> --squash = <commit>

Construct a commit message for use with rebase --autosquash. The commit message subject line is taken from the specified commit with a prefix of "squash! ". Can be used with additional commit message options (-m/-c/-C/-F). See git-rebase[1] for details.で使用するためのコミットメッセージを作成しrebase --autosquashます。コミットメッセージの件名は、指定されたコミットの先頭に "squash！"を付けたものです。追加のコミットメッセージオプション（-m/ -c/ -C/ -F）と共に使用できます。詳細はgit-rebase [1]を見てください。

--reset-author

When used with -C/-c/--amend options, or when committing after a conflicting cherry-pick, declare that the authorship of the resulting commit now belongs to the committer. This also renews the author timestamp.-C / -c / - 修正オプションとともに使用した場合、または競合するチェリーピックの後にコミットした場合は、結果として得られたコミットの作成者がコミッターに属していることを宣言します。これは作者のタイムスタンプも更新します。

--short - ショート

When doing a dry-run, give the output in the short-format. See git-status[1] for details. Implies --dry-run.予行演習を行うときは、短い形式で出力してください。詳細はgit-status [1]を見てください。ほのめかし--dry-runます。

--branch - ブランチ

Show the branch and tracking info even in short-format.短い形式でも分岐と追跡情報を表示します。

--porcelain - 磁器

When doing a dry-run, give the output in a porcelain-ready format. See git-status[1] for details. Implies --dry-run.予行演習を行うときは、磁器対応フォーマットで出力してください。詳細はgit-status [1]を見てください。ほのめかし--dry-runます。

--long - 長いです

When doing a dry-run, give the output in the long-format. Implies --dry-run.予行演習を行うときは、出力を長形式で指定してください。ほのめかし--dry-runます。

-z

--null - ヌル

When showing short or porcelain status output, print the filename verbatim and terminate the entries with NUL, instead of LF. If no format is given, implies the --porcelain output format. Without the -z option, filenames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git-config[1]).表示shortまたはporcelainステータス出力の際には、ファイル名を逐語的に表示し、エントリをLFではなくNULで終了します。フォーマットが指定されていない場合は、--porcelain出力フォーマットを意味します。この-zオプションがなければ、"変わった"文字を含むファイル名は設定変数で説明されているように引用符で囲まれますcore.quotePath（git-config [1]を参照）。

-F <file> -F <ファイル>

--file=<file> --file = <ファイル>

Take the commit message from the given file. Use - to read the message from the standard input.与えられたファイルからコミットメッセージを取ります。標準入力からメッセージを読み取るには、-を使用してください。

--author=<author> --author = <author>

Override the commit author. Specify an explicit author using the standard A U Thor <author@example.com> format. Otherwise <author> is assumed to be a pattern and is used to search for an existing commit by that author (i.e. rev-list --all -i --author=<author>); the commit author is then copied from the first such commit found.コミット作者を上書きします。標準A U Thor <author@example.com>形式を使用して明示的な作者を指定してください。それ以外の場合、<author>はパターンと見なされ、その作者による既存のコミットを検索するために使用されます（すなわち、rev-list --all -i --author = <author>）。コミットの作成者は、最初に見つかったコミットからコピーされます。

--date=<date> --date = <日付>

Override the author date used in the commit.コミットに使用された作成者の日付を上書きします。

-m <msg>

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

Use the given <msg> as the commit message. If multiple -m options are given, their values are concatenated as separate paragraphs.コミットメッセージとして与えられた<msg>を使用してください。複数の-mオプションが指定されている場合、それらの値は別々の段落として連結されます。

The -m option is mutually exclusive with -c, -C, and -F.-mオプションは相互に排他的である-c、-Cと-F。

-t <file> -t <ファイル>

--template=<file> --template = <ファイル>

When editing the commit message, start the editor with the contents in the given file. The commit.template configuration variable is often used to give this option implicitly to the command. This mechanism can be used by projects that want to guide participants with some hints on what to write in the message in what order. If the user exits the editor without editing the message, the commit is aborted. This has no effect when a message is given by other means, e.g. with the -m or -F options.コミットメッセージを編集するときは、与えられたファイルの内容でエディタを起動してください。commit.template設定変数は、多くの場合、コマンドに暗黙のうちに、このオプションを与えるために使用されます。このメカニズムは、何を順番にメッセージに書き込むかについてのヒントを使用して参加者をガイドしたいプロジェクトで使用できます。ユーザがメッセージを編集せずにエディタを終了すると、コミットは中止されます。メッセージが他の方法で与えられたとき、例えば-mまたは-Fオプションを使ったとき、これは効果がありません。

-s

--signoff - サインオフ

Add Signed-off-by line by the committer at the end of the commit log message. The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see http://developercertificate.org/ for more information).コミットログメッセージの最後に、コミッターによるサインオフラインを追加します。承認の意味はプロジェクトによって異なりますが、通常、コミッターは同じライセンスの下でこの作品を送信する権利を持っていることを証明し、開発者証明書に同意します（詳細についてはhttp://developercertificate.org/を参照）。

-n

--no-verify

This option bypasses the pre-commit and commit-msg hooks. See also githooks[5].このオプションはpre-commitフックとcommit-msgフックをバイパスします。githooks [5]もご覧ください。

--allow-empty - 許可 - 空

Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is primarily for use by foreign SCM interface scripts.通常、その唯一の親コミットとまったく同じツリーを持つコミットを記録するのは誤りです。このコマンドは、そのようなコミットをすることを妨げます。このオプションは安全性を迂回し、主に外部のSCMインタフェーススクリプトで使用されます。

--allow-empty-message

Like --allow-empty this command is primarily for use by foreign SCM interface scripts. It allows you to create a commit with an empty commit message without using plumbing commands like git-commit-tree[1].--allow-emptyと同様に、このコマンドは主に外部のSCMインタフェーススクリプトで使用されます。git-commit-tree [1]のような配管コマンドを使わずに、空のコミットメッセージでコミットを作成することができます。

--cleanup=<mode> --cleanup = <モード>

This option determines how the supplied commit message should be cleaned up before committing. The <mode> can be strip, whitespace, verbatim, scissors or default.このオプションは、提供されたコミットメッセージをコミット前にどのようにクリーンアップするかを決定します。<モード>することができstrip、whitespace、verbatim、scissorsまたはdefault。

strip ストリップ

Strip leading and trailing empty lines, trailing whitespace, commentary and collapse consecutive empty lines.先頭と末尾の空白行、末尾の空白、コメントと、連続する空白行を折りたたむ。

whitespace 空白

Same as strip except #commentary is not removed.strip#commentaryが削除されていない以外は同じです。

verbatim 逐語的

Do not change the message at all.メッセージをまったく変更しないでください。

scissors はさみ

Same as whitespace except that everything from (and including) the line found below is truncated, if the message is to be edited. "#" can be customized with core.commentChar.whitespaceメッセージを編集する場合は、以下の行から（およびそれを含む）すべてが切り捨てられること以外は同じです。" #"はcore.commentCharでカスタマイズできます。

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

default デフォルト

Same as strip if the message is to be edited. Otherwise whitespace.stripメッセージを編集する場合と同じです。そうでなければwhitespace。

The default can be changed by the commit.cleanup configuration variable (see git-config[1]).デフォルトはcommit.cleanup設定変数で変更できます（git-config [1]参照）。

-e

--edit - 編集

The message taken from file with -F, command line with -m, and from commit object with -C are usually used as the commit log message unmodified. This option lets you further edit the message taken from these sources.file with -F、command line with -m、from from commit object withから取得されたメッセージ-Cは、通常、変更されずにコミットログメッセージとして使用されます。このオプションを使用すると、これらのソースから取得したメッセージをさらに編集できます。

--no-edit

Use the selected commit message without launching an editor. For example, git commit --amend --no-edit amends a commit without changing its commit message.エディタを起動せずに選択したコミットメッセージを使用します。たとえばgit commit --amend --no-edit、コミットメッセージを変更せずにコミットを修正します。

--amend - アメンド

Replace the tip of the current branch by creating a new commit. The recorded tree is prepared as usual (including the effect of the -i and -o options and explicit pathspec), and the message from the original commit is used as the starting point, instead of an empty message, when no other message is specified from the command line via options such as -m, -F, -c, etc. The new commit has the same parents and author as the current one (the --reset-author option can countermand this).新しいコミットを作成して現在のブランチの先端を置き換えます。記録されたツリーは（-iand -oオプションと明示的なパス指定の効果を含めて）通常通り準備され、コマンドラインから他のメッセージが指定されていない場合は、空のメッセージの代わりに元のコミットからのメッセージが開始点として使用されます。以下のようなオプションを経由して-m、-F、-cなど、新しいコミット現在の（同じ親や著者を持っている--reset-authorオプションは、これを打ち消すことができます）。

It is a rough equivalent for:これは次のものと大体同じです。

	$ git reset --soft HEAD^
	$ ... do something else to come up with the right tree ...
	$ git commit -c ORIG_HEAD

but can be used to amend a merge commit.しかしマージコミットを修正するために使用することができます。

You should understand the implications of rewriting history if you amend a commit that has already been published. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase[1].)すでに公開されているコミットを修正する場合は、履歴を書き換えることの意味を理解する必要があります。（git-rebase [1]の「UPSTREAM REBASEからの回復」を参照してください。）

--no-post-rewrite

Bypass the post-rewrite hook.書き換え後フックをバイパスします。

-i -私

--include - 含める

Before making a commit out of staged contents so far, stage the contents of paths given on the command line as well. This is usually not what you want unless you are concluding a conflicted merge.ここまでの段階的な内容からコミットを行う前に、コマンドラインで与えられたパスの内容も段階的に決めてください。競合するマージを締結していない限り、これは通常あなたが望むことではありません。

-o

--only - のみ

Make a commit by taking the updated working tree contents of the paths specified on the command line, disregarding any contents that have been staged for other paths. This is the default mode of operation of git commit if any paths are given on the command line, in which case this option can be omitted. If this option is specified together with --amend, then no paths need to be specified, which can be used to amend the last commit without committing changes that have already been staged. If used together with --allow-empty paths are also not required, and an empty commit will be created.コマンドラインで指定されたパスの更新された作業ツリーの内容を取得し、他のパスにステージされた内容を無視してコミットします。コマンドラインでパスが指定されている場合、これがgit commitのデフォルトの動作モードです。この場合、このオプションは省略できます。このオプションを一緒に指定した場合--amend、パスを指定する必要はありません。これは、既にステージされた変更をコミットせずに最後のコミットを修正するために使用できます。--allow-emptyパスと一緒に使用した場合も必須ではなく、空のコミットが作成されます。

-u[<mode>] -u [<モード>]

--untracked-files[=<mode>] --untracked-files [= <mode>]

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

The mode parameter is optional (defaults to all), and is used to specify the handling of untracked files; when -u is not used, the default is normal, i.e. show untracked files and directories.modeパラメータはオプションで（デフォルトはall）、追跡されていないファイルの処理を指定するために使用されます。-uが使用されていない場合、デフォルトは通常、つまり追跡されていないファイルとディレクトリを表示します。

The possible options are:可能なオプションは以下のとおりです。

no - Show no untracked filesno - 追跡されていないファイルを表示しない
normal - Shows untracked files and directoriesnormal - 追跡されていないファイルとディレクトリを表示する
all - Also shows individual files in untracked directories.all - 追跡されていないディレクトリ内の個々のファイルも表示します。

The default can be changed using the status.showUntrackedFiles configuration variable documented in git-config[1].デフォルトはgit-config [1]に書かれているstatus.showUntrackedFiles設定変数を使って変更することができます。

-v

--verbose - 冗談

Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has. Note that this diff output doesn’t have its lines prefixed with #. This diff will not be a part of the commit message. See the commit.verbose configuration variable in git-config[1].HEADコミットとコミットメッセージテンプレートの下部に何がコミットされるかの統一された差分を表示して、コミットにどのような変更があるのか??を思い出させることでユーザーがコミットを説明できるようにします。このdiff出力の行の先頭に＃が付いていないことに注意してください。この差分はコミットメッセージの一部にはなりません。git-config [1]のcommit.verbose設定変数を見てください。

If specified twice, show in addition the unified diff between what would be committed and the worktree files, i.e. the unstaged changes to tracked files.2回指定された場合は、コミットされるものとワークツリーファイルとの間の統一された差分、つまり追跡されているファイルに対するステージされていない変更をさらに表示します。

-q

--quiet - 静か

Suppress commit summary message.コミット要約メッセージを抑制します。

--dry-run

Do not create a commit, but show a list of paths that are to be committed, paths with local changes that will be left uncommitted and paths that are untracked.コミットを作成しないで、コミットされることになっているパス、コミットされないままにされるローカルな変更があるパス、および追跡されないパスのリストを表示します。

--status - 状態

Include the output of git-status[1] in the commit message template when using an editor to prepare the commit message. Defaults to on, but can be used to override configuration variable commit.status.エディタを使用してコミットメッセージを準備するときは、git-status [1]の出力をコミットメッセージテンプレートに含めます。デフォルトはオンですが、構成変数commit.statusをオーバーライドするために使用できます。

--no-status - ステタスはありません

Do not include the output of git-status[1] in the commit message template when using an editor to prepare the default commit message.エディタを使用してデフォルトのコミットメッセージを準備するときは、git-status [1]の出力をコミットメッセージテンプレートに含めないでください。

-S[<keyid>] -S [<keyid>]

--gpg-sign[=<keyid>] --gpg-sign [= <keyid>]

GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.GPG-signがコミットします。keyid引数はコミッターのアイデンティティオプションで、デフォルトです。指定した場合は、スペースなしでオプションに固定する必要があります。

--no-gpg-sign

Countermand commit.gpgSign configuration variable that is set to force each and every commit to be signed.commit.gpgSign各コミットに署名を強制するように設定されているcountermand 構成変数。

-- -

Do not interpret any more arguments as options.これ以上引数をオプションとして解釈しないでください。

<file>… <ファイル>…

When files are given on the command line, the command commits the contents of the named files, without recording the changes already staged. The contents of these files are also staged for the next commit on top of what have been staged before.ファイルがコマンドラインで指定されると、コマンドはすでにステージされた変更を記録せずに、指定されたファイルの内容をコミットします。これらのファイルの内容は、以前にステージングされたものの上に次のコミットのためにステージングされます。

DATE FORMATS日付フォーマット

The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables and the --date option support the following date formats:GIT_AUTHOR_DATE、GIT_COMMITTER_DATE環境変数と--dateオプションは次の日付形式をサポートしています。

Git internal format Gitの内部フォーマット

It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.これは、ある<unix timestamp> <time zone offset>場合には、<unix timestamp>UNIXエポックからの秒数です。<time zone offset>UTCからの正または負のオフセットです。例えばCET（これはUTCより1時間進んでいます）です+0100。

RFC 2822

The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.たとえば、RFC 2822で説明されている標準の電子メール形式Thu, 07 Apr 2005 22:13:13 +0200。

ISO 8601

Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well.たとえば、ISO 8601規格で指定されている日時2005-04-07T22:13:13。パーサーはT文字の代わりにスペースも受け入れます。

Note	In addition, the date part is accepted in the following formats: `YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`. さらに、日付部分は次の形式で受け入れられます。`YYYY.MM.DD`、`MM/DD/YYYY`および`DD.MM.YYYY`。

EXAMPLES例

When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the "index" with git add. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with git reset HEAD -- <file>, which effectively reverts git add and prevents the changes to this file from participating in the next commit. After building the state to be committed incrementally with these commands, git commit (without any pathname parameter) is used to record what has been staged so far. This is the most basic form of the command. An example:あなた自身の作業を記録するとき、あなたの作業ツリーの変更されたファイルの内容はgit addで "index"と呼ばれるステージング領域に一時的に保存されます。ファイルは、インデックス内のみで作業ツリー内ではなく最後のコミットのファイルに戻すことができますgit reset HEAD -- <file>。これにより、git addが実質的に元に戻され、このファイルへの変更が次のコミットに参加しなくなります。これらのコマンドで段階的にコミットされる状態を構築した後、git commit（pathnameパラメーターなしで）これまでにステージされた内容を記録するために使用されます。これはコマンドの最も基本的な形式です。例：

$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit

Instead of staging files after each individual change, you can tell git commit to notice the changes to the files whose contents are tracked in your working tree and do corresponding git add and git rm for you. That is, this example does the same as the earlier example if there is no other change in your working tree:個々の変更後にファイルをステージングする代わりgit commitに、作業ツリーで内容が追跡されているファイルへの変更に気付くように指示して、対応する操作git addを実行するgit rmこともできます。つまり、作業ツリーに他に変更がない場合、この例は前の例と同じです。

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

The command git commit -a first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary git add and git rm for you.このコマンドはgit commit -a最初にあなたの作業ツリーを見て、あなたがhello.cを修正し、goodbye.cを削除したことに気付き、そして必要に応じてgit addそしてgit rmあなたのために実行します。

After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to git commit. When pathnames are given, the command makes a commit that only records the changes made to the named paths:多くのファイルに対する変更をステージングした後は、パス名を指定することによって、変更が記録される順序を変更できますgit commit。パス名が指定されると、コマンドは名前付きパスに加えられた変更のみを記録するコミットを行います。

$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile

This makes a commit that records the modification to Makefile. The changes staged for hello.c and hello.h are not included in the resulting commit. However, their changes are not lost — they are still staged and merely held back. After the above sequence, if you do:これは変更をに記録するコミットを行いMakefileます。変更がために上演hello.cし、hello.hコミット結果には含まれていません。しかし、それらの変更は失われることはありません - それらはまだ上演され、単に阻止されています。上記のシーケンスの後に、次のようにします。

$ git commit

this second commit would record the changes to hello.c and hello.h as expected.これは、第二の変更計上するコミットhello.cとhello.h予想されるなどし。

After a merge (initiated by git merge or git pull) stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with git status and after fixing them manually in your working tree, you would stage the result as usual with git add:（git mergeまたはgit pullによって開始された）マージが競合のために停止した後、きれいにマージされたパスはすでにあなたのためにコミットされるようにステージングされており、競合したパスはマージされていない状態のままです。最初にどのパスがgitステータスと衝突しているのかをチェックし、それらを作業ツリーで手動で修正した後、git addを使用して通常どおりに結果をステージングします。

$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c

After resolving conflicts and staging the result, git ls-files -u would stop mentioning the conflicted path. When you are done, run git commit to finally record the merge:矛盾を解決して結果をステージングした後git ls-files -uは、矛盾するパスについて言及するのをやめるでしょう。完了したら、git commit最後にマージを記録するために実行します。

$ git commit

As with the case to record your own changes, you can use -a option to save typing. One difference is that during a merge resolution, you cannot use git commit with pathnames to alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command refuses to run when given pathnames (but see -i option).あなた自身の変更を記録する場合と同様に、あなたは-aタイプを節約するためにオプションを使うことができます。1つの違いは、マージがgit commit単一のコミットとして記録される必要があるため、マージの解決中に、変更がコミットされる順序を変更するためにパス名を使用できないことです。実際、コマンドはパス名が与えられると実行を拒否します（ただし-iオプションを参照）。

DISCUSSION討論

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch[1] turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.必須ではありませんが、コミットメッセージを変更を要約した短い（50文字未満）行で開始し、その後に空白行とその後でより詳細な説明を記述することをお勧めします。コミットメッセージの最初の空白行までのテキストはコミットタイトルとして扱われ、そのタイトルはGitを通して使われます。たとえば、git-format-patch [1]はコミットを電子メールに変換し、Subject行のタイトルと本文の残りのコミットを使用します。

Git is to some extent character encoding agnostic.Gitはある程度文字コードを認識しません。

The contents of the blob objects are uninterpreted sequences of bytes. There is no encoding translation at the core level.BLOBオブジェクトの内容は、未解釈の一連のバイトです。コアレベルでのエンコード変換はありません。
Path names are encoded in UTF-8 normalization form C. This applies to tree objects, the index file, ref names, as well as path names in command line arguments, environment variables and config files (.git/config (see git-config[1]), gitignore[5], gitattributes[5] and gitmodules[5]).パス名はUTF-8正規化形式Cでエンコードされています。これはツリーオブジェクト、インデックスファイル、参照名、コマンドライン引数のパス名、環境変数、設定ファイルに適用されます（.git/config（git-config [1]を参照））。、gitignore [5]、gitattributes [5]そしてgitmodules [5]）。

Note that Git at the core level treats path names simply as sequences of non-NUL bytes, there are no path name encoding conversions (except on Mac and Windows). Therefore, using non-ASCII path names will mostly work even on platforms and file systems that use legacy extended ASCII encodings. However, repositories created on such systems will not work properly on UTF-8-based systems (e.g. Linux, Mac, Windows) and vice versa. Additionally, many Git-based tools simply assume path names to be UTF-8 and will fail to display other encodings correctly.コアレベルでのGitはパス名を単にNUL以外のバイトのシーケンスとして扱うので、パス名のエンコード変換はありません（MacとWindowsを除く）。したがって、ASCII以外のパス名を使用することは、従来の拡張ASCIIエンコードを使用するプラットフォームおよびファイルシステムでもほとんどの場合うまくいきます。ただし、そのようなシステムで作成されたリポジトリは、UTF-8ベースのシステム（Linux、Mac、Windowsなど）では正しく機能しません。その逆も同様です。さらに、多くのGitベースのツールはパス名を単にUTF-8と仮定しているため、他のエンコーディングを正しく表示できません。
Commit log messages are typically encoded in UTF-8, but other extended ASCII encodings are also supported. This includes ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).コミットログメッセージは通常UTF-8でエンコードされていますが、他の拡張ASCIIエンコードもサポートされています。これにはISO-8859-x、CP125x、その他多くのものが含まれますが、 UTF-16/32、EBCDICおよびCJKマルチバイトエンコーディング（GBK、Shift-JIS、Big5、EUC-x、CP9xxなど）は含まれません。

Although we encourage that the commit log messages are encoded in UTF-8, both the core and Git Porcelain are designed not to force UTF-8 on projects. If all participants of a particular project find it more convenient to use legacy encodings, Git does not forbid it. However, there are a few things to keep in mind.コミットログメッセージはUTF-8でエンコードすることをお勧めしますが、コアとGit PorcelainはどちらもプロジェクトでUTF-8を強制しないように設計されています。特定のプロジェクトのすべての参加者が従来のエンコーディングを使用するほうが便利だと判断した場合、Gitはそれを禁止しません。ただし、留意すべき点がいくつかあります。

git commit and git commit-tree issues a warning if the commit log message given to it does not look like a valid UTF-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to have i18n.commitencoding in .git/config file, like this:git commitおよびgit commit-treeは、コミットログメッセージが有効なUTF-8文字列のように見えない場合に警告を発行します。ただし、明示的にプロジェクトで従来のエンコーディングを使用しているとは限りません。これを言う方法はこの.git/configようにファイルにi18n.commitencodingを持つことです：
```
[i18n]
	commitEncoding = ISO-8859-1
```
Commit objects created with the above setting record the value of i18n.commitEncoding in its encoding header. This is to help other people who look at them later. Lack of this header implies that the commit log message is encoded in UTF-8.上記の設定で作成されたコミットオブジェクトはi18n.commitEncoding、その値をencodingヘッダーに記録します。これは後で見る人を助けるためです。このヘッダがないということは、コミットログメッセージがUTF-8でエンコードされていることを意味します。
git log, git show, git blame and friends look at the encoding header of a commit object, and try to re-code the log message into UTF-8 unless otherwise specified. You can specify the desired output encoding with i18n.logOutputEncoding in .git/config file, like this:git log、git show、git blame、および友達encodingは、コミットオブジェクトのヘッダを調べ、特に指定がない限り、ログメッセージをUTF-8に書き換えます。このように、i18n.logOutputEncodingin .git/configfileで希望の出力エンコーディングを指定できます。
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
If you do not have this configuration variable, the value of i18n.commitEncoding is used instead.この構成変数がない場合は、i18n.commitEncoding代わりにの値が使用されます。

Note that we deliberately chose not to re-code the commit log message when a commit is made to force UTF-8 at the commit object level, because re-coding to UTF-8 is not necessarily a reversible operation.UTF-8への再コーディングは必ずしも可逆的な操作ではないため、コミットがコミットオブジェクトレベルでUTF-8を強制するために行われたときにコミットログメッセージを再コーディングしないことを意図的に選択したことに注意してください。

ENVIRONMENT AND CONFIGURATION VARIABLES環境と設定変数

The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order). See git-var[1] for details.コミットログメッセージの編集に使用されるエディタは、GIT_EDITOR環境変数、core.editor設定変数、VISUAL環境変数、またはEDITOR環境変数の順に選択されます。詳細はgit-var [1]を見てください。

HOOKSフック

This command can run commit-msg, prepare-commit-msg, pre-commit, post-commit and post-rewrite hooks. See githooks[5] for more information.このコマンドを実行することができcommit-msg、prepare-commit-msg、pre-commit、post-commitおよびpost-rewriteフック。詳細についてはgithooks [5]を参照してください。

FILESファイル

$GIT_DIR/COMMIT_EDITMSG: This file contains the commit message of a commit in progress. If git commit exits due to an error before creating a commit, any commit message that has been provided by the user (e.g., in an editor session) will be available in this file, but will be overwritten by the next invocation of git commit.このファイルには、進行中のコミットのコミットメッセージが含まれています。git commitコミットを作成する前にエラーが発生して終了した場合、ユーザーによって（たとえば、エディタセッションで）提供されたコミットメッセージはすべてこのファイルで使用可能になりますが、次の呼び出しによって上書きされますgit commit。