Git Manual Pages
****************

Name
****

git-add — ファイルの内容をインデックスに追加します

Synopsis
********

     git add [–verbose | -v] [–dry-run | -n] [–force | -f] [–interactive | -i] [–patch | -p]
               [–edit | -e] [–[no-]all | –[no-]ignore-removal | [–update | -u]]
               [–intent-to-add | -N] [–refresh] [–ignore-errors] [–ignore-missing] [–renormalize]
               [–chmod=(+|-)x] [–pathspec-from-file=<file> [–pathspec-file-nul]]
               [–] [<pathspec>…]

DESCRIPTION
***********

このコマンドは、作業ツリーで見つかった現在のコンテンツを使用してインデッ
クスを更新し、次のコミットのためにステージングされたコンテンツを準備しま
す。 通常、既存のパスの現在のコンテンツを全体として追加しますが、一部の
オプションを使用して、作業ツリーファイルに加えられた変更の一部のみを適用
したコンテンツを追加したり、作業ツリーにもう存在しないパスを削除したりす
ることもできます。

   「インデックス」は作業ツリーのコンテンツのスナップショットを保持し、
次のコミットのコンテンツとして取得されるのはこのスナップショットです。 し
たがって、作業ツリーに変更を加えた後、commitコマンドを実行する前に、
‘add’ コマンドを使用して新しいファイルまたは変更されたファイルをインデッ
クスに追加する必要があります。

   このコマンドは、コミット前に複数回実行できます。 addコマンドの実行時
に指定されたファイルのコンテンツのみが追加されます。 その次のコミットに
後続の変更を含める場合は、 ‘git add’ を再度実行して、新しいコンテンツを
インデックスに追加する必要があります。

   ‘git status’ コマンドを使用して、次のコミットのためにステージングされ
る変更が含まれているファイルの概要を取得できます。

   ‘git add’ コマンドは、デフォルトでは無視されたファイル(ignored
files)を追加しません。 無視されたファイル(ignored files)をコマンドライン
で明示的に指定した場合、 ‘git add’ は無視されたファイルのリストにより失
敗します。 Gitによって実行されたディレクトリ再帰またはファイル名グロブ
(シェル展開される前にあなたのグロブをクォートしておく)によって到達した無
視されたファイルは、黙って無視されます。 ‘-f’ (force)オプションとともに
‘git add’ コマンドを使用すると無視されたファイルを追加できます。

   コミットにコンテンツを追加する別の方法については、 git-commit(1) を参
照してください。

OPTIONS
*******

<pathspec>…
     コンテンツを追加するファイル。 ファイルグロブ(例: ‘*.c’)を指定して
     、マッチするすべてのファイルを追加できます。 また、先頭のディレクト
     リ名(たとえば ‘dir’ で ‘dir/file1’ と ‘dir/file2’ を追加)を指定して
     、ディレクトリ全体の現在の状態に一致するようにインデックスを更新す
     ることもできます(たとえば、 ‘dir’ を指定すると、作業ツリーで変更さ
     れたファイル ‘dir/file1’ の変更記録や、作業ツリーに追加されたファイ
     ル ‘dir/file2’ の追加記録だけでなく、作業ツリーから削除されたファイ
     ル ‘dir/file3’ の削除記録も行われます)。 古いバージョンのGitでは、
     削除されたファイルを無視していたことに注意してください。 変更された
     ファイルまたは新しいファイルを追加し、削除されたファイルを無視する
     場合は、 ‘--no-all’ オプションを使用します。

     <pathspec>構文の詳細については、 gitglossary(7) の「pathspec」エン
     トリを参照してください。

‘-n’
‘--dry-run’
     実際にファイルを追加するのではなく、ファイルが存在するかどうか、お
     よび/または 無視されるかどうかを表示します。

‘-v’
‘--verbose’
     おしゃべりにします。

‘-f’
‘--force’
     これ以外の場合は無視されるファイルの追加を許可します。

‘-i’
‘--interactive’
     作業ツリーの変更されたコンテンツを対話的にインデックスに追加します
     。 オプションのパス引数を指定して、操作を作業ツリーのサブセットに制
     限することができます。 詳細については、「Interactive mode」を参照し
     てください。

‘-p’
‘--patch’
     インデックスと作業ツリーの間でパッチの塊(hunk)を対話的に選択し、そ
     れらをインデックスに追加します。 これにより、ユーザーは、変更された
     コンテンツをインデックスに追加する前に、違いを確認することができま
     す。

     これは効果的に ‘add --interactive’ を実行しますが、初期コマンドメニ
     ューをバイパスし、 ‘patch’ サブコマンドに直接ジャンプします。 詳細
     については、「Interactive mode」を参照してください。

‘-e’
‘--edit’
     差分とインデックスをエディタで開き、ユーザに編集させる。 エディタを
     閉じた後、ハンクヘッダ(hunk headers)を調整し、インデックスにパッチ
     を適用する。

     このオプションの目的は、適用するパッチの行を選択すること、またはス
     テージングする行の内容を変更することです。 これは、対話的なハンク選
     択器(interactive hunk selector)を使用するよりも迅速かつ柔軟になりま
     す。 しかしながら、混乱してインデックスに適用されないパッチを作成す
     るのも簡単にできてしまいます。以下の「EDITING PATCHES」を参照してく
     ださい。

‘-u’
‘--update’
     <pathspec>にマッチするエントリがすでにある場所でインデックスを更新
     します。 これにより、作業ツリーにマッチするようにインデックスエント
     リが削除および変更されますが、新しいファイルは追加されません。

     ‘-u’ オプションが使用されているときに<pathspec>が指定されていない場
     合、作業ツリー全体で追跡されているファイル(tracked files)すべてが更
     新されます(Gitの古いバージョンでは、更新を現在のディレクトリとその
     サブディレクトリに制限するために使用されていました)。

‘-A’
‘--all’
‘--no-ignore-removal’
     作業ツリーに<pathspec>にマッチするファイルがある場合だけでなく、イ
     ンデックスにすでにエントリがある場合にも、インデックスを更新します
     。 これにより、作業ツリーにマッチするようにインデックスエントリが 追
     加や変更や削除 されます。

     ‘-A’ オプションが使用されているときに<pathspec>が指定されていない場
     合、作業ツリー全体のすべてのファイルが更新されます(Gitの古いバージ
     ョンでは、現在のディレクトリとそのサブディレクトリに更新を制限する
     ために使用されていました)。

‘--no-all’
‘--ignore-removal’
     インデックスに未知の新しいファイルや、作業ツリーで変更されたファイ
     ルを追加してインデックスを更新するが、作業ツリーから削除されたファ
     イルは無視する。 <pathspec> が使用されていない場合、このオプション
     は何もしません。

     このオプションは主に、 ‘git add <pathspec>...’ が ‘git add --no-all
     <pathspec>...’ つまり、削除されたファイルの無視、の同義語であった、
     古いバージョンのGitに慣れているユーザーを支援するためのものです。

‘-N’
‘--intent-to-add’
     パスが後で追加されるという事実のみを記録します。 パスのエントリは、
     コンテンツなしでインデックスに配置されます。 これは、特に、そのよう
     なファイルのステージングされていないコンテンツを ‘git diff’ で表示
     し、それらを ‘git commit -a’ でコミットする場合に役立ちます。

‘--refresh’
     ファイルを追加しません。 ただし、インデックス内の stat() 情報のみ更
     新します。

‘--ignore-errors’
     一部のファイルのインデックス作成エラーが原因で追加できなかった場合
     は、操作を中止せずに、他のファイルの追加を続行します。 コマンドは、
     ゼロ以外のステータスで終了します。 構成変数 ‘add.ignoreErrors’ を
     trueに設定して、これをデフォルトの動作にすることができます。

‘--ignore-missing’
     このオプションは、 ‘--dry-run’ と一緒にのみ使用できます。 このオプ
     ションを使用することにより、ユーザーは、指定されたファイルがすでに
     作業ツリーに存在するかどうかに関係なく、それらのファイルのどれが無
     視されるかどうかを確認できます。

‘--no-warn-embedded-repo’
     デフォルトでは、 ‘git submodule add’ を使用して ‘.gitmodules’ にエ
     ントリを作成せずに、埋め込みリポジトリ(embedded repository)をインデ
     ックスに追加すると、 ‘git add’ が警告を表示します。 このオプション
     は、警告を抑制します(たとえば、サブモジュールで手動で操作を実行して
     いる場合)。

‘--renormalize’
     全ての追跡されたファイル(tracked files)に「クリーン」(clean)プロセ
     スを新たに適用して、それらをインデックスに強制的に再度追加します。
     これは、誤った CRLF/LF 行末で追加されたファイルを修正するために、
     ‘core.autocrlf’ 構成または ‘text’ 属性を変更した後に役立ちます。 こ
     のオプションは ‘-u’ の指定を含んでいます。

‘--chmod=(+|-)x’
     追加されたファイルの実行可能ビットを上書きします。 実行可能ビットは
     インデックス内でのみ変更され、ディスク上のファイルは変更されません
     。

‘--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’ でのみ意味があります。 pathspec要素はNUL文字
     で区切られ、他のすべての文字は文字通りに解釈されます(改行と引用符を
     含む)。

‘--’
     このオプションは、コマンドラインオプションをファイルのリストから分
     離するために使用できます(ファイル名がコマンドラインオプションと間違
     えられる可能性がある場合に便利です)。

EXAMPLES
********

   • ‘Documentation’ ディレクトリとそのサブディレクトリの下にあるすべて
     の ‘*.txt’ ファイルからコンテンツを追加します:

          $ git add Documentation/\*.txt

     注意: この例では、アスタリスク ‘*’ がシェルからクォートされているこ
     とに注意してください。 これにより、コマンドに ‘Documentation/’ ディ
     レクトリのサブディレクトリからのファイルを含めることができます。

   • すべての git-*.sh スクリプトからコンテンツを追加することを検討しま
     す:

          $ git add git-*.sh

     この例では、シェルがアスタリスクを展開できてしまうため(つまり、ファ
     イルを明示的にリストしているため)、 ‘subdir/git-foo.sh’ は考慮され
     ません。

INTERACTIVE MODE
****************

コマンドが対話モード(interactive mode)に入ると、「status」サブコマンドの
出力が表示され、対話コマンドループに入ります。

   コマンドループは、使用可能なサブコマンドのリストを表示し、 ‘What now>
` というプロンプトを表示します。 一般に、プロンプトが単一の `>’ で終了す
る場合、以下のように、指定された選択肢の1つだけを選択し、returnキーをタ
イプできます:

         *** Commands ***
           1: status       2: update       3: revert       4: add untracked
           5: patch        6: diff         7: quit         8: help
         What now> 1

   選択が一意である限り、上記のは「s」または「sta」または「status」と言
うことができます。

   メインコマンドループには6つのサブコマンドがあります(加えてhelpと
quitがあります)。

status
     これは、HEADとインデックスの間の変更(つまり、 ‘git commit’ とした場
     合にコミットされるもの)、および、各パスのインデックスと作業ツリーフ
     ァイルの間の変更(つまり、 ‘git add’ を使用して、 ‘git commit’ する
     前にさらにステージングできるもの)を示しています。 出力例は以下のよ
     うになります:

                        staged     unstaged path
               1:       binary      nothing foo.png
               2:     +403/-35        +1/-1 git-add--interactive.perl

     foo.pngにはHEADとの違いがあり(ただし、これはバイナリであるため、行
     数を表示できません)、インデックスされたコピーと作業ツリーのバージョ
     ンに違いはありません(作業ツリーのバージョンも異なる場合、 ‘binary’
     が ‘nothing’ の代わりに表示されます)。 もう1つのファイル
     ‘git-add{litdd}Interactive.perl’ では、インデックスにあるものをコミ
     ットすると403行が追加されて35行が削除され、作業ツリーファイルにはさ
     らに変更が加えられます(1回の追加と1回の削除)。

update
     これにより、ステータス情報が表示され、 ‘Update>>’ プロンプトが表示
     されます。 プロンプトが二重の ‘>>’ で終わる場合は、空白またはコンマ
     で連結して複数の選択を行うことができます。 また、範囲指定もできます
     。 例えば、 ‘2-5 7,9’ でリストから 2,3,4,5,7,9 を選択します。 範囲
     内の2番目の数字を省略すると、残りのすべてのパッチが適用されます。 例
     えば、 ‘7-’ はリストから 7,8,9 を選択します。 ‘*’ で全選択できます
     。

     あなたが選択したものは、以下のように ‘*’ で強調表示されます:

                     staged     unstaged path
            1:       binary      nothing foo.png
          * 2:     +403/-35        +1/-1 git-add--interactive.perl

     選択を削除するには、以下のように入力の前に ‘-’ を付けます:

          Update>> -2

     選択後、空行で答えて、インデックス内の選択されたパスの作業ツリーフ
     ァイルの内容をステージングします。

revert
     これは「update」と非常によく似たUIを持ち、選択されたパスのステージ
     ングされた情報はHEADバージョンの情報に戻されます(revert)。 新しいパ
     スを元に戻すと、追跡されなくなります。

add untracked
     これは、「update」および「revert」と非常によく似たUIを備えており、
     追跡されていないパスをインデックスに追加できます。

patch
     これにより、選択に似た ‘status’ から1つのパスを選択できます。 パス
     を選択すると、インデックスと作業ツリーファイルの差分が表示され、各
     ハンクの変更をステージングするかどうかを尋ねられます。 以下のオプシ
     ョンのいずれかを選択してからreturnキーをタイプできます。

          y - stage this hunk
          n - do not stage this hunk
          q - quit; do not stage this hunk or any of the remaining ones
          a - stage this hunk and all later hunks in the file
          d - do not stage this hunk or any of the later hunks in the file
          g - select a hunk to go to
          / - search for a hunk matching the given regex
          j - leave this hunk undecided, see next undecided hunk
          J - leave this hunk undecided, see next hunk
          k - leave this hunk undecided, see previous undecided hunk
          K - leave this hunk undecided, see previous hunk
          s - split the current hunk into smaller hunks
          e - manually edit the current hunk
          ? - print help

     すべてのハンクの運命を決定した後、選択されたハンク達がある場合、イ
     ンデックスは選択されたハンク達によって更新されます。

     構成変数 ‘interactive.singleKey’ を ‘true’ に設定することにより、あ
     なたはここでreturnキーをタイプする必要をなくすことができます。

diff
     これにより、コミットされる内容(つまり、HEAD〜インデックス間)を確認
     できます。

EDITING PATCHES
***************

‘git add -e’ を呼び出すか、対話的ハンク選択器(interactive hunk
selector)で ‘e’ を選択すると、エディタでパッチを開きます。 エディタが終
了すると、結果がインデックスに適用されます。 パッチに任意の変更を加える
ことは自由ですが、一部の変更は混乱を招く結果をもたらす可能性があること、
または適用できないパッチをもたらす可能性があることに注意してください。 操
作を完全に中止する場合(つまり、インデックスに新しいものをステージングし
ない場合)は、パッチのすべての行を削除するだけです。 以下のリストは、パッ
チに見られる一般的なものと、それらに対して意味のある編集操作を示していま
す。

added content
     追加されたコンテンツは、 + で始まる行で表されます。 追加行を削除す
     ることで、追加行のステージングを防ぐことができます。

removed content
     削除されたコンテンツは、 ‘-’ で始まる行で表されます。 ‘-’ を ‘ ‘ (ス
     ペース)に変換することで、ステージングによる削除を防ぐことができます
     。

modified content
     変更されたコンテンツは、 ‘-’ 行(古いコンテンツを削除)とそれに続く +
     行(置換コンテンツを追加)で表されます。 ‘-’ 行を ‘ ‘ に変換し、 + 行
     を削除することで、変更のステージングを防ぐことができます。 ペアの半
     分だけを変更すると、インデックスに紛らわしい変更が加えられる可能性
     があることに注意してください。

   実行できるより複雑な操作もあります。 ただし、パッチはインデックスにの
み適用され、作業ツリーには適用されないため、作業ツリーはインデックスの変
更を「元に戻す」(undo)ように見えることに注意してください。 たとえば、
HEADにも作業ツリーにも存在しないインデックスに新しい行を導入すると、コミ
ットのために新しい行がステージングされますが、その行は作業ツリーで元に戻
されている(revert)ように見えます。

   これらの構成を使用しないようにするか、または、細心の注意を払って使用
してください。

removing untouched content
     インデックスと作業ツリーの間で異なって無いコンテンツが、 ‘ ‘ (スペ
     ース)で始まるコンテキスト行に表示される場合があります。 スペースを
     ‘-’ に変換することで、削除するコンテキスト行としてステージングでき
     ます。 その結果、再度追加してくださいと、その作業ツリーファイルが表
     示されます。

modifying existing content
     (‘ ‘ を ‘-’ に変換することにより、)削除のためにステージングして、新
     しいコンテンツに + 行を追加することにより、コンテキスト行を変更する
     こともできます。 同様に、既存の追加または変更のために + 行を変更で
     きます。 いずれの場合も、新しい変更は作業ツリーに戻されて表示されま
     す。

new content
     パッチに存在しない新しいコンテンツを追加することもできます。 それぞ
     れが + で始まる新しい行を追加するだけです。 追加は、作業ツリーに戻
     されて表示されます。

   パッチが適用できなくなるため、完全に回避する必要のある操作もいくつか
あります:

   • コンテキスト行達(" ")または削除行達("-")の追加

   • コンテキスト行達または削除行達の削除

   • コンテキスト行達または削除行達の内容を変更する

SEE ALSO
********

git-status(1) git-rm(1) git-reset(1) git-mv(1) git-commit(1)
git-update-index(1)

GIT
***

Part of the git(1) suite

Name
****

git-am — メールボックスから一連のパッチを適用します

Synopsis
********

     git am [–signoff] [–keep] [–[no-]keep-cr] [–[no-]utf8]
              [–[no-]3way] [–interactive] [–committer-date-is-author-date]
              [–ignore-date] [–ignore-space-change | –ignore-whitespace]
              [–whitespace=<option>] [-C<n>] [-p<n>] [–directory=<dir>]
              [–exclude=<path>] [–include=<path>] [–reject] [-q | –quiet]
              [–[no-]scissors] [-S[<keyid>]] [–patch-format=<format>]
              [–quoted-cr=<action>]
              [(<mbox> | <Maildir>)…]
     git am (–continue | –skip | –abort | –quit | –show-current-patch[=(diff|raw)])

DESCRIPTION
***********

メールボックス内のメールメッセージを、コミットログメッセージと作者情報と
パッチに分割し、それらを現在のブランチに適用します。

OPTIONS
*******

(<mbox>|<Maildir>)…
     パッチを読み取るメールボックスファイルのリスト。 この引数を指定しな
     い場合、コマンドは標準入力から読み取ります。 ディレクトリを指定する
     と、それらはMaildirとして扱われます。

‘-s’
‘--signoff’
     自分のコミッターIDを使用して、コミットメッセージに ‘Signed-off-by’
     トレーラーを追加します。 詳細については、 git-commit(1) のsignoffオ
     プションを参照してください。

‘-k’
‘--keep’
     ‘-k’ フラグを ‘git mailinfo’ に渡します(git-mailinfo(1) 参照)。

‘--keep-non-patch’
     ‘-b’ フラグを ‘git mailinfo’ に渡します(git-mailinfo(1) 参照)。

‘--[no-]keep-cr’
     ‘--keep-cr’ を使用して、同じオプションで ‘git mailsplit’
     (git-mailsplit(1) 参照)を呼び出し、行末のCRが削除されないようにしま
     す。 ‘am.keepcr’ 構成変数を使用して、デフォルトの動作を指定できます
     。 ‘--no-keep-cr’ は、 ‘am.keepcr’ をオーバーライドするのに役立ちま
     す。

‘-c’
‘--scissors’
     切り取り線行の前にある本体のすべてを削除します(git-mailinfo(1) 参照
     )。 ‘mailinfo.scissors’ 構成変数を使用してデフォルトでアクティブ化
     できます。

‘--no-scissors’
     切り取り線を無視します(git-mailinfo(1) 参照)。

‘--quoted-cr=<action>’
     このフラグは ‘git mailinfo’ に渡されます(git-mailinfo(1) 参照)。

‘-m’
‘--message-id’
     ‘-m’ フラグを ‘git mailinfo’ (git-mailinfo(1) 参照)に渡して、
     Message-IDヘッダーがコミットメッセージに追加されるようにします。
     ‘am.messageid’ 構成変数を使用して、デフォルトの動作を指定できます。

‘--no-message-id’
     コミットメッセージにMessage-IDヘッダーを追加しないでください。
     ‘no-message-id’ は、 ‘am.messageid’ を上書きするのに役立ちます。

‘-q’
‘--quiet’
     静かにします。エラーメッセージのみ出力します。

‘-u’
‘--utf8’
     ‘-u’ フラグを ‘git mailinfo’ に渡します（linkgit：git-mailinfo [1]を
     参照）。 電子メールから取得された、提案されたコミットログメッセージ
     は、UTF-8エンコーディングに再コーディングされます(UTF-8でない場合は
     、構成変数 ‘i18n.commitEncoding’ を使用して、プロジェクトの優先エン
     コーディングを指定できます)。

     これは以前のバージョンのgitではオプションでしたが、現在はデフォルト
     です。 ‘--no-utf8’ を使用してこれをオーバーライドできます。

‘--no-utf8’
     ‘-n’ フラグを ‘git mailinfo’ に渡します(git-mailinfo(1) 参照)。

‘-3’
‘--3way’
‘--no-3way’
     パッチが適切に適用されない場合、パッチが適用されるはずのブロブの
     IDを記録し、それらのブロブがローカルで使用できる場合は、3方向マージ
     にフォールバックします。 ‘--no-3way’ を使用して、 am.threeWay構成変
     数をオーバーライドできます。 詳細については、 git-config(1) の
     am.threeWayを参照してください。

‘--rerere-autoupdate’
‘--no-rerere-autoupdate’
     可能であれば、rerereメカニズムが自動競合解決の結果でインデックスを
     更新できるようにします。

‘--ignore-space-change’
‘--ignore-whitespace’
‘--whitespace=<option>’
‘-C<n>’
‘-p<n>’
‘--directory=<dir>’
‘--exclude=<path>’
‘--include=<path>’
‘--reject’
     これらのフラグは、パッチを適用する ‘git apply’ (git-apply(1) 参照
     )プログラムに渡されます。

‘--patch-format’
     デフォルトでは、コマンドはパッチ形式を自動的に検出しようとします。
     このオプションを使用すると、ユーザーは自動検出をバイパスして、パッ
     チを解釈するパッチ形式を指定できます。 有効な形式は、mbox、mboxrd、
     stgit、stgit-series、hg です。

‘-i’
‘--interactive’
     対話的に実行します。

‘--committer-date-is-author-date’
     デフォルトでは、コマンドは電子メールメッセージの日付をコミット作者
     の日付として記録し、コミットの作成時刻をコミッターの日付として使用
     します。 これにより、ユーザーは作者の日付と同じ値を使用して、コミッ
     ターの日付について嘘をつくことができます。

‘--ignore-date’
     デフォルトでは、コマンドは電子メールメッセージの日付をコミット作者
     の日付として記録し、コミットの作成時刻をコミッターの日付として使用
     します。 これにより、ユーザーはコミッターの日付と同じ値を使用して、
     作者の日付について嘘をつくことができます。

‘--skip’
     現在のパッチをスキップします。 これは、中止(abort)されたパッチを再
     スタートする場合にのみ意味があります。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     GPG署名コミット。 ‘keyid’ 引数はオプションであり、デフォルトでコミ
     ッターIDになります。 指定する場合は、スペースなしでオプションに固定
     する必要があります。 ‘--no-gpg-sign’ は、 ‘commit.gpgSign’ 構成変数
     と以前の ‘--gpg-sign’ の両方を打ち消すのに役立ちます。

‘--continue’
‘-r’
‘--resolved’
     パッチが失敗した後(たとえば、競合するパッチを適用しようとした場合
     )、ユーザーはそれを手動で適用し、インデックスファイルに適用の結果が
     保存されます。 電子メールメッセージと現在のインデックスファイルから
     抽出された作者とコミットログを使用してコミットし、続行します。

‘--resolvemsg=<msg>’
     パッチ障害が発生すると、終了する前に<msg>が画面に出力されます。 こ
     れは、失敗を処理するために ‘--continue’ または ‘--skip’ を使用する
     ように通知する標準メッセージをオーバーライドします。 これは、 ‘git
     rebase’ と ‘git am’ の間の内部使用のみを目的としています。

‘--abort’
     元のブランチを復元(restore)し、パッチ操作を中止(abort)します。 am操
     作に関係するファイルの内容をam前の状態(pre-am state)に戻します
     (revert)。

‘--quit’
     パッチ適用操作を中止しますが、HEADとインデックスはそのままにしてお
     きます。

‘--show-current-patch[=(diff|raw)]’
     競合が原因で ‘git am’ が停止(stop)したメッセージを表示します。
     ‘raw’ が指定されている場合、電子メールメッセージの生の内容を表示し
     ます。 ‘diff’ の場合、diff部分のみを表示します。 デフォルトは ‘raw’
     です。

DISCUSSION
**********

コミット作者名はメッセージの "From: " から取得され、コミット作者日付はメ
ッセージの "Date: " 行から取得されます。 "Subject: " 行は、共通のプレフ
ィックス ‘[PATCH <anything>]’ を削除した後、コミットのタイトルとして使用
されます。 "Subject: " 行は、コミットが何であるかを1行のテキストで簡潔に
説明することになっています。

   "From: " や "Date: " や "Subject: " の行で始まる本文は、ヘッダーから
取得されたそれぞれのコミット作者名とタイトルの値をオーバーライドします。

   コミットメッセージは、 "Subject: " から取得したタイトルと空行とパッチ
が開始されるところまでのメッセージの本文によって形成されます。 各行の終
わりにある余分な空白(whitespace)は自動的に削除されます。

   パッチは、メッセージの直後にインラインであることが期待されます。 以下
の形式の行:

   • 3つのダッシュ(‘---’)と行終端(end-of-line)、または

   • "diff -" で始まる行、または

   • "Index: " で始まる行

   これらはパッチの開始と見なされ、そのような行が最初に出現する前でコミ
ットログメッセージが終了します。

   最初に ‘git am’ を呼び出すときに、処理するメールボックスの名前を指定
します。 適用されない最初のパッチを確認すると、途中で中止(abort)されます
。 これからは、以下の2つの方法のいずれかで回復(recover)できます:

  1. ‘--skip’ オプションを指定してコマンドを再実行し、現在のパッチをスキ
     ップします。

  2. 作業ディレクトリの競合を手動で解決し、インデックスファイルを更新し
     て、パッチが生成するはずの状態にします。その次に、 ‘--continue’ オ
     プションを指定してコマンドを実行します。

   このコマンドは、現在の操作が終了するまで新しいメールボックスの処理を
拒否するため、最初からやり直す場合は、メールボックス名を指定してコマンド
を実行する前に、 ‘git am --abort’ を実行してください。

   パッチが適用される前に、ORIG_HEADは現在のブランチの先端に設定されます
。 これは、間違ったブランチで ‘git am’ を実行したり、メールボックスを変
更することでより簡単に修正できるコミットのエラー("From:" 行のエラーなど
)など、複数のコミットに問題がある場合に役立ちます。

HOOKS
*****

このコマンドは、 applypatch-msgフックとpre-applypatchフックと
post-applypatchフックを実行できます。 詳細については githooks(5) を参照
してください。

SEE ALSO
********

git-apply(1).

GIT
***

Part of the git(1) suite

Name
****

git-annotate — 指定ファイルの各行のコミット情報を表示

Synopsis
********

     git annotate [<options>] <file> [<revision>]

DESCRIPTION
***********

指定されたファイルの各行に、その行を導入したコミットからの情報で注釈を付
けます。オプションで、特定のリビジョンから注釈を付けます。

   このコマンドと git-blame(1) の唯一の違いは、わずかに異なる出力形式を
使用することです。このコマンドは、既存のスクリプトをサポートするための下
位互換性のためにのみ存在し、他のSCMシステムから来た人々により馴染みのあ
るコマンド名を提供します。

OPTIONS
*******

‘-b’
     境界コミットでは空白のSHA-1を表示します。これは、
     ‘blame.blankBoundary’ 構成オプションを介して制御することもできます
     。

‘--root’
     ルートコミットを境界として扱わないでください。 これは、
     ‘blame.showRoot’ 構成オプションを介して制御することもできます。

‘--show-stats’
     blameの出力の最後に追加の統計を含めます。

‘-L <start>,<end>’
‘-L :<funcname>’
     _<start>,<end>_ で指定の行範囲のみ、または正規表現関数名
     _<funcname>_ で指定の行範囲のみに注釈を付けます。複数回指定できます
     。範囲が重複するのは許されます。

     _<start>_ と _<end>_ はオプションです。 ‘-L <start>’ または ‘-L
     <start>,’ は _<start>_ からファイルの終わりまでの範囲です。 ‘-L
     ,<end>’ は、ファイルの先頭から _<end>_ までの範囲です。

     <start> と <end> は、以下のいずれかの形式です:

        • 数値

          <start> または <end> が数値の場合、絶対行番号を指定します(行は
          1から数えます)。

        • ‘/regex/’

          この形式は、指定されたPOSIX正規表現に一致する最初の行を使用し
          ます。 <start> が正規表現の場合、前の ‘-L’ 範囲の末尾から検索
          します。それ以外の場合は、ファイルの先頭から検索します。
          <start> が ‘^/regex/’ の場合、ファイルの先頭から検索します。
          <end> が正規表現の場合、 <start> で指定された行から検索開始し
          ます。

        • +offset or -offset

          これは <end> に対してのみ有効であり、 <start> で指定された行の
          前後の行数を指定します。

     <start> と <end> の代わりに ‘:<funcname>’ が指定されている場合、こ
     れは <funcname> に一致する最初の関数名行から次の関数名行までの範囲
     を示す正規表現です。 ‘:<funcname>’ は、前の ‘-L’ 範囲の末尾から検索
     します。それ以外の場合は、ファイルの先頭から検索します。
     ‘^:<funcname>’ はファイルの先頭から検索します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘-l’
     長いレビジョンを表示します(デフォルト: off)。

‘-t’
     生のタイムスタンプを表示します(デフフォルト: off)。

‘-S <revs-file>’
     git-rev-list(1) を呼び出す代わりに、revs-fileのリビジョンを使用しま
     す。

‘--reverse <rev>..<rev>’
     履歴を後方へではなく前方へウォークします。行があらわれたされたリビ
     ジョンを表示する代わりに、行が存在した最後のリビジョンを表示します
     。これには、START..END のように、STARTにblameのパスが存在するレビジ
     ョン範囲が必要です。 便宜上、 ‘git blame --reverse START’ は ‘git
     blame --reverse START..HEAD’ と見なされます。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを追跡します。 この
     オプションは、履歴全体にいつ導入されたかではなく、特定の統合ブラン
     チにいつ導入されたかを判別するために使用できます。

‘-p’
‘--porcelain’
     ソフトウェア等で使用するのに適した形式で表示します。

‘--line-porcelain’
     磁器形式で表示しますが、コミットが最初に参照されたときだけでなく、
     各行のコミット情報を出力します。 –porcelain の機能を含んでいます。

‘--incremental’
     ソフトウェア等で使用するのに適した形式で結果を段階的
     (incrementally)に表示します。

‘--encoding=<encoding>’
     作者名(author names)の出力と要約のコミットに使用されるエンコーディ
     ングを指定します。 これを ‘none’ に設定すると、blame出力は変換され
     ていないデータになります。詳細については、 git-log(1) のマニュアル
     ページにある discussion の encoding に関する説明を参照してください
     。

‘--contents <file>’
     <rev> が指定されていない場合、コマンドは作業ツリーのコピーから逆方
     向に開始して変更に注釈を付けます。このフラグにより、コマンドは、作
     業ツリーのコピーに、指定されたファイルの内容が含まれているように見
     せかけます(コマンドを標準入力から読み取るには、 ‘-’ を指定します)。

‘--date <format>’
     日付の出力に使用される形式を指定します。 –date が指定されていない場
     合、blame.date 構成変数の値が使用されます。 blame.date 構成変数も設
     定されていない場合は、 iso形式が使用されます。サポートされている値
     については、 git-log(1) の –date オプションの説明を参照してください
     。

‘--[no-]progress’
     進行状況は、端末に接続されている場合、デフォルトで標準エラーストリ
     ームに報告されます。このフラグは、端末に接続されていない場合でも進
     行状況のレポートを有効にします。 ‘--progress’ を ‘--porcelain’ また
     は ‘--incremental’ と一緒に使用することはできません。

‘-M[<num>]’
     ファイル内の移動またはコピーされた行を検出します。コミットが行のブ
     ロックを移動またはコピーすると(たとえば、元のファイルにA、次にBがあ
     り、コミットによってB、次にAに変更される)、従来の「blame」アルゴリ
     ズムは移動の半分だけに気づき、通常は行をblameします それは親に上に
     移動され(つまりB)、子のコミットに下に移動された(つまりA)行にblameを
     割り当てます。このオプションを使用すると、追加の検査パスを実行する
     ことにより、両方のグループの行が親のせいになります。

     <num> はオプションですが、Gitがそれらの行を親コミットに関連付けるた
     めにファイル内で移動/コピーとして検出する必要がある英数字の数
     (number of alphanumeric characters)の下限です。デフォルト値は20です
     。

‘-C[<num>]’
     ‘-M’ に加えて、同じコミットで変更された他のファイルから移動またはコ
     ピーされた行を検出します。これは、プログラムを再編成し、ファイル間
     でコードを移動するときに役立ちます。このオプションを2回指定すると、
     コマンドは、ファイルを作成するコミットで他のファイルからのコピーを
     追加で検索します。このオプションを3回指定すると、コマンドはコミット
     で他のファイルからのコピーを追加で検索します。

     <num> はオプションですが、Gitがそれらの行を親コミットに関連付けるた
     めにファイル間の移動/コピーとして検出する必要がある英数字の数
     (number of alphanumeric characters)の下限です。また、デフォルト値は
     40です。複数の ‘-C’ オプションが指定されている場合、最後の ‘-C’ の
     <num> 引数が有効になります。

‘--ignore-rev <rev>’
     変更が発生しなかったかのように、blameを割り当てるときにリビジョンに
     よって行われた変更を無視します。無視されたコミットによって変更また
     は追加された行は、その行または近くの行を変更した前のコミットのせい
     になります。このオプションは、複数のリビジョンを無視するために複数
     回指定できます。 ‘blame.markIgnoredLines’ 構成オプションが設定され
     ている場合、無視されたコミットによって変更され、別のコミットに起因
     する行は、blame出力で ‘?’ でマークされます。
     ‘blame.markUnblamableLines’ 構成オプションが設定されている場合、別
     のリビジョンに帰することができなかった無視されたコミットによって触
     れられた行は、 _*_ でマークされます。

‘--ignore-revs-file <file>’
     ‘file’ にリストされているリビジョンを無視します。これは
     ‘fsck.skipList’ と同じ形式である必要があります。このオプションは繰
     り返すことができ、これらのファイルは、 ‘blame.ignoreRevsFile’ 構成
     オプションで指定されたファイルの後に処理されます。空のファイル名
     ‘""’ は、以前に処理されたファイルからrevsのリストをクリアします。

‘-h’
     ヘルプメッセージを表示する。

SEE ALSO
********

git-blame(1)

GIT
***

Part of the git(1) suite

Name
****

git-apply — パッチをファイルやインデックスに適用します

Synopsis
********

     git apply [–stat] [–numstat] [–summary] [–check] [–index | –intent-to-add] [–3way]
               [–apply] [–no-add] [–build-fake-ancestor=<file>] [-R | –reverse]
               [–allow-binary-replacement | –binary] [–reject] [-z]
               [-p<n>] [-C<n>] [–inaccurate-eof] [–recount] [–cached]
               [–ignore-space-change | –ignore-whitespace]
               [–whitespace=(nowarn|warn|fix|error|error-all)]
               [–exclude=<path>] [–include=<path>] [–directory=<root>]
               [–verbose] [–unsafe-paths] [<patch>…]

DESCRIPTION
***********

提供されたdiff出力(つまり「パッチ」)を読み取り、ファイルに適用します。 リ
ポジトリ内のサブディレクトリから実行する場合、ディレクトリ外のパスへのパ
ッチは無視されます。 ‘--index’ オプションを使用すると、パッチはインデッ
クスにも適用され、 ‘--cached’ オプションを使用すると、パッチはインデック
スにのみ適用されます。 これらのオプションがない場合、コマンドはパッチを
ファイルにのみ適用し、Gitリポジトリにいる必要はありません。

   このコマンドはパッチを適用しますが、コミットは作成しません。
git-format-patch(1) によって生成されたパッチや、電子メールで受信されたパ
ッチから、 git-am(1) を使用してコミットを作成します。

OPTIONS
*******

<patch>…
     パッチを読み取るファイル。 ‘-’ は、標準入力から読み取るために使用で
     きます。

‘--stat’
     パッチを適用する代わりに、入力に対してdiffstatを出力します。
     ※applyはオフです(適用操作しません)。

‘--numstat’
     ‘--stat’ に似ていますが、機械読み取り用に、追加および削除された行数
     を10進表記で表示し、パス名を省略形で表示します。 バイナリファイルの
     場合、 ‘0 0’ と言う代わりに2つの ‘-’ を出力します。 ※applyはオフで
     す(適用操作しません)。

‘--summary’
     パッチを適用する代わりに、ファイル作成、名前変更、モード変更など、
     git diff 拡張ヘッダーから取得した情報の要約を出力します。 ※applyは
     オフです(適用操作しません)。

‘--check’
     パッチを適用する代わりに、パッチが現在の作業ツリーやインデックスフ
     ァイルに適用可能かどうかを確認し、エラーを検出します。 ※applyはオフ
     です(適用操作しません)。

‘--index’
     パッチをインデックスと作業ツリーの両方に適用します(または、
     ‘--check’ が有効になっている場合は、両方に正しく適用されることをチ
     ェックします)。 注意: ‘--index’ はインデックスエントリと関連するパ
     スの作業木のコピーが同じであることを期待し(それらの内容とファイルモ
     ードなどのメタデータは一致する必要があります)、そうでない場合には、
     たとえパッチがインデックスと作業ツリーのそれぞれに単独できれいに適
     用されるとしても、エラーを発生させることに注意してください。

‘--cached’
     作業ツリーに触れることなく、インデックスのみにパッチを適用します。
     ‘--check’ が有効になっている場合は、インデックスエントリに正しく適
     用されることをチェックするだけです。

‘--intent-to-add’
     パッチを作業ツリーだけに適用する場合は、新規ファイルをマークして後
     でインデックスに追加します(git-add(1) の ‘--intent-to-add’ オプショ
     ンを参照してください)。このオプションは、Git リポジトリ内で実行して
     いて ‘--index’ が指定されていない場合、無視されます。 なお、
     ‘--index’ は ‘--cached’ や ‘--3way’ などの他のオプションによって暗
     示される可能性があります。

‘-3’
‘--3way’
     パッチが適用する予定のブロブのIDを記録していて、それらのブロブがロ
     ーカルで利用可能である場合、3方向マージを試みます。作業ツリーのファ
     イルに競合マーカーを残して、ユーザーが解決できるようにするかもしれ
     ません。 このオプションは、 ‘--cached’ オプションが使用されていない
     限り、 ‘--index’ オプションを意味し、 ‘--reject’ オプションと互換性
     がありません。 また、 ‘--reject’ オプションと互換性がありません。
     ‘--cached’ オプションと一緒に使用すると、競合があってもキャッシュの
     上位に残されます。

‘--build-fake-ancestor=<file>’
     新しい ‘git diff’ 出力には、パッチが適用される元のバージョンを識別
     するのに役立つ各ブロブの「インデックス情報」が埋め込まれています。
     このオプションが指定され、元のバージョンのブロブがローカルで使用可
     能な場合は、それらのブロブを含む一時的なインデックスを作成します。

     純粋なモード変更(インデックス情報を持たない)に遭遇した場合、代わり
     に現在のインデックスから情報が読み取られます。

‘-R’
‘--reverse’
     パッチを逆に適用します。

‘--reject’
     アトミックな場合、 ‘git apply’ はデフォルトでパッチ全体に失敗し、一
     部のハンクが適用されない場合は作業ツリーにアクセスしません。 このオ
     プションを使用すると、パッチの該当する部分が適用され、拒否されたハ
     ンクが対応する ‘*.rej’ ファイルに残されます。

‘-z’
     ‘--numstat’ が指定されている場合、パス名を変更せずに、NULで終了する
     機械可読形式を使用します。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、「異常な」文字を含むパス名がクォートされます(git-config(1)
     参照)。

‘-p<n>’
     <n>個の先頭のパスコンポーネント(スラッシュで区切られている)を従来の
     diffパスから削除します。 たとえば、 ‘-p2’ を使用すると、
     ‘a/dir/file’ に対するパッチが ‘file’ に直接適用されます。 デフォル
     トは1です。

‘-C<n>’
     各変更の前後で、周囲のコンテキストの少なくとも<n>行が一致することを
     確認してください。 周囲のコンテキストの行が少ない場合、それらはすべ
     て一致する必要があります。 デフォルトでは、コンテキストが無視される
     ことはありません。

‘--unidiff-zero’
     デフォルトでは、 ‘git apply’ は、適用されるパッチが少なくとも1行の
     コンテキストを持つ統一された差分(unified diff)であることを想定して
     います。 これは優れた安全索を提供しますが、 ‘--unified=0’ で生成さ
     れたdiffを適用すると機能しなくなります。 これらのチェックをバイパス
     するには、 ‘--unidiff-zero’ を使用します。

     注意: 上記の理由により、文脈自由パッチ(context-free patches)の使用
     は推奨されないことに注意してください。

‘--apply’
     上記の「※applyはオフです(適用操作しません)」と記されたされたオプシ
     ョンのいずれかを使用すると、 ‘git apply’ は、実際にパッチを適用せず
     に、要求された情報を読み取って出力します。 これらのフラグの後にこの
     フラグを付けると、パッチも適用します。

‘--no-add’
     パッチを適用するときは、パッチによる追加を無視してください。 これを
     使用して、最初に ‘diff’ を実行し、このオプションを使用して結果を適
     用することにより、2つのファイル間の共通部分を抽出できます。これによ
     り、削除部分は適用されますが、追加部分は適用されません。

‘--allow-binary-replacement’
‘--binary’
     Gitの歴史上、ユーザーからの明示的な許可なしにバイナリパッチを適用す
     ることは許可されていませんでした。このフラグは、そのための方法でし
     た。 現在、バイナリパッチの適用は常に許可されているため、これは何の
     操作も行いません(no-op)。

‘--exclude=<path-pattern>’
     与えられたパスパターンに一致するファイルに変更を適用しないでくださ
     い。 これは、特定のファイルまたはディレクトリを除外するパッチセット
     をインポートするときに役立ちます。

‘--include=<path-pattern>’
     与えられたパスパターンに一致するファイルに変更を適用します。 これは
     、特定のファイルまたはディレクトリを含めるパッチセットをインポート
     するときに役立ちます。

     ‘--exclude’ および ‘--include’ パターンが使用される場合、それらはコ
     マンドラインに表示される順序で検査され、最初の一致によって各パスへ
     のパッチが使用されるかどうかが決定されます。 どの include/exclude パ
     ターンにも一致しないパスへのパッチは、コマンドラインに include パタ
     ーンがない場合は既定で使用され、includeパターンがある場合は無視され
     ます。

‘--ignore-space-change’
‘--ignore-whitespace’
     パッチを適用するときは、必要に応じてコンテキスト行の空白
     (whitespace)の変更を無視してください。 コンテキスト行は空白を保持し
     、‘--whitespace’ オプションの値に関係なく空白が修正されることはあり
     ません。 ただし、追加行はこのオプションに関わらず引き続き修正されま
     す。

‘--whitespace=<action>’
     パッチを適用するときは、空白エラー(whitespace errors)のある新しい行
     または変更された行を検出してください。 何を空白エラーと見なすのかは
     、 ‘core.whitespace’ 構成で制御します。 デフォルトでは、末尾の空白
     (空白のみで構成される行を含む)と、行の最初のインデント内で直後にタ
     ブ文字が続くスペース文字は、空白エラーと見なされます。

     デフォルトでは、コマンドは警告メッセージを出力しますが、パッチを適
     用します。 ‘git-apply’ が統計に使用され、パッチを適用しない場合、デ
     フォルトで ‘nowarn’ になります。

     さまざまな ‘<action>’ 値を使用して、この振る舞いを制御できます:

        • ‘nowarn’ は、末尾の空白の警告をオフにします。

        • ‘warn’ は、そのようないくつかのエラーに対する警告を出力します
          が、パッチはそのまま適用します(デフォルト)。

        • ‘fix’ は、そのようないくつかのエラーに対する警告を出力し、それ
          らを修正した後にパッチを適用します(‘strip’ は同義語です — 末尾
          の空白文字のみをエラーと見なすために使用されるツールであり、
          fixにはstripが含まれますが、現在のGitはもっと多くのことをしま
          す)。

        • ‘error’ は、そのようないくつかのエラーに対する警告を出力し、パ
          ッチの適用を拒否します。

        • ‘error-all’ は ‘error’ に似ていますが、すべてのエラーを表示し
          ます。

‘--inaccurate-eof’
     特定の状況下では、 ‘diff’ の一部のバージョンは、ファイルの最後で欠
     落している改行を正しく検出しません。 その結果、そのような ‘diff’ プ
     ログラムによって作成されたパッチは、不完全な行を正しく記録しません
     。 このオプションは、このバグを回避することにより、そのようなパッチ
     を適用するためのサポートを追加します。

‘-v’
‘--verbose’
     進捗状況をstderrに報告します。 デフォルトでは、現在適用されているパ
     ッチに関するメッセージのみが出力されます。 このオプションを使用する
     と、追加情報が報告されます。

‘--recount’
     ハンクヘッダーの行数を信頼せず、パッチを調べて推測してください。 (た
     とえば、ハンクヘッダーを適切に調整せずにパッチを編集した後。)

‘--directory=<root>’
     すべてのファイル名の前に <root> を付けます。 ‘-p’ 引数も渡された場
     合、 新しい <root> を前に付ける前に適用されます。

     たとえば、 ‘a/git-gui.sh’ を ‘b/git-gui.sh’ に更新することについて
     説明しているパッチを作業ツリー ‘modules/git-gui/git-gui.sh のファイ
     ルに適用できます。 `git apply --directory=modules/git-gui’ を実行し
     ます。

‘--unsafe-paths’
     デフォルトでは、作業領域(Git制御の作業ツリー、または ‘git apply’ が
     GNUパッチの代わりに使用される場合の現在の作業ディレクトリ)の外側に
     影響を与えるパッチは、間違い(またはいたずら)として拒否されます。

     ‘git apply’ が「より良いGNUパッチ」として使用される場合、ユーザーは
     ‘--unsafe-paths’ オプションを渡してこの安全性チェックをオーバーライ
     ドできます。 ‘--index’ または ‘--cached’ が使用されている場合、この
     オプションは効果がありません。

CONFIGURATION
*************

apply.ignoreWhitespace
     空白(whitespace)の変更をデフォルトで無視する場合は、 ‘change’ に設
     定します。 空白の変更を重要なものにする場合は、no、none、never、
     false のいずれかに設定します。

apply.whitespace
     コマンドラインから ‘--whitespace’ フラグが指定されていない場合、こ
     の構成アイテムがデフォルトとして使用されます。

SUBMODULES
**********

パッチにサブモジュールへの変更が含まれている場合、 ‘git apply’ はこれら
の変更を以下のように扱います。

   ‘--index’ が(明示的または暗黙的に)指定されている場合、パッチを適用す
るには、サブモジュールのコミットがインデックスと正確に一致する必要があり
ます。 サブモジュールのいずれかがチェックアウトされている場合、これらの
チェックアウトは完全に無視されます。つまり、サブモジュールは最新またはク
リーンである必要はなく、更新されません。

   ‘--index’ が指定されていない場合、パッチ内のサブモジュールのコミット
は無視され、対応するサブディレクトリの有無のみがチェックされ、(可能であ
れば)更新されます。

SEE ALSO
********

git-am(1).

GIT
***

Part of the git(1) suite

Name
****

git-archimport — GNU Arch リポジトリをGitにインポートします

Synopsis
********

     git archimport [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
                    <archive/branch>[:<git-branch>] …

DESCRIPTION
***********

1つ以上の GNU Arch リポジトリからプロジェクトをインポートします。これは
、提供された <archive/branch> パラメーターによって定義された名前空間内の
ブランチとリポジトリに従います。リモートブランチが見つからない場合は、マ
ージ元から通常のコミットとしてインポートされます。見つかった場合は、可能
な限りマージとしてマークします(以下の説明を参照)。

   スクリプトは、 _initial import_ または _tag_ 型のArchコミットからイン
ポートを開始できるキールート(key root)を提供することを想定しています。提
供されたルート(root)内の新しいブランチを追跡してインポートします。

   1つのプロジェクトのみを扱うことを想定しています。ルート(root)が異なる
ブランチを検出した場合、実行を拒否します。その場合は、 <archive/branch>
パラメータを編集して、インポートの範囲を明確に定義します。

   _git archimport_ は、バックグラウンドで ‘tla’ を広範囲に使用して、
Archリポジトリにアクセスします。パス上に利用可能な ‘tla’ の最新バージョ
ンがあることを確認してください。 ‘tla’ は、 _git archimport_ に渡すリポ
ジトリについて知っている必要があります。

   最初のインポートでは、 _git archimport_ は空のディレクトリに自分自身
を見つけることをf期待しています。 Archを使用するプロジェクトの開発を追跡
するには、最初のインポートと同じパラメーターを使用して「git archimport」
を再実行し、増分インポートを実行します。

   _git archimport_ は、インポートするアーカイブに適切なブランチ名を作成
しようとしますが、Gitブランチ名を手動で指定することもできます。これを行
うには、各 <archive/branch> パラメーターの後にコロン(‘:’)で区切ってGitブ
ランチ名を記述します。このようにして、Archブランチ名を短縮し、Arch専門用
語をGit専門用語に変換できます。たとえば、「PROJECT–devo–VERSION」ブラン
チを「master」にマッピングします。

   複数のArchブランチを1つのGitブランチに関連付けることができます。 結果
は、2番目のブランチが作成された後、最初のブランチに対してコミットが行わ
れない場合にのみ最も意味があります。それでも、これは定期的にローテーショ
ンされたArchリポジトリを変換するのに役立ちます。

MERGES
******

Archからのパッチマージデータは、Gitでのマージをマークするためにも使用さ
れます。 Gitはパッチの追跡についてはあまり気にせず、分岐した時点以降、ブ
ランチにすべてのコミットが組み込まれている場合にのみマージを考慮します。
最終的な結果として、Gitはブランチがどこまで分岐したかを把握できます。し
たがって、インポートプロセスでは、パッチ取引のメタデータが失われます。

   幸い、Archからインポートされたブランチをマージしようとすると、Gitは適
切なマージベースを見つけ、ブランチ間で順番どおりにトレードされていないパ
ッチを特定できる可能性が高くなります。

OPTIONS
*******

‘-h’
     使い方表示。

‘-v’
     詳細な出力。

‘-T’
     多くのタグ。Archリポジトリのコミット名を反映して、すべてのコミット
     にタグを作成します。

‘-f’
     高速パッチセットインポート戦略(fast patchset import strategy)を使用
     します。これは、大きなツリーでは大幅に高速化できますが、ディレクト
     リの名前変更やアクセス許可の変更を処理できません。デフォルトの戦略
     は遅いけど安全(slow and safe)です。

‘-o’
     これは、以前のバージョンの「git archimport」で使用されていた古いス
     タイルのブランチ名との互換性のために使用します。古いスタイルのブラ
     ンチ名は category–branch でしたが、新しいスタイルのブランチ名は
     category–branch–version です。 どちらの場合も、コマンドラインで指定
     された名前が自動生成された名前を上書きします。

‘-D <depth>’
     マージの祖先に従い、マージされたツリーのインポートを試みます。パッ
     チログが剪定されている場合は、1より大きい深さを指定します。

‘-a’
     ‘http://mirrors.sourcecontrol.net’ でアーカイブを自動登録してみてく
     ださい。これは、 ‘-D’ オプションを使用すると特に便利です。

‘-t <tmpdir>’
     デフォルトのtempdirをオーバーライドします。

<archive/branch>
     ‘tla log’ が理解できる形式の archive/branch ID。

GIT
***

Part of the git(1) suite

Name
****

git-archive — 名前付きツリーからファイルのアーカイブを作成します

Synopsis
********

     git archive [–format=<fmt>] [–list] [–prefix=<prefix>/] [<extra>]
                   [-o <file> | –output=<file>] [–worktree-attributes]
                   [–remote=<repo> [–exec=<git-upload-archive>]] <tree-ish>
                   [<path>…]

DESCRIPTION
***********

名前付きツリーのツリー構造を含む指定された形式のアーカイブを作成し、それ
を標準出力に書き込みます。 <prefix> が指定されている場合、アーカイブ内の
ファイル名の前に追加されます。

   「git archive」は、ツリーIDを指定した場合と、コミットIDまたはタグIDを
指定した場合の動作が異なります。ツリーIDを指定した場合は、現在の時刻がア
ーカイブ内の各ファイルの変更時刻として使用されます。コミットIDまたはタグ
IDを指定した場合、参照されたコミットオブジェクトに記録されたコミット時間
が代わりに使用されます。さらに、tar形式が使用されている場合、コミット
IDはグローバル拡張paxヘッダー(global extended pax header)に格納されます
。 ‘git get-tar-commit-id’ を使用して抽出できます。ZIPファイルでは、ファ
イルコメントとして保存されます。

OPTIONS
*******

‘--format=<fmt>’
     結果のアーカイブの形式を指定します。「tar」または「zip」です。 この
     オプションが指定されておらず、出力ファイルが指定されている場合、可
     能であればファイル名から形式が推測されます(たとえば、「foo.zip」に
     書き込むと、出力はzip形式になります)。それ以外の場合、出力形式は
     ‘tar’ です。

‘-l’
‘--list’
     有効なすべての形式を表示します。

‘-v’
‘--verbose’
     進捗状況をstderrに報告します。

‘--prefix=<prefix>/’
     アーカイブ内の各ファイル名の前に <prefix>/ を付けます。

‘-o <file>’
‘--output=<file>’
     アーカイブをstdoutではなく<file>に書き込みます。

‘--add-file=<file>’
     追跡されていないファイルをアーカイブに追加します。繰り返すことで複
     数のファイルを追加する事ができます。アーカイブ内のファイルのパスは
     、 ‘--prefix’ の値(存在する場合) と<file>のベース名を連結することに
     よって作成されます。

‘--worktree-attributes’
     作業ツリーの .gitattributes ファイルでも属性を探します( see
     ATTRIBUTES 参照)。

<extra>
     これは、アーカイババックエンドが理解できる任意のオプションです。次
     のセクションを参照してください。

‘--remote=<repo>’
     ローカルリポジトリからtarアーカイブを作成する代わりに、リモートリポ
     ジトリからtarアーカイブを取得します。リモートリポジトリは、
     ‘<tree-ish>’ で許可されるsha1式に制限を課す場合があることに注意して
     ください。詳細については、 git-upload-archive(1) を参照してください
     。

‘--exec=<git-upload-archive>’
     ‘--remote’ とともに使用して、リモート側の「git-upload-archive」への
     パスを指定します。

<tree-ish>
     アーカイブを作成するためのツリーまたはコミット。

<path>
     オプションのパスパラメータがない場合、現在の作業ディレクトリのすべ
     てのファイルとサブディレクトリがアーカイブに含まれます。1つ以上のパ
     スが指定されている場合、それらのみが含まれます。

BACKEND EXTRA OPTIONS
*********************

zip
===

‘-0’
     ファイルを圧縮せずに保存します。

‘-9’
     最も高圧縮かつ最も遅い圧縮レベル。あなたは1〜9までの任意の整数を指
     定して、圧縮速度と比率を調整できます。

CONFIGURATION
*************

tar.umask
     この変数は、tarアーカイブエントリの許可ビットを制限するために使用で
     きます。 デフォルトは 0002 で、ワールド書き込みビットをオフにします
     。特別な値「user」は、代わりにアーカイブユーザーのumaskが使用される
     ことを示します。詳細については、 umask(2) を参照してください。
     ‘--remote’ が使用されている場合、リモートリポジトリの設定のみが有効
     になります。

tar.<format>.command
     この変数は、 ‘git archive’ によって生成されたtar出力をパイプするシ
     ェルコマンドを指定します。コマンドは、標準入力から生成されたtarファ
     イル取り込み、シェルを使用して実行され、標準出力に最終出力を生成す
     る必要があります。圧縮レベルのオプションはすべてコマンドに渡されま
     す(例: ‘-9’ )。他の形式が指定されていない場合、出力ファイルの拡張子
     が ‘<format>’ と同じ場合にこの形式を使用します。

     「tar.gz」および「tgz」形式は自動的に定義され、デフォルトで「gzip
     -cn」になります。 カスタムコマンドでそれらを上書きすることができま
     す。

tar.<format>.remote
     trueの場合、 git-upload-archive(1) を介してリモートクライアントで使
     用できるように ‘<format>’ を有効にします。 ユーザー定義形式の場合、
     デフォルトはfalseですが、「tar.gz」および「tgz」形式の場合はtrueで
     す。

ATTRIBUTES
**********

export-ignore
     属性export-ignoreを持つファイルとディレクトリは、アーカイブファイル
     に追加されません。 詳細については、 gitattributes(5) を参照してくだ
     さい。

export-subst
     属性export-substがファイルに設定されている場合、Gitはこのファイルを
     アーカイブに追加するときにいくつかのプレースホルダーを展開します。
     詳細については、 gitattributes(5) を参照してください。

   注意: デフォルトでは、属性はアーカイブされているツリーの
‘.gitattributes’ ファイルから取得されることに注意してください。事後に出
力が生成される方法を微調整したい場合(たとえば、 ‘.gitattributes’ に適切
な export-ignore を追加せずにコミットした場合)、必要に応じてチェックアウ
トされた ‘.gitattributes’ ファイルを調整して ‘--worktree-attributes’ オ
プションを使用します。 または、 ‘$GIT_DIR/info/attributes’ ファイルに、
ツリーをアーカイブするときに適用する必要のある属性を保持することもできま
す。

EXAMPLES
********

‘git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)’
     現在のブランチの最新のコミットの内容を含むtarアーカイブを作成し、そ
     れを ‘/var/tmp/junk’ ディレクトリに抽出します。

‘git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz’
     これは、 v1.4.0リリース用の圧縮tarballを作成します。

‘git archive --format=tar.gz --prefix=git-1.4.0/ v1.4.0 >git-1.4.0.tar.gz’
     これは、上記と同じですが、組み込みのtar.gz処理を使用します。

‘git archive --prefix=git-1.4.0/ -o git-1.4.0.tar.gz v1.4.0’
     これは上記と同じですが、形式は出力ファイル名から推測されます。

‘git archive --format=tar --prefix=git-1.4.0/ v1.4.0^{tree} | gzip >git-1.4.0.tar.gz’
     v1.4.0リリース用の圧縮tarballを作成しますが、グローバル拡張paxヘッ
     ダー(global extended pax header)はありません。

‘git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs.zip’
     現在のヘッド のDocumentation/ ディレクトリにあるすべてのものを「
     git-1.4.0-docs.zip」にプレフィックス「git-docs/」を付けて配置します
     。

‘git archive -o latest.zip HEAD’
     現在のブランチの最新のコミットの内容を含むZipアーカイブを作成します
     。出力形式は、出力ファイルの拡張子によって推測されることに注意して
     ください。

‘git config tar.tar.xz.command "xz -c"’
     LZMA圧縮tarファイルを作成するための「tar.xz」形式を構成します。
     ‘--format=tar.xz’ を指定するか、 ‘-o foo.tar.xz’ のような出力ファイ
     ルを作成することで使用できます。

SEE ALSO
********

gitattributes(5)

GIT
***

Part of the git(1) suite

Name
****

git-bisect — 二分木検索を使用して、バグを引き起こしたコミットを見つけま
す

Synopsis
********

     git bisect <subcommand> <options>

DESCRIPTION
***********

このコマンドは、さまざまなサブコマンドと、サブコマンドに応じて異なるオプ
ションを取ります:

     git bisect start [--term-{new,bad}=<term> --term-{old,good}=<term>]
                      [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
     git bisect (bad|new|<term-new>) [<rev>]
     git bisect (good|old|<term-old>) [<rev>...]
     git bisect terms [--term-good | --term-bad]
     git bisect skip [(<rev>|<range>)...]
     git bisect reset [<commit>]
     git bisect (visualize|view)
     git bisect replay <logfile>
     git bisect log
     git bisect run <cmd>...
     git bisect help

   このコマンドは、二分木検索アルゴリズムを使用して、プロジェクトの履歴
のどのコミットでバグが発生したかを検出します。 最初に、バグが含まれてい
ることがわかっている「bad」コミットと、バグが発生する前にあることがわか
っている「good」コミットを伝えることで使用します。 次に、 ‘git bisect’ は
、これら2つのエンドポイントの中間のコミットを選択し、選択したコミットが
「good」か「bad」かを尋ねます。 変更を導入した正確なコミットが見つかるま
で、範囲を絞り込み続けます。

   実際、 ‘git bisect’ を使用して、プロジェクトの *任意の* プロパティを
変更したコミットを見つけることができます。 例：バグを修正したコミット、
またはベンチマークのパフォーマンスを向上させたコミット。 このより一般的
な使用法をサポートするために、「good」と「bad」の代わりに「old」と「
new」という用語(terms)を使用することも、独自の用語(terms)を選択すること
もできます。 詳細については、以下の「Alternate terms」(代替用語)のセクシ
ョンを参照してください。

Basic bisect commands: start, bad, good
=======================================

例として、プロジェクトのバージョン ‘v2.6.13-rc2’ では動作することがわか
っている機能を壊したコミットを見つけようとしているとします。以下のように
bisectセッションを開始します:

     $ git bisect start
     $ git bisect bad                 # Current version is bad
     $ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good

   少なくとも1つのbadコミットと1つのgoodコミットを指定すると、 ‘git
bisect’ はその範囲の履歴の真ん中でコミットを選択し、それをチェックアウト
して、以下のようなものを出力します(訳注:テスト対象残り675リビジョン(ざっ
くり10ステップ)):

     Bisecting: 675 revisions left to test after this (roughly 10 steps)

   あなたはチェックアウトしたバージョンをコンパイルしてテストする必要が
あります。 もし、そのバージョンが正しく機能する場合は、次のように入力し
ます

     $ git bisect good

   もし、そのバージョンが壊れている場合は、以下のように入力します

     $ git bisect bad

   そうすると、 ‘git bisect’ は以下のように応答します

     Bisecting: 337 revisions left to test after this (roughly 9 steps)

   このプロセスを繰り返します: ツリーをコンパイルしてテストし、それが
goodかbadかに応じて、 ‘git bisect good’ または ‘git bisect bad’ を実行し
て、テストが必要な次のコミットを要求します。

   最終的には、検査するリビジョンがなくなり、コマンドは最初の不正なコミ
ットの説明を出力します。 参照 ‘refs/bisect/bad’ は、そのコミットを指した
ままになります。

Bisect reset
============

bisectセッションの後、bisect状態をクリーンアップして元のHEADに戻すには、
以下のコマンドを発行します:

     $ git bisect reset

   デフォルトでは、これにより、あなたのツリーは ‘git bisect start’ の前
にチェックアウトされたコミットに戻ります。 (新しく行う ‘git bisect
start’ も、古いbisect状態をクリーンアップするため、これを実行します。)

   オプションの引数を使用すると、代わりに異なるコミットに戻ることができ
ます:

     $ git bisect reset <commit>

   たとえば、 ‘git bisect reset bisect/bad’ は最初のbadリビジョンをチェ
ックアウトしますが、 ‘git bisect reset HEAD’ は現在のbisectコミットのま
まにし、コミットの切り替えを完全に回避します。

Alternate terms(代替用語)
=========================

破損を引き起こしたコミットではなく、他の「old」状態と「new」状態の間で変
化を引き起こしたコミットを探している場合があります。 たとえば、特定の修
正を導入したコミットを探している場合があります。 または、ソースコードの
ファイル名がすべて最終的に会社の命名基準に変換された最初のコミットを探し
ているかもしれません。その他何でもありです。

   このような場合、「変更前の状態」と「変更後の状態」を指すのに「good」
と「bad」という用語(terms)を使用することは非常に混乱する可能性があります
。 したがって、「good」と「bad」の代わりに、それぞれ「old」と「new」とい
う用語を使用できます。 (ただし、単一のセッション内で「good」と「bad」を
「old」と「new」と混在させることはできないことに注意してください。)

   このより一般的な使用法では、 ‘git bisect’ に、いくつかのプロパティを
持つ「new」コミットと、そのプロパティを持たない「old」コミットを提供しま
す。 ‘git bisect’ がコミットをチェックアウトするたびに、そのコミットにそ
のプロパティがあるかどうかをテストします。 含まれている場合は、コミット
を「new」としてマークします。 それ以外の場合は、「old」とマークします。
bisectが行われると、 ‘git bisect’ はどのコミットがそのプロパティを導入し
たかを報告します。

   「good」と「bad」の代わりに「old」と「new」を使用するには、引数として
commitを指定せずに ‘git bisect start’ を実行してから、以下のコマンドを実
行してコミットを追加する必要があります:

     git bisect old [<rev>]

   これは、コミットが求められた変更の前であったことを知らせるためで、あ
るいは、

     git bisect new [<rev>...]

   これはコミットが求められた変更より新しい事を知らせます。

   現在使用している用語(terms)を思い出したいときは、以下を入力します。

     git bisect terms

   old(または new)の用語(term)は、 ‘git bisect terms --term-old’ または
‘git bisect terms --term-good’ で取得できます。

   bad/good または new/old の代わりに独自の用語(terms)を使用する場合は、
以下を使用してbisectを開始することにより、(‘reset’ 、‘start’ などの既存
のbisectサブコマンドを除く)任意の名前を選択できます

     git bisect start --term-old <term-old> --term-new <term-new>

   たとえば、あなたがパフォーマンスの低下をもたらすコミットを探している
場合は、以下のように使用できます

     git bisect start --term-old fast --term-new slow

   または、あなたがバグを修正したコミットを探している場合は、以下のよう
にします

     git bisect start --term-new fixed --term-old broken

   次に、コミットをマークするために、 ‘git bisect good’ や ‘git bisect
bad’ の代わりに、 ‘git bisect <term-old>’ や ‘git bisect <term-new>’ を
使用します。

Bisect visualize/view
=====================

‘gitk’ に現在残っている容疑者(suspects)を確認するには、bisectプロセス中
に以下のコマンドを発行します(サブコマンド ‘view’ は ‘visualize’ の代わり
に使用できます):

     $ git bisect visualize

   ‘DISPLAY’ 環境変数が設定されていない場合、代わりに ‘git log’ が使用さ
れます。 ‘-p’ や ‘--stat’ などのコマンドラインオプションを指定することも
できます。

     $ git bisect visualize --stat

Bisect log and bisect replay
============================

リビジョンをgoodまたはbadとマークした後、以下のコマンドを発行して、これ
までに行われたことを表示します:

     $ git bisect log

   リビジョンのステータスの指定を間違えたのを見つけた場合は、このコマン
ドの出力をファイルに保存し、それを編集して誤ったエントリを削除してから、
以下のコマンドを発行して修正された状態に戻すことができます:

     $ git bisect reset
     $ git bisect replay that-file

Avoiding testing a commit
=========================

bisectセッションの途中で、提案されたリビジョンがテストに適していないこと
がわかっている場合(たとえば、ビルドに失敗し、その失敗が追跡しているバグ
とは何の関係もないことがわかっている場合)、その近くのコミットを手動で選
択し、代わりにそれをテストできます。

   例えば:

     $ git bisect good/bad                   # previous round was good or bad.
     Bisecting: 337 revisions left to test after this (roughly 9 steps)
     $ git bisect visualize                  # oops, that is uninteresting.
     $ git reset --hard HEAD~3               # try 3 revisions before what
                                             # was suggested

   次に、選択したリビジョンをコンパイルしてテストし、その後、通常の方法
でリビジョンにgoodまたはbadのマークを付けます。

Bisect skip
===========

自分で近くのコミットを選択する代わりに、コマンドを発行してGitにそれを実
行するように依頼できます:

     $ git bisect skip                 # Current version cannot be tested

   しかしながら、探しているコミットに隣接するコミットをスキップすると、
Gitはそれらのコミットのどれが最初のbadコミットであったかを正確に知ること
ができなくなります。

   範囲表記を使用して、1つのコミットだけでなく、範囲のコミットをスキップ
することもできます。 例えば以下のようにします:

     $ git bisect skip v2.5..v2.6

   これは、‘v2.5’ 以降の ‘v2.6’ までのコミットをテストしてはならないこと
をbisectプロセスに伝えます。

   注意: 範囲の最初のコミットもスキップする場合は、以下のコマンドを発行
することに注意してください:

     $ git bisect skip v2.5 v2.5..v2.6

   これは、‘v2.5’ と ‘v2.6’ (の両端を含む) の間のコミットをスキップする
必要があることをbisectプロセスに通知します。

bisect startでより多くのパラメータを与えて探索量削減
====================================================

あなたが追跡している問題にツリーのどの部分が関係しているかがわかっている
場合は、 ‘bisect start’ コマンドを発行するときにパスパラメータを指定する
ことで、試行回数をさらに減らすことができます:

     $ git bisect start -- arch/i386 include/asm-i386

   複数の適切なコミットが事前にわかっている場合は、 ‘bisect start’ コマ
ンドを発行するときに、badコミットの直後にすべてのgoodコミットを指定する
ことで、bisect量を絞り込むことができます:

     $ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
                        # v2.6.20-rc6 is bad
                        # v2.6.20-rc4 and v2.6.20-rc1 are good

Bisect run
==========

現在のソースコードがgoodかbadかを判断できるスクリプトがある場合は、以下
のコマンドを発行してbisectすることができます:

     $ git bisect run my_script arguments

   注意: スクリプト(上記例では ‘my_script’)は、現在のソースコードが
good/old ならばコード0で終了し、現在のソースコードが bad/new の場合はコ
ードは125を除く1〜127で終了します。

   その他の終了コードは、bisectプロセスを中止します。 ‘exit(-1)’ を介し
て終了するプログラムは $?= 255 を残すことに注意してください。 (exit(3)の
マニュアルページ参照)。 値は ‘& 0377’ でマスクされます。

   現在のソースコードをテストできない場合は、特別な終了コード125を使用す
る必要があります。 スクリプトがこのコードで終了する場合、現在のリビジョ
ンはスキップされます(上記「git bisect skip」参照)。 126と127はPOSIXシェ
ルによって特定のエラーステータスを通知するために使用されるため、125がこ
の目的で使用する最も適切な値として選択されました(127は、コマンドが見つか
りません で、 126は コマンドが見つかりましたが実行可能ではありません で
す。 — これらの詳細は、 ‘bisect run’ に関する限り、スクリプトの通常のエ
ラーであるため、重要ではありません)。

   bisectセッション中に、テスト対象のリビジョンに一時的な変更を加えたい
場合がよくあります(例: ヘッダーファイルで ‘s/#define DEBUG 0/#define
DEBUG 1/’ 、または「このコミットがないリビジョンでは、このbisectが関心を
持たない別の問題を解決するために、このパッチを適用する必要があります」
)。

   このような状況に対処するために、「git bisect」内部でテストする次のリ
ビジョンを見つけた後、スクリプトはコンパイル前にパッチを適用し、実際のテ
ストを実行し、その後、リビジョン(おそらく必要なパッチを含む)が合格したか
どうかを判断できます。 テストしてから、ツリーを元の状態に巻き戻します。
最後に、スクリプトは実際のテストのステータスで終了し、 ‘git bisect run’
コマンドループがbisectセッションの最終的な結果を決定できるようにする必要
があります。

OPTIONS
*******

‘--no-checkout’
     bisectプロセスの各反復で新しい作業ツリーをチェックアウトしないでく
     ださい。 代わりに、 ‘BISECT_HEAD’ という名前の特別な参照を更新して
     、テストする必要のあるコミットを指すようにします。

     このオプションは、各ステップで実行するテストで、チェックアウトされ
     たツリーが必要ない場合に役立つことがあります。

     ベアリポジトリの場合、 ‘--no-checkout’ が想定されます。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを実行します。

     ブランチのマージによって導入されたデグレを検出する際に、マージコミ
     ットはバグの導入として識別され、その祖先は無視されます。

     このオプションは、マージされたブランチに壊れたコミットまたはビルド
     できないコミットが含まれているが、マージ自体はOKな場合に誤検知を回
     避するのに特に役立ちます。

EXAMPLES
********

   • v1.2とHEADの間で壊れたビルドを自動的にbisectします:

          $ git bisect start HEAD v1.2 --      # HEAD is bad, v1.2 is good
          $ git bisect run make                # "make" builds the app
          $ git bisect reset                   # quit the bisect session

   • originとHEADの間のテスト失敗を自動的にbisectします:

          $ git bisect start HEAD origin --    # HEAD is bad, origin is good
          $ git bisect run make test           # "make test" builds and tests
          $ git bisect reset                   # quit the bisect session

   • 壊れたテストケースを自動的にbisectします:

          $ cat ~/test.sh
          #!/bin/sh
          make || exit 125                     # this skips broken builds
          ~/check_test_case.sh                 # does the test case pass?
          $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10
          $ git bisect run ~/test.sh
          $ git bisect reset                   # quit the bisect session

     ここでは、 ‘test.sh’ カスタムスクリプトを使用します。 このスクリプ
     トでは、 ‘make’ が失敗した場合、現在のコミットをスキップします。
     ‘check_test_case.sh’ は、テストケースが合格した場合は ‘exit 0’ であ
     り、そうでない場合は ‘exit 1’ である必要があります。

     ‘test.sh’ と ‘check_test_case.sh’ の両方がリポジトリの外にある場合
     は、bisectプロセスとmakeプロセスとtestプロセスとスクリプトの間の相
     互作用を防ぐ方が安全です。

   • 一時的な変更(ホットフィックス)で自動的にbisectします:

          $ cat ~/test.sh
          #!/bin/sh

          # tweak the working tree by merging the hot-fix branch
          # and then attempt a build
          if      git merge --no-commit --no-ff hot-fix &&
                  make
          then
                  # run project specific test and report its status
                  ~/check_test_case.sh
                  status=$?
          else
                  # tell the caller this is untestable
                  status=125
          fi

          # undo the tweak to allow clean flipping to the next commit
          git reset --hard

          # return control
          exit $status

     これにより、各テスト実行の前にホットフィックスブランチからの変更が
     適用されます。 例えば、ビルドやテスト環境が変わり、古いリビジョンで
     はすでに修正されているものが、新しいリビジョンでは修正が必要になる
     可能性があるからです。（ホットフィックスブランチが、bisectしている
     すべてのリビジョンに含まれているコミットに基づいていることを確認し
     て、マージがあまり引き込まれないようにするか、 ‘git merge’ の代わり
     に ‘git cherry-pick’ を使用します。)

   • 壊れたテストケースを自動的にbisectします:

          $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10
          $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
          $ git bisect reset                   # quit the bisect session

     これは、テストを1行で記述した場合、実行スクリプトなしで実行できるこ
     とを示しています。

   • 破損したリポジトリでオブジェクトグラフの適切な領域を見つけます

          $ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout
          $ git bisect run sh -c '
                  GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
                  git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
                  git pack-objects --stdout >/dev/null <tmp.$$
                  rc=$?
                  rm -f tmp.$$
                  test $rc = 0'

          $ git bisect reset                   # quit the bisect session

     この場合、「git bisect run」が終了すると、 bisect/bad は、到達可能
     なグラフが「git pack objects」で必要な意味で完全にトラバース可能な
     親が少なくとも1つあるコミットを参照します。

   • コードでデグレの代わりに修正を探します

          $ git bisect start
          $ git bisect new HEAD    # current commit is marked as new
          $ git bisect old HEAD~10 # the tenth commit from now is marked as old

     または:

     $ git bisect start --term-old broken --term-new fixed
     $ git bisect fixed
     $ git bisect broken HEAD~10

Getting help
============

‘git bisect’ を使用して短い使用法の説明を取得し、 ‘gitbisect help’ また
は ‘git bisect -h’ を使用して長い使用法の説明を取得します。

SEE ALSO
********

Fighting regressions with git bisect (git-bisect-lk2009.html),
git-blame(1).

GIT
***

Part of the git(1) suite

Name
****

git-blame — ファイルの各行を最後に変更したリビジョンと作者を表示する

Synopsis
********

     git blame [-c] [-b] [-l] [–root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [–incremental]
                 [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [–since=<date>]
                 [–ignore-rev <rev>] [–ignore-revs-file <file>]
                 [–progress] [–abbrev=<n>] [<rev> | –contents <file> | –reverse <rev>..<rev>]
                 [–] <file>

DESCRIPTION
***********

指定のファイルの各行で、その行を最後に変更したリビジョンからの情報を注釈
します。 オプションで、指定のリビジョンから注釈を開始します。

   ‘-L’ は注釈を指定行に制限します。複数回指定できます。

   行の原初は、ファイル自体の名前変更にまたがって自動的に追跡されます(現
在のところ、名前変更追跡をオフにするオプションはありません)。 あるファイ
ルから別のファイルに移動した行を追跡したり、別のファイルからコピーして貼
り付けた行を追跡したりするには、 ‘-C’ および ‘-M’ オプションを参照してく
ださい。

   レポートには、削除または置換された行については何も表示されません。 以
下の段落で簡単に説明する ‘git diff’ や ‘pickaxe’ インターフェースなどの
ツールを使用する必要があります。

   Gitは、ファイル注釈のサポートとは別に、変更時にコード断片(code
snippet)が発生したときの開発履歴の検索もサポートしています。 これにより
、コード断片がファイルに追加され、ファイル間で移動またはコピーされ、最終
的に削除または置換された時期を追跡できます。 これは、diffでテキスト文字
列を検索することで機能します。 ‘blame_usage’ を検索するpickaxeインターフ
ェースの小さな例:

     $ git log --pretty=oneline -S'blame_usage'
     5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
     ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

OPTIONS
*******

‘-b’
     境界コミットでは空白のSHA-1を表示します。これは、
     ‘blame.blankBoundary’ 構成オプションを介して制御することもできます
     。

‘--root’
     ルートコミットを境界として扱わないでください。 これは、
     ‘blame.showRoot’ 構成オプションを介して制御することもできます。

‘--show-stats’
     blameの出力の最後に追加の統計を含めます。

‘-L <start>,<end>’
‘-L :<funcname>’
     _<start>,<end>_ で指定の行範囲のみ、または正規表現関数名
     _<funcname>_ で指定の行範囲のみに注釈を付けます。複数回指定できます
     。範囲が重複するのは許されます。

     _<start>_ と _<end>_ はオプションです。 ‘-L <start>’ または ‘-L
     <start>,’ は _<start>_ からファイルの終わりまでの範囲です。 ‘-L
     ,<end>’ は、ファイルの先頭から _<end>_ までの範囲です。

     <start> と <end> は、以下のいずれかの形式です:

        • 数値

          <start> または <end> が数値の場合、絶対行番号を指定します(行は
          1から数えます)。

        • ‘/regex/’

          この形式は、指定されたPOSIX正規表現に一致する最初の行を使用し
          ます。 <start> が正規表現の場合、前の ‘-L’ 範囲の末尾から検索
          します。それ以外の場合は、ファイルの先頭から検索します。
          <start> が ‘^/regex/’ の場合、ファイルの先頭から検索します。
          <end> が正規表現の場合、 <start> で指定された行から検索開始し
          ます。

        • +offset or -offset

          これは <end> に対してのみ有効であり、 <start> で指定された行の
          前後の行数を指定します。

     <start> と <end> の代わりに ‘:<funcname>’ が指定されている場合、こ
     れは <funcname> に一致する最初の関数名行から次の関数名行までの範囲
     を示す正規表現です。 ‘:<funcname>’ は、前の ‘-L’ 範囲の末尾から検索
     します。それ以外の場合は、ファイルの先頭から検索します。
     ‘^:<funcname>’ はファイルの先頭から検索します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘-l’
     長いレビジョンを表示します(デフォルト: off)。

‘-t’
     生のタイムスタンプを表示します(デフフォルト: off)。

‘-S <revs-file>’
     git-rev-list(1) を呼び出す代わりに、revs-fileのリビジョンを使用しま
     す。

‘--reverse <rev>..<rev>’
     履歴を後方へではなく前方へウォークします。行があらわれたされたリビ
     ジョンを表示する代わりに、行が存在した最後のリビジョンを表示します
     。これには、START..END のように、STARTにblameのパスが存在するレビジ
     ョン範囲が必要です。 便宜上、 ‘git blame --reverse START’ は ‘git
     blame --reverse START..HEAD’ と見なされます。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを追跡します。 この
     オプションは、履歴全体にいつ導入されたかではなく、特定の統合ブラン
     チにいつ導入されたかを判別するために使用できます。

‘-p’
‘--porcelain’
     ソフトウェア等で使用するのに適した形式で表示します。

‘--line-porcelain’
     磁器形式で表示しますが、コミットが最初に参照されたときだけでなく、
     各行のコミット情報を出力します。 –porcelain の機能を含んでいます。

‘--incremental’
     ソフトウェア等で使用するのに適した形式で結果を段階的
     (incrementally)に表示します。

‘--encoding=<encoding>’
     作者名(author names)の出力と要約のコミットに使用されるエンコーディ
     ングを指定します。 これを ‘none’ に設定すると、blame出力は変換され
     ていないデータになります。詳細については、 git-log(1) のマニュアル
     ページにある discussion の encoding に関する説明を参照してください
     。

‘--contents <file>’
     <rev> が指定されていない場合、コマンドは作業ツリーのコピーから逆方
     向に開始して変更に注釈を付けます。このフラグにより、コマンドは、作
     業ツリーのコピーに、指定されたファイルの内容が含まれているように見
     せかけます(コマンドを標準入力から読み取るには、 ‘-’ を指定します)。

‘--date <format>’
     日付の出力に使用される形式を指定します。 –date が指定されていない場
     合、blame.date 構成変数の値が使用されます。 blame.date 構成変数も設
     定されていない場合は、 iso形式が使用されます。サポートされている値
     については、 git-log(1) の –date オプションの説明を参照してください
     。

‘--[no-]progress’
     進行状況は、端末に接続されている場合、デフォルトで標準エラーストリ
     ームに報告されます。このフラグは、端末に接続されていない場合でも進
     行状況のレポートを有効にします。 ‘--progress’ を ‘--porcelain’ また
     は ‘--incremental’ と一緒に使用することはできません。

‘-M[<num>]’
     ファイル内の移動またはコピーされた行を検出します。コミットが行のブ
     ロックを移動またはコピーすると(たとえば、元のファイルにA、次にBがあ
     り、コミットによってB、次にAに変更される)、従来の「blame」アルゴリ
     ズムは移動の半分だけに気づき、通常は行をblameします それは親に上に
     移動され(つまりB)、子のコミットに下に移動された(つまりA)行にblameを
     割り当てます。このオプションを使用すると、追加の検査パスを実行する
     ことにより、両方のグループの行が親のせいになります。

     <num> はオプションですが、Gitがそれらの行を親コミットに関連付けるた
     めにファイル内で移動/コピーとして検出する必要がある英数字の数
     (number of alphanumeric characters)の下限です。デフォルト値は20です
     。

‘-C[<num>]’
     ‘-M’ に加えて、同じコミットで変更された他のファイルから移動またはコ
     ピーされた行を検出します。これは、プログラムを再編成し、ファイル間
     でコードを移動するときに役立ちます。このオプションを2回指定すると、
     コマンドは、ファイルを作成するコミットで他のファイルからのコピーを
     追加で検索します。このオプションを3回指定すると、コマンドはコミット
     で他のファイルからのコピーを追加で検索します。

     <num> はオプションですが、Gitがそれらの行を親コミットに関連付けるた
     めにファイル間の移動/コピーとして検出する必要がある英数字の数
     (number of alphanumeric characters)の下限です。また、デフォルト値は
     40です。複数の ‘-C’ オプションが指定されている場合、最後の ‘-C’ の
     <num> 引数が有効になります。

‘--ignore-rev <rev>’
     変更が発生しなかったかのように、blameを割り当てるときにリビジョンに
     よって行われた変更を無視します。無視されたコミットによって変更また
     は追加された行は、その行または近くの行を変更した前のコミットのせい
     になります。このオプションは、複数のリビジョンを無視するために複数
     回指定できます。 ‘blame.markIgnoredLines’ 構成オプションが設定され
     ている場合、無視されたコミットによって変更され、別のコミットに起因
     する行は、blame出力で ‘?’ でマークされます。
     ‘blame.markUnblamableLines’ 構成オプションが設定されている場合、別
     のリビジョンに帰することができなかった無視されたコミットによって触
     れられた行は、 _*_ でマークされます。

‘--ignore-revs-file <file>’
     ‘file’ にリストされているリビジョンを無視します。これは
     ‘fsck.skipList’ と同じ形式である必要があります。このオプションは繰
     り返すことができ、これらのファイルは、 ‘blame.ignoreRevsFile’ 構成
     オプションで指定されたファイルの後に処理されます。空のファイル名
     ‘""’ は、以前に処理されたファイルからrevsのリストをクリアします。

‘-h’
     ヘルプメッセージを表示する。

‘-c’
     git-annotate(1) と同じ出力モードを使用します(デフォルト: オフ)。

‘--score-debug’
     ファイル間の行の移動(‘-C’ 参照)およびファイル内で移動された行(‘-M’
     参照)に関連するデバッグ情報を含めます。 リストされている最初の数字
     はスコアです。 これは、ファイル間またはファイル内で移動を検出した英
     数字の数です。これらのコード行が移動されたと見なすには、 これが
     ‘git blame’ の特定のしきい値を超えている必要があります。

‘-f’
‘--show-name’
     元のコミットのファイル名を表示します。 デフォルトでは、名前変更の検
     出により、別の名前のファイルからの行がある場合はファイル名が表示さ
     れます。

‘-n’
‘--show-number’
     元のコミットの行番号を表示します(デフォルト: オフ)。

‘-s’
     作者名とタイムスタンプの出力を抑制します。

‘-e’
‘--show-email’
     作者名の代わりに作者の電子メールアドレス(author email)を表示します
     (デフォルト: オフ)。 これは、 ‘blame.showEmail’ 構成オプションを介
     して制御することもできます。

‘-w’
     親のバージョンと子のバージョンを比較して、その行がどこから来たのか
     を見つけるときは、空白(whitespace)を無視します。

‘--abbrev=<n>’
     デフォルトの7+1桁の16進数でオブジェクト名を省略する代わりに、
     <m>+1桁を使用します。ここで<m>は少なくとも<n>ですが、コミットオブジ
     ェクト名が一意になるような長さにします。 1列分はコミットの境界を示
     すカレット(‘^’)に使用されることに注意してください。

THE PORCELAIN FORMAT(磁器形式)
******************************

この形式では、各行はヘッダーの後に出力されます。 少なくともヘッダーには
、以下のような最初の行があります:

   • その行が属するコミットの40バイトのSHA-1;

   • 元のファイルの行の行番号;

   • 最終ファイルの行の行番号;

   • 前のコミットとは異なるコミットからの行のグループを開始する行におい
     ては、そのグループの行数。以降の行では、このフィールドはありません
     。

   このヘッダー行の後には、コミットごとに少なくとも1回は以下の情報が続き
ます:

   • author name ("author") と email ("author-mail") と time
     ("author-time") と time zone ("author-tz"); コミッターも同様。

   • その行が属するコミット内のファイル名。

   • コミットログメッセージの最初の行("summary")。

   実際の行の内容は、上記のヘッダーの後にTABが前に付いて出力されます。 こ
れは、後でヘッダー要素を追加できるようにするためです。

   磁器形式(porcelain format)は、一般的に、既視のコミット情報を抑制しま
す。 たとえば、同じコミットのせいにされた2行が両方とも表示されますが、そ
のコミットの詳細は1回だけ表示されます。これはより効率的ですが、リーダー
がより多くの状態を保持する必要がある場合があります。 ‘--line-porcelain’
オプションを使用すると、各行の完全なコミット情報を出力できるため、以下の
ように単純な(ただし効率の低い)使用法が可能になります:

     # count the number of lines attributed to each author
     git blame --line-porcelain file |
     sed -n 's/^author //p' |
     sort | uniq -c | sort -rn

SPECIFYING RANGES
*****************

古いバージョンのgitの ‘git blame’ や ‘git annotate’ と異なり、注釈の範囲
は行範囲とリビジョン範囲の両方で制限できます。注釈を行の範囲に制限する
‘-L’ オプションは、複数回指定できます。

   あなたがファイル ‘foo’ の40〜60行目の行の原初を見つけることに関心があ
る場合は、以下のように ‘-L’ オプションを使用できます(2行とも同じ意味です
。どちらも40行目から21行を要求します):

     git blame -L 40,60 foo
     git blame -L 40,+21 foo

   また、正規表現を使用して行範囲を指定することもできます:

     git blame -L '/^sub hello {/,/^}$/' foo

   これは、注釈を ‘hello’ サブルーチンの本体に制限します。

   あなたがバージョンv2.6.18より古い変更、または3週間より古い変更に関心
がない場合は、 ‘git rev-list’ のようにリビジョン範囲指定子を使用できます
:

     git blame v2.6.18.. -- foo
     git blame --since=3.weeks -- foo

   リビジョン範囲指定子を使用して注釈を制限すると、範囲境界以降に変更さ
れていない行(上記の例で、コミットv2.6.18 または 3週間以上経過した最新の
コミットのいずれか)は、その範囲境界のコミットのblameになります。

   特に便利な方法は、追加されたファイルに、既存のファイルからコピペして
作成された行があるかどうかを確認することです。 これは、開発者がだらしな
く、コードを適切にリファクタリングしなかったことを示している場合がありま
す。 最初に、ファイルを導入したコミットを以下のように見つけることができ
ます:

     git log --diff-filter=A --pretty=short -- foo

   次に、 ‘commit^!’ 表記を使用して、コミットとその親の間の変更に注釈を
付けます:

     git blame -C -C -f $commit^! -- foo

INCREMENTAL OUTPUT
******************

‘--incremental’ オプションを付けて呼び出すと、ビルドした結果を出力します
。 出力は一般に、より新しいコミットによって触れられた行から順に語られま
す(つまり、行の注釈は順不同になります)。これは、対話的なビューアで使用す
るためのものです。

   出力形式は磁器形式(Porcelain format)に似ていますが、注釈が付けられて
いるファイルの実際の行は含まれていません。

  1. 各blame項目は必ず行で始まる:

          <40-byte hex sha1> <sourceline> <resultline> <num_lines>

     行番号は1から数えます。

  2. コミットがストリームに初めて現れるとき、追加のコミット情報(作成者、
     電子メール、コミッター、日付、要約など)を説明する1語のタグが各行の
     先頭に出力されて、コミットに関するその他のさまざまな情報が出力され
     ます。

  3. 磁器形式(Porcelain format)とは異なり、ファイル名情報が常に与えられ
     、エントリを終了します:

          "filename" <whitespace-quoted-filename-goes-here>

     したがって、一部の行指向および単語指向のパーサーの解析は非常に簡単
     です(ほとんどのスクリプト言語では非常に自然なはずです)。

          *Note*

          構文解析を行う人の場合: より堅牢にするために、拡張情報行
          (extended information lines)の先頭にあるタグワード(またはその
          特定のものを気にする)を認識できない最初の行と最後の行の間の行
          (‘<sha1>’ 行や ‘filename’ 行)はすべて無視してください。 そうす
          れば、(コミットエンコーディング(commit encoding)や拡張コミット
          解説(extended commit commentary)のような)情報が追加されたとし
          ても、blameビュワーは気にしません。

MAPPING AUTHORS
***************

gitmailmap(5) を参照してください。

SEE ALSO
********

git-annotate(1)

GIT
***

Part of the git(1) suite

Name
****

git-branch — ブランチを、一覧表示または作成または削除します

Synopsis
********

     git branch [–color[=<when>] | –no-color] [–show-current]
             [-v [–abbrev=<n> | –no-abbrev]]
             [–column[=<options>] | –no-column] [–sort=<key>]
             [–merged [<commit>]] [–no-merged [<commit>]]
             [–contains [<commit>]] [–no-contains [<commit>]]
             [–points-at <object>] [–format=<format>]
             [(-r | –remotes) | (-a | –all)]
             [–list] [<pattern>…]
     git branch [–track | –no-track] [-f] <branchname> [<start-point>]
     git branch (–set-upstream-to=<upstream> | -u <upstream>) [<branchname>]
     git branch –unset-upstream [<branchname>]
     git branch (-m | -M) [<oldbranch>] <newbranch>
     git branch (-c | -C) [<oldbranch>] <newbranch>
     git branch (-d | -D) [-r] <branchname>…
     git branch –edit-description [<branchname>]

DESCRIPTION
***********

‘--list’ が指定されている場合、またはオプション以外の引数がない場合は、
既存のブランチが一覧表示されます。 現在のブランチは緑色(green)で強調表示
され、アスタリスク(‘*’)でマークされます。 リンクされたワークツリーでチェ
ックアウトされたブランチは、シアン(cyan)で強調表示され、プラス記号
(‘+’)でマークされます。 オプション ‘-r’ を指定すると、リモート追跡ブラン
チが一覧表示され、オプション ‘-a’ はローカルブランチとリモートブランチの
両方を表示します。

   ‘<pattern>’ が指定されている場合、出力を、マッチするブランチに制限す
るためのシェルワイルドカードとして使用されます。 複数のパターンが指定さ
れている場合、いずれかのパターンに一致するとブランチが表示されます。

   ‘<pattern>’ を提供するときは、 ‘--list’ を使用する必要があることに注
意してください。 そうしないと、コマンドがブランチの作成として解釈される
可能性があります。

   ‘--contains’ を使用すると、名前付きコミットを含むブランチ(つまり、先
端コミットが名前付きコミットの子孫であるブランチ)のみが表示され、
‘--no-contains’ はそれを反転します。 ‘--merged’ を使用すると、指定された
コミットにマージされたブランチ(つまり、指定されたコミットから先端コミッ
トに到達できるブランチ)のみが一覧表示されます。 ‘--no-merged’ を使用する
と、指定されたコミットにマージされていないブランチのみが一覧表示されます
。 <commit> 引数が欠落している場合、デフォルトで ‘HEAD’ (つまり、現在の
ブランチの先端)になります。

   コマンドの2番目の形式は、現在の ‘HEAD’ 、または、指定されている場合は
<start-point> を指す <branchname> という名前の新しいブランチヘッドを作成
します。 特殊なケースとして、 <start-point> について、マージベースが1つ
しかない場合は、‘A’ と ‘B’ のマージベースのショートカットとして ‘A...B’
を使用できます。 最大で ‘A’ と ‘B’ のいずれかを省略できます。その場合、
デフォルトで ‘HEAD’ になります。

   注意: これにより新しいブランチが作成されますが、作業ツリーはそれに切
り替わりません。 ‘git switch <newbranch>’ を使用して、新しいブランチに切
り替えます。

   ローカルブランチがリモート追跡ブランチから開始されると、Gitはブランチ
(具体的には ‘branch.<name>.remote’ と ‘branch.<name>.merge’ の構成エント
リ)をセットアップし、 ‘git pull’ でリモート追跡ブランチから適切にマージ
するようにします。 この動作は、グローバルな ‘branch.autoSetupMerge’ 構成
フラグを介して変更できます。 この設定は、 ‘--track’ および ‘--no-track’
オプションを使用してオーバーライドでき、後で ‘git branch
--set-upstream-to’ を使用して変更できます。

   ‘-m’ または ‘-M’ オプションを使用すると、 <oldbranch> の名前を
<newbranch> に名前変更します。 <oldbranch> に対応するreflogがある場合は
、 <newbranch> に一致するように名前変更され、ブランチの名前変更を記憶す
るためにreflogエントリが作成されます。 <newbranch> が存在する場合は、
‘-M’ を使用して名前の変更を強制する必要があります。

   ‘-c’ および ‘-C’ オプションは、 ‘-m’ および ‘-M’ とまったく同一の意図
(semantics)ですが、ブランチの名前が変更される代わりに、configおよび
reflogとともに新しい名前にコピーされます。

   ‘-d’ または ‘-D’ オプションを使用すると、 ‘<branchname>’ が削除されま
す。 削除するブランチを複数指定できます。 現在、ブランチがreflogを持って
いる場合、reflogも削除されます。

   ‘-r’ を ‘-d’ と一緒に使用して、リモート追跡ブランチを削除します。 リ
モート追跡ブランチを削除するのは、リモートリポジトリに存在しなくなった場
合、または ‘git fetch’ が再度フェッチしないように構成されている場合にの
み意味があることに注意してください。 廃止されたすべてのリモート追跡ブラ
ンチをクリーンアップする方法については、 git-remote(1) の「prune」サブコ
マンドも参照してください。

OPTIONS
*******

‘-d’
‘--delete’
     ブランチを削除します。 ブランチは、アップストリームブランチで完全に
     マージする必要があります。アップストリームが ‘--track’ または
     ‘--set-upstream-to’ で設定されていない場合は、‘HEAD’ でマージする必
     要があります。

‘-D’
     ‘--delete --force’ のショートカットです。

‘--create-reflog’
     ブランチのreflogを作成します。 これにより、ブランチrefに加えられた
     すべての変更の記録がアクティブになり、 ‘<branchname>@\{yesterday}’
     などの日付ベースのsha1式を使用できるようになります。 非ベアリポジト
     リでは、通常、reflogはデフォルトで ‘core.logAllRefUpdates’ 設定オプ
     ションによって有効になっていることに注意してください。 否定形式
     ‘--no-create-reflog’ は、それ以前の ‘--create-reflog’ をオーバーラ
     イドするだけですが、現在のところ ‘core.logAllRefUpdates’ の設定を否
     定しません。

‘-f’
‘--force’
     <branchname> がすでに存在する場合でも、 <branchname> を
     <startpoint> にリセットします。 ‘-f’ がないと、 ‘git branch’ は既存
     のブランチの変更を拒否します。 ‘-d’(または ‘--delete’)と組み合わせ
     て、マージされたステータスに関係なく、または有効なコミットを指して
     いるかどうかに関係なく、ブランチを削除できるようにします。 ‘-m’(ま
     たは ‘--move’)と組み合わせて、新しいブランチ名がすでに存在する場合
     でもブランチの名前を変更できるようにします。同じことが ‘-c’(または
     ‘--copy’)にも当てはまります。

‘-m’
‘--move’
     ブランチと、対応するreflogを、移動/名前変更 します。

‘-M’
     ‘--move --force’ のショートカットです。

‘-c’
‘--copy’
     ブランチと、対応するreflogをコピーします。

‘-C’
     ‘--copy --force’ のショートカットです。

‘--color[=<when>]’
     現在のブランチと、ローカルブランチと、リモート追跡ブランチを強調表
     示するためにブランチに色を付けます。値は always (デフォルト) または
     never または auto でなければなりません。

‘--no-color’
     構成ファイルでデフォルトのカラー出力が指定されている場合でも、ブラ
     ンチの色付けをオフにします。 ‘--color=never’ と同じです。

‘-i’
‘--ignore-case’
     ブランチの並べ替えとフィルタリングでは英大文字小文字を区別しません
     (case insensitive)。

‘--column[=<options>]’
‘--no-column’
     ブランチの一覧表示を複数列に表示します。 オプションの構文については
     、構成変数 ‘column.branch’ を参照してください。 オプションのない
     ‘--column’ と ‘--no-column’ は、それぞれ ‘always’ と ‘never’ と同等
     です。

     このオプションは、非おしゃべりモード(non-verbose mode)でのみ適用で
     きます。

‘-r’
‘--remotes’
     リモートトラッキングブランチを一覧表示または削除(‘-d’ とともに使用
     する場合)します。 オプションのパターンに一致するように ‘--list’ と
     組み合わせます。

‘-a’
‘--all’
     リモートトラッキングブランチとローカルブランチの両方を一覧表示しま
     す。 ‘--list’ と組み合わせて、オプションのパターンにマッチさせます
     。

‘-l’
‘--list’
     ブランチを一覧表示します。 オプションの‘<pattern>…‘を使用します。 例
     : `git branch --list 'maint-*'’ パターンにマッチするブランチのみを
     リストします。

‘--show-current’
     現在のブランチの名前を出力します。 HEADを切り離した(detached HEAD)状
     態では、何も出力されません。

‘-v’
‘-vv’
‘--verbose’
     リストモード(list mode)の場合は、sha1を表示し、各ヘッドの件名と、
     (存在する場合、)アップストリームブランチとの関係をコミットします。
     2回指定した場合は、リンクされたワークツリーのパス(存在する場合)とア
     ップストリームブランチの名前も出力します(‘git remote show <remote>’
     も参照)。 現在のワークツリーのHEADにはパスが出力されないことに注意
     してください(常に現在のディレクトリになります)。

‘-q’
‘--quiet’
     エラー以外のメッセージを抑制して、ブランチを作成または削除するとき
     はもっと静かにしてください。

‘--abbrev=<n>’
     コミットオブジェクト名を示す詳細リストで、オブジェクトを一意に参照
     する、少なくとも16進数 _<n>_ 桁の長さの最短のプレフィックスを表示し
     ます。 デフォルト値は 7 で、 ‘core.abbrev’ 構成オプションでオーバー
     ライドできます。

‘--no-abbrev’
     省略せずに、出力リストに完全なsha1を表示します。

‘-t’
‘--track’
     新しいブランチを作成するときは、 ‘branch.<name>.remote’ および
     ‘branch.<name>.merge’ 構成エントリを設定して、開始点ブランチを新し
     いブランチの「アップストリーム」としてマークします。 この構成は、
     ‘git status’ と ‘git branch -v’ で、2つのブランチの間の関係を表示す
     るようにgitに指示します。 さらに、引数なしで ‘git pull’ に、新しい
     ブランチがチェックアウトされたときにアップストリームからプルするよ
     うに指示します。

     この振る舞いは、開始点がリモート追跡ブランチである場合のデフォルト
     です。 ‘git switch’ と ‘git checkout’ と ‘git branch’ を常に
     ‘--no-track’ が指定されているかのように動作させる場合は、
     branch.autoSetupMerge構成変数を ‘false’ に設定します。 開始点がロー
     カルまたはリモート追跡ブランチのいずれかであるときにこの動作が必要
     な場合は、これを ‘always’ に設定します。

‘--no-track’
     branch.autoSetupMerge構成変数がtrueの場合でも、「upstream」構成をセ
     ットアップしないでください。

‘--set-upstream’
     このオプションは構文がわかりにくいため、サポートされなくなりました
     。 代わりに ‘--track’ または ‘--set-upstream-to’ を使用してください
     。

‘-u <upstream>’
‘--set-upstream-to=<upstream>’
     <branchname> の追跡情報を設定して、<upstream> が <branchname> のア
     ップストリームブランチと見なされるようにします。 <branchname> が指
     定されていない場合、デフォルトで現在のブランチになります。

‘--unset-upstream’
     <branchname> のアップストリーム情報を削除します。 ブランチが指定さ
     れていない場合、デフォルトで現在のブランチになります。

‘--edit-description’
     エディタを開き、テキストを編集して、ブランチの目的を説明し、他のさ
     まざまなコマンド(‘format-patch’ 、‘ request-pull‘ 、 ‘merge’ (有効
     な場合) など)で使用できるようにします。 複数行の説明を使用できます
     。

‘--contains [<commit>]’
     指定されたコミットを含むブランチのみをリストします(指定されていない
     場合はHEAD)。 ‘--list’ の指定を含んでいます。

‘--no-contains [<commit>]’
     指定されたコミットを含まないブランチのみをリストします(指定されてい
     ない場合はHEAD)。 ‘--list’ の指定を含んでいます。

‘--merged [<commit>]’
     指定されたコミットから先端に到達できるブランチのみをリストします(指
     定されていない場合はHEAD)。 ‘--list’ の指定を含んでいます。

‘--no-merged [<commit>]’
     指定されたコミットから先端に到達できないブランチのみをリストします
     (指定されていない場合はHEAD)。 ‘--list’ の指定を含んでいます。

<branchname>
     作成または削除するブランチの名前。 新しいブランチ名は、
     git-check-ref-format(1) で定義されているすべてのチェックに合格する
     必要があります。 これらのチェックの一部は、ブランチ名で許可される文
     字を制限する場合があります。

<start-point>
     新しいブランチヘッドはこのコミットを指します。 ブランチ名 または
     commit-id または タグ として指定できます。 このオプションを省略する
     と、代わりに現在のHEADが使用されます。

<oldbranch>
     名前を変更する既存のブランチの名前。

<newbranch>
     既存のブランチの新しい名前。 <branchname> と同じ制限が適用されます
     。

‘--sort=<key>’
     指定されたキーに基づいて並べ替えます。 プレフィックス ‘-’ を使用し
     て、値の降順で並べ替えます。 ‘--sort=<key>’ オプションを複数回使用
     できます。その場合、最後のキーが主キーになります。 サポートされてい
     るキーは、 ‘gitfor-each-ref’ のキーと同じです。 ソート順は、デフォ
     ルトで、 ‘branch.sort’ 変数が存在する場合はその値に設定されているか
     、完全なrefname (‘refs/...’ プレフィックスを含む)に基づいてソートさ
     れます。 これにより、切り離されたHEAD(detached HEAD)(存在する場合
     )が最初にリストされ、次にローカルブランチ、最後にリモート追跡ブラン
     チがリストされます。 git-config(1) を参照してください。

‘--points-at <object>’
     指定されたオブジェクトのブランチのみを一覧表示します。

‘--format <format>’
     表示されているブランチrefとそれが指すオブジェクトを ‘%(fieldname)’
     によって差し込みする書式文字列。 形式はgit-for-each-ref(1) の形式と
     同じです。

CONFIGURATION
*************

‘pager.branch’ は、ブランチを一覧表示する場合、 つまり ‘--list’ が使用ま
たは暗示されている場合にのみ尊重されます。 デフォルトでは、ページャーを
使用します。 git-config(1) を参照してください。

EXAMPLES
********

Start development from a known tag
          $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
          $ cd my2.6
          $ git branch my2.6.14 v2.6.14   (1)
          $ git switch my2.6.14

     See (1).
          このステップと次のステップは、 ‘checkout -b my2.6.14 v2.6.14’
          を使用して1つのステップに組み合わせることができます。

Delete an unneeded branch
          $ git clone git://git.kernel.org/.../git.git my.git
          $ cd my.git
          $ git branch -d -r origin/todo origin/html origin/man   (1)
          $ git branch -D test                                    (2)

     See (1).
          リモート追跡ブランチ「todo」と「html」と「man」を削除します。
          この後の ‘fetch’ または ‘pull’ は、あなたが構成しないように構
          成しない限り、それらを再度作成します。 git-fetch(1) を参照して
          ください。

     See (2).
          「master」ブランチ(または現在チェックアウトされているブランチ
          )にtestブランチからのすべてのコミットがない場合でも、「test」
          ブランチを削除します。

Listing branches from a specific remote
          $ git branch -r -l '<remote>/<pattern>'                 (1)
          $ git for-each-ref 'refs/remotes/<remote>/<pattern>'    (2)

     See (1).
          ‘-a’ を使用すると、<remote>が、同じ<remote>パターンのプレフィ
          ックスが付いているローカルブランチと混同されます。

     See (2).
          ‘for-each-ref’ は幅広いオプションをとることができます。
          git-for-each-ref(1) を参照してください

   通常、パターンにはクォートが必要です。

NOTES
*****

すぐに切り替えたいブランチを作成する場合は、 ‘git switch’ コマンドとその
‘-c’ オプションを使用して、1つのコマンドで同じことを行う方が簡単です。

   オプション ‘--contains’ と ‘ –no-contains‘ と ‘--merged’ と
‘--no-merged’ は、4つの関連しているが異なる目的を果たします:

   • ‘--contains <commit>’ は、<commit>がリベースまたは修正された場合に
     特別な注意が必要なすべてのブランチを検索するために使用されます。こ
     れらのブランチには、指定された<commit>が含まれているためです。

   • ‘--no-contains <commit>’ はその逆です。つまり、指定された<commit>を
     含まないブランチです。

   • ‘--merged’ は、安全に削除できるすべてのブランチを検索するために使用
     されます。これらのブランチはHEADに完全に含まれているためです。

   • ‘--no-merged’ は、HEADにマージする候補となるブランチを見つけるため
     に使用されます。これらのブランチは、HEADに完全には含まれていないた
     めです。

   複数の ‘--contains’ フィルターと ‘--no-contains’ フィルターを組み合わ
せる場合、少なくとも1つの ‘--contains’ コミットを含み、 ‘--no-contains’
コミットを含まない参照のみが表示されます。

   複数の ‘--merged’ フィルターと ‘--no-merged’ フィルターを組み合わせる
と、少なくとも1つの ‘--merged’ コミットから到達可能で、 ‘--no-merged’ コ
ミットのいずれからも到達できない参照のみが表示されます。

SEE ALSO
********

git-check-ref-format(1), git-fetch(1), git-remote(1), “Understanding
history: What is a branch?” (user-manual.html#what-is-a-branch) in the
Git User’s Manual.

GIT
***

Part of the git(1) suite

Name
****

git-bugreport — ユーザーがバグ報告を提出するための情報を収集する

Synopsis
********

     git bugreport [(-o | –output-directory) <path>] [(-s | –suffix) <format>]

DESCRIPTION
***********

ユーザーのマシン、Gitクライアント、リポジトリの状態に関する情報、および
ユーザーが観察した動作に関する情報の入力書式を(例えば、Gitメーリングリス
トに観察されたバグを報告するために)、ユーザーが共有できる単一のテキスト
ファイルとして獲得します。

   以下の情報がユーザーに要求されます:

   • 再現手順

   • 期待する動作

   • 実際の動作

   以下の情報が自動的に収集されます:

   • _git version –build-options_

   • uname sysname と release と version と machine strings

   • コンパイラ指定情報文字列

   • 有効なフックのリスト

   • $SHELL

   このツールは、通常のGitセットアッププロセスを介して呼び出されます。つ
まり、関連する構成ファイルが読み取れない場合など、起動できない場合があり
ます。 この種のシナリオでは、手動で助けを求めるときに、上記の種類の情報
を手動で収集すると役立つ場合があります。

OPTIONS
*******

‘-o <path>’
‘--output-directory <path>’
     結果のバグレポートファイルを現在のディレクトリではなく ‘<path>’ に
     配置します。

‘-s <format>’
‘--suffix <format>’
     バグレポート名の代替サフィックスを指定して、
     _git-bugreport-<formatted suffix>_ という名前のファイルを作成します
     。 これは、 strftime(3) 形式の文字列の形式をとる必要があります。現
     在の現地時間が使用されます。

GIT
***

Part of the git(1) suite

Name
****

git-bundle — アーカイブごとにオブジェクトとrefを移動します

Synopsis
********

     git bundle create [-q | –quiet | –progress | –all-progress] [–all-progress-implied]
                         [–version=<version>] <file> <git-rev-list-args>
     git bundle verify [-q | –quiet] <file>
     git bundle list-heads <file> [<refname>…]
     git bundle unbundle [–progress] <file> [<refname>…]

DESCRIPTION
***********

「bundle」ファイルを作成や解凍や操作します。 バンドルは、ネットワーク接
続の反対側にアクティブな「サーバー」がない時に、Gitオブジェクトの「オフ
ライン」転送に使用されます。

   これらを使用して、リポジトリの増分(incremental)バックアップと完全
(full)バックアップの両方を作成し、あるリポジトリ内の参照の状態を別のリポ
ジトリに取り次ぐことができます。

   ‘ssh://’ や ‘https://’ などのプロトコルを介してフェッチまたは「読み取
り」するGitコマンドも、バンドルファイルを操作できます。 バンドルから新し
いリポジトリを作成するために git-clone(1) を使うことができ、そして、バン
ドルからリポジトリを取得するために git-fetch(1) を使うことができ、そして
、バンドルの中に含まれる参照を git-ls-remote(1) でリストすることが可能で
す。 対応する「書き込み」サポートはありません。 つまり、バンドルへの
‘git push’ はサポートされていません。

   バンドルの使用方法例については、以下の「EXAMPLES」セクションを参照し
てください。

BUNDLE FORMAT
*************

バンドルは ‘.pack’ ファイル(linkgit：git-pack-objects[1] 参照)であり、バ
ンドル内に含まれる参照を示すヘッダーが付いています。

   パックされたアーカイブ形式自体と同様に、バンドルは自己完結型
(self-contained)にすることも、除外(exclusions)を使用して作成することもで
きます。 以下の「OBJECT PREREQUISITES」(オブジェクトの前提条件)セクショ
ンを参照してください。

   リビジョンの除外を使用して作成されたバンドルは、 git-pack-objects(1)
の ‘--thin’ オプションを使用して作成された「薄いパック」(thin packs)であ
り、 git-index-pack(1) の ‘--fix-thin’ オプションを使用してバンドル解除
します。

   リビジョンの除外を使用する場合、厚いパック(thick pack)を作成するオプ
ションはありません。ユーザーは違いについて心配する必要はありません。 薄
いパック(thin packs)を使用することにより、除外を使用して作成されたバンド
ルのサイズが小さくなります。 それらが内部で「薄い」(thin)ことは、ここで
は単に好奇心として、および他のドキュメントへの参照として示されています

   詳細については、 the ‘bundle-format’ documentation
(technical/bundle-format.html) を参照してください。 「thin pack」ついて
は、 the pack format documentation (technical/pack-format.html) を参照し
てください。

OPTIONS
*******

create [options] <file> <git-rev-list-args>
     ‘file’ という名前のバンドルを作成するために使用されます。 これには
     、バンドルの内容を定義するための ‘<git-rev-list-args>’ 引数が必要で
     す。 ‘options’ には、 ‘git bundle create’ サブコマンドに固有のオプ
     ションが含まれています。

verify <file>
     バンドルファイルが有効であり、現在のリポジトリにきれいに適用される
     ことを確認するために使用されます。 これには、バンドル形式自体のチェ
     ックと、前提条件となるコミットが現在のリポジトリに存在し、完全にリ
     ンクされているかどうかのチェックが含まれます。 ‘git bundle’ は、も
     しあれば欠落しているコミットのリストを表示し、0 以外のステータスで
     終了(exit)します。

list-heads <file>
     バンドルで定義されている参照を一覧表示します。 参照のリストが後に続
     く場合、与えられたものと一致する参照のみが出力されます。

unbundle <file>
     バンドル内のオブジェクトをリポジトリに保存するために ‘git
     index-pack’ に渡し、定義されたすべての参照の名前を出力します。 参照
     のリストが指定されている場合、リスト内の参照と一致する参照のみが出
     力されます。 このコマンドは実際には配管コマンド(plumbing)であり、
     ‘git fetch’ によって呼び出されることのみを目的としています。

<git-rev-list-args>
     ‘git rev-parse’ および ‘git rev-list’ に受け入れられる引数のリスト
     (および名前付きrefを含む。下記「SPECIFYING REFERENCES」参照)。これ
     は、転送する特定のオブジェクトと参照を指定します。 たとえば、
     ‘master~10..master’ を指定すると、現在のmaster参照が、10番目の祖先
     のコミット以降に追加されたすべてのオブジェクトとともにパッケージ化
     されます。 パッケージ化できる参照とオブジェクトの数に明示的な制限は
     ありません。

[<refname>…]
     利用可能として報告された参照を制限するために使用される参照のリスト
     。 これは主に ‘git fetch’ に役立ちます。これは、要求された参照のみ
     を受け取り、必ずしもパック内のすべてを受け取るとは限りません(この場
     合、 ‘git bundle’ は ‘git fetch-pack’ のように機能します)。

‘--progress’
     ‘-q’ が指定されていない限り、進行状況は、端末に接続されている場合、
     デフォルトで標準エラーストリームに報告されます。 このフラグは、標準
     エラーストリームが端末に送られていない場合でも、進行状況を強制しま
     す。

‘--all-progress’
     ‘--stdout’ を指定すると、進行状況レポートはオブジェクトのカウントお
     よび圧縮フェーズでは表示されますが、書き込みフェーズでは禁止されま
     す。 その理由は、場合によっては、出力ストリームが別のコマンドに直接
     リンクされており、受信パックデータを処理するときに独自の進行状況を
     表示したい場合があるためです。 このフラグは ‘--progress’ に似ていま
     すが、 ‘--stdout’ が使用されている場合でも、書き込みフェーズの進行
     状況レポートを強制する点が異なります。

‘--all-progress-implied’
     これは、進行状況の表示がアクティブになるたびに ‘--all-progress’ を
     意味するために使用されます。 ‘--all-progress’ とは異なり、このフラ
     グは実際にはそれ自体では進行状況の表示を強制しません。

‘--version=<version>’
     バンドルのバージョンを指定します。 バージョン2 は古い形式であり、
     SHA-1リポジトリでのみ使用できます。 新しい バージョン3 には、拡張を
     許可する機能が含まれています。 デフォルトは、使用中のハッシュアルゴ
     リズムに基づいて、サポートされている最も古い形式です。

‘-q’
‘--quiet’
     このフラグにより、コマンドは標準エラーストリームで進行状況を報告し
     なくなります。

SPECIFYING REFERENCES
*********************

リビジョンには、バンドルにパッケージ化するための参照名を付ける必要があり
ます。

   複数の参照をパッケージ化でき、複数の前提条件オブジェクトのセットを指
定できます。 パッケージ化されたオブジェクトは、前提条件の結合に含まれて
いないオブジェクトです。

   ‘git bundle create’ コマンドは、 ‘git rev-parse --abbrev-ref=loose’ と
同じルールを使用して参照名を解決します。 各前提条件は、明示的に指定する
ことも(例: ‘^master~10’)、暗黙的に指定することもできます(例:
‘master~10..master’, ‘--since=10.days.ago master’)。

   これらの単純なケースはすべてOKです(「master」ブランチと「next」ブラン
チがあると仮定します):

     $ git bundle create master.bundle master
     $ echo master | git bundle create master.bundle --stdin
     $ git bundle create master-and-next.bundle master next
     $ (echo master; echo next) | git bundle create master-and-next.bundle --stdin

   そして、以下も同様です(上記と同一ですが ‘--stdin’ が省略された例です
):

     $ git bundle create recent-master.bundle master~10..master
     $ git bundle create recent-updates.bundle master~10..master next~5..next

   リビジョン名や、右辺が参照に解決できない範囲は、受け付けられません:

     $ git bundle create HEAD.bundle $(git rev-parse HEAD)
     fatal: Refusing to create empty bundle.
     $ git bundle create master-yesterday.bundle master~10..master~5
     fatal: Refusing to create empty bundle.

OBJECT PREREQUISITES
********************

PREREQUISITES(前提条件);バンドルを作成する場合、共通の履歴のないリポジト
リでバンドル解凍できる自己完結型のバンドルを作成できます。また、履歴の初
期の部分で必要なオブジェクトを除外するための負のリビジョン(negative
revisions)を提供することもできます。

   ‘new’ などのリビジョンを ‘git bundle create’ にフィードすると、リビジ
ョン ‘new’ から到達可能なすべてのオブジェクトを含むバンドルファイルが作
成されます。 そのバンドルを任意のリポジトリでバンドル解凍して、リビジョ
ン ‘new’ につながる完全な履歴を取得できます。

     $ git bundle create full.bundle new

   ‘old..new’ のようなリビジョン範囲は、バンドルファイルを生成しますが、
バンドルが「バンドル解除」可能(unbundle-able)であるためには、リビジョン
‘old’ (とそこから到達できるすべてのオブジェクト) が存在する必要がありま
す:

     $ git bundle create full.bundle old..new

   前提条件のない自己完結型のバンドルは、空のリポジトリにさえもどこにで
も抽出できます。または、そのバンドルからcloneすることもできます(つまり、
‘new’ ですが、 ‘old..new’ ではありません)。

   注意: バンドルファイルには、宛先に既に存在するオブジェクトが含まれて
いても、宛先で解凍する際には無視されますので、注意してください。

   ‘refs/remotes/*’ などの参照を含む ‘git clone --mirror’ と一致させる場
合は、 ‘--all’ を使用します。 ソースリポジトリから直接クローンが取得する
のと同じ参照セットを提供する場合は、 ‘<git-rev-list-args>’ に
‘--branches --tags’ を使用します。

   ‘git bundle verify’ コマンドを使用して、受信者リポジトリにバンドルに
必要な前提条件のコミットがあるかどうかを確認できます。

EXAMPLES
********

あなたが、マシンAのリポジトリR1から、マシンBの別のリポジトリR2に、履歴を
転送するとします。 何らかの理由で、AとBの間の直接接続は許可されていませ
んが、何らかのメカニズム(CD、電子メールなど)を介してAからBにデータを移動
することはできます。 私達は、R1のmasterブランチで行われた開発で、R2を更
新したいと思います。

   開発プロセスをブートストラップするために、あなたは、最初に前提条件の
ないバンドルを作成します。あなたはタグを使用して、最後に処理したコミット
までを記憶し、後で他のリポジトリを増分バンドル(incremental bundle)で簡単
に更新できるようにすることができます:

     machineA$ cd R1
     machineA$ git bundle create file.bundle master
     machineA$ git tag -f lastR2bundle master

   次に、file.bundleをターゲットマシンBに転送します。このバンドルでは既
存のオブジェクトを抽出する必要がないため、あなたはマシンBからクローンを
作成して、新しいリポジトリを作成できます:

     machineB$ git clone -b master /home/me/tmp/file.bundle R2

   これにより、結果のリポジトリに「origin」と呼ばれるリモートが定義され
、バンドルからフェッチおよびプルできるようになります。 R2 の
$GIT_DIR/config ファイルには、以下のようなエントリがあります:

     [remote "origin"]
         url = /home/me/tmp/file.bundle
         fetch = refs/heads/*:refs/remotes/origin/*

   結果のmine.gitリポジトリを更新するには、 /home/me/tmp/file.bundle に
保存されているバンドルを増分更新(incremental updates)に置き換えた後、フ
ェッチまたはプルできます。

   元のリポジトリでさらに作業した後、増分バンドル(incremental bundle)を
作成して、他のリポジトリを更新できます:

     machineA$ cd R1
     machineA$ git bundle create file.bundle lastR2bundle..master
     machineA$ git tag -f lastR2bundle master

   次に、あなたはバンドルを他のマシンに転送して /home/me/tmp/file.bundle
を置き換え、そこからプルします。

     machineB$ cd R2
     machineB$ git pull

   目的の受信者リポジトリが必要なオブジェクトをどのコミットまで持つべき
かがわかっている場合は、その知識を使用して前提条件を指定し、結果のバンド
ルに含まれるリビジョンとオブジェクトを制限するカットオフポイントを指定で
きます。 前の例では、この目的でlastR2bundleタグを使用しましたが、
git-log(1) コマンドに指定する他のオプションを使用できます。 その他の例は
以下のとおりです:

   あなたは両方に存在するタグを使用できます:

     $ git bundle create mybundle v1.0.0..master

   あなたは日時に基づく前提条件を使用できます:

     $ git bundle create mybundle --since=10.days master

   あなたはコミット数を利用できます:

     $ git bundle create mybundle -10 master

   ‘git-bundle verify’ を実行して、前提条件に従って作成されたバンドルか
ら抽出可能かどうかを確認できます:

     $ git bundle verify mybundle

   これにより、バンドルから抽出するために必要なコミットが一覧表示され、
コミットがない場合はエラーになります。

   受信者リポジトリの観点からのバンドルは、フェッチまたはプルする通常の
リポジトリと同じです。 たとえば、フェッチするときに参照をマップできます:

     $ git fetch mybundle master:localRef

   あなたはまた、それが提供する参照を確認することもできます:

     $ git ls-remote mybundle

GIT
***

Part of the git(1) suite

Name
****

git-cat-file — リポジトリオブジェクトのコンテンツまたはタイプとサイズの
情報を提供します

Synopsis
********

     git cat-file (-t [–allow-unknown-type]| -s [–allow-unknown-type]| -e | -p | <type> | –textconv | –filters ) [–path=<path>] <object>
     git cat-file (–batch[=<format>] | –batch-check[=<format>]) [ –textconv | –filters ] [–follow-symlinks]

DESCRIPTION
***********

SYNOPSISの最初の形式では、コマンドはリポジトリ内のオブジェクトのコンテン
ツまたはタイプを提供します。 オブジェクトのタイプを調べるために ‘-t’ や
‘-p’ が使われているか、オブジェクトのサイズを調べるために ‘-s’ が使われ
ているか、あるいは ‘--textconv’ や ‘--filters’ が使われている(これらはタ
イプ ‘blob’ を意味する)場合を除いて、タイプは必須となります。

   SYNOPSISの2番目の形式では、オブジェクトのリスト(改行で区切られている
)がstdinに提供され、各オブジェクトのSHA-1のタイプとサイズがstdoutに出力
されます。 オプションの ‘<format>’ 引数を使用して、出力形式をオーバーラ
イドできます。 ‘--textconv’ または ‘--filters’ のいずれかが指定された場
合、入力は、適切なドライバーを決定できるように、オブジェクト名とそれに続
くパス名を単一の空白で区切ってリストすることが期待されます。

OPTIONS
*******

<object>
     表示するオブジェクトの名前。 オブジェクト名を綴る方法のより完全なリ
     ストについては、 gitrevisions(7) の「SPECIFYING REVISIONS」セクショ
     ンを参照してください。

‘-t’
     コンテンツの代わりに、 ‘<object>’ で識別されるオブジェクトタイプを
     表示します。

‘-s’
     コンテンツの代わりに、 ‘<object>’ で識別されるオブジェクトサイズを
     表示します。

‘-e’
     ‘<object>’ が存在し、有効なオブジェクトである場合、ステータスはゼロ
     で終了(exit)します。 ‘<object>’ が無効な形式の場合、ゼロ以外で終了
     (exit)し、stderrでエラーを発行します。

‘-p’
     そのタイプに基づいて ‘<object>’ の内容をきれいに印刷
     (pretty-print)します。

<type>
     通常、これは実際のタイプの ‘<object>’ と一致しますが、指定された
     ‘<object>’ から簡単に逆参照できるタイプを要求することもできます。 例
     として、‘<object>`がそれを含むコミットオブジェクトである `tree`を要
     求するか、または `<object>’ がそれを指すタグオブジェクトである
     ‘blob’ を要求します。

‘--textconv’
     textconvフィルターによって変換されたコンテンツを表示します。 この場
     合、 ‘<object>’ は、 ‘<tree-ish>:<path>’ または ‘:<path>’ の形式で
     ある必要があり、 ‘<path>’ のインデックスに記録されたコンテンツにフ
     ィルターを適用します。

‘--filters’
     与えられた ‘<path>’ に対して、現在の作業ツリーで構成されているフィ
     ルターによって変換された内容を表示します(つまり、スマッジ(smudge)フ
     ィルター、行末変換など)。 この場合、‘<object>’ は
     ‘<tree-ish>:<path>’ または ‘:<path>’ の形式である必要があります。

‘--path=<path>’
     ‘--textconv’ または ‘--filters’ とともに使用して、例えば、ブロブの
     元となったリビジョンを把握するのが難しいときに、オブジェクト名とパ
     スを別々に指定できるようにします。

‘--batch’
‘--batch=<format>’
     stdinで提供される各オブジェクトの、オブジェクト情報とコンテンツを印
     刷します。 ‘--textconv’ または ‘--filters’ 以外は、他のオプションや
     引数と組み合わせることはできません。 ‘--textconv’ または
     ‘--filters’ 場合、入力行も空白で区切られたパスを指定する必要があり
     ます。 詳細については、以下の「BATCH OUTPUT」のセクションを参照して
     ください。

‘--batch-check’
‘--batch-check=<format>’
     stdinで提供される各オブジェクトのオブジェクト情報を出力します。
     ‘--textconv’ または ‘--filters’ を除いて、他のオプションや引数と組
     み合わせることはできません。 ‘--textconv’ または ‘--filters’ の場合
     、入力行も空白で区切られたパスを指定する必要があります。 詳細につい
     ては、以下の「BATCH OUTPUT」のセクションを参照してください。

‘--batch-all-objects’
     stdinでオブジェクトのリストを読み取る代わりに、 (到達可能なオブジェ
     クトだけでなく、)リポジトリ内のすべてのオブジェクトと代替オブジェク
     トストア(alternate object stores)に対して要求されたバッチ操作を実行
     します。 ‘--batch’ または ‘--batch-check’ を指定する必要があります
     。 オブジェクトは、ハッシュでソートされた順序でアクセスされることに
     注意してください。

‘--buffer’
     通常、バッチ出力は各オブジェクトが出力された後にフラッシュされるた
     め、プロセスは ‘cat-file’ からインタラクティブに読み取りおよび書き
     込みを行うことができます。 このオプションを使用すると、出力は通常の
     stdioバッファリングを使用します。 これは、多数のオブジェクトで
     ‘--batch-check’ を呼び出す場合には、はるかに効率的です。

‘--unordered’
     ‘--batch-all-objects’ が使用されている場合に、このオプションを使用
     すると、ハッシュの順序よりもオブジェクトのコンテンツにアクセスする
     のに効率的な順序でオブジェクトにアクセスします。 順序の正確な詳細は
     指定されていませんが、特定の順序が必要ない場合は、特に ‘--batch’ を
     使用すると、通常、出力が速くなります。 注意: ‘cat-file’ は、リポジ
     トリに同一オブジェクトが複数回保存されている場合でも、オブジェクト
     を1回だけ表示することに注意してください。

‘--allow-unknown-type’
     ‘-s’ または ‘-t’ が不明なタイプの 壊れた/破損した オブジェクトを照
     会できるようにします。

‘--follow-symlinks’
     ‘--batch’ または ‘--batch-check’ を使用して、 tree-ish:path-in-tree
     形式の拡張SHA-1式を使用してオブジェクトを要求する場合は、リポジトリ
     内のシンボリックリンクをたどります。 リンク自体に関する出力を提供す
     る代わりに、リンク先オブジェクトに関する出力を提供します。 シンボリ
     ックリンクがツリーっぽいものの外側を指している場合(たとえば、
     ‘/foo’ へのリンクまたは ‘../foo’ へのルートレベルのリンク)、ツリー
     の外側にあるリンクの部分が出力されます。

     このオプションは、ツリー内のオブジェクトではなく、インデックス内の
     オブジェクトが指定されている場合(たとえば、 ‘HEAD:link’ ではなく
     ‘:link’）、 (現在のところ)正しく機能しません。

     ‘--batch’ または ‘--batch-check’ が使用されていない限り、このオプシ
     ョンは(現在のところ)使用できません。

     たとえば、以下のものを含むgitリポジトリについて考えてみましょう:

          f はファイルで、内容は "hello\n" です。
          link は f への symlink です。
          dir/link は ../f への symlink です。
          plink は ../f への symlink です。
          alink は /etc/passwd への symlink です。

     通常のファイル ‘f’ の場合、 ‘echo HEAD:f | git cat-file --batch’ と
     すると、以下を出力します

          ce013625030ba8dba906f756967f9e9ca394464a blob 6

     そして ‘echo HEAD:link | git cat-file --batch --follow-symlinks’ は
     、 ‘HEAD:dir/link’ と同様に、 両方とも ‘HEAD:f’ を指しているため、
     同一の出力を行います。

     ‘--follow-symlinks’ がないと、これらはシンボリックリンク自体に関す
     るデータを出力します。 ‘HEAD:link’ の場合、以下のように表示されます
     。

          4d1ae35ba2c8ec712fa2a379db44ad639ca277bd blob 1

     ‘plink’ と ‘alink’ はどちらもツリーの外側を指しているため、それぞれ
     以下のように出力されます:

          symlink 4
          ../f

          symlink 11
          /etc/passwd

OUTPUT
******

‘-t’ が指定されている場合、 ‘<type>’ の1つを出力。

   ‘-s’ が指定されている場合、 ‘<object>’ のサイズ(バイト単位)を出力。

   ‘-e’ が指定されている場合、 ‘<object>’ の形式が正しくない限り、出力は
行われません。

   ‘-p’ を指定すると、‘<object>’ の内容がきれいに印刷(pretty-printed)さ
れます。

   ‘<type>’ が指定されている場合、 ‘<object>’ の生の(圧縮されていない)コ
ンテンツが返されます。

BATCH OUTPUT
************

‘--batch’ または ‘--batch-check’ が指定されている場合、 ‘cat-file’ は
stdinからオブジェクトを1行に1つずつ読み取り、それらに関する情報を出力し
ます。 デフォルトでは、 git-rev-parse(1) にフィードされたかのように、行
全体がオブジェクトと見なされます。

   カスタム ‘<format>’ を使用して、オブジェクトごとに表示される情報を指
定できます。 ‘<format>’ は、各オブジェクトのstdoutに文字通りコピーされ、
‘%(atom)’ ‘形式のプレースホルダーが展開され、その後に改行が続きます。 使
用可能なatomは以下のとおりです:

‘objectname’
     オブジェクト名の完全な16進表現。

‘objecttype’
     オブジェクトのタイプ(‘cat-file -t’ で表示されるものと同じ)。

‘objectsize’
     オブジェクトのサイズ(バイト単位) (‘cat-file -s’ で表示されるものと
     同じ)。

‘objectsize:disk’
     オブジェクトがディスク上で占めるサイズ(バイト単位)。 下記「
     CAVEATS」セクションの「note about on-disk sizes」（ディスク上のサイ
     ズに関する注記)を参照してください。

‘deltabase’
     オブジェクトがディスク上にデルタとして保存されている場合、これはデ
     ルタベースオブジェクト名の完全な16進表現に展開されます。 それ以外の
     場合は、null OID ( 全てゼロ)に展開されます。 下記「CAVEATS」を参照
     してください。

‘rest’
     このatomが出力文字列で使用されている場合、入力行は最初の空白の境界
     で分割されます。 その空白の前のすべての文字がオブジェクト名と見なさ
     れます。 その最初の空白後の文字(つまり、行の「残り」)は、 ‘%(rest)’
     アトムに置き換えられて出力されます。

   形式が指定されていない場合、デフォルトの形式は ‘%(objectname)
%(objecttype) %(objectsize)’ です。

   ‘--batch’ が指定されている場合、オブジェクト情報の後にオブジェクトの
内容(‘%(objectsize)’ バイトのサイズ)が続き、その後に改行(newline)が続き
ます。

   たとえば、カスタム形式のない ‘--batch’ は、以下のように生成されます:

     <oid> SP <type> SP <size> LF
     <contents> LF

   一方、 ‘--batch-check='%(objectname) %(objecttype)'’ は、以下のように
生成します:

     <oid> SP <type> LF

   リポジトリ内のオブジェクトに解決できない名前がstdinに指定されている場
合、 ‘cat-file’ はカスタム形式を無視して以下のように出力します:

     <object> SP missing LF

   (あいまいな短い sha など、)複数のオブジェクトを参照する可能性のある名
前が指定されている場合、 ‘cat-file’ はカスタム形式を無視して以下のように
出力します:

     <object> SP ambiguous LF

   ‘--follow-symlinks’ が使用され、リポジトリ内のシンボリックリンクがリ
ポジトリの外部を指している場合、 ‘cat-file’ はカスタム形式を無視して以下
のように出力します:

     symlink SP <size> LF
     <symlink> LF

   シンボリックリンク(symlink)はツリーのルートに対して絶対(absolute)(‘/’
で始まる)か、あるいは相対(relative)です。 たとえば、 dir/link が
‘../../foo’ を指している場合、‘<symlink>’ は ‘../foo’ になります。
‘<size>’ は、バイト単位のシンボリックリンクのサイズです。

   ‘--follow-symlinks’ を使用すると、以下のエラーメッセージが表示されま
す:

     <object> SP missing LF

   これは、要求した最初のシンボリックリンク(initial symlink)が存在しない
場合に出力されます。

     dangling SP <size> LF
     <object> LF

   これは、最初のシンボリックリンク(initial symlink)が存在する場合に出力
されますが、それが指すモノは出力されません。

     loop SP <size> LF
     <object> LF

   これは、シンボリックリンクループ(または解決するために40を超えるリンク
段数を必要とするシンボリックリンク)に対して出力されます。

     notdir SP <size> LF
     <object> LF

   これは、シンボリックリンクの解決中に、ファイルがディレクトリ名として
使用された場合に出力されます。

CAVEATS(警告)
*************

注意: ディスク上のオブジェクトのサイズは正確に報告されますが、どのrefま
たはオブジェクトがディスクの使用に関与しているかについて結論を出す際には
注意が必要です。 パックされた非デルタオブジェクトのサイズは、それに対し
てデルタするオブジェクトのサイズよりもはるかに大きい場合がありますが、ベ
ースとデルタのオブジェクトの選択は任意であり、再パック中に変更される可能
性があります。

   注意: オブジェクトの複数のコピーがオブジェクトデータベースに存在する
可能性があることにも注意してください。 この場合、どのコピーのサイズまた
はデルタベースが報告されるかは未定義です。

GIT
***

Part of the git(1) suite

Name
****

git-check-attr — gitattributes情報を表示

Synopsis
********

     git check-attr [-a | –all | <attr>…] [–] <pathname>…
     git check-attr –stdin [-z] [-a | –all | <attr>…]

DESCRIPTION
***********

このコマンドは、すべてのパス名について、gitattributesとしての各属性を
‘unspecified’(未指定)または ‘set’ または ‘unset’ であるかどうか一覧表示
します。

OPTIONS
*******

‘-a, --all’
     指定されたパスに関連付けられているすべての属性を一覧表示します。 こ
     のオプションを使用すると、 _unspecified_ (指定されていない)属性は出
     力に含まれません。

‘--cached’
     作業ツリーを無視して、インデックス内のみに対して ‘.gitattributes’ を
     考慮してください。

‘--stdin’
     コマンドラインからではなく、標準入力から1行に1つずつパス名を読み取
     ります。

‘-z’
     出力形式は、マシンで解析できるように変更されます。 ‘--stdin’ も指定
     されている場合、入力パスは改行文字ではなくNUL文字で区切ります。

‘--’
     先行するすべての引数を属性として解釈し、後続のすべての引数をパス名
     として解釈します。

   ‘--stdin’ と ‘--all’ と ‘--’ のいずれも使用されていない場合、最初の引
数は属性として扱われ、残りの引数はパス名として扱われます。

OUTPUT
******

出力形式: <path> COLON SP <attribute> COLON SP <info> LF

   ‘-z’ が有効の場合はNULが区切り文字として使用されます: <path> NUL
<attribute> NUL <info> NUL

   <path>はクエリ対象のファイルのパス、 <attribute> はクエリ対象の属性、
<info> は行かのいずれかになります:

‘unspecified’
     (未指定)パスにその属性が定義されていない場合。

‘unset’
     属性がfalseとして定義されている場合。

‘set’
     属性がtrueとして定義されている場合。

<value>
     属性に値が割り当てられたとき。

   バッファリングは、 git(1) の ‘GIT_FLUSH’ オプションに記載されているよ
うに行われます。呼び出し元は、入力バッファーのオーバーフィル
(overfilling)または空の出力バッファーからの読み取りによって引き起こされ
るデッドロックを回避する責任があります。

EXAMPLES
********

これらの例では、以下の ‘.gitattributes’ ファイルが使用されています:

     *.java diff=java -crlf myAttr
     NoMyAttr.java !myAttr
     README caveat=unspecified

   • 単一の属性のリスト:

     $ git check-attr diff org/example/MyClass.java
     org/example/MyClass.java: diff: java

   • ファイルの複数の属性の一覧表示:

     $ git check-attr crlf diff myAttr -- org/example/MyClass.java
     org/example/MyClass.java: crlf: unset
     org/example/MyClass.java: diff: java
     org/example/MyClass.java: myAttr: set

   • ファイルのすべての属性を一覧表示:

     $ git check-attr --all -- org/example/MyClass.java
     org/example/MyClass.java: diff: java
     org/example/MyClass.java: myAttr: set

   • 複数のファイルの属性を一覧表示:

     $ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
     org/example/MyClass.java: myAttr: set
     org/example/NoMyAttr.java: myAttr: unspecified

   • すべての値が等しく明確であるわけではありません:

     $ git check-attr caveat README
     README: caveat: unspecified

SEE ALSO
********

gitattributes(5).

GIT
***

Part of the git(1) suite

Name
****

git-check-ignore — gitignoreや除外ファイルのデバッグ

Synopsis
********

     git check-ignore [<options>] <pathname>…
     git check-ignore [<options>] –stdin

DESCRIPTION
***********

コマンドラインまたは ‘--stdin’ を介してファイルから指定されたパス名ごと
に、ファイルが ‘.gitignore’ (またはexcludeメカニズムへの他の入力ファイル
)によって除外されているかどうかを確認し、除外されている場合はそのパスを
出力します。

   デフォルトでは、追跡中のファイル(tracked files)は除外ルールの対象では
ないため、まったく表示されません。但し、 ‘–no-index’ もご覧下さい。

OPTIONS
*******

‘-q, --quiet’
     何も出力せず、終了ステータスを設定するだけです。 これは、単一のパス
     名でのみ有効です。

‘-v, --verbose’
     除外されたパスを出力する代わりに、除外パターンに一致するパスごとに
     、パスと一緒に除外パターンを出力します。(通常、除外パターンに一致す
     ることはパスが除外されることを意味しますが、パターンが ‘!’ で始まる
     場合、それは否定パターンであり、一致することはパスが除外されないこ
     とを意味します。)

     除外ソース内および除外ソース間の優先ルールについては、 gitignore(5)
     を参照してください。

‘--stdin’
     コマンドラインからではなく、標準入力から1行に1つずつパス名を読み取
     ります。

‘-z’
     出力フォーマットは、マシン解析可能になるように変更されます(以下を参
     照)。 ‘--stdin’ も指定されている場合、入力パスは改行文字ではなく
     NUL文字で区切られます。

‘-n, --non-matching’
     どのパターンにも一致しないパスを表示します。これは、 ‘--verbose’ が
     有効になっている場合にのみ意味があります。有効になっていないと、パ
     ターンに一致するパスと一致しないパスを区別できません。

‘--no-index’
     チェックを行うときにインデックスを調べません。これは、例えば ‘git
     add .’ で追跡されたパスが、ユーザーの期待通りにルールで無視されなか
     った場合のデバッグに使用できます。また、以前に ‘git add -f’ で追加
     したパスにマッチするように、否定を含むパターンを開発するときにも使
     用できます。

OUTPUT
******

デフォルトでは、指定されたパス名のうち無視パターンに一致するパスが1行に
1つずつ出力されます。特定のパスに一致する無視パターンがない場合、そのパ
スについては何も出力されません。これは、そのパスが無視されないことを意味
します。

   ‘--verbose’ が指定されている場合、出力の各行は以下の形式になります:

   <source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname>

   <pathname> はクエリ対象のファイルのパス、 <pattern> は一致するパター
ン、 <source> はパターンのソースファイル、 <linenum> はそのソース内のパ
ターンの行番号です。 パターンに ‘!’ 接頭辞または ‘/’ 接尾辞が含まれてい
る場合、それは出力でも保持されます。 <source> は、 ‘core.excludesFile’ で
構成されたファイルを参照する場合は絶対パス、 ‘.git/info/exclude’ または
ディレクトリごとの除外ファイルを参照する場合はリポジトリルートを基準とし
ます。

   ‘-z’ が指定されている場合、出力のパス名はヌル文字で区切られます。
‘--verbose’ も指定されている場合、コロンとハードタブの代わりにヌル文字も
使用されます:

   <source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL>

   ‘-n’ または ‘--non-matching’ が指定されている場合、一致しないパス名も
出力されます。その場合、 <pathname> を除く各出力レコードのすべてのフィー
ルドが空になります。これは、非対話的に実行する場合に役立ちます。これによ
り、ファイル達を長時間実行されるチェック無視プロセスのSTDINに段階的にス
トリーミングでき、これらのファイルごとに、STDOUTはそのファイルがパターン
に一致するかどうかを示します。 (このオプションがないと、特定のファイルの
出力がないということは、どのパターンとも一致しなかったのか、出力がまだ生
成されていないのかを判断することはできません。)

   バッファリングは、 git(1) の ‘GIT_FLUSH’ オプションに記載されているよ
うに行われます。呼び出し元は、入力バッファーのオーバーフィルまたは空の出
力バッファーからの読み取りによって引き起こされるデッドロックを回避する責
任があります。

EXIT STATUS
***********

0
     提供されたパスの1つ以上が無視されます。

1
     提供されたパスはどれも無視されません。

128
     致命的なエラーが発生しました。

SEE ALSO
********

gitignore(5) git-config(1) git-ls-files(1)

GIT
***

Part of the git(1) suite

Name
****

git-check-mailmap — 連絡先(contacts)の、正式な名前と電子メールアドレスを
表示

Synopsis
********

     git check-mailmap [<options>] <contact>…

DESCRIPTION
***********

コマンドライン指定または、(‘--stdin’ を使用する場合)標準入力からの各
“Name <user@host>” または “<user@host>” について、その人の正規名と電子メ
ールアドレス(以下 "Mapping Authors" 参照)を検索します。見つかった場合は
、それらを印刷します。それ以外の場合は、入力をそのまま出力します。

OPTIONS
*******

‘--stdin’
     コマンドラインで指定された連絡先(contacts)を消費後、標準入力から連
     絡先(contacts)を1行に1つずつ読み取ります。

OUTPUT
******

各連絡先(contact)ごとに、改行で終了する1行が出力されます。 名前が
_mailmap_ に提供または認識されている場合、 “Name <user@host>” が出力され
ます。それ以外の場合は、 “<user@host>” のみが出力されます。

CONFIGURATION
*************

カスタムの ‘.mailmap’ ターゲットファイルまたはオブジェクトを指定する方法
については、 git-config(1) の ‘mailmap.file’ と ‘mailmap.blob’ を参照し
てください。

MAPPING AUTHORS
***************

gitmailmap(5) 参照。

GIT
***

Part of the git(1) suite

Name
****

git-check-ref-format — 参照名が整形式であることを確認します

Synopsis
********

     git check-ref-format [–normalize]
            [–[no-]allow-onelevel] [–refspec-pattern]
            <refname>
     git check-ref-format –branch <branchname-shorthand>

DESCRIPTION
***********

指定の refname が受け入れ可能かどうかを確認し、受け入れられない場合はゼ
ロ以外のステータスで終了します。

   参照はGitでブランチとタグを指定するために使用されます。ブランチヘッド
は ‘refs/heads’ 階層に格納され、タグはref名前空間の ‘refs/tags’ 階層に格
納されます(通常は ‘$GIT_DIR/refs/heads’ ディレクトリと
‘$GIT_DIR/refs/tags’ ディレクトリに、または refが ‘git gc’ によってパッ
クされている場合はファイル ‘$GIT_DIR/packed-refs’ のエントリとしてありま
す)。

   Gitは、参照の命名方法に以下のルールを課しています:

  1. 階層(ディレクトリ)グループ化のためにスラッシュ(‘/’)を含めることがで
     きますが、スラッシュで区切られたコンポーネントは、ドット(‘.’)で開始
     したり、シーケンス ‘.lock’ で終了したりすることはできません。

  2. 少なくとも1つのスラッシュ(‘/’)が含まれている必要があります。これに
     より、 ‘heads/’ 、 ‘tags/’ などのカテゴリの存在が強制されますが、実
     際の名前は制限されません。 ‘--allow-onelevel’ オプションが使用され
     ている場合、このルールは放棄されます。

  3. どこにも2つの連続したドット(‘..’)を含めることはできません。

  4. ASCII制御文字(つまり、値が \040 未満のバイト または \177(‘DEL’))、
     スペース、チルダ(‘~’)、キャレット(‘^’)、コロン(‘:’)はどこにでも含め
     ることはできません。

  5. 疑問符(‘？’)、アスタリスク(‘*’)、角かっこ(‘[’)がどこにあってもいけ
     ません。この規則の例外については、以下の ‘--refspec-pattern’ オプシ
     ョンを参照してください。

  6. スラッシュ(‘/’)で開始または終了したり、複数の連続したスラッシュを含
     めることはできません(この規則の例外については、以下の ‘--normalize’
     オプションを参照してください)。

  7. ドット(‘.’)で終わらせることはできません。

  8. シーケンス ‘@{’ を含めることはできません。

  9. 単一の文字 ‘@’ にすることはできません。

  10. ‘\’ を含めることはできません。

   これらのルールにより、シェルスクリプトをベースにしたツールで参照名を
簡単にパースできるようになり、参照名が(誤って)引用符なしで使われたときに
シェルでパス名を展開したり、特定の参照名表現におけるあいまいさを回避する
ことができます(gitrevisions(7) を参照)。

  1. 二重ドット(‘..’)は、 ‘ref1..ref2’ などとよく使用されます。一部のコ
     ンテキストでは、この表記は ‘^ref1 ref2’ を意味します(つまり、‘ref1’
     に無く かつ ‘ref2’ にある)。

  2. チルダ(‘~’)とキャレット(‘^’)は、接尾辞 _nth parent_ (n番目の親)と
     _peel onion_ (玉ねぎ剥き)操作を導入するために使用されます。

  3. コロン(‘：’)は、 ‘srcref:dstref’ のように、フェッチおよびプッシュ操
     作で「srcrefの値を使用してdstrefに格納する」ことを意味するために使
     用されます。 ‘git cat-file blob v1.3.3:refs.c’ のようにして ‘git
     cat-file’ などで特定のオブジェクトを選択するためにも使用できます。

  4. at-open-brace(‘@{’)は、reflogエントリにアクセスするための表記法とし
     て使用されます。

   ‘--branch’ オプションを使用すると、コマンドは名前を取得し、それが有効
なブランチ名として使用できるかどうかを確認します(たとえば、新しいブラン
チを作成するとき)。ただし、切り離された(detached)HEAD状態を参照する可能
性のある、遡及チェックアウト構文(previous checkout syntax)を使用する場合
は注意が必要です。 ‘git check-ref-format --branch $name’ が実装するルー
ルは、 ‘git check-ref-format refs/heads/$name’ が言うことよりも厳しい場
合があります(たとえば、参照コンポーネントの先頭にダッシュが表示される場
合がありますが、ブランチ名の先頭では明示的に禁止されています)。リポジト
リで ‘--branch’ オプションを指定して実行すると、入力は最初に「遡及チェッ
クアウト構文」 ‘@{-n}’ 用に展開されます。たとえば、 ‘@{-1}’ は、 ‘git
switch’ または ‘git checkout’ 操作を使用して最後にチェックアウトされたも
のを参照する方法です。磁器コマンドでは、ブランチ名が必要な場所でこの構文
を受け入れるために、このオプションを使用する必要があります。これにより、
あなたがブランチ名を入力したかのように機能できます。注意: 「遡及チェック
アウト操作」では、例外として、チェックアウトされたN番目の最後のものがブ
ランチではなかった場合にコミットオブジェクト名が生成される可能性があるこ
とに注意してください。

OPTIONS
*******

‘--[no-]allow-onelevel’
     1レベルのrefnameを受け入れるかどうかを制御します(つまり、複数の ‘/’
     で区切られたコンポーネントを含まないrefname)。 デフォルトは
     ‘--no-allow-onelevel’ です。

‘--refspec-pattern’
     <refname>を(リモートリポジトリで使用される)refspecの参照名パターン
     として解釈します。このオプションを有効にすると、<refname>は
     refspecに単一の ‘*’ を含めることができます(例: ‘foo/bar*/baz’ また
     は ‘foo/bar*baz/’ はOKですが、 ‘foo/bar*/baz*’ はダメです)。

‘--normalize’
     先行スラッシュ(‘/’)文字を削除し、名前コンポーネント間の隣接するスラ
     ッシュを1つのスラッシュに折りたたむことにより、 _refname_ を正規化
     します。正規化されたrefnameが有効な場合は、それを標準出力に出力し、
     ステータス0で終了します。それ以外の場合は、ゼロ以外のステータスで終
     了します。 ( ‘--print’ は ‘--normalize’ を綴る非推奨の方法です。)

EXAMPLES
********

   • チェックアウトしたのモノの一つ前のものの名前を印刷します:

          $ git check-ref-format --branch @{-1}

   • 新しいブランチに使用する参照名を決定します:

          $ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")||
          { echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; }

GIT
***

Part of the git(1) suite

Name
****

git-checkout-index — インデックスから作業ツリーにファイルをコピー

Synopsis
********

     git checkout-index [-u] [-q] [-a] [-f] [-n] [–prefix=<string>]
                        [–stage=<number>|all]
                        [–temp]
                        [-z] [–stdin]
                        [–] [<file>…]

DESCRIPTION
***********

リストされているすべてのファイルをインデックスから作業ディレクトリにコピ
ーします(既存ファイルは上書きしません)。

OPTIONS
*******

‘-u’
‘--index’
     インデックスファイルのチェックアウトされたエントリの統計情報を更新
     します。

‘-q’
‘--quiet’
     ファイルが存在する場合、またはインデックスにない場合は、静かにする

‘-f’
‘--force’
     既存ファイルを強制的に上書きします

‘-a’
‘--all’
     インデックス内のすべてのファイルをチェックアウトします。ファイル名
     の明示的な指定と一緒に使用することはできません。

‘-n’
‘--no-create’
     新しいファイルをチェックアウトせず、すでにチェックアウトされている
     ファイルのみを更新します。

‘--prefix=<string>’
     ファイルを作成するときは、<string> (通常は末尾に/を含むディレクトリ
     名) をファイル名の先頭に追加します

‘--stage=<number>|all’
     マージされていないエントリをチェックアウトする代わりに、名前付きス
     テージからファイルをコピーします。 <number>は1〜3の間でなければなり
     ません。 注: ‘--stage=all’ は自動的に ‘--temp’ の指定を含みます。

‘--temp’
     ファイルを作業ディレクトリにコピーする代わりに、コンテンツを一時フ
     ァイルに書き込みます。一時的な名前の関連付けはstdoutに書き込まれま
     す。

‘--stdin’
     コマンドラインからパスのリストを取得する代わりに、標準入力からパス
     のリストを読み取ります。デフォルトでは、パスはLFで区切られます(つま
     り、1行に1つのパス)。

‘-z’
     ‘--stdin’ でのみ意味があります。 パスは、LFではなくNUL文字で区切ら
     れます。

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

   フラグの順序は以前は重要でしたが、現在は重要ではありません。

   ‘git checkout-index’ を実行するだけでは何も起こりません。 あなたはお
そらく ‘git checkout-index -a’ を意図しました。 そして、それを強制したい
場合は、 ‘git checkout-index -f -a’ が必要です。

   ここでは直感性は目標ではありません。再現性が目標です。 「引数がないと
いうことは作業がないことを意味する」という振る舞いの理由は、スクリプトか
ら以下のことができるはずだからです:

     $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --

   これにより、既存のすべての ‘*.h’ ファイルがキャッシュされたコピーに置
き換えられます。 空のコマンドラインが「すべて」を意味するならば、これは
インデックス内のすべてを強制的に更新してしまいますが、そうではありません
。 ただし、 ‘git checkout-index’ は ‘--stdin’ を受け入れるため、以下のよ
うにする方が高速です:

     $ find . -name '*.h' -print0 | git checkout-index -f -z --stdin

   残りがファイル名になることがわかっている場合は、 ‘--’ を使用すること
をお勧めします。 たとえば、‘-a’ のファイル名での問題を防ぎます。 スクリ
プトでは ‘--’ を使用することをお勧めします。

–temp または –stage=all の使用
******************************

‘--temp’ が使用されている場合(または ‘--stage=all’ によって暗黙に指定さ
れている場合)、 ‘git checkout-index’ は、チェックアウトされているインデ
ックスエントリごとに一時ファイルを作成します。 インデックスの統計情報は
更新されません。 これらのオプションは、マージされていないファイルを外部
のマージツールで処理できるように、呼び出し元がマージされていないすべての
エントリのすべてのステージを必要とする場合に役立ちます。

   一時ファイル名と追跡されたパス名の関連付けを提供するリストがstdoutに
書き込まれます。リスト形式には2つのバリエーションがあります:

     . tempname TAB path RS

   最初の形式は、 ‘--stage’ が省略されているか、 ‘--stage=all’ でない場
合に使用される形式です。 フィールドtempnameはファイルの内容を保持する一
時ファイル名であり、pathはインデックスで追跡されるパス名です。 要求され
たエントリのみが出力されます。

     . stage1temp SP stage2temp SP stage3tmp TAB path RS

   2番目の形式は、 ‘--stage=all’ の場合に使用される形式です。 3つのステ
ージ一時フィールド(stage1temp、stage2temp、stage3temp)は、インデックスに
ステージエントリがある場合は一時ファイルの名前をリストし、ステージエント
リがない場合は ‘.’ をリストします。ステージ0のエントリしかないpathは、常
に出力から省略されます。

   どちらの形式でも、RS(レコード区切り文字)はデフォルトでは改行ですが、
コマンドラインで ‘-z’ が渡された場合はヌルバイトになります。一時ファイル
名は常に安全な文字列(safe strings)で、ディレクトリ区切り文字や空白文字が
含まれることはありません。pathフィールドは常に現在のディレクトリを基準に
しており、一時ファイル名は常に最上位ディレクトリを基準にしています。

   一時ファイルにコピーされるオブジェクトがシンボリックリンクである場合
、リンクの内容は通常のファイルに書き込まれます。 この情報を利用するのは
エンドユーザーまたは磁器コマンドの責任です。

EXAMPLES
********

すでにチェックアウトされているファイルのみをupdateおよびrefreshするには
          $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh

‘git checkout-index’ を使用して「ツリー全体をエクスポート」
     プレフィックス機能により、基本的に ‘git checkout-index’ を「ツリー
     としてエクスポートする」機能として使用するのは簡単になります。目的
     のツリーをインデックスに読み込んで、以下の手順を実行します:

          $ git checkout-index --prefix=git-export-dir/ -a

     ‘git checkout-index’ は、指定されたディレクトリにインデックスを「エ
     クスポート」します。

     最後の ‘/’ は重要です。 エクスポートされた名前には、文字通り、指定
     された文字列が接頭辞として付けられます。 これを以下の例と比較してく
     ださい。

プレフィックス付きのファイルをエクスポート
          $ git checkout-index --prefix=.merged- Makefile

     これにより、現在キャッシュされている ‘Makefile’ のコピーが、ファイ
     ル ‘.merged-Makefile’ にチェックアウトされます。

GIT
***

Part of the git(1) suite

Name
****

git-checkout — ブランチの切り替え、または作業ツリーファイルの復元を行い
ます。

Synopsis
********

     git checkout [-q] [-f] [-m] [<branch>]
     git checkout [-q] [-f] [-m] –detach [<branch>]
     git checkout [-q] [-f] [-m] [–detach] <commit>
     git checkout [-q] [-f] [-m] [[-b|-B|–orphan] <new_branch>] [<start_point>]
     git checkout [-f|–ours|–theirs|-m|–conflict=<style>] [<tree-ish>] [–] <pathspec>…
     git checkout [-f|–ours|–theirs|-m|–conflict=<style>] [<tree-ish>] –pathspec-from-file=<file> [–pathspec-file-nul]
     git checkout (-p|–patch) [<tree-ish>] [–] [<pathspec>…]

DESCRIPTION
***********

作業ツリー内のファイルを、インデックスまたは指定されたツリー内のバージョ
ンと一致するように更新します。 pathspecが指定されていない場合、 ‘git
checkout’ は ‘HEAD’ も更新して、指定されたブランチを現在のブランチとして
設定します。

‘git checkout [<branch>]’
     ‘<branch>’ での作業の準備をするために、インデックスと作業ツリーのフ
     ァイルを更新し、 ‘HEAD’ をブランチに向けることで、‘<branch>’ に切り
     替わります。作業ツリーのファイルに対するローカルな変更は保持され、
     ‘<branch>’ にコミットできるようになります。

     ‘<branch>’ が見つからないが、一致する名前を持つ1つのリモート
     (‘<remote>’ と呼びます)に追跡ブランチが存在し、‘ –no-guess‘ が指定
     されていない場合は、以下と同等として扱います

          $ git checkout -b <branch> --track <remote>/<branch>

     あなたは ‘<branch>’ を省略できます。この場合、コマンドは「現在のブ
     ランチをチェックアウトする」ことになり、(もし存在すれば)現在のブラ
     ンチの追跡情報だけを表示するという、かなり高価な副作用のある、見栄
     えの良いノー・オペレーション(no-op)となります。

‘git checkout -b|-B <new_branch> [<start point>]’
     ‘-b’ を指定すると、git-branch(1) が呼び出されてチェックアウトされた
     かのように新しいブランチが作成されます。 この場合、 ‘git branch’ に
     渡される ‘--track’ または ‘--no-track’ オプションを使用できます。便
     利にするために ‘-b’ のない ‘--track’ はブランチの作成を意味します。
     後述の ‘--track’ の説明を参照してください。

     ‘-B’ を指定すると、存在しない場合は ‘<new_branch>’ が作成されます。
     それ以外の場合はリセットされます。これは、以下の取引(transaction)と
     同等です

          $ git branch -f <branch> [<start point>]
          $ git checkout <branch>

     つまり、 ‘git checkout’ が成功しない限り、ブランチは リセット/作成
     されません。

‘git checkout --detach [<branch>]’
‘git checkout [--detach] <commit>’
     ‘<commit>’ の上で作業する準備をします。その上で、 ‘HEAD’ を切り離し
     (「DETACHED HEAD」セクションを参照)、作業ツリーのインデックスとファ
     イルを更新します。 作業ツリー内のファイルへのローカルの変更は保持さ
     れるため、結果の作業ツリーは、コミットに記録された状態と、ローカル
     の変更になります。

     ‘<commit>’ 引数がブランチ名の場合、 ‘--detach’ オプションを使用して
     、ブランチの先端にある ‘HEAD’ をデタッチできます(‘git checkout
     <branch>’ は、 ‘HEAD’ をデタッチせずにそのブランチをチェックアウト
     します)。

     ‘<branch>’ を省略すると、現在のブランチの先端にある ‘HEAD’ が切り離
     されます。

‘git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>...’
‘git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]’
     pathspecにマッチするファイルの内容を上書きします。 ‘<tree-ish>’ (ほ
     とんどの場合コミット)が指定されていない場合は、作業ツリーをインデッ
     クスの内容で上書きします。 ‘<tree-ish>’ が指定された場合、インデッ
     クスと作業ツリーの両方を ‘<tree-ish>’ の内容で上書きします。

     以前にマージに失敗したため、インデックスがマージされていないエント
     リを含んでいる可能性があります。デフォルトでは、インデックスからそ
     のようなエントリをチェックアウトしようとすると、チェックアウト操作
     は失敗し、何もチェックアウトされません。 ‘-f’ を使用すると、これら
     のマージされていないエントリは無視されます。マージの特定の側からの
     コンテンツは、 ‘--ours’ または ‘--theirs’ を使用してインデックスか
     らチェックアウトできます。 ‘-m’ を使用すると、作業ツリーファイルに
     加えられた変更を破棄して、元の競合するマージ結果を再作成できます。

‘git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]’
     これは以前のモードと似ていますが、対話的インターフェイスを使用して
     「diff」出力を表示し、その結果において使用するハンクを選択できます
     。 ‘--patch’ オプションの説明については、以下を参照してください。

OPTIONS
*******

‘-q’
‘--quiet’
     静かにします。フィードバックメッセージを抑制します。

‘--progress’
‘--no-progress’
     ‘--quiet’ が指定されていない限り、進行状況は、端末に接続されている
     場合、デフォルトで標準エラーストリームに報告されます。 このフラグは
     、 ‘--quiet’ に関係なく、端末に接続されていない場合でも進行状況のレ
     ポートを有効にします。

‘-f’
‘--force’
     ブランチを切り替えるときは、インデックスや作業ツリーが ‘HEAD’ と異
     なっていても続行します。これは、ローカルの変更を破棄するために使用
     されます。

     インデックスからパスをチェックアウトするときは、マージされていない
     エントリでエラーにしないでください。代わりに、マージされていないエ
     ントリは無視されます。

‘--ours’
‘--theirs’
     インデックスからパスをチェックアウトするときは、ステージ
     #2(_ours_)または#3(_theirs_)でマージされていないパスをチェックアウ
     トしてください。

     注意: ‘git rebase’ と ‘git pull --rebase’ での作業中、「ours」と「
     theirs」が入れ替わっているように見える場合があることに注意してくだ
     さい。 ‘--ours’ は、変更がリベースされるブランチからのバージョンを
     提供し、 ‘--theirs’ は、リベースされる作業を保持するブランチからの
     バージョンを提供します。

     これは、リモートでの履歴を共有の正規の履歴として扱うワークフローで
     ‘rebase’ が使用されているためです。リベースするブランチで行われた作
     業を、統合されるサードパーティの作業として扱います。そして、あなた
     は一時的にリベース中に正規の歴史の管理者の役割を引き受けています。
     正規の履歴の管理者として、リモートからの履歴を「私たち」(ours; つま
     り、「私達の共有された正規の履歴」)として表示する必要があり、サイド
     ブランチで行ったことは「彼ら」(theirs;つまり「その上での貢献者の作
     品」)として表示する必要があります。

‘-b <new_branch>’
     ‘<new_branch>’ という名前の新しいブランチを作成し、 ‘<start_point>’
     で開始します。詳細については、 git-branch(1) を参照してください。

‘-B <new_branch>’
     ブランチ ‘<new_branch>’ を作成し、 ‘<start_point>’ で開始します。す
     でに存在する場合は、 ‘<start_point>’ にリセットします。 これは、
     ‘-f’ を伴って ‘git branch’ を実行するのと同じです。詳細については、
     git-branch(1) を参照してください。

‘-t’
‘--track’
     新しいブランチを作成するときは、「アップストリーム構成」(upstream
     configuration)をセットアップします。 詳細については、
     git-branch(1)の ‘--track’ を参照してください。

     ‘-b`オプションが指定されていない場合、新しいブランチの名前は、対応
     するリモート用に構成されたrefspecのローカル部分を調べ、最初の部分を
     `*’ まで削除することにより、リモート追跡ブランチから派生させます。
     これにより、 ‘origin/hack’ (または ‘remotes/origin/hack’、 あるいは
     ‘refs/remotes/origin/hack’) から分岐するときに、ローカルブランチと
     して ‘hack’ を使用するように指示されます。指定された名前にスラッシ
     ュ(‘/’)がない場合、または上記の推測の結果が空の名前になる場合、推測
     は中止されます。このような場合は、 ‘-b’ を使用して明示的に名前を付
     けることができます。

‘--no-track’
     ‘branch.autoSetupMerge’ 構成変数がtrueであっても、「アップストリー
     ム構成」を設定しないでください。

‘--guess’
‘--no-guess’
     ‘<branch>‘が見つからないが、名前が一致する1つのリモート(
     ‘<remote>‘と呼びます)に追跡ブランチが存在する場合は、以下と同等とし
     てあつかいます

          $ git checkout -b <branch> --track <remote>/<branch>

     ブランチが複数のリモートに存在し、そのうちの1つが
     _checkout.defaultRemote_ 構成変数で名付けられている場合、
     _<branch>_ がすべてのリモートで一意でなくても、曖昧さ回避の目的でそ
     のブランチを使用します。例えば ‘checkout.defaultRemote=origin’ と設
     定すると、 _<branch>_ があいまいだが _origin_ リモート上に存在する
     場合、常にそこからリモートブランチをチェックアウトします。
     git-config(1) の _checkout.defaultRemote_ も参照してください。

     ‘--guess’ がデフォルトの振る舞いです。無効にするには、 ‘--no-guess’
     を使用します。

     デフォルトの振る舞いは、‘checkout.guess’ 構成変数を介して設定できま
     す。

‘-l’
     新しいブランチのreflogを作成します。詳細については、 git-branch(1)
     を参照してください。

‘-d’
‘--detach’
     ブランチをチェックアウトして作業するのではなく、検査と破棄可能な実
     験のためのコミットをチェックアウトします。 これは、 ‘<commit>’ がブ
     ランチ名でない場合の、 ‘git checkout <commit>’ のデフォルトの動作で
     す。 詳細については、以下の「DETACHED HEAD」セクションを参照してく
     ださい。

‘--orphan <new_branch>’
     ‘<start_point>’ から開始された ‘<new_branch>’ という名前の新しい _孤
     立した_ (orphan) ブランチを作成し、それに切り替えます。 この新しい
     ブランチで行われた最初のコミットには親がなく、他のすべてのブランチ
     とコミットから完全に切断された新しい履歴のルートになります。

     インデックスと作業ツリーは、以前に ‘git checkout <start_point>’ を
     実行した場合と同じように調整されます。これにより、 ルート(root)をコ
     ミットするために容易に ‘git commit -a’ 実行をでき、‘<start_point>’
     と同様のパスのセットを記録する新しい履歴を開始できます。

     これは、ツリーの完全な履歴を公開せずにコミットからツリーを公開する
     場合に便利です。これは、現在のツリーが「クリーン」であるが、完全な
     履歴にはプロプライエタリなコードやその他の邪魔なコードが含まれてい
     るプロジェクトの、オープンソースブランチを公開するためにこれを行う
     ことができます。

     ‘<start_point>’ のパスとはまったく異なるパスのセットを記録する切断
     された履歴を開始する場合は、作業ツリーの最上位から ‘git rm -rf .’ を
     実行して、孤立したブランチ(orphan branch)を作成した直後にインデック
     スと作業ツリーをクリアする必要があります。その後に、新しいファイル
     を準備したり、作業ツリーを再作成したり、他の場所からファイルをコピ
     ーしたり、tarballを抽出したりする準備が整います。

‘--ignore-skip-worktree-bits’
     スパースチェックアウトモード(sparse checkout mode)では、 ‘git
     checkout -- <paths>’ は、 ‘<paths>’ と一致するエントリと、
     ‘$GIT_DIR/info/sparse-checkout’ のスパースパターン(sparse
     patterns)のみを更新します。このオプションは、スパースパターンを無視
     し、 ‘<paths>’ 内のファイルを追加し直します。

‘-m’
‘--merge’
     ブランチを切り替えるときに、現在のブランチと切り替え先のブランチの
     間で異なる1つ以上のファイルにローカルの変更がある場合、コマンドは、
     コンテキストでの変更を保持するためにブランチの切り替えを拒否します
     。ただし、このオプションを使用すると、現在のブランチ、作業ツリーの
     内容、および新しいブランチの間の3方向のマージを実行してから新しいブ
     ランチに移動します。

     マージの競合が発生すると、競合するパスのインデックスエントリはマー
     ジされないままになります。競合を解決し、解決されたパスを ‘git add’（
     またはマージによってパスが削除される場合は ‘git rm’)でマークする必
     要があります。

     インデックスからパスをチェックアウトする場合、このオプションを使用
     すると、指定したパスで競合するマージを再作成できます。

     ‘--merge’ でブランチを切り替えると、ステージされた変更が失われる可
     能性があります。

‘--conflict=<style>’
     上記の ‘--merge’ オプションと同一ですが、競合するハンクの表示方法を
     変更し、 ‘merge.conflictStyle’ 構成変数をオーバーライドします。 可
     能な値は「merge」(デフォルト)と「diff3」(「merge」スタイルで表示さ
     れるものに加えて、元のコンテンツを表示する)です。

‘-p’
‘--patch’
     ‘<tree-ish>’ (または指定されていない場合はインデックス)と作業ツリー
     の間の差分でハンクを対話的に選択します。選択されたハンクは、作業ツ
     リー(‘<tree-ish>’ が指定されている場合はインデックス)に逆に適用され
     ます。

     これは、 ‘git checkout -p’ を使用して、現在の作業ツリーから編集を選
     択的に破棄できることを意味します。 ‘--patch’ モードの操作方法につい
     ては、 git-add(1) の「Interactive Mode」セクションを参照してくださ
     い。

     注意: このオプションはデフォルトでオーバーレイなしモードを使用しま
     す(‘--overlay’ も参照)。現在はオーバーレイモードをサポートしていな
     いことに注意してください。

‘--ignore-other-worktrees’
     ‘git checkout’ は、必要なrefが別のワークツリーによってすでにチェッ
     クアウトされている場合に拒否します。このオプションを使用すると、と
     にかくrefをチェックアウトできます。つまり、refを複数のワークツリー
     で保持できます。

‘--overwrite-ignore’
‘--no-overwrite-ignore’
     ブランチを切り替えるときに、無視したファイルを黙って上書きします。
     これがデフォルトの動作です。新しいブランチに無視したファイルが含ま
     れている場合に操作を中止するには、 ‘--no-overwrite-ignore’ を使用し
     ます。

‘--recurse-submodules’
‘--no-recurse-submodules’
     ‘--recurse-submodules’ を使用すると、スーパープロジェクトに記録され
     たコミットに従って、すべてのアクティブなサブモジュールのコンテンツ
     が更新されます。サブモジュールのローカル変更が上書きされる場合、
     ‘-f’ が使用されない限り、チェックアウトは失敗します。何も使用されて
     いない場合(または ‘--no-recurse-submodules’)、サブモジュールの作業
     ツリーは更新されません。 git-submodule(1) と同様に、これはサブモジ
     ュールの ‘HEAD’ を切り離します(detach)。

‘--overlay’
‘--no-overlay’
     デフォルトのオーバーレイモードでは、 ‘git checkout’ がインデックス
     または作業ツリーからファイルを削除することはありません。
     ‘--no-overlay’ を指定すると、インデックスと作業ツリーには表示される
     が、 ‘<tree-ish>’ には表示されないファイルが削除され、 ‘<tree-ish>’
     と完全に一致するようになります。

‘--pathspec-from-file=<file>’
     pathspecは、コマンドライン引数の代わりに ‘<file>’ で渡されます。
     ‘<file>’ が正確に ‘-’ の場合、標準入力が使用されます。pathspec要素
     は、LFまたはCR/LFで区切られます。pathspec要素は、構成変数
     ‘core.quotePath’ で説明されているように、クォートできます
     (git-config(1) 参照)。 ‘--pathspec-file-nul’ および グローバル
     ‘--literal-pathspecs’ も参照してください。

‘--pathspec-file-nul’
     ‘–pathspec-from-file‘でのみ意味があります。Pathspec要素はNUL文字で
     区切られ、他のすべての文字は文字通りに解釈されます(改行と引用符を含
     む)。

<branch>
     チェックアウトするブランチ。もしそれがブランチ(つまり、
     ‘refs/heads/’ を前につけたとき、有効なrefである名前)を参照している
     なら、そのブランチはチェックアウトされます。そうでない場合、もしそ
     れが有効なコミットを参照していれば、あなたの ‘HEAD’ は "detached" と
     なり、あなたはもはやどのブランチにもいません(詳しくは以下を参照して
     ください)。

     ‘@{-N}’ 構文を使用して、 ‘git checkout `操作を使用してチェックアウ
     トされた最後からN番目ブランチ/コミットを参照できます。 `@{-1}’ と同
     義の ‘-’ を指定することもできます。

     特殊なケースとして、マージベースが1つしかない場合は、 ‘A’ と ‘B’ の
     マージベースのショートカットとして ‘A...B’ を使用できます。 最大で
     ‘A’ と ‘B’ のどちらかを省略できます。その場合、デフォルトで ‘HEAD’
     になります。

<new_branch>
     新しいブランチの名前。

<start_point>
     新しいブランチを開始するコミットの名前。詳細については、
     git-branch(1) を参照してください。デフォルトは ‘HEAD’ です。

     特殊なケースとして、マージベースが1つしかない場合は、 ‘A’ と ‘B’ の
     マージベースのショートカットとして ‘A...B’ を使用できます。 最大で
     ‘A’ と ‘B’ のどちらかを省略できます。その場合、デフォルトで ‘HEAD’
     になります。

<tree-ish>
     チェックアウト元のツリー(パスが指定されている場合)。指定しない場合
     はインデックスが使用されます。

     特殊なケースとして、マージベースが1つしかない場合は、 ‘A’ と ‘B’ の
     マージベースのショートカットとして ‘A...B’ を使用できます。 最大で
     ‘A’ と ‘B’ のどちらかを省略できます。その場合、デフォルトで ‘HEAD’
     になります。

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

<pathspec>…
     操作の影響を受けるパスを制限します。

     詳細については、 gitglossary(7) の「pathspec」エントリを参照してく
     ださい。

DETACHED HEAD
*************

‘HEAD’ は通常、名前付きブランチ(‘master’ など)を指します。一方、各ブラン
チは特定のコミットを参照します。3つのコミットがあり、そのうちの1つがタグ
付けされており、ブランチ‘master‘ がチェックアウトされているリポジトリを
見てみましょう:

                HEAD (refers to branch 'master')
                 |
                 v
     a---b---c  branch 'master' (refers to commit 'c')
         ^
         |
       tag 'v2.0' (refers to commit 'b')

   この状態でコミットが作成されると、新しいコミットを参照するようにブラ
ンチが更新されます。 具体的には、 ‘git commit’ は、親がコミット ‘c’ であ
る新しいコミット ‘d’ を作成し、ブランチ ‘master’ を更新して新しい コミッ
ト ‘d’ を参照します。 ‘HEAD’ はまだブランチ ‘master’ を参照しているので
、間接的に コミット ‘d’ を参照するようになりました:

     $ edit; git add; git commit

                    HEAD (refers to branch 'master')
                     |
                     v
     a---b---c---d  branch 'master' (refers to commit 'd')
         ^
         |
       tag 'v2.0' (refers to commit 'b')

   名前付きブランチの先端にないコミットをチェックアウトしたり、名前付き
ブランチによって参照されていない新しいコミットを作成したりできると便利な
場合があります。 コミット ‘b’ をチェックアウトするとどうなるか見てみまし
ょう(ここでは、これを行う2つの方法を示します):

     $ git checkout v2.0  # or
     $ git checkout master^^

        HEAD (refers to commit 'b')
         |
         v
     a---b---c---d  branch 'master' (refers to commit 'd')
         ^
         |
       tag 'v2.0' (refers to commit 'b')

   使用するcheckoutコマンドに関係なく、 ‘HEAD’ はコミット ‘b’ を直接参照
するようになりました。 これは、切り離された ‘HEAD’ (detached HEAD)状態に
あることとして知られています。これは、名前付きブランチを参照するのではな
く、単に ‘HEAD’ が特定のコミットを参照することを意味します。この状態でコ
ミットを作成するとどうなるか見てみましょう:

     $ edit; git add; git commit

          HEAD (refers to commit 'e')
           |
           v
           e
          /
     a---b---c---d  branch 'master' (refers to commit 'd')
         ^
         |
       tag 'v2.0' (refers to commit 'b')

   新しいコミット ‘e’ がありますが、これは ‘HEAD’ によってのみ参照されま
す。 もちろん、この状態でさらに別のコミットを追加できます:

     $ edit; git add; git commit

              HEAD (refers to commit 'f')
               |
               v
           e---f
          /
     a---b---c---d  branch 'master' (refers to commit 'd')
         ^
         |
       tag 'v2.0' (refers to commit 'b')

   実際、私達は通常のGit操作はすべて実行できます。 しかし、ここで私達が
‘master’ をチェックアウトするとどうなるか見てみましょう:

     $ git checkout master

                    HEAD (refers to branch 'master')
           e---f     |
          /          v
     a---b---c---d  branch 'master' (refers to commit 'd')
         ^
         |
       tag 'v2.0' (refers to commit 'b')

   この時点で、コミット ‘f’ を指しているものは何もないことを理解すること
が重要です。最終的に、コミット ‘f’ (および拡張によりコミット ‘e’ )は、あ
なたがルーチンのGitガベージコレクションプロセス前に参照を作成しない限り
、ルーチンのGitガベージコレクションプロセスによって削除されます。あなた
が、まだコミット‘f‘から離れていない場合、以下のいずれかがそれへの参照を
作成します:

     $ git checkout -b foo   (1)
     $ git branch foo        (2)
     $ git tag foo           (3)

See (1).
     コミット ‘f’ を参照する新しいブランチ ‘foo’ を作成し、次にブランチ
     ‘foo’ を参照するように‘HEAD‘を更新します。つまり、このコマンドを実
     行すると、もはや切り離された‘HEAD‘ (detached HEAD)状態では無くなり
     ます。

See (2).
     同様に、コミット ‘f’ を参照する新しいブランチ ‘foo’ を作成しますが
     、 ‘HEAD’ は切り離されたままにします。

See (3).
     新しいタグ ‘foo’ を作成します。これは、‘HEAD’ を切り離したままコミ
     ット ‘f’ を参照します。

   私達がうっかり ‘f’ から離れてしまった場合は、最初にそのオブジェクト名
を回復する必要があり(通常は ‘git reflog’ を使用)、次にそれへの参照を作成
できます。 たとえば、 ‘HEAD’ が参照した最後の2つのコミットを確認するには
、以下のいずれかのコマンドを使用できます:

     $ git reflog -2 HEAD # or
     $ git log -g -2 HEAD

ARGUMENT DISAMBIGUATION(引数の曖昧性解消)
*****************************************

与えられた引数が1つだけで、それが ‘--’ ではない場合(例: ‘git checkout
abc’)や、引数が有効な ‘<tree-ish>’ (例:ブランチ ‘abc’ が存在する)や、有
効な ‘<pathspec>’ (たとえば、 "abc" という名前のファイルまたはディレクト
リが存在する)な場合、Gitは通常、明確にするように求めます。ただし、ブラン
チのチェックアウトは非常に一般的な操作であるため、このような状況では、
‘git checkout abc’ は "abc" を ‘<tree-ish>’ と見なします。これらのパスを
インデックスからチェックアウトする場合は、 ‘git checkout -- <pathspec>’
を使用します。

EXAMPLES
********

  1. 以下のシーケンスは、 ‘master’ ブランチをチェックアウトし、
     ‘Makefile’ のリビジョンを2つ戻し、誤って ‘hello.c’ を削除したので、
     ‘hello.c’ をインデックスから取得します。

          $ git checkout master             (1)
          $ git checkout master~2 Makefile  (2)
          $ rm -f hello.c
          $ git checkout hello.c            (3)

     See (1).
          ブランチを切り替えます

     See (2).
          別のコミットからファイルを取り出します

     See (3).
          インデックスから ‘hello.c’ を復元します

          あなたがインデックスから「すべての」Cソースファイルをチェック
          アウトしたい場合は、以下のように言うことができます

               $ git checkout -- '*.c'

          ‘*.c’ を囲む引用符に注意してください。 ファイル ‘hello.c’ も、
          作業ツリーに存在していなくてもチェックアウトされます。これは、
          (引用符で囲む事で作業ツリーに対してシェル展開するのではなくて
          )ファイルグロブがインデックスのエントリを照合するために使用さ
          れるためです。

          ‘hello.c’ という名前の不幸なブランチがある場合、このステップは
          そのブランチに切り替えるための指示として混乱を産みます。あなた
          は代わりに以下のように書く必要があります。

               $ git checkout -- hello.c

  2. 間違ったブランチで作業した後、正しいブランチへの切り替えは以下を使
     用して行います:

          $ git checkout mytopic

     ただし、あなたの「間違った」ブランチと正しい ‘mytopic’ ブランチは、
     ローカルで変更したファイルで異なる場合があります。その場合、上記の
     チェックアウトは以下のように失敗します:

          $ git checkout mytopic
          error: You have local changes to 'frotz'; not switching branches.

     コマンドに ‘-m’ フラグを指定すると、3方向のマージを試みます:

          $ git checkout -m mytopic
          Auto-merging frotz

     この3方向マージの後、ローカルの変更はインデックスファイルに登録され
     ないため、 ‘git diff’ は、新しいブランチの先端以降に行った変更を表
     示します。

  3. ‘-m’ オプションを使用してブランチを切り替えるときにマージの競合が発
     生すると、以下のように表示されます:

          $ git checkout -m mytopic
          Auto-merging frotz
          ERROR: Merge conflict in frotz
          fatal: merge program failed

     この時点で、 ‘git diff’ は、前の例のようにきれいにマージされた変更
     と、競合するファイルの変更を示しています。 競合を編集して解決し、通
     常どおり ‘git add’ で解決済みのマークを付けます。

          $ edit frotz
          $ git add frotz

SEE ALSO
********

git-switch(1), git-restore(1)

GIT
***

Part of the git(1) suite

Name
****

git-cherry-pick — いくつかの既存のコミットによって導入された変更を適用し
ます

Synopsis
********

     git cherry-pick [–edit] [-n] [-m parent-number] [-s] [-x] [–ff]
                       [-S[<keyid>]] <commit>…
     git cherry-pick (–continue | –skip | –abort | –quit)

DESCRIPTION
***********

1つ以上の既存のコミットが与えられた場合、それぞれが導入する変更を適用し
、それぞれに新しいコミットを記録します。 これには、作業ツリーがクリーン
(HEADコミットが編集中でない)である必要があります。

   変更を適用する方法が明確でない場合、以下のようになります:

  1. 現在のブランチと ‘HEAD’ ポインタは、正常に行われた最後のコミットに
     留まります。

  2. ‘CHERRY_PICK_HEAD’ refは、適用が難しい変更を導入したコミットを指す
     ように設定されています。

  3. 変更がクリーンに適用されたパスは、インデックスファイルとあなたの作
     業ツリーの両方で更新されます。

  4. 競合するパスの場合、git-merge(1) の「TRUE MERGE」セクションで説明さ
     れているように、インデックスファイルには最大3つのバージョンが記録さ
     れます。 作業ツリーファイルには、通常の競合マーカー ‘<<<<<<<’ およ
     び ‘>>>>>>>’ で囲まれた競合の説明が含まれます。

  5. その他の変更は行われません。

   このような競合を解決するための幾つかのヒントについては、 git-merge(1)
を参照してください。

OPTIONS
*******

<commit>…
     チェリーピックにコミットします。 コミットを綴る方法のより完全なリス
     トについては、 gitrevisions(7) を参照してください。 コミットのセッ
     トを渡すことはできますが、デフォルトでは、 ‘--no-walk’ オプションが
     指定されているかのように振る舞い、トラバーサルは実行されません。
     git-rev-list(1) を参照してください。 範囲を指定すると、すべての
     ‘<commit>...’ 引数が単一のリビジョンウォークに送られることに注意し
     てください(‘maint master..next’ を使用するk後述する例を参照してくだ
     さい)。

‘-e’
‘--edit’
     このオプションを使用すると、 ‘git cherry-pick’ を使用してコミットす
     る前にコミットメッセージを編集できます。

‘--cleanup=<mode>’
     このオプションは、コミットメッセージがコミット機構に渡される前にど
     のようにクリーンアップされるかを決定します。 詳細については、
     git-commit(1) を参照してください。 特に、 ‘<mode>’ に ‘scissors’ の
     値が指定されている場合、競合が発生した場合に渡される前に、切り取り
     線 が ‘MERGE_MSG’ に追加されます。

‘-x’
     コミットを記録するときは、"(cherry picked from commit …)" という行
     を元のコミットメッセージに追加して、この変更がどのコミットからチェ
     リーピックされたかを示します。 これは、競合のないチェリーピックに対
     してのみ行われます。 情報が受信者にとって役に立たないため、プライベ
     ートブランチからチェリーピッキングをしている場合は、このオプション
     を使用しないでください。 一方、公開されている2つのブランチ間を選択
     している場合(たとえば、開発ブランチからの古いリリースのメンテナンス
     ブランチへの修正をバックポートする場合)、この情報を追加すると便利で
     す。

‘-r’
     以前は、コマンドはデフォルトで上記の ‘-x’ を実行し、 ‘-r’ はそれを
     無効にすることでした。 現在、デフォルトでは ‘-x’ を実行しないため、
     このオプションは何もしません。

‘-m parent-number’
‘--mainline parent-number’
     マージのどちら側をメインラインと見なすべきかわからないため、通常、
     マージを選択することはできません。 このオプションは、メインラインの
     親番号(1から始まる)を指定し、cherry-pickが指定された親に関連する変
     更を再実行(replay)できるようにします。

‘-n’
‘--no-commit’
     通常、コマンドはコミットのシーケンスを自動的に作成します。 このフラ
     グは、コミットを行わずに、名前付きの各コミットを作業ツリーとインデ
     ックスにチェリーピックするために必要な変更を適用します。 さらに、こ
     のオプションを使用する場合、インデックスはHEADコミットと一致する必
     要はありません。 チェリーピックは、インデックスの開始状態に対して行
     われます。

     これは、インデックスへの複数のコミットの効果を連続して選択する場合
     に便利です。

‘-s’
‘--signoff’
     コミットメッセージの最後に ‘Signed-off-by’ トレーラーを追加します。
     詳細については、git-commit(1) のsignoffオプションを参照してください
     。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     GPG署名コミット。 ‘keyid’ 引数はオプションであり、デフォルトでコミ
     ッターIDになります。 指定する場合は、スペースなしでオプションに固定
     する必要があります。 ‘--no-gpg-sign’ は、 ‘commit.gpgSign’ 構成変数
     と以前の ‘--gpg-sign’ の両方を打ち消すのに役立ちます。

‘--ff’
     現在のHEADが、チェリーピックされたコミットの親と同じである場合、こ
     のコミットへの早送り(fast forward)が実行されます。

‘--allow-empty’
     デフォルトでは、空のコミットのチェリーピックは失敗し、 ‘git commit
     --allow-empty’ の明示的な呼び出しが必要であることを示します。 この
     オプションはその動作をオーバーライドし、空のコミットをチェリーピッ
     クに自動的に保存できるようにします。 ‘--ff’ が有効な場合、「早送り
     」要件を満たす空のコミットは、このオプションがなくても保持されるこ
     とに注意してください。 注意: また、このオプションを使用すると、最初
     は空だったコミット(つまり、親と同じツリーを記録していたコミット)だ
     けが保持されることに注意してください。以前のコミットのために空にさ
     れたコミットはドロップされます。 これらのコミットを強制的に含めるに
     は、 ‘--keep-redundant-commits’ を使用します。

‘--allow-empty-message’
     デフォルトでは、空のメッセージでコミットをチェリーピックすると失敗
     します。 このオプションはその動作をオーバーライドし、空のメッセージ
     を含むコミットをチェリーピックできるようにします。

‘--keep-redundant-commits’
     チェリーピックされているコミットが現在の履歴にすでにあるコミットと
     重複している場合、そのコミットは空になります。 デフォルトでは、これ
     らの冗長なコミットにより ‘cherry-pick’ が停止するため、ユーザーはコ
     ミットを調べることができます。 このオプションはその動作をオーバーラ
     イドし、空のコミットオブジェクトを作成します。 ‘--allow-empty’ の指
     定含んでいます。

‘--strategy=<strategy>’
     指定のマージ戦略を使用します。複数回指定できません。 詳細については
     、 git-merge(1) の「MERGE STRATEGIES」セクションを参照してください
     。

‘-X<option>’
‘--strategy-option=<option>’
     マージ戦略固有のオプションをマージ戦略に渡します。 詳細については、
     git-merge(1) を参照してください。

‘--rerere-autoupdate’
‘--no-rerere-autoupdate’
     可能であれば、rerereメカニズムが自動競合解決の結果でインデックスを
     更新できるようにします。

SEQUENCER SUBCOMMANDS
*********************

‘--continue’
     ‘.git/sequencer’ の情報を使用して、進行中の操作の続行を行います。失
     敗したcherry-pickまたはrevertの競合を解決した後、続行するために使用
     できます。

‘--skip’
     現在のコミットをスキップして、残りのシーケンスを続行します。

‘--quit’
     進行中の今回の操作を忘れてください。チェリーピックまたはrevertに失
     敗した後、シーケンサーの状態をクリアするために使用できます。

‘--abort’
     操作をキャンセルして、シーケンス操作前の状態に戻ります。

EXAMPLES
********

‘git cherry-pick master’
     masterブランチの先端でコミットによって導入された変更を適用し、その
     変更で新しいコミットを作成します。

‘git cherry-pick ..master’
‘git cherry-pick ^HEAD master’
     masterの祖先であるがHEADの祖先ではないすべてのコミットによって導入
     された変更を適用して、新しいコミットを生成します。

‘git cherry-pick maint next ^master’
‘git cherry-pick maint master..next’
     maintまたはnextの祖先であるが、masterまたはその祖先のいずれでもない
     すべてのコミットによって導入された変更を適用します。 後者は ‘maint’
     と ‘master’ と ‘next’ の間のすべてを意味するものではないことに注意
     してください。 具体的には、 ‘master’ に含まれている場合は ‘maint’ は
     使用されません。

‘git cherry-pick master~4 master~2’
     masterが指す最後から5番目と3番目のコミットによって導入された変更を
     適用し、これらの変更を使用して2つの新しいコミットを作成します。

‘git cherry-pick -n master~1 next’
     作業ツリーとインデックスに、masterが指す最後から2番目のコミットと
     nextが指す最後のコミットによって導入された変更を適用しますが、これ
     らの変更でコミットを作成しないでください。

‘git cherry-pick --ff ..next’
     履歴が線形で、HEADがnextの祖先である場合は、作業ツリーを更新し、
     HEADポインターをnextに一致するように進めます。 それ以外の場合は、次
     のコミットで導入された変更を現在のブランチに適用し、新しい変更ごと
     に新しいコミットを作成します。

‘git rev-list --reverse master -- README | git cherry-pick -n --stdin’
     READMEにアクセスしたmasterブランチのすべてのコミットによって導入さ
     れた変更を作業ツリーとインデックスに適用します。これにより、結果を
     検査して、必要に応じて1つの新しいコミットにすることができます。

   以下のシーケンスは、パッチのバックポートを試み、パッチが適用されるコ
ードが大幅に変更されたためにベイルアウト(脱出; git reste)してから、再試
行します。今度は、コンテキスト行の一致にさらに注意を払います。

     $ git cherry-pick topic^             (1)
     $ git diff                           (2)
     $ git reset --merge ORIG_HEAD        (3)
     $ git cherry-pick -Xpatience topic^  (4)

See (1).
     ‘git show topic^’ で表示される変更を適用します。 この例では、パッチ
     が適切に適用されないため、競合に関する情報がインデックスと作業ツリ
     ーに書き込まれ、新しいコミット結果はありません。

See (2).
     調停する変更を要約します

See (3).
     チェリーピックをキャンセルします。 つまり、作業ツリーで行ったローカ
     ルの変更を保持したまま、チェリーピック前の状態に戻ります。

See (4).
     より多くの時間のを費やして、 ‘topic^’ によって導入された変更を再度
     適用し、コンテキスト行の誤った一致に基づく間違いを避けようと試みま
     す。

SEE ALSO
********

git-revert(1)

GIT
***

Part of the git(1) suite

Name
****

git-cherry — アップストリームにまだ適用されていないコミットを検索する

Synopsis
********

     git cherry [-v] [<upstream> [<head> [<limit>]]]

DESCRIPTION
***********

‘<head>..<upstream>’ に ‘<limit>..<head>’ の範囲と同等のコミットがあるか
どうかを検査(determine)します。

   等価性テストは、空白と行番号を削除した後のdiffに基づいています。した
がって、git-cherry は、 git-cherry-pick(1) または git-am(1) または
git-rebase(1) を使用してコミットが「コピー」された時に検出します。

   ‘<limit>..<head>’ の範囲のすべてのコミットのSHA1を出力し、 <upstream>
に同等のものがあるコミットの場合は ‘-’ を接頭辞として付け、そうでないコ
ミットの場合は ‘+’ を接頭辞として付けます。

OPTIONS
*******

‘-v’
     SHA1の横にコミット件名(commit subject)を表示します。

<upstream>
     同等のコミットを検索するためのアップストリームブランチ。デフォルト
     はHEADのアップストリームブランチです。

<head>
     作業ブランチ。デフォルトはHEADです。

<limit>
     コミットをlimitまで(limitを含む)報告しないでください。

EXAMPLES
********

Patch workflows
===============

git-cherryは、パッチベースのワークフロー(gitworkflows(7) 参照)で頻繁に使
用され、一連のパッチがアップストリームメンテナによって適用されているかど
うかを判断します。このようなワークフローでは、以下のようなトピックブラン
チを作成して送信できます:

     $ git checkout -b topic origin/master
     # work and create some commits
     $ git format-patch origin/master
     $ git send-email ... 00*

   後で、あなたは(まだ ‘topic’ に居る時に、)次のように言うことで、変更が
適用されたかどうかを確認できます:

     $ git fetch  # update your notion of origin/master
     $ git cherry -v

Concrete example
================

トピックが3つのコミットで構成され、メンテナがそのうちの2つを適用した状況
では、状況は以下のようになります:

     $ git log --graph --oneline --decorate --boundary origin/master...topic
     * 7654321 (origin/master) upstream tip commit
     [... snip some other commits ...]
     * cccc111 cherry-pick of C
     * aaaa111 cherry-pick of A
     [... snip a lot more that has happened ...]
     | * cccc000 (topic) commit C
     | * bbbb000 commit B
     | * aaaa000 commit A
     |/
     o 1234567 branch point

   このような場合、git-cherryはまだ適用されていないモノの簡潔な要約を示
します:

     $ git cherry origin/master topic
     - cccc000... commit C
     + bbbb000... commit B
     - aaaa000... commit A

   ここで、(‘-’ でマークされている)コミットAとCは、 ‘origin/master’ のト
ップでリベースすると、トピックブランチから削除できますが、（‘+’ でマーク
されている)コミットBは ‘origin/master’ にapplyするために送信されるために
、まだ保持しつづける必要があります。

Using a limit
=============

オプションの <limit> は、あなたのトピックがアップストリームにない他の作
業に基づいている場合に役立ちます。前の例を拡張すると、これは以下のように
なります:

     $ git log --graph --oneline --decorate --boundary origin/master...topic
     * 7654321 (origin/master) upstream tip commit
     [... snip some other commits ...]
     * cccc111 cherry-pick of C
     * aaaa111 cherry-pick of A
     [... snip a lot more that has happened ...]
     | * cccc000 (topic) commit C
     | * bbbb000 commit B
     | * aaaa000 commit A
     | * 0000fff (base) unpublished stuff F
     [... snip ...]
     | * 0000aaa unpublished stuff A
     |/
     o 1234567 merge-base between upstream and topic

   制限として ‘base’ を指定することで、 ‘base’ と ‘topic’ の間のコミット
をリストすることを回避できます:

     $ git cherry origin/master topic base
     - cccc000... commit C
     + bbbb000... commit B
     - aaaa000... commit A

SEE ALSO
********

git-patch-id(1)

GIT
***

Part of the git(1) suite

Name
****

git-citool — git-commitのグラフィカルな代替手段

Synopsis
********

     git citool

DESCRIPTION
***********

Tcl/Tkベースのグラフィカルインターフェイス。変更されたファイルを確認し、
それらをインデックスにステージングし、コミットメッセージを入力して、新し
いコミットを現在のブランチに記録します。このインターフェースは、インタラ
クティブ性の低い’git commit’プログラムの代替手段です。

   ’git citool’は実際には‘git gui citool‘の標準エイリアスです。詳細につ
いては、git-gui(1)を参照してください。

GIT
***

Part of the git(1) suite

Name
****

git-clean — 作業ツリーから追跡されていないファイルを削除する

Synopsis
********

     git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [–] <path>…

DESCRIPTION
***********

現在のディレクトリから開始して、バージョン管理下にないファイルを再帰的に
削除することにより、作業ツリーをクリーンにします。

   通常、Gitが追跡していないファイルのみが削除されますが、 ‘-x’ オプショ
ンが指定されている場合、無視されたファイル(ignored files)も削除されます
。これは、たとえば、ビルドでの生成物全てを削除するのに役立ちます。

   オプションで、任意の数の ‘<path> ...’ 引数を指定すると、それらのパス
のみが影響を受けます。

OPTIONS
*******

‘-d’
     通常、<path> が指定されていない場合、削除が多すぎるのを避けるために
     、git cleanは追跡されていないディレクトリ内には再帰処理しません。
     ‘-d’ を指定すると、そのようなディレクトリ内でも再帰的に処理します。
     パスが指定されている場合、 ‘-d’ は関係ありません。(‘--force’ で言及
     されているネストされたgitディレクトリを除く、)指定されたパスに一致
     するすべての追跡されていないファイルは削除されます。

‘-f’
‘--force’
     Git構成変数 clean.requireForce が false に設定されてい無い場合、「
     git clean」は、 ‘-f’ または ‘-i’ が指定されていない限り、ファイルま
     たはディレクトリの削除を拒否します。 2つ目の ‘-f’ が指定されていな
     い限り、Gitは追跡されていないネストされたgitリポジトリ(.gitサブディ
     レクトリを持つディレクトリ)の変更を拒否します。

‘-i’
‘--interactive’
     何が行われるを示し、ファイルを対話的にクリーンアップします。 詳細は
     「Interactive mode」を参照してください。

‘-n’
‘--dry-run’
     実際には何も削除せず、何が行われるかを表示します。

‘-q’
‘--quiet’
     静かにして、エラーのみを報告し、正常に削除されたファイルは報告しな
     いでください。

‘-e <pattern>’
‘--exclude=<pattern>’
     標準の無視ルールに加えて、指定の除外パターンを使用します
     (gitignore(5) 参照)。

‘-x’
     標準の無視ルール(gitignore(5) 参照)を使用しないでください。ただし、
     コマンドラインから ‘-e’ オプションを指定して指定された無視ルールは
     使用してください。これにより、ビルド生成物を含む、追跡されていない
     すべてのファイルを削除できます。これを使用して（おそらく「git
     restore」または「git reset」と組み合わせて）、ビルドをテストするた
     めのクリーンな、元の作業ディレクトリを作成できます。

‘-X’
     Gitによって無視されたファイルのみを削除します。これは、すべてを最初
     から再構築するのに役立つ場合がありますが、手動で作成したファイルは
     保持します。

Interactive mode
****************

コマンドがinteractive modeに入ると、クリーンアップするファイルとディレク
トリが表示され、インタラクティブコマンドループに入ります。

   コマンドループは、使用可能なサブコマンドのリストを表示し、「Whatnow>
」というプロンプトを表示します。一般に、プロンプトが単一の「>」で終わる
場合、以下のように、選択肢の1つだけを選択し、ENTERキーを押します:

         *** Commands ***
             1: clean                2: filter by pattern    3: select by numbers
             4: ask each             5: quit                 6: help
         What now> 1

   選択が一意である限り、上記は「c」または「clean」と打ち込む事もできま
す。

   メインコマンドループには6つのサブコマンドがあります。

clean
     ファイルとディレクトリのクリーニングを開始して、終了(quit)します。

filter by pattern
     これにより、削除するファイルとディレクトリが表示され、「Input
     ignore patterns>>」(入力無視パターン)プロンプトが表示されます。スペ
     ースで区切られたパターンを入力して、ファイルとディレクトリを削除か
     ら除外できます。 例えば。 「* .c * .h」は、「.c」と「.h」で終わるフ
     ァイルを削除から除外します。そして、結果に満足したら、ENTER を押し
     てメインメニューに戻ります。

select by numbers
     これにより、削除するファイルとディレクトリが表示され、「Select
     items to delete>>」(削除するアイテムを選択)というプロンプトが表示さ
     れます。プロンプトがこのように二重の「>>」で終わる場合、空白または
     コンマで連結して複数の選択を行うことができます。また、あなたは範囲
     を伝えることができます。 例えば「2-57,9」でリストから2,3,4,5,7,9を
     選択します。範囲の2番目の数値を省略すると、残りのすべての項目が選択
     されます。 例えば「7-」はリストから7,8,9を選択します。「*」dで全て
     を選択できます。そして、結果に満足したら、ENTER を押してメインメニ
     ューに戻ります。

ask each
     これはクリーニングが始まると、アイテムを削除するために一つずつ確認
     する必要があります。この操作は、上記の2つのアクションほど効率的では
     ないことに注意してください。

quit
     これにより、クリーニングを行わずに終了(quit)できます。

help
     git-cleanの対話的な簡単な使用法を示します。

SEE ALSO
********

gitignore(5)

GIT
***

Part of the git(1) suite

Name
****

git-clone — リポジトリを新しいディレクトリにクローン(複製)します

Synopsis
********

     git clone [–template=<template_directory>]
               [-l] [-s] [–no-hardlinks] [-q] [-n] [–bare] [–mirror]
               [-o <name>] [-b <name>] [-u <upload-pack>] [–reference <repository>]
               [–dissociate] [–separate-git-dir <git dir>]
               [–depth <depth>] [–[no-]single-branch] [–no-tags]
               [–recurse-submodules[=<pathspec>]] [–[no-]shallow-submodules]
               [–[no-]remote-submodules] [–jobs <n>] [–sparse] [–[no-]reject-shallow]
               [–filter=<filter>] [–] <repository>
               [<directory>]

DESCRIPTION
***********

リポジトリを新しく作成されたディレクトリにクローン(clone;複製)し、複製さ
れたリポジトリ内の各ブランチのリモート追跡ブランチを作成し(‘git branch
--remotes’ を使用して表示できます)、複製されたリポジトリの現在アクティブ
なブランチからフォークされた初期ブランチを作成してチェックアウトします。

   クローン後、引数のない ‘git fetch’ は、すべてのリモート追跡ブランチを
更新し、加えて、引数のない ‘git pull’ は、存在する場合、リモートの
masterブランチを現在のmasterブランチにマージします（これは、
‘--single-branch’ が指定されている場合は当てはまりません。以下参照)。

   このデフォルト設定は、 ‘refs/remotes/origin’ の下にリモートブランチヘ
ッドへの参照を作成し、‘remote.origin.url’ と ‘remote.origin.fetch’ 設定
変数を初期化することによって実現されます。

OPTIONS
*******

‘-l’
‘--local’
     複製元のリポジトリがローカルマシン上にある場合、このフラグは通常の
     「Git対応」転送メカニズムをバイパスし、オブジェクトおよびrefsディレ
     クトリの下にあるHEADおよびすべてのコピーを作成することでリポジトリ
     を複製します。 ‘.git/objects/’ ディレクトリの下のファイルは、可能な
     場合はスペースを節約するためにハードリンクされています。

     リポジトリがローカルパス(例: ‘/path/to/repo’)として指定されている場
     合、これがデフォルトであり、 ‘--local’ は基本的に何も操作しません
     (no-op)です。 リポジトリがURLとして指定されている場合、このフラグは
     無視されます(ローカル最適化は使用されません)。 ‘--no-local’ を指定
     すると、 ‘/path/to/repo’ が指定されたときデフォルトが上書きされ、代
     わりに通常のGit転送が使用されます。

          *Note*

          この操作は、 ‘src’ を変更しながら ‘cp -r src dst’ を実行するの
          と同様に、ソースリポジトリへの同時変更と競合する可能性がありま
          す。

‘--no-hardlinks’
     ハードリンクを使用する代わりに、ローカルファイルシステム上のリポジ
     トリからのクローン作成プロセスで、ファイルを ‘.git/objects’ ディレ
     クトリの下にコピーするように強制します。 これは、リポジトリのバック
     アップを作成しようとしている場合に望ましい場合があります。

‘-s’
‘--shared’
     クローンを作成するリポジトリがローカルマシン上にある場合、ハードリ
     ンクを使用する代わりに、オブジェクトをソースリポジトリと共有するよ
     うに ‘.git/objects/info/alternates’ を自動的に設定します。 結果のリ
     ポジトリは、独自のオブジェクトなしで開始されます。

          *Note*

          これは危険な操作になり得ます。あなたが、それが何をするのか理解
          していない限り、使用してはいけません。 このオプションを使用し
          てリポジトリのクローンを作成してから、ソースリポジトリ内のブラ
          ンチを削除する(または既存のコミットを参照しないようにする他の
          Gitコマンドを使用する)と、一部のオブジェクトが参照されなくなる
          (unreferenced)(または宙ぶらりん(dangling)になる)可能性がありま
          す。 そうしたオブジェクトは、 ‘git maintenance run --auto’ を
          自動的に呼び出す通常のGit操作(‘git commit’ など)によって削除さ
          れる場合があります(git-maintenance(1) 参照)。 これらのオブジェ
          クトが削除され、クローンされたリポジトリーによって参照された場
          合、クローンされたリポジトリーは破損します。

     注意: ‘--shared’ でクローンされたリポジトリで ‘--local’ オプション
     なしで ‘git repack’ を実行すると、オブジェクトがソースリポジトリか
     らクローンされたリポジトリのパックにコピーされ、 ‘clone --shared’ に
     よるディスクスペースの節約はなくなります。 ただし、デフォルトで
     ‘--local’ オプションを使用する ‘git gc’ を実行するのは安全です。

     ‘--shared’ でクローンされたリポジトリのソースリポジトリへの依存関係
     を解消したい場合、 ‘git repack -a’ を実行するだけで、すべてのオブジ
     ェクトをソースリポジトリから、クローンされたリポジトリのパックにコ
     ピーできます。

‘--reference[-if-able] <repository>’
     参照リポジトリがローカルマシン上にある場合は、参照リポジトリからオ
     ブジェクトを取得するように ‘.git/objects/info/alternates’ を自動的
     に設定します。 既存のリポジトリをalternateとして使用すると、クロー
     ンされるリポジトリからコピーする必要のあるオブジェクトが少なくなり
     、ネットワークとローカルのストレージコストが削減されます。
     ‘--reference-if-able’ を使用すると、存在しないディレクトリはクロー
     ンを中断する代わりに警告を出してスキップします。

          *Note*

          ‘--shared’ オプションと ‘--dissociate’ オプションについては「
          NOTE」を参照してください。

‘--dissociate’
     ネットワーク転送を減らすために ‘--reference’ オプションで指定された
     参照リポジトリからオブジェクトを借用しクローン作成後に、借用したオ
     ブジェクトの必要なローカルコピーを作成し、借用を停止(stop)します。
     このオプションは、すでに他のリポジトリからオブジェクトを借りている
     リポジトリからローカルにクローンを作成するときにも使用できます—新し
     いリポジトリは同一のリポジトリからオブジェクトを借りますが、このオ
     プションを使用して借用を停止できます。

‘-q’
‘--quiet’
     静かにします。進行状況は標準エラーストリームに報告されません。

‘-v’
‘--verbose’
     賑やかにします。標準エラーストリームへの進行状況のレポートには影響
     しません。

‘--progress’
     ‘--quiet’ が指定されていない限り、進行状況は、端末に接続されている
     場合、デフォルトで標準エラーストリームに報告されます。 このフラグは
     、標準エラーストリームが端末に送信されていない場合でも、進行状況を
     強制します。

‘--server-option=<option>’
     プロトコルバージョン2を使用して通信する場合、指定の文字列をサーバー
     に送信します。指定の文字列には、NULまたはLF文字を含めることはできま
     せん。 不明なオプションを含むサーバーオプションのサーバー処理は、サ
     ーバー固有です。 複数の ‘--server-option=<option>’ が指定されている
     場合、それらはすべてコマンドラインにリストされている順序で相手側に
     送信されます。

‘-n’
‘--no-checkout’
     クローンの完了後、HEADのチェックアウトは実行されません。

‘--[no-]reject-shallow’
     ソースリポジトリが浅い(shallow)リポジトリの場合は失敗します。
     _clone.rejectShallow_ 構成変数を使用して、デフォルトを指定できます
     。

‘--bare’
     「ベア」(bare=裸の)Gitリポジトリを作成します。 つまり、
     ‘<directory>’ を作成して管理ファイルを ‘<directory>/.git’ に配置す
     る代わりに、 ‘<directory>’ 自体を ‘$GIT_DIR’ にします。 作業ツリー
     をチェックアウトする場所がないため、これは明らかに ‘--no-checkout’
     を意味します。 また、リモートのブランチヘッドは、
     ‘refs/remotes/origin/’ にマッピングせずに、対応するローカルブランチ
     ヘッドに直接コピーされます。 このオプションを使用すると、リモート追
     跡ブランチも関連する構成変数も作成されません。

‘--sparse’
     (sparse:まばらなの意)作業ディレクトリがリポジトリのルートにあるファ
     イルのみで開始するように、sparse-checkoutファイルを初期化します。
     sparse-checkoutファイルは、必要に応じて作業ディレクトリを拡張するよ
     うに変更できます。

‘--filter=<filter-spec>’
     部分クローン(partial clone)機能を使用して、サーバーが特定のオブジェ
     クトフィルターに従って到達可能なオブジェクトのサブセットを送信する
     ように要求します。 ‘--filter’ を使用する場合、提供された
     ‘<filter-spec>’ が部分クローンフィルターに使用されます。 たとえば、
     ‘--filter=blob:none’ は、Gitで必要になるまで、すべてのブロブ(ファイ
     ルの内容)を除外します。 また、 ‘--filter=blob:limit=<size>’ は、少
     なくとも ‘<size>’ のサイズのすべてのブロブを除外します。 フィルタ仕
     様の詳細については、 git-rev-list(1) の ‘--filter’ オプションを参照
     してください。

‘--mirror’
     ソースリポジトリのミラーを設定します。 これは ‘--bare’ を意味します
     。 ‘--bare’ と比較して、 ‘--mirror’ は、ソースのローカルブランチを
     ターゲットのローカルブランチにマップするだけでなく、すべての参照(リ
     モート追跡ブランチ、noteなどを含む)をマップし、以下のような
     refspec構成をセットアップします。 これらのすべての参照は、ターゲッ
     トリポジトリ内の ‘git remote update’ によって上書きされます。

‘-o <name>’
‘--origin <name>’
     リモート名 ‘origin’ を使用してアップストリームリポジトリを追跡する
     代わりに、‘<name>’ を使用します。 構成(config)の
     ‘clone.defaultRemoteName’ をオーバーライドします。

‘-b <name>’
‘--branch <name>’
     新しく作成されたHEADを、複製されたリポジトリのHEADが指すブランチに
     ポイントする代わりに、代わりに ‘<name>’ ブランチをポイントします。
     非ベアリポジトリでは、これはチェックアウトされるブランチです。
     ‘--branch’ はタグを取得し、結果のリポジトリでそのコミット時にHEADを
     切り離す(detach)こともできます。

‘-u <upload-pack>’
‘--upload-pack <upload-pack>’
     これが指定され、クローンを作成するリポジトリにssh経由でアクセスする
     場合、これは、通信相手側(the other end)で実行されるコマンドのデフォ
     ルト以外のパスを指定します。

‘--template=<template_directory>’
     テンプレートを使用するディレクトリを指定します。 (git-init(1) の「
     TEMPLATE DIRECTORY」セクションを参照してください。)

‘-c <key>=<value>’
‘--config <key>=<value>’
     新しく作成されたリポジトリに構成変数を設定します。 これは、リポジト
     リが初期化された直後または、リモート履歴がフェッチされる前または、
     ファイルがチェックアウトされる前に有効になります。 キーは、
     git-config(1) で期待されるものと同じ形式です(例: ‘core.eol=true’)。
     同じキーに複数値が指定されている場合、各値は構成ファイルに書き込ま
     れます。 これにより、たとえば、originのリモートにフェッチrefspecを
     追加しても安全になります。

     現在の実装の制限により、一部の構成変数は、最初のフェッチとチェック
     アウトが完了するまで有効になりません。 有効にならないことがわかって
     いる構成変数は、 ‘remote.<name>.mirror’ と ‘remote.<name>.tagOpt’ で
     す。 代わりに、対応する ‘--mirror’ および ‘--no-tags’ オプションを
     使用してください。

‘--depth <depth>’
     指定されたコミット数に切り捨てられた履歴を持つ「浅い」クローン
     (shallow clone)を作成します。 すべてのブランチの先端近くの履歴をフ
     ェッチするために ‘--no-single-branch’ が指定されていない限り、
     ‘--single-branch’ を意味します。 サブモジュールを浅くクローンする場
     合は、 ‘--shallow-submodules’ も渡します。

‘--shallow-since=<date>’
     指定した日時以降の履歴を持つ浅いクローン(shallow clone)を作成します
     。

‘--shallow-exclude=<revision>’
     指定のリモートブランチまたはタグから到達可能なコミットを除外して、
     履歴を持つ浅いクローン(shallow clone)を作成します。 このオプション
     は複数回指定できます。

‘--[no-]single-branch’
     ‘--branch’ オプションで指定された、またはリモートのプライマリブラン
     チの ‘HEAD’ が指す単一のブランチの先端につながる履歴のみをクローン
     します。 結果のリポジトリにさらにフェッチすると、このオプションが最
     初のクローン作成に使用されたブランチのリモート追跡ブランチのみが更
     新されます。 ‘--single-branch’ クローンが作成されたときに、リモート
     のHEADがどのブランチも指さなかった場合、リモート追跡ブランチは作成
     されません。

‘--no-tags’
     タグのクローンを作成せず、構成に ‘remote.<remote>.tagOpt=--no-tags’
     を設定して、今後の ‘git pull’ および ‘git fetch’ 操作がタグに従わな
     いようにします。 指定後も明示的なタグフェッチは引き続き機能します
     (git-fetch(1) 参照)。

     ‘--single-branch’ と組み合わせて使用すると、単一のクローンされたブ
     ランチ以外の参照なしでブランチをクローンおよび維持できます。 検索イ
     ンデックス作成のために、一部のリポジトリのデフォルトブランチの最小
     限のクローンを維持するので便利です。

‘--recurse-submodules[=<pathspec>]’
     クローンが作成されたら、提供されたパススペックに基づいてサブモジュ
     ールを初期化し、クローンを作成します。 パススペックが指定されていな
     い場合、すべてのサブモジュールが初期化され、クローン化されます。 こ
     のオプションは、複数のエントリで構成されるパススペックに対して複数
     回指定できます。 結果として得られるクローンには ‘submodule.active’
     が指定され、パス指定がない場合は ‘.’ (すべてのサブモジュールを意味
     します) が設定されます。

     サブモジュールは、デフォルト設定を使用して初期化およびクローン化さ
     れます。 これは、クローンが終了した直後に ‘git submodule update
     --init --recursive <pathspec>’ を実行するのと同じです。 クローンさ
     れたリポジトリに ワークツリー/チェックアウト がない場合(つまり、
     ‘--no-checkout’/‘-n’ または ‘--bare’ または ‘--mirror’ のいずれかが
     指定されている場合)、このオプションは無視されます。

‘--[no-]shallow-submodules’
     クローンされるすべてのサブモジュールは、深さが1の浅さののになります
     。

‘--[no-]remote-submodules’
     クローン化されるすべてのサブモジュールは、スーパープロジェクトの記
     録されたSHA-1ではなく、サブモジュールのリモート追跡ブランチのステー
     タスを使用してサブモジュールを更新します。 ‘--remote’ を ‘git
     submodule update’ に渡すのと同じです。

‘--separate-git-dir=<git dir>’
     クローンされたリポジトリを本来あるべき場所に配置する代わりに、クロ
     ーンされたリポジトリを指定されたディレクトリに配置し、そこへのファ
     イルシステムに依存しないGitシンボリックリンクを作成します。 その結
     果、Gitリポジトリを作業ツリーから分離できます。

‘-j <n>’
‘--jobs <n>’
     同時にフェッチするサブモジュールの数。 デフォルトは
     ‘submodule.fetchJobs’ オプションです。

<repository>
     クローンを作成する(場合によってはリモートの)リポジトリ。 リポジトリ
     の指定の詳細については、下記 GIT URLS セクションを参照してください
     。

<directory>
     クローンを作成する新しいディレクトリの名前。 ディレクトリが明示的に
     指定されていない場合は、ソースリポジトリの「人間味のある」
     (humanish)部分が使用されます(‘/path/to/repo.git’ の場合は ‘repo’ 、
     ‘host.xz:foo/.git’ の場合は ‘foo’ )。 既存のディレクトリへのクロー
     ン作成は、ディレクトリが空の場合にのみ許可されます。

GIT URLS
********

一般に、URLには、トランスポートプロトコル、リモートサーバーのアドレス、
およびリポジトリへのパスに関する情報が含まれています。トランスポートプロ
トコルによっては、一部の情報が欠落している場合があります。

   Gitはsshとgitとhttpとhttpsプロトコルをサポートします(さらにftpと
ftpsをフェッチに使用できますが、これは非効率的で非推奨です。使用しないで
ください)。

   ネイティブトランスポート(つまり、 git:// URL)は認証を行わないため、セ
キュリティで保護されていないネットワークでは注意して使用する必要がありま
す。

   以下の構文を使用できます:

   • ssh://[user@]host.xz[:port]/path/to/repo.git/

   • git://host.xz[:port]/path/to/repo.git/

   • http[s]://host.xz[:port]/path/to/repo.git/

   • ftp[s]://host.xz[:port]/path/to/repo.git/

   代替のscpのような構文をsshプロトコルで使用することもできます:

   • [user@]host.xz:path/to/repo.git/

   この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されま
す。これは、コロンを含むローカルパスを区別するのに役立ちます。たとえば、
ローカルパス ‘foo:bar’ を、絶対パスまたは ‘./foo:bar’ として指定して、
ssh url として誤って解釈されないようにすることができます。

   sshおよびgitプロトコルは、さらに ~username 拡張をサポートします:

   • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

   • git://host.xz[:port]/~[user]/path/to/repo.git/

   • [user@]host.xz:/~[user]/path/to/repo.git/

   Gitでもネイティブにサポートされているローカルリポジトリの場合、以下の
構文を使用できます:

   • /path/to/repo.git/

   • file:///path/to/repo.git/

   これらの2つの構文は、前者が ‘--local’ オプションを含むことを除いて、
ほとんど同等です。

   「git clone」と「git fetch」と「git pull」は、「git push」と違って適
切なバンドルファイルを受け入れます。 git-bundle(1) を参照してください。

   Gitが特定のトランスポートプロトコルを処理する方法を知らない場合、
Gitは _remote-<transport>_ リモートヘルパー(存在する場合)を使用しようと
します。リモートヘルパーを明示的に要求するには、以下の構文を使用できます
:

   • <transport>::<address>

   ここで、 <address> は、パス、サーバーとパス、または呼び出されている特
定のリモートヘルパーによって認識される任意のURLのような文字列です。詳細
については、 gitremote-helpers(7) を参照してください。

   同じ名前のリモートリポジトリが多数あり、それらに異なる形式を使用する
場合(あなたの使用するURLが機能するURLに書き換えられるように)、以下の形式
の構成セクションを作成できます:

             [url "<actual url base>"]
                     insteadOf = <other url base>

   例えば、以下のようになります:

             [url "git://git.host.xz/"]
                     insteadOf = host.xz:/path/to/
                     insteadOf = work:

   "work:repo.git" や "host.xz:/path/to/repo.git" のようなURLは、任意の
コンテキストで、"git://git.host.xz/repo.git" に書き換えられます。

   プッシュ専用のURLを書き換えたい場合は、以下の形式の構成セクションを作
成できます:

             [url "<actual url base>"]
                     pushInsteadOf = <other url base>

   例えば、以下のようになります:

             [url "ssh://example.org/"]
                     pushInsteadOf = git://example.org/

   "git://example.org/path/to/repo.git" のようなURLは、プッシュの場合は
"ssh://example.org/path/to/repo.git" に書き換えられますが、プルは引き続
き元のURLのままです。

EXAMPLES
********

   • アップストリームからのクローン:

          $ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
          $ cd my-linux
          $ make

   • チェックアウトせずに、現在のディレクトリから借用するローカルクロー
     ンを作成します:

          $ git clone -l -s -n . ../copy
          $ cd ../copy
          $ git show-branch

   • 既存のローカルディレクトリから借用しつつ、アップストリームからクロ
     ーンを作成します:

          $ git clone --reference /git/linux.git \
                  git://git.kernel.org/pub/scm/.../linux.git \
                  my-linux
          $ cd my-linux

   • 変更を公開するためのベア(bare)リポジトリを作成します:

          $ git clone --bare -l /home/proj/.git /pub/scm/proj.git

GIT
***

Part of the git(1) suite

Name
****

git-column — データを複数列表示する

Synopsis
********

     git column [–command=<name>] [–[raw-]mode=<mode>] [–width=<width>]
                  [–indent=<string>] [–nl=<string>] [–padding=<n>]

DESCRIPTION
***********

このコマンドは、標準入力の行を複数の列を持つテーブル(表)にフォーマットし
ます。各入力行は、テーブルの1つのセルを占有します。これは、出力を複数列
にフォーマットするために他のgitコマンドによって内部的に使用されます。

OPTIONS
*******

‘--command=<name>’
     構成変数 column.<name> とcolumn.ui を使用してレイアウトモードを探し
     ます。

‘--mode=<mode>’
     レイアウトモードを指定します。 git-config(1) のオプション構文につい
     ては、構成変数 column.ui を参照してください。

‘--raw-mode=<n>’
     ‘--mode’ と同じですが、数値としてエンコードされたモードを使用します
     。これは主に、レイアウトモードをすでにパースしている他のコマンドに
     よって使用されます。

‘--width=<width>’
     端末幅を指定します。デフォルトでは、「git column」は端末の幅を検出
     するか、検出できない場合は80にフォールバックします。

‘--indent=<string>’
     各行の先頭に印刷される文字列。

‘--nl=<string>’
     改行文字を含む、各行の終わりに印刷される文字列。

‘--padding=<N>’
     列間のスペースの数。 デフォルトでは1つの空白。

EXAMPLES
********

データを複数列(columns)でフォーマット:

     $ seq 1 24 | git column --mode=column --padding=5
     1      4      7      10     13     16     19     22
     2      5      8      11     14     17     20     23
     3      6      9      12     15     18     21     24

   データを複数行(rows)でフォーマット:

     $ seq 1 21 | git column --mode=row --padding=5
     1      2      3      4      5      6      7
     8      9      10     11     12     13     14
     15     16     17     18     19     20     21

   列幅が等しくないテーブルにいくつかのタグをリストします:

     $ git tag --list 'v2.4.*' --column=row,dense
     v2.4.0  v2.4.0-rc0  v2.4.0-rc1  v2.4.0-rc2  v2.4.0-rc3
     v2.4.1  v2.4.10     v2.4.11     v2.4.12     v2.4.2
     v2.4.3  v2.4.4      v2.4.5      v2.4.6      v2.4.7
     v2.4.8  v2.4.9

GIT
***

Part of the git(1) suite

Name
****

git-commit-graph — Gitコミットグラフファイル(commit-graph file)の書き出
しと検証(verify)

Synopsis
********

     git commit-graph verify [–object-dir <dir>] [–shallow] [–[no-]progress]
     git commit-graph write <options> [–object-dir <dir>] [–[no-]progress]

DESCRIPTION
***********

シリアル化されたコミットグラフファイルを管理します。

OPTIONS
*******

‘--object-dir’
     パックファイルとコミットグラフファイルの場所として、指定のディレク
     トリを使用します。このパラメータは、完全な ‘.git’ ディレクトリでは
     なく、objectsディレクトリのみを持つ代替の場所を指定するために存在し
     ます。コミットグラフファイルは ‘<dir>/info’ ディレクトリにあり、パ
     ックファイルは ‘<dir>/pack’ にあるものと期待されます。ディレクトリ
     を絶対パスにすることができなかった場合、または既知のオブジェクトデ
     ィレクトリと一致しない場合、 ‘git commit-graph ...’ はゼロ以外のス
     テータスで終了します。

‘--[no-]progress’
     進行状況を明示的にオン/オフにします。どちらも指定されていない場合、
     標準エラーが端末に接続されていれば進行状況が表示されます。

COMMANDS
********

‘write’
     パックファイルで見つかったコミットに基づいてコミットグラフファイル
     を書き出します。構成オプション ‘core.commitGraph’ が無効になってい
     る場合、このコマンドは警告を出力し、コミットグラフファイルを書き込
     まずに成功を返します。

     ‘--stdin-packs’ オプションと共に使用して、指定のパックインデックス
     内のオブジェクトのみをウォークすることにより、新しいコミットグラフ
     を生成します。 (‘--stdin-commits’ または ‘--reachable’ と組み合わせ
     ることはできません。)

     ‘--stdin-commits’ オプションと共に使用して、16進数のOIDのリストとし
     てstdinで指定されたコミットから始まるコミットを1行に1つずつウォーク
     して、新しいコミットグラフを生成します。(直接に、またはタグの皮むき
     によって、)非コミットに解決されるOIDは黙って無視されます。不正な形
     式のOID、または存在しないOIDは、エラーを生成します。
     (‘--stdin-packs’ または ‘--reachable’ と組み合わせることはできませ
     ん。)

     ‘--reachable’ オプションと共に使用して、すべての参照で開始するコミ
     ットをウォークして、新しいコミットグラフを生成します。
     (‘--stdin-commits’ または ‘--stdin-packs’ と組み合わせることはでき
     ません。)

     ‘--append’ オプションと共に使用して、既存のコミットグラフファイルに
     存在するすべてのコミットを含めます。

     ‘--changed-paths’ オプションと共に使用すると、コミットとその最初の
     親(first parent)の間で変更されたパスに関する情報を計算して書き込み
     ます。この操作は、大規模なリポジトリでは時間がかかる場合があります
     。 ‘git log -- <path>’ を使用すると、ディレクトリまたはファイルの履
     歴を取得するためのパフォーマンスが大幅に向上します。このオプション
     が指定されている場合、その後のコミットグラフ書き込みでは、このオプ
     ションが指定されたものであると自動的に想定されます。このデータの保
     存を停止するには、 ‘--no-changed-paths’ を使用します。

     ‘--max-new-filters=<n>’ オプションと共に使用して、
     (‘--changed-paths’ が指定されている場合、)最大で ‘n’ の新しいブルー
     ムフィルター(Bloom filters)を生成します。 ‘n’ が ‘-1’ の場合、制限
     は適用されません。この制限に対しては、新しいレイヤーに存在するコミ
     ットのみがカウントされます。以前のレイヤーでブルームフィルターをさ
     かのぼって計算するには、 ‘--split=replace’ を使用することをお勧めし
     ます。 ‘commitGraph.maxNewFilters’ 構成をオーバーライドします。

     ‘--split[=<strategy>]’ オプションと共に使用して、
     ‘<dir>/info/commit-graphs’ に格納されている複数のコミットグラフファ
     イルのチェーンとしてコミットグラフを記述します。コミットグラフレイ
     ヤーは、戦略およびその他の分割オプションに基づいてマージされます。
     コミットグラフにまだ含まれていない新しいコミットは、新しい先端ファ
     イル(tip file)に追加されます。以下のマージ条件が満たされた場合、こ
     のファイルは既存のファイルとマージされます:

        • ‘--split=no-merge’ が指定されている場合、マージは実行されず、
          残りのオプションは無視されます。 ‘--split=replace’ は、既存の
          チェーンを新しいチェーンで上書きします。裸の ‘--split’ は後続
          のオプションに従います。 (注意: コミットグラフのチェーンをマー
          ジすると、既存のチェーンが長さ1のチェーンに置き換えられ、最初
          で唯一の増分がグラフ全体を保持することに注意してください)。

        • ‘--size-multiple=<X>’ が指定されていない場合は、 Xを2に等しく
          します。新しい先端ファイル(tip file)にN個のコミットがあり、以
          前の先端にM個のコミットがあり、「X 掛ける N」が M より大きい場
          合は、代わりに2つのファイルを1つのファイルにマージします。

        • ‘--max-commits=<M>’ オプションの M が正の整数で指定され、新し
          い先端ファイル(tip file) に M 以上のコミットがある場合は、代わ
          りに新しい先端を以前の先端とマージします。

          最後に、 ‘--expire-time=<datetime>’ が指定されていない場合は、
          datetimeを現在の時刻とします。分割コミットグラフ(split
          commit-graph)を書き込んだ後、変更時刻がdatetimeより古い未使用
          のコミットグラフをすべて削除します。

‘verify’
     コミットグラフファイルを読み取り、その内容をオブジェクトデータベー
     スと照合して確認(verify)します。破損したデータをチェックするために
     使用されます。

     ‘--shallow’ オプションと共に使用すると、分割コミットグラフ(split
     commit-graphs)のチェーン内の先端コミットグラフファイルのみをチェッ
     クします。

EXAMPLES
********

   • パックされたコミットのコミットグラフファイルをローカルの ‘.git’ デ
     ィレクトリに書き込みます。

          $ git commit-graph write

   • ‘<pack-index>’ のコミットを使用して、現在のコミットグラフファイルを
     拡張するコミットグラフファイルを書き出します。

          $ echo <pack-index> | git commit-graph write --stdin-packs

   • 到達可能なすべてのコミットを含むコミットグラフファイルを作成します
     。

          $ git show-ref -s | git commit-graph write --stdin-commits

   • 現在のコミットグラフファイル内のすべてのコミットと ‘HEAD’ から到達
     可能なコミットを含むコミットグラフファイルを書き出します。

          $ git rev-parse HEAD | git commit-graph write --stdin-commits --append

GIT
***

Part of the git(1) suite

Name
****

git-commit-tree — 新しいコミットオブジェクトを作成します

Synopsis
********

     git commit-tree <tree> [(-p <parent>)…]
     git commit-tree [(-p <parent>)…] [-S[<keyid>]] [(-m <message>)…]
                       [(-F <file>)…] <tree>

DESCRIPTION
***********

これは通常、エンドユーザーが直接実行するものではありません。代わりに
git-commit(1) を参照してください。

   提供されたツリーオブジェクトに基づいて新しいコミットオブジェクトを作
成し、標準出力に新しいコミットオブジェクトIDを発行します。 ‘-m’ または
‘-F’ オプションが指定されていない限り、ログメッセージは標準入力から読み
取られます。

   ‘-m’ および ‘-F’ オプションは、任意の回数、任意の順序で指定できます。
コミットログメッセージは、オプションが指定された順序で作成されます。

   コミットオブジェクトには、任意の数の親を含めることができます。親が1つ
だけの場合、これは通常のコミットです。 複数の親を持つことで、コミットは
複数の履歴行の間でマージされます。なお、最初のコミット(ルートコミット)に
は親はありません。

   ツリーは作業ディレクトリの特定のディレクトリ状態を表しますが、コミッ
トはある「時点」における状態を表し、そこに到達する方法を説明します。

   あなたがその状態に関するメモをは何処に保存してもGitは気にしませんが、
通常、コミットは新しい「HEAD」状態を識別します。実際のところGitは、
‘.git/HEAD’ が指すファイルに結果を書き込む傾向にあり、最後にコミットされ
た状態が何であったかを常に確認できるようにしています。

OPTIONS
*******

<tree>
     既存のツリーオブジェクト。

‘-p <parent>’
     各 ‘-p’ は、親コミットオブジェクトのIDを示します。

‘-m <message>’
     コミットログメッセージの段落。これは複数回指定でき、各 <message> は
     独立した段落になります。

‘-F <file>’
     指定されたファイルからコミットログメッセージを読み取ります。 標準入
     力から読み取るには、 ‘-’ を使用します。 これは複数回指定でき、各フ
     ァイルの内容は独自した段落になります。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     GPG署名コミット。 ‘keyid’ 引数はオプションで、デフォルトはコミッタ
     ーIDです。指定する場合は、スペースなしでオプションに指定する必要が
     あります。 ‘--no-gpg-sign’ は、コマンドラインで前に指定した
     ‘--gpg-sign’ オプションを無効にするのに役立ちます。

Commit Information
******************

コミットをカプセル化します:

   • 全ての親のオブジェクトID

   • 作者名と電子メールアドレスと日付

   • コミッター名とコミッター電子メールアドレスとコミット日付

   コミットコメントは標準入力から読み取られます。変更ログエントリが "<"
リダイレクトを介して提供されない場合、「git commit-tree」は、変更ログエ
ントリがターミナルから入力されて ^D で終了するのを待つだけです。

DATE FORMATS
************

‘GIT_AUTHOR_DATE’ と ‘GIT_COMMITTER_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’ として扱われます。

          *Note*

          日付部分は、上記に加えて、 ‘YYYY.MM.DD’ または ‘MM/DD/YYYY’ ま
          たは ‘DD.MM.YYYY’ 形式が受け入れられます。

Discussion
**********

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

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

   • パス名はUTF-8正規化形式C(UTF-8 normalization form C)でエンコードさ
     れます。これは、ツリーオブジェクト、インデックスファイル、ref名、お
     よびコマンドライン引数、環境変数、構成ファイル( ‘.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. ‘git commit’ と ‘git commit-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への再コーディングは必ずしも可逆的な操作ではないため、我々はコミ
ットが行われたときにコミットログメッセージを再コーディングしないことを意
図的に選択したことに注意してください。

FILES
*****

/etc/mailname

SEE ALSO
********

git-write-tree(1) git-commit(1)

GIT
***

Part of the git(1) suite

Name
****

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

Synopsis
********

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

DESCRIPTION
***********

インデックスの現在の内容と変更を説明する指定されたログメッセージを含む新
しいコミットを作成します。 新しいコミットはHEADの直接の子であり、通常は
現在のブランチの先端であり、ブランチはそれを指すように更新されます(作業
ツリーにブランチが関連付けられていない場合は、git-checkout(1) で説明され
ているようにHEADが「切り離され」(detached)されます)。

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

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

  2. 再び「commit」コマンドを使用する前に、 git-rm(1) を使用して、作業ツ
     リーとインデックスからファイルを削除します。

  3. 「commit」コマンドの引数としてファイルをリストします
     (‘--interactive’ や ‘--patch’ スイッチがない場合)。 この場合、その
     コミットはインデックスにステージングされた変更を無視し、代わりにリ
     ストされたファイル(これらはすでに Git に知られている必要があります
     )の現在のコンテンツを記録します

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

  5. 「commit」コマンドで ‘--interactive’ または ‘--patch’ スイッチを使
     用して、操作を完了する前に、インデックスの内容に加えて、どのファイ
     ルまたはハンクをコミットの一部にするかを1つずつ決定します。 これら
     のモードの操作方法については、 git-add(1)の「Interactive Mode」セク
     ションを参照してください。

   ‘--dry-run’ オプションは、同じパラメーターのセット(オプションとパス
)を指定することにより、次のコミットにて上記のいずれかに含まれるものの要
約を取得するために使用できます。

   コミットを行い、その直後に間違いを見つけた場合は、「git reset」を使用
してそれから回復できます。

OPTIONS
*******

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

‘-p’
‘--patch’
     対話的なパッチ選択インターフェイスを使用して、コミットする変更を選
     択します。 詳細については、git-add(1) を参照してください。

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

‘-c <commit>’
‘--reedit-message=<commit>’
     _-C_ と同様ですが、 ‘-c’ を使用するとエディターが呼び出されるため、
     ユーザーはコミットメッセージをさらに編集できます。

‘--fixup=[(amend|reword):]<commit>’
     ‘git rebase --autosquash’ を適用すると ‘<commit>’ を「fixes up」(修
     正)する新しいコミットを作成します。 プレーンな ‘--fixup=<commit>’ は
     「fixup!」コミットを作成します。 これは ‘<commit>’ の内容を変更しま
     すが、ログメッセージは変更されません。 ‘--fixup=amend:<commit>’ も
     同様ですが、「amend!」コミットを作成します。 これにより ‘<commit>’
     のログメッセージも「amend!」コミットのログメッセージに置き換えられ
     ます。 ‘--fixup=reword:<commit>’ は「amend!」コミットを作成します。
     これは ‘<commit>’ のログメッセージを独自のログメッセージに置き換え
     る「amend!」コミットを作成しますが、 ‘<commit>’ の内容は変更しませ
     ん。

     プレーンな ‘--fixup=<commit>’ によって作成されたコミットは、
     ‘fixup!’ に <commit> の件名行が続く件名を作り、これは ‘git rebase
     --autosquash’ によって特別に認識されます。 ‘-m’ オプションは、作成
     されたコミットのログメッセージを補足するために使用できますが、「
     fixup!」コミットが ‘git rebase --autosquash’ によって ‘<commit>’ に
     押しつぶされる(squash)と、追加のコメントは破棄されます。

     ‘--fixup=amend:<commit>’ によって作成されたコミットは似ていますが、
     その件名には代わりに ‘amend!’ というプレフィックスが付いています。
     <commit> のログメッセージが「amend!」コミットのログメッセージにコピ
     ーされ、エディターで開いた時に調整できます。 ‘git rebase
     --autosquash’ が「fixup!」を押しつぶす(squash)とき ‘<commit>’ にコ
     ミットすると、 ‘<commit>’ のログメッセージは「amend!」コミットから
     の修正されたログメッセージに置き換えられます。 「amend!」コミットの
     ログメッセージが空であることは、 ‘--allow-empty-message’ が指定され
     ていない限りエラーとなります。

     ‘--fixup=reword:<commit>’ は ‘--fixup=amend:<commit> --only’ の省略
     形です。 これはログメッセージのみで「amend!」コミットを作成します
     (インデックスにステージングされた変更は無視します)。 ‘git rebase
     --autosquash’ によって押しつぶされる(squash)と、他の変更を加えるこ
     となく、 ‘<commit>’ のログメッセージを置き換えます。

     「fixup!」や「amend!」といったコミットは、 ‘git rebase
     --autosquash’ で適用したときに ‘<commit>’ の作者は変更しません。 詳
     しくは 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’ ステータス出力を表示する場合は、ファイル
     名をそのまま(verbatim)出力し、LFではなくNULでエントリを終了します。
     フォーマットが指定されていない場合は、 ‘--porcelain’ 出力フォーマッ
     トを意味します。 ‘-z’ オプションを指定しない場合、構成変数
     ‘core.quotePath’ で説明されているように、「異常な」文字を含むファイ
     ル名がクォートされます(git-config(1) 参照)。

‘-F <file>’
‘--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’ と相互に排他的(mutually
     exclusive)です。

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

‘-s’
‘--signoff’
‘--no-signoff’
     コミットログメッセージの最後に、コミッターによる「Signed-off-by」ト
     レーラーを追加します。signoffの意味は、コミットしているプロジェクト
     によって異なります。たとえば、コミッターがプロジェクトのライセンス
     に基づいて作品を提出する権利を持っていることを証明したり、開発者の
     原産地証明書などの寄稿者の代表に同意したりする場合があります。
     (LinuxカーネルおよびGitプロジェクトで使用されるものについては、
     http：//developercertificate.orgを参照してください)。プロジェクトで
     signoffがどのように使用されるかを理解するには、貢献しているプロジェ
     クトのドキュメントまたはリーダーシップ(leadership)を参照してくださ
     い。

     ‘--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’
     ‘--allow-empty’ と同様に、このコマンドは主に外部SCMインターフェイス
     スクリプトで使用されます。 あなたは git-commit-tree(1) のような配管
     コマンドを使用せずに、空のコミットメッセージでコミットを作成できま
     す。

‘--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’ を使用してファイルから取得したメッセージや、 ‘-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

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

     すでに公開されているコミットを修正する場合、あなたは履歴の書き換え
     の影響を理解する必要があります。 (git-rebase(1) の「RECOVERING FROM
     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>]’
     追跡されていないファイル(untracked files)を表示します。

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

     可能なオプションは以下のとおりです:

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

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

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

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

‘-v’
‘--verbose’
     HEADコミットとコミットメッセージテンプレートの下部にコミットされる
     内容とのunified diffを表示して、ユーザーがコミットの変更内容を思い
     出させることでコミットを説明できるようにします。 注意: このdiff出力
     には、接頭辞 ‘#’ が付いた行がないことに注意してください。 この
     diffは、コミットメッセージの一部にはなりません。 git-config(1) の
     ‘commit.verbose’ 構成変数を参照してください。

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

‘-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)の「pathspec」エントリを参照してくだ
     さい。

EXAMPLES
********

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

     $ 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」によって開始）が停
止(stop)した後では、クリーンにマージされたパスはすでにステージングされて
コミットされ、競合したパスはマージされていない状態のままになります。 最
初に、「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’ オプションも参
照してください)。

COMMIT INFORMATION
******************

作者とコミッターの情報は、以下の環境変数から取得されます(設定されてる場
合):

     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’ 変数のみを設定する
ことです。 他のオプションは、より複雑なユースケースのために提供されてい
ます。

DATE FORMATS
************

‘GIT_AUTHOR_DATE’ と ‘GIT_COMMITTER_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’ として扱われます。

          *Note*

          日付部分は、上記に加えて、 ‘YYYY.MM.DD’ または ‘MM/DD/YYYY’ ま
          たは ‘DD.MM.YYYY’ 形式が受け入れられます。

   上記のすべての日付形式を認識することに加えて、 ‘--date’ オプションは
、 "yesterday" や "last Friday at noon" など、より人間よりの日付形式も理
解しようとします。

DISCUSSION
**********

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

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

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

   • パス名はUTF-8正規化形式C(UTF-8 normalization form C)でエンコードさ
     れます。これは、ツリーオブジェクト、インデックスファイル、ref名、お
     よびコマンドライン引数、環境変数、構成ファイル( ‘.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. ‘git commit’ と ‘git commit-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への再コーディングは必ずしも可逆的な操作ではないため、我々はコミ
ットが行われたときにコミットログメッセージを再コーディングしないことを意
図的に選択したことに注意してください。

ENVIRONMENT AND CONFIGURATION VARIABLES
***************************************

コミットログメッセージの編集に使用されるエディターは、 ‘GIT_EDITOR’ 環境
変数 または core.editor 構成変数 または ‘VISUAL’ 環境変数 または
‘EDITOR’ 環境変数から(この順序で)選択されます。 詳細については、
git-var(1) を参照してください。

HOOKS
*****

このコマンドは、 ‘commit-msg’ フックと、 ‘prepare-commit-msg’ フックと、
‘pre-commit’ フックと、 ‘post-commit’ フックと、 ‘post-rewrite’ フック を
実行できます。 詳細については、 githooks(5) を参照してください。

FILES
*****

‘$GIT_DIR/COMMIT_EDITMSG’
     このファイルには、進行中のコミットのコミットメッセージが含まれてい
     ます。 コミットを作成する前にエラーが原因で ‘gitc ommit’ が終了した
     場合、ユーザーによって提供されたコミットメッセージ(エディターセッシ
     ョンなど)は全てこのファイルに残りますが、次の ‘git commit’ の呼び出
     しによって上書きされます。

SEE ALSO
********

git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)

GIT
***

Part of the git(1) suite

Name
****

git-config — リポジトリオプションまたはグローバルオプションを、取得およ
び設定する

Synopsis
********

     git config [<file-option>] [–type=<type>] [–fixed-value] [–show-origin] [–show-scope] [-z|–null] name [value [value-pattern]]
     git config [<file-option>] [–type=<type>] –add name value
     git config [<file-option>] [–type=<type>] [–fixed-value] –replace-all name value [value-pattern]
     git config [<file-option>] [–type=<type>] [–show-origin] [–show-scope] [-z|–null] [–fixed-value] –get name [value-pattern]
     git config [<file-option>] [–type=<type>] [–show-origin] [–show-scope] [-z|–null] [–fixed-value] –get-all name [value-pattern]
     git config [<file-option>] [–type=<type>] [–show-origin] [–show-scope] [-z|–null] [–fixed-value] [–name-only] –get-regexp name_regex [value-pattern]
     git config [<file-option>] [–type=<type>] [-z|–null] –get-urlmatch name URL
     git config [<file-option>] [–fixed-value] –unset name [value-pattern]
     git config [<file-option>] [–fixed-value] –unset-all name [value-pattern]
     git config [<file-option>] –rename-section old_name new_name
     git config [<file-option>] –remove-section name
     git config [<file-option>] [–show-origin] [–show-scope] [-z|–null] [–name-only] -l | –list
     git config [<file-option>] –get-color name [default]
     git config [<file-option>] –get-colorbool name [stdout-is-tty]
     git config [<file-option>] -e | –edit

DESCRIPTION
***********

このコマンドを使用して、オプションを照会(query)/設定(set)/置換
(replace)/設定解除(unset;削除)できます。名前は実際にはドットで区切られた
セクションとキーであり、値はエスケープされます。

   ‘--add’ オプションを使用すると、オプションに複数の行を追加できます。
複数行で発生する可能性のあるオプションを更新または設定解除する場合は、
‘value-pattern’ ( ‘--fixed-value’ オプションが指定されていない限り、拡張
正規表現)を指定する必要があります。パターンに一致する既存の値のみが更新
または設定解除されます。パターンと「一致しない」行を処理する場合は、前に
1つの感嘆符(‘!’)を追加するだけです(see EXAMPLES も参照下さい)が、た
だし、これは ‘--fixed-value’ オプションが使用されていない場合のみ機能す
ることに注意してください。

   ‘--type=<type>’ オプションは _git config_ に指示して、指定の<type>の
下で入力値(incoming value)と出力値(outgoing value)が正規化可能であること
を確認します。 ‘-type=<type>’ が指定されていない場合、正規化は実行されま
せん。 呼び出し元は、既に指定済の ‘--type’ 指定子を ‘--no-type’ で設定解
除できます。

   読み取り時、値はデフォルトでシステム、グローバル、リポジトリのローカ
ル構成ファイルから読み取られ、オプション ‘--system’ 、‘--global’ 、
‘--local’ 、 ‘--worktree’ 、 ‘–file <filename> ‘ を使用して、その場所か
ら「のみ」読み取るようにコマンドに指示できます(see FILES 参照)。

   書き込み時、新しい値はデフォルトでリポジトリのローカル構成ファイルに
書き込まれます。オプション ‘--system’ 、‘--global’ 、 ‘--worktree’ 、
‘--file <filename> ` を使用すれば、コマンドにその場所に書き込むよう指示
できます(あなたは `--local’ と言うこともでき、そしてこれはデフォルトです
)。

   このコマンドは、エラー時にゼロ以外のステータスで失敗します。 いくつか
の終了コードは以下のとおりです:

   • セクションキーが不正(ret=1)

   • セクションまたは名前が与えられてない(ret=2)

   • configファイルが不正(ret=3)

   • configファイルに書き込みできない(ret=4)

   • 存在しないオプションの設定を削除(unseet)しようとしました(ret=5)

   • あなたは、複数の行が一致するオプションを設定(set)/削除(unset)しよう
     としています(ret=5)

   • 不正な正規表現を使おうとしています(ret=6)

   成功の場合、コマンドは終了コード 0 を返します。

   使用可能なすべての構成変数のリストは、 ‘git help --config’ コマンドを
使用して取得できます。

OPTIONS
*******

‘--replace-all’
     デフォルトの振る舞いでは最大1行を置き換えますが、このオプションより
     、キー(およびオプションで ‘value-pattern’)に一致するすべての行が置
     換されます。

‘--add’
     既存の値を変更せずに、オプションに新しい「行を追加」します。 これは
     ‘--replace-all’ の ‘value-pattern’ として _^$_ を指定しても同じ事が
     可能です。

‘--get’
     指定されたキーの値を取得します(オプションで、値に一致する正規表現で
     フィルタリングされます)。キーが見つからなかった場合はエラーコード
     1を返し、複数のキー値が見つかった場合は「最後の値」を返します。

‘--get-all’
     ‘--get’ と同様ですが、複数値キー(複数行;multivar)のすべての値を返し
     ます。

‘--get-regexp’
     ‘--get-all’ と同様ですが、名前を正規表現として解釈し、キー名を書き
     出します。正規表現の照合では現在、大文字と小文字が区別され、セクシ
     ョン名と変数名が小文字になっている正規化されたバージョンのキーに対
     して実行されますが、サブセクション名は大文字と小文字が区別されませ
     ん。

‘--get-urlmatch name URL’
     2つの部分からなる名前 section.key を指定すると、<url> 部分が指定し
     たURLに最もよく一致する section.<url>.key の値が返されます(そのよう
     なキーが存在しない場合は、 section.keyの値にフォールバックします)。
     セクションだけを名前として指定した合は、当該セクション内のすべての
     キー・値をリストします。値が見つからない場合はエラーコード1を返しま
     す。

‘--global’
     オプション書き込みの場合: リポジトリの ‘.git/config’ ではなくグロー
     バル ‘~/.gitconfig’ ‘$XDG_CONFIG_HOME/git/config’ ファイルがある場
     合は ‘$XDG_CONFIG_HOME/git/config’ ファイルに書き込みます。

     オプション読み取りの場合: 使用可能なすべてのファイルからではなく、
     グローバル ‘~/.gitconfig’ と ‘$XDG_CONFIG_HOME/git/config’ からのみ
     読み取ります。

     FILES も参照して下さい。

‘--system’
     オプション書き込みの場合: リポジトリの ‘.git/config’ ではなくシステ
     ム全体の ‘$(prefix)/etc/gitconfig’ に書き込みます。

     オプション読み取りの場合: 使用可能なすべてのファイルからではなく、
     システム全体の ‘$(prefix)/etc/gitconfig’ からのみ読み取ります。

     FILES も参照して下さい。

‘--local’
     オプションを書き込む場合: リポジトリの ‘.git/config’ ファイルに書き
     込みます。これがデフォルトの動作です。

     読み取りオプションの場合: 使用可能なすべてのファイルからではなく、
     リポジトリ ‘.git/config’ からのみ読み取ります。

     FILES も参照して下さい。

‘--worktree’
     ‘--local’ と似ていますが、 ‘extensions.worktreeConfig’ が存在する場
     合、 ‘.git/config.worktree’ が読み書きされる点が異なります。
     ‘extensions.worktreeConfig’ が存在しない場合は ‘--local’ と同じです
     。

‘-f config-file’
‘--file config-file’
     オプション書き込みの場合: リポジトリの ‘.git/config’ ではなく、指定
     のファイルに書き込みます。

     オプション読み取りの場合: 使用可能なすべてのファイルからではなく、
     指定のファイルからのみ読み取ります。

     FILES も参照して下さい。

‘--blob blob’
     ‘--file’ に似ていますが、ファイルの代わりに指定のブロブを使用します
     。例えば、 _master:.gitmodules_ を使用して、masterブランチのファイ
     ル _.gitmodules_ から値を読み取ることができます。ブロブ名の綴りのよ
     り完全なリストについては、 gitrevisions(7) の「SPECIFYING
     REVISIONS」セクションを参照してください。

‘--remove-section’
     指定のセクションを構成ファイルから削除します。

‘--rename-section’
     指定のセクションの名前を新しい名前に変更します。

‘--unset’
     キーに一致する行を構成ファイルから削除します。

‘--unset-all’
     キーに一致するすべての行を構成ファイルから削除します。

‘-l’
‘--list’
     構成ファイルに「設定されている」すべての変数とその値を一覧表示しま
     す(訳注:使用可能なすべての構成変数のリストは、 ‘git help
     --config’)。

‘--fixed-value’
     ‘value-pattern’ 引数と一緒に使用する場合、 ‘value-pattern’ を正規表
     現ではなく単なる文字列として扱います。これにより、値が
     ‘value-pattern’ と完全に等しいものにのみ一致する、名前/値のペアだけ
     に制限されます。

‘--type <type>’
     _git config_ は、入力または出力が指定された型(type)の制約の下で有効
     であることを保証し、その型の正規形式で出力値を正規化します。

     有効な型には以下のものがあります:

        • _bool_: 値を「true」または「false」として正規化します。

        • _int_ 値を単純な10進数として正規化します。オプションのサフィッ
          クス「k」また「m」または「g」を使用すると、入力時に値にそれぞ
          れ1,024または1,048,576(1024^2)または1,073,741,824(10243)が掛け
          算されます。

        • _bool-or-int_: 上記のように、 _bool_ または _int_ のいずれかに
          従って正規化します。

        • _path_: ‘$HOME’ の値を意味する ‘~’ を先頭に追加し、指定のユー
          ザのホームディレクトリを ‘~user’ として正規化します。この ‘~’
          は値を書き込むときには効果がありません(ただし、あなたはコマン
          ドラインから ‘git config section.variable ~/’ と実行してシェル
          に展開をさせることができます)。

        • _expiry-date_: 固定または相対の日付文字列からタイムスタンプに
          変換することで正規化します。この指定は値を書き込むときには効果
          がありません。

        • _color_: 値を取得するときに、ANSIカラーエスケープシーケンスに
          変換して正規化します。値を設定するとき、指定された値がANSIカラ
          ーとして正規化可能であることを確認するために健全性チェックが実
          行されますが、正規化自体は行われず、そのまま書き込まれます。

‘--bool’
‘--int’
‘--bool-or-int’
‘--path’
‘--expiry-date’
     タイプ指定子を選択するための歴史的オプション。 代わりに ‘--type’ を
     優先します(上記参照)。

‘--no-type’
     (これ以前に設定されていた場合、)これ以前に設定された型指定子の設定
     を解除します。このオプションは、「git config」が取得した変数を正規
     化しないように要求します。 ‘--no-type’ は、‘--type=<type>’ または
     ‘--<type>’ が無い場合は何の効果もありません。

‘-z’
‘--null’
     値やキーを出力するすべてのオプションで、値を(改行ではなく)常にヌル
     バイト(\0)で終了します。代わりに、キーと値の間の区切り文字として改
     行を使用します。これにより、例えば、改行を含む値を混乱することなく
     、出力を安全にパースできます。

‘--name-only’
     ‘--list’ または ‘--get-regexp’ の構成変数で名前のみを出力します。

‘--show-origin’
     照会されたすべての構成オプションの出力に、その構成オプションの出処
     の種類(ファイル、標準入力、blob、コマンドライン)と実際の出処(設定フ
     ァイルのパス、参照、または該当する場合はblobのID)を追加します。

‘--show-scope’
     ‘--show-origin’ と同様に、クエリされたすべての設定オプションの出力
     をその値のスコープ(ローカル、グローバル、システム、コマンド)で拡張
     します。

‘--get-colorbool name [stdout-is-tty]’
     ‘name’ の色設定(たとえば ‘color.diff’)を見つけて、「true」または「
     false」を出力します。 ‘stdout-is-tty’ は「true」または「false」のい
     ずれかである必要があり、構成で「auto」と表示されている場合に考慮さ
     れます。 ‘stdout-is-tty’ がない場合は、コマンド自体の標準出力をチェ
     ックし、色を使用する場合はステータス0で終了し、それ以外の場合はステ
     ータス1で終了します。 ‘name’ の色設定が未定義の場合、コマンドはフォ
     ールバックとして ‘color.ui’ を使用します。

‘--get-color name [default]’
     ‘name’ (例: ‘color.diff.new’) に設定されている色を見つけて、ANSIカ
     ラーエスケープシーケンスとして標準出力に出力します。 ‘name’ に色が
     設定されていない場合は、オプションの ‘default’ パラメータが代わりに
     使用されます。

     ‘--type=color [--default=<default>]’ は ‘--get-color’ よりも優先さ
     れます(ただし、 ‘--get-color’ は、 ‘--type=color’ によって出力され
     る末尾の改行を省略します)。

‘-e’
‘--edit’
     指定の構成ファイルを変更するためのエディタを開きます。指定できるの
     は、 ‘--system’ または ‘--global’ または「リポジトリ」(指定なし;デ
     フォルト)、のいずれかです。

‘--[no-]includes’
     値を検索するときは、設定ファイルの ‘include.*’ ディレクティブを尊重
     します。特定のファイルが指定されている場合(たとえば、 ‘--file’ 、
     ‘--global’ などを使用した場合)はデフォルトで ‘off’ になり、すべての
     構成ファイルを検索する場合は ‘on’ になります。

‘--default <value>’
     ‘--get’ を使用していて、要求した変数が見つからない場合、 <value> が
     その変数に割り当てられた値であるかのように動作します。

CONFIGURATION
*************

‘pager.config’ は、構成を一覧表示する場合、つまり、 ‘ –list‘ 、または複
数の結果を返す可能性のある ‘--get-*’ のいずれか、を使用する場合にのみ尊
重されます。デフォルトでは pager を使用します。

FILES
*****

‘--file’ で明示的に設定されていない場合、 _git config_ が構成オプション
を検索する以下の4つのファイルがあります:

$(prefix)/etc/gitconfig
     システム全体(PC毎)の構成ファイル

$XDG_CONFIG_HOME/git/config
     2番目のユーザー固有の構成ファイルです。 $XDG_CONFIG_HOME が設定され
     ていないか空の場合 ‘$HOME/.config/git/config’ が使用されます。この
     ファイルに設定されている単一値の変数は、 ‘~/.gitconfig’ にあるもの
     によって上書きされます。このファイルのサポートはごく最近追加された
     ため、古いバージョンのGitを使用することがある場合は、このファイルを
     作成しないことをお勧めします。

~/.gitconfig
     ユーザー毎の構成ファイル。グローバル(global)構成ファイルとも呼ばれ
     る。

$GIT_DIR/config
     リポジトリ毎の構成ファイル。

$GIT_DIR/config.worktree
     これはオプションであり、 ‘extensions.worktreeConfig’ が
     $GIT_DIR/config に存在する場合にのみ検索されます。

   それ以上のオプションが指定されていない場合、すべての読み取りオプショ
ンは、使用可能なこれらのファイルをすべて読み取ります。グローバルまたはシ
ステム全体の構成ファイルが使用できない場合、それらは無視されます。リポジ
トリ設定ファイルが利用できないか読み取り可能でない場合、「git config」は
ゼロ以外のエラーコードで終了します。 ただし、どちらの場合もエラーメッセ
ージは発行されません。

   ファイルは上記の順序で読み取られ、「最後」に見つかった値が前に読み取
った値よりも優先されます。なお、複数値(multiple values)を取得すると、す
べてのファイルのキーのすべての値が使用されます。

   あなたは gitコマンドを実行するとき、 ‘-c’ オプションを使用して、個々
の構成パラメーターをオーバーライドできます。詳細については git(1) を参照
してください。

   すべての書き込みオプションは、デフォルトではリポジトリ固有の構成ファ
イルに書き込みます。これは、 ‘--replace-all’ や ‘--unset’ などのオプショ
ンにも影響することに注意してください。 ※ ‘git config’ は一度に1つのファ
イルのみを変更します。

   これらのルールは、 ‘--global’ と‘ –system‘ と ‘--local’ と‘
–worktree‘ と ‘--file’ コマンドラインオプションを使用してオーバーライド
できます。上記の OPTIONS を参照してください。

ENVIRONMENT
***********

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM
     グローバルまたはシステムレベルの構成からではなく、指定されたファイ
     ルから構成を取得します。詳細については git(1) を参照してください。

GIT_CONFIG_NOSYSTEM
     システム全体(PC毎)の $(prefix)/etc/gitconfig ファイルからの設定の読
     み取りをスキップするかどうか。詳細については git(1) を参照してくだ
     さい。

   FILES も参照して下さい。

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>
     GIT_CONFIG_COUNTが正の数に設定されている場合、その数までのすべての
     環境ペア GIT_CONFIG_KEY_<n> と GIT_CONFIG_VALUE_<n> がプロセスのラ
     ンタイム構成に追加されます。構成ペアはゼロインデックスです。キーま
     たは値が欠落している場合は、エラーとして扱われます。空の
     GIT_CONFIG_COUNTは、GIT_CONFIG_COUNT=0と同じように扱われます。つま
     り、ペアは処理されません。これらの環境変数は構成ファイルの値をオー
     バーライドしますが、 ‘git -c’ を介して渡された明示的なオプションに
     よってオーバーライドされます。

     これは、共通の構成で複数のgitコマンドを生成したいが、スクリプトを作
     成する場合など、構成ファイルに依存できない場合に役立ちます。

GIT_CONFIG
     ‘git config’ に ‘--file’ オプションが指定されていない場合は、
     ‘--file’ を介して提供されているかのように ‘GIT_CONFIG’ によって指定
     されたファイルを使用します。この変数は他のGitコマンドには影響せず、
     主に歴史的な互換性のためのものです。 通常、 ‘--file’ オプションの代
     わりに使用する理由はありません。

EXAMPLES
********

以下の .git/config が与えられているものとします:

     #
     # This is the config file, and
     # a '#' or ';' character indicates
     # a comment
     #

     ; core variables
     [core]
             ; Don't trust file modes
             filemode = false

     ; Our diff algorithm
     [diff]
             external = /usr/local/bin/diff-wrapper
             renames = true

     ; Proxy settings
     [core]
             gitproxy=proxy-command for kernel.org
             gitproxy=default-proxy ; for all the rest

     ; HTTP
     [http]
             sslVerify
     [http "https://weak.example.com"]
             sslVerify = false
             cookieFile = /tmp/cookie.txt

   あなたは以下のようにしてfilemodeをtrueに設定できます

     % git config core.filemode true

   とある架空のプロキシコマンドエントリで、末尾が kernel.org である行を
、 _"ssh" for kernel.org_ に置換するには

     % git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'

   これにより、kernel.orgのキーと値のペアのみが置き換えられます。

   renamesのエントリを削除するには

     % git config --unset diff.renames

   マルチ変数(multivar)(上記のcore.gitproxyなど)のエントリを削除する場合
は、正確に1行の値に一致する正規表現を指定する必要があります。

   特定のキーの値を照会するには、次のようにします。

     % git config --get core.filemode

   または

     % git config core.filemode

   また、マルチ変数(multivar)の照会は:

     % git config --get core.gitproxy "for kernel.org$"

   マルチ変数のすべての値を知りたい場合は、次のようにします:

     % git config --get-all core.gitproxy

   あなたが危険極まりない人生を送りたい場合は、以下のようにして
core.gitproxy の「全て」を新しいものに置き換えることができます。

     % git config --replace-all core.gitproxy ssh

   しかし、あなたが本当にデフォルトプロキシの行、つまり「for …」の接尾辞
のない行だけを置き換えたい場合は、次のようにします:

     % git config core.gitproxy ssh '! for '

   感嘆符(‘!’)と実際に一致させるには、以下のことを行う必要があります。

     % git config section.key value '[!]'

   既存のプロキシを変更せずに新しいプロキシを追加するには、以下を使用し
ます。

     % git config --add core.gitproxy '"proxy-command" for example.com'

   あなたのスクリプトで構成からカスタマイズされた色を使う例:

     #!/bin/sh
     WS=$(git config --get-color color.diff.whitespace "blue reverse")
     RESET=$(git config --get-color "" "reset")
     echo "${WS}your whitespace color or blue reverse${RESET}"

   URL が ‘https://weak.example.com’ の場合、 ‘http.sslVerify’ はfalseに
設定され、他のすべてのURLでは ‘true’ に設定されます:

     % git config --type=bool --get-urlmatch http.sslverify https://good.example.com
     true
     % git config --type=bool --get-urlmatch http.sslverify https://weak.example.com
     false
     % git config --get-urlmatch http https://weak.example.com
     http.cookieFile /tmp/cookie.txt
     http.sslverify false

CONFIGURATION FILE
******************

Git構成ファイルには、Gitコマンドの動作に影響を与えるいくつかの変数が含ま
れています。各リポジトリ内のファイル ‘.git/config’ と、オプションで
‘config.worktree’ (git-worktree(1) の「CONFIGURATION FILE」セクションを
参照)は、そのリポジトリの設定を保存するために使用され、
‘$HOME/.gitconfig’ は、ユーザーごとの構成を ‘.git/config’ ファイルのフォ
ールバック値として保存するために使用されます。 ファイル ‘/etc/gitconfig’
を使用して、システム全体のデフォルト設定を保存できます。

   構成変数は、Git配管コマンドとGit磁器コマンドの両方で使用されます。変
数はセクションに分割されます。変数自体の完全修飾変数名は最後のドット区切
りセグメントであり、セクション名は最後のドットより前のすべてです。変数名
では大文字と小文字が区別されず、英数字(alphanumeric)と ‘-’(\x2d) のみが
許可され、英字(alphabetic)で始まる必要があります。一部の変数は複数回現れ
る場合があり、その変数はmultivalueであると言います(訳注:multiple lines(複
数行)という表現とmultivalueと言う表現が混在する。configでは同じ意味)。

Syntax
======

構文はかなり柔軟で寛容です。空白(whitespace)はほとんど無視されます。 _#_
と _;_ 文字はそこからその行の行末までコメントにします。空白行は無視され
ます。

   このファイルは、セクションと変数で構成されています。セクションは角括
弧内(‘[' … `]')のセクションの名前で始まり、次のセクションが始まるまで続
きます。セクション名では大文字と小文字は区別されません。セクション名には
、英数字(alphanumeric) と `-’ (\x2d) と ‘.’ (\x2e) のみを使用できます。
各変数はあるセクションに属している必要があります。つまり、変数の最初の設
定の前にセクションヘッダーが必要です。

   セクションはさらにサブセクションに分割できます。サブセクションを開始
するには、以下の例のように、セクションヘッダーで、セクション名からスペー
スで区切って、その名前を二重引用符で囲みます:

             [section "subsection"]

   サブセクション名では大文字と小文字が区別され、改行とヌルバイト
(\x00)以外の任意の文字を含めることができます。 二重引用符 ‘"’ (\x22)と バ
ックスラッシュ(\x5c;日本の環境では円記号で表示される事がある)は、それぞ
れ ‘\"’ と ‘\\’ としてエスケープすることで含めることができます。 他の文
字の前にあるバックスラッシュは、読み取るときに削除されます。 たとえば、
‘\t’ は ‘t’ として読み取られ、 ‘\0’ は ‘0’ として読み取られます。セクシ
ョンヘッダーは複数行にまたがることはできません。変数は、セクションまたは
特定のサブセクションに直接属する場合があります。 ‘[section" subsection
"]’ がある場合は ‘[section]’ も使用できますが、必須ではありません。

   非推奨の ‘[section.subsection]’ 構文があります。この構文では、サブセ
クション名は小文字に変換され、大文字と小文字が区別されて比較されます。こ
れらのサブセクション名は、セクション名と同じ制限に従います。

   他のすべての行(およびセクションヘッダーの後の行の残りの部分)は、「
name = value」(または単に「name」)の形式で設定変数として認識されます(「
name」形式は「name = true」の省略形で、変数をブール値「true」に設定しま
す)。変数名では大文字と小文字が区別されず、英数字(alphanumeric)と ‘-’
(\x2d) のみが許可され、英字(alphabetic)で始まる必要があります。

   値を定義する行は、 ‘\’ (\x5c) で終了することにより、次の行に続けるこ
とができます。続けた時、バックスラッシュと行末は削除されて認識されます。
_name =_ の後の先頭の空白と、その行で最初に現れるコメント文字 _#_ または
_;_ 以降行末まで、または、行末尾の空白は、二重引用符で囲まれていない限り
破棄されます。値内の内部空白はそのまま保持されます。

   ダブルクォートで囲まれた中では、ダブルクォート ‘"’ とバックスラッシュ
‘\’ 文字はエスケープしなければなりません。 ‘"’ を表わすには ‘\"’ を使い
、 ‘\’ を表わすには ‘\\’ を使ってください。

   ( ‘\"’ と ‘\\’ に加えて)認識されるエスケープシーケンスは、改行文字
(NL;newline)が ‘\n’ 、水平タブ(HT;TAB)が ‘\t’ 、バックスペース(BS)が
‘\b’ です。他のエスケープシーケンス(8進エスケープシーケンスを含む)は無効
です。

Includes
========

‘include’ セクションと ‘includeIf’ セクションを使用すると、別のソースか
らの設定ディレクティブを含めることができます。これら２つのセクションは、
条件がtrueと評価されない場合 ‘includeIf’ セクションが無視されることを除
いて、同様に動作します。 以下の「Conditional includes」を参照してくださ
い。

   特別な ‘include.path’ (または ‘includeIf.*.path’ )変数をインクルード
するファイルの名前に設定することにより、別の構成ファイルをインクルードで
きます。 変数はその値としてパス名を取り、チルダ展開の対象となります。こ
れらの変数は複数回指定できます。

   インクルードファイルの内容は、includeディレクティブの場所で見つかった
かのように、すぐに挿入されます。変数の値が相対パスである場合、そのパスは
、includeディレクティブが見つかった構成ファイルからの相対パスであると見
なされます。例については、以下を参照してください。

Conditional includes
====================

‘includeIf.<condition>.path’ 変数をインクルードするファイルの名前に設定
することにより、条件付きで別の構成ファイルをインクルードできます。

   条件は、キーワードで始まり、その後にコロンと、形式と意味がキーワード
によって異なるいくつかのデータが続きます。サポートされているキーワードは
以下のとおりです:

‘gitdir’
     キーワード ‘gitdir:’ 続くデータは、グロブパターンとして使用されます
     。 .git ディレクトリの場所がパターンと一致する場合、インクルード条
     件が満たされます。

     ‘.git’ の場所は自動検出されるか、 ‘$GIT_DIR’ 環境変数から取得されま
     す。 リポジトリが .git ファイルを介して(つまり、サブモジュールやリ
     ンクされたワークツリーなどから)自動検出される場合、最終的に検出され
     る .git の場所とは、 .git ファイルの場所ではなく .git ファイルから
     たどった .gitディレクトリの場所です。

     パターンには、標準のグロブワイルドカードと、複数のパス部分に一致す
     る可能性のある2つの追加のワイルドカード ‘**/’ と ‘/**’ を含めること
     ができます。詳細については、 gitignore(5) を参照してください。便宜
     上、以下の記法が使えます:

        • パターンが ‘~/’ で始まる場合、 ‘~’ は環境変数 ‘HOME’ の内容に
          置き換えられます。

        • パターンが ‘./’ で始まる場合、現在の設定ファイルを含むディレク
          トリに置き換えられます。

        • パターンが ‘~/’ ・ ‘./’ ・ ‘/’ のいずれでも始まらない場合、
          ‘**/’ 自動的に先頭に追加されます。たとえば、パターン ‘foo/bar’
          は ‘**/foo/bar’ になり、 ‘/any/path/to/foo/bar’ と一致します。

        • パターンが ‘/’ で終わる場合、 ‘**’ が自動的に追加されます。 た
          とえば、パターン ‘foo/’ は ‘foo/**’ になります。言い換えると、
          「foo」ディレクトリとその中のすべてに再帰的に一致します。

‘gitdir/i’
     これは、照合が大文字と小文字を区別せずに行われることを除いて、
     ‘gitdir’ と同じです(大文字と小文字を区別しないファイルシステムなど
     )。

‘onbranch’
     キーワード ‘onbranch:’ に続くデータは、標準のグロブワイルドカードと
     、複数のパス部分に一致する可能性のある2つの追加のワイルドカード
     ‘**/’ と ‘/**’ を含むパターンと見なされます。現在チェックアウトされ
     ているブランチの名前がパターンと一致するワークツリーにいる場合、イ
     ンクルード条件が満たされます。

     パターンが ‘/’ で終わる場合、 ‘**’ が自動的に追加されます。 たとえ
     ば、パターン ‘foo/’ は ‘foo/**’ になります。つまり、 ‘foo/’ で始ま
     るすべてのブランチに一致します。これは、ブランチが階層的に編成され
     ていて、その階層内のすべてのブランチに構成を適用する場合に役立ちま
     す。

   ‘gitdir’ と ‘gitdir/i’ を介したマッチングに関するいくつかの注意事項:

   • ‘$GIT_DIR’ の中のシンボリックリンクは、マッチ前に解決されません。

   • シンボリックリンクバージョンとrealpathバージョンの両方のパスが、
     ‘$GIT_DIR’ の値と照合されます。例えば ‘~/git’ が ‘/mnt/storage/git’
     へのシンボリックリンクである場合、 ‘gitdir:~/git’ と
     ‘gitdir:/mnt/storage/git’ の両方が一致します。

     これは、Git v2.13.0 でのこの機能の最初のリリースには当てはまりませ
     んでした。これは、realpathバージョンにのみ一致していました。この機
     能の初期リリースとの互換性を希望する構成では、realpathバージョンの
     み、あるいは両方のバージョンを指定する必要があります。

   • 注意: 「../」は特別なものではなく、文字通り一致することに注意してく
     ださい。これは、あなたが望むものではない可能性があります。

Example
=======

     # Core variables
     [core]
             ; Don't trust file modes
             filemode = false

     # Our diff algorithm
     [diff]
             external = /usr/local/bin/diff-wrapper
             renames = true

     [branch "devel"]
             remote = origin
             merge = refs/heads/devel

     # Proxy settings
     [core]
             gitProxy="ssh" for "kernel.org"
             gitProxy=default-proxy ; for the rest

     [include]
             path = /path/to/foo.inc ; include by absolute path
             path = foo.inc ; find "foo.inc" relative to the current file
             path = ~/foo.inc ; find "foo.inc" in your `$HOME` directory

     ; include if $GIT_DIR is /path/to/foo/.git
     [includeIf "gitdir:/path/to/foo/.git"]
             path = /path/to/foo.inc

     ; include for all repositories inside /path/to/group
     [includeIf "gitdir:/path/to/group/"]
             path = /path/to/foo.inc

     ; include for all repositories inside $HOME/to/group
     [includeIf "gitdir:~/to/group/"]
             path = /path/to/foo.inc

     ; relative paths are always relative to the including
     ; file (if the condition is true); their location is not
     ; affected by the condition
     [includeIf "gitdir:/path/to/group/"]
             path = foo.inc

     ; include only if we are in a worktree where foo-branch is
     ; currently checked out
     [includeIf "onbranch:foo-branch"]
             path = foo.inc

Values
======

多くの変数の値は単純な文字列として扱われますが、特定のタイプの値をとる変
数があり、それらの綴り方に関する規則があります。

boolean
     変数がブール値をとると言われるとき、「true」と「false」の多くの同義
     語が受け入れられます。なお、これらはすべて大文字と小文字を区別しま
     せん。

     true
          ブール値 true のリテラルは、 ‘yes’ と ‘on’ と ‘true’ と ‘1`で
          す。 また、値の指定無し( `= <value>’ 無し) の変数は true と見
          なされます。

     false
          ブール値 false リテラルは、 ‘no’ と ‘off’ と ‘false’ と ‘0’ と
          空文字列です。

          ‘--type = bool’ 型指定子を使用して値を正規形に変換する場合、
          _git config_ は、値の出力を「true」または「false」（小文字で表
          記）にします。

integer
     さまざまなサイズを指定する多くの変数の値には、「k」、「M」などの接
     尾辞を付けることができます。これは、「数値に1024掛けた値に」、「数
     値に1024x1024を掛けた値に」などを意味します。

color
     色をとる変数の値は、スペースで区切られた色(最大で2つ、1つは前景用
     (foreground)、もう1つは背景用(background))と、(必要な数の)属性
     (attribute)の「リスト」です。

     使用できる基本色は、 ‘normal’ と ‘black’ と ‘red’ と ‘green’ と
     ‘yellow’ と ‘blue’ と ‘magenta’ と ‘cyan’ と ‘white’ です。与えられ
     た最初の色は前景用です。2番目は背景用です。 ‘normal’ を除くすべての
     基本色には、 ‘brightred’ のように色の前に ‘bright’ と付けることで指
     定できる明るいバリエーションがあります。

     色は0から255までの数字で指定することもできます。これらはANSI256色モ
     ードを使用します(ただし、すべての端末がこれをサポートしているわけで
     はないことに注意してください)。端末が24ビットRGB値をサポートしてい
     る場合は ‘#ff0ab3’ のように16進数として指定することもできます。

     受け入れられる属性(attribute)は、 ‘bold’ と ‘dim’ と ‘ul’ と
     ‘blink’ と ‘reverse’ と ‘italic’ と ‘strike’ (取り消し線
     (cross-out)または「取り消し線」の文字(strikethrough letters)の場合)
     です。色に関する属性の位置(前、後、または中間)は重要ではありません
     。特定の属性は、それらの前に「no」または「no-」を付けることによって
     オフにすることができます(たとえば、「noreverse」、「no-ul」など)。

     空のカラー文字列は、色の効果をまったく生成しません。 これは、色を完
     全に無効にすることなく、特定の要素の色付けを回避するために使用でき
     ます。

     gitで事前定義されたカラースロットの場合、属性は、カラー出力の各アイ
     テムの先頭でリセットされることを意図しています。したがって、
     ‘color.decorate.branch`を’ black‘に設定すると、同じ出力行の前のもの
     が ‘bold’ または他の属性でペイントされるように設定されている場合(た
     とえば ‘log --decorate’ 出力のブランチ名のリストの前で括弧を開く)で
     も、そのブランチ名がプレーンな ‘black’ でペイントされます。ただし、
     カスタムログ形式では、より複雑で階層化された色付けが行われる場合が
     あり、否定された形式が役立つ場合があります。

pathname
     パス名の値をとる変数には、 ‘~/’ または ‘~user/’ で始まる文字列を指
     定できます。このような文字列には、通常のチルダ展開が行われます。
     ‘~/’ は ‘$HOME’ の値に展開され、 ‘~user/’ は指定のユーザーのホーム
     ディレクトリに展開されます。

     パスが ‘%(prefix)/’ で始まる場合、残りはGitの「ランタイムプレフィッ
     クス」に関連するパス、つまりGit自体がインストールされた場所に関連す
     るパスとして解釈されます。 たとえば、 ‘%(prefix)/bin/’ は、Git実行
     可能ファイル自体が存在するディレクトリを指します。Gitがランタイムプ
     レフィックスのサポートなしでコンパイルされた場合、代わりにコンパイ
     ルされたプレフィックスが置き換えられます。万が一、展開してはならな
     いリテラルパスを指定する必要がある場合は、 ‘./%(prefix)/bin’ のよう
     に接頭辞 ‘./’ を付ける必要があります。

Variables
=========

注意: このリストは包括的ではなく、必ずしも完全ではないことに注意してくだ
さい。コマンド固有の変数については、適切なマニュアルページに詳細な説明が
あります。

   他のgit関連ツールは、独自の変数を使用する場合があります。独自のツール
で使用する新しい変数を考案するときは、それらの名前がGit自体や他の一般的
なツールで使用されているものと競合しないことを確認し、ドキュメントに記述
してください。

advice.*
     これらの変数は、新しいユーザーを支援するために設計されたさまざまな
     オプションのヘルプメッセージを制御します。すべての「advice.*」変数
     はデフォルトで「true」に設定されており、これらを「false」に設定する
     ことで、ヘルプが不要であることをGitに伝えることができます。

     fetchShowForcedUpdates
          git-fetch(1)がrefの更新後に強制更新を計算したり、 チェックが無
          効になっていることを警告したりするのに 長い時間がかかる場合に
          表示されるアドバイス。

     pushUpdateRejected
          _pushNonFFCurrent_ と _pushNonFFMatching_ と
          _pushAlreadyExists_ と _pushFetchFirst_ と _pushNeedsForce_ と
          _pushRefNeedsUpdate_ を 同時に無効にする場合は、この変数を
          _false_ に設定します。

     pushNonFFCurrent
          現在のブランチへの non-fast-forward 更新が原因で git-push(1) が
          失敗した場合に表示されるアドバイス。

     pushNonFFMatching
          git-push(1) を実行し、 「matching refs」を明示的にプッシュ(つ
          まり あなたは「:」を使用したか、 あなたの現在のブランチではな
          いrefspecを指定した)して、 「non-fast-forward」エラーが発生し
          たときに表示されるアドバイスです。

     pushAlreadyExists
          git-push(1) が、 fast-forwarding の対象とならない更新(タグなど
          )を拒否した場合に表示されます。

     pushFetchFirst
          git-push(1) が、私たちが持っていないオブジェクトを指す リモー
          ト参照を上書きしようとする更新を 拒否した場合に表示されます。

     pushNeedsForce
          git-push(1) が、 コミットっぽくないオブジェクトを指すリモート
          refを上書きしようとする更新、 またはコミットっぽくないブジェク
          トを指すリモートrefを作成しようとする更新を 拒否した場合に表示
          されます。

     pushUnqualifiedRefname
          git-push(1) が、 ソースと宛先のrefsに基づいて、 ソースが属する
          リモートref名前空間を推測しようとするのをあきらめたときに表示
          されます。 ただし、 ソースオブジェクトのタイプに基づいて、
          refs/heads/* または refs/tags/* のいずれかにプッシュすることを
          提案できる場合もあります。

     pushRefNeedsUpdate
          git-push(1) が、 リモート追跡refにローカルにない更新がある場合
          に、 ブランチの強制更新を拒否した場合に表示されます。

     skippedCherryPicks
          git-rebase(1) が、 アップストリームブランチにすでにチェリーピ
          ックされているコミットをスキップした場合に表示されます。

     statusAheadBehind
          git-status(1) が、 リモート追跡refと比較したローカルrefの先行
          (ahead)/遅延(behind)カウントを計算し、 その計算に予想よりも時
          間がかかる場合に表示されます。 ‘status.aheadBehind’ がfalseの
          場合、 またはオプション ‘--no-ahead-behind’ が指定されている場
          合は表示されません。

     statusHints
          git-status(1) の出力や、 git-commit(1) の コミットメッセージ記
          入時のテンプレート表示や、 git-switch(1) または
          git-checkout(1) の ブランチ切り替え時のヘルプメッセージに、 現
          在の状態からどのように進めていくかの指示を表示します。

     statusUoption
          コマンドが、 追跡されていないファイルを列挙するのに2秒以上かか
          る場合は、 git-status(1) で ‘-u’ オプション使用の検討をアドバ
          イスします。

     commitBeforeMerge
          git-merge(1) がローカルの変更を上書きしないようにマージを拒否
          した場合に、 アドバイスが表示されます。

     resetQuiet
          コマンドがreset後に、 ステージングされていない変更を列挙するの
          に2秒以上かかる場合は、 git-reset(1) で ‘--quiet’ オプション使
          用の検討をアドバイスします。

     resolveConflict
          競合が原因で操作が実行できない場合に、 さまざまなコマンドによ
          って表示されるアドバイス。

     sequencerInUse
          シーケンサーコマンドがすでに進行中の場合に表示されるアドバイス
          。

     implicitIdentity
          システムのユーザー名とドメイン名から 情報が推測される場合の
          ID構成の設定方法に 関するアドバイス。

     detachedHead
          git-switch(1) または git-checkout(1) を使用して HEADのデタッチ
          状態に移行し、 事後にローカルブランチを作成する方法を 指示した
          ときに表示されるアドバイス。

     checkoutAmbiguousRemoteBranchName
          git-checkout(1) と git-switch(1) の引数が、 明確な引数によらず
          リモート追跡ブランチがチェックアウトされる状況で、 複数のリモ
          ート上のリモート追跡ブランチに対して あいまいに解決される場合
          に表示されるアドバイス。 このアドバイスが出力される状況で、 特
          定のリモートをデフォルトで 使用するように設定する方法について
          は、 ‘checkout.defaultRemote’ 構成変数を参照してください。

     amWorkDir
          git-am(1) がパッチファイルの適用に失敗した場合に パッチファイ
          ルの場所を示すアドバイス。

     rmHints
          git-rm(1) の出力に失敗した場合、 現在の状態からどのように進め
          るかについての指示を表示します。

     addEmbeddedRepo
          誤って、あるgitリポジトリを別のリポジトリ内に追加した 場合の対
          処方法に関するアドバイス。

     ignoredHook
          フックが実行可能ファイルとして設定されていないために フックが
          無視された場合に表示されるアドバイス。

     waitingForEditor
          Gitがユーザーからのエディタ入力を待機しているときは、 いつでも
          端末にメッセージを出力します。

     nestedTag
          ユーザーがタグオブジェクトに再帰的にタグを付けようとした 場合
          に表示されるアドバイス。

     submoduleAlternateErrorStrategyDie
          「die」に設定された submodule.alternateErrorStrategy オプショ
          ンが 致命的なエラーを引き起こす場合に表示されるアドバイス。

     addIgnoredFile
          ユーザーが、無視されたファイルをインデックスに追加しようとした
          場合に表示されるアドバイス。

     addEmptyPathspec
          ユーザーがpathspecパラメーターを指定せずに addコマンドを実行し
          た場合に表示されるアドバイス。

     updateSparsePath
          git-add(1) または git-rm(1) のいずれかが、 現在のスパースチェ
          ックアウト外のインデックスエントリを 更新するように求められた
          ときに表示されるアドバイス。

core.fileMode
     作業ツリー内のファイルの実行可能ビットを尊重するかどうかをGitに通知
     します。

     一部のファイルシステムでは、実行可能としてマークされたファイルがチ
     ェックアウトされるか、実行可能ビットがオンになっている実行不可能な
     ファイルをチェックアウトすると、実行可能ビットを失います。
     git-clone(1) または git-init(1) は、ファイルシステムを調査して、実
     行可能ビットを正しく処理し、この変数が必要に応じて自動的に設定され
     るかどうかを確認します。

     リポジトリはファイルモードを正しく処理するファイルシステム上にある
     可能性があり、この変数は作成時に「true」に設定されますが、後でファ
     イルモードを失う別の環境からアクセスできるようになる可能性がありま
     す(たとえば、CIFSマウントを介したext4のエクスポート。CygwinがGit
     for WindowsまたはEclipseでリポジトリを作成た時など)。このような場合
     、この変数を「false」に設定する必要がある場合があります。
     git-update-index(1) を参照してください。

     (設定ファイルでcore.filemodeが指定されていない場合、)デフォルトは
     trueです。

core.hideDotFiles
     (Windowsのみ)trueの場合、名前がドットで始まる、新しく作成されたディ
     レクトリと新しく作成されたファイルを非表示としてマークします。
     _dotGitOnly_ の場合、 ‘.git/’ ディレクトリのみが非表示になり、ドッ
     トで始まる他のファイルは非表示になりません。デフォルトのモードは「
     dotGitOnly」です。

core.ignoreCase
     APFS、HFS+、FAT、NTFSなどの大文字と小文字を区別しないファイルシステ
     ムでGitをより適切に機能させるためのさまざまな回避策を可能にする内部
     変数。たとえば、Gitが「Makefile」を予期しているときにディレクトリリ
     ストで「makefile」が見つかった場合、Git それは実際には同じファイル
     であると想定し、「Makefile」として記憶し続けます。

     デフォルトはfalseですが、 git-clone(1) または git-init(1) は、リポ
     ジトリの作成時に必要に応じてcore.ignoreCaseを調査してtrueに設定しま
     す。

     あなたのオペレーティングシステムとファイルシステムに関して、Gitは、
     この変数の適切な構成に依存しています。この値を変更すると、予期しな
     い動作が発生する可能性があります。

core.precomposeUnicode
     このオプションは、GitのMacOS実装でのみ使用されます。
     core.precomposeUnicode=true の場合、GitはMacOSによって行われたファ
     イル名のUnicode分解(unicode decomposition)を元に戻します。これは、
     MacOSとLinuxまたはWindowsの間でリポジトリを共有する場合に便利です。
     (Git for Windows 1.7.10以降、または Git under cygwin 1.7 が必要です
     )。 falseの場合、ファイル名はGitによって完全に透過的に処理されます
     。これは、古いバージョンのGitとの下位互換性があります。

core.protectHFS
     trueに設定されている場合、 HFS+ ファイルシステムで ‘.git’ と同等と
     見なされるパスのチェックアウトを許可しないでください。デフォルトは
     MacOSでは ‘true’ 、それ以外の場合は ‘false’ です。

core.protectNTFS
     trueに設定されている場合、NTFSファイルシステムで問題を引き起こす可
     能性のあるパスのチェックアウトを許可しないでください。 例えば、 8.3
     の「短い」名前と競合します。デフォルトは、Windowsでは「true」、それ
     以外の場合は「false」です。

core.fsmonitor
     設定されている場合、この変数の値は、要求された日時以降に変更された
     可能性のあるすべてのファイルを識別するコマンドとして使用されます。
     この情報は、変更されていないファイルの不要な処理を回避することによ
     り、gitを高速化するために使用されます。 githooks(5) の「
     fsmonitor-watchman」セクションを参照してください。

core.fsmonitorHookVersion
     fsmonitorを呼び出すときに使用されるフックのバージョンを設定します。
     現在、バージョン1と2があります。これが設定されていない場合、バージ
     ョン2が最初に試行され、失敗した場合はバージョン1が試行されます。 バ
     ージョン1は、入力としてtimpstampを使用して、それ以降に変更があった
     ファイルを判別しますが、watchmanなどの一部のモニターでは、
     timestampを使用すると競合状態になります。バージョン2はopaque
     stringを使用しているため、モニターは競合状態なしで変更されたファイ
     ルを判別するために使用できるものを返すことができます。

core.trustctime
     falseの場合、インデックスと作業ツリー間のctimeの違いは無視されます
     。iノードの変更時刻がGitの外部の何か(ファイルシステムクローラーおよ
     び一部のバックアップシステム)によって定期的に変更される場合に役立ち
     ます。 git-update-index(1) を参照してください。デフォルトではtrueで
     す。

core.splitIndex
     trueの場合、インデックスの分割インデックス機能が使用されます。
     git-update-index(1) を参照してください。 デフォルトではfalseです。

core.untrackedCache
     インデックスの追跡されていないモノのキャッシュ機能をどうするかを決
     定します。この変数が設定されていない(unset)か、 ‘keep’ に設定されて
     いる場合、キャッシュが保持されます。 ‘true’ に設定すると、自動的に
     追加されます。 また、 ‘false’ に設定すると、自動的に削除されます。
     ‘true’ に設定する前に、mtimeがシステムで正しく機能していることを確
     認する必要があります。 git-update-index(1) を参照してください。 こ
     の設定をデフォルトで ‘true’ に設定する ‘feature.manyFiles’ が有効に
     なっていない限り、デフォルトは ‘keep’ です。

core.checkStat
     core.checkStat が設定されていないか ‘default’ に設定されている場合
     、Gitがファイルを調べてからファイルが変更されたかどうかを検出するた
     めに、stat構造体の多くのフィールドがチェックされます。この構成変数
     が ‘minimal’ に設定されている場合、mtimeとctimeの1秒未満の部分、フ
     ァイルの所有者のuidとgid、iノード番号(およびGitがそれを使用するよう
     にコンパイルされている場合はデバイス番号も)はチェック対象から除外さ
     れ、mtimeの2分の1の部分(および ‘core.trustCtime’ が設定されている場
     合はctime)とファイルサイズチェックのみがチェック対象として残ります
     。

     (JGitなど)一部のフィールドに使用可能な値を残さないGitの実装がありま
     す。これらのフィールドを比較から除外することにより、 ‘minimal’ モー
     ドは、同じリポジトリがこれらの他のシステムによって同時に使用される
     場合の相互運用性に役立つ可能性があります。

core.quotePath
     パスを出力するコマンド(例: _ls-files_ 、 _diff_)は、パス名を二重引
     用符で囲み(‘"..."’)、Cが制御文字をエスケープするのと同じ方法でそれ
     らの文字をバックスラッシュ(‘\’)でエスケープすることにより、パス名の
     「異常な」文字をクォートします(例: TABの場合は ‘\t’ 、LFの場合は
     ‘\n’ 、バックスラッシュの場合は ‘\\’ )、または0x80より大きい値のバ
     イト(たとえば、UTF-8の "micro" の場合は8進数 ‘\302\265’)。この変数
     がfalseに設定されている場合、0x80を超えるバイトは「異常」とは見なさ
     れなくなります。この変数の設定に関係なく、二重引用符(‘"’)、バックス
     ラッシュ(‘\’)、および制御文字は常にエスケープされます。単純なスペー
     ス文字は「異常」とは見なされません。多くのコマンドは、 ‘-z’ オプシ
     ョンを使用してパス名を完全にそのままで出力できます。デフォルト値は
     trueです。

core.eol
     作業ディレクトリ内で、( ‘text’ 属性を設定するか、‘text=auto’ と
     Gitがコンテンツをテキストとして自動検出することにより)テキストとし
     てマークされたファイルが使用する行末タイプを設定します。 代替手段は
     、 ‘lf’ と ‘crlf’ と プラットフォームの生来の行末を使用する
     ‘native’ があります。デフォルト値は ‘native’ です。行末変換の詳細に
     ついては、 gitattributes(5) を参照してください。注意:
     ‘core.autocrlf’ が ‘true’ または ‘input’ に設定されている場合、この
     値は無視されることに注意してください。

core.safecrlf
     trueの場合、行末変換がアクティブなときに ‘CRLF’ の変換が可逆的かど
     うかをGitにチェックさせます。 Gitは、コマンドが作業ツリー内のファイ
     ルを直接または間接的に変更するかどうかを確認します。たとえば、ある
     ファイルをコミットしてから同じファイルをチェックアウトすると、作業
     ツリーに元のファイルが生成されます。この操作が ‘core.autocrlf’ の現
     在の設定に当てはまらない場合、Gitはそのファイルを拒否します。変数を
     ‘warn’ に設定でき、その場合、Gitは不可逆的な変換についてのみ警告は
     しますが、操作を続行します。

     CRLF変換には、データが破損する可能性がわずかにあります。有効にする
     と、Gitはコミット時にCRLFをLFに変換し、チェックアウト時にLFをCRLFに
     変換します。コミット前にLFとCRLFが混在しているファイルは、Gitでは復
     元できません。リポジトリにLF行末のみが含まれるように行末を修正する
     のは、テキストファイルの場合は正しい操作です。しかし、誤ってテキス
     トとして分類されたバイナリファイルの場合、変換によってデータが破損
     する可能性があります。

     あなたがこのような破損を早期に認識した場合は、 .gitattributes で変
     換タイプを明示的に設定することで簡単に修正できます。コミットした直
     後は、作業ツリーに元のファイルが残っており、このファイルはまだ破損
     していません。 このファイルはバイナリファイルなのだからと、Gitがフ
     ァイルを適切に処理することをGitに明示的に伝えることができます。

     残念ながら、行末が混在するテキストファイルをクリーンアップするとい
     う望ましい効果と、バイナリファイルを破損するという望ましくない効果
     を区別することはできません。どちらの場合も、CRLFは元に戻せない方法
     で削除されます。テキストファイルの場合、CRLFは行末であるため、これ
     は正しいことですが、バイナリファイルの場合、CRLFを変換するとデータ
     が破損します。

     注意: この安全性チェックは、チェックアウトによって、 ‘core.eol’ と
     ‘core.autocrlf’ の異なる設定に対して元のファイルと同じファイルが生
     成されることを意味するのではなく、現在のファイルに対してのみ生成さ
     れることに注意してください。 たとえば、 ‘LF’ を含むテキストファイル
     は ‘core.eol=lf’ で受け入れられ、後で ‘ core.eol=crlf‘ でチェックア
     ウトできます。この場合、結果のファイルには ‘CRLF’ が含まれますが、
     元のファイルには ‘LF`が含まれていました。 ただし、両方の作業ツリー
     で、行末は一貫しています。つまり、すべて `LF’ または、 すべて
     ‘CRLF’ のいずれかですが、混合されることはありません。行末が混在する
     ファイルは、 ‘core.safecrlf’ メカニズムによって報告されます。

core.autocrlf
     この変数を「true」に設定することは、すべてのファイルで「text」属性
     を「auto」に設定し、core.eolを「crlf」に設定することと同じです。 作
     業ディレクトリに ‘CRLF’ 行末があり、リポジトリにLF行末がある場合は
     、trueに設定します。 この変数は「input」に設定できます。この場合、
     出力変換は実行されません。

core.checkRoundtripEncoding
     ‘working-tree-encoding’ 属性で使用された場合に Git が UTF-8 のラウ
     ンドトリップチェックを行うエンコーディングの、カンマや空白で区切ら
     れたリスト(gitattributes(5) を参照)。デフォルト値は ‘SHIFT-JIS’ で
     す。

core.symlinks
     falseの場合、シンボリックリンクは、リンクテキストを含む小さなプレー
     ンファイルとしてチェックアウトされます。 git-update-index(1) と
     git-add(1) は、記録されたタイプを通常のファイルに変更しません。シン
     ボリックリンクをサポートしないFATのようなファイルシステムで役立ちま
     す。

     デフォルトは true ですが、git-clone(1) や git-init(1) はリポジトリ
     の作成時に core.symlinks を調査して必要に応じて core.symlinks を
     false に設定します。

core.gitProxy
     フェッチにGitプロトコルを使用する場合、リモートサーバーへの直接接続
     を確立する代わりに(「コマンドホストポート」として)実行する「プロキ
     シコマンド」。変数値が「COMMAND for DOMAIN」形式の場合、コマンドは
     、指定されたドメイン文字列で終わるホスト名にのみ適用されます。この
     変数は複数回設定でき、指定された順序で照合されます。最初にマッチし
     たものが採用されます。

     ‘GIT_PROXY_COMMAND’ 環境変数(特別な「for」処理なしで常に普遍的に適
     用されます)によってオーバーライドできます。

     特別な文字列 ‘none’ をプロキシコマンドとして使用して、特定のドメイ
     ンパターンにプロキシを使用しないように指定できます。これは、ファイ
     アウォール内のサーバをプロキシの使用から除外する一方で、外部ドメイ
     ンには共通のプロキシをデフォルトで使用する場合に便利です。

core.sshCommand
     この変数が設定されている場合、 ‘git fetch’ と ‘git push’ は、リモー
     トシステムに接続する必要があるときに、 ‘ssh’ の代わりに指定したコマ
     ンドを使用します。このコマンドは ‘GIT_SSH_COMMAND’ 環境変数と同じ形
     式であり、環境変数が設定されると上書きされます。

core.ignoreStat
     trueの場合、Gitはインデックスと作業ツリーの両方で同じように更新され
     た追跡ファイルの「assume-unchanged」(無変更と仮定する)ビットを設定
     することにより、ファイルが変更されたかどうかを検出するための
     lstat() 呼び出しを回避します。

     ファイルがGitの外部で変更される場合、ユーザーは変更されたファイルを
     明示的にステージングする必要があります(たとえば、
     git-update-index(1) の「Examples」セクションを参照)。 Gitは通常、こ
     れらのファイルへの変更を検出しません。

     これは、 CIFS/Microsoft Windows など、 lstat() 呼び出しが非常に遅い
     システムで役立ちます。

     false がデフォルトです。

core.preferSymlinkRefs
     HEADおよびその他のシンボリック参照ファイルのデフォルトの「symref」
     形式の代わりに、シンボリックリンクを使用します。これは、HEADがシン
     ボリックリンクであることを期待する古いスクリプトを操作するために必
     要になる場合があります。

core.alternateRefsCommand
     alternateから利用可能な履歴のヒントをアドバタイズする場合は、
     git-for-each-ref(1) の代わりに、シェルを使用して指定されたコマンド
     を実行します。最初の引数は、alternateの絶対パスです。出力には、1行
     に1つの16進オブジェクトIDが含まれている必要があります(つまり、 ‘git
     for-each-ref --format='%(objectname)'’ によって生成されたものと同じ
     ある必要があります)。

     注意: 通常、 あなたは ‘git for-each-ref’ をconfig値に直接入れること
     はできません。これは、リポジトリパスを引数として受け取らないためで
     す(ただし、あなたは上記のコマンドをシェルスクリプトでラップすること
     はできます)。

core.alternateRefsPrefixes
     alternateからの参照を一覧表示する場合は、指定のプレフィックスで始ま
     る参照のみを一覧表示します。プレフィックスは git-for-each-ref(1) へ
     の引数として指定されたかのようにマッチングします。複数のプレフィッ
     クスを一覧表示するには、それらを空白で区切ります。
     ‘core.alternateRefsCommand’ が設定されている場合、
     ‘core.alternateRefsPrefixes’ を設定しても効果ありません。

core.bare
     trueの場合、このリポジトリは「ベア」(bare;ベアリポジトリ)であると見
     なされ、作業ディレクトリは関連付けられていません。この場合、
     git-add(1) や git-merge(1) など、作業ディレクトリを必要とする多くの
     コマンドが無効になります。

     この設定は、リポジトリの作成時に git-clone(1) または git-init(1) に
     よって自動的に推測されます。 デフォルトでは、 ‘/.git’ で終わるリポ
     ジトリはベアではないと見なされ(bare = false)、他のすべてのリポジト
     リはベアであると見なされます(bare = true)。

core.worktree
     作業ツリーのルートへのパスを設定します。 ‘GIT_COMMON_DIR’ 環境変数
     が設定されている場合、 core.worktree は無視され、作業ツリーのルート
     を決定するために使用されません。core.worktree は ‘GIT_WORK_TREE’ 環
     境変数と ‘--work-tree’ コマンドラインオプションで上書きできます。値
     は、絶対パスまたは ‘.git’ ディレクトリへの相対パスにすることができ
     ます。これは、 ‘--git-dir’ または GIT_DIR 環境変数で指定されるか、
     ‘--git-dir’ や GIT_DIR 環境変数の指定が無い場合は自動的に検出されま
     す。‘--work-tree’ と GIT_WORK_TREE と core.worktree のいずれも指定
     されていない場合、現在の作業ディレクトリが作業ツリーの最上位と見な
     されます。

     注意: この変数は、ディレクトリの ‘.git｀ サブディレクトリ内の構成フ
     ァイルに設定されている場合でも適用され、その値は前者のディレクトリ
     とは異なることに注意してください(たとえば、 `/path/to/’ ディレクト
     リの ‘.git’ サブディレクトリ内の構成ファイル ‘/path/to/.git/config’
     内の core.worktree が ‘/different/path’ に設定されていたとする)、こ
     れはおそらく設定ミスです。あなたが ‘/path/to’ ディレクトリでGitコマ
     ンドを実行すると、引き続き ‘/different/path’ が作業ツリーのルートと
     して使用され、あなたが何をしているのか分かっている(たとえば、リポジ
     トリの通常の作業ツリーとは異なる場所に同じインデックスの読み取り専
     用スナップショットを作成している)のでない限り混乱を招く可能性があり
     ます。

core.logAllRefUpdates
     reflogを有効にします。新旧のSHA-1の追加や、日付/時刻・理由の更新に
     よる、refである <ref> の更新は、ファイル ‘$GIT_DIR/logs/<ref>’ が存
     在する場合のみ、そのファイルにロギングされます。この構成変数が
     ‘true’ に設定されている場合、欠落している ‘$GIT_DIR/logs/<ref>’ フ
     ァイルがブランチヘッド(つまり、 ‘refs/heads/’ 下)、リモートref(つま
     り、 refs/ 下)、note refs(つまり、 ‘refs/notes/’ 下)、およびシンボ
     リックref ‘HEAD’ 。 ‘always`に設定されている場合、欠落している
     reflogは、 `refs/’ 下のすべてのrefに対して自動的に作成されます。

     この情報を使用して、「2日前」(2 days ago)にブランチの先端であったコ
     ミットを判別できます。

     この値は、作業ディレクトリが関連付けられているリポジトリではデフォ
     ルトでtrueになり、ベアリポジトリではデフォルトでfalseになります。

core.repositoryFormatVersion
     リポジトリの形式とレイアウトのバージョンを識別する内部変数。

core.sharedRepository
     _group_ (または _true_ )の場合、リポジトリはグループ内の複数のユー
     ザー間で共有可能になります(すべてのファイルとオブジェクトがグループ
     書き込み可能であることを確認してください)。 _all_ (または _world_ ま
     たは _everybody_)の場合、リポジトリはグループ共有可能であることに加
     えて、すべてのユーザーが読み取り可能になります。 _umask_ (または
     _false_ )の場合、Gitは umask(2) によって報告された権限を使用します
     。「0xxx」(「0xxx」は8進数)の場合、リポジトリ内のファイルはこのモー
     ド値になります。「0xxx」はユーザーのumask値をオーバーライドします
     (他のオプションはユーザーのumask値の要求された部分のみをオーバーラ
     イドします)。例:「0660」は、所有者とグループがリポジトリを読み取り
     /書き込み可能にしますが、他のユーザーはアクセスできません(umaskが「
     0022」などでない限り、「group」と同等です)。 「0640」は、グループで
     読み取り可能ですが、グループで書き込み可能ではないリポジトリです。
     git-init(1) を参照してください。 デフォルトではFalseです。

core.warnAmbiguousRefs
     trueの場合、渡したref名があいまいでリポジトリ内の複数のrefと一致す
     る可能性がある場合、Gitは警告を表示します。 デフォルトではtrue。

core.compression
     デフォルトの圧縮レベルを示す整数 -1〜9。 -1はzlibのデフォルトです。
     0は圧縮がないことを意味し、1〜9はさまざまな速度とサイズのトレードオ
     フであり、9が最も低速です。設定されている場合、これは
     ‘core.looseCompression’ や ‘pack.compression’ などの他の圧縮変数の
     デフォルトを提供します。

core.looseCompression
     整数 -1〜9は、パックファイルにないオブジェクトの圧縮レベルを示しま
     す。-1はzlibのデフォルトです。0は圧縮がないことを意味し、1〜9はさま
     ざまな速度とサイズのトレードオフであり、9が最も低速です。設定されて
     いない場合、デフォルトは core.compression です。 これが設定されてい
     ない場合、デフォルトは1(最高速度)になります。

core.packedGitWindowSize
     1回のマッピング操作でメモリにマップするパックファイルのバイト数。ウ
     ィンドウサイズを大きくすると、システムが少数の大きなパックファイル
     をより迅速に処理できるようになる場合があります。ウィンドウサイズを
     小さくすると、オペレーティングシステムのメモリマネージャへの呼び出
     しが増えるため、パフォーマンスに悪影響を及ぼしますが、多数の大きな
     パックファイルにアクセスする場合のパフォーマンスが向上する可能性が
     あります。

     コンパイル時にNO_MMAPが設定されている場合、デフォルトは1Mバイトです
     。それ以外の場合、32ビットプラットフォームでは32Mバイト、64ビットプ
     ラットフォームでは1Gバイトです。これは、すべてのユーザー/オペレーテ
     ィングシステムにとって妥当なはずです。おそらくあなたはこの値を調整
     する必要はありません。

     _k_ または _m_ または _g_ の一般的な単位接尾辞がサポートされていま
     す。

core.packedGitLimit
     パックファイルからメモリに同時にマップする最大バイト数。Gitが操作を
     完了するために一度にこれ以上のバイトにアクセスする必要がある場合、
     Gitは既存の領域のマップを解除して、プロセス内の仮想アドレス空間を再
     利用します。

     デフォルトは、32ビットプラットフォームでは256Mバイト、64ビットプラ
     ットフォームでは32Tバイト(事実上無制限)です。これは、超巨大プロジェ
     クトを除いて、すべてのユーザー/オペレーティングシステムにとって妥当
     なはずです。あなたは、おそらくこの値を調整する必要はありません。

     _k_ または _m_ または _g_ の一般的な単位接尾辞がサポートされていま
     す。

core.deltaBaseCacheLimit
     複数の削除されたオブジェクトによって参照される可能性のあるベースオ
     ブジェクトをキャッシュするために予約するスレッドあたりの最大バイト
     数。解凍(decompress)されたベースオブジェクト全体をキャッシュに保存
     することで、Gitは頻繁に使用されるベースオブジェクトを何度もアンパッ
     クおよび解凍することを回避できます。

     デフォルトは、すべてのプラットフォームで96Mバイトです。これは、超巨
     大プロジェクトを除いて、すべてのユーザー/オペレーティングシステムに
     とって妥当なはずです。あなたは、おそらくこの値を調整する必要はあり
     ません。

     _k_ または _m_ または _g_ の一般的な単位接尾辞がサポートされていま
     す。

core.bigFileThreshold
     このサイズより大きいファイルは、デルタ圧縮を試行せずに、デフレート
     して保存されます。デルタ圧縮なしで大きなファイルを保存すると、ディ
     スク使用量が増えるというわずかな犠牲を払って、過度のメモリ使用量を
     回避できます。加えて、このサイズより大きいファイルは常にバイナリと
     して扱われます。

     デフォルトは、すべてのプラットフォームで512Mバイトです。ソースコー
     ドやその他のテキストファイルは依然としてデルタ圧縮できるため、これ
     はほとんどのプロジェクトにとって合理的ですが、より大きなバイナリメ
     ディアファイルにとっては合理的ではありません。

     _k_ または _m_ または _g_ の一般的な単位接尾辞がサポートされていま
     す。

core.excludesFile
     ‘.gitignore’ (ディレクトリごと)と ‘.git/info/exclude’ に加えて、追
     跡されることを意図されていないパスを記述するパターンを含むファイル
     へのパス名を指定します。 デフォルトは ‘$XDG_CONFIG_HOME/git/ignore’
     です。 ‘$XDG_CONFIG_HOME’ が設定されていないか空の場合、代わりに
     ‘$HOME/.config/git/ignore’ が使用されます。 gitignore(5) を参照して
     ください。

core.askPass
     パスワードを対話的に要求する一部のコマンド(svnやhttpインターフェイ
     スなど)は、この変数の値を介して指定された外部プログラムを使用するよ
     うに指示できます。 ‘GIT_ASKPASS’ 環境変数でオーバーライドできます。
     設定されていない場合は、 ‘SSH_ASKPASS’ 環境変数の値にフォールバック
     するか、それが失敗した場合は、単純なパスワードプロンプトにフォール
     バックします。外部プログラムには、コマンドライン引数として適切なプ
     ロンプトが与えられ、その標準出力にパスワードを書き出す事になってい
     ます。

core.attributesFile
     ‘.gitattributes’ (ディレクトリごと) と ‘.git/info/attributes’ に加
     えて、Gitはこのファイルで属性を調べます(gitattributes(5) を参照)。
     パスの拡張は、 ‘core.excludesFile’ の場合と同じ方法で行われます。デ
     フォルト値は ‘$XDG_CONFIG_HOME/git/attributes’ です。
     ‘$XDG_CONFIG_HOME’ が設定されていないか空の場合、代わりに
     ‘$HOME/.config/git/attributes’ が使用されます。

core.hooksPath
     デフォルトでは、Gitは ‘$GIT_DIR/hooks’ ディレクトリでフックを探しま
     す。これを別のパスに設定します。例えば ‘/etc/git/hooks’ です。そし
     てGitはそのディレクトリであなたのフックを見つけようとします。例えば
     ‘$GIT_DIR/hooks/pre-receive’ の代わりに
     ‘/etc/git/hooks/pre-receive’ です。

     パスは絶対パスでも相対パスでもかまいません。相対パスは、フックが実
     行されているディレクトリを基準にしたものと見なされます(githooks(5)
     の「DESCRIPTION」セクションを参照)。

     この設定変数は、あなたのGitフックをリポジトリごとに設定するのではな
     く一元的に設定したい場合や、デフォルトのフックを変更した
     ‘init.templateDir’ に代わるより柔軟で一元的な設定として有用です。

core.editor
     エディタを起動してメッセージを編集できる ‘commit’ や ‘tag’ などのコ
     マンドは、この変数が設定されているときにこの変数の値を使用し、環境
     変数 ‘GIT_EDITOR’ は設定されていません。 git-var(1) を参照してくだ
     さい。

core.commentChar
     メッセージを編集できる ‘commit’ や ‘tag’ などのコマンドは、この文字
     で始まるコメント行を考慮し、エディタから戻った後にそれらを削除しま
     す(デフォルトは ‘#’)。

     ‘auto’ に設定すると、 ‘git-commit’ は、既存のコミットメッセージのど
     の行の先頭文字でもない文字を選択します。

core.filesRefLockTimeout
     個々の参照をロックしようとしたときに再試行する時間の長さ(ミリ秒単位
     )。値0は、まったく再試行しないことを意味します。 -1 は無期限に試す
     ことを意味します。 デフォルトは100です(つまり、100ミリ秒再試行しま
     す)。

core.packedRefsTimeout
     ‘packed-refs’ ファイルをロックしようとしたときに再試行する時間の長
     さ(ミリ秒単位)。値0は、まったく再試行しないことを意味します。-1は無
     期限に試すことを意味します。デフォルトは1000です(つまり、1秒間再試
     行します)。

core.pager
     Gitコマンドで使用するテキストビューア(「less」など)。値はシェルによ
     って解釈されることを意図しています。 優先順位は、 ‘$GIT_PAGER’ 環境
     変数、 ‘core.pager’ 構成、 ‘$PAGER’ 、そしてコンパイル時に選択され
     たデフォルト(通常は _less_)です。

     ‘LESS’ 環境変数が設定されていない(unset)場合、Gitはそれを ‘FRX’ に
     設定(set)します(‘LESS’ 環境変数が設定されている場合は、Gitはそれを
     まったく変更しません)。Gitのデフォルト設定である ‘LESS’ を選択的に
     オーバーライドする場合は、 ‘core.pager’ を、例えば ‘less -S’ と設定
     できます。これはGitによってシェルに渡され、Gitは最後のコマンドを
     ‘LESS=FRX less -S’ に変換します。環境変数では ‘S’ オプションを設定
     しませんが、コマンドラインでは設定し、長い行を切り捨てるように指示
     します。同様に、 ‘core.pager’ を ‘less -+F’ に設定すると、環境変数
     によって指定された ‘F`オプションがコマンドラインによって非アクティ
     ブになり、 `less’ の「1画面の場合は終了」動作が非アクティブになりま
     す。特定のGitコマンドに対していくつかのフラグを特に指定してアクティ
     ブにすることができます。たとえば、 ‘pager.blame’ を ‘less -S’ に設
     定すると、 ‘git blame’ でのみページャーで行の切り捨てが有効になりま
     す。

     同様に、 ‘LV’ 環境変数が設定されていない場合、Gitはそれを ‘-c’ に設
     定します。この設定を上書きするには、 ‘LV’ を別の値でエクスポートす
     るか、 ‘core.pager’ を ‘lv +c’ に設定します。

core.whitespace
     注意すべき一般的な空白(whitespace)の問題のコンマ(‘,’)区切りのリスト
     。 _gitd iff_ は ‘color.diff.whitespace’ を使用してそれらを強調表示
     し、 ‘git apply --whitespace = error’ はそれらをエラーと見なします
     。 接頭辞 ‘-’ を付けて、それらのいずれかを無効にすることができます
     (例: ‘-trailing-space’):

        • ‘blank-at-eol’ は、行末の末尾の空白をエラーとして扱います(デフ
          ォルトで有効になっています)。

        • ‘space-before-tab’ は、行の最初のインデント部分のタブ文字の直
          前に表示されるスペース文字をエラーとして扱います(デフォルトで
          有効になっています)。

        • ‘indent-with-non-tab’ は、同等のタブではなくスペース文字でイン
          デントされた行をエラーとして扱います(デフォルトでは有効になっ
          ていません)。

        • ‘tab-in-indent’ は、行の最初のインデント部分にあるタブ文字をエ
          ラーとして扱います(デフォルトでは有効になっていません)。

        • ‘blank-at-eof’ は、ファイルの最後に追加された空白行をエラーと
          して扱います(デフォルトで有効になっています)。

        • ‘trailing-space’ は、‘ blank-at-eol‘ と ‘blank-at-eof’ の両方
          をカバーする省略形です。

        • ‘cr-at-eol’ は、行末のキャリッジリターンをラインターミネータの
          一部として扱います。つまり、そのようなキャリッジリターンの前の
          文字が空白(a whitespace)でない場合、 ‘trailing-space’ はトリガ
          ーされません(デフォルトでは有効になっていません)。

        • ‘tabwidth=<n>’ は、タブが占める文字数を示します。 これは、
          ‘indent-with-non-tab’ と、 Gitが ‘tab-in-indent’ エラーを修正
          する場合に関連します。デフォルトのタブ幅は8です。許可される値
          は1〜63です。

core.fsyncObjectFiles
     このブール値は、オブジェクトファイルを書き込むときに _fsync()_ を有
     効にします。

     これは、データの書き込みを適切に順序付けるファイルシステムでは時間
     と労力の無駄ですが、ジャーナル処理を使用しないファイルシステム(伝統
     的なUNIXファイルシステム)や、ファイルの内容ではなくメタデータのみを
     ジャーナル処理するファイルシステム(OS XのHFS+や、‘data=writeback’ な
     Linux ext3)で役立ちます。

core.preloadIndex
     _git diff_ などの操作のために並列インデックスプリロードを有効にする

     これにより、特にキャッシュセマンティクスが弱く、IOレイテンシが比較
     的高いNFSなどのファイルシステムで、「git diff」や「git status」など
     の操作を高速化できます。有効にすると、Gitはファイルシステムデータと
     のインデックス比較を並行して実行し、重複する入出力を許可します。デ
     フォルトはtrueです。

core.unsetenvvars
     Windowsのみ: 他のプロセスを生成する前に設定を解除する必要がある環境
     変数の名前のコンマ(‘,’)区切りのリスト。Git for Windowsが独自の
     Perlインタープリターの使用を主張しているという事実を説明するために
     、デフォルトは ‘PERL5LIB’ です。

core.restrictinheritedhandles
     Windowsのみ: 生成されたプロセスが標準のファイルハンドル( ‘stdin’ と
     ‘stdout’ と ‘stderr’)のみを継承するか、すべてのハンドルを継承するか
     をオーバーライドします。 ‘auto’ または ‘true’ または ‘false’ にする
     ことができます。デフォルトは ‘auto’ で、これはWindows7以降では
     ‘true’ を意味し、古いバージョンのWindowsでは ‘false’ を意味します。

core.createObject
     これを _link_ に設定できます。この場合、ハードリンク後のソース削除
     を、オブジェクトの作成が既存のオブジェクトが上書しないことをチェッ
     クするために使用します。

     一部のファイルシステム/オペレーティングシステムの組み合わせでは、こ
     れは信頼できませんので、この構成設定を _rename_ に設定します。ただ
     し、これにより、既存のオブジェクトファイルが上書きされないようにす
     るチェックが削除されます。

core.notesRef
     コミットメッセージを表示するときは、指定されたrefに保存されている
     note も表示します。refは完全に修飾されている必要があります。指定さ
     れたrefが存在しない場合、それはエラーではありませんが、noteを印刷し
     てはならないことを意味します。

     この設定のデフォルトは「refs/notes/commits」であり、
     ‘GIT_NOTES_REF’ 環境変数でオーバーライドできます。 git-notes(1) を
     参照してください。

core.commitGraph
     trueの場合、gitはcommit-graphファイル(存在する場合)を読み取り、コミ
     ットのグラフ構造をパースします。デフォルトはtrueです。詳細について
     は、 git-commit-graph(1) を参照してください。

core.useReplaceRefs
     ‘false’ に設定すると、コマンドラインで ‘--no-replace-objects’ オプ
     ションが指定されたかのように振る舞います。詳細については git(1) と
     git-replace(1) を参照してください。

core.multiPackIndex
     multi-pack-index ファイルを使用して、単一のインデックスを使用して複
     数のパックファイルを追跡します。詳細については
     git-multi-pack-index(1) を参照してください。デフォルトはtrueです。

core.sparseCheckout
     「スパースチェックアウト」(sparse checkout)機能を有効にします。 詳
     細については、 git-sparse-checkout(1) を参照してください。

core.sparseCheckoutCone
     スパースチェックアウト機能の「コーンモード」(cone mode)を有効にしま
     す。スパースチェックアウトファイルに含まれるパターンのセットが限ら
     れている場合、このモードはパフォーマンスに大きな利点をもたらします
     。詳細については git-sparse-checkout(1) を参照してください。

core.abbrev
     オブジェクト名の省略形の長さを設定します。指定されていないか「
     auto」に設定されている場合、リポジトリ内のパックされたオブジェクト
     のおおよその数に基づいて適切な値が計算されます。それは、省略された
     オブジェクト名がしばらくの間(some time)一意であるのに十分な長さです
     。「no」に設定すると、省略形は作成されず、オブジェクト名は完全な長
     さで表示されます。 最小の長さは4です。

add.ignoreErrors
add.ignore-errors (非推奨)
     インデックスエラーのために一部のファイルを追加できない場合にファイ
     ルの追加を続行するように ‘git add’ に指示します。 git-add(1) の
     ‘--ignore-errors’ オプションと同等です。 ‘add.ignore-errors’ は、構
     成変数の通常の命名規則に従わないため、非推奨になりました。

add.interactive.useBuiltin
     [EXPERIMENTAL](実験的)Perlスクリプトバージョンの代わりに、対話バー
     ジョンの git-add(1) の実験的な組み込み実装を使用するには、 ‘true’ に
     設定します。デフォルトでは ‘false’ です。

alias.*
     git(1) コマンドラッパーのコマンドエイリアス。例えば、 ‘alias.last =
     cat-file commit HEAD’ 定義後、 ‘git last’ の呼び出しは ‘git
     cat-file commit HEAD’ と同等です。スクリプトの使用に関する混乱や問
     題を回避するために、既存のGitコマンドを非表示にするエイリアスは無視
     されます。 引数はスペースで分割され、通常のシェルのクォートとエスケ
     ープがサポートされています。 引用符のペアまたはバックスラッシュ
     (‘\’)を使用して、それらをクォートすることができます。

     エイリアスの最初の単語は必ずしもコマンドである必要はないことに注意
     してください。 これは、‘git’ の呼び出しに渡されるコマンドラインオプ
     ションにすることができます。 特に、これは、 ‘-c’ を使用して1回限り
     の構成で渡す場合、または ‘-p’ を使用して強制的にページネーションを
     行う場合に役立ちます。 たとえば、 ‘loud-rebase = -c
     commit.verbose=true rebase’ は、‘git loud-rebase’ の実行が ‘git -c
     commit.verbose=true rebase’ と同等になるように定義できます。 また、
     ‘ps = -p status’ は便利なエイリアスで、 ‘git ps’ は ‘git status’ の
     出力をページ分割して出力します。

     エイリアス展開の前に感嘆符(‘!’)が付いている場合は、シェルコマンドと
     して扱われます。 たとえば、 ‘alias.new = !gitk --all --not
     ORIG_HEAD’ を定義すると、 ‘git new’ の呼び出しは、シェルコマンド
     ‘gitk --all --not ORIG_HEAD’ を実行するのと同じです。 シェルコマン
     ドは、リポジトリの最上位ディレクトリから実行されることに注意してく
     ださい。これは、必ずしも現在のディレクトリであるとは限りません。
     ‘GIT_PREFIX’ は、元のカレントディレクトリから ‘git rev-parse
     --show-prefix’ を実行したときに返される値が設定されます。
     git-rev-parse(1) を参照してください。

am.keepcr
     trueの場合、 ‘git-am’ は、パラメーター ‘--keep-cr’ を使用してmbox形
     式のパッチに対して‘ git-mailsplit‘ を呼び出します。 この場合、
     ‘git-mailsplit’ は ‘\r\n’ で終わる行から ‘\r’ を削除しません。 コマ
     ンドラインから ‘--no-keep-cr’ を指定することでオーバーライドできま
     す。 git-am(1) と git-mailsplit(1) を参照してください。

am.threeWay
     デフォルトでは、パッチが正しく適用されない場合、 ‘git am’ は失敗し
     ます。 trueに設定すると、この設定は、パッチが適用される予定のブロブ
     のIDを記録し、それらのブロブをローカルで使用できる場合に、3方向マー
     ジにフォールバックするように ‘git am’ に指示します(コマンドラインか
     ら ‘--3way’ オプションを指定するのと同じです)。 デフォルトは
     ‘false’ です。 git-am(1)を参照してください。

apply.ignoreWhitespace
     ‘change’ に設定すると、 ‘--ignore-space-change’ オプションと同じよ
     うに、空白の変更を無視するように ‘git apply’ に指示します。 ‘no’,
     ‘none’, ‘never’, ‘false’ のいずれかに設定すると、すべての空白の違い
     を尊重するように ‘git apply’ に指示されます。 git-apply(1) を参照し
     てください。

apply.whitespace
     ‘--whitespace’ オプションと同じ方法で、 ‘git apply’ に空白の処理方
     法を指示します。 git-apply(1) を参照してください。

blame.blankBoundary
     git-blame(1)で境界コミット(boundary commits)の空白コミットオブジェ
     クト名を表示します。このオプションのデフォルトはfalseです。

blame.coloring
     これにより、blame出力に適用される配色が決まります。 これは、
     ‘repeatedLines’ または ‘highlightRecent’ またはデフォルトの ‘none’
     にすることができます。

blame.date
     git-blame(1) で日付を出力するために使用される形式を指定します。 設
     定を解除すると、iso形式が使用されます。 サポートされている値につい
     ては、 git-log(1) の ‘--date’ オプションの説明を参照してください。

blame.showEmail
     git-blame(1) で、作者名(author)の代わりに作者の電子メールアドレス
     (author email)を表示します。 このオプションのデフォルトはfalseです
     。

blame.showRoot
     git-blame(1) ではルートコミットを境界として扱わないでください。 こ
     のオプションのデフォルトはfalseです。

blame.ignoreRevsFile
     git-blame(1) で、ファイルにリストされているリビジョン(1行に1つの省
     略されていないオブジェクト名)を無視します。 ‘#’ で始まる空白とコメ
     ントは無視されます。 このオプションは複数回繰り返すことができます。
     空のファイル名は、無視されたリビジョンのリストをリセットします。 こ
     のオプションは、コマンドラインオプション ‘--ignore-revs-file’ の前
     に処理されます。

blame.markUnblamableLines
     git-blame(1)の出力で ‘*’ を使用して、別のコミットに帰することができ
     なかった、無視されたリビジョンによって変更された行をマークします。

blame.markIgnoredLines
     git-blame(1)の出力で、別のコミットに起因する無視されたリビジョンに
     よって変更された行を ‘?’ でマークします。

branch.autoSetupMerge
     git-pull(1) が開始点ブランチから適切にマージされるように、 ‘git
     branch’ や ‘git switch’ や ‘git checkout’ に新しいブランチを設定す
     るように指示します。 このオプションが設定されていない場合でも、この
     動作は、 ‘--track’ や ‘--no-track’ オプションを使用してブランチごと
     に選択できることに注意してください。 有効な設定は次のとおりです:
     ‘false’ - 自動セットアップは行われません。 ‘true’ - 開始点がリモー
     ト追跡ブランチの場合、自動セットアップが実行されます。 ‘always’ - 自
     動セットアップは、開始点がローカルブランチまたはリモート追跡ブラン
     チのいずれかである場合に実行されます。 このオプションのデフォルトは
     trueです。

branch.autoSetupRebase
     別のブランチを追跡する ‘git branch’ または ‘git switch’ または ‘git
     checkout’ を使用して新しいブランチが作成されると、この変数はGitにマ
     ージではなくリベースするプルを設定するように指示します
     (‘branch.<name>.rebase’ 参照)。 ‘never’ の場合、リベースが自動的に
     trueに設定されることはありません。 ‘local’ の場合、他のローカルブラ
     ンチの追跡されたブランチに対してリベースがtrueに設定されます。
     ‘remote’ の場合、リモート追跡ブランチの追跡されたブランチに対してリ
     ベースがtrueに設定されます。 ‘always’ の場合、リベースはすべての追
     跡ブランチに対してtrueに設定されます。 別のブランチを追跡するために
     ブランチを設定する方法の詳細については、 ‘branch.autoSetupMerge’ を
     参照してください。 このオプションのデフォルトは ‘never’ です。

branch.sort
     この変数は、 git-branch(1) によって表示されるときのブランチの並べ替
     え順序を制御します。 ‘--sort=<value>’ オプションが指定されていない
     場合、この変数の値がデフォルトとして使用されます。 有効な値について
     は、 git-for-each-ref(1) のfield namesを参照してください。

branch.<name>.remote
     ブランチ<name>にいる場合、フェッチ元/プッシュ先 のリモートを ‘git
     fetch’ と ‘git push’ に通知します。 プッシュ先のリモートは、 (全ブ
     ランチ用の) ‘remote.pushDefault’ でオーバーライドできます。 現在の
     ブランチの場合、プッシュ先のリモートは、 ‘branch.<name>.pushRemote’
     によってさらにオーバーライドされる可能性があります。 リモートが構成
     されていない場合、またはブランチを使用していない場合、デフォルトで
     は、フェッチについては ‘origin’ に、プッシュについては
     ‘remote.pushDefault’ になります。 さらに、 ‘.’ (ピリオド)は現在のロ
     ーカルリポジトリ(ドットリポジトリ)です。下記の
     ‘branch.<name>.merge’ の最後の注意を参照してください。

branch.<name>.pushRemote
     ブランチ<name>にいる場合、プッシュするための ‘branch.<name>.remote’
     をオーバーライドします。 また、ブランチ<name>からプッシュするための
     ‘remote.pushDefault’ をオーバーライドします。 ある場所(あなたのアッ
     プストリームなど)から別の場所(独自の公開リポジトリなど)にプッシュす
     る場合は、 ‘remote.pushDefault’ を設定して、すべてのブランチにプッ
     シュするリモートを指定し、そして、このオプションを使用して 特定のブ
     ランチに対してオーバーライドします。

branch.<name>.merge
     branch.<name>.remote とともに、指定されたブランチのアップストリーム
     ブランチを定義します。 マージするブランチを ‘git fetch’/‘git
     pull’/‘git rebase’ に通知し、 ‘git push’ にも影響を与える可能性があ
     ります(push.default参照)。 ブランチ<name>にいる場合、FETCH_HEADでマ
     ージするためにマークされるデフォルトのrefspecを ‘git fetch’ に指示
     します。 値はrefspecのリモート部分のように処理され、
     ‘branch.<name>.remote ` で指定されたリモートからフェッチされたrefと
     一致する必要があります。 マージ情報は、マージのためにデフォルトのブ
     ランチを検索するために `git pull’ (最初に ‘git fetch’ を呼び出しま
     す)によって使用されます。 このオプションがない場合、 ‘git pull’ は
     デフォルトで、フェッチされた最初のrefspecをマージします。 octopusマ
     ージを取得するには、複数値を指定します。 あなたがローカルリポジトリ
     内の別のブランチから<name>にマージされるように ‘git pull’ を設定し
     たい場合は、branch.<name>.mergeが目的をブランチを指すようにして、そ
     して、 branch.<name>.remote に相対パス設定 ‘.’ (ピリオド)を使用でき
     ます。

branch.<name>.mergeOptions
     ブランチ<name>にマージするためのデフォルトオプションを設定します。
     構文とサポートされているオプションは git-merge(1) のものと同じです
     が、空白文字を含むオプション値は現在サポートされていません。

branch.<name>.rebase
     trueの場合、 ‘git pull’ の実行時にデフォルトのリモートからデフォル
     トのブランチをマージするのではなく、フェッチされたブランチの上にブ
     ランチ<name>をリベースします。 ブランチ固有ではない方法でこれを行う
     には、 ‘pull.rebase’ を参照してください。

     When ‘merges’ (or just _m_), pass the ‘--rebase-merges’ option to
     _git rebase_ so that the local merge commits are included in the
     rebase (see git-rebase(1) for details).

     ‘preserve’ (または単に ‘p’ 。‘merges’ を優先してこれは非推奨)の場合
     は、 ‘--preserve-merges’ を ‘git rebase’ に渡して、ローカルでコミッ
     トされたマージコミットが ‘git pull’ を実行してもフラット化されない
     ようにします。

     値が ‘interactive’ (または単に ‘i’)の場合、リベースは対話モードで実
     行されます。

     *注意*: これはおそらく危険な操作です。 あなたが影響を理解していない
     限り、使用しないでください (詳細については、 git-rebase(1) を参照し
     てください)。

branch.<name>.description
     ブランチの説明は、 ‘git branch --edit-description’ で編集できます。
     ブランチの説明は、format-patchのカバーレターまたはrequest-pullの概
     要に自動的に追加されます。

browser.<tool>.cmd
     指定したブラウザ(<tool>)を起動するコマンドを指定してください。 指定
     されたコマンドは、引数として渡されたURLを使用してシェルで評価されま
     す。 (git-web–browse(1) を参照してください。)

browser.<tool>.path
     HTMLヘルプ(git-help(1) の ‘-w’ オプション参照) または gitwebの作業
     リポジトリ(git-instaweb(1) 参照) をブラウズするために使用される可能
     性のある指定のツール(<tool>)のパス(path)をオーバーライドします。

checkout.defaultRemote
     ‘git checkout <something>’ または ‘git switch <something>’ を実行し
     、リモートが1つしかない場合、 ‘origin/<something>’ のチェックアウト
     と追跡に暗黙的にフォールバックする可能性があります。 ‘<something>’
     参照を持つリモートが複数あるとすぐに動作しなくなります。 この設定に
     より、曖昧性解消に関して常に勝利させる優先リモートの名前を設定でき
     ます。 典型的なユースケースは、これを ‘origin’ に設定することです。

     現在、これは git-switch(1) と git-checkout(1) によって、‘git
     checkout <something>’ や ‘git switch <something>’ が別のリモート上
     の ‘<something>’ ブランチをチェックアウトするときに使われています。
     また git-worktree(1) は ‘git worktree add’ がリモートブランチを参照
     しているときに使われています。 この設定は、将来、他のチェックアウト
     のようなコマンドまたは機能に使用される可能性があります。

checkout.guess
     ‘git checkout’ と ‘git switch’ の、 ‘--guess’ または ‘--no-guess’ オ
     プションのデフォルト値を提供します。 git-switch(1) および
     git-checkout(1) を参照してください。

checkout.workers
     作業ツリーを更新するときに使用する並列ワーカーの数。デフォルトは1、
     つまり順次実行です。 1未満の値に設定すると、Gitは使用可能な論理コア
     の数と同じ数のワーカーを使用します。 この設定と
     ‘checkout.thresholdForParallelism’ は、チェックアウトを実行するすべ
     てのコマンドに影響します。 例えば、 checkout, clone, reset,
     sparse-checkout, などです。

     注意: 並列チェックアウトは通常、SSDまたはNFS上にあるリポジトリのパ
     フォーマンスを向上させます。 回転するディスクやコアの数が少ないマシ
     ン上のリポジトリの場合、デフォルトのシーケンシャルチェックアウトの
     方がパフォーマンスが向上することがよくあります。 リポジトリのサイズ
     と圧縮レベルも、並列バージョンのパフォーマンスに影響を与える可能性
     があります。

checkout.thresholdForParallelism
     少数のファイルで並列チェックアウトを実行する場合、サブプロセスの生
     成とプロセス間通信のコストが並列化のメリットを上回る可能性がありま
     す。 この設定により、並列チェックアウトを試行する必要のあるファイル
     の最小数を定義できます。 デフォルトは100です。

clean.requireForce
     ‘-f’ または ‘-i’ または ‘-n’ が指定されない限り、git-clean が何もし
     ないようにするためのブール値です。 デフォルトは true です。

clone.defaultRemoteName
     リポジトリのクローンを作成するときに作成するリモートの名前。 デフォ
     ルトは ‘origin’ で、 ‘--origin’ コマンドラインオプションを
     git-clone(1) に渡すことでオーバーライドできます。

clone.rejectShallow
     リポジトリが浅い(shallow)場合は、リポジトリの複製(clone)を拒否しま
     す。コマンドラインでオプション ‘--reject-shallow’ を渡すことでオー
     バーライドできます。 git-clone(1) を参照してください

color.advice
     ヒントの色を有効/無効にするブール値(たとえば、プッシュが失敗した場
     合のリストについては ‘advice.*’ を参照します)。 ‘always’ または
     ‘false’(または ‘never’) または ‘auto’(または ‘true’) に設定でき、そ
     の場合、色は、エラー出力が端末に送信される場合にのみ使用されます。
     設定されていない場合は、 ‘color.ui’ の値が使用されます(デフォルトで
     は ‘auto’ )。

color.advice.hint
     ヒントにはカスタマイズされた色を使用します。

color.blame.highlightRecent
     これは、行の履歴年代(age)に応じて、blame行のメタデータに色を付ける
     ために使用できます。

     この設定は、色と日付設定のコンマ区切りリストに設定する必要がありま
     す。色で開始および終了し、日付は古いものから新しいものへと設定する
     必要があります。 指定されたタイムスタンプの前に行が導入された場合、
     メタデータは指定の色付けされ、古いタイムスタンプの色を上書きします
     。

     絶対タイムスタンプの代わりに、相対タイムスタンプも機能します。例え
     ば、‘2.weeks.ago’ は、2週間より古いものに対処するために有効です。

     デフォルトは ‘blue,12 month ago,white,1 month ago,red’ で、1年以上
     前のすべてを青に色付けし、1か月前から1年前までの変更は白のままにし
     、先月に導入された行赤に色付けします。

color.blame.repeatedLines
     行ごとにメタ情報が繰り返されるgit-blame出力の部分(コミットID、作成
     者名、日付、タイムゾーンなど)にカスタマイズ色を使用します。デフォル
     トは ‘cyan’ (シアン) です。

color.branch
     git-branch(1) の出力で色を有効/無効にするブール値。 ‘always’ または
     ‘false’(または ‘never’) または ‘auto’(または ‘true’)に設定でき、そ
     の場合、色は出力が端末への場合にのみ使用されます。 設定されていない
     場合は、 ‘color.ui’ の値が使用されます(デフォルトでは ‘auto’)。

color.branch.<slot>
     ブランチの色付けにスタマイズ色を使用します。 ‘<slot>’ は、
     ‘current’(現在のブランチ)、 ‘local’(ローカルブランチ)、
     ‘remote’(‘refs/remotes/’ 内のリモート追跡ブランチ)、 ‘upstream’(ア
     ップストリーム追跡ブランチ）、 ‘plain’(その他のref)、のいずれかです
     。

color.diff
     ANSIエスケープシーケンスを使用してパッチに色を追加するかどうか。 こ
     れが ‘always’ に設定されている場合、 git-diff(1) と git-log(1) と
     git-show(1) はすべてのパッチに色を使用します。 ‘true’ または ‘auto’
     に設定されている場合、これらのコマンドは、端末への出力時にのみ色を
     使用します。 設定されていない場合は、 ‘color.ui’ の値が使用されます
     (デフォルトでは ‘auto’)。

     これは、 git-format-patch(1) または ‘git-diff-{asterisk}’ 配管コマ
     ンドには影響しません。 ‘--color[=<when>]’ オプションを使用してコマ
     ンドラインでオーバーライドできます。

color.diff.<slot>
     diffカラー化にカスタマイズ色を使用します。 ‘<slot>’ は、パッチのど
     の部分で指定された色を使用するかを指定します。 次のいずれか一つです
     : ‘context’(コンテキストテキスト。 ‘plain’ は歴史的な同義語です)、
     ‘meta’(メタ情報)、 ‘frag’(ハンクヘッダー)、 ‘func’(ハンクヘッダーの
     関数)、 ‘old’(削除された行)、 ‘new’(追加された行)、 ‘commit’(コミッ
     トヘッダー)、 ‘whitespace’(空白エラーを強調表示)、 ‘oldMoved’(削除
     された複数行)、 ‘newMoved’(追加された複数行)、 ‘oldMovedDimmed’ 、
     ‘oldMovedAlternative’ 、 ‘oldMovedAlternativeDimmed’ 、
     ‘newMovedDimmed’ 、 ‘newMovedAlternative’ 、
     ‘newMovedAlternativeDimmed’(詳細については、 git-diff(1) の
     ‘--color-moved’ の ‘<mode>’ 設定参照)、 ‘contextDimmed’ 、
     ‘oldDimmed’ 、 ‘newDimmed’ 、‘contextBold’ 、 ‘oldBold’ 、
     ‘newBold’(詳細については git-range-diff(1) 参照)。

color.decorate.<slot>
     ‘git log --decorate’ 出力にカスタマイズ色を使用します。 ‘<slot>’ に
     はそれぞれ、ローカルブランチ、リモート追跡ブランチ、タグ、stash、
     HEADと、graftedコミットをあらわす、 ‘branch’ 、‘remoteBranch’ 、
     ‘tag’ 、 ‘stash’ 、 ‘HEAD’ 、 ‘grafted’ のうちの一つを指定します。

color.grep
     ‘always’ に設定すると、常に一致を強調表示します。 ‘false’(または
     ‘never’)の場合、決して一致を強調表示しません。 ‘true’ または ‘auto’
     に設定すると、出力が端末に書き込まれる場合にのみ色を使用します。 設
     定されていない場合は、 ‘color.ui’ の値が使用されます(デフォルトでは
     ‘auto’)。

color.grep.<slot>
     grepの色付けにカスタマイズ色を使用します。 ‘<slot>’ は、指定の色を
     使用する行の部分を指定します。

     ‘context’
          コンテキスト行の非一致テキスト(‘-A’ または ‘-B’ または ‘-C’ 使
          用時)

     ‘filename’
          ファイル名接頭辞(‘-h’ 使用時以外)

     ‘function’
          関数名行(‘-p’ 使用時)

     ‘lineNumber’
          行番号接頭辞(‘-n’ 使用時)

     ‘column’
          桁番号接頭辞(‘--column’ 使用時)

     ‘match’
          一致テキスト(‘matchContext’ と ‘matchSelected’ の設定と同じ)

     ‘matchContext’
          内容行の一致テキスト

     ‘matchSelected’
          選択行の一致テキスト

     ‘selected’
          選択行の非一致テキスト

     ‘separator’
          行内のフィールド間セパレータ(‘:’ と ‘-’ と ‘=’)と、ハンク間セ
          パレータ(‘--’)

color.interactive
     ‘always’ に設定すると、対話プロンプトと表示には常に色を使用します
     (‘git-add --interactive’ や ‘git-clean --interactive`で使用されるも
     のなど)。 false(または `never’)の場合、決して色を使用しません。
     ‘true’ または ‘auto’ に設定すると、出力が端末に向けられている場合に
     のみ色を使用します。 設定されていない場合は、 ‘color.ui’ の値が使用
     されます(デフォルトでは ‘auto’)。

color.interactive.<slot>
     ‘git add --interactive’ および ‘git clean --interactive’ 出力にカス
     タマイズ色を使用します。 ‘<slot>`は、対話コマンドからの通常の出力の
     4つの異なるタイプに対して、 `prompt’ または ‘header’ または ‘help’
     または ‘error’ の場合があります。

color.pager
     ‘auto’ カラーモードがページャーに送られる出力を色付けするかどうかを
     指定するブール値。 デフォルトはtrueです。 ページャーがANSIカラーコ
     ードを理解しない場合は、これをfalseに設定します。

color.push
     プッシュエラーで色を有効/無効にするブール値。 ‘always’ 、 ‘false’(ま
     たは ‘never’)または ‘auto’(または ‘true’)に設定でき、その場合、色は
     エラー出力が端末に送られる場合にのみ使用されます。 設定されていない
     場合は、 ‘color.ui’ の値が使用されます(デフォルトでは ‘auto’)。

color.push.error
     プッシュエラーのカスタマイズされた色に使用。

color.remote
     設定されている場合、行の先頭にあるキーワードが強調表示されます。 キ
     ーワードは ‘error’ と ‘warning’ と ‘hint’ と ‘success’ であり、大文
     字と小文字を区別せずに照合されます。 ‘always’ または ‘false’(または
     ‘never’)または ‘auto’(または ‘true’)に設定できます。 設定されていな
     い場合は、 ‘color.ui’ の値が使用されます(デフォルトでは ‘auto’)。

color.remote.<slot>
     リモートキーワードごとにカスタマイズ色を使用します。 ‘<slot>’ は、
     対応するキーワードに一致する ‘hint’ または ‘warning’ または
     ‘success’ または ‘error’ の場合があります。

color.showBranch
     linkgit：git-show-branch[1]の出力で色を有効/無効にするブール値。
     ‘always’ 、‘false’(または ‘never’)または ‘auto’ (または ‘true’) に
     設定でき、その場合、色は出力が端末への場合にのみ使用されます。 設定
     されていない場合は、 ‘color.ui’ の値が使用されます(デフォルトでは
     ‘auto’)。

color.status
     git-status(1) の出力で色を有効/無効にするブール値。 ‘always’ 、
     ‘false’(または ‘never’)または ‘auto’(または ‘true’)に設定でき、その
     場合、色は出力が端末への場合にのみ使用されます。 設定されていない場
     合は、 ‘color.ui’ の値が使用されます(デフォルトでは ‘auto’)。

color.status.<slot>
     ステータスの色付けにカスタマイズ色を使用します。 ‘<slot>’ は次から
     一つを選択します。 ‘header’(ステータスメッセージのヘッダーテキスト
     )、 ‘added’ または ‘updated’((追加されたがコミットされていないファ
     イル)、 ‘changed’(変更されたがインデックスに追加されていないファイ
     ル)、 ‘untracked’(Git によって追跡されていないファイル)、
     ‘branch’(現在のブランチ)、 ‘nobranch’(「no branch」警告を表示する色
     。デフォルトは赤)、 ‘localBranch’ または ‘remoteBranch’(ブランチと
     追跡情報をステータス表示する際の、ローカルブランチとリモートブラン
     チの名前) または ‘unmerged’ (変更がマージされていないファイル)

color.transport
     プッシュが拒否されたときに色を有効/無効にするブール値。 ‘always’ 、
     ‘false’(または ‘never’)または ‘auto’(または ‘true’)に設定でき、その
     場合、色はエラー出力が端末に送られる場合にのみ使用されます。 設定さ
     れていない場合は、 ‘color.ui’ の値が使用されます(デフォルトでは
     ‘auto’)。

color.transport.rejected
     プッシュが拒否された時に使うカスタマイズ色。

color.ui
     この変数は、コマンドファミリごとの色の使用を制御する ‘color.diff’ や
     ‘color.grep’ などの変数のデフォルト値を決定します。 より多くのコマ
     ンドが ‘--color’ オプションのデフォルトを設定するための構成を習得す
     るにつれて、その範囲は拡大します。 他の構成または ‘--color’ オプシ
     ョンで明示的に有効にしない限り、Gitコマンドで色を使用しないようにす
     る場合は、‘false’ または ‘never’ に設定します。 機械での利用を目的
     としない、すべての出力でカラーを使用する場合は ‘always’ に設定し、
     端末への書き込み時にそのような出力でカラーを使用する場合は ‘true’ ま
     たは ‘auto’ (これはGit 1.8.4以降のデフォルトです)に設定します。

column.ui
     サポートされているコマンドを列(column)で出力するかどうかを指定しま
     す。 この変数は、スペースまたはコンマで区切られたトークンのリストで
     構成されます:

     以下のオプションは、機能を有効にするタイミングを制御します(デフォル
     トは ‘never’):

     ‘always’
          常に列表示

     ‘never’
          決して列表示しない

     ‘auto’
          端末へ出力の場合は列表示

     以下のオプションはレイアウトを制御します(デフォルトは ‘column’)。
     ‘always’ や ‘never’ や ‘auto’ のいずれも指定されていない場合に、以
     下のいずれかを設定すると、 ‘always’ の指定を含みます。

     ‘column’
          行の前に列を埋める

     ‘row’
          列の前に行を埋める

     ‘plain’
          1つの列に表示

     最後に、以下のオプションはレイアウトオプションと組み合わせることが
     できます(デフォルトは ‘nodense’):

     ‘dense’
          より多くのスペースを利用するために不等サイズの列を作成する

     ‘nodense’
          同じサイズの列を作成する

column.branch
     ‘git branch’ でブランチリストを列出力するかどうかを指定します。 詳
     細については、 ‘column.ui’ を参照してください。

column.clean
     ‘git clean -i’ でアイテムを一覧表示するときのレイアウトを指定します
     。これにより、常にファイルとディレクトリが列表示されます。 詳細につ
     いては、 ‘column.ui’ を参照してください。

column.status
     ‘git status’ で追跡されていないファイルを列表示するかどうかを指定し
     ます。 詳細については、 ‘column.ui’ を参照してください。

column.tag
     ‘git tag’ でタグリストを列出力するかどうかを指定します。 詳細につい
     ては、 ‘column.ui’ を参照してください。

commit.cleanup
     この設定は、 ‘git commit’ の ‘--cleanup’ オプションのデフォルトを上
     書きします。 詳細については、 git-commit(1) を参照してください。 デ
     フォルトを変更すると、コメント文字 ‘#’ で始まる行をログメッセージに
     常に残しておきたい場合に役立ちます。その場合は、 ‘git config
     commit.cleanup whitespace’ を実行します(注意:これを行う場合は、コミ
     ットログテンプレートの ‘#’ で始まるヘルプ行を自分で削除する必要があ
     ることに注意してください)。

commit.gpgSign
     すべてのコミットをGPG署名する必要があるかどうかを指定するブール値。
     リベースなどの操作を行うときにこのオプションを使用すると、多数のコ
     ミットが署名される可能性があります。 エージェントを使用して、GPGパ
     スフレーズの入力を省略するようにすると便利な場合があります。

commit.status
     エディタを使用してコミットメッセージを準備するときに、コミットメッ
     セージテンプレートにステータス情報を含めることを有効/無効にするブー
     ル値。 デフォルトはtrueです。

commit.template
     新しいコミットメッセージのテンプレートとして使用するファイルのパス
     名を指定します。

commit.verbose
     ‘git commit’ でverboseレベルを指定するブール値またはint。
     git-commit(1) を参照してください。

commitGraph.generationVersion
     commit-graph ファイルの書き込みまたは読み取り時に使用する世代番号バ
     ージョン(generation number version)のタイプを指定します。 バージョ
     ン 1 が指定されている場合、修正されたコミット日付は書き込まれたり読
     み取られたりしません。 デフォルトは 2 です。

commitGraph.maxNewFilters
     ‘git commit-graph write’ の ‘--max-new-filters’ オプションのデフォ
     ルト値を指定します(git-commit-graph(1) 参照)。

commitGraph.readChangedPaths
     trueの場合、gitはcommit-graphファイルで変更パスブルームフィルター
     (the changed-path Bloom filters)を使用します(存在し、有効な場合)。
     デフォルトはtrueです。 詳細については、 git-commit-graph(1) を参照
     してください。

credential.helper
     ユーザー名またはパスワードの資格情報が必要なときに呼び出される外部
     ヘルパーを指定します。ヘルパーは、ユーザーに資格情報の入力を求めな
     いように、外部ストレージを参照する場合があります。これは通常、可能
     な引数を持つ資格情報ヘルパーの名前ですが、引数を持つ絶対パス、また
     は ‘!’ が前に付いている場合はシェルコマンドの場合もあります。

     注意: 複数のヘルパーが定義されている場合があることに注意してくださ
     い。詳細と例については、 gitcredentials(7) を参照してください。

credential.useHttpPath
     資格情報を取得するとき、http URL または https URL のパス部分を重要
     視します。デフォルトはfalseです。詳細については、 gitcredentials(7)
     を参照してください。

credential.username
     ネットワーク認証にユーザー名が設定されていない場合は、デフォルトで
     このユーザー名を使用します。 以下の credential.<context>.* と
     gitcredentials(7) を参照してください。

credential.<url>.*
     上記の credential.* オプションは、一部の資格情報に選択的に適用でき
     ます。 たとえば、 "credential.https://example.com.username" は、
     example.com への https 接続に対してのみデフォルトのユーザー名を設定
     します。 URLの照合方法の詳細については、 gitcredentials(7) を参照し
     てください。

credentialCache.ignoreSIGHUP
     git-credential-cache—daemon に、終了する代わりにSIGHUPを無視するよ
     うに指示します。

credentialStore.lockTimeoutMS
     資格情報ファイルをロックしようとしたときに git-credential-store が
     再試行する時間の長さ(ミリ秒単位)。値0は、まったく再試行しないことを
     意味します。-1は無期限に試すことを意味します。デフォルトは1000です
     (つまり、1秒間再試行します)。

completion.commands
     これは、補完コマンドのリストからコマンドを追加または削除するために
     git-completion.bashによってのみ使用されます。通常、磁器コマンドと、
     いくつかの選択されたコマンドのみが補完します。この変数には、スペー
     スで区切ってコマンドを追加できます。 コマンドの前に ‘-’ を付けると
     、既存のリストから削除されます。

diff.autoRefreshIndex
     _git diff_ を使用して作業ツリーファイルと比較する場合、統計のみの変
     更を変更されたものと見なさない。代わりに、サイレントに ‘git
     update-index --refresh’ を実行して、ワークツリーの内容がインデック
     スの内容と一致するパスの、キャッシュされた統計情報を更新します。こ
     のオプションのデフォルトはtrueです。注意: これは ‘git diff’ 磁器コ
     マンドにのみ影響し、 ‘git diff-files’ などの下位レベルのdiffコマン
     ドには影響しないことに注意してください。

diff.dirstat
     git-diff(1) およびその仲間に対する ‘--dirstat’ オプションのデフォル
     トの動作を指定する ‘--dirstat’ パラメーターのコンマ区切りリスト。デ
     フォルトは(‘--dirstat=<param1,param2,...>’ を使用して)コマンドライ
     ンでオーバーライドできます。フォールバックのデフォルトは
     ‘changes,noncumulative,3’ です(‘diff.dirstat’ によって変更されてい
     ない限り)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加 された行数を合計し
          て、dirstat数を計算します。(バイナリファイルの場合、バイナリフ
          ァイルには行の自然な概念がないため、代わりに64バイトのチャンク
          をカウントします)。 これは ‘changes’ 動作よりもコストのかかる
          ‘--dirstat’ 動作ですが、他の変更と同じようにファイル内の再配置
          された行をカウントします。 結果の出力は、他の ‘--*stat’ オプシ
          ョンから得られるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          も安価な ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更もカウントします。
          ‘cumulative’ を使用する場合、報告されるパーセンテージの合計が
          100％を超える場合があることに注意してください。 デフォルトの
          (非累積的な)動作は、 ‘non-cumulative’ パラメーターで指定できま
          す。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。変更への貢献がこの割合より少ないディレクトリは出力に
          表示されません。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウントする: ‘files,10,cumulative’

diff.statGraphWidth
     ‘--stat’ 出力でグラフ部分の幅を制限します。設定されている場合、
     format-patchを除く ‘--stat’ 出力を生成するすべてのコマンドに適用さ
     れます。

diff.context
     デフォルトの3ではなく<n>行のコンテキストで差分を生成します。この値
     は ‘-U’ オプションによってオーバーライドされます。

diff.interHunkContext
     指定された行数までのdiffハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。この値は、 ‘--inter-hunk-context’ コ
     マンドラインオプションのデフォルトとして機能します。

diff.external
     この構成変数が設定されている場合、diffの生成は、内部のdiff機構を使
     用して実行されるのではなく、指定されたコマンドを使用して実行されま
     す。 ‘GIT_EXTERNAL_DIFF’ 環境変数でオーバーライドできます。このコマ
     ンドは、 git(1) の「git Diffs」で説明されているパラメーターを使用し
     て呼び出されます。 注意: ファイルのサブセットでのみ外部diffプログラ
     ムを使用する場合は、代わりに gitattributes(5) を使用することをお勧
     めします。

diff.ignoreSubmodules
     ‘--ignore-submodules’ のデフォルト値を設定します。これは ‘git diff’
     磁器コマンドにのみ影響し、 ‘git diff-files’ などの下位レベルの
     diffコマンドには影響しないことに注意してください。 ‘git checkout’ や
     ‘git switch’ も、コミットされていない変更を報告するときにこの設定を
     尊重します。 _all_ に設定すると、 ‘--ignore-submodules’ コマンドラ
     インオプションを使用してオーバーライドされない限り、
     ‘status.submoduleSummary’ が設定されている場合、通常は _git commit_
     および _git status_ で表示されるサブモジュールの概要が無効になりま
     す。 _git submodule_ コマンドは、この設定の影響を受けません。デフォ
     ルトでは、これは untracked に設定されているため、追跡されていないサ
     ブモジュールはすべて無視されます。

diff.mnemonicPrefix
     設定されている場合、 ‘git diff’ は、比較対象に応じて標準の _a/_ や
     _b/_ とは異なるプレフィックスのペアを使用します。この構成が有効な場
     合、逆差分出力でもプレフィックスの順序が入れ替わります:

     ‘git diff’
          (i)ndex と (w)ork tree を比較

     ‘git diff HEAD’
          (c)ommit と (w)ork tree を比較

     ‘git diff --cached’
          (c)ommit と (i)ndex を比較

     ‘git diff HEAD:file1 file2’
          (o)bject と (w)ork tree エンティティを比較

     ‘git diff --no-index a b’
          2つの非git項目 (1) と (2) を比較

diff.noprefix
     設定されている場合、 ‘git diff’ は送信元または宛先のプレフィックス
     を表示しません。

diff.relative
     _true_ に設定すると、 _git diff_ はディレクトリ外の変更を表示せず、
     現在のディレクトリへの相対的なパス名を表示します。

diff.orderFile
     diff内でファイルを並べ替える方法を示すファイル。 詳細については、
     git-diff(1) の ‘-O’ オプションを参照してください。 ‘diff.orderFile’
     が相対パス名の場合、作業ツリーの最上位を基準として扱います。

diff.renameLimit
     コピー/名前変更 の検出の徹底的な部分で考慮するファイルの数。 _git
     diff_ の ‘-l’ オプションと同等です。設定されていない場合、デフォル
     ト値は現在1000です。この設定は、名前変更の検出がオフになっている場
     合は効果がありません。

diff.renames
     Gitが名前の変更を検出するかどうかとその方法。 "false" に設定すると
     、名前変更の検出が無効になります。 "true" に設定すると、基本的な名
     前変更の検出が有効になります。 "copies" または "copy" に設定されて
     いる場合、Gitはコピーも検出します。デフォルトはtrueです。これは
     git-diff(1) や git-log(1) のような _git diff_ 磁器コマンドにのみ影
     響し、 git-diff-files(1) などの下位レベルのコマンドには影響しないこ
     とに注意してください。

diff.suppressBlankEmpty
     空の出力行の前にスペースを印刷する標準的な動作を禁止するブール値。
     デフォルトはfalseです。

diff.submodule
     サブモジュールの違いを表示する形式を指定します。 "short" 形式は、範
     囲の最初と最後にコミットの名前を表示するだけです。 "log" 形式は、
     git-submodule(1) の ‘summary’ のように範囲内のコミットをリストしま
     す。 "diff" 形式は、サブモジュールの変更された内容のインライン
     diffを示します。デフォルトは "short" です。

diff.wordRegex
     単語ごとの差の計算を実行するときに「単語」(word)とは何かを判別する
     ために使用されるPOSIX拡張正規表現。正規表現に一致する文字シーケンス
     は「単語」(words)であり、他のすべての文字は*無視できる*空白
     (whitespace)です。

diff.<driver>.command
     カスタムdiffドライバーコマンド。詳細については gitattributes(5) を
     参照してください。

diff.<driver>.xfuncname
     diffドライバーがハンクヘッダーを認識するために使用する必要がある正
     規表現。内蔵パターンを使用することもできます。詳細については
     gitattributes(5) を参照してください。

diff.<driver>.binary
     このオプションをtrueに設定すると、diffドライバーがファイルをバイナ
     リとして処理します。詳細については gitattributes(5) を参照してくだ
     さい。

diff.<driver>.textconv
     ファイルのテキスト変換バージョンを生成するためにdiffドライバーが呼
     び出す必要のあるコマンド。変換の結果は、人間が読める形式のdiffを生
     成するために使用されます。詳細については gitattributes(5) を参照し
     てください。

diff.<driver>.wordRegex
     diffドライバーが単語(words)を1行に分割するために使用する必要がある
     正規表現。詳細については gitattributes(5) を参照してください。

diff.<driver>.cachetextconv
     このオプションをtrueに設定すると、diffドライバーがテキスト変換出力
     をキャッシュするようになります。詳細については gitattributes(5) を
     参照してください。

diff.tool
     git-difftool(1) によって使用されるdiffツールを制御します。この変数
     は、 ‘merge.tool’ で構成された値をオーバーライドします。以下のリス
     トは、有効な組み込み値を示しています。その他の値はカスタムdiffツー
     ルとして扱われ、対応する difftool.<tool>.cmd 変数が定義されている必
     要があります。

diff.guitool
     ‘-g/--gui’ フラグが指定されている場合に、 git-difftool(1) が使用す
     るdiffツールを制御します。この変数は、 ‘merge.guitool’ で構成された
     値をオーバーライドします。以下のリストは、有効な組み込み値を示して
     います。その他の値はカスタムdiffツールとして扱われ、対応する
     difftool.<guitool>.cmd 変数が定義されている必要があります。

        • araxis

        • bc

        • bc3

        • bc4

        • codecompare

        • deltawalker

        • diffmerge

        • diffuse

        • ecmerge

        • emerge

        • examdiff

        • guiffy

        • gvimdiff

        • gvimdiff1

        • gvimdiff2

        • gvimdiff3

        • kdiff3

        • kompare

        • meld

        • nvimdiff

        • nvimdiff1

        • nvimdiff2

        • nvimdiff3

        • opendiff

        • p4merge

        • smerge

        • tkdiff

        • vimdiff

        • vimdiff1

        • vimdiff2

        • vimdiff3

        • winmerge

        • xxdiff

diff.indentHeuristic
     このオプションを ‘false’ に設定すると、パッチを読みやすくするために
     diffハンク境界をシフトするデフォルトのヒューリスティックが無効にな
     ります。

diff.algorithm
     diffアルゴリズムを選択します。 派生形は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム。現在、これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして。可能な限り最小の差分が生成されるよう
          にします。

     ‘patience’
          パッチを生成するときは、patience diff(忍耐差分)アルゴリズムを
          使用してください。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズムを拡張して、「発生頻度の低
          い共通要素をサポート」(support low-occurrence common
          elements)します。

diff.wsErrorHighlight
     差分の ‘context’ または ‘old または `new’ 行の空白エラー(whitespace
     errors)を強調表示します。複数の値はコンマで区切られ、 ‘none’ は前の
     値をリセットし、 ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は
     ‘old,new,context’ の省略形です。空白のエラー(whitespace errors)は
     ‘color.diff.whitespace’ で色分けされています。コマンドラインオプシ
     ョン ‘--ws-error-highlight=<kind>’ はこの設定を上書きします。

diff.colorMoved
     有効な ‘<mode>’ またはtrueのいずれかに設定すると、diff内の移動され
     た行が異なる色で表示されます。有効なモードの詳細については、
     git-diff(1) の ‘--color-moved’ を参照してください。単にtrueに設定す
     ると、デフォルトのカラーモードが使用されます。 falseに設定すると、
     移動した行は色付けされません。

diff.colorMovedWS
     このオプションは、例えば ‘diff.colorMoved’ 設定を使用して移動した行
     に色を付ける場合、スペース(spaces)をどのように扱うかを ‘<mode>’ で
     制御します。有効なモードの詳細については git-diff(1) の
     ‘--color-moved-ws’ を参照してください。

difftool.<tool>.path
     指定のツール(<tool>)のパスを上書きします。これは、あなたのツールが
     PATHにない場合に役立ちます。

difftool.<tool>.cmd
     指定のdiffツール(<tool>)を呼び出すコマンドを指定します。指定された
     コマンドは、次の変数を使用してシェルで評価されます: ‘LOCAL’ は、
     diff pre-imageの内容を含む一時ファイルの名前に設定され、 ‘REMOTE’ は
     、diff post-imageの内容を含む一時ファイルの名前に設定されます。

difftool.prompt
     diffツールを呼び出す前にプロンプトを表示します。

extensions.objectFormat
     使用するハッシュアルゴリズムを指定します。 許容値は ‘sha1’ と
     ‘sha256’ です。 指定しない場合、 ‘sha1’ が想定されます。
     ‘core.repositoryFormatVersion’ が1でない限り、このキーを指定すると
     エラーになります。

     注意: この設定は、git-init(1) または git-clone(1) によってのみ設定
     する必要があることに注意してください。 初期化後に変更しようとすると
     機能せず、診断が難しい問題が発生します。

fastimport.unpackLimit
     git-fast-import(1) によってインポートされたオブジェクトの数がこの制
     限を下回る場合、オブジェクトは緩いオブジェクト(loose object)ファイ
     ルに解凍されます。 ただし、インポートされたオブジェクトの数がこの制
     限以上の場合、パックはパックとして保存されます。 fast-import(高速イ
     ンポート)からパックを保存すると、特に低速のファイルシステムで、イン
     ポート操作をより速く完了することができます。 設定されていない場合は
     、代わりに ‘transfer.unpackLimit’ の値が使用されます。

feature.*
     ‘feature.’ で始まる構成設定は、他の構成設定のグループのデフォルトを
     変更します。 これらのグループは、Git開発者コミュニティによって推奨
     されるデフォルトとして作成されており、変更される可能性があります。
     特に、新しい構成オプションが異なるデフォルトで追加される場合があり
     ます。

feature.experimental
     Gitの新機能であり、将来のデフォルトで検討されている構成オプションを
     有効にします。 ここに含まれる構成設定は、マイナーバージョンの更新を
     含め、リリースごとに追加または削除される場合があります。 これらの設
     定は非常に新しいため、意図しない相互作用が発生する可能性があります
     。 実験的な機能に関するフィードバックを提供したい場合は、この設定を
     有効にしてください。 新しいデフォルト値は以下のとおりです:

        • ‘fetch.negotiationAlgorithm=skipping’ は、一度により多くのコミ
          ットをスキップし、ラウンドトリップの数を減らすことで、フェッチ
          ネゴシエーション時間を改善できます。

feature.manyFiles
     作業ディレクトリに多数のファイルがあるリポジトリを最適化する構成オ
     プションを有効にします。 多くのファイルがあると、 ‘git status’ や
     ‘git checkout’ などのコマンドが遅くなる可能性があり、これらの新しい
     デフォルトによりパフォーマンスが向上します:

        • ‘index.version=4’ インデックスのpath-prefix圧縮を有効にします
          。

        • ‘core.untrackedCache=true’ 追跡されていないキャッシュを有効に
          します。この設定は、mtimeがマシンで機能していることを前提とし
          ています。

fetch.recurseSubmodules
     このオプションは、 ‘git fetch’(および ‘git pull’ の基になるフェッチ
     )が入力されたサブモジュールに再帰的にフェッチするかどうかを制御しま
     す。 このオプションは、ブール値または ‘on-demand’ のいずれかに設定
     できます。 ブール値に設定すると、フェッチとプルの動作が変更され、
     trueに設定されている場合は無条件にサブモジュールに再帰し、falseに設
     定されている場合はまったく再帰しません。 ‘on-demand’ に設定すると、
     フェッチとプルは、スーパープロジェクトがサブモジュールの参照を更新
     するコミットを取得したときにのみ、入力されたサブモジュールに再帰し
     ます。 デフォルトは ‘on-demand’ 、または ‘submodule.recurse’ が設定
     されている場合はその値です。

fetch.fsckObjects
     trueに設定されている場合、git-fetch-packはフェッチされたすべてのオ
     ブジェクトをチェックします。 チェックされる内容については、
     ‘transfer.fsckObjects’ を参照してください。 デフォルトはfalseです。
     設定されていない場合は、代わりに ‘transfer.fsckObjects’ の値が使用
     されます。

fetch.fsck.<msg-id>
     ‘fsck.<msg-id>’ のように機能しますが、 git-fsck(1) の代わりに
     git-fetch-pack(1) によって使用されます。 詳細については、
     ‘fsck.<msg-id>’ のドキュメントを参照してください。

fetch.fsck.skipList
     ‘fsck.skipList’ のように機能しますが、 git-fsck(1) の代わりに
     git-fetch-pack(1) によって使用されます。 詳細については、
     ‘fsck.skipList’ のドキュメントを参照してください。

fetch.unpackLimit
     Gitネイティブ転送を介してフェッチされるオブジェクトの数がこの制限を
     下回る場合、オブジェクトは緩いオブジェクト(loose object)ファイルに
     解凍されます。 ただし、受信したオブジェクトの数がこの制限以上の場合
     、受信したパックは、欠落しているデルタベースを追加した後、パックと
     して保存されます。 プッシュからパックを保存すると、特に低速のファイ
     ルシステムで、プッシュ操作をより速く完了することができます。 これが
     設定されていない場合は、代わりに ‘transfer.unpackLimit’ の値が使用
     されます。

fetch.prune
     trueの場合、fetchはコマンドラインで ‘--prune’ オプションが指定され
     たかのように自動的に動作します。 ‘remote.<name>.prune’ および
     git-fetch(1) の「PRUNING」セクションも参照してください。

fetch.pruneTags
     trueの場合、フェッチは、まだ設定されていない場合、刈り込み
     (pruning)時に ‘refs/tags/*:refs/tags/*’ refspecが提供されたかのよう
     に自動的に振る舞います。 これにより、このオプションと ‘fetch.prune’
     の両方を設定して、アップストリーム参照への 1=1 マッピングを維持でき
     ます。 ‘remote.<name>.pruneTags’ および git-fetch(1) の「PRUNING」
     セクションも参照してください。

fetch.output
     ref updateステータスの出力方法を制御します。 有効な値は ‘full’ と
     ‘compact’ です。 デフォルト値は ‘full’ です。 詳細については、
     git-fetch(1) の「OUTPUT」セクションを参照してください。

fetch.negotiationAlgorithm
     サーバーによって送信されるパックファイルの内容をネゴシエートすると
     きに、ローカルリポジトリ内のコミットに関する情報がどのように送信さ
     れるかを制御します。 ‘skipping’ に設定すると、より速く収束するため
     にコミットをスキップするアルゴリズムを使用しますが、必要以上にパッ
     クファイルが大きくなる可能性があります。 または、 ‘noop’ に設定して
     情報をまったく送信しないようにします。これにより、ほぼ確実に必要以
     上のパックファイルが作成されますが、ネゴシエーション手順はスキップ
     されます。 デフォルトは ‘default’ で、コミットをスキップしないデフ
     ォルトのアルゴリズムを使用するようにGitに指示します(サーバーがコミ
     ットまたはその子孫の1つを確認した場合を除く)。
     ‘feature.experimental’ が有効になっている場合、この設定はデフォルト
     で ‘skipping’ になります。 値が不明な場合、 ‘git fetch’ でエラーが
     発生します。

     git-fetch(1) の ‘--negotiate-only’ および ‘--negotiation-tip’ オプ
     ションも参照してください。

fetch.showForcedUpdates
     falseに設定すると、 git-fetch(1) および git-pull(1) コマンドで
     ‘--no-show-forced-updates’ が有効になります。 デフォルトはtrueです
     。

fetch.parallel
     一度に並行して実行されるフェッチ操作の最大数を指定します(サブモジュ
     ール、または、git-fetch(1) の ‘--multiple’ オプションが有効な場合は
     リモート)。

     値0は、適切なデフォルトを提供します。 設定されていない場合、デフォ
     ルトで1になります。

     サブモジュールの場合、この設定は、 ‘submodule.fetchJobs’ 構成設定を
     使用してオーバーライドできます。

fetch.writeCommitGraph
     リモートからパックファイルをダウンロードするすべての ‘git fetch’ コ
     マンドの後でcommit-graphを書き込むには、trueに設定します。
     ‘--split’ オプションを使用すると、ほとんどの実行で、既存の
     commit-graphファイルの上に非常に小さなcommit-graphファイルが作成さ
     れます。 場合によっては、これらのファイルがマージされ、書き込みに時
     間がかかることがあります。 更新されたcommit-graphファイルがあると、
     ‘git merge-base’ や ‘git push -f’ や ‘git log --graph’ などの多くの
     Gitコマンドのパフォーマンス改善に役立ちます。 デフォルトはfalseです
     。

format.attach
     _format-patch_ のデフォルトとして マルチパート/混合の添付
     (multipart/mixed attachments)を有効にします。値は二重引用符
     (‘"..."’)で囲まれた文字列にすることもできます。これにより、添付ファ
     イルがデフォルトとして有効になり、文字列が境界として設定されます。
     git-format-patch(1) の ‘--attach’ オプションを参照してください。

format.from
     ‘--from’ オプションのデフォルト値をformat-patchに提供します。ブール
     値、または名前と電子メールアドレスを受け入れます。 falseの場合、
     format-patchはデフォルトで ‘--no-from’ になり、パッチメールの
     ‘From:’ フィールドに直接コミット作成者を使用します。 trueの場合、
     format-patchはデフォルトで ‘--from’ になり、パッチメールの ‘From:’
     フィールドにあなたのコミッターIDを使い、異なる場合にはパッチメール
     の本文に ‘From:’ フィールドを含めます。 ブール値でない値を設定した
     場合、format-patch はあなたのコミッターIDの代わりにその値を使用しま
     す。 デフォルトは false です。

format.numbered
     パッチ件名のシーケンス番号を有効または無効にできるブール値。 デフォ
     ルトは「auto」で、複数のパッチがある場合にのみ有効になります。 「
     true」または「false」に設定することで、すべてのメッセージに対して有
     効または無効にできます。 git-format-patch(1)の ‘--numbered’ オプシ
     ョンを参照してください。

format.headers
     メールで送信するパッチに含める追加の電子メールヘッダー。
     git-format-patch(1) を参照してください。

format.to
format.cc
     メールで送信するパッチに含める追加の受信者。 git-format-patch(1)の
     ‘--to’ および‘ –cc‘ オプションを参照してください。

format.subjectPrefix
     format-patchのデフォルトは、 ‘[PATCH]’ 件名接頭辞 を持つファイルを
     出力することです。 この変数を使用して、その接頭辞を変更します。

format.coverFromDescription
     ブランチの説明を使用してカバーレターのどの部分にデータを入力するか
     を決定するためのformat-patchのデフォルトモード。
     git-format-patch(1)の ‘--cover-from-description’ オプションを参照し
     てください。

format.signature
     format-patchのデフォルトは、Gitバージョン番号を含む署名を出力するこ
     とです。 この変数を使用して、そのデフォルトを変更します。 この変数
     を空の文字列("")に設定すると、署名の生成を抑制します。

format.signatureFile
     この変数で指定されたファイルの内容が署名として使用されることを除い
     て、 format.signature と同じように機能します。

format.suffix
     format-patchのデフォルトは、接尾辞が ‘.patch’ のファイルを出力する
     ことです。 この変数を使用して、その接尾辞を変更します(必要に応じて
     、必ずドット(‘.’)を含めてください)。

format.encodeEmailHeaders
     電子メール送信用に、非ASCII文字を含む電子メールヘッダーを「
     Q-encoding」(RFC 2047で説明)でエンコードします。 デフォルトはtrueで
     す。

format.pretty
     log/show/whatchanged コマンドのpretty形式のデフォルト。 git-log(1)
     、 git-show(1) 、 git-whatchanged(1) を参照してください。

format.thread
     ‘git format-patch’ のデフォルトのスレッドスタイル。 ブール値 または
     ‘shallow’ または ‘deep’ にすることができます。 ‘shallow’ スレッドは
     、すべてのメールをシリーズの先頭にに対して返信します。先頭は、カバ
     ーレター、 ‘--in-reply-to’ 、最初のパッチメールの順に選択されます。
     ‘deep’ スレッドは、すべてのメールを前のメールに返信します。 true の
     ブール値は ‘shallow’ と同じであり、 false値はスレッド化を無効にしま
     す。

format.signOff
     デフォルトでformat-patchの ‘-s/--signoff’ オプションを有効にできる
     ブール値。 *注意* パッチに「Signed-off-by」トレーラーを追加すること
     は意識的な行為である必要があり、同じオープンソースライセンスの下で
     この作品を提出する権利があることを証明することを意味します。 詳細に
     ついては、「SubmittingPatches」ドキュメントを参照してください。

format.coverLetter
     format-patchが呼び出されたときにカバーレターを生成するかどうかを制
     御するブール値ですが、さらに「auto」に設定して、複数のパッチがある
     場合にのみカバーレターを生成することができます。 デフォルトは
     falseです。

format.outputDirectory
     現在の作業ディレクトリの代わりに、結果のファイルを保存するカスタム
     ディレクトリを設定します。 すべてのディレクトリコンポーネントが作成
     されます。

format.filenameMaxLength
     ‘format-patch’ コマンドによって生成される出力ファイル名の最大長。 デ
     フォルトは64です。‘--filename-max-length=<n>’ コマンドラインオプシ
     ョンで上書きできます。

format.useAutoBase
     format-patch のオプションである ‘--base=auto’ をデフォルトで有効に
     するためのブール値です。 ‘whenAble’ に設定すると、適切なベースがあ
     る場合に ‘--base=auto’ を有効にし、それ以外の場合はフォーマット終了
     せずにベース情報の追加をスキップすることもできます。

format.notes
     format-patchの ‘--notes’ オプションのデフォルト値を提供します。 ブ
     ール値、またはnotesを取得する場所を指定するrefを受け入れます。
     falseの場合、format-patchのデフォルトは ‘--no-notes’ です。 trueの
     場合、format-patchのデフォルトは ‘--notes’ です。 非ブール値に設定
     されている場合、format-patchのデフォルトは ‘--notes=<ref>’ です。こ
     こで、 ‘ref’ は指定した非ブール値です。 デフォルトはfalseです。

     ref ‘ref/notes/true’ を使用したい場合は、代わりにそのリテラルを使用
     してください。

     この構成は、複数のnotes refを含めるために複数回指定できます。その場
     合、渡された複数の ‘--[no-]notes[=]’ オプションと同様に動作します。
     つまり、値 ‘true’ はデフォルトのnotesを表示し、値 ‘<ref>’ はその
     notes ref からのnotesも表示し、値 ‘false’ はそれ以前の設定を無効に
     し、notesを表示しません。

     例えば以下の場合、

          [format]
                  notes = true
                  notes = foo
                  notes = false
                  notes = bar

     ‘refs/notes/bar’ からのnotesのみが表示されます。

filter.<driver>.clean
     チェックイン時にワークツリーファイルのコンテンツをブロブに変換する
     ために使用されるコマンド。 詳細については、 gitattributes(5) を参照
     してください。

filter.<driver>.smudge
     チェックアウト時にブロブオブジェクトのコンテンツをワークツリーファ
     イルに変換するために使用されるコマンド。 詳細については、
     gitattributes(5) を参照してください。

fsck.<msg-id>
     fsck中に、gitは、現在のバージョンのgitでは生成されず、
     ‘transfer.fsckObjects’ が設定されている場合はネットワーク経由で送信
     されない、レガシーデータの問題を検出する場合があります。この機能は
     、そのようなデータを含むレガシーリポジトリの操作をサポートすること
     を目的としています。

     ‘fsck.<msg-id>’ 設定は、 git-fsck(1) によって取得されますが、代わり
     に、そのようなデータセット ‘receive.fsck.<msg-id>’ のプッシュを受け
     入れるか、または、クローンまたはフェッチのセットである
     ‘fetch.fsck.<msg-id>’ を使用します。

     この文書の残りの部分では、簡潔にするために ‘fsck.*’ 変数について説
     明していますが、対応する ‘receive.fsck.*’ 変数と ‘fetch.<msg-id>.*’
     変数にも同じことが当てはまります。

     ‘color.ui’ や ‘core.editor’ のような変数とは異なり、
     ‘receive.fsck.<msg-id>’ と ‘fetch.fsck.<msg-id>’ 変数は、設定されて
     いない場合、 ‘fsck.<msg-id>’ 構成にフォールバックしません。さまざま
     な状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設定す
     る必要があります。

     ‘fsck.<msg-id>’ が設定されている場合、 ‘fsck.<msg-id>’ の値を
     ‘error’ 、 ‘warn’ 、‘ignore’ のいずれか一つとすることにより、エラー
     を警告に切り替える事もでき、その逆も可能です。そして ‘<msg-id>’ の
     部分はメッセージIDです。便利なように、fsckはエラー/警告メッセージの
     前にメッセージIDを付けます。たとえば「missingEmail: invalid
     author/committer line - missing email」は、 ‘fsck.missingEmail =
     ignore’ を設定するとその問題が非表示になることを意味します。

     一般に、これらの問題のあるオブジェクトが共有する破損の種類をリスト
     して無視するのではなく、 ‘fsck.skipList’ に問題のある既存のオブジェ
     クトを列挙することをお勧めします。前者を実行すると、同じ破損の新し
     いインスタンスが見過ごされる可能性があります。

     不明な ‘fsck.<msg-id>’ 値を設定すると、fsckが停止(die)しますが、
     ‘receive.fsck.<msg-id>’ や ‘fetch.fsck.<msg-id>’ に対して同じことを
     行うと、gitは単に警告するだけです。

fsck.skipList
     非致命的な理由により既に壊れている(broken)ことが分かっているため無
     視する必要があるオブジェクト名(1行につき1つの省略されてないSHA-1)の
     リストへのパス。Git 2.20 以降では、コメント(‘#’)文字から行末までと
     、空行と、先頭と末尾の空白(whitespace)は無視されます。それより古い
     バージョンでは1行につき1つのSHA-1以外は全てエラーになります。

     この機能は、無効なコミッターの電子メールアドレスなど、初期のコミッ
     トにもかかわらず、安全に無視できるエラーを含む、確立されたプロジェ
     クトを受け入れる必要がある場合に役立ちます。 注意: この設定では、
     corruptオブジェクトをスキップすることはできません。

     ‘fsck.<msg-id>’ と同様に、この変数に対応する
     ‘receive.fsck.skipList’ 派生と ‘fetch.fsck.skipList’ 派生があります
     。

     ‘color.ui’ や ‘core.editor’ のような変数とは異なり、
     ‘receive.fsck.skipList’ 変数と ‘fetch.fsck.skipList’ 変数は、設定さ
     れていない場合、 ‘fsck.skipList’ 構成にフォールバックしません。さま
     ざまな状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設
     定する必要があります。

     古いバージョンのGit(2.20より前)では、オブジェクト名リストを並べ替え
     る必要があることが文書化されています。これは必須ではなく、オブジェ
     クト名は任意の順序で表示できますが、リストを読み取るときに、内部バ
     イナリ検索実装の目的でリストが並べ替えられているかどうかを追跡しま
     した。これにより、既に並べ替えられたリストでは作業を節約できます。
     膨大なリストがない限り、リストを事前に並べ替える必要はありませんで
     した。 Gitバージョン2.20以降では、代わりにハッシュ実装が使用される
     ため、リストを事前に並べ替える必要はありません。

gc.aggressiveDepth
     ‘git gc --aggressive’ で使用されるデルタ圧縮アルゴリズムで使用され
     る深さパラメーター。これはデフォルトで50に設定されています。これは
     ‘--aggressive’ が使用されていない場合の ‘--depth’ オプションのデフ
     ォルトです。

     詳細については git-repack(1) の ‘--depth’ オプションの文書を参照し
     てください。

gc.aggressiveWindow
     ‘git gc --aggressive’ で使用されるデルタ圧縮アルゴリズムで使用され
     るウィンドウサイズパラメータ。これはデフォルトで250に設定されていま
     す。これは、 ‘--window’ のデフォルト値の10よりもはるかに積極的なウ
     ィンドウサイズです。

     詳細については、 git-repack(1) の ‘--window’ オプションの文書を参照
     してください。

gc.auto
     リポジトリにおおよそ指定の値より多くのルーズオブジェクトがある場合
     、 ‘git gc --auto’ はそれらをパックします。一部の磁器コマンドは、こ
     のコマンドを使用して、軽量のガベージコレクションを時々実行します。
     デフォルト値は6700です。

     これを0に設定すると、ルーズオブジェクトの数に基づく自動パッキングが
     無効にななります。また、他のヒューリスティックな ‘git gc --auto’ が
     、 ‘gc.autoPackLimit’ などの作業があるかどうかを判断するためにこの
     値を使用します。

gc.autoPackLimit
     リポジトリに ‘* .keep’ ファイルでマークされていないパックがこの設定
     値より多くある場合、 ‘git gc --auto’ はそれらを1つの大きなパックに
     統合します。デフォルト値は50です。これを0に設定すると、無効になりま
     す。 ‘gc.auto’ を0に設定すると、この設定も無効になります。

     以下の ‘gc.bigPackThreshold’ 構成変数を参照してください。この設定を
     使用中は、自動パックの制限がどのように機能するかに影響します。

gc.autoDetach
     システムがサポートしている場合は ‘git gc --auto’ は即座戻り、実行は
     バックグラウンドで行われます。デフォルトはtrueです。

gc.bigPackThreshold
     ゼロ以外の場合、 ‘git gc’ の実行時に、この設定値より大きいすべての
     パックが保持されます。これは ‘--keep-largest-pack’ と非常に似ていま
     すが、最大のパックだけでなく、しきい値を満たす全てのパックが保持さ
     れる点が異なります。デフォルトはゼロです。 _k_ 、 _m_ 、 _g_ の一般
     的な単位接尾辞がサポートされています。

     注意: 保持されるパックの数が gc.autoPackLimit を超える場合、この構
     成変数は無視され、基本パックを除くすべてのパックが再パックされるこ
     とに注意してください。再パック後、パックの数は gc.autoPackLimit を
     下回り、再び gc.bigPackThreshold が尊重されるでしょう。

     ‘git repack’ がスムーズに実行されると推定されるメモリ量が利用できず
     、かつ、 ‘gc.bigPackThreshold’ が設定されていない場合、最大のパック
     も除外されます(これは、 ‘--keep-largest-pack’ を指定して ‘git gc’ を
     実行するのと同じです)。

gc.writeCommitGraph
     trueの場合、 git-gc(1) が実行されると、 gcはcommit-graphファイルを
     書き換えます。 ‘git gc --auto’ を使用する場合、ハウスキーピングが必
     要な場合はコミットグラフが更新されます。デフォルトはtrueです。詳細
     については git-commit-graph(1) を参照してください。

gc.logExpiry
     ファイルgc.logが存在する場合、 ‘git gc --auto’ はそのコンテンツを出
     力し、そのファイルが「gc.logExpiry」より古い場合を除いて、実行する
     代わりにステータス0で終了します。デフォルトは「1.day」です。その他
     の値の指定方法については ‘gc.pruneExpire’ を参照してください。

gc.packRefs
     リポジトリで ‘git pack-refs’ を実行すると、HTTPなどの馬鹿プロトコル
     (dumb transport) を介して 1.5.1.2 より前のGitバージョンではクローン
     が作成できなくなります。この変数は、「git gc」が「git pack-refs」を
     実行するかどうかを決定します。これを ‘notbare’ に設定して、すべての
     非ベアリポジトリ内で有効にするか、ブール値に設定することができます
     。 デフォルトは ‘true’ です。

gc.pruneExpire
     「git gc」を実行すると、‘prune --expire 2.weeks.ago’ が呼び出されま
     す。この構成変数で猶予期間をオーバーライドします。 値「now」を使用
     してこの猶予期間を無効にし、到達不能なオブジェクトを常にすぐに剪定
     (prune)するか、「never」を使用して剪定を抑制することができます。こ
     の機能は「git gc」がリポジトリに書き込む別のプロセスと同時に実行さ
     れる場合の破損を防ぐのに役立ちます。 git-gc(1) の「NOTES」セクショ
     ンを参照してください。

gc.worktreePruneExpire
     _git gc_ が実行されると、 ‘git worktree prune --expire3.months.ago’
     が呼び出されます。この構成変数を使用して、別の猶予期間を設定できま
     す。値「now」を使用して猶予期間を無効にし、 ‘$GIT_DIR/worktrees’ を
     すぐに剪定(prune)するか、「never」を使用して剪定を抑制することがで
     きます。

gc.reflogExpire
gc.<pattern>.reflogExpire
     「git reflog expire」は、この時間より古いreflogエントリを削除します
     。デフォルトは90日です。値「now」はすべてのエントリをすぐに期限切れ
     にし、「never」は期限切れを完全に抑制します。中央に「<pattern>」(例
     :「refs/stash」)がある場合、設定は <pattern> に一致するrefにのみ適
     用されます。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable
     _git reflog expire_ は、この時間より古いreflogエントリを削除し、現
     在の先端(the current tip)から到達不能にします。デフォルトは30日です
     。値「now」はすべてのエントリをすぐに期限切れにし、「never」は期限
     切れを完全に抑制します。中央に「<pattern>」(例:「refs/stash」)があ
     る場合、設定は <pattern> に一致するrefにのみ適用されます。

     これらのタイプのエントリは通常、 ‘git commit--amend’ または ‘git
     rebase’ を使用した結果として作成され、修正またはリベースが発生する
     前のコミットです。これらの変更は現在のプロジェクトの一部ではないた
     め、ほとんどのユーザーはそれらをより早く期限切れにしたいと思うでし
     ょう。そのため、デフォルトは ‘gc.reflogExpire’ よりも積極的です。

gc.rerereResolved
     以前に解決した競合するマージの記録は、「git rerere gc」が実行される
     ときに、この設定値で指定の日数保持されます。より人間が読める「
     1.month.ago」などを使用することもできます。デフォルトは60日です。
     git-rerere(1) を参照してください。

gc.rerereUnresolved
     _git rerere gc_ が実行されると、解決していない競合するマージの記録
     がこの設定値の日数保持されます。より人間が読める「1.month.ago」など
     を使用することもできます。デフォルトは15日です。 git-rerere(1) を参
     照してください。

gitcvs.commitMsgAnnotation
     この文字列を各コミットメッセージに追加します。この機能を無効にする
     には、空の文字列に設定します。 デフォルトは "via git-CVS emulator"
     (git-CVSエミュレーター経由)です。

gitcvs.enabled
     このリポジトリに対してCVSサーバー・インターフェースが有効になってい
     るかどうか。 git-cvsserver(1) を参照してください。

gitcvs.logFile
     CVS サーバインターフェイスが様々なことを記録するログファイルへのパ
     スです。 git-cvsserver(1) を参照してください。

gitcvs.usecrlfattr
     trueの場合、サーバーはファイルの行末変換属性を検索して、使用する
     ‘-k’ モードを決定します。 属性がGitにファイルをテキストとして処理さ
     せる場合、 ‘-k’ モードは空白(blank)のままになるため、CVSクライアン
     トはファイルをテキストとして処理します。 それらがテキスト変換を抑制
     する場合、ファイルは ‘-kb’ モードで設定されます。これにより、クライ
     アントが他の方法で行う可能性のある改行の変更が抑制されます。 属性で
     ファイルタイプを決定できない場合は、‘gitcvs.allBinary’ が使用されま
     す。 gitattributes(5) を参照してください。

gitcvs.allBinary
     これは、 ‘gitcvs.usecrlfattr’ が使用する「正しい ‘-kb’ モード」
     (correct _-kb_ mode)で解決しない場合に使用されます。 trueの場合、未
     解決のファイルはすべてモード ‘-kb’ でクライアントに送信されます。 こ
     れにより、クライアントはそれらをバイナリファイルとして扱い、改行が
     変更されないようにします。 または、 ‘guess’ に設定されている場合は
     、ファイルの内容が調べられ、 ‘core.autocrlf’ と同様に、バイナリであ
     るかどうかが判断されます。

gitcvs.dbName
     Gitリポジトリから派生したリビジョン情報をキャッシュするために
     git-cvsserverによって使用されるデータベース。 正確な意味は、使用す
     るデータベースドライバーによって異なります。 SQLite(デフォルトのド
     ライバー)の場合、これはファイル名です。 変数の置換をサポートします
     (詳細については、 git-cvsserver(1) を参照してください)。 セミコロン
     (‘;’)を含めることはできません。 デフォルトは ‘%Ggitcvs.%m.sqlite’ で
     す。

gitcvs.dbDriver
     使用するPerlDBIドライバー。 ここで使用可能なドライバーを指定できま
     すが、機能しない場合があります。 git-cvsserverは ‘DBD::SQLite’ でテ
     ストされています。 ‘DBD::Pg で動作するという報告がありますが、
     `DBD::mysql’ で動作しないことが報告されています。 実験的機能です。
     二重コロン(‘::’)を含めることはできません。 デフォルトは ‘SQLite’ で
     す。 git-cvsserver(1) を参照してください。

gitcvs.dbUser, gitcvs.dbPass
     データベースのユーザーとパスワード。 SQLiteにはデータベースユーザー
     やパスワードの概念がないため、 ‘gitcvs.dbDriver’ を設定する場合にの
     み役立ちます。 ‘gitcvs.dbUser’ は変数の置換をサポートしています(詳
     細については git-cvsserver(1) を参照してください)。

gitcvs.dbTableNamePrefix
     データベーステーブル名のプレフィックス。 使用されるデータベーステー
     ブルの名前の前に付けられ、単一のデータベースを複数のリポジトリに使
     用できるようにします。 変数の置換をサポートします(詳細については、
     git-cvsserver(1) を参照してください)。 アルファベット以外の文字はす
     べてアンダースコアに置き換えられます。

   ‘gitcvs.usecrlfattr’ と ‘gitcvs.allBinary’ を除くすべてのgitcvs変数は
、 ‘gitcvs.<access_method>.<varname>’ (‘access_method’ は "ext" と
"pserver" のいずれか)として指定することもできます。それらは、指定のアク
セス方法(‘<access_method>’)にのみ適用されます。

gitweb.category
gitweb.description
gitweb.owner
gitweb.url
     説明については gitweb(1) を参照してください。

gitweb.avatar
gitweb.blame
gitweb.grep
gitweb.highlight
gitweb.patches
gitweb.pickaxe
gitweb.remote_heads
gitweb.showSizes
gitweb.snapshot
     説明については gitweb.conf(5) を参照してください。

grep.lineNumber
     trueに設定すると、デフォルトで ‘-n’ オプションが有効になります。

grep.column
     trueに設定されている場合、デフォルトで ‘--column’ オプションを有効
     にします。

grep.patternType
     デフォルトの一致動作を設定します。 ‘basic’ または ‘extended’ または
     ‘fixed’ または ‘perl’ の値を使用すると、それぞれに応じて
     ‘--basic-regexp’ または ‘ –extended-regexp‘ または
     ‘--fixed-strings’ または ‘--perl-regexp’ オプションが有効になります
     。 値 ‘default’ はデフォルトの一致動作に戻ります。

grep.extendedRegexp
     trueに設定されている場合、デフォルトで ‘--extended-regexp’ オプショ
     ンを有効にします。 ‘grep.patternType’ オプションが ‘default’ 以外の
     値に設定されている場合、このオプションは無視されます。

grep.threads
     使用するgrepワーカースレッドの数。 詳細については、 git-grep(1) の
     ‘grep.threads’ を参照してください。

grep.fallbackToNoIndex
     trueに設定すると、 ‘git grep’ がgitリポジトリの外部で実行される場合
     は、 ‘git grep --no-index’ にフォールバックします。 デフォルトは
     falseです。

gpg.program
     PGP署名を作成または検証するときは、‘$PATH’ にある ‘gpg’ の代わりに
     このカスタムプログラムを使用します。 プログラムはGPGと同じコマンド
     ラインインターフェイスをサポートする必要があります。つまり、切り離
     された署名(detached signature)を検証するには、 ‘gpg --verify
     $signature - <$file’ が実行され、 プログラムは、コード0で終了するこ
     とにより、適切な署名を通知することが期待されます。PGP ASCII-armor の
     分離署名(ASCII-armored detached signature)を生成するために、 ‘gpg
     -bsau $key’ の標準入力には、署名する内容が入力され、プログラムはそ
     の結果を標準出力に送信することが期待されています。

gpg.format
     ‘--gpg-sign’ で署名するときに使用するキー形式を指定します。 デフォ
     ルトは ‘openpgp’ で、別の可能な値は ‘x509’ です。

gpg.<format>.program
     これを使用して、選択した署名形式に使用されるプログラムをカスタマイ
     ズします。 ( ‘gpg.program’ と ‘gpg.format’ 参照) ‘gpg.program’ は、
     ‘gpg.openpgp.program’ の歴史的同義語として引き続き使用できます。
     ‘gpg.x509.program’ のデフォルト値は ‘gpgsm’ です。

gpg.minTrustLevel
     署名検証(signature verification)の最小信頼(trust)レベルを指定します
     。 このオプションが設定されていない場合、マージ操作の署名検証には、
     少なくとも ‘marginal’ 信頼(trust)のあるキーが必要です。 署名の検証
     を実行する他の操作には、少なくとも ‘undefined’ の信頼を持つキーが必
     要です。 このオプションを設定すると、すべての操作に必要な信頼レベル
     が上書きされます。 サポートされている値は以下のとおりです(重要度の
     昇順):

        • ‘undefined’

        • ‘never’

        • ‘marginal’

        • ‘fully’

        • ‘ultimate’

gui.commitMsgWidth
     git-gui(1) のコミットメッセージウィンドウの幅を定義します。 「75」
     がデフォルトです。

gui.diffContext
     git-gui(1) によるdiffの呼び出しで使用するコンテキスト行の数を指定し
     ます。 デフォルトは「5」です。

gui.displayUntracked
     git-gui(1) がファイルリストに追跡されていないファイルを表示するかど
     うかを決定します。 デフォルトは「true」です。

gui.encoding
     git-gui(1) および gitk(1) でファイルの内容を表示するために使用する
     デフォルトの文字エンコードを指定します。 関連するファイルの「
     encoding」属性を設定することでオーバーライドできます
     (gitattributes(5) 参照)。 このオプションが設定されていない場合、ツ
     ールはデフォルトでロケールエンコーディングになります。

gui.matchTrackingBranch
     git-gui(1) で作成された新しいブランチが、デフォルトで名前が一致する
     リモートブランチを追跡するかどうかを決定します。 デフォルトは「
     false」です。

gui.newBranchTemplate
     git-gui(1) を使用して新しいブランチを作成するときに、推奨される名前
     として使用されます。

gui.pruneDuringFetch
     git-gui(1) がフェッチの実行時にリモート追跡ブランチを刈り込み
     (prune)する必要がある場合は「true」。 デフォルト値は「false」です。

gui.trustmtime
     git-gui(1) がファイル変更のタイムスタンプを信頼するかどうかを決定し
     ます。 デフォルトでは、タイムスタンプは信頼されていません。

gui.spellingDictionary
     git-gui(1) でコミットメッセージのスペルチェックに使用される辞書を指
     定します。「none」に設定すると、スペルチェックがオフになります。

gui.fastCopyBlame
     trueの場合、 ‘git gui blame’ は、元の場所(original location)の検出
     に ‘-C -C’ ではなく ‘-C’ を使用します。 コピーの検出が完全ではなく
     なる代わりに、巨大なリポジトリでのblameが大幅に速くなります。

gui.copyBlameThreshold
     英数字(alphanumeric)文字で測定された、 ‘git gui blame’ の元の位置
     (original location)検出で使用するしきい値を指定します。 コピー検出
     の詳細については、 git-blame(1) のマニュアルを参照してください。

gui.blamehistoryctx
     「Show History Context」(履歴コンテキストの表示)メニュー項目が ‘git
     gui blame’ から呼び出されたときに、選択したコミットの gitk(1) に表
     示する履歴コンテキストの範囲を日数で指定します。 この変数がゼロに設
     定されている場合、履歴全体が表示されます。

guitool.<name>.cmd
     git-gui(1) Toolsメニューの対応する項目が呼び出されたときに実行する
     シェルコマンドラインを指定します。 このオプションは、すべてのツール
     に必須です。 コマンドは作業ディレクトリのルートから実行され、環境で
     はツールの名前を ‘GIT_GUITOOL’ 、現在選択されているファイルの名前を
     ‘FILENAME’ 、現在のブランチの名前を ‘CUR_BRANCH’ として受け取ります
     (切り離されたヘッド(detached head)の場合、 ‘CUR_BRANCH’ は空です)。

guitool.<name>.needsFile
     GUIでdiffが選択されている場合にのみ、ツールを実行します。
     ‘FILENAME’ が空でないことを保証します。

guitool.<name>.noConsole
     出力を表示するウィンドウを作成せずに、コマンドを黙って実行します。

guitool.<name>.noRescan
     ツールの実行が終了した後、変更がないか作業ディレクトリを再スキャン
     しないでください。

guitool.<name>.confirm
     ツールを実際に実行する前に、確認ダイアログを表示します。

guitool.<name>.argPrompt
     ユーザーに文字列引数を要求し、それを ‘ARGS’ 環境変数を介してツール
     に渡します。 引数の要求は確認を意味するため、これが有効になっている
     場合、「confirm」オプションは効果がありません。 オプションが ‘true’
     または ‘yes’ または 1 に設定されている場合、ダイアログは組み込みの
     汎用プロンプトを使用します。 それ以外の場合は、変数の正確な値が使用
     されます。

guitool.<name>.revPrompt
     ユーザーに有効なリビジョンを1つ要求し、 ‘REVISION’ 環境変数を設定し
     ます。 それ以外は ‘argPrompt’ と同様です。 ‘argPrompt’ と一緒に使用
     できます。

guitool.<name>.revUnmerged
     ‘revPrompt’ サブダイアログにマージされていないブランチのみを表示し
     ます。 これは、マージやリベースに似たツールには役立ちますが、チェッ
     クアウトやリセットなどには役立ちません。

guitool.<name>.title
     プロンプトダイアログに使用するタイトルを指定します。 デフォルトはツ
     ール名です。

guitool.<name>.prompt
     ダイアログの上部、 ‘argPrompt’ および ‘revPrompt’ のサブセクション
     の前に表示する一般的なプロンプト文字列を指定します。 デフォルト値に
     は実際のコマンドが含まれます。

help.browser
     ヘルプをweb形式で表示するために使用されるブラウザーを指定します。
     git-help(1) を参照してください。

help.format
     git-help(1) で使用されるデフォルトのヘルプ形式を上書きします。 値と
     して ‘man’ と ‘info’ と ‘web’ と ‘html’ がサポートされています。
     ‘man’ がデフォルトです。 ‘web’ と ‘html’ は同じ(same)です。

help.autoCorrect
     gitがタイプミスを検出し、間違いにに類似した有効なコマンドを1つだけ
     識別できる場合、gitは正しいコマンドを提案しようとするか、提案を自動
     的に実行します。 可能な構成値は以下のとおりです:

        • 0 (デフォルト): 提案されたコマンドを表示します。

        • 正の数: 指定されたデシ秒単位(0.1秒単位)の秒数後に提案されたコ
          マンドを実行します。

        • "immediate": 提案されたコマンドを即座に実行します。

        • "prompt": コマンドを実行するための提案と確認のプロンプトを表示
          します。

        • "never": 提案されたコマンドを実行も表示もしないでください。

help.htmlPath
     HTMLドキュメントが存在するパスを指定します。 ファイルシステムのパス
     とURLがサポートされています。 ヘルプが「web」形式で表示される場合、
     HTMLページの前にこのパスが付けられます。 これはデフォルトでGitイン
     ストールのドキュメントパスになります。

http.proxy
     通常は ‘http_proxy’ や ‘https_proxy’ や ‘all_proxy’ 環境変数を使用
     して構成されたHTTPプロキシをオーバーライドします(curl(1) 参照)。
     curlが理解できる構文に加えて、ユーザー名はパスワードなしでプロキシ
     文字列を指定でき、その場合、gitは他の資格情報の場合と同じ方法でプロ
     キシ文字列を取得しようとします。 詳細については、 gitcredentials(7)
     を参照してください。 構文は
     ‘[protocol://][user[:password]@]proxyhost[:port]’ です。 これは、リ
     モートごとにオーバーライドできます。 remote.<name>.proxy を参照して
     ください

http.proxyAuthMethod
     HTTPプロキシに対して認証する方法を設定します。 これは、構成されたプ
     ロキシ文字列にユーザー名の部分が含まれている場合にのみ有効になりま
     す(つまり、 ‘user@host’ または ‘user@host:port’ 形式)。 これは、リ
     モートごとにオーバーライドできます。
     ‘remote.<name>.proxyAuthMethod’ を参照してください。 どちらも
     ‘GIT_HTTP_PROXY_AUTHMETHOD’ 環境変数でオーバーライドできます。 可能
     な値は以下のとおりです:

        • ‘anyauth’ - 適切な認証方法を自動的に選択します。 プロキシは、
          407ステータスコードとサポートされている認証方法を使用した1つ以
          上のProxy-authenticateヘッダーを使用して、認証されていない要求
          に応答すると想定されます。 これがデフォルトです。

        • ‘basic’ - HTTPベーシック認証

        • ‘digest’ - HTTPダイジェスト認証。これにより、パスワードがクリ
          アテキストでプロキシに送信されるのを防ぎます

        • ‘negotiate’ - GSSネゴシエーション認証(‘curl(1)’ の
          ‘--negotiate’ オプションと比較してください)

        • ‘ntlm’ - NTLM認証(‘curl(1)’ の ‘--ntlm’ オプションと比較してく
          ださい)

http.proxySSLCert
     HTTPSプロキシでの認証に使用するクライアント証明書を格納するファイル
     のパス名。 ‘GIT_PROXY_SSL_CERT’ 環境変数でオーバーライドできます。

http.proxySSLKey
     HTTPSプロキシでの認証に使用する秘密鍵を格納するファイルのパス名。
     ‘GIT_PROXY_SSL_KEY’ 環境変数でオーバーライドできます。

http.proxySSLCertPasswordProtected
     プロキシSSL証明書に対するGitのパスワードプロンプトを有効にします。
     それ以外の場合、証明書または秘密鍵が暗号化されていると、OpenSSLはユ
     ーザーにプロンプトを表示します。
     ‘GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED’ 環境変数で上書きできます。

http.proxySSLCAInfo
     HTTPSプロキシを使用するときにプロキシを検証するために使用する必要が
     ある証明書バンドルを含むファイルへのパス名。 ‘GIT_PROXY_SSL_CAINFO’
     環境変数でオーバーライドできます。

http.emptyAuth
     ユーザー名またはパスワードを求めずに認証を試みます。 libcurlは通常
     、認証にユーザー名を必要とするため、これを使用して、URLにユーザー名
     を指定せずにGSS-Negotiate認証を試みることができます。

http.delegation
     GSSAPI資格情報の委任を制御します。 バージョン7.21.7以降、libcurlで
     は委任がデフォルトで無効になっています。 ユーザー資格情報に関して、
     何を委任できるかをサーバーに通知するパラメーターを設定します。
     GSS/kerberosで使用されます。 可能な値は以下のとおりです:

        • ‘none’ - 委任を許可しないでください。

        • ‘policy’ - OK-AS-DELEGATE フラグが Kerberos サービスチケットに
          設定されている場合にのみ委任します。これはレルムポリシー(realm
          policy)の問題です。

        • ‘always’ - サーバーが無条件に委任できるようにします。

http.extraHeader
     サーバーと通信するときに追加のHTTPヘッダーを渡します。 そのようなエ
     ントリが複数存在する場合は、それらすべてが追加のヘッダーとして追加
     されます。 システム構成から継承された設定をオーバーライドできるよう
     にするには、値を空にすると、余分なヘッダーが空のリストにリセットさ
     れます。

http.cookieFile
     以前に保存されたクッキー行を含むファイルのパス名。サーバーと一致す
     る場合はGit httpセッションで使用する必要があります。 クッキーを読み
     取るファイルのファイル形式は、プレーンHTTPヘッダーまたは、
     Netscape/Mozilla クッキーファイル形式である必要があります(curl(1) 参
     照)。 注意: ‘http.saveCookies’ が設定されていない限り、
     ‘http.cookieFile’ で指定されたファイルは入力としてのみ使用されるこ
     とに注意してください。

http.saveCookies
     設定されている場合、リクエスト中に受信したクッキーを
     http.cookieFile で指定されたファイルに保存します。 http.cookieFile
     が設定されていない場合は効果がありません。

http.version
     サーバーと通信するときは、指定されたHTTPプロトコルバージョンを使用
     してください。 デフォルトを強制する場合、使用可能なデフォルトバージ
     ョンはlibcurlによって異なります。 現在、このオプションの可能な値は
     以下のとおりです:

        • HTTP/2

        • HTTP/1.1

http.sslVersion
     デフォルトを強制する場合に、SSL接続をネゴシエートするときに使用する
     SSLバージョン。 使用可能なデフォルトバージョンは、libcurlがNSSまた
     はOpenSSLのどちらに対して構築されたか、および使用中の暗号ライブラリ
     の特定の構成によって異なります。 内部的には、これにより
     ‘CURLOPT_SSL_VERSION’ オプションが設定されます。 このオプションの形
     式とサポートされているSSLバージョンの詳細については、libcurlのドキ
     ュメントを参照してください。 現在、このオプションの可能な値は以下の
     とおりです:

        • sslv2

        • sslv3

        • tlsv1

        • tlsv1.0

        • tlsv1.1

        • tlsv1.2

        • tlsv1.3

     ‘GIT_SSL_VERSION’ 環境変数で上書きできます。 gitにlibcurlのデフォル
     トのsslバージョンを使用させ、明示的なhttp.sslversionオプションを無
     視するには、 ‘GIT_SSL_VERSION’ を空の文字列に設定します。

http.sslCipherList
     SSL接続をネゴシエートするときに使用するSSL暗号のリスト。 使用可能な
     暗号は、libcurlがNSSまたはOpenSSLのどちらに対して構築されたか、およ
     び使用中の暗号ライブラリの特定の構成によって異なります。 内部的には
     、これにより ‘CURLOPT_SSL_CIPHER_LIST’ オプションが設定されます。 こ
     のリストの形式の詳細については、libcurlのドキュメントを参照してくだ
     さい。

     ‘GIT_SSL_CIPHER_LIST’ 環境変数で上書きできます。 gitにlibcurlのデフ
     ォルトの暗号リストを使用させ、明示的なhttp.sslCipherListオプション
     を無視するには、 ‘GIT_SSL_CIPHER_LIST’ を空の文字列に設定します。

http.sslVerify
     HTTPSをフェッチまたはプッシュするときにSSL証明書を検証するかどうか
     。 デフォルトはtrueです。 ‘GIT_SSL_NO_VERIFY’ 環境変数で上書きでき
     ます。

http.sslCert
     HTTPSをフェッチまたはプッシュするときのSSL証明書を含むファイル。
     ‘GIT_SSL_CERT’ 環境変数で上書きできます。

http.sslKey
     HTTPSをフェッチまたはプッシュするときのSSL秘密鍵を含むファイル。
     ‘GIT_SSL_KEY’ 環境変数で上書きできます。

http.sslCertPasswordProtected
     SSL証明書に対するGitのパスワードプロンプトを有効にします。 それ以外
     の場合、証明書または秘密鍵が暗号化されていると、OpenSSLはユーザーに
     プロンプトを表示します。 ‘GIT_SSL_CERT_PASSWORD_PROTECTED’ 環境変数
     で上書きできます。

http.sslCAInfo
     HTTPSをフェッチまたはプッシュするときにピア(peer)を検証(verify)する
     ための証明書を含むファイル。 ‘GIT_SSL_CAINFO’ 環境変数でオーバーラ
     イドできます。

http.sslCAPath
     HTTPSをフェッチまたはプッシュするときにピア(peer)を検証(verify)する
     ためのCA証明書を含むファイルを含むパス。 ‘GIT_SSL_CAPATH’ 環境変数
     で上書きできます。

http.sslBackend
     使用するSSLバックエンドの名前(例: ‘openssl’ または ‘schannel’)。
     cURLが実行時にSSLバックエンドを選択するためのサポートを欠いている場
     合、このオプションは無視されます。

http.schannelCheckRevoke
     ‘http.sslBackend’ が ‘schannel’ に設定されている場合にcURLで証明書
     失効チェックを実施または無効にするために使用されます。 設定されてい
     ない場合、デフォルトは ‘true’ です。 Gitが一貫してエラーを出し、メ
     ッセージが証明書の失効ステータスの確認に関するものである場合にのみ
     、これを無効にする必要があります。 cURLが実行時に関連するSSLオプシ
     ョンを設定するためのサポートを欠いている場合、このオプションは無視
     されます。

http.schannelUseSSLCAInfo
     cURL v7.60.0以降、セキュリティで保護されたチャネルのバックエンドは
     ‘http.sslCAInfo’ を介して提供される証明書バンドルを使用できますが、
     これによりWindows証明書ストアが上書きされます。 これはデフォルトで
     は望ましくないため、 ‘http.schannelUseSSLCAInfo’ がこの動作をオーバ
     ーライドしない限り、 ‘schannel’ バックエンドが ‘http.sslBackend’ を
     介して構成されている場合、Gitはデフォルトでそのバンドルを使用しない
     ようにcURLに指示します。

http.pinnedpubkey
     httpsサービスの公開鍵。 これは、PEMまたはDERでエンコードされた公開
     鍵ファイルのファイル名か、 ‘sha256//’ で始まり、その後にbase64でエ
     ンコードされた公開鍵のsha256ハッシュが続く文字列のいずれかです。
     libcurlの _CURLOPT_PINNEDPUBLICKEY_ も参照してください。 このオプシ
     ョンが設定されているがcURLでサポートされていない場合、gitはエラーで
     終了します。

http.sslTry
     通常のFTPプロトコルを介して接続する場合は、AUTH SSL/TLS と暗号化さ
     れたデータ転送を使用してみてください。 これは、FTPサーバーがセキュ
     リティ上の理由でそれを必要とする場合、またはリモートFTPサーバーがそ
     れをサポートする場合はいつでも安全に接続したい場合に必要になること
     があります。 誤って構成されたサーバーで証明書検証エラーが発生する可
     能性があるため、デフォルトはfalseです。

http.maxRequests
     並行して起動するHTTPリクエストの数。 ‘GIT_HTTP_MAX_REQUESTS’ 環境変
     数でオーバーライドできます。 デフォルトは 5 です。

http.minSessions
     リクエスト間で保持されるcurlセッションの数(スロット全体でカウント
     )。 http_cleanup() が呼び出されるまで、curl_easy_cleanup()で終了す
     ることはありません。 USE_CURL_MULTIが定義されていない場合、この値の
     上限は1になります。 デフォルトは1です。

http.postBuffer
     リモートシステムにデータをPOSTするときにスマートHTTPトランスポート
     によって使用されるバッファーの最大サイズ(バイト単位)。 このバッファ
     サイズより大きいリクエストの場合、 HTTP/1.1 と Transfer-Encoding: チ
     ャンクが使用され、ローカルで大規模なパックファイルが作成されるのを
     防ぎます。 デフォルトは1MiBで、ほとんどのリクエストでは十分です。

     この制限を引き上げることは、チャンク転送エンコーディングを無効にす
     る場合にのみ有効であるため、リモートサーバーまたはプロキシが
     HTTP/1.0 のみをサポートするか、HTTP標準に準拠していない場合にのみ使
     用する必要があることに注意してください。 この制限を引き上げることは
     、一般に、ほとんどのプッシュの問題に対して効果的な解決策ではありま
     せんが、小さなプッシュに対してもバッファー全体が割り当てられるため
     、メモリー消費を大幅に増やす可能性があります。

http.lowSpeedLimit, http.lowSpeedTime
     ‘http.lowSpeedTime’ 秒より長いために、HTTP転送速度が
     ‘http.lowSpeedLimit’ 未満の場合、転送は中止されます。
     ‘GIT_HTTP_LOW_SPEED_LIMIT’ および ‘GIT_HTTP_LOW_SPEED_TIME’ 環境変
     数でオーバーライドできます。

http.noEPSV
     curlによるEPSV ftpコマンドの使用を無効にするブール値。 これは、
     EPSVモードをサポートしていない一部の「貧弱な」ftpサーバーで役立ちま
     す。 ‘GIT_CURL_FTP_NO_EPSV’ 環境変数でオーバーライドできます。 デフ
     ォルトはfalseです(curlはEPSVを使用します)。

http.userAgent
     HTTPサーバーに提示されるHTTP USER_AGENT文字列。 デフォルト値は、
     git/1.7.1などのクライアントGitのバージョンを表します。 このオプショ
     ンを使用すると、この値をMozilla/4.0などのより一般的な値にオーバーラ
     イドできます。 これは、たとえば、HTTP接続を一連の一般的な
     USER_AGENT文字列(ただし、 git/1.7.1 などは含まない、)に制限するファ
     イアウォールを介して接続する場合に必要になることがあります。
     ‘GIT_HTTP_USER_AGENT’ 環境変数で上書きできます。

http.followRedirects
     gitがHTTPリダイレクトに従うべきかどうか。 ‘true’ に設定されている場
     合、gitは、検出したサーバーによって発行されたリダイレクトを透過的に
     追跡します。 ‘false’ に設定すると、gitはすべてのリダイレクトをエラ
     ーとして扱います。 ‘initial’ に設定されている場合、gitはリモートへ
     の最初のリクエストに対してのみリダイレクトに従いますが、後続のフォ
     ローアップHTTPリクエストに対しては追跡しません。 gitはリダイレクト
     されたURLをフォローアップリクエストのベースとして使用するため、通常
     はこれで十分です。 デフォルトは ‘initial’ です。

http.<url>.*
     上記の ‘http.*’ オプションはいずれも、一部のURLに選択的に適用できま
     す。 構成キーがURLと一致するように、構成キーの各要素がURLの要素と以
     下の順序で比較されます:

       1. スキーム(例: ‘https://example.com/’ の ‘https’ の部分)。 この
          フィールドは、構成キーとURLの間で正確に一致する必要があります
          。

       2. ホスト/ドメイン名(例: ‘https://example.com/’ の ‘example.com’
          の部分)。 このフィールドは、構成キーとURLの間で一致する必要が
          あります。 このレベルのすべてのサブドメインに一致するように、
          ホスト名の一部として ‘*’ を指定することができます。 たとえば、
          ‘https://*.example.com/’ は ‘https://foo.example.com/’ と一致
          しますが、 ‘https://foo.bar.example.com/’ とは一致しません。

       3. ポート番号(例: ‘http://example.com:8080/’ の ‘8080’ の部分)。
          このフィールドは、構成キーとURLの間で正確に一致する必要があり
          ます。 省略されたポート番号は、照合する前に、スキームの正しい
          デフォルトに自動的に変換されます。

       4. パス(例: ‘https://example.com/repo.git’ の ‘repo.git’ の部分
          )。 構成キーのパスフィールドは、URLのパスフィールドと正確に一
          致するか、スラッシュ(‘/’)で区切られたパス要素のプレフィックス
          として一致する必要があります。 これは、パス ‘foo/’ の設定キー
          がURLパス ‘foo/bar’ と一致することを意味します。 プレフィック
          スは、スラッシュ(‘/’)境界でのみ一致できます。 長い一致が優先さ
          れます(したがって、パス ‘foo/bar’ の構成キーは、パス ‘foo/’ の
          構成キーよりもURLパス ‘foo/bar’ によく一致します)。

       5. ユーザー名(例: ‘https://user@example.com/repo.git’ の ‘user’ の
          部分)。 構成キーにユーザー名がある場合は、URLのユーザー名と正
          確に一致する必要があります。 構成キーにユーザー名がない場合、
          その構成キーは任意のユーザー名(ユーザー名無しを含む)のURLと一
          致しますが、ユーザー名の構成キーよりも優先順位は低くなります。

     上記のリストは、優先順位の高い順に並べられています。 構成キーのパス
     に一致するURLは、そのユーザー名に一致するURLよりも優先されます。 例
     えば、URLが ‘https://user@example.com/foo/bar’ の場合、
     ‘https://user@example.com’ の設定キーの一致よりも
     ‘https://example.com/foo’ の設定キーの一致が優先されます。

     すべてのURLは、照合を試みる前に正規化されます(パスワード部分がURLに
     埋め込まれている場合、照合目的では常に無視されます)。これにより、ス
     ペルが異なる同等のURLが正しく照合されます。 環境変数の設定は、常に
     一致を上書きします。 照合されるURLは、Gitコマンドに直接指定された
     URLです。 これは、リダイレクトの結果としてアクセスされたURLがマッチ
     ングに参加しないことを意味します。

i18n.commitEncoding
     コミットメッセージの文字エンコーディングは保存されます。 Gitそれ自
     体は気にしませんが、この情報は必要です。 例えば、電子メールまたは
     gitkグラフィカル履歴ブラウザーからコミットをインポートする場合(そし
     ておそらく将来の他の場所や他の磁器コマンドでも)です。例として
     linkgit：git-mailinfo[1] を参照してください。 デフォルトは ‘utf-8’
     です。

i18n.logOutputEncoding
     コミットメッセージの文字エンコーディングは、 ‘git log’ やその仲間を
     実行するときに変換されます。

imap.folder
     メールをドロップするフォルダー。通常はドラフトフォルダーです。 例：
     「INBOX.Drafts」とか「INBOX/Drafts」とか「[Gmail]/Drafts」です。必
     須です。

imap.tunnel
     サーバーへの直接ネットワーク接続を使用する代わりに、コマンドがパイ
     プされるIMAPサーバーへのトンネルをセットアップするために使用される
     コマンド。 imap.host が設定されていない場合に必須です。

imap.host
     サーバーを識別するURL。 非セキュア接続には ‘imap://’ プレフィックス
     を使用し、セキュア接続には ‘imaps://’ プレフィックスを使用します。
     imap.tunnel が設定されている場合は無視されますが、それ以外の場合は
     必須です。

imap.user
     サーバーにログインするときに使用するユーザー名。

imap.pass
     サーバーにログインするときに使用するパスワード。

imap.port
     サーバー上で接続する整数のポート番号。 デフォルトは、 imap:// ホス
     トの場合は143、 imaps:// ホストの場合は993です。 imap.tunnel が設定
     されている場合は無視されます。

imap.sslverify
     SSL/TLS接続で使用されるサーバー証明書の検証を有効/無効にするブール
     値。デフォルトは ‘true’ です。 imap.tunnel が設定されている場合は無
     視されます。

imap.preformattedHTML
     パッチを送信するときにhtmlエンコーディングの使用を有効/無効にするブ
     ール値。 htmlでエンコードされたパッチは <pre> で囲まれ、コンテンツ
     タイプは text/html になります。皮肉なことに、このオプションを有効に
     すると、Thunderbirdはパッチを plane/text の format=fixed メールとし
     て送信します。デフォルトは ‘false’ です。

imap.authMethod
     IMAPサーバーでの認証の認証方法を指定します。GitがNO_CURLオプション
     を使用してビルドされた場合、curlバージョンが7.34.0より古い場合、ま
     たはgit-imap-sendを ‘--no-curl’ オプションを指定して実行している場
     合、サポートされるメソッドは _CRAM-MD5_ のみです。これが設定されて
     いない場合、「git imap-send」は基本的なIMAPプレーンテキストLOGINコ
     マンドを使用します。

index.recordEndOfIndexEntries
     インデックスファイルに「End Of Index Entry」セクションを含めるかど
     うかを指定します。 これにより、マルチプロセッサマシンでのインデック
     スの読み込み時間が短縮されますが、2.20より前のバージョンのGitを使用
     してインデックスを読み取ると、「ignoring EOIE extension」というメッ
     セージが表示されます。 index.threads が明示的に有効になっている場合
     はデフォルトで ‘true’ 、それ以外の場合は ‘false’ になります。

index.recordOffsetTable
     インデックスファイルに「Index Entry Offset Table」セクションを含め
     るかどうかを指定します。 これにより、マルチプロセッサマシンでのイン
     デックスの読み込み時間が短縮されますが、2.20より前のバージョンの
     Gitを使用してインデックスを読み取ると、「ignoring IEOT extension」
     というメッセージが表示されます。 index.threadsが明示的に有効になっ
     ている場合はデフォルトで ‘true’ 、それ以外の場合は ‘false’ になりま
     す。

index.sparse
     有効にすると、sparse-directory エントリを使用してインデックスを書き
     込みます。 ‘core.sparseCheckout’ と ‘core.sparseCheckoutCone’ の両
     方が有効になっていない限り、これは効果がありません。 デフォルトは
     ‘false’ です。

index.threads
     インデックスをロードするときに生成するスレッドの数を指定します。 こ
     れは、マルチプロセッサマシンでのインデックスのロード時間を短縮する
     ことを目的としています。 0または ‘true’ を指定すると、GitはCPUの数
     を自動検出し、それに応じてスレッドの数を設定します。 1または
     _false_ を指定すると、マルチスレッドが無効になります。 デフォルトは
     ‘true’ です。

index.version
     新しいインデックスファイルを初期化するバージョンを指定します。 これ
     は既存のリポジトリには影響しません。 ‘feature.manyFiles’ が有効にな
     っている場合、デフォルトは4です。

init.templateDir
     テンプレートのコピー元のディレクトリを指定します。 (git-init(1) の
     「TEMPLATE DIRECTORY」セクションを参照してください。)

init.defaultBranch
     デフォルトのブランチ名を上書きできます。例えば、新しいリポジトリを
     初期化するとき。

instaweb.browser
     gitwebであなたの作業リポジトリをブラウズするために使用されるプログ
     ラムを指定します。 git-instaweb(1) を参照してください。

instaweb.httpd
     あなたの作業リポジトリでgitwebを起動するためのHTTPデーモンコマンド
     ライン。 git-instaweb(1) を参照してください。

instaweb.local
     trueの場合、 git-instaweb(1) によって起動されたWebサーバーはローカ
     ルIP(local IP)(127.0.0.1)にバインドされます。

instaweb.modulePath
     ‘/usr/lib/apache2/modules’ の代わりに使用する git-instaweb(1) のデ
     フォルトのモジュールパス。httpdがApacheの場合にのみ使用されます。

instaweb.port
     gitweb httpdをバインドするポート番号。 git-instaweb(1) を参照してく
     ださい。

interactive.singleKey
     対話コマンドでは、ユーザーが1つのキーで1文字の入力を提供できるよう
     にします(つまり、Enterキーを押さずに)。 現在、これは git-add(1) と
     git-checkout(1) と git-restore(1) と git-commit(1) と git-reset(1)
     と git-stash(1) の ‘--patch’ モードで使用されています。 ポータブル
     キーストローク入力(portable keystroke input)が利用できない場合、こ
     の設定は黙って無視されることに注意してください。 Perlモジュール
     Term::ReadKey が必要です。

interactive.diffFilter
     対話コマンド(‘git add --patch’ など)が色付きのdiffを表示すると、
     gitはこの構成変数で定義されたシェルコマンドを介してdiffをパイプしま
     す。 コマンドは、元のdiffの行と1対1の対応を保持している場合、人間に
     読みやすいようにdiffをさらにマークアップできます。 デフォルトは無効
     (フィルタリングなし)です。

log.abbrevCommit
     trueの場合、 linkgit:git-log [1] と git-show(1) と
     git-whatchanged(1) に ‘--abbrev-commit’ を想定させます。 このオプシ
     ョンは ‘--no-abbrev-commit’ で上書きできます。

log.date
     ‘log’ コマンドのデフォルトの日時モードを設定します。 log.dateの値の
     設定は、 ‘git log’ の ‘--date’ オプションと同様です。 詳細について
     は、 git-log(1) を参照してください。

log.decorate
     logコマンドで表示されるコミットのref名を出力します。 ‘short’ が指定
     されている場合、ref名の接頭辞 ‘refs/heads/’ と ‘refs/tags/’ と
     ‘refs/remotes/’ は出力されません。 ‘full’ が指定されている場合、完
     全なref名(接頭辞を含む)が出力されます。 ‘auto’ が指定されている場合
     、出力が端末に送られる場合、ref名は ‘short’ が指定されているかのよ
     うに表示されます。それ以外の場合、ref名は表示されません。 これは、
     ‘git log’ の ‘--decorate’ オプションと同じです。

log.excludeDecoration
     ログ装飾(log decorations)から指定されたパターンを除外します。 これ
     は ‘--decorate-refs-exclude’ コマンドラインオプションに似ていますが
     、構成オプションは ‘--decorate-refs’ オプションで上書きできます。

log.diffMerges
     マージコミットに使用されるデフォルトのdiff形式を設定します。 詳細に
     ついては、 git-log(1) の ‘--diff-merges’ を参照してください。 デフ
     ォルトは ‘separate’ です。

log.follow
     ‘true’ の場合、 ‘git log’ は、単一の<path>が指定されたときに
     ‘--follow’ オプションが使用されたかのように機能します。 これには
     ‘--follow’ と同じ制限があります。つまり、複数のファイルを追跡するた
     めに使用することはできず、非線形履歴ではうまく機能しません。

log.graphColors
     ‘git log --graph’ で履歴線(history lines)を描画するために使用できる
     、コンマで区切られた色のリスト。

log.showRoot
     trueの場合、最初のコミットは大きな作成イベントとして表示されます。
     これは、空のツリーに対するdiffに相当します。 git-log(1) や
     git-whatchanged(1) などのツールは、通常はルートコミットを隠していま
     すが、今後は表示されるようになります。 デフォルトでは True です。

log.showSignature
     trueの場合、 git-log(1) と git-show(1) と git-whatchanged(1) に
     ‘--show-signature’ を想定させます。

log.mailmap
     trueの場合、 git-log(1) と git-show(1) と git-whatchanged(1) で
     ‘--use-mailmap’ を想定させ、それ以外の場合は ‘--no-use-mailmap’ を
     想定させます。 デフォルトではtrueです。

lsrefs.unborn
     「advertise」(デフォルト)または「allow」または「ignore」の場合があ
     ります。 「advertise」の場合、サーバーは「unborn」
     (protocol-v2.txtに説明があります)を送信するクライアントに応答し、プ
     ロトコルv2機能の広告(advertise)中にこの機能のサポートを広告します。
     「allow」は「advertise」と同じですが、サーバーがこの機能のサポート
     を広告しない点が異なります。 これは、管理者が「allow」を構成し、遅
     れて「advertise」を構成できるため、(たとえば、)アトミックに更新でき
     ない負荷分散サーバーに役立ちます。

mailinfo.scissors
     trueの場合、 git-mailinfo(1) (それゆえ git-am(1) も)は、コマンドラ
     インで ‘--scissors’ オプションが指定されているかのようにデフォルト
     で動作します。この機能がアクティブな場合、メッセージ本文から切り取
     り線(つまり、主に ">8" や "8<" や "-" で構成される)行とそれより前の
     すべてを削除します。

mailmap.file
     拡張メールマップファイルの場所。リポジトリのルートにあるデフォルト
     のメールマップが最初にロードされ、次にこの変数が指すメールマップフ
     ァイルがロードされます。メールマップファイルの場所は、リポジトリサ
     ブディレクトリ内、またはリポジトリの外部のどこかにあります。
     git-shortlog(1) と git-blame(1) を参照してください。

mailmap.blob
     ‘mailmap.file’ と同様ですが、値をリポジトリ内のブロブへの参照と見な
     します。 ‘mailmap.file’ と ‘mailmap.blob’ の両方が指定されている場
     合、両方が解析され、 ‘mailmap.file’ からのエントリが優先されます。
     この変数は、ベアリポジトリではデフォルトで ‘HEAD:.mailmap’ になりま
     す。非ベアリポジトリでは、デフォルトで空になります。

maintenance.auto
     このブール構成オプションは、一部のコマンドが通常の作業を行った後に
     ‘git maintenance run --auto’ を実行するかどうかを制御します。 デフ
     ォルトはtrueです。

maintenance.strategy
     この文字列設定オプションは、バックグラウンドメンテナンスのいくつか
     の推奨スケジュールの1つを指定する方法を提供します。 これは、
     ‘--task=<task>’ 引数が指定されていない場合、 ‘git maintenance run
     --schedule=X’ コマンド中に実行されるタスクにのみ影響します。 さらに
     、 ‘maintenance.<task>.schedule’ 構成値が設定されている場合、
     ‘maintenance.strategy’ によって提供される値の代わりにその値が使用さ
     れます。 戦略として指定可能な文字列は以下のとおりです:

        • ‘none’: このデフォルト設定は、どのスケジュールでもタスクが実行
          されないことを意味します。

        • ‘incremental’: この設定は、データを削除しない小さなメンテナン
          スアクティビティの実行に最適化されています。 これは ‘gc’ タス
          クをスケジュールしませんが、 ‘prefetch’ および ‘commit-graph’
          タスクを1時間ごとに実行し、 ‘loose-objects’ および
          ‘incremental-repack’ タスクを毎日実行し、 ‘pack-refs’ タスクを
          毎週実行します。

maintenance.<task>.enabled
     このブール構成オプションは、 ‘git maintenance run’ に ‘--task’ オプ
     ションが指定されていない場合に、 ‘<task>’ という名前のメンテナンス
     タスクを実行するかどうかを制御します。 ‘--task’ オプションが存在す
     る場合、これらの構成値は無視されます。 デフォルトでは、
     ‘maintenance.gc.enabled’ のみがtrueです。

maintenance.<task>.schedule
     この設定オプションは、指定された ‘<task>’ が ‘git maintenance run
     --schedule=<frequency>’ コマンド中に実行されるかどうかを制御します
     。 値は、 "hourly", "daily", "weekly" のいずれかである必要がありま
     す。

maintenance.commit-graph.auto
     この整数値構成オプションは、 ‘git maintenance run --auto’ の一部と
     して ‘commit-graph’ タスクを実行する頻度を制御します。 ゼロの場合、
     ‘commit-graph’ タスクは‘–auto‘ オプションで実行されません。負の値を
     指定すると、タスクは毎回実行されます。 それ以外の場合、正の値は、
     commit-graphファイルにない到達可能なコミットの数が
     ‘maintenance.commit-graph.auto’ の値以上であるときにコマンドを実行
     する必要があることを意味します。デフォルト値は100です。

maintenance.loose-objects.auto
     この整数値構成オプションは、 ‘git maintenance run --auto’ の一部と
     して ‘loose-objects’ タスクを実行する頻度を制御します。 ゼロの場合
     、 ‘loose-objects’ タスクは ‘--auto’ オプションでは実行されません。
     負の値を指定すると、タスクは毎回実行されます。 それ以外の場合、正の
     値は、緩いオブジェクト(loose objects)の数が
     ‘maintenance.loose-objects.auto’ の値以上であるときにコマンドを実行
     する必要があることを意味します。 デフォルト値は100です。

maintenance.incremental-repack.auto
     この整数値構成オプションは、 ‘git maintenance run --auto’ の一部と
     して ‘incremental-repack’ タスクを実行する頻度を制御します。 ゼロの
     場合、 ‘incremental-repack’ タスクは ‘--auto’ オプションでは実行さ
     れません。 負の値を指定すると、タスクは毎回実行されます。 それ以外
     の場合、正の値は、multi-pack-indexにないpack-fileの数が
     ‘maintenance.incremental-repack.auto’ の値以上であるときにコマンド
     を実行する必要があることを意味します。 デフォルト値は10です。

man.viewer
     ヘルプを ‘man’ 形式で表示するために使用できるプログラムを指定します
     。 git-help(1) を参照してください。

man.<tool>.cmd
     指定されたmanビューア(<tool>)を呼び出すコマンドを指定します。指定さ
     れたコマンドは、引数として渡されたマニュアルページを使用してシェル
     で評価されます。(git-help(1) を参照してください。)

man.<tool>.path
     ‘man’ 形式でヘルプを表示するために使用される可能性のある特定のツー
     ル(<tool>)のパスをオーバーライドします。 git-help(1) を参照してくだ
     さい。

merge.conflictStyle
     マージ時に競合するハンクが作業ツリーファイルに書き出されるスタイル
     を指定します。 デフォルトは「merge」です。これは、 ‘<<<<<<<’ 競合マ
     ーカー、一方の側で行われた変更、 ‘=======’ マーカー、もう一方の側で
     行われた変更、そして ‘>>>>>>>’ マーカーというスタイルです。 別のス
     タイル「diff3」は、 ‘|||||||’ マーカーと元のテキストを ‘=======’ マ
     ーカーの前に追加します。

merge.defaultToUpstream
     コミット引数なしでmergeが呼び出された場合は、リモート追跡ブランチに
     格納されている最後に観測された値を使用して、現在のブランチ用に構成
     されたアップストリームブランチをマージします。
     ‘branch.<currentbranch>.remote’ によって指定されたリモートのブラン
     チに名前を付ける ‘branch.<currentbranch>.merge’ の値が参照され、次
     に、それらは ‘remote.<remote>.fetch’ を介して対応するリモート追跡ブ
     ランチにマッピングされ、そして、これらの追跡ブランチの先端がマージ
     されます。 デフォルトはtrueです。

merge.ff
     デフォルトでは、Gitは、現在のコミットの子孫であるコミットをマージす
     るときに、追加のマージコミットを作成しません。 代わりに、現在のブラ
     ンチの先端が早送り(fast-forward)されます。 ‘false’ に設定すると、こ
     の変数はGitにそのような場合に追加のマージコミットを作成するように指
     示します(コマンドラインから ‘--no-ff’ オプションを指定するのと同じ
     です)。 ‘only’ に設定すると、そのような早送りマージのみが許可されま
     す(コマンドラインから ‘--ff-only’ オプションを指定するのと同じです
     )。

merge.verifySignatures
     trueの場合、これは ‘--verify-signatures’ コマンドラインオプションと
     同等です。 詳細については、 git-merge(1) を参照してください。

merge.branchdesc
     ブランチ名に加えて、それらに関連付けられたブランチの説明テキストを
     ログメッセージに入力します。デフォルトはfalseです。

merge.log
     ブランチ名に加えて、マージされる実際のコミットからの最大「指定の数
     」の親コミットの1行説明をログメッセージに入力します。デフォルトは
     falseで、trueは20の同義語です。

merge.suppressDest
     統合ブランチの名前に一致するグロブをこの複数値の構成変数
     (multi-valued configuration variable)に追加することにより、これらの
     統合ブランチへのマージに対して計算されるデフォルトのマージメッセー
     ジは、タイトルから「into <branch name>」を省略します。

     空の値を持つ要素を使用して、以前の構成エントリから蓄積されたグロブ
     のリストをクリアできます。 ‘merge.suppressDest’ 変数が定義されてい
     ない場合、下位互換性のためにデフォルト値の ‘master’ が使用されます
     。

merge.renameLimit
     マージ処理中に名前変更検出の網羅的な部分で考慮するファイルの数。 指
     定されない場合、デフォルトは diff.renameLimit の値です。
     merge.renameLimit と diff.renameLimit の両方が指定されていない場合
     、現在のデフォルトは 7000 です。 この設定は、名前変更検出がオフの場
     合は効果がありません。

merge.renames
     Gitが名前の変更を検出するかどうか。 「false」に設定すると、名前変更
     の検出が無効になります。 「true」に設定すると、基本的な名前変更の検
     出が有効になります。 デフォルトは diff.renames の値です。

merge.directoryRenames
     Gitがディレクトリの名前変更を検出するかどうか。これは、履歴の一方の
     側でディレクトリが名前変更されたときに、もう一方の側で追加された新
     しいファイルがマージ時にどうなるのかに影響します。
     merge.directoryRenames を ‘false’ に設定すると、ディレクトリの名前
     変更の検出は無効になります。つまり、そのような新しいファイルは古い
     ディレクトリに残されます。 ‘true’ に設定すると、ディレクトリの名前
     変更検出が有効になり、そのような新しいファイルは新しいディレクトリ
     に移動されることを意味します。 ‘conflict’ に設定すると、そのような
     パスに対して競合が報告されます。 merge.renames が false の場合、
     merge.directoryRenames は無視され、false として扱われます。 デフォ
     ルトは ‘conflict’ です。

merge.renormalize
     リポジトリ内のファイルの標準の表現が時間の経過とともに変更されたこ
     とをGitに伝えます(たとえば、以前はCRLF行末のレコードテキストファイ
     ルをコミットしていましたが、最近のファイルはLF行末を使用している)。
     このようなリポジトリでは、Gitは、不必要な競合を減らすために、マージ
     を実行する前に、コミットに記録されたデータを標準形式に変換できます
     。 詳細については、gitattributes(5) の「Merging branches with
     differing checkin/checkout attributes」(チェックイン/チェックアウト
     属性が異なるブランチのマージ)のセクションを参照してください。

merge.stat
     マージの最後にORIG_HEADとマージ結果の間のdiffstatを出力するかどうか
     。 デフォルトではtrue。

merge.autoStash
     trueに設定すると、操作を開始する前に一時的なstashエントリを自動的に
     作成し、操作の終了後に適用します。 これは、ダーティ作業ツリーでマー
     ジを実行できることを意味します。 ただし、注意して使用してください。
     マージが成功した後の最後のstashアプリケーションは、重要な競合を引き
     起こす可能性があります。 このオプションは、 git-merge(1)の
     ‘--no-autostash’ および ‘--autostash’ オプションでオーバーライドで
     きます。 デフォルトはfalseです。

merge.tool
     git-mergetool(1) が使用するマージツールを制御します。 以下のリスト
     は、有効な組み込み値を示しています。その他の値はカスタムマージツー
     ルとして扱われ、対応する mergetool.<tool>.cmd 変数が定義されている
     必要があります。

merge.guitool
     ‘-g’/‘--gui’ フラグが指定されている場合に、 git-mergetool(1) が使用
     するマージツールを制御します。以下のリストは、有効な組み込み値を示
     しています。 その他の値はカスタムマージツールとして扱われ、対応する
     mergetool.<guitool>.cmd 変数が定義されている必要があります。

        • araxis

        • bc

        • bc3

        • bc4

        • codecompare

        • deltawalker

        • diffmerge

        • diffuse

        • ecmerge

        • emerge

        • examdiff

        • guiffy

        • gvimdiff

        • gvimdiff1

        • gvimdiff2

        • gvimdiff3

        • kdiff3

        • meld

        • nvimdiff

        • nvimdiff1

        • nvimdiff2

        • nvimdiff3

        • opendiff

        • p4merge

        • smerge

        • tkdiff

        • tortoisemerge

        • vimdiff

        • vimdiff1

        • vimdiff2

        • vimdiff3

        • winmerge

        • xxdiff

merge.verbosity
     再帰的マージ戦略によって示される出力の量を制御します。 レベル0は、
     競合が検出された場合の最終エラーメッセージ以外は何も出力しません。
     レベル1は競合のみを出力し、レベル2は競合とファイル変更を出力します
     。 レベル5以上はデバッグ情報を出力します。 デフォルトはレベル2です
     。 ‘GIT_MERGE_VERBOSITY’ 環境変数でオーバーライドできます。

merge.<driver>.name
     カスタムの低レベルマージドライバーの人間が読める名前を定義します。
     詳細については、 gitattributes(5) を参照してください。

merge.<driver>.driver
     カスタムの低レベルのマージドライバーを実装するコマンドを定義します
     。 詳細については、 gitattributes(5) を参照してください。

merge.<driver>.recursive
     共通の祖先間で内部マージを実行するときに使用される低レベルのマージ
     ドライバーに名前を付けます。 詳細については、 gitattributes(5) を参
     照してください。

mergetool.<tool>.path
     指定のツール(<tool>)のパスを上書きします。 これは、ツールがPATH上に
     ない場合に役立ちます。

mergetool.<tool>.cmd
     指定のマージツール(<tool>)を呼び出すコマンドを指定します。指定され
     たコマンドは、次の変数を使用してシェルで評価されます: ‘BASE’ は、マ
     ージされるファイルの共通ベースを含む一時ファイルの名前です(使用可能
     な場合)。 ‘LOCAL’ は、現在のブランチのファイルの内容を含む一時ファ
     イルの名前です。 ‘REMOTE’ は、マージされるブランチのファイルの内容
     を含む一時ファイルの名前です。 ‘MERGED’ は、マージツールが正常なマ
     ージの結果を書き込むファイルの名前が含まれています。

mergetool.<tool>.hideResolved
     ユーザーが特定のツール(<tool>)のグローバルな
     ‘mergetool.hideResolved’ 値をオーバーライドできるようにします。 詳
     細については、 ‘mergetool.hideResolved’ を参照してください。

mergetool.<tool>.trustExitCode
     カスタムマージコマンドの場合、マージコマンドの終了コードを使用して
     マージが成功したかどうかを判断できるかどうかを指定します。 これが
     trueで無い場合、マージターゲットファイルのタイムスタンプがチェック
     され、ファイルが更新されている場合はマージが成功したと見なされます
     。そうでない場合、ユーザーはマージの成功を示すように求められます。

mergetool.meld.hasOutput
     古いバージョンの ‘meld’ は ‘--output’ オプションをサポートしていま
     せん。 Gitは、 ‘meld --help’ の出力を調べることで、 ‘meld’ が
     ‘--output’ をサポートしているかどうかを検出しようとします。
     ‘mergetool.meld.hasOutput’ を設定すると、Gitはこれらのチェックをス
     キップし、代わりに設定された値を使用します。
     ‘mergetool.meld.hasOutput’ を ‘true’ に設定すると、Gitは無条件に
     ‘--output’ オプションを使用するようになり、 ‘false’ は ‘--output’ の
     使用を回避します。

mergetool.meld.useAutoMerge
     meld は ‘--auto-merge’ が指定されると、競合しないすべての部分を自動
     的にマージし、競合する部分を強調表示して、ユーザーの決定を待ちます
     。 ‘mergetool.meld.useAutoMerge’ を‘true‘に設定すると、Gitは
     ‘--auto-merge’ オプションを ‘meld’ で無条件に使用するようになります
     。 この値を ‘auto’ に設定すると、gitは ‘--auto-merge’ がサポートさ
     れているかどうかを検出し、使用可能な場合にのみ ‘--auto-merge’ を使
     用します。 ‘false’ の値はデフォルト値で、‘ –auto-merge‘ の使用を完
     全に回避します。

mergetool.hideResolved
     マージ処理中、Gitは可能な限り多くの競合を自動的に解決し、解決できな
     い競合の周りに競合マーカーを含ませた ‘MERGED’ ファイルを書き込みま
     す。 「LOCAL」と「REMOTE」は通常、Gitの競合解決前のファイルのバージ
     ョンを表します。 この設定により、「LOCAL」と「REMOTE」が上書きされ
     、未解決の競合のみがマージツールに表示されます。
     ‘mergetool.<tool>.hideResolved’ 構成変数を介してツールごとに構成で
     きます。 デフォルトは ‘false’ です。

mergetool.keepBackup
     マージを実行した後、競合マーカーを含む元のファイルを、拡張子
     ‘.orig’ のファイルとして保存できます。 この変数が ‘false’ に設定さ
     れている場合、このファイルは保存されません。 デフォルトは ‘true’ で
     す(つまり、バックアップファイルを保持します)。

mergetool.keepTemporaries
     カスタムマージツールを呼び出すとき、Gitは一時ファイルの組をツールに
     渡します。 ツールがエラーを返し、この変数が ‘true’ に設定されている
     場合、これらの一時ファイルは保持されます。それ以外の場合、ツールの
     終了後に削除されます。 デフォルトは ‘false’ です。

mergetool.writeToTemp
     Gitは、デフォルトで、競合するファイルの一時的な 「BASE」バージョン
     と「LOCAL」バージョンと「REMOTE」バージョンをワークツリーに書き込み
     ます。 ‘true’ に設定すると、Gitはこれらのファイルに一時ディレクトリ
     を使用しようとします。 デフォルトは ‘false’ です。

mergetool.prompt
     マージ解決プログラムを呼び出す前にプロンプトを表示します。

notes.mergeStrategy
     ノートの競合を解決するときにデフォルトで選択するマージ戦略。
     ‘manual’ 、‘ ours‘、 ‘theirs’、‘ union‘ 、‘cat_sort_uniq’ のいずれ
     かである必要があります。 デフォルトは ‘manual’ です。 各戦略の詳細
     については、 git-notes(1) の「NOTES MERGE STRATEGIES」セクションを
     参照してください。

notes.<name>.mergeStrategy
     ‘refs/notes/<name>’ にノートをマージするときに、どのマージ戦略を選
     択するか。 これは、より一般的な ‘notes.mergeStrategy’ をオーバーラ
     イドします。 利用可能な戦略の詳細については、 git-notes(1) の「
     NOTES MERGE STRATEGIES」セクションを参照してください。

notes.displayRef
     コミットメッセージを表示するときにノートを表示する、(完全修飾された
     )refname。 この変数の値はグロブ(glob)に設定できます。その場合、一致
     するすべての参照からのノートが表示されます。 この構成変数を複数回指
     定することもできます。 存在しない参照に対しては警告が発行されますが
     、どの参照とも一致しないグロブは黙って無視されます。

     この設定は、 ‘GIT_NOTES_DISPLAY_REF’ 環境変数でオーバーライドでき、
     環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要
     があります。

     ‘core.notesRef’ の有効な値(GIT_NOTES_REFによってオーバーライドされ
     る可能性があります)も、表示されるrefのリストに暗黙的に追加されます
     。

notes.rewrite.<command>
     <command> (現在は ‘amend’ または ‘rebase’)でコミットを書き換え、そ
     して、この変数が ‘true’ に設定されている場合、Gitはノートを元のコミ
     ットから書き換えられたコミットに自動的にコピーします。 デフォルトは
     ‘true’ ですが、下記 ‘notes.rewriteRef’ を参照してください。

notes.rewriteMode
     書き換え時にノートをコピーする場合(‘notes.rewrite.<command>’ オプシ
     ョン参照)、ターゲットコミットにすでにノートがある場合の対処方法を決
     定します。 ‘overwrite’ 、 ‘concatenate’ 、 ‘cat_sort_uniq’ 、
     ‘ignore’ のいずれかである必要があります。 デフォルトは
     ‘concatenate’ です。

     この設定は、 ‘GIT_NOTES_REWRITE_MODE’ 環境変数でオーバーライドでき
     ます。

notes.rewriteRef
     書き換え中にノートをコピーする場合は、ノートをコピーする(完全修飾さ
     れた)refを指定します。 refはグロブ(glob)である可能性があり、その場
     合、一致するすべてのrefのノートがコピーされます。 この構成を複数回
     指定することもできます。

     デフォルト値はありません。 ノートの書き換えを有効にするには、この変
     数を構成する必要があります。 デフォルトのコミットノートの書き換えを
     有効にするには、これを ‘refs/notes/commits’ に設定します。

     この設定は、 ‘GIT_NOTES_REWRITE_REF’ 環境変数でオーバーライドでき、
     環境変数はコロンで区切られたrefまたはグロブ(glob)のリストである必要
     があります。

pack.window
     コマンドラインでウィンドウサイズが指定されていない場合に
     git-pack-objects(1) によって使用されるウィンドウのサイズ。デフォル
     トは10です。

pack.depth
     コマンドラインで最大深度が指定されていない場合に
     git-pack-objects(1) によって使用される最大デルタ深度。デフォルトは
     50です。最大値は4095です。

pack.windowMemory
     コマンドラインで制限が指定されていない場合に、パックウィンドウメモ
     リの git-pack-objects(1) の各スレッドで消費されるメモリの最大サイズ
     。値には、「k」または「m」または「g」の接尾辞を付けることができます
     。未構成のまま(または明示的に0に設定する)にした場合、制限はありませ
     ん。

pack.compression
     パックファイル内のオブジェクトの圧縮レベルを示す整数 -1〜9。-1は
     zlibのデフォルトです。0は圧縮がないことを意味し、1〜9はさまざまな速
     度とサイズのトレードオフであり、9が最も低速です。設定されていない場
     合のデフォルトは core.compression です。 core.compression も設定さ
     れていない場合、デフォルトは -1 になります。これは、「速度と圧縮の
     間のデフォルトの妥協点(現在はレベル6と同等)」であるzlibのデフォルト
     です。

     注意: 圧縮レベルを変更しても、既存のすべてのオブジェクトが自動的に
     再圧縮されるわけではないことに注意してください。 ‘-F’ オプションを
     git-repack(1) に渡すことで、強制的に再圧縮できます。

pack.allowPackReuse
     trueの場合、かつ、到達可能性ビットマップ(reachability bitmaps)が有
     効になっている場合、pack-objectsはビットマップ化されたパックファイ
     ルの一部をそのままで送信しようとします。これにより、フェッチを提供
     するためのメモリとCPUの使用量を減らすことができますが、送信するパッ
     クが少し大きくなる可能性があります。デフォルトはtrueです。

pack.island
     デルタアイランド(delta islands)のセットを構成する拡張正規表現。詳細
     については、 git-pack-objects(1) の「DELTA ISLANDS」を参照してくだ
     さい。

pack.islandCore
     オブジェクトを最初にパックする島名(island name)を指定します。 これ
     により、1つのパックの前に一種の疑似パックが作成されるため、指定の島
     のオブジェクトを、これらのオブジェクトを要求するユーザーに提供する
     必要のあるパックにコピーする速度が速くなることが期待されます。実際
     には、これは、指定された島が、リポジトリで最も一般的に複製される島
     に対応している可能性が高いことを意味します。 git-pack-objects(1) の
     「DELTA ISLANDS」も参照してください。

pack.deltaCacheSize
     デルタをパックに書き出す前に、 git-pack-objects(1) でデルタをキャッ
     シュするために使用されるバイト単位の最大メモリ。すべてのオブジェク
     トに最適なものが見つけたあとで、このキャッシュがあれば、最終的なデ
     ルタ結果を再計算する必要がないため、オブジェクトの書き込みフェーズ
     を高速化できます。そのために使用されます。ただし、メモリが不足して
     いるマシンで大規模なリポジトリを再パックして、特にこのキャッシュが
     システムをスワップに追いやる場合、これによって悪影響を受ける可能性
     があります。値0は、制限がないことを意味します。このキャッシュを事実
     上無効にするために、最小サイズの1バイトを使用できます。デフォルトは
     256MiBです。

pack.deltaCacheLimit
     git-pack-objects(1) でキャッシュされるデルタの最大サイズ。すべての
     オブジェクトに最適なものが見つかった後、このキャッシュがあれば、最
     終的なデルタ結果を再計算する必要がないため、オブジェクトの書き込み
     フェーズを高速化します。そのために使用されます。デフォルトは1000で
     す。最大値は65535です。

pack.threads
     最適なデルタマッチングを検索するときに生成するスレッドの数を指定し
     ます。このためには git-pack-objects(1)をpthreadでコンパイルする必要
     があります。そうしないと、このオプションは無視され、警告が表示され
     ます。 これは、マルチプロセッサマシンでのパッキング時間を短縮するこ
     とを目的としています。ただし、デルタ検索ウィンドウに必要なメモリ量
     は、スレッド数で乗算されます。0を指定すると、GitはCPUの数を自動検出
     し、それに応じてスレッドの数を設定します。

pack.indexVersion
     デフォルトのパックインデックスバージョンを指定します。有効な値は、
     1.5.2より前のバージョンで使用されていたレガシーパックインデックスの
     場合は1、4GBを超えるパックの機能と破損したパックの再パックに対する
     適切な保護を備えた新しいパックインデックスの場合は2です。バージョン
     2がデフォルトです。注意: 対応するパックが2GBを超える場合は常にバー
     ジョン2が適用され、この構成オプションは無視されることに注意してくだ
     さい。

     バージョン2の ‘*.idx’ ファイルを理解しない古いGitを使用している場合
     は、 ‘*.pack’ ファイルと対応する ‘*.idx’ ファイルの両方を反対側から
     コピーする非ネイティブプロトコル(例:http)を介してクローンを作成また
     はフェッチすると、古いバージョンのGitではアクセスできないリポジトリ
     が提供される場合があります。けれども、 ‘*.pack’ ファイルが2GBより小
     さい場合は、 *.pack に git-index-pack(1) を使用して、 ‘*.idx’ ファ
     イルを再生成できます。

pack.packSizeLimit
     パックの最大サイズ。この設定は、再パック時にファイルへパッキングす
     るときのみ影響します。つまり、 git:// プロトコルは影響を受けません
     。 git-repack(1) の ‘--max-pack-size’ オプションでオーバーライドで
     きます。この制限に達すると、複数のパックファイルが作成されます。

     注意: このオプションが役立つことはめったになく、(Gitはパックにまた
     がるデルタを保存しないため、)ディスク上の合計サイズが大きくなり、実
     行時のパフォーマンスが低下する可能性があることに注意してください(複
     数のパック内のオブジェクトルックアップは単一のパックで行うよりも遅
     く、到達可能性ビットマップなどの最適化は複数パックに対応できません
     )。

     (たとえば、ファイルシステムが大きいファイルをサポートしていないため
     、)あなたが小さいパックファイルを使用してGitをバリバリと使う必要が
     ある場合、このオプションが役立かもしれません。ただし、限られたサイ
     ズをサポートするメディア(たとえば、リポジトリ全体を保存できないリム
     ーバブルメディア)を介してパックファイルを送信することが目標である場
     合は、単一の大きなパックファイルを作成し、一般的なマルチボリューム
     アーカイブツール(例えば Unix ‘split’ )を使用して分割する方がよいで
     しょう。

     許可される最小サイズは1MiBに制限されています。デフォルトの大きさは
     無制限です。 _k_ または _m_ または _g_ の一般的な単位接尾辞がサポー
     トされています。

pack.useBitmaps
     trueの場合、(たとえば、フェッチ作業中のサーバー側で、)gitはstdoutに
     パックするときに(可能な場合は、)パックビットマップを使用します。デ
     フォルトはtrueです。パックビットマップをデバッグしている場合を除い
     て、通常、これをオフにする必要はありません。

pack.useSparse
     trueの場合、 gitは _git pack-objects‘ で ’–revs_ オプションが存在す
     る場合、デフォルトで ‘--sparse’ オプションを使用します。このアルゴ
     リズムは、新しいオブジェクトを導入するパスに現れるツリーのみをウォ
     ークします。これは、小さな変更を送信するパックを計算するときに、パ
     フォーマンスに大きなメリットをもたらす可能性があります。ただし、含
     まれているコミットに特定の種類の直接名前変更(direct renames)が含ま
     れている場合は、パックファイルに追加のオブジェクトが追加される可能
     性があります。 デフォルトは ‘true’ です。

pack.preferBitmapTips
     ビットマップを受け取るコミットを選択するときは、「選択ウィンドウ」
     (selection window)の他のコミットよりも、この構成の任意の値の接尾辞
     である参照の先端にあるコミットを優先します。

     注意: この設定を ‘refs/foo’ に設定しても、 ‘refs/foo/bar’ と
     ‘refs/foo/baz’ の先端のコミットが必ずしも選択されるわけではないこと
     に注意してください。 これは、可変長の一連のウィンドウ内からビットマ
     ップに対してコミットが選択されるためです。

     この構成の任意の値の接尾辞である参照の先端にあるコミットがウィンド
     ウに表示された場合、そのウィンドウ内の他のコミットよりも即座に優先
     されます。

pack.writeBitmaps (deprecated)
     これは、 ‘repack.writeBitmaps’ の非推奨の同義語です。

pack.writeBitmapHashCache
     trueの場合、gitはビットマップインデックスに「hash cache」(ハッシュ
     キャッシュ)セクションを含めます(記述されている場合)。 このキャッシ
     ュは、gitのデルタヒューリスティックを供給するために使用でき、ビット
     マップオブジェクトと非ビットマップオブジェクト間のデルタを改善する
     可能性があります(たとえば、古いビットマップパックと最後のgc以降にプ
     ッシュされたオブジェクト間のフェッチを提供する場合)。欠点は、ディス
     クスペースのオブジェクトごとに4バイトを消費することです。 デフォル
     トはtrueです。

pack.writeReverseIndex
     trueの場合、gitは、 git-fast-import(1) と バルクチェックインメカニ
     ズム(bulk checkin mechanism)を除く、すべての場所に書き込む新しいパ
     ックファイルごとに対応する .rev ファイル(参照:
     Documentation/technical/pack-format.txt
     (../technical/pack-format.html))を書き込みます。デフォルトはfalseで
     す。

pager.<cmd>
     値がブール値の場合、ttyへの書き込み時に特定のGitサブコマンドの出力
     のページ付けをオンまたはオフにします。それ以外の場合は、
     ‘pager.<cmd>’ の値で指定されたページャーを使用してサブコマンドのペ
     ージ付けをオンにします。コマンドラインで ‘--paginate’ または
     ‘--no-pager’ が指定されている場合、このオプションよりも優先されます
     。すべてのコマンドのページ付けを無効にするには、 ‘core.pager’ また
     は ‘GIT_PAGER’ を ‘cat’ に設定します。

pretty.<name>
     git-log(1)で 指定されている、 ‘--pretty=’ 書式文字列のエイリアス。
     ここで定義されたエイリアスは、組み込みのpretty書式と同じように使用
     できます。 たとえば、 ‘git config pretty.changelog "format:* %H
     %s"’ を実行すると、 ‘git log --pretty=changelog’ の呼び出しは ‘git
     log "--pretty=format:* %H %s"’ を実行するのと同じになります。注意:
     組み込みフォーマットと同じ名前のエイリアスは黙って無視されることに
     注意してください。

protocol.allow
     設定されている場合は、ポリシーを明示的に持たないすべてのプロトコル
     にユーザー定義のデフォルトポリシーを指定します
     (‘protocol.<name>.allow’)。デフォルトでは、設定されていない場合、既
     知の安全なプロトコル(http、https、git、ssh、file)のデフォルトポリシ
     ーは「always」、既知の危険なプロトコル(ext)のデフォルトポリシーは「
     never」、その他の全てのプロトコルのデフォルトのポリシーは「user」で
     す。サポートされているポリシーは以下です:

        • ‘always’ - プロトコルは常に使用できます。

        • ‘never’ - プロトコルを使用することはできません。

        • ‘user’ - プロトコルは、 ‘GIT_PROTOCOL_FROM_USER’ が設定されて
          いないか、値が ‘1’ の場合にのみ使用できます。このポリシーは、
          プロトコルをユーザーが直接使用できるようにしたいが、ユーザー入
          力なしの clone/fetch/push を実行するコマンドでは使用したくない
          場合(たとえば再帰的なsubmoduleの初期化の場合)、設定しなければ
          なりません。

protocol.<name>.allow
     clone/fetch/push コマンドでプロトコル ‘<name>’ が使用するポリシーを
     設定します。 使用可能なポリシーについては、上記の「protocol.allow」
     を参照してください。

     現在gitで使用されているプロトコル名はイカのとおりです:

        • ‘file’: 任意のローカルファイルベースのパス( ‘file://’ URL また
          は ローカルパス を含む)

        • ‘git’: 直接TCP接続(または構成されている場合はプロキシ)を介した
          匿名のgitプロトコル

        • ‘ssh’: sshプロトコルの上で動くgitプロトコル( ‘host:path’ 書式
          や ‘ssh://’ 等を含む)

        • ‘http’: httpプロトコルの上で動くgitプロトコル。「スマート
          http」と「ダムhttp」の両方です。両方を構成する場合は、個別に構
          成する必要があります。注意:これには ‘https’ は含まれないことに
          注意してください。

        • 外部ヘルパーはそれらのプロトコルによる名前が付けられます(たと
          えば、 ‘hg’ というプロトコルを指定したら ‘git-remote-hg’ ヘル
          パーを許可します)

protocol.version
     設定されている場合、クライアントは指定されたプロトコルバージョンを
     使用してサーバーとの通信を試みます。サーバーがサポートしていない場
     合、通信はバージョン0にフォールバックします。設定されていない場合、
     デフォルトは「2」です。 サポートされているバージョンは以下です:

        • ‘0’ - 独自のワイヤープロトコル

        • ‘1’ - サーバーからの初期応答にバージョン文字列が追加された独自
          のワイヤープロトコル。

        • ‘2’ - wire protocol version 2 (technical/protocol-v2.html)

pull.ff
     デフォルトでは、Gitは、現在のコミットの子孫であるコミットをマージす
     るときに、追加のマージコミットを作成しません。 代わりに、現在のブラ
     ンチの先端が早送り(fast-forward)されます。 ‘false’ に設定すると、こ
     の変数はGitにそのような場合に追加のマージコミットを作成するように指
     示します(コマンドラインから ‘--no-ff’ オプションを指定するのと同じ
     です)。 ‘only’ に設定すると、そのような早送り(fast-forward)マージの
     みが許可されます(コマンドラインから ‘--ff-only’ オプションを指定す
     るのと同じです)。 この設定は、プル時に ‘merge.ff’ をオーバーライド
     します。

pull.rebase
     trueの場合、 ‘git pull’ の実行時にデフォルトのリモートからデフォル
     トのブランチをマージするのではなく、フェッチされたブランチの上にブ
     ランチをリベースします。 ブランチごとにこれを設定するには、
     ‘branch.<name>.rebase’ を参照してください。

     ‘merges’ (または単に ‘m’ )の場合、 ‘--rebase-merges’ オプションを
     ‘git rebase’ に渡して、ローカルマージコミットがリベースに含まれるよ
     うにします(詳細については、 git-rebase(1) を参照してください)。

     ‘preserve’ (または単に _p_ 。 ‘merges’ を優先してこれは非推奨)の場
     合は、 ‘--preserve-merges’ を ‘git rebase’ に渡して、ローカルでコミ
     ットされたマージコミットが ‘git pull’ を実行してもフラット化されな
     いようにします。

     値が ‘interactive’ (または単に ‘i’)の場合、リベースは対話モードで実
     行されます。

     *注意*: これはおそらく危険な操作です。 あなたが影響を理解していない
     限り、使用しないでください (詳細については、 git-rebase(1) を参照し
     てください)。

pull.octopus
     複数のブランチを一度にプルするときに使用するデフォルトのマージ戦略
     。

pull.twohead
     単一のブランチをプルするときに使用するデフォルトのマージ戦略。

push.default
     (コマンドライン、構成、またはその他の場所で、)refspecが指定されてい
     ない場合に ‘git push’ が実行するアクションを定義します。 特定の作業
     フローに適するさまざまな値があります。 たとえば、純粋に中央のワーク
     フロー(つまり、フェッチ元がプッシュ先と等しい)では、 ‘upstream’ が
     おそらく必要なものです。 可能な値は以下のとおりです:

        • ‘nothing’ - refspecが指定されていない限り、何もプッシュ(エラー
          出力)しないでください。 これは主に、常に明示的にすることで間違
          いを避けたい人を対象としています。

        • ‘current’ - 現在のブランチをプッシュして、受信側で同一の名前の
          ブランチを更新します。 中央作業フローと非中央作業フローの両方
          で機能します。

        • ‘upstream’ - 現在のブランチを、通常その変更が現在のブランチに
          統合されるブランチにプッシュバックします(これを ‘@{upstream}’
          と呼びます)。 このモードは、通常プルするのと同じリポジトリ(つ
          まり中央ワークフロー)にプッシュする場合にのみ意味があります。

        • ‘tracking’ - これは ‘upstream’ の非推奨の同義語です。

        • ‘simple’ - リモートで同一の名前の現在のブランチをプッシュしま
          す。

          あなたが一元化された作業フロー(あなたのプル元の同一のリポジト
          リにプッシュする、通常は ‘origin’ )で作業している場合は、あな
          たは同一の名前でアップストリームブランチを構成する必要がありま
          す。

          このモードはGit2.0以降のデフォルトであり、初心者に適した最も安
          全なオプションです。

        • ‘matching’ - 送信側受信側両方で同一の名前のすべてのブランチを
          プッシュします。 これにより、プッシュするリポジトリは、プッシ
          ュされるブランチのセットを記憶するようになります(たとえば、常
          に「maint」と「master」をプッシュし、他のブランチがない場合、
          プッシュするリポジトリには、これら2つのブランチがあり、ローカ
          ルの「maint」と「master」がそこにプッシュされます)。

          このモードを効果的に使用するには、 ‘git push’ を実行する前に、
          あなたがプッシュしたい「すべてのブランチ」がプッシュされる準備
          ができていることを確認する必要があります。このモードの要点は、
          すべてのブランチを一度にプッシュできるようにすることです。通常
          、1つのブランチのみで作業を終了して結果をプッシュする場合、他
          のブランチは未完了ですので、このモードは適していません。 また
          、このモードは、共有中央リポジトリにプッシュするのには適してい
          ません。他の人がそこに新しいブランチを追加したり、コントロール
          外の既存のブランチの先端を更新したりする可能性があるためです。

          これは以前はデフォルトでしたが、Git 2.0以降ではそうではありま
          せん(‘simple’ が新しいデフォルトです)。

push.followTags
     trueに設定されている場合、デフォルトで ‘--follow-tags’ オプションを
     有効にします。 ‘--no-follow-tags’ を指定することにより、プッシュ時
     にこの構成をオーバーライドできます。

push.gpgSign
     ブール値、または文字列 ‘if-asked’ に設定できます。 true値を指定する
     と、 ‘--signed’ linkgit:git-push [1]に渡されたかのように、すべての
     プッシュがGPG署名されます。 文字列 ‘if-asked’ を指定し、サーバーが
     サポートしている場合は、 ‘--signed=if-asked’ が ‘git push’ に渡され
     たかのように、プッシュで署名されます。 誤った値は、優先度の低い構成
     ファイルの値を上書きする可能性があります。 明示的なコマンドラインオ
     プションは、常にこの設定オプションを上書きします。

push.pushOption
     コマンドラインから ‘--push-option=<option>’ 引数が指定されていない
     場合、 ‘git push’ はこの変数の各<value> が ‘--push-option=<value>’
     として指定されているかのように動作します。

     これは複数値の変数であり、優先度の高い構成ファイル(リポジトリ内の
     ‘.git/config’ など)で空の値を使用して、優先度の低い構成ファイル
     (‘$HOME/.gitconfig’ など)から継承された値をクリアできます。

          Example:

          /etc/gitconfig
            push.pushoption = a
            push.pushoption = b

          ~/.gitconfig
            push.pushoption = c

          repo/.git/config
            push.pushoption =
            push.pushoption = b

          This will result in only b (a and c are cleared).

push.recurseSubmodules
     プッシュされるリビジョンで使用されるすべてのサブモジュールコミット
     がリモートト追跡ブランチで利用可能であることを確認します。 値が
     ‘check’ の場合、Gitは、プッシュされるリビジョンで変更されたすべての
     サブモジュールコミットが、サブモジュールの少なくとも1つのリモートで
     使用可能であることを確認します。 コミットが欠落している場合、プッシ
     ュは中止(abort)され、ゼロ以外のステータスで終了します。 値が
     ‘on-demand’ の場合、プッシュされるリビジョンで変更されたすべてのサ
     ブモジュールがプッシュされます。 on-demandで必要なすべてのリビジョ
     ンをプッシュできなかった場合も、中止(abort)され、ゼロ以外のステータ
     スで終了します。 値が ‘no’ の場合、プッシュ時にサブモジュールを無視
     するデフォルトの動作が保持されます。
     ‘--recurse-submodules=check|on-demand|no’ を指定することにより、プ
     ッシュ時にこの構成をオーバーライドできます。 設定されていない場合、
     ‘submodule.recurse’ が設定されていない限り、デフォルトで ‘no’ が使
     用されます(この場合、 ‘true’ 値は ‘on-demand’ を意味します)。

push.useForceIfIncludes
     「true」に設定すると、コマンドラインで git-push(1) のオプションとし
     て ‘--force-if-includes’ を指定するのと同じです。 プッシュ時に
     ‘--no-force-if-includes’ を追加すると、この構成設定が上書きされます
     。

push.negotiate
     「true」に設定されている場合は、クライアントとサーバーが共通のコミ
     ットを見つけようとするネゴシエーションの段階で送信されるパックファ
     イルのサイズを縮小してみます。 「false」の場合、Gitはサーバーの
     ref広告のみに依存して、共通のコミットを検索します。

rebase.backend
     リベースに使用するデフォルトのバックエンド。 可能な選択肢は、「
     apply」または「merge」です。 将来、mergeバックエンドがapplyバックエ
     ンドの残りのすべての機能を取得した場合、この設定は使用されなくなる
     可能性があります。

rebase.stat
     最後のリベース以降にアップストリームで変更されたもののdiffstatを表
     示するかどうか。デフォルトではFalseです。

rebase.autoSquash
     trueに設定されている場合、デフォルトで ‘--autosquash’ オプションを
     有効にします。

rebase.autoStash
     trueに設定すると、操作を開始する前に一時的なstashエントリを自動的に
     作成し、操作の終了後に適用します。これは、ダーティワークツリーでリ
     ベースを実行できることを意味します。ただし、注意して使用してくださ
     い。リベースが成功した後の最後のstashアプリケーションは、重要な競合
     を引き起こす可能性があります。このオプションは、 git-rebase(1) の
     ‘--no-autostash’ および ‘--autostash’ オプションでオーバーライドで
     きます。 デフォルトはfalseです。

rebase.missingCommitsCheck
     「warn」に設定すると、 ‘git rebase -i’ は、一部のコミットが削除され
     た場合(たとえば、行が削除された場合)に警告を出力しますが、リベース
     は続行されます。 「error」に設定すると、前記の警告が出力され、リベ
     ースが停止(stop)します。 ‘git rebase --edit-todo’ を使用して、エラ
     ーを修正できます。 「ignore」に設定すると、チェックは行われません。
     警告やエラーなしにコミットをドロップするには、todoリストの ‘drop’ コ
     マンドを使用します。 デフォルトは「ignore」です。

rebase.instructionFormat
     git-log(1) で指定されている、対話的リベース中にToDoリストに使用され
     る書式文字列。書式では、自動的に長いコミットハッシュが書式の前に付
     加されます。

rebase.abbreviateCommands
     trueに設定すると、 ‘git rebase’ はtodoリストで省略コマンド名を使用
     し、以下のようになります:

                  p deadbee The oneline of the commit
                  p fa1afe1 The oneline of the next commit
                  ...

     上記は以下の省略形です:

                  pick deadbee The oneline of the commit
                  pick fa1afe1 The oneline of the next commit
                  ...

     デフォルトではfalseです。

rebase.rescheduleFailedExec
     失敗した ‘exec’ コマンドを自動的に再スケジュールします。 これは、対
     話モード (または ‘--exec’ オプションが指定されている場合)でのみ意味
     があります。これは ‘--reschedule-failed-exec’ オプションを指定する
     のと同じです。

rebase.forkPoint
     falseに設定されている場合、デフォルトで ‘--no-fork-point’ オプショ
     ンを設定します。

receive.advertiseAtomic
     デフォルトでは、git-receive-packはアトミックプッシュ機能(atomic
     push capability)をクライアントに公表(advertise)します。この機能を公
     表したくない場合は、この変数をfalseに設定してください。

receive.advertisePushOptions
     trueに設定すると、git-receive-packはプッシュオプション機能(push
     options capability)をクライアントに公表(advertise)します。デフォル
     トではFalse。

receive.autogc
     デフォルトでは、git-pushからデータを受信し、参照を更新した後、
     git-receive-packは ‘git-gc --auto’ を実行します。 この変数をfalseに
     設定することで停止できます。

receive.certNonceSeed
     この変数を文字列に設定すると、 ‘git receive-pack’ は ‘git push
     --signed’ を受け入れ、その文字列を秘密鍵として使用してHMACによって
     保護された「nonce」を使用して検証します。

receive.certNonceSlop
     ‘git push --signed’ が、同じリポジトリにサービスを提供する
     receive-packによって発行された「nonce」を含むプッシュ証明書をこの数
     秒以内に送信した場合、証明書で見つかった「nonce」をフックのために
     ‘GIT_PUSH_CERT_NONCE’ にエクスポートします(receive-packが送信側に含
     めるように要求したものの代わりに)。 これにより、 ‘pre-receive’ と
     ‘post-receive’ でのチェックの記述が少し簡単になります。証明書を受け
     入れるかどうかを決定するために、nonce が何秒後に古くなるかを記録す
     る環境変数 ‘GIT_PUSH_CERT_NONCE_SLOP’ をチェックする代わりに、
     ‘GIT_PUSH_CERT_NONCE_STATUS’ が ‘OK’ であることだけをチェックするこ
     とができます。

receive.fsckObjects
     trueに設定されている場合、git-receive-packは受信したすべてのオブジ
     ェクトをチェックします。 チェックされる内容については、
     ‘transfer.fsckObjects’ を参照してください。デフォルトはfalseです。
     設定されていない場合は、代わりに ‘transfer.fsckObjects’ の値が使用
     されます。

receive.fsck.<msg-id>
     ‘fsck.<msg-id>’ のように機能しますが、 linkgit: git-fsck[1] の代わ
     りに git-receive-pack(1) によって使用されます。詳細については、
     ‘fsck.<msg-id>’ の文書を参照してください。

receive.fsck.skipList
     ‘fsck.skipList’ のように機能しますが、 git-fsck(1) の代わりに
     git-receive-pack(1) によって使用されます。詳細については、
     ‘fsck.skipList’ の文書を参照してください。

receive.keepAlive
     クライアントからパックを受信した後、パックの処理中に ‘receive-pack’
     が出力を生成せず(‘--quiet’ が指定されている場合)、一部のネットワー
     クがTCP接続を切断する可能性があります。このオプションを設定すると、
     ‘receive-pack’ はこのフェーズで ‘receive.keepAlive’ 秒の間データを
     送信しない場合、short keepalive packetを送信します。デフォルトは5秒
     です。キープアライブを完全に無効にするには、0に設定します。

receive.unpackLimit
     プッシュで受信されるオブジェクトの数がこの制限を下回る場合、オブジ
     ェクトは緩いオブジェクト(loose object)ファイルに解凍されます。ただ
     し、受信したオブジェクトの数がこの制限以上の場合、受信したパックは
     、欠落しているデルタベースを追加した後、パックとして保存されます。
     プッシュからパックを保存すると、特に低速のファイルシステムで、プッ
     シュ操作をより速く完了することができます。 設定されていない場合は、
     代わりに ‘transfer.unpackLimit’ の値が使用されます。

receive.maxInputSize
     着信パックストリームのサイズがこの制限よりも大きい場合、パックファ
     イルを受け入れる代わりに git-receive-pack がエラーになります。0に設
     定または設定されていない場合、サイズは無制限です。

receive.denyDeletes
     trueに設定すると、git-receive-packはrefを削除するrefの更新を拒否し
     ます。これを使用して、プッシュによるそのような参照の削除を防ぎます
     。

receive.denyDeleteCurrent
     trueに設定すると、git-receive-packは、非ベアリポジトリの現在チェッ
     クアウトされているブランチを削除するrefの更新を拒否します。

receive.denyCurrentBranch
     trueまたは "refuse"(拒否)に設定すると、 git-receive-pack は、非ベア
     リポジトリの現在チェックアウトされているブランチへのrefの更新を拒否
     します。このようなプッシュは、HEADがインデックスおよび作業ツリーと
     同期しなくなるため、潜在的に危険です。"warn"(警告)に設定されている
     場合は、stderrへのそのようなプッシュの警告を出力しますが、プッシュ
     を続行できるようにします。 falseまたは"ignore"(無視)に設定されてい
     る場合は、メッセージなしでそのようなプッシュを許可します。 デフォル
     トは"refuse"です。

     別のオプションは"updateInstead"で、現在のブランチにプッシュすると作
     業ツリーが更新されます。このオプションは、インタラクティブsshを介し
     て一方の側に簡単にアクセスできない場合に作業ディレクトリを同期する
     ことを目的としています(たとえば、ライブWebサイト。つまり作業ディレ
     クトリがクリーンである必要があります)。 このモードは、VM内で開発し
     て、さまざまなオペレーティングシステムでコードをテストおよび修正す
     る場合にも役立ちます。

     デフォルトでは、作業ツリーまたはインデックスにHEADとの違いがある場
     合、"updateInstead"はプッシュを拒否しますが、 ‘push-to-checkout’ フ
     ックを使用してこれをカスタマイズできます。 githooks(5) を参照してく
     ださい。

receive.denyNonFastForwards
     trueに設定すると、git-receive-packは、fast-forwardではないrefの更新
     を拒否します。これを使用して、プッシュが強制されている場合でも、プ
     ッシュによるそのような更新を防ぎます。この構成変数は、共有リポジト
     リを初期化するときに設定されます。

receive.hideRefs
     この変数は ‘transfer.hideRefs’ と同じですが、 ‘receive-pack’ にのみ
     適用されます(したがって、プッシュには影響しますが、フェッチには影響
     しません)。 ‘git push’ によって非表示の参照を更新または削除しようと
     する試みは拒否されます。

receive.procReceiveRefs
     これは、 ‘receive-pack’ のコマンドに一致する参照プレフィックスを定
     義する複数値の変数(multi-valued variable)です。プレフィックスに一致
     するコマンドは、内部の ‘execute_commands’ 関数ではなく、外部フック
     「proc-receive」によって実行されます。この変数が定義されていない場
     合、「proc-receive」フックは使用されず、すべてのコマンドは内部の
     ‘execute_commands’ 関数によって実行されます。

     たとえば、この変数が "refs/for" に設定されている場合、
     "refs/for/master" などの参照にプッシュしても "refs/for/master" とい
     う名前の参照は作成・更新されませんが、 "proc-receive" フックを実行
     すれば直接プルリクエストを作成・更新できるはずです。

     オプションの修飾子を値の先頭に指定して、特定のアクション(作成(a)、
     変更(m)、削除(d))のコマンドをフィルター処理できます。 ‘!’ を修飾子
     に含めて、参照プレフィックスエントリを無効にすることができます。 例
     えば以下のようにできます:

          git config --system --add receive.procReceiveRefs ad:refs/heads
          git config --system --add receive.procReceiveRefs !:refs/heads

receive.updateServerInfo
     trueに設定すると、git-pushからデータを受信し、参照を更新した後、
     git-receive-packはgit-update-server-infoを実行します。

receive.shallowUpdate
     trueに設定すると、新しい参照に新しいshallow rootsが必要になったとき
     に .git/shallow を更新できます。それ以外の場合、それらの参照は拒否
     されます。

remote.pushDefault
     デフォルトでプッシュするリモート。 すべてのブランチの
     ‘branch.<name>.remote’ をオーバーライドし、特定のブランチの
     ‘branch.<name>.pushRemote’ によってオーバーライドされます。

remote.<name>.url
     リモートリポジトリのURL。 git-fetch(1) または git-push(1) を参照し
     てください。

remote.<name>.pushurl
     リモートリポジトリのプッシュURL。 git-push(1) を参照してください。

remote.<name>.proxy
     curl(httpとhttpsとftp)を必要とするリモートの場合、そのリモートに使
     用するプロキシへのURL。 そのリモートのプロキシを無効にするには、空
     の文字列に設定します。

remote.<name>.proxyAuthMethod
     curl(httpとhttpsとftp)を必要とするリモートの場合、使用中のプロキシ
     (おそらく ‘remote.<name>.proxy’ で設定)に対して認証するために使用す
     るメソッド。 ‘http.proxyAuthMethod’ を参照してください。

remote.<name>.fetch
     git-fetch(1) のデフォルトの「refspec」セット。 git-fetch(1) を参照
     してください。

remote.<name>.push
     git-push(1) のデフォルトの「refspec」セット。 git-push(1) を参照し
     てください。

remote.<name>.mirror
     trueの場合、このリモートにプッシュすると、コマンドラインで
     ‘--mirror’ オプションが指定されたかのように自動的に振る舞います。

remote.<name>.skipDefaultUpdate
     trueの場合、 git-fetch(1) または git-remote(1) の ‘update’ サブコマ
     ンドを使用して更新すると、このリモートはデフォルトでスキップされま
     す。

remote.<name>.skipFetchAll
     trueの場合、 git-fetch(1) または git-remote(1) の ‘update’ サブコマ
     ンドを使用して更新すると、このリモートはデフォルトでスキップされま
     す。

remote.<name>.receivepack
     プッシュ時にリモート側で実行するデフォルトのプログラム。
     git-push(1) のオプション ‘--receive-pack’ を参照してください。

remote.<name>.uploadpack
     フェッチ時にリモート側で実行するデフォルトのプログラム。
     git-fetch-pack(1) のオプション ‘--upload-pack’ を参照してください。

remote.<name>.tagOpt
     この値を ‘--no-tags’ に設定すると、リモート<name>からフェッチすると
     きの自動タグ追跡が無効になります。 ‘--tags’ に設定すると、リモート
     ブランチヘッドから到達できない場合でも、リモート<name>からすべての
     タグがフェッチされます。 これらのフラグを直接 git-fetch(1) に渡すと
     、この設定を上書きできます。 git-fetch(1) のオプション ‘--tags’ お
     よび ‘--no-tags’ を参照してください。

remote.<name>.vcs
     これを値 <vcs> と設定すると、Gitは git-remote-<vcs> ヘルパーを使用
     してリモートと対話します。

remote.<name>.prune
     trueに設定した時は、デフォルトでこのリモートからフェッチすると、(コ
     マンドラインで ‘--prune’ オプションが指定されているかのように、)リ
     モートに存在しなくなったリモート追跡参照も削除されます。
     ‘fetch.prune’ 設定が存在する場合、それをオーバーライドします。

remote.<name>.pruneTags
     trueに設定した時、デフォルトでこのリモートからフェッチすると、一般
     に刈り込み(pruning)が ‘remote.<name>.prune’ または ‘fetch.prune’ ま
     たは ‘--prune’ を介して、アクティブ化されている場合、リモートに存在
     しなくなったローカルタグも削除されます。 ‘fetch.pruneTags’ 設定存在
     する場合それをオーバーライドします。

     ‘remote.<name>.prune’ および git-fetch(1) の「PRUNING」セクションも
     参照してください。

remote.<name>.promisor
     trueに設定すると、このリモートはプロミザー(promisor)オブジェクトを
     フェッチするために使用されます。

remote.<name>.partialclonefilter
     このプロミザー(promisor)リモートからフェッチするときに適用されるフ
     ィルター。

remotes.<group>
     ‘git remote update <group>’ によってフェッチされるremoteのリスト。
     git-remote(1) を参照してください。

repack.useDeltaBaseOffset
     デフォルトでは、 git-repack(1) はデルタベースオフセットを使用するパ
     ックを作成します。 あなたのリポジトリを、バージョン1.4.4より古い
     Gitと直接、またはhttpなどのバカ(dumb)プロトコルを介して共有する必要
     がある場合は、このオプションを ‘false’ に設定して再パックする必要が
     あります。 ネイティブプロトコルを介した古いバージョンのGitからのア
     クセスは、このオプションの影響を受けません。

repack.packKeptObjects
     trueに設定すると、 ‘git repack’ が ‘--pack-kept-objects’ が渡された
     かのように動作します。 詳細については、 git-repack(1) を参照してく
     ださい。 デフォルトは通常 ‘false’ ですが、ビットマップインデックス
     が(‘--write-bitmap-index’ または ‘repack.writeBitmaps’ のいずれかを
     介して)書き込まれている場合は ‘true’ です。

repack.useDeltaIslands
     trueに設定すると、 ‘git repack’ が ‘--delta-islands’ が渡されたかの
     ように動作します。 デフォルトは ‘false’ です。

repack.writeBitmaps
     trueの場合、gitはすべてのオブジェクトをディスクにパックするときにビ
     ットマップインデックスを書き込みます(たとえば、 ‘git repack -a’ が
     実行される場合)。 このインデックスは、クローンとフェッチ用に作成さ
     れた後続のパックの「オブジェクトのカウント」フェーズを高速化できま
     すが、ディスクスペースと最初の再パックに余分な時間がかかります。 複
     数のパックファイルが作成されている場合、これは効果がありません。 ベ
     ア(bare)リポジトリではデフォルトでtrueになり、それ以外の場合は
     falseになります。

rerere.autoUpdate
     trueに設定すると、 ‘git-rerere’ は、以前に記録された解決策を使用し
     て競合をクリーンに解決した後、結果のコンテンツでインデックスを更新
     します。 デフォルトはfalseです。

rerere.enabled
     解決された競合の記録をアクティブにして、同じ競合ハンクが再度発生し
     た場合に自動的に解決できるようにします。 デフォルトでは、
     ‘$GIT_DIR’ の下に ‘rr-cache’ ディレクトリがある(例えば ‘rerere’ が
     以前にリポジトリで使用されていた)場合、 git-rerere(1) が有効になり
     ます。

reset.quiet
     trueに設定すると、 ‘git reset’ はデフォルトで ‘--quiet’ オプション
     になります。

sendemail.identity
     構成ID。 指定すると、 ‘sendemail.<identity>’ サブセクションの値が
     ‘sendemail’ セクションの値よりも優先されます。 デフォルトのIDは、
     ‘sendemail.identity‘の値です。

sendemail.smtpEncryption
     説明については、 git-send-email(1) を参照してください。 注意: この
     設定は _identity_ メカニズムの対象ではないことに注意してください。

sendemail.smtpsslcertpath
     ca-certificatesへのパス(ディレクトリまたは単一ファイルのどちらか)。
     証明書の検証を無効にするには、空の文字列に設定します。

sendemail.<identity>.*
     以下の ‘sendemail.*’ パラメータのID固有のバージョン。コマンドライン
     または ‘sendemail.identity’ のいずれかを使用して、このIDが選択され
     た場合のパラメータよりも優先されます。

sendemail.aliasesFile
sendemail.aliasFileType
sendemail.annotate
sendemail.bcc
sendemail.cc
sendemail.ccCmd
sendemail.chainReplyTo
sendemail.confirm
sendemail.envelopeSender
sendemail.from
sendemail.multiEdit
sendemail.signedoffbycc
sendemail.smtpPass
sendemail.suppresscc
sendemail.suppressFrom
sendemail.to
sendemail.tocmd
sendemail.smtpDomain
sendemail.smtpServer
sendemail.smtpServerPort
sendemail.smtpServerOption
sendemail.smtpUser
sendemail.thread
sendemail.transferEncoding
sendemail.validate
sendemail.xmailer
     説明については、 git-send-email(1) を参照してください。

sendemail.signedoffcc (非推奨)
     ‘sendemail.signedoffbycc’ の非推奨のエイリアス。

sendemail.smtpBatchSize
     接続ごとに送信されるメッセージの数。その後、再ログインが発生します
     。 値が0または未定義の場合、すべてのメッセージを1つの接続で送信しま
     す。 git-send-email(1) の ‘--batch-size’ オプションも参照してくださ
     い。

sendemail.smtpReloginDelay
     SMTPサーバーに再接続する前に指定の秒数待機します。
     git-send-email(1)の ‘--relogin-delay’ オプションも参照してください
     。

sendemail.forbidSendmailVariables
     一般的な設定ミスを回避するために、 git-send-email(1) は、
     ‘sendmail’ の設定オプションが存在する場合、警告とともに中止します。
     チェックをバイパスするには、この変数を設定します。

sequence.editor
     リベース命令ファイル(rebase instruction file)を編集するために ‘git
     rebase -i’ によって使用されるテキストエディタ。この値は、使用時にシ
     ェルによって解釈されることを意図しています。 これは、
     ‘GIT_SEQUENCE_EDITOR’ 環境変数によってオーバーライドできます。構成
     されていない場合は、代わりにデフォルトのコミットメッセージエディタ
     が使用されます。

showBranch.default
     git-show-branch(1) のデフォルトのブランチセット。
     git-show-branch(1) を参照してください。

splitIndex.maxPercentChange
     分割インデックス機能を使用する場合、これは、新しい共有インデックス
     が書き込まれる前の、分割インデックスと共有インデックスの両方のエン
     トリの総数と比較した、分割インデックスに含めることができるエントリ
     の割合を指定します。 値は0〜100の間である必要があります。 値が0の場
     合、新しい共有インデックスが常に書き込まれ、100の場合、新しい共有イ
     ンデックスが書き込まれることはありません。 デフォルトの値は20である
     ため、分割インデックスのエントリ数がエントリの総数の20%を超える場合
     は、新しい共有インデックスが書き込まれます。 git-update-index(1) を
     参照してください。

splitIndex.sharedIndexExpire
     分割インデックス機能を使用すると、この変数が指定する時間以降に変更
     されなかった共有インデックスファイルは、新しい共有インデックスファ
     イルが作成されるときに削除されます。 値 ‘now’ はすべてのエントリを
     すぐに期限切れにし、 ‘never’ は期限切れを完全に抑制します。 デフォ
     ルト値は ‘2.weeks.ago’ です。 共有インデックスファイルは、それに基
     づいて新しい分割インデックスファイルが作成されるか、そこから読み取
     られるたびに、(有効期限について)変更されたと見なされることに注意し
     てください。 git-update-index(1) を参照してください。

ssh.variant
     デフォルトでは、Gitは設定されたSSHコマンドのベース名(環境変数
     ‘GIT_SSH’ または環境変数 ‘GIT_SSH_COMMAND’ または構成設定
     ‘core.sshCommand’ を使用して設定)に基づいて使用するコマンドライン引
     数を決定します。ベース名が認識されない場合、Gitは最初に ‘-G’ (print
     configuration)オプションを使用して構成済みのSSHコマンドを呼び出し、
     その後、(成功した場合、)OpenSSHオプションを使用するか、(失敗した場
     合、)hostおよびremoteコマンド以外のオプションを使用しないことで、
     OpenSSHオプションのサポートを検出しようとします。

     構成変数 ‘ssh.variant’ は、この検出をオーバーライドするように設定で
     きます。有効な値は、 ‘ssh’ (OpenSSHオプションを使用する場合)、
     ‘plink’ 、 ‘putty’ 、 ‘tortoiseplink’ 、 ‘simple’ (hostおよび
     remoteコマンド以外のオプションを持っていません)、です。 デフォルト
     の自動検出は、値 ‘auto’ を使用して明示的に要求できます。また、これ
     以外の値は ‘ssh’ として扱われます。この設定は、環境変数
     ‘GIT_SSH_VARIANT’ を介してオーバーライドすることもできます。

     各派生で使用されている現在のコマンドラインパラメータは以下のとおり
     です:

        • ‘ssh’ - [-p port] [-4] [-6] [-o option] [username@]host
          command

        • ‘simple’ - [username@]host command

        • ‘plink’ or ‘putty’ - [-P port] [-4] [-6] [username@]host
          command

        • ‘tortoiseplink’ - [-P port] [-4] [-6] -batch [username@]host
          command

     ‘simple’ 派生を除き、コマンドラインパラメータはgitが新しい機能を取
     得するにつれて変更される可能性があります。

status.relativePaths
     デフォルトでは、 git-status(1) は現在のディレクトリからの相対パスを
     表示します。 この変数を ‘false’ に設定すると、リポジトリルートを基
     準にしたパスが表示されます(これはv1.5.4より前のGitのデフォルトでし
     た)。

status.short
     git-status(1) でデフォルトで ‘--short’ を有効にするには、trueに設定
     します。 オプション‘ –no-short‘ は、この変数よりも優先されます。

status.branch
     git-status(1) でデフォルトで ‘--branch’ を有効にするには、trueに設
     定します。 オプション ‘--no-branch’ は、この変数よりも優先されます
     。

status.aheadBehind
     非磁器コマンドステータス形式(non-porcelain status formats)の
     git-status(1) で、デフォルトで ‘--ahead-behind’ を有効にするには
     trueに設定し、 ‘--no-ahead-behind’ を有効にするにはfalseに設定しま
     す。 デフォルトはtrueです。

status.displayCommentPrefix
     trueに設定すると、 git-status(1) は各出力行の前にコメントプレフィッ
     クスを挿入します(‘core.commentChar’ で始まります。つまりデフォルト
     では ‘#’ です)。 これは、Git 1.8.4以前の git-status(1) の動作でした
     。 デフォルトはfalseです。

status.renameLimit
     git-status(1) および git-commit(1) で名前変更の検出を実行するときに
     考慮するファイルの数。 デフォルトは diff.renameLimit の値です。

status.renames
     Gitが git-status(1) と git-commit(1) で名前の変更を検出するかどうか
     とその方法。 ‘false’ に設定すると、名前変更の検出が無効になります。
     ‘true’ に設定すると、基本的な名前変更の検出が有効になります。
     ‘copies’ または ‘copy’ に設定されている場合、Gitはコピーも検出しま
     す。 デフォルトは diff.renames の値です。

status.showStash
     trueに設定すると、 git-status(1) は現在stashされているエントリの数
     を表示します。 デフォルトはfalseです。

status.showUntrackedFiles
     デフォルトでは、 git-status(1) と git-commit(1) は、現在Gitによって
     追跡されていないファイルを表示します。 追跡されていないファイルのみ
     を含むディレクトリは、ディレクトリ名のみで表示されます。 追跡されて
     いないファイルを表示するということは、Gitがリポジトリ全体のすべての
     ファイルを lstat() する必要があることを意味します。これは、一部のシ
     ステムでは低速になる可能性があります。 したがって、この変数は、コマ
     ンドが追跡されていないファイルを表示する方法を制御します。 可能な値
     は以下のとおりです:

        • ‘no’ - 追跡していないファイルを表示しない。

        • ‘normal’ - 追跡していないファイルとディレクトリを表示

        • ‘all’ - 追跡されていないディレクトリ内の個々のファイルも表示。

     この変数が指定されていない場合、デフォルトで ‘normal’ になります。
     この変数は、 git-status(1) および git-commit(1) の
     ‘-u’|‘--untracked-files’ オプションでオーバーライドできます。

status.submoduleSummary
     デフォルトはfalseです。 これがゼロ以外の数値、またはtrue(-1または無
     制限と同じ)に設定されている場合、サブモジュールの要約が有効になり、
     変更されたサブモジュールのコミットの要約が表示されます
     (git-submodule(1) の ‘--summary-limit’ オプションを参照してください
     )。 ‘diff.ignoreSubmodules’ が ‘all’ に設定されている場合、または
     ‘submodule.<name>.ignore=all’ であるサブモジュールに対してのみ、要
     約出力コマンドが抑制されることに注意してください。 そのルールの唯一
     の例外は、statusとcommitが、ステージされたサブモジュールの変更を表
     示することです。 無視されたサブモジュールの概要も表示するには、
     ‘--ignore-submodules=dirty’ コマンドラインオプションまたは ‘git
     submodule summary’ コマンドを使用できます。これは同様の出力を表示し
     ますが、これらの設定を尊重しません。

stash.useBuiltin
     未使用の構成変数。 Gitバージョン2.22から2.26で、stashのレガシーシェ
     ルスクリプト実装を有効にするための緊急避難口(escape hatch)として使
     用されていました。 現在はC言語での組み込みの書き換えが常に使用され
     ています。 これを設定すると警告が表示され、これを設定しても何も起こ
     らないことをユーザーに警告します。

stash.showIncludeUntracked
     これがtrueに設定されている場合、 ‘git stash show’ コマンドはstashエ
     ントリの追跡されていないファイルを表示します。 デフォルトはfalseで
     す。 git-stash(1) の showコマンドの説明を参照してください。

stash.showPatch
     これがtrueに設定されている場合、オプションのない ‘git stash show’ コ
     マンドは、パッチ形式でstashエントリを表示します。 デフォルトは
     falseです。 git-stash(1)の showコマンドの説明を参照してください。

stash.showStat
     これがtrueに設定されている場合、オプションのない ‘git stash show’ コ
     マンドは、stashエントリのdiffstatを表示します。 デフォルトはtrueで
     す。 git-stash(1) の showコマンドの説明を参照してください。

submodule.<name>.url
     サブモジュールのURL。 この変数は、 ‘git submodule init’ を介して
     ‘.gitmodules’ ファイルから git config にコピーされます。 ユーザーは
     、 ‘git submodule update’ を介してサブモジュールを取得する前に、構
     成されたURLを変更できます。 ‘submodule.<name>.active’ も
     ‘submodule.active’ も設定されていない場合、この変数の存在は、サブモ
     ジュールがgitコマンドに関係するかどうかを示すためのフォールバックと
     して使用されます。 詳細については、 git-submodule(1)および
     gitmodules(5) を参照してください。

submodule.<name>.update
     影響を受ける唯一のコマンドである ‘git submodule update’ によってサ
     ブモジュールが更新される方法。 ‘git checkout --recurse-submodules’
     などの他のコマンドは影響を受けません。 ‘git submodule’ がサブモジュ
     ールと対話する唯一のコマンドであった場合、これは歴史的な理由で存在
     します。 ‘submodule.active`や `pull.rebase’ などの設定はより具体的
     です。 これは、gitmodules(5) ファイルから ‘git submodule init’ によ
     って入力されます。 git-submodule(1) のupdateコマンドの説明を参照し
     てください。

submodule.<name>.branch
     ‘git submodule update --remote’ によって使用されるサブモジュールの
     リモートブランチ名。 このオプションを設定すると、 ‘.gitmodules’ フ
     ァイルにある値が上書きされます。 詳細については、 git-submodule(1)
     および gitmodules(5) を参照してください。

submodule.<name>.fetchRecurseSubmodules
     このオプションは、このサブモジュールの再帰的フェッチを制御するため
     に使用できます。 ‘--[no-]recurse-submodules’ コマンドラインオプショ
     ンを使用して ‘git fetch’ と ‘git pull’ をオーバーライドすることでオ
     ーバーライドできます。 この設定は、 gitmodules(5) ファイルの設定を
     上書きします。

submodule.<name>.ignore
     どのような状況で ‘git status’ とdiffファミリーがサブモジュールを変
     更済みとして表示するかを定義します。 ‘all’ に設定すると、変更された
     とは見なされません(ただし、ステータスの出力に表示され、ステージング
     されるとコミットされます)。 ‘dirty’ は、サブモジュールの作業ツリー
     に対するすべての変更を無視し、差異のみを取ります。 サブモジュールの
     HEADと、スーパープロジェクトに記録されたコミットの間を考慮に入れま
     す。 ‘untracked’ はさらに、作業ツリー内の変更された追跡ファイルを持
     つサブモジュールを表示させます。 ‘none’ (設定されていない場合のデフ
     ォルト)を使用すると、作業ツリーに追跡されていないファイルが変更され
     たサブモジュールも表示されます。 この設定は、このサブモジュールの
     ‘.gitmodules`で行われた設定を上書きします。両方の設定は、
     `--ignore-submodules’ オプションを使用してコマンドラインで上書きで
     きます。 ‘git submodule’ コマンドは、この設定の影響を受けません。

submodule.<name>.active
     サブモジュールがgitコマンドに関係するかどうかを示すブール値。 この
     構成オプションは、 ‘submodule.active’ 構成オプションよりも優先され
     ます。 詳細については、 gitsubmodules(7) を参照してください。

submodule.active
     サブモジュールが git コマンドの対象かどうかを判断するためにサブモジ
     ュールのパスと照合するために使用される pathspec を含む繰り返しフィ
     ールド。詳細は gitsubmodules(7) を参照してください。

submodule.recurse
     コマンドがデフォルトで ‘--recurse-submodules’ オプションを有効にす
     るかどうかを示すブール値。 ‘clone’ と‘ls-files‘ を除く、このオプシ
     ョンをサポートするすべてのコマンド(‘checkout’ 、 ‘fetch’ 、 ‘grep’
     、 ‘pull’ 、 ‘push’ 、 ‘read-tree’ 、 ‘reset’ 、 ‘restore’ 、
     ‘switch’)に適用されます。 デフォルトはfalseです。 trueに設定すると
     、 ‘--no-recurse-submodules’ オプションを使用して非アクティブ化でき
     ます。 このオプションがない一部のGitコマンドは、
     ‘submodule.recurse’ の影響を受ける上記のコマンドの一部を呼び出す可
     能性があることに注意してください。 たとえば、 ‘git remote update’ は
     ‘git fetch’ を呼び出しますが、 ‘--no-recurse-submodules’ オプション
     はありません。 これらのコマンドの回避策は、 ‘git -c
     submodule.recurse=0’ を使用して構成値を一時的に変更することです。

submodule.fetchJobs
     同時に フェッチ/クローン されるサブモジュールの数を指定します。 正
     の整数を使用すると、その数までのサブモジュールを並列にフェッチでき
     ます。 値0は、適切なデフォルトを提供します。 設定されていない場合、
     デフォルトで1になります。

submodule.alternateLocation
     サブモジュールがcloneされるときに、サブモジュールがalternateを取得
     する方法を指定します。 可能な値は ‘no’ 、‘superproject’ です。 デフ
     ォルトでは、参照を追加しない ‘no’ が想定されています。 値が
     ‘superproject’ に設定されている場合、cloneされるサブモジュールは、
     スーパープロジェクトのalternates locationを基準にしてalternates
     locationを計算します。

submodule.alternateErrorStrategy
     ‘submodule.alternateLocation’ を介して計算されたサブモジュールの
     alternateでエラーを処理する方法を指定します。 可能な値は ‘ignore’ 、
     ‘info’ 、 ‘die’ です。デフォルトは ‘die’ です。 ‘ignore’ または
     ‘info’ に設定されていて、計算されたalternateにエラーがある場合、
     alternateが指定されていないかのようにクローンが進行することに注意し
     てください。

tag.forceSignAnnotated
     作成された注釈付きタグをGPG署名するかどうかを指定するブール値。 コ
     マンドラインで ‘--annotate’ が指定されている場合、このオプションよ
     りも優先されます。

tag.sort
     この変数は、 git-tag(1) によって表示されるときのタグの並べ替え順序
     を制御します。 ‘--sort=<value>’ オプションが指定されていない場合、
     この変数の値がデフォルトとして使用されます。

tag.gpgSign
     すべてのタグをGPG署名するかどうかを指定するブール値。 自動スクリプ
     トで実行しているときにこのオプションを使用すると、多数のタグが署名
     される可能性があります。 したがって、あなたは、エージェントを使用し
     て、gpgパスフレーズを毎回入力しないようにするのが便利です。 このオ
     プションは、 ‘-u<keyid>’ または ‘--local-user=<keyid>’ オプションに
     よって有効にされるタグ署名の動作には影響しないことに注意してくださ
     い。

tar.umask
     この変数は、tarアーカイブエントリの許可ビットを制限するために使用で
     きます。デフォルトは0002で、ワールド書き込みビット(world write
     bit)をオフにします。 特別な値 "user" は、アーカイブユーザーの
     umaskが代わりに使用されることを示します。 umask(2) および
     git-archive(1) を参照してください。

   trace2構成設定は、システムおよびグローバル構成ファイルからのみ読み取
られます。 リポジトリのローカルおよびワークツリー構成ファイルと ‘-c’ コ
マンドライン引数は尊重されません。

trace2.normalTarget
     この変数は、通常のターゲット(normal target)宛先を制御します。
     ‘GIT_TRACE2’ 環境変数によってオーバーライドされる可能性があります。

trace2.perfTarget
     この変数は、パフォーマンスターゲットの宛先を制御します。
     ‘GIT_TRACE2_PERF’ 環境変数によってオーバーライドされる可能性があり
     ます。

trace2.eventTarget
     この変数は、イベントターゲットの宛先を制御します。
     ‘GIT_TRACE2_EVENT’ 環境変数によってオーバーライドされる可能性があり
     ます。

        • ‘0’ or ‘false’ - ターゲットを無効にします。

        • ‘1’ or ‘true’ - ‘STDERR’ に書き出します。

        • ‘[2-9]’ - すでに開いているファイル・デスクリプターに書き出しま
          す。

        • ‘<absolute-pathname>’ - appendモードでファイルに書き込みます。
          ターゲットがすでに存在し、ディレクトリである場合、トレースは指
          定のディレクトリの下のファイル(プロセスごとに1つ)に書き込まれ
          ます。

        • ‘af_unix:[<socket_type>:]<absolute-pathname>’ - Unixドメインソ
          ケットに書き出します(それらをサポートするプラットフォーム上で
          あれば)。ソケットタイプは ‘stream’ または ‘dgram’ のいずれかで
          す。省略した場合、Gitは両方を試します。

trace2.normalBrief
     ブール値。 trueの場合、 ‘time’ と ‘filename’ と ‘line’ フィールドは
     通常の出力(normal output)から省略されます。 ‘GIT_TRACE2_BRIEF’ 環境
     変数によってオーバーライドされる可能性があります。 デフォルトは
     falseです。

trace2.perfBrief
     ブール値。 trueの場合、 ‘time’ と ‘filename’ と ‘line’ フィールドは
     PERF出力から省略されます。 ‘GIT_TRACE2_PERF_BRIEF’ 環境変数によって
     オーバーライドされる可能性があります。 デフォルトはfalseです。

trace2.eventBrief
     ブール値。 trueの場合、 ‘time’ と ‘filename’ と ‘line’ フィールドは
     イベント出力から省略されます。 ‘GIT_TRACE2_EVENT_BRIEF’ 環境変数に
     よってオーバーライドされる可能性があります。 デフォルトはfalseです
     。

trace2.eventNesting
     整数。 イベント出力でネストされた領域(region)の必要な深さを指定しま
     す。この値より深い領域は省略されます。 ‘GIT_TRACE2_EVENT_NESTING’ 環
     境変数によってオーバーライドされる可能性があります。 デフォルトは
     2です。

trace2.configParams
     trace2出力に記録する必要がある「重要な」構成設定のパターンのコンマ
     区切りリスト。 たとえば、 ‘core.*,remote.*.url’ を指定すると、
     trace2の出力には、構成された各リモートを一覧表示するイベントが含ま
     れます。 ‘GIT_TRACE2_CONFIG_PARAMS’ 環境変数によってオーバーライド
     される可能性があります。 デフォルトでは設定されていません。

trace2.envVars
     trace2出力に記録する必要がある「重要な」環境変数のコンマ区切りリス
     ト。 たとえば、 ‘GIT_HTTP_USER_AGENT,GIT_CONFIG’ を指定すると、
     trace2出力に、(いずれも設定されていると仮定して、)HTTPユーザーエー
     ジェントのオーバーライドとGit構成ファイルの場所をリストするイベント
     が含まれます。 ‘GIT_TRACE2_ENV_VARS’ 環境変数によってオーバーライド
     される可能性があります。 デフォルトでは設定されていません。

trace2.destinationDebug
     ブール値。 trueの場合、トレースターゲットの宛先を書き込み用に開くこ
     とができない場合、Gitはエラーメッセージを出力します。 デフォルトで
     は、これらのエラーは抑制され、トレースは黙って無効になっています。
     ‘GIT_TRACE2_DST_DEBUG’ 環境変数によってオーバーライドされる可能性が
     あります。

trace2.maxFiles
     整数。 トレースファイルをターゲットディレクトリに書き込むとき、この
     数のファイルを超える場合は、追加のトレースを書き込まないでください
     。 代わりに、このディレクトリへのそれ以上のトレースをブロックする番
     兵ファイル(sentinel file)を作成します。 デフォルトは0で、このチェッ
     クを無効にします。

transfer.fsckObjects
     ‘fetch.fsckObjects’ または ‘receive.fsckObjects’ が設定されていない
     場合、代わりにこの変数の値が使用されます。デフォルトはfalseです。

     設定すると、不正な形式のオブジェクトまたは存在しないオブジェクトへ
     のリンクの場合、フェッチまたは受信は中止されます。 さらに、レガシー
     問題(‘fsck.<msg-id>’ を参照)を含む、 ‘.GIT’ ディレクトリや悪意のあ
     る ‘.gitmodules’ ファイルの存在などの潜在的なセキュリティの問題(詳
     細については、v2.2.1およびv2.17.1のリリースノートを参照してください
     )など、他のさまざまな問題がチェックされます。 その他の健全性とセキ
     ュリティのチェックが、将来のリリースで追加される可能性があります。

     受信側では、fsckObjects に障害が発生すると、これらのオブジェクトに
     到達できなくなります。 git-receive-pack(1) の「QUARANTINE
     ENVIRONMENT」を参照してください。 一方、フェッチ側では、不正な形式
     のオブジェクトはリポジトリで参照されない(unreferenced)ままになりま
     す。

     ‘fetch.fsckObjects’ 実装は隔離されていない(non-quarantine nature)た
     め、 ‘receive.fsckObjects’ のようにオブジェクトストアをクリーンな状
     態に保つことはできません。

     オブジェクトが解凍されると、オブジェクトストアに書き込まれるため、
     「フェッチ」が失敗したにもかかわらず、悪意のあるオブジェクトが導入
     される場合があります。オブジェクトストアにすでに書き込まれているオ
     ブジェクトではなく、新しい着信オブジェクトのみがチェックされるため
     、後続の「フェッチ」が成功するだけです。 この振る舞いの違いは信頼さ
     れるべきではありません。将来的には、そのようなオブジェクトは「フェ
     ッチ」のために隔離される可能性があります。

     今のところ、「プッシュ」と同じ保護が必要な場合、疑り深い人
     (paranoid)は検疫環境をエミュレートする方法を見つける必要があります
     。 例えば、内部ミラーの場合、2つのステップでミラーリングを実行しま
     す。信頼できないオブジェクトをフェッチするために1ステップ、そして次
     に、別の内部リポジトリに「プッシュ」(隔離を使用します)を実行する2ス
     テップ目です。内部クライアントにこのプッシュ先リポジトリを消費させ
     、または、内部フェッチを禁止し、完全な ‘fsck’ が実行された場合にの
     み許可します(その間に新しいフェッチは発生しません)。

transfer.hideRefs
     文字列 ‘receive-pack’ と ‘upload-pack’ は、最初の広告から除外する
     refを決定するために使用します。 複数のプレフィックス文字列を指定す
     るには、複数の定義を使用します。 この変数の値にリストされている階層
     の下にあるrefは除外され、 ‘git push’ または ‘git fetch’ に応答する
     ときに非表示になります。 この構成のプログラム固有のバージョンについ
     ては、 ‘receive.hideRefs’ および ‘uploadpack.hideRefs’ を参照してく
     ださい。

     あなたは ref名の前に ‘!’ を含めてエントリを無効にし、以前のエントリ
     で非表示としてマークされていた場合でも、明示的に公開することもでき
     ます。 複数の非表示ref値がある場合、後のエントリが前のエントリを上
     書きします(そして、より具体的な構成ファイルのエントリは、より具体的
     でないものを上書きします)。

     名前空間が使用されている場合、名前空間プレフィックスは、
     ‘transfer.hiderefs’ パターンと照合される前に、各参照から削除されま
     す。 削除する前に参照を一致させるには、参照名の前に ‘^’ を追加しま
     す。 ‘!’ と ‘^’ を組み合わせる場合は、最初に ‘!’ を指定する必要があ
     ります。

     たとえば、 ‘refs/heads/master’ が ‘transfer.hideRefs’ で指定され、
     現在の名前空間が ‘foo’ の場合、
     ‘refs/namespaces/foo/refs/heads/master’ は広告から省略されます。
     ‘uploadpack.allowRefInWant’ が設定されている場合、 ‘upload-pack’ は
     、プロトコルバージョン2の ‘fetch’ コマンドの ‘want-ref
     refs/heads/master’ で、 ‘refs/namespaces/foo/refs/heads/master’ が
     存在しないかのように扱います。 一方、 ‘receive-pack`は、その名前(い
     わゆる `.have’ 行)を指定せずに、refが指しているオブジェクトIDを広告
     します。

     refを非表示にしても、 gitnamespaces(7)のマニュアルページの「
     SECURITY」セクションで説明されている手法を使用して、クライアントが
     ターゲットオブジェクトを盗むことができる場合があります。よって、プ
     ライベートデータは別のリポジトリに保持するのが最良です。

transfer.unpackLimit
     ‘fetch.unpackLimit’ または ‘receive.unpackLimit’ が設定されていない
     場合、代わりにこの変数の値が使用されます。 デフォルト値は100です。

transfer.advertiseSID
     ブール値。 trueの場合、クライアントプロセスとサーバープロセスは、一
     意のセッションIDをリモートの対応するプロセスに広告します。 デフォル
     トはfalseです。

uploadarchive.allowUnreachable
     trueの場合、クライアントが ‘git archive --remote’ を使用して、ref先
     端から到達可能かどうかに関係なく、任意のツリーを要求できるようにし
     ます。詳細については、 git-upload-archive(1)の「SECURITY」セクショ
     ンの説明を参照してください。デフォルトは ‘false’ です。

uploadpack.hideRefs
     この変数は ‘transfer.hideRefs’ と同じですが、 ‘upload-pack’ にのみ
     適用されます(したがって、プッシュではなくフェッチにのみ影響します
     )。 ‘git fetch’ で隠しref(hidden ref)をフェッチしようとすると失敗し
     ます。 ‘uploadpack.allowTipSHA1InWant’ も参照してください。

uploadpack.allowTipSHA1InWant
     ‘uploadpack.hideRefs’ が有効な場合、 ‘upload-pack’ が非表示の参照の
     先端にあるオブジェクトを要求するフェッチ要求を受け入れることを許可
     します(デフォルトでは、そのような要求は拒否されます)。
     ‘uploadpack.hideRefs’ も参照してください。 これが false であっても
     、クライアントは、 gitnamespaces(7) のマニュアルページの「
     SECURITY」セクションで説明されている手法を使用してオブジェクトを盗
     むことができる場合があります。プライベートデータを別のリポジトリに
     保持することをお勧めします。

uploadpack.allowReachableSHA1InWant
     ‘upload-pack’ が、任意の参照先端から到達可能なオブジェクトを要求す
     るフェッチ要求を受け入れることを許可します。 ただし、オブジェクトの
     到達可能性の計算には計算コストがかかることに注意してください。 デフ
     ォルトは ‘false’ です。 これが false であっても、クライアントは、
     gitnamespaces(7) のマニュアルページの「SECURITY」セクションで説明さ
     れている手法を使用してオブジェクトを盗むことができる場合があります
     。 プライベートデータを別のリポジトリに保持することをお勧めします。

uploadpack.allowAnySHA1InWant
     ‘upload-pack’ が、オブジェクトを要求するフェッチ要求を受け入れるこ
     とを許可します。 デフォルトは ‘false’ です。

uploadpack.keepAlive
     ‘upload-pack’ が ‘pack-objects’ を開始したとき、‘pack-objects’ がパ
     ックを準備している間は黙っている期間があるかもしれません。 通常は進
     行状況情報を出力しますが、フェッチに ‘--quiet’ を使用した場合、
     ‘pack-objects’ はパックデータが開始するまで何も出力しません。 一部
     のクライアントとネットワークは、サーバーがハングしてあきらめている
     と見なす場合があります。 このオプションを設定すると、 ‘upload-pack’
     は ‘uploadpack.keepAlive’ 秒ごとに空のキープアライブパケットを送信
     するように指示されます。 このオプションを0に設定すると、キープアラ
     イブパケットが完全に無効になります。 デフォルトは5秒です。

uploadpack.packObjectsHook
     このオプションが設定されている場合、 ‘upload-pack’ がクライアントの
     パックファイルを作成するために ‘git pack-objects’ を実行しようとす
     ると、代わりにこのシェルコマンドが実行されます。 ‘pack-objects’ コ
     マンドとそれが実行するであろう引数(最初の ‘git pack-objects’ を含む
     )がシェルコマンドに追加されます。 フックのstdinとstdoutは、
     ‘pack-objects’ 自体が実行されたかのように扱われます。 つまり、
     ‘upload-pack’ は、 ‘pack-objects’ を対象とした入力をフックに送り、
     stdoutで完成したpackfileを期待します。

     注意: この構成変数は、リポジトリレベルの構成で見られる場合は無視さ
     れることに注意してください(これは、信頼できないリポジトリからのフェ
     ッチに対する安全対策です)。

uploadpack.allowFilter
     このオプションが設定されている場合、 ‘upload-pack’ は部分クローン
     (partial clone)および部分フェッチオブジェクト(partial fetch
     object)のフィルタリングをサポートします。

uploadpackfilter.allow
     未指定のオブジェクトフィルターのデフォルト値を提供します(下記構成変
     数参照)。 ‘true’ に設定すると、将来追加されるすべてのフィルターも有
     効になります。 デフォルトは ‘true’ です。

uploadpackfilter.<filter>.allow
     ‘<filter>’ に対応するオブジェクトフィルターを明示的に許可または禁止
     します。ここで、‘<filter>’ は次のいずれかになります: ‘blob:none’,
     ‘blob:limit’, ‘object:type’, ‘tree’, ‘sparse:oid’, ‘combine’ 。 組
     み合わフィルターを使用する場合は、‘combine’ とすべてのネストされた
     フィルターの種類の両方を許可する必要があります。 デフォルトは
     ‘uploadpackfilter.allow’ です。

uploadpackfilter.tree.maxDepth
     ‘<n>’ が ‘uploadpackfilter.tree.maxDepth’ の値以下の場合にのみ、
     ‘--filter=tree:<n>’ を許可します。 設定されている場合、この構成変数
     がすでに設定されていない限り、これは
     ‘uploadpackfilter.tree.allow=true’ も意味します。 設定されていない
     場合は効果がありません。

uploadpack.allowRefInWant
     このオプションが設定されている場合、 ‘upload-pack’ はプロトコルバー
     ジョン2の ‘fetch’ コマンドの ‘ref-in-want’ 機能をサポートします。 こ
     の機能は、レプリケーションの遅延のために、refが指すOIDについて同じ
     ビューを持たない可能性がある負荷分散サーバーの利益を目的としていま
     す。

url.<base>.insteadOf
     この値で始まるURLは、代わりに<base>で始まるように書き換えられます。
     あるサイトが多数のリポジトリを提供し、それらを複数のアクセス方法で
     提供しており、一部のユーザーが異なるアクセス方法を使用する必要があ
     る場合、この機能は、ユーザーが任意の同等のURLを指定し、Gitが自動的
     に特定のユーザーにとって最適な代替URLに書き換えることを可能にします
     。 複数の insteadOf 文字列が特定のURLに一致する場合、最も長い一致が
     使用されます。

     注意: プロトコルの制限は、書き換えられたURLに適用されることに注意し
     てください。 リライトによってカスタムプロトコルまたはリモートヘルパ
     ーを使用するようにURLが変更された場合は、リクエストを許可するように
     ‘protocol.*.allow’ 構成を調整する必要があります。 特に、サブモジュ
     ールに使用する予定のプロトコルは、デフォルトの ‘user’ ではなく
     ‘always’ に設定する必要があります。 上記 ‘protocol.allow’ の説明を
     参照してください。

url.<base>.pushInsteadOf
     この値で始まるURLはプッシュされません。代わりに、<base>で始まるよう
     に書き直され、結果のURLがにプッシュされます。 あるサイトが多数のリ
     ポジトリを提供し、それらを複数のアクセス方法で提供し、そのうちのい
     くつかはプッシュを許可しない場合、この機能は、サイト上で見たことの
     ないリポジトリであっても、プル専用のURLを指定して、Gitが自動的に適
     切なURLを使ってプッシュすることを可能にします。 複数の
     pushInsteadOf 文字列が特定のURLに一致する場合、最も長い一致が使用さ
     れます。 リモートに明示的な pushurl がある場合、Gitはそのリモートの
     この設定を無視します。

user.name
user.email
author.name
author.email
committer.name
committer.email
     ‘user.name’ 変数と ‘user.email’ 変数は、コミットオブジェクトの
     ‘author’ フィールドと ‘committer’ フィールドに何が入るかを決定しま
     す。 ‘author’ または ‘committer’ を変更する必要がある場合は、
     ‘author.name’ または ‘author.email’ または ‘committer.name’ または
     ‘committer.email’ 変数を設定できます。 また、これらはすべて、
     ‘GIT_AUTHOR_NAME’ または ‘GIT_AUTHOR_EMAIL’ または
     ‘GIT_COMMITTER_NAME’ または ‘GIT_COMMITTER_EMAIL’ または ‘EMAIL’ 環
     境変数によってオーバーライドできます。

     注意: これらの変数の ‘name’ 形式は、通常、何らかの形式の個人名を参
     照していることに注意してください。 これらの設定の詳細については、
     git-commit(1) および git(1) の「environment variables」セクションを
     参照してください。代わりに認証資格情報(authentication credentials)を
     探している場合は、 ‘credential.username’ オプションを参照してくださ
     い。

user.useConfigOnly
     ‘user.email’ と ‘user.name’ のデフォルトを推測しようとせず、代わり
     に構成からのみ値を取得するようにGitに指示します。 たとえば、複数の
     メールアドレスがあり、リポジトリごとに異なるアドレスを使用する場合
     、 グローバル設定でこの設定オプションを ‘true’ に設定し、名前を指定
     すると、 Gitは、新しく複製されたリポジトリで新しくコミットを行う前
     に、電子メールを設定するように求めるプロンプトを表示します。 デフォ
     ルトは‘false‘です。

user.signingKey
     git-tag(1) または git-commit(1) が、署名付きタグまたはコミットを作
     成するときに自動的に使用するキーを選択していない場合は、この変数を
     使用してデフォルトの選択をオーバーライドできます。 このオプションは
     変更されずにgpgの ‘--local-user’ パラメータに渡されるため、gpgがサ
     ポートする任意のメソッドを使用してキーを指定できます。

versionsort.prereleaseSuffix (非推奨)
     ‘versionsort.suffix’ の非推奨のエイリアス。 ‘versionsort.suffix’ が
     設定されている場合は無視されます。

versionsort.suffix
     linkgit:git-tag [1]でバージョンの並べ替えが使用されている場合でも、
     基本バージョンが同じで接尾辞が異なるタグ名は辞書式順序で並べ替えら
     れます。 例えば、メインリリースの後に表示されるプレリリースタグ(例:
     ‘1.0’ の後の ‘1.0-rc1’)。 この変数を指定して、異なる接尾辞を持つタ
     グのソート順を決定できます。

     この変数に単一の接尾辞(suffix)を指定すると、その接尾辞を含むタグ名
     は、対応するメインリリースの前に表示されます。 例えば、変数が ‘-rc’
     に設定されている場合、すべての ‘1.0-rcX’ タグは ‘1.0’ の前に表示さ
     れます。 複数回指定した場合、1つのサフィックスにつき1回だけ、設定中
     のサフィックスの順番でタグ名の並べ替え順が決定されます。 例えば、構
     成で ‘-pre`が `-rc’ の前に表示されている場合、すべての ‘1.0-preX’ タ
     グが ‘1.0-rcX’ タグの前にリストされます。 さまざまな接尾辞を持つタ
     グに対するメインリリースタグの配置順序は、他の接尾辞群の中で空の接
     尾辞を指定することで決定できます。 例えば、接尾辞 「-rc」と「」と「
     -ck」と「-bfs」がこの順序で構成に表示される場合、すべての
     ‘v4.8-rcX｀タグが最初にリストされ、次に `v4.8’ がリストされ、その次
     が ‘v4.8-ckX’ で、最後に ‘v4.8-bfsX’ です。

     複数の接尾辞(suffixes)が同じタグ名に一致する場合、そのタグ名は、タ
     グ名の最初の位置から始まる接尾辞に従って並べ替えされます。 一致する
     複数の異なる接尾辞がその最も早い位置から始まる場合、そのタグ名はそ
     れらの接尾辞の最長のものに従って並べ替えされます。 異なる接尾辞間の
     並べ替え順は、それらが複数の構成ファイルに渡る場合は未定義です。

web.browser
     一部のコマンドで使用できるWebブラウザを指定します。 現在、
     git-instaweb(1) と git-help(1) のみが使用できます。

worktree.guessRemote
     ブランチが指定されておらず、 ‘-b’ や ‘ -B‘ や ‘--detach’ のいずれも
     使用されていない場合、 ‘git worktree add’ はデフォルトでHEADから新
     しいブランチを作成します。 ‘worktree.guessRemote’ がtrueに設定され
     ている場合、 ‘worktree add’ は、名前が新しいブランチ名と一意に一致
     するリモート追跡ブランチを見つけようとします。 そのようなブランチが
     存在する場合、それはチェックアウトされ、新しいブランチの「アップス
     トリーム」として設定されます。 そのような一致が見つからない場合は、
     フォールバックして現在のHEADから新しいブランチを作成します。

BUGS
****

非推奨の ‘[section.subsection]’ 構文を使用する場合、サブセクションに少な
くとも1つの大文字が指定されていると、値を変更すると、変更ではなく複数行
のキーが追加されます。たとえば、設定が以下のようになっている場合

       [section.subsection]
         key = value1

   ‘git config section.Subsection.key value2’ を実行すると、以下のように
なります。

       [section.subsection]
         key = value1
         key = value2

GIT
***

Part of the git(1) suite

Name
****

git-count-objects — パックされていない(unpack)オブジェクトの数とそのディ
スク消費量を計量します

Synopsis
********

     git count-objects [-v] [-H | –human-readable]

DESCRIPTION
***********

これは、パックされていないオブジェクトファイルの数とそれらによって消費さ
れたディスク領域を計量し、再パックするのに適した時期を判断するのに役立ち
ます。

OPTIONS
*******

‘-v’
‘--verbose’
     より詳細な報告:

     count: 緩いオブジェクト(loose objects;ファイルごとに１つのオブジェ
     クトな形式)の数

     size: 緩いオブジェクトによって消費される、KiB単位のディスク容量(-H
     が指定されていない場合)

     in-pack: パック内にあるオブジェクトの数

     size-pack: パック群によって消費される、KiB単位のディスク容量(-Hが指
     定されていない場合)

     prune-packable: パック内にも同じものが存在する緩いオブジェクトの数
     。これらの緩いオブジェクトは、‘git prune-packed’ を使用して剪定する
     (prune)事ができます。

     garbage: オブジェクトデータベース内の、有効な緩いオブジェクトでも有
     効なパックでもないファイルの数

     size-garbage: garbageファイルによって消費されるKiB単位のディスク容
     量(-Hが指定されていない場合)

     alternate: 代替オブジェクトデータベース群の絶対パス。パスごとに1行
     ずつ、複数回表示される場合があります。パスに印刷不可能な文字が含ま
     れている場合は、二重引用符で囲まれ、C言語スタイルのバックスラッシュ
     エスケープシーケンスが含まれている可能性があることに注意してくださ
     い。

‘-H’
‘--human-readable’
     人間に分かりやすい形式でサイズを出力する

GIT
***

Part of the git(1) suite

Name
****

git-credential-cache–daemon — ユーザーの資格情報を一時的にメモリに保存す
る

Synopsis
********

     git credential-cache—daemon [–debug] <socket>

DESCRIPTION
***********

     *Note*

     あなたが、このコマンドを手動で起動したくないなら、
     git-credential-cache(1) を使用すれば自動的に開始されます。

   このコマンドは、 ‘<socket>’ で指定されたUnixドメインソケットで
‘git-credential-cache’ クライアントをリッスンします。クライアントは、資
格情報を保存および取得できます。 各資格情報は、クライアントによって指定
されたタイムアウトまで保持されます。資格情報が保持されなくなると、デーモ
ンは終了します。

   ‘--debug’ オプションが指定されている場合、デーモンはstderrストリーム
を閉じず、クライアントのリッスンを開始した後でも、追加の診断を出力する場
合があります。

GIT
***

Part of the git(1) suite

Name
****

git-credential-cache — パスワードを一時的にメモリに保存するヘルパー

Synopsis
********

     git config credential.helper 'cache [<options>]'

DESCRIPTION
***********

このコマンドは、将来のGitプログラムで使用するために認証情報
(credential)をメモリにキャッシュします。保存された認証情報はディスクに記
録されることはなく、設定可能なタイムアウト後にメモリから削除されます。キ
ャッシュはUnixドメインソケットを介してアクセスでき、ファイルシステムのア
クセス許可によって現在のユーザーに制限されます。

   あなたはこのコマンドを直接呼び出すことは無いでしょう。これは、Gitの他
の部分で認証情報ヘルパーとして使用されることを目的としています。
gitcredentials(7) または 以下の EXAMPLES を参照してください。

OPTIONS
*******

‘--timeout <seconds>’
     認証情報をキャッシュする秒数(デフォルト: 900)。

‘--socket <path>’
     ‘<path>’ を使用して、実行中のキャッシュデーモンに接続します(または
     、新しいキャッシュデーモンが開始されていない場合は開始します)。デフ
     ォルトは ‘$XDG_CACHE_HOME/git/credential/socket’ です
     (‘~/.git-credential-cache/’ が存在しない限り)。
     ‘~/.git-credential-cache/’ が存在する場合は、代わりに
     ‘~/.git-credential-cache/’ が使用されます。あなたのホームディレクト
     リがネットワークにマウントされたファイルシステム上にある場合は、こ
     れをローカルファイルシステムに変更する必要がある場合があります。あ
     なたは絶対パスを指定しなければなりません。

CONTROLLING THE DAEMON
**********************

あなたがデーモンを早期に終了させ、タイムアウトする前にキャッシュされたす
べての認証情報を忘れ去りたい場合は、「exit」アクションを発行できます:

     git credential-cache exit

EXAMPLES
********

このヘルパーの肝は、ユーザー名またはパスワードを入力する必要がある回数を
減らすことです。例えば:

     $ git config credential.helper cache
     $ git push http://example.com/repo.git
     Username: <type your username>
     Password: <type your password>

     [work for 5 more minutes]
     $ git push http://example.com/repo.git
     [your credentials are used automatically]

   credential.helper構成変数を介してオプションを提供できます(この例では
、キャッシュ時間が5分に短縮されます):

     $ git config credential.helper 'cache --timeout=300'

GIT
***

Part of the git(1) suite

Name
****

git-credential-store — 資格情報をディスクに保存するヘルパー

Synopsis
********

     git config credential.helper 'store [<options>]'

DESCRIPTION
***********

     *Note*

     このヘルパーを使用すると、パスワードは暗号化されずにディスクに保存
     され、ファイルシステムのアクセス許可によってのみ保護されます。これ
     が許容できるセキュリティのトレードオフではない場合は
     git-credential-cache(1) を試すか、オペレーティングシステムが提供す
     る安全なストレージと統合するヘルパーを探してください。

   このコマンドは、将来に渡ってGitプログラムで使用できるように、資格情報
をディスクに無期限に保存します。

   このコマンドが直接呼び出されることはありません。これは、gitの他の部分
で資格情報ヘルパーとして使用されることを目的としています。以下の
EXAMPLESまたは gitcredentials(7) を参照してください。

OPTIONS
*******

‘--file=<path>’
     ‘<path>’ を使用して、資格情報を探してして保存します。ファイルには、
     システム上の他のユーザーがファイルを読み取れないようにファイルシス
     テムのアクセス許可が設定されますが、暗号化またはその他の方法で保護
     されることはありません。‘<path>’ 指定がない場合、資格情報は
     ‘~/.git-credentials’ と ‘$XDG_CONFIG_HOME/git/credentials’ から検索
     されます。そして、書き込みは、存在すれば ‘~/.git-credentials’ に書
     き込みますが、‘~/.git-credentials’ に書き込まなかった場合、存在すれ
     ば ‘$XDG_CONFIG_HOME/git/credentials’ に書き込みます。
     FILES も参照してください。

FILES
*****

‘--file’ で明示的に設定されていない場合、git-credential-store が優先順位
に従って資格情報を検索する2つのファイルがあります:

~/.git-credentials
     ユーザー毎の資格情報ファイル。

$XDG_CONFIG_HOME/git/credentials
     2番目のユーザー毎の資格情報ファイル。 _$XDG_CONFIG_HOME_ が設定され
     ていないか空の場合、 ‘$HOME/.config/git/credentials’ が使用されます
     。 ‘~/.git-credentials’ に一致する資格情報がある場合、このファイル
     に保存されている資格情報は使用されません。このファイルがサポートさ
     れていない、古いバージョンのGitを使用することがある場合は、このファ
     イルを作成しないことをお勧めします。

   資格情報探索の場合、ファイルは上記の順序で読み取られ、最初に一致した
資格情報が、リストのさらに下のファイルで見つかった資格情報よりも優先され
ます。

   資格情報ストレージは、デフォルトでこのリストの順で最初に見つかった既
存のファイルに書き込みます。これらのファイルが存在しない場合は、
‘~/.git-credentials’ を作成して書き込みます。

   資格情報の消去を行うと、一致するすべての資格情報がすべてのファイルか
ら消去されます。

EXAMPLES
********

このヘルパーの要点は、ユーザー名またはパスワードを入力する必要がある回数
を減らすことです。 例えば:

     $ git config credential.helper store
     $ git push http://example.com/repo.git
     Username: <type your username>
     Password: <type your password>

     [several days later]
     $ git push http://example.com/repo.git
     [your credentials are used automatically]

STORAGE FORMAT
**************

‘.git-credentials’ ファイルはプレーンテキストで保存されます。各資格情報
は、以下のようなURLとしてそれぞれ独自の行に保存されます:

     https://user:pass@example.com

   他の種類の行(空の行やコメント行など)は、一部が黙って無視される場合で
も、ファイル内では許可されません。エディタでファイルを表示または編集しな
いでください。

   Gitが特定のURLコンテキストの認証を必要とする場合、credential-store は
そのコンテキストを、資格情報ファイルの各エントリと照合するパターンと見な
します。 protocolとhostnameと(すでに持っている場合)usernameが一致する場
合、パスワードはGitに返されます。詳細については、 gitcredentials(7) の 「
the discussion of configuration」を参照してください。

GIT
***

Part of the git(1) suite

Name
****

git-credential — ユーザー資格情報の取得と保存

Synopsis
********

     git credential <fill|approve|reject>

DESCRIPTION
***********

Gitには、システム固有のヘルパーから資格情報(credentials)を保存および取得
したり、ユーザーにユーザー名とパスワードの入力を求めたりするための内部イ
ンターフェイスがあります。 git-credentialコマンドは、Gitと同じ方法で資格
情報を取得、保存、または要求する可能性のあるスクリプトにこのインターフェ
イスを公開します。 このスクリプト可能なインターフェイスの設計は、内部
CAPIをモデル化しています。 概念の背景については、credential.hを参照して
ください。

   git-credentialは、コマンドラインで「action」オプション(‘fill’ または
‘approve’ または ‘reject’ のいずれか)を取り、stdinで資格情報の説明
(description)を読み取ります(INPUT/OUTPUT FORMAT (see INPUT/OUTPUT FORMAT)
を参照)

   アクションが ‘fill’ の場合、git-credentialは、構成ファイルを読み取る
か、構成された資格情報ヘルパーに連絡するか、ユーザーにプロンプトを表示す
ることにより、説明(description)に「username」および「password」属性を追
加しようとします。次に、資格情報の説明(description)のユーザー名とパスワ
ードの属性が、すでに提供されている属性とともにstdoutに出力されます。

   アクションが ‘approve’(承認)の場合、git-credentialは、構成された資格
情報ヘルパーに説明(description)を送信します。ヘルパーは、後で使用するた
めに資格情報を保存する場合があります。

   アクションが ‘reject’ の場合、git-credentialは設定された資格情報ヘル
パーに説明(description)を送信します。これにより、説明(description)に一致
する保存済みの資格情報が消去される場合があります。

   アクションが ‘approve’(承認)または ‘reject’(拒否)の場合、出力は生成さ
れません。

TYPICAL USE OF GIT CREDENTIAL
*****************************

git-credentialを使用するアプリケーションは、通常、以下の手順に従って
‘git credential’ を使用します:

  1. コンテキストに基づいて資格情報の説明(description)を生成します。

     たとえば、 ‘https://example.com/foo.git’ のパスワードが必要な場合は
     、以下の資格情報の説明(description)を生成できます(最後の空白行を忘
     れないでください。これは、アプリケーションがすべての情報の提供を終
     了したことを ‘git credential’ に通知します):

          protocol=https
          host=example.com
          path=foo.git

  2. この説明(description)のユーザー名とパスワードを提供するように
     git-credentialに依頼してください。 これは、 ‘git credential fill’ を
     実行し、ステップ(1)の説明(description)を標準入力に送ることで実行さ
     れます。完全な資格情報の説明(description)(資格情報自体、つまりログ
     インとパスワードを含む)は、以下のように標準出力へ生成されます。

          protocol=https
          host=example.com
          username=bob
          password=secr3t

     ほとんどの場合、これは入力で指定された属性が出力で繰り返されること
     を意味しますが、Gitは資格情報の説明(description)を変更する場合もあ
     ります。たとえば、プロトコルがHTTP(s)であり、
     ‘credential.useHttpPath’ がfalseの場合、 ‘path’ 属性を削除します。

     ‘git credential’ が既にパスワードを知っていた場合、この手順では、ユ
     ーザーが ‘password=secr3t’ を返す前に実際にこのパスワードを入力して
     いなかった可能性があります(ユーザーが代わりにキーチェーンのロックを
     解除するためにパスワードを入力したか、キーチェーンがすでにロック解
     除している場合はユーザーの操作が行われなかった可能性があります)。

  3. 資格情報を使用し(たとえば、手順(2)のユーザー名とパスワードを使用し
     てURLにアクセスします)、それが受け入れられるかどうかを確認します。

  4. パスワードの成功または失敗について報告します。資格情報によって操作
     が正常に完了することが許可された場合は、「approve」アクションでマー
     クを付けて、「git credential」に次の呼び出しで再利用するように指示
     できます。操作中に資格情報が拒否された場合は、「reject」アクション
     を使用して、 ‘git credential’ が次の呼び出しで新しいパスワードを要
     求するようにします。 いずれの場合も、 ‘git credential’ には、ステッ
     プ(2)で取得した資格情報の説明(description)(ステップ(1)で提供された
     ものも含まれます)を指定する必要があります。

INPUT/OUTPUT FORMAT
*******************

‘git credential’ は、標準入力/標準出力で(使用するアクションに応じて)資格
情報を読み取り および/また は書き込みます。この情報は、 ‘git credential’
がログイン情報(ホスト、プロトコル、パスなど)を取得するキー、または取得す
る実際の資格データ(ユーザー名/パスワード)のいずれかに対応できます。

   資格情報は、1行に1つの属性を持つ、名前付き属性のセットに分割されます
。 各属性は、キーと値のペアで指定され、 ‘=’ (等号)記号と、改行で続けます
。

   キーには、 ‘=’ または改行またはNUL以外の任意のバイトを含めることがで
きます。値には、改行またはNUL以外の任意のバイトを含めることができます。

   どちらの場合も、すべてのバイトはそのまま扱われます(つまり、クォートせ
ず、改行またはNULを含む値を送信することはできません)。属性のリストは、空
白行またはファイルの終わりで終了します。

   Gitは以下の属性を理解します:

‘protocol’
     資格情報が使用されるプロトコル(例: ‘https’)。

‘host’
     ネットワーク資格情報のリモートホスト名。これには、ポート番号が指定
     されている場合はそれも含まれます(例: ‘example.com:8088’)。

‘path’
     資格情報が使用されるパス。 たとえば、リモートhttpsリポジトリにアク
     セスする場合、これはサーバー上のリポジトリのパスになります。

‘username’
     私達が既に持っている(たとえば、URL、構成、ユーザー、または以前に実
     行したヘルパーから)場合、資格情報のユーザー名。

‘password’
     資格情報のパスワード(私達が保存を要求している場合)。

‘url’
     この特別な属性が ‘git credential’ によって読み取られると、値はURLと
     して解析され、その構成要素が読み取られたかのように扱われます(たとえ
     ば、 ‘url=https://example.com’ は ‘protocol=https’ と
     ‘host=example.com’ が提供されたかのように振る舞います)。これは、発
     信者がURL自体を解析することを回避するのに役立ちます。

     注意:プロトコルの指定は必須であり、そして、URLでホスト名が指定され
     ていない場合(たとえば "cert:///path/to/file")、資格情報には、値が空
     の文字列であるホスト名属性が含まれることに注意してください。

     URLから欠落しているコンポーネント(たとえば、上記の例にユーザー名が
     ないとか)は未設定のままになります。

GIT
***

Part of the git(1) suite

Name
****

git-cvsexportcommit — 単一のコミットをCVSチェックアウトにエクスポートし
ます

Synopsis
********

     git cvsexportcommit [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
             [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID

DESCRIPTION
***********

コミットをGitからCVSチェックアウトにエクスポートし、Gitリポジトリから
CVSリポジトリへのパッチのマージを容易にします。

   ‘-w’ スイッチを使用してCVSチェックアウトの名前を指定するか、CVS作業コ
ピーのルートから実行します。後者の場合、GIT_DIRを定義する必要があります
。以下の例を参照してください。

   安全寄りに最大限振って、CVSチェックアウトでファイルが変更されておらず
、最新であることを確認したら、デフォルトでは自動コミットしません。

   バイナリファイルに影響するファイルの追加、削除、およびコミットをサポ
ートします。

   コミットがマージコミットの場合は、あなたは ‘git cvsexportcommit’ に
changesetの対象となる親を指定する必要があります。

OPTIONS
*******

‘-c’
     パッチが正常に適用された場合、自動的にコミットします。ハンクが適用
     されない場合、またはその他の問題が発生した場合、コミットされません
     。

‘-p’
     パッチを適用するときは、pedantic(衒学的)(paranoid;病的なほど疑り深
     い)にする。 ‘--fuzz=0’ でpatchを呼び出します。

‘-a’
     著者情報を追加します。作者行と(作成者と異なる場合)コミッターをメッ
     セージに追加します。

‘-d’
     使用する代替CVSROOTを設定します。これは、 ‘CVS -d’ パラメーターに対
     応します。 非対称的な方法でCVSを使用する場合を除いて、通常、ユーザ
     ーはこれを設定することは無いと思います。

‘-f’
     ファイルが最新でない場合でも、強制的にマージします。

‘-P’
     直接の親でなくても、親を強制的にコミットします。

‘-m’
     コミットメッセージの前に、指定のプレフィックスを付けます。パッチシ
     リーズなどに便利です。

‘-u’
     エクスポートを試みる前に、影響を受けるファイルをCVSリポジトリから更
     新してください。

‘-k’
     パッチを適用する前に、CVSチェックアウトの動作でCVSキーワード拡張を
     逆にします。 (例: $Revision: 1.2.3.4$ は $Revision$ になります)

‘-w’
     エクスポートに使用するCVSチェックアウトの場所を指定します。現在のデ
     ィレクトリがGitリポジトリ内にある場合、このオプションでは、実行前に
     GIT_DIRを設定する必要はありません。 デフォルトは
     ‘cvsexportcommit.cvsdir’ の値です。

‘-W’
     現在の作業ディレクトリがGitチェックアウトであるだけでなく、CVSチェ
     ックアウトでもあることをcvsexportcommitに伝えます。したがって、
     Gitは続行する前に作業ディレクトリを親コミットにリセットします。

‘-v’
     おしゃべりにします。

CONFIGURATION
*************

cvsexportcommit.cvsdir
     エクスポートに使用するCVSチェックアウトのデフォルトの場所。

EXAMPLES
********

1つのパッチをCVSにマージします
          $ export GIT_DIR=~/project/.git
          $ cd ~/project_cvs_checkout
          $ git cvsexportcommit -v <commit-sha1>
          $ cvs commit -F .msg <files>

1つのパッチをCVSにマージします( ‘-c’ および ‘-w’ オプション)。作業ディレクトリはGitリポジトリ内にあります
                  $ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>

保留中のパッチをCVSに自動的にマージします — 自分が何をしているかを本当に知っている場合だけにしましょう。
          $ export GIT_DIR=~/project/.git
          $ cd ~/project_cvs_checkout
          $ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v

GIT
***

Part of the git(1) suite

Name
****

git-cvsimport — 別の嫌われ者のSCMからあなたのデータを救難救助する

Synopsis
********

     git cvsimport [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
                   [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
                   [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
                   [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
                   [-r <remote>] [-R] [<CVS_module>]

DESCRIPTION
***********

     *Warning*

     ‘git cvsimport’ はcvspsバージョン2を使用しますが、cvspsバージョン
     2は非推奨とされています。 ‘git cvsimport’ はcvspsバージョン3以降で
     は動作しません。 CVSリポジトリのワンショットインポートを実行してい
     る場合は、 cvs2git (http://cvs2svn.tigris.org/cvs2git.html) または
     cvs-fast-export (http://www.catb.org/esr/cvs-fast-export/) の使用を
     検討してください。

   CVSリポジトリをGitにインポートします。新しいリポジトリを作成するか、
既存のリポジトリに追加インポートします。

   CVSログをパッチセットに分割するには、「cvsps」を使用します。 少なくと
もバージョン2.1が必要です。

     *Warning*

     特定の状況では、インポートによって誤った結果が発生します。 詳細につ
     いては、 ISSUES (see ISSUES) セクションを参照してください。

   ‘git cvsimport’ によって作成されたブランチに対して独自の作業を「絶対
に」行ってはいけません。 デフォルトでは、初期インポートにより、自由に操
作できるCVSリポジトリのメインブランチから「master」ブランチが作成され、
データが入力されます。 その後、自分で増分インポート(incremental
imports)またはCVSブランチを ‘git merge’ する必要があります。着信ブランチ
を分離して保護するために、 ‘-r’ を介して名前付きリモートを指定することを
お勧めします。

   すべての開発者が読み取り/書き込みできる共有パブリックリポジトリを設定
する場合、または git-cvsserver(1) を使用する場合は、インポートされたリポ
ジトリのベアクローンを作成し、 共有リポジトリとしてクローンを作成します
。 gitcvs-migration(7) を参照してください。

OPTIONS
*******

‘-v’
     おしゃべりにします: cvsimportが何をしているかを報告します。
     Verbosity: let _cvsimport_ report what it is doing.

‘-d <CVSROOT>’
     CVSアーカイブのルート。 ローカル(単純なパス)またはリモートの場合が
     あります。 現在、 :local: と :ext: と :pserver: アクセスメソッドの
     みがサポートされています。 指定しない場合、 ‘git cvsimport’ は
     ‘CVS/Root’ から読み取ろうとします。 そのようなファイルが存在しない
     場合は、 ‘CVSROOT’ 環境変数をチェックします。

<CVS_module>
     インポートするCVSモジュール。 <CVSROOT>を基準にしています。 指定し
     ない場合、 ‘git cvsimport’ は ‘CVS/Repository’ からそれを読み取ろう
     とします。

‘-C <target-dir>’
     インポート先のGitリポジトリ。 ディレクトリが存在しない場合は作成さ
     れます。 デフォルトは現在のディレクトリです。

‘-r <remote>’
     このCVSリポジトリをインポートするGitリモート。 ‘git clone’ がデフォ
     ルトで ‘origin’ を使用する方法と同様に、すべてのCVSブランチを
     remotes/<remote>/<branch> に移動します。

‘-o <branch-for-HEAD>’
     (‘-r`を介して)リモートが指定されていない場合、CVSからの `HEAD’ ブラ
     ンチはGitリポジトリ内の ‘origin’ ブランチにインポートされます。 こ
     れは、 ‘HEAD’ がすでにGitに対して特別な意味を持っているためです。 リ
     モートが指定されると、 ‘HEAD’ ブランチの名前は
     ‘remotes/<remote>/master’ になり、 ‘git clone’ の振る舞いを真似しま
     す。 別のブランチにインポートする場合は、このオプションを使用します
     。

     ‘-o master’ を使用すると、古いcvs2gitツールによって最初に実行された
     インポートを続行します。

‘-i’
     インポートのみ: インポート後にチェックアウトを実行しません。 このオ
     プションにより、作業ディレクトリとインデックスは変更されずに残り、
     存在しない場合は作成されません。

‘-k’
     排除キーワード(kill keywords): ノイズの多いチェンジセットを回避する
     ために、CVSアーカイブからファイル名に ‘-kk’ が付くファイルを抽出し
     ます。 強くお勧めしますが、初期にインポートされたツリーとの互換性を
     維持するために、デフォルトではオフになっています。

‘-u’
     タグ名とブランチ名のアンダースコアをドットに変換します。

‘-s <subst>’
     ブランチ名の文字 ‘/’ を <subst> に置き換えます

‘-p <options-for-cvsps>’
     cvspsの追加オプション。 オプション ‘-u’ および _-A_ は暗黙的であり
     、ここでは使用しないでください。

     複数のオプションを渡す必要がある場合は、それらをコンマ(‘,’)で区切り
     ます。

‘-z <fuzz>’
     タイムスタンプファズ係数(timestamp fuzz factor)を秒単位でcvspsに渡
     します。 設定されていない場合、cvspsのデフォルトは300秒です。

‘-P <cvsps-output-file>’
     cvspsを呼び出す代わりに、提供されているcvsps出力ファイルを読み取り
     ます。 デバッグ時や、cvspsがcvsimportの外部で処理されている場合に便
     利です。

‘-m’
     コミットメッセージに基づいてマージを検出しようとします。 このオプシ
     ョンは、コミットメッセージからソースブランチ名をキャプチャしようと
     するデフォルトの正規表現を有効にします。

‘-M <regex>’
     カスタム正規表現を使用したコミットメッセージに基づいてマージを検出
     しようとします。 ‘-m’ と一緒に使用して、デフォルトの正規表現を有効
     にすることもできます。スラッシュ(‘/’)をエスケープする必要があります
     。

     正規表現は、ソースブランチ名を$1でキャプチャする必要があります。

     このオプションは、複数の検出正規表現を提供するために複数回使用でき
     ます。

‘-S <regex>’
     正規表現にマッチするパスをスキップします。

‘-a’
     最近のものを含むすべてのコミットをインポートします。 cvsimportはデ
     フォルトで、タイムスタンプが10分未満のコミットをスキップします。

‘-L <limit>’
     インポートされるコミットの数を制限します。 cvsimportがメモリをリー
     クする場合の回避策です。

‘-A <author-conv-file>’
     CVSは、デフォルトで、コミットログを書き込むときにUnixユーザー名を使
     用します。 このオプションとauthor-conv-fileを使用すると、CVSに記録
     されている名前が作者名(author)と電子メールアドレス(e-mail)と、オプ
     ションのタイムゾーン(time zone)にマップされます:

                  exon=Andreas Ericsson <ae@op5.se>
                  spawn=Simon Pawn <spawn@frog-pond.org> America/Chicago

     ‘git cvsimport’ は、これらの作者が GIT_AUTHOR_NAME と
     GIT_AUTHOR_EMAIL を最初から正しく設定していたかのように見せかけます
     。 タイムゾーンが指定されている場合は、GIT_AUTHOR_DATE に対応するオ
     フセットが適用されます。

     便宜上、このデータは ‘-A’ オプションが提供されるたびに
     ‘$GIT_DIR/cvs-authors’ に保存され、 ‘git cvsimport’ が実行されるた
     びに同じファイルから読み取られます。

     後で ‘git cvsexportcommit’ を使用して変更をCVSに再度エクスポートす
     る場合は、この機能を使用することはお勧めしません。

‘-R’
     CVSリビジョン番号から新しく作成されたGitコミットIDへのマッピングを
     含む ‘$GIT_DIR/cvs-revisions’ ファイルを生成します。 生成されたファ
     イルには、インポートされた（ファイル名、リビジョン）のペアごとに1行
     が含まれます。 各行は以下のようになります

          src/widget.c 1.1 1d862f173cdc7325b6fa6d2ae1cfd61fd1b512b7

     追加インポート(incremental imports)を行うときに使用するために、リビ
     ジョンデータがすでに存在する場合はファイルに追加されます。

     このオプションは、コミットメッセージ、バグ追跡システム、電子メール
     アーカイブなどにCVSリビジョン番号が保存されている場合に役立つことが
     あります。

‘-h’
     短い使用法メッセージを印刷して終了(exit)します。

OUTPUT
******

‘-v’ が指定されている場合、スクリプトは実行内容を報告します。

   それ以外の場合、成功はUnixの方法で示されます。つまり、終了ステータス
がゼロで終了するだけです。

ISSUES
******

タイムスタンプ関連の問題:

   • CVSリポジトリ内のコミットのタイムスタンプが、コミットの順序付けに使
     用できるほど安定していない場合、変更が間違った順序で表示される可能
     性があります。

   • いずれかのファイルが複数回「cvsインポート」された場合(たとえば、複
     数のベンダーリリースのインポート)、HEADに間違ったコンテンツが含まれ
     ています。

   • 異なるファイルのタイムスタンプの順序がコミット一致時間ウィンドウ
     (commit matching time window)内でリビジョンの順序と交差する場合、コ
     ミットの順序が間違っている可能性があります。

   ブランチ関連の問題:

   • コミットが行われていないブランチはインポートされません。

   • 分岐点(branching point)からのすべてのファイルは、CVSに追加されてい
     ない場合でも、ブランチに追加されます。

   • これは、子ブランチが作成された「後に」ソースブランチに追加されたフ
     ァイルに適用されます。以前に子ブランチでコミットが行われなかった場
     合、それらはgitの子ブランチに誤って追加されます。

   タグ関連の問題:

   • 同じリビジョンの複数のタグはインポートされません。

   これらの問題のいずれかがインポートするリポジトリに当てはまると思われ
る場合は、cvs2gitの使用を検討してください:

   • cvs2git (cvs2svnの一部です), ‘http://subversion.apache.org/’

GIT
***

Part of the git(1) suite

Name
****

git-cvsserver — Git用のCVSサーバーエミュレーター

Synopsis
********

SSH

     export CVS_SERVER="git cvsserver"
     cvs -d :ext:user@server/path/repo.git co <HEAD_name>

pserver (/etc/inetd.conf)

     cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

Usage

     git-cvsserver [<options>] [pserver|server] [<directory> …]

DESCRIPTION
***********

このアプリケーションは、GitのCVSエミュレーションレイヤーです。

   非常に機能的です。 ただし、すべてのメソッドが実装されているわけではな
く、実装されているメソッドについては、すべてのスイッチが実装されているわ
けではありません。

   テストは、 CLI CVSクライアントと、 Eclipse CVSプラグインの両方を使用
して行われました。 ほとんどの機能は、これらのクライアントの両方で正常に
機能します。

OPTIONS
*******

これらのオプションはすべて、サーバー側で適用された場合にのみ意味がありま
す。 これらは、 git-daemon(1) オプションにできるだけ似るように実装されて
います。

‘--base-path <path>’
     要求された CVSROOT の前に「path」を追加します

‘--strict-paths’
     サブディレクトリへの再帰を許可しない

‘--export-all’
     構成で ‘gitcvs.enabled’ をチェックしないでください。 このオプション
     を使用する場合は、許可されるディレクトリのリスト(list of allowed
     directories)(下記参照)も指定する必要があります。

‘-V’
‘--version’
     バージョン情報を出力して終了(exit)します

‘-h’
‘-H’
‘--help’
     使用法を出力して終了(exit)します

<directory>
     許可されるディレクトリのリストを指定できます。 ディレクトリが指定さ
     れていない場合、すべてが許可されます。 これは追加の制限です。
     ‘--export-all’ も指定されていない限り、 gitcvs アクセスは
     ‘gitcvs.enabled’ 構成オプションで有効にする必要があります。

LIMITATIONS
***********

CVS クライアントは、タグ付け、ブランチ、Git マージを実行することはできま
せん。

   _git-cvsserver_ は、GitブランチをCVSモジュールにマップします。 これは
、ほとんどのCVSユーザーが期待するものとは大きく異なります。これは、CVSモ
ジュールでは通常1つ以上のディレクトリを表すためです。

INSTALLATION
************

  1. pserverを介してCVSアクセスを提供する場合は、 /etc/inetd.conf に以下
     のような行を追加します

             cvspserver stream tcp nowait nobody git-cvsserver pserver

     注意: 一部のinetdサーバーでは、 argv[0] の値(つまり、プログラムが実
     行されたと想定する名前)とは関係なく、実行可能ファイルの名前を指定で
     きます。 この場合、 /etc/inetd.conf の正しい行は以下のようになりま
     す

             cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

     デフォルトでは、匿名(anonymous)アクセスのみがpserveによって提供され
     ます。 コミットするには、pserverアカウントを作成する必要があります
     。 cvsserverに書き込みを許可するリポジトリの構成ファイルに
     gitcvs.authdb 設定を追加するだけです。たとえば以下のようにします:

             [gitcvs]
                  authdb = /etc/cvsserver/passwd

     これらのファイルの形式は、ユーザー名の後に暗号化されたパスワードが
     続きます。以下に例を示します:

             myuser:$1Oyx5r9mdGZ2
             myuser:$1$BA)@$vbnMJMDym7tA32AamXrm./

     Apacheに付属の「htpasswd」機能を使用してこれらのファイルを作成でき
     ますが、ApacheのMD5 cryptメソッドは、ほとんどのCライブラリの
     crypt() 関数で使用されるメソッドとは異なるため、 ‘-m’ オプションは
     使用しないでください。

     あるいは、perlの crypt() 演算子を使用してパスワードを作成することも
     できます:

             perl -e 'my ($user, $pass) = @ARGV; printf "%s:%s\n", $user, crypt($user, $pass)' $USER password

     次に、pserverメソッドを介してあなたのパスワードを入力します。以下に
     例を示します:

             cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>

     PATHにGitツールを含める以外に、SSHアクセスに特別な設定は必要ありま
     せん。 CVS_SERVER環境変数を受け入れないクライアントがある場合は、
     ‘git-cvsserver’ の名前を ‘cvs’ に変更できます。

     注意: 新しいCVSバージョン(>= 1.12.11)では、CVSROOTで直接
     CVS_SERVERを指定することもサポートしています

          cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>

     これは、あなたの ‘CVS/Root’ ファイルに保存されるので、常に正しい環
     境変数を設定することを心配する必要がないという利点があります。
     ‘git-shell’ に制限されている SSH ユーザは CVS_SERVER でデフォルトを
     上書きする必要はありません(すべきでもありません)。 なぜなら
     ‘git-shell’ は ‘cvs’ を ‘git-cvsserver’ と理解して、相手側が本当の
     ‘cvs’ より良いものを実行していると見せかけているからです。

  2. CVSからアクセスできるようにするリポジトリごとに、リポジトリの構成を
     編集して、以下のセクションを追加する必要があります。

             [gitcvs]
                  enabled=1
                  # optional for debugging
                  logFile=/path/to/logfile

     注意: ‘git-cvsserver’ を呼び出す各ユーザーが、ログファイルとデータ
     ベースへの書き込みアクセス権を持っていることを確認する必要がありま
     す(Database Backend (see DATABASE BACKEND) を参照してください
     )。SSH経由の書き込みアクセスを提供する場合は、 もちろん、ユーザーは
     Gitリポジトリ自体への書き込みアクセス権も必要です。

     また、 ‘cvs commit’ が機能するには、各リポジトリが「ベアリポジトリ
     」(Gitインデックスファイルなし)であることを確認する必要があります。
     gitcvs-migration(7) を参照してください。

     特定のアクセス方法では、すべての構成変数をオーバーライドすることも
     できます。 有効なメソッド名は ‘ext’ (SSHアクセス用) と ‘pserver’ で
     す。 以下の設定例では、SSH経由のアクセスを許可しながら、pserverアク
     セスを無効にします。

             [gitcvs]
                  enabled=0

             [gitcvs "ext"]
                  enabled=1

  3. あなたがチェックアウトコマンドで、CVSROOT/CVS_SERVER を直接指定しな
     くて、自動的に あなたの ‘CVS/Root’ ファイルに保存した場合は、環境で
     明示的に設定する必要があります。 CVSROOTは通常どおりに設定する必要
     がありますが、ディレクトリは適切なGitリポジトリを指している必要があ
     ります。 上記のように、 ‘git-shell’ に制限されて無いSSHクライアント
     の場合、 CVS_SERVERを ‘git-cvsserver’ に設定する必要があります。

               export CVSROOT=:ext:user@server:/var/git/project.git
               export CVS_SERVER="git cvsserver"

  4. コミットを行うSSHクライアントの場合、サーバー側の .ssh/environment
     ファイル(またはシェルによっては .bashrc など)が、 GIT_AUTHOR_NAMEと
     GIT_AUTHOR_EMAILとGIT_COMMITTER_NAMEとGIT_COMMITTER_EMAIL の為に適
     切な値をエクスポートすることを確認します。 ログインシェルがbashであ
     るSSHクライアントの場合、.bashrc が妥当な代替手段となる可能性があり
     ます。

  5. これで、クライアントはプロジェクトをチェックアウトできるようになり
     ます。 CVSの「モジュール」名を使用して、チェックアウトするGitの「ヘ
     ッド」を示します。 これにより、 ‘-d <dir_name>’ で特に指定しない限
     り、新しくチェックアウトしたディレクトリの名前も設定されます。 たと
     えば、以下は「master」ブランチを「project-master」ディレクトリにチ
     ェックアウトします:

               cvs co -d project-master master

DATABASE BACKEND
****************

‘git-cvsserver’ は、Gitヘッド(つまり、CVSモジュール)ごとに1つのデータベ
ースを使用して、リポジトリに関する情報を格納し、一貫したCVSリビジョン番
号を維持します。 データベースは、コミットするたびに更新(つまり、書き込み
)する必要があります。

   (‘git-cvsserver’ を使用するのではなく、)コミットが ‘git’ を使用して直
接行われる場合、アクセス方法や要求された操作に関係なく、 ‘git-cvsserver’
による次のリポジトリアクセスで更新を行う必要があります。

   つまり、(たとえば、pserverメソッドを使用して、)読み取りアクセスのみを
提供している場合でも、 ‘git-cvsserver’ はデータベースへの書き込みアクセ
ス権を持っている必要があります(それ以外の場合は、 ‘git-cvsserver’ が実行
されるたびにデータベースが最新であることを確認する必要があります)。

   デフォルトでは、Gitディレクトリにある ‘gitcvs.<module_name>.sqlite’ と
いう名前のSQLiteデータベースを使用します。 SQLiteバックエンドは書き込み
時にデータベースファイルと同じディレクトリに一時ファイルを作成するため、
‘git-cvsserver’ を使用するユーザーにディレクトリへの書き込みアクセスを許
可せずにデータベースファイルへの書き込みアクセスを許可するだけでは不十分
な場合があることに注意してください 。

   追跡しているブランチが変更された後、データベースを一貫した形式で確実
に再生成することはできません。 例:マージされたブランチの場合、
‘git-cvsserver’ は開発の1つのブランチのみを追跡し、 ‘git merge’ の後、増
分更新されたデータベースは、最初から再生成されたデータベースとは異なるブ
ランチを追跡し、一貫性のないCVSリビジョン番号を引き起こす可能性がありま
す。 ‘git-cvsserver’ には、マージ前に段階的に実行された場合にどのブラン
チを選択したかを知る方法がありません。 したがって、データベースを完全に
または部分的に(古いバックアップから)再生成する必要がある場合は、既存の
CVSサンドボックスを疑う必要があります。

   以下の構成変数を使用してデータベースバックエンドを構成できます:

Configuring database backend
============================

‘git-cvsserver’ は Perl DBI モジュールを使用します。 これらの変数を変更
する場合、特に ‘DBI->connect()’ については、そのドキュメントもお読みくだ
さい。

gitcvs.dbName
     データベース名。 正確な意味は、選択したデータベースドライバーによっ
     て異なります。SQLiteの場合、これはファイル名です。 変数置換をサポー
     トします(下記参照)。 セミコロン(‘;’)を含めることはできません。 デフ
     ォルト: ：‘%Ggitcvs.%m.sqlite’

gitcvs.dbDriver
     使用DBIドライバー。 ここで使用可能なドライバーを指定できますが、機
     能しない場合があります。 cvsserverは「DBD::SQLite」でテストされ、「
     DBD::Pg」で動作報告があり、「DBD::mysql」で動作しないことが報告され
     ています。 これは実験的な機能と見なしてください。 コロン(‘:’)を含め
     ることはできません。 デフォルト: ‘SQLite’

gitcvs.dbuser
     データベースユーザー。 SQLiteにはデータベースユーザーの概念がないた
     め、 ‘dbDriver’ を設定する場合にのみ役立ちます。 変数置換(variable
     substitution)をサポートします(下記参照)。

gitcvs.dbPass
     データベースのパスワード。 SQLiteにはデータベースパスワードの概念が
     ないため、 ‘dbDriver’ を設定する場合にのみ役立ちます。

gitcvs.dbTableNamePrefix
     データベーステーブル名の接頭辞。 変数置換をサポートします(下記参照
     )。 アルファベット以外の文字(non-alphabetic characters)はすべてアン
     ダースコアに置き換えられます。

   すべての変数は、アクセス方法ごとに設定することもできます。 上記
(see configaccessmethod) を参照してください。

Variable substitution
---------------------

‘dbDriver’ と ‘dbUser’ では、以下の変数を使用できます:

%G
     Gitディレクトリ名

%g
     Gitディレクトリ名。英数字 と ‘.’ と ‘-’ を除くすべての文字が ‘_’ に
     置き換えられます(これにより、ディレクトリ名をファイル名として使用す
     ることが容易になります)。

%m
     CVSモジュール/Gitヘッド名

%a
     アクセス方法("ext" または "pserver" のいずれか)

%u
     ‘git-cvsserver’ を実行しているユーザーの名前。 名前を判別できない場
     合は、数値uidが使用されます。

ENVIRONMENT
***********

これらの変数により、状況によってはコマンドラインオプションが不要になり、
git-shellを使用して使用を制限しやすくなります。

   GIT_CVSSERVER_BASE_PATHは、 ‘--base-path’ 引数の代わりになります。

   GIT_CVSSERVER_ROOTは、単一ディレクトリのホワイトリストを指定します。
上記のように、リポジトリは git-cvsserver を介したアクセスを許可するよう
に構成する必要があります。

   これらの環境変数が設定されている場合、対応するコマンドライン引数は使
用されない場合があります。

ECLIPSE CVS CLIENT NOTES
************************

Eclipse CVSクライアントでチェックアウトを取得するには:

  1. メニューの "Create a new project → From CVS checkout"

  2. 新しい場所(location)を作成します。 適切なプロトコルを選択する方法の
     詳細については、以下のnotesを参照してください。

  3. 利用可能な「モジュール」を参照します。 リポジトリ内のヘッドのリスト
     が表示されます。 そこからツリーを閲覧することはできません。 表示さ
     れるのはヘッドだけです。

  4. チェックアウトする ブランチ/タグ を尋ねられたら、 ‘HEAD’ を選択しま
     す。 .project ファイルのコミットを回避するには、「launch commit
     wizard」のチェックを外します。

   プロトコルに関する注意: pserver経由で匿名アクセスを使用している場合は
、それを選択するだけです。 SSHアクセスを使用している場合は、「ext」プロ
トコルを選択し、 Preferences→Team→CVS→ExtConnectionペインで「ext」アクセ
スを構成する必要があります。 CVS_SERVERを ‘gitcvsserver’ に設定します。
なお、 ‘ext’ を使用する場合、パスワードのサポートは良くないので、SSHキー
の設定を必ずしてください。

   または、Eclipseが提供する非標準のextsshプロトコルを使用することもでき
ます。 その場合、CVS_SERVERは無視され、サーバー上のcvsユーティリティを
‘git-cvsserver’ に置き換えるか、 ‘.bashrc’ を操作して、「cvs」を呼び出す
と「git-cvsserver」が効果的に呼び出されるようにする必要があります。

動作が確認されているクライアント
********************************

   • CVS 1.12.9 on Debian

   • CVS 1.11.17 on MacOSX (from Fink package)

   • Eclipse 3.0, 3.1.2 on MacOSX (「Eclipse CVS Client Notes」参照)

   • TortoiseCVS

OPERATIONS SUPPORTED
********************

checkout, diff, status, update, log, add, remove, commit を含む、通常の
使用に必要なすべての操作がサポートされています。

   CVSタグまたはリビジョン番号(通常は ‘-r’)を読み取るほとんどのCVSコマン
ド引数は機能し、任意のgit refspec(タグ、ブランチ、コミットIDなど)もサポ
ートします。 ただし、デフォルト以外のブランチのCVSリビジョン番号は十分に
エミュレートされておらず、cvsログにはタグまたはブランチがまったく表示さ
れません。 (非メインブランチのCVSリビジョン番号は、表面的にはCVSリビジョ
ン番号に似ていますが、実際には、ブランチポイント以降のリビジョン数を表す
のではなく、git commit IDを直接エンコードします。)

   注意: 特定のブランチをチェックアウトする方法は2つあることに注意してく
ださい。 この文書の他の場所で説明されているように、cvs checkoutの「
module」パラメーターはブランチ名として解釈され、メインブランチになります
。 cvs update -rを使用して別のブランチを一時的にスティッキーにした場合で
も、特定のサンドボックスのメインブランチのままです。 あるいは、モジュー
ルがまだ「メイン」ブランチである場合でも、-r引数は実際にチェックアウトす
る他のブランチを示すことができます。 （現在実装分の)トレードオフ: 新しい
「モジュール」ごとに、指定されたモジュールの履歴を持つ新しいデータベース
がディスク上に作成され、データベースが作成された後、そのメインブランチに
対する操作は高速になります。 または、-rは余分なディスク領域を必要としま
せんが、cvs updateなどの多くの操作では大幅に遅くなる可能性があります。

   CVSで許可されていない文字を含む git refspec を参照する場合は、2つのオ
プションがあります。 まず、適切なCVS ‘-r’ 引数に直接 git refspec を提供
するだけで機能する場合があります。 一部のCVSクライアントは、引数の健全性
チェックをあまり行っていないようです。 次に、それが失敗した場合は、CVSタ
グで有効な文字のみを使用する特殊文字エスケープメカニズムを使用できます。
書式の4文字または5文字のシーケンス(アンダースコア(‘_’)と、ダッシュ
(‘-’)と、1〜2字と、ダッシュ(‘-’))は、1〜2字に基づいてさまざまな文字をエ
ンコードできます: スラッシュ(‘/’)の場合は ‘s’ 、または ピリオド(‘.’)の場
合は ‘p’ 、または アンダースコア(‘_’)の場合は ‘u’ 、または 2桁の16進数で
表される任意のバイト値(通常はASCIIコード。またはUTF-8でエンコードされた
文字の一部)。

   従来の監視操作(edit、watch 関連)はサポートされていません。 エクスポー
トとタグ付け(タグとブランチ)は、この段階ではサポートされていません。

CRLF Line Ending Conversions
============================

デフォルトでは、サーバーはすべてのファイルに対して ‘-k’ モードを空白のま
まにします。これにより、CVSクライアントはそれらをテキストファイルとして
扱い、一部のプラットフォームでは行末変換の対象になります。

   ‘gitcvs.usecrlfattr’ 構成変数を設定することにより、サーバーで行末変換
属性を使用してファイルの ‘-k’ モードを設定することができます。 行末変換
の詳細については、 gitattributes(5) を参照してください。

   あるいは、 ‘gitcvs.usecrlfattr’ 構成が有効になっていない場合、または
属性でファイル名の自動検出が許可されていない場合、サーバーはデフォルト設
定に ‘gitcvs.allBinary’ 構成を使用します。 ‘gitcvs.allBinary’ が設定され
ている場合、特に指定されていないファイルはデフォルトで ‘-kb’ モードにな
ります。 それ以外の場合、 ‘-k’ モードは空白のままになります。 ただし、
‘gitcvs.allBinary’ が ‘guess’ に設定されている場合、ファイルの内容に基づ
いて正しい ‘-k’ モードが推測されます。

   cvsとの一貫性を最大限に保つには、 ‘gitcvs.usecrlfattr’ をtrueに設定し
、 ‘gitcvs.allBinary’ を ‘guess’ に設定して、デフォルトをオーバーライド
するのがおそらく最善です。

DEPENDENCIES
************

‘git-cvsserver’ は DBD::SQLite に依存します。

GIT
***

Part of the git(1) suite

Name
****

git-daemon — Gitリポジトリ用のほんまにシンプルなサーバー

Synopsis
********

     git daemon [–verbose] [–syslog] [–export-all]
                  [–timeout=<n>] [–init-timeout=<n>] [–max-connections=<n>]
                  [–strict-paths] [–base-path=<path>] [–base-path-relaxed]
                  [–user-path | –user-path=<path>]
                  [–interpolated-path=<pathtemplate>]
                  [–reuseaddr] [–detach] [–pid-file=<file>]
                  [–enable=<service>] [–disable=<service>]
                  [–allow-override=<service>] [–forbid-override=<service>]
                  [–access-hook=<path>] [–[no-]informative-errors]
                  [–inetd |
                   [–listen=<host_or_ipaddr>] [–port=<n>]
                   [–user=<user> [–group=<group>]]]
                  [–log-destination=(stderr|syslog|none)]
                  [<directory>…]

DESCRIPTION
***********

通常はポート「DEFAULT_GIT_PORT」(9418)でリッスンする非常に単純なTCP Gitデ
ーモン。サービスを要求する接続を待機し、有効になっている場合はそのサービ
スを提供します。

   ディレクトリにマジックファイル "git-daemon-export-ok" があることを確
認し、この方法でエクスポートのマークが明示されていないGitディレクトリの
エクスポートを拒否します(‘--export-all’ パラメーターが指定されていない場
合)。 いくつかのディレクトリパスを ‘git daemon’ の引数として渡すと、あな
たは提供するモノをそれらで構成されるホワイトリストにさらに制限できます。

   デフォルトでは、 ‘upload-pack’ サービスのみが有効になっており、 _git
fetch_ や _git pull_ や _git clone_ から呼び出される _git fetch-pack_ と
_git ls-remote_ クライアントにサービスを提供します。

   これは、読み取り専用の更新、つまりGitリポジトリからのプルに最適です。

   _git archive_ を提供するための ‘upload-archive’ もあります。

OPTIONS
*******

‘--strict-paths’
     パスを正確に一致させ(つまり、実際のパスが "/foo/repo.git" または
     "/foo/repo/.git" の場合は "/foo/repo" を許可しないでください)、そし
     てユーザー相対パスを許可しないでください。このオプションが有効で、
     かつ、ホワイトリストが指定されていない場合、 ‘git daemon’ は起動を
     拒否します。

‘--base-path=<path>’
     指定されたパスを基準にして、すべてのパス要求を再マップします。これ
     は一種の "Git root" です。example.comで ‘--base-path=/srv/git’ を伴
     って ‘git daemon’ を実行し、後で ‘git://example.com/hello.git’ をプ
     ルしようと試みると、 ‘git daemon’ はパスを ‘/srv/git/hello.git’ と
     して解釈します。

‘--base-path-relaxed’
     ‘--base-path’ が有効になっていて、リポジトリを探すのに失敗した場合
     、このオプションを使用すると、 ‘git daemon’ はベースパスを前に付け
     ずに探索を試みます。 これは、古いパスを許可したまま、 ‘--base-path’
     使用に切り替える場合に便利です。

‘--interpolated-path=<pathtemplate>’
     仮想ホスティングをサポートするために、補完されたパステンプレートを
     使用して、代替パスを動的に構築できます。テンプレートは、クライアン
     トから提供されたターゲットホスト名の %H をサポートしますが、すべて
     小文字に変換されます。正規ホスト名の場合は %CH、サーバーのIPアドレ
     スの場合は %IP、ポート番号の場合は %P、名前付きリポジトリの絶対パス
     の場合は %D です。補完後、パスはディレクトリホワイトリストに対して
     検証されます。

‘--export-all’
     _git-daemon-export-ok_ ファイルがない場合でも、Gitリポジトリのよう
     に見えるすべてのディレクトリ(_objects_ と _refs_ サブディレクトリが
     ある)からのプルを許可します。

‘--inetd’
     サーバーをinetdサービスとして実行します。‘--syslog’ の指定を含んで
     います(‘--log-destination=’ でオーバーライドされる場合があります)。
     ‘--detach’ 、 ‘--port’ 、 ‘--listen’ 、 ‘--user’ 、 ‘--group’ オプ
     ションとは互換性がありません。

‘--listen=<host_or_ipaddr>’
     特定のIPアドレスまたはホスト名でリッスンします。IPアドレスは、
     IPv4アドレス、またはサポートされている場合はIPv6アドレスのいずれか
     になります。IPv6がサポートされていない場合、 ‘--listen=hostname’ も
     サポートされていないため、 ‘--listen’ にはIPv4アドレスを指定する必
     要があります。このオプションは複数回与えることができます。
     ‘--inetd’ オプションと互換性がありません。

‘--port=<n>’
     代わりのポートでリッスンします。 ‘--inetd’ オプションと互換性があり
     ません。

‘--init-timeout=<n>’
     接続が確立されてからクライアント要求が受信されるまでのタイムアウト
     (秒単位)(基本的には即時である必要があるため、通常はかなり低い値)。

‘--timeout=<n>’
     特定のクライアントサブリクエスト(client sub-requests)のタイムアウト
     (秒単位)。これには、サーバーがサブリクエストを処理するのにかかる時
     間と、次のクライアントのリクエストを待つために費やされる時間が含ま
     れます。

‘--max-connections=<n>’
     同時クライアントの最大数。デフォルトは32です。制限しない場合はゼロ
     に設定します。

‘--syslog’
     ‘--log-destination=syslog’ の短縮形。

‘--log-destination=<destination>’
     指定した宛先にログメッセージを送信します。 このオプションは
     ‘--verbose’ を意味しないため、デフォルトではエラー状態のみがログに
     記録されることに注意してください。 <destination> は以下のいずれかで
     ある必要があります:

     stderr
          標準エラーに書き込みます。 ‘--detach’ が指定されている場合、プ
          ロセスは実際の標準エラーから切断され、この宛先は実質的に
          ‘none’ と同等になることに注意してください。

     syslog
          ‘git-daemon’ 識別子を使用してsyslogに書き込みます。

     none
          すべてのログを無効にします。

     デフォルトの宛先は、 ‘--inetd’ または ‘--detach’ が指定されている場
     合、は ‘syslog’ であり、それ以外の場合は ‘stderr’ です。

‘--user-path’
‘--user-path=<path>’
     ~user 表記をリクエストで使用できるようにします。パラメータなしで指
     定した場合、 git://host/~alice/foo git：// host / ~ alice / fooへの
     リクエストは、ユーザー ‘alice’ のホームディレクトリにある _foo_ リ
     ポジトリへのアクセスリクエストと見なされます。 ‘--user-path=path’ が
     指定されている場合、同じリクエストが、ユーザー ‘alice’ のホームディ
     レクトリにある ‘path/foo’ リポジトリにアクセスするリクエストと見な
     されます。

‘--verbose’
     着信接続と要求されたファイルに関する詳細をログに記録します。

‘--reuseaddr’
     リスニングソケットをバインドするときは SO_REUSEADDR を使用します。
     これにより、古い接続がタイムアウトするのを待たずにサーバーを再起動
     できます。

‘--detach’
     シェルからデタッチします。 ‘--syslog’ オプションの指定を含んでいま
     す。

‘--pid-file=<file>’
     プロセスIDを <file> に保存します。デーモンが ‘--inetd’ で実行されて
     いる場合は無視されます。

‘--user=<user>’
‘--group=<group>’
     サービスループに入る前に、デーモンのuidとgidを変更します。
     ‘--group’ なしで ‘--user’ のみが指定された場合、ユーザーのプライマ
     リグループIDが使用されます。オプションの値は ‘getpwnam(3)’ と
     ‘getgrnam(3)’ に与えられ、数値IDはサポートされていません。

     これらのオプションを指定すると、 ‘--inetd’ と一緒に使用するとエラー
     になります。 同じことを実現するには、必要に応じて、 _git daemon_ を
     生成する前に、inetデーモンの機能を使用します。

     ユーザーIDを切り替える多くのプログラムと同様に、デーモンは、(例えば
     、‘upload-pack’ や‘receive-pack‘ の) gitプログラムを実行するときに
     ‘$HOME’ などの環境変数をリセットしません。このオプションを使用する
     場合は、デーモンを起動する前に、 ‘HOME’ を ‘<user>’ のホームディレ
     クトリを指すように設定、およびエクスポートし、そのディレクトリ内の
     Git構成ファイルが ‘<user>’ によって読み取り可能であることを確認して
     ください。

‘--enable=<service>’
‘--disable=<service>’
     デフォルトでサイト全体のサービスを 有効/無効 にします。サイト全体で
     無効にされたサービスは、オーバーライド可能とマークされていて、リポ
     ジトリが構成アイテムでサービスを有効にしている場合でも、リポジトリ
     ごとに有効にできることに注意してください。

‘--allow-override=<service>’
‘--forbid-override=<service>’
     リポジトリごとの構成でサイト全体のデフォルトをオーバーライドするこ
     とを 許可/禁止 します。デフォルトでは、すべてのサービスがオーバーラ
     イドされる場合があります。

‘--[no-]informative-errors’
     informative-errorsがオンになっている場合、git-daemonはより詳細なエ
     ラーをクライアントに報告し、「no such repository」(そのようなリポジ
     トリがない)と「repository not exported」(リポジトリがエクスポートさ
     れていない)などの条件を区別します。これはクライアントにとってより便
     利ですが、エクスポートされていないリポジトリの存在に関する情報が漏
     洩する可能性があります。informative-errorsが有効になっていない場合
     、すべてのエラーは「access denied」とクライアントに報告します。 デ
     フォルトは ‘--no-informative-errors’ です。

‘--access-hook=<path>’
     クライアントが接続するたびに、最初に、<path> で指定された外部コマン
     ドを実行します。コマンドライン引数として、サービス名
     ("upload-pack"など)や、リポジトリへのパスや、ホスト名(%H)や、正規の
     ホスト名(%CH)や、IPアドレス(%IP)や、TCPポート(%P)を、指定します。外
     部コマンドは、ゼロ以外のステータスで終了することによってサービスを
     拒否する(またはゼロ・ステータスで終了することによってサービスを許可
     する)ことを決定できます。また $REMOTE_ADDR や ‘$REMOTE_PORT’ 環境変
     数を調べて、この決定を行うときにリクエスト側(requestor)ついて調べる
     こともできます。

     外部コマンドはオプションで、サービスを拒否したときにエラーメッセー
     ジとしてリクエスト側(requestor)に送信される1行を標準出力に書き込む
     ことができます。

<directory>
     許可するディレクトリを列挙するホワイトリストに追加するディレクトリ
     。 ‘--strict-paths’ が指定されていない限り、これには指定のディレク
     トリのサブディレクトリも含まれます。

SERVICES
********

これらのサービスは、このコマンドのコマンドラインオプションを使用してグロ
ーバルに 有効/無効 にできます。よりきめ細かい制御が必要な場合(たとえば、
デーモンがサービスを提供するいくつかの選択されたリポジトリでのみ ‘git
archive’ を実行できるようしたい時)、リポジトリごとの構成ファイルを使用し
て、それらを有効または無効にできます。

upload-pack
     これは、 ‘git fetch-pack’ と ‘git ls-remote’ クライアントにサービス
     を提供します。デフォルトで有効になっていますが、リポジトリでは
     ‘daemon.uploadpack `構成アイテムを `false’ に設定することで無効にで
     きます。

upload-archive
     これは ‘git archive --remote’ を提供します。 デフォルトでは無効にな
     っていますが、リポジトリでは、 ‘daemon.uploadarch’ 構成アイテムを
     ‘true’ に設定することで有効にできます。

receive-pack
     これは ‘git send-pack’ クライアントにサービスを提供し、匿名プッシュ
     を可能にします。プロトコルに認証が「ない」ため、デフォルトでは無効
     になっています(つまり、参照の削除を含め、誰でもリポジトリに何でもプ
     ッシュできます)。これは、誰もが友好的であるクローズドLAN設定のみを
     対象としています。このサービスは、 ‘daemon.receivepack’ 構成アイテ
     ムを ‘true’ に設定することで有効にできます。

EXAMPLES
********

ここでは /etc/services の下に構築するものと仮定します
          $ grep 9418 /etc/services
          git             9418/tcp                # Git Version Control System

_git daemon_ as inetd server
     ホワイトリストに登録されたディレクトリのセット /pub/foo および
     /pub/bar の下にあるリポジトリを処理するinetdサービスとして「git
     daemon」を設定するには、以下のようなエントリを /etc/inetd にすべて
     1行で配置します:

                  git stream tcp nowait nobody  /usr/bin/git
                          git daemon --inetd --verbose --export-all
                          /pub/foo /pub/bar

_git daemon_ as inetd server for virtual hosts
     異なる仮想ホスト ‘www.example.com’ と ‘www.example.org’ のリポジト
     リを処理するinetdサービスとして「git daemon」を設定するには、以下の
     ようなエントリをすべて１行で ‘/etc/inetd’ に配置します:

                  git stream tcp nowait nobody /usr/bin/git
                          git daemon --inetd --verbose --export-all
                          --interpolated-path=/pub/%H%D
                          /pub/www.example.org/software
                          /pub/www.example.com/software
                          /software

     この例では、ルートレベルのディレクトリ ‘/pub’ には、サポートされて
     いる各仮想ホスト名のサブディレクトリが含まれています。さらに、両方
     のホストは、リポジトリを単に
     ‘git://www.example.com/software/repo.git’ として公開します。 1.4.0よ
     り前のクライアントの場合、 ‘/software’ から適切なデフォルトリポジト
     リへのシンボリックリンクも作成できます。

_git daemon_ as regular daemon for virtual hosts
     IPアドレスに基づいて複数の仮想ホストのリポジトリを処理する通常の非
     inetdサービスとして「git daemon」を設定するには、以下のようにデーモ
     ンを起動します:

                  git daemon --verbose --export-all
                          --interpolated-path=/pub/%IP/%D
                          /pub/192.168.1.200/software
                          /pub/10.10.220.23/software

     IPアドレスに基づいて複数の仮想ホストのリポジトリを処理する通常の非
     inetdサービスとして「git daemon」を設定するには、以下のようにデーモ
     ンを起動します。

selectively enable/disable services per repository
     リポジトリに対して ‘git archive --remote’ を有効にし、 ‘git fetch’
     を無効にするには、リポジトリの構成ファイルに以下のものを含めます（
     つまり、「HEAD」、「refs」、および「objects」の横にあるファイル「
     config」)。

                  [daemon]
                          uploadpack = false
                          uploadarch = true

ENVIRONMENT
***********

「git daemon」は、IPアドレスが使用可能な場合、REMOTE_ADDRをそれに接続し
たクライアントのIPアドレスに設定します。 REMOTE_ADDRは、サービスの実行時
に呼び出されるフックの環境で使用できます。

GIT
***

Part of the git(1) suite

Name
****

git-describe — 有効なrefに基づいて、オブジェクトに人間が読める形式の名前
を付けます

Synopsis
********

     git describe [–all] [–tags] [–contains] [–abbrev=<n>] [<commit-ish>…]
     git describe [–all] [–tags] [–contains] [–abbrev=<n>] –dirty[=<mark>]
     git describe <blob>

DESCRIPTION
***********

このコマンドは、コミットから到達可能な最新のタグを検索します。 タグがコ
ミットを指している場合は、タグのみが表示されます。 それ以外の場合は、タ
グ名に、タグ付けされたオブジェクトの上に追加されたコミットの数と、最新の
コミットの省略されたオブジェクト名の接尾辞が付きます。 結果は「人間が読
める」オブジェクト名であり、他のgitコマンドへのコミットを識別するために
も使用できます。

   デフォルト(‘--all’ または ‘--tags’ なし)では、 ‘git describe’ は注釈
付きタグのみを表示します。 注釈付きタグの作成の詳細については、
git-tag(1) の ‘-a’ および ‘-s’ オプションを参照してください。

   与えられたオブジェクトがブロブを参照している場合、それは
‘<commit-ish>:<path>’ として表されます。これは、そブロブが
‘<commit-ish>’ の ‘<path>’ にあり、それ自体が、このブロブがHEADからの逆
リビジョンウォークで発生する最初のコミットを表しているためです。

OPTIONS
*******

<commit-ish>…
     説明するコミットっぽいオブジェクト名。 省略した場合、デフォルトで
     HEADになります。

‘--dirty[=<mark>]’
‘--broken[=<mark>]’
     作業ツリーの状態を説明します。 作業ツリーがHEADと一致する場合、出力
     は ‘git describe HEAD’ と同じになります。 作業ツリーにローカル変更
     がある場合、接尾辞 ‘-dirty’ が追加されます。 リポジトリが破損してい
     て、Gitがローカルでの変更があるかどうかを判断できない場合(代わりに
     接尾辞 ‘-broken’ を追加する ‘--broken’ が指定されていない限り)、
     Gitはエラーになります。

‘--all’
     注釈付きタグのみを使用する代わりに、 ‘refs/’ 名前空間にあるrefを使
     用してください。 このオプションを使用すると、既知のブランチ または
     リモート追跡ブランチ または 軽量タグ を照合できます。

‘--tags’
     注釈付きタグのみを使用する代わりに、 ‘refs/tags’ 名前空間にあるタグ
     を使用してください。 このオプションを使用すると、軽量(注釈なし)タグ
     のマッチングが可能になります。

‘--contains’
     そのコミットより前のタグを見つける代わりに、そのコミットの後に来る
     タグを見つけて、それを含めます。 自動的に ‘--tags’ の指定を含んでい
     ます。

‘--abbrev=<n>’
     省略されたオブジェクト名のデフォルトの16進数(これは、リポジトリ内の
     オブジェクトの数によって異なりますが、デフォルトは7桁です)を使用す
     る代わりに、<n>桁、または一意のオブジェクト名を形成するために必要な
     数の桁を使用します。<n>が0の場合、長い形式は抑制され、最も近いタグ
     のみが表示されます。

‘--candidates=<n>’
     入力のコミットっぽいのを説明するための候補として最新の10個のタグの
     みを考慮するのではなく、最大<n>個の候補を考慮してください。 <n>を
     10より大きくすると、少し時間がかかりますが、より正確な結果が得られ
     る場合があります。 <n>が0の場合、完全一致のみが出力されます。

‘--exact-match’
     完全一致のみを出力します(タグは指定されたコミットを直接参照します
     )。 これは ‘--candidates=0’ の同義語です。

‘--debug’
     標準エラーに、検索戦略に関する情報を詳細に表示します。タグ名は引き
     続き標準出力で印刷されます。

‘--long’
     タグと一致する場合でも、常に長い形式(タグとコミット数と省略されたコ
     ミット名)を出力します。 これは、問題のコミットがタグ付きバージョン
     である場合でも、 ‘describe’ 出力にコミットオブジェクト名の一部を表
     示する場合に役立ちます。 タグ名を発行するだけでなく、
     v1.2-0-gdeadbeeなどのコミットを記述します(オブジェクトdeadbeeを指す
     タグv1.2以降の0番目のコミット…)。

‘--match <pattern>’
     ‘refs/tags/’ プレフィックスを除いて、指定された glob(7) パターンに
     一致するタグのみを考慮してください。 ‘--all’ と一緒に使用すると、パ
     ターンに一致するローカルブランチとリモート追跡参照も考慮されます。
     ただし、それぞれ ‘refs/heads/’ と ‘refs/remotes/’ プレフィックスは
     除外されます。 他のタイプの参照は考慮されません。 複数回指定すると
     、パターンのリストが蓄積され、いずれかのパターンに一致するタグが考
     慮されます。 パターンのリストをクリアしてリセットするには、
     ‘--no-match’ を使用します。

‘--exclude <pattern>’
     ‘refs/tags/’ プレフィックスを除いて、指定された glob(7) パターンに
     一致するタグを考慮しないでください。 ‘--all’ と一緒に使用すると、そ
     れぞれ ‘refs/heads/’ と ‘refs/remotes/’ プレフィックスを除いて、パ
     ターンに一致するローカルブランチとリモート追跡参照も考慮されません
     。 他のタイプの参照は考慮されません。 複数回指定すると、パターンの
     リストが蓄積され、いずれかのパターンに一致するタグが除外されます。
     ‘--match’ と組み合わせると、タグが少なくとも1つの ‘--match’ パター
     ンに一致し、 ‘-exclude’ パターンのいずれにも一致しない場合にタグが
     考慮されます。 パターンのリストをクリアしてリセットするには、
     ‘--no-exclude’ を使用します。

‘--always’
     ユニークさを保ちつつ省略されたコミットオブジェクトをフォールバック
     として表示します。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを追跡します。 これ
     は、ターゲットコミットの履歴でマージされたブランチのタグを一致させ
     たくない場合に役立ちます。

EXAMPLES
********

git.gitのツリーのようなナニカなら、以下のようなものを得るでしょう:

     [torvalds@g5 git]$ git describe parent
     v1.0.4-14-g2414721

   つまり、私の「親」ブランチの現在のヘッドはv1.0.4に基づいていますが、
その上にいくつかのコミットがあるため、describeは、追加のコミットの数
(‘14’)と、コミット自体の省略されたオブジェクト名(‘2414721’)を最後に追加
しました。

   追加のコミットの数は、 ‘git log v1.0.4..parent’ によって表示されるコ
ミットの数です。 ハッシュ接尾辞は ‘-g’ 親の先端コミットの明確な略語です
(これは ‘2414721b194453f058079d897d13c4e377f92dc6’ でした)。 省略形の長
さは、リポジトリ内のオブジェクトのおおよその数と、誕生日のパラドックスに
関する少しの計算を使用して、リポジトリが大きくなるにつれてスケーリングさ
れ、デフォルトでは最小7になります。 ‘g’ プレフィックスは ‘git’ を表し、
ソフトウェアが管理されているSCMに応じてソフトウェアのバージョンを記述で
きるようにするために使用されます。 これは、人々がさまざまなSCMを使用する
可能性がある環境で役立ちます。

   タグ名に対して ‘git describe’ を実行すると、タグ名が表示されるだけで
す:

     [torvalds@g5 git]$ git describe v1.0.4
     v1.0.4

   ‘--all’ を使用すると、コマンドはブランチヘッドを参照として使用できる
ため、出力には参照パスも表示されます:

     [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
     tags/v1.0.0-21-g975b

     [torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^
     heads/lt/describe-7-g975b

   ‘–abbrev‘を0に設定すると、このコマンドを使用して、接尾辞(suffix)なし
で最も近いタグ名を見つけることができます:

     [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
     tags/v1.0.0

   注意: 今、これらのコマンドを入力した場合に取得するサフィックスは、か
つてLinusがこれらのコマンドを実行したときに上記で見たものよりも長くなる
可能性があることに注意してください。Gitリポジトリには、オブジェクト名が
975bで始まり、当時は存在しなかった新しいコミットが含まれている可能性があ
ります。 ‘-g975b’ サフィックスだけでは、これらのコミットを明確にするのに
十分でない場合があります。

SEARCH STRATEGY
***************

提供されたコミットっぽいのごとに、 ‘git describe’ は最初にそのコミットを
正確にタグ付けするタグを探します。 注釈付きタグは常に軽量タグよりも優先
され、新しい日付のタグは常に古い日付のタグよりも優先されます。 完全に一
致するものが見つかると、その名前が出力され、検索が停止します。

   完全に一致するものが見つからなかった場合、 ‘git describe’ はコミット
履歴をさかのぼって、タグ付けされた祖先コミットを見つけます。 祖先のタグ
は、入力したコミットっぽい何かのSHA-1の省略形とともに出力されます。
‘--first-parent’ が指定された場合、ウォークは各コミットの最初の親のみを
考慮します。

   ウォーク中に複数のタグが見つかった場合は、入力コミットっぽい何かとは
異なるコミットが最も少ないタグが選択されて出力されます。 ここで異なるコ
ミットの数は、 ‘git log tag..input’ で示されるコミットの数として定義され
、可能な限り最小のコミット数になります。

BUGS
****

ツリーオブジェクト、およびコミットを指していないタグオブジェクトは表わせ
ません。 ブロブを表す場合、ブロブを指す軽量タグは無視されますが、軽量タ
グが有利であるにもかかわらず、ブロブは依然として <committ-ish>:<path> と
して表されます。

GIT
***

Part of the git(1) suite

Name
****

git-diff-files — 作業ツリーとインデックス内のファイルを比較します

Synopsis
********

     git diff-files [-q] [-0|-1|-2|-3|-c|–cc] [<common diff options>] [<path>…]

DESCRIPTION
***********

作業ツリーとインデックス内のファイルを比較します。パスが指定されている場
合、それらの名前付きパスのみを比較します。それ以外の場合は、インデックス
内のすべてのエントリが比較されます。出力形式は、 _git diff-index_ や
_git diff-tree_ の場合と同じです。

OPTIONS
*******

‘-p’
‘-u’
‘--patch’
     パッチを生成します(generating patches に関するセクションを参照)。

‘-s’
‘--no-patch’
     diff出力を抑制します。デフォルトでパッチを表示する ‘git show’ のよ
     うなコマンド、または ‘--patch’ の効果をキャンセルする場合に便利です
     。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。 ‘--patch’ の機
     能を含んでいます。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--raw’
     生形式(raw format)でdiffを生成します。 これがデフォルトです。

‘--patch-with-raw’
     ‘-p --raw’ の同義語。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--patch-with-stat’
     ‘-p --stat’ と同義語。

‘-z’
     ‘--raw’ または ‘--numstat’ または ‘--name-only’ または
     ‘--name-status’ が指定されている場合は パス名を変更せず、出力フィー
     ルドターミネータとしてNULLを使用してください。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、 通常の文字以外(unusual characters)を含むパス名が引用符で囲
     まれます(git-config(1) 参照)。

‘--name-only’
     変更されたファイルの名前のみを表示します。 多くの場合、ファイル名は
     UTF-8でエンコードされます。 詳細については、 git-log(1) のマニュア
     ルページにあるエンコーディングに関する議論(the discussion about
     encoding)を参照してください。

‘--name-status’
     変更されたファイルの名前とステータスのみを表示します。ステータス文
     字の意味については、 ‘--diff-filter’ オプションの説明を参照してくだ
     さい。 ‘--name-only’ と同じように、ファイル名はしばしばUTF-8でエン
     コードされます。

‘--submodule[=<format>]’
     サブモジュールの違いをどのように表示するかを指定します。
     ‘--submodule=short’ を指定する場合、 short形式が使用されます。この
     形式は、範囲の最初と最後にコミットの名前を表示するだけです。
     ‘--submodule’ または ‘--submodule=log’ が指定されている場合、 log形
     式が使用されます。この形式では、 git-submodule(1) ‘summary’ のよう
     に範囲内のコミットが一覧表示されます。 ‘--submodule=diff’ が指定さ
     れている場合、 diff形式が使用されます。この形式は、コミット範囲間の
     サブモジュールの内容の変更のインラインdiffを示します。configオプシ
     ョンが設定されていない場合、デフォルトは ‘diff.submodule’ または
     ‘short’ 形式です。

‘--color[=<when>]’
     色付きのdiffを表示します。 ‘--color’ (つまり、 ‘=<when>’ 無し) は
     ‘--color=always’ と同じです。 <when> は、 always または never また
     は auto のいずれかになります。

‘--no-color’
     カラーdiffをオフにします。 ‘--color=never’ と同じです。

‘--color-moved[=<mode>]’
     ソースコードの移動した行を別の色にします。 <mode>は、オプションが指
     定されていない場合はデフォルトで no になり、 モードが指定されていな
     いオプションが指定されている場合は zebra になります。 モードは以下
     のいずれかでなければなりません:

     no
          移動行をハイライトしません。

     default
          zebra の同義語です。これは、将来、より賢明なモードに変更される
          可能性があります。

     plain
          ある場所で追加され、別の場所で削除された行は、
          ‘color.diff.newMoved’ で色付けされます。 同様に、
          ‘color.diff.oldMoved’ は、差分の別の場所に追加された削除された
          行に使用されます。このモードは移動された行をピックアップします
          が、コードのブロックが順列なしで移動されたかどうかを判断するこ
          とはレビューではあまり役に立ちません。

     blocks
          少なくとも20文字の英数字の移動テキストのブロックが貪欲に検出さ
          れます。検出されたブロックは、 ‘color.diff.{old,new}Moved’ 色
          のいずれかを使用して色付けされます。隣接するブロックを区別する
          ことはできません。

     zebra
          移動されたテキストのブロックは、 _blocks_ モードの場合と同様に
          検出されます。 ブロックは、 _color.diff.{old,new}Moved_ 色また
          は _color.diff.{old,new}MovedAlternative_ 色のいずれかを使用し
          て色付けされます。2つの色の間の変化は、新しいブロックが検出さ
          れたことを示します。

     dimmed-zebra
          _zebra_ に似ていますが、移動されたコードの重要でない部分の追加
          の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は
          興味深いと見なされ、残りは興味深いものではありません。
          ‘dimmed_zebra’ は非推奨の同義語です。

‘--no-color-moved’
     移動検出をオフにします。 これは、構成設定を上書きするために使用でき
     ます。 ‘--color-moved=no’ と同じです。

‘--color-moved-ws=<modes>’
     これは、 ‘--color-moved’ の移動検出を実行するときに空白を無視する方
     法を設定します。 これらのモードは、コンマ区切りのリストとして指定で
     きます:

     no
          移動行検出を実行するときに、空白(whitespace)を無視しない。

     ignore-space-at-eol
          行末(EOL)での空白(whitespace)の変更を無視します。

     ignore-space-change
          空白(whitespace)の数の変更は無視してください。これは、行末の空
          白(whitespace)を無視し、1つ以上の空白文字(whitespace
          characters)の他のすべてのシーケンスを同等と見なします。

     ignore-all-space
          行を比較するときは空白(whitespace)を無視します。これにより、一
          方の行に空白があり、もう一方の行に空白がない場合でも、違いは無
          視されます。

     allow-indentation-change
          最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変
          更が行ごとに同じである場合にのみ、移動されたコードブロックをブ
          ロックにグループ化します。 これは他のモードと互換性がありませ
          ん。

‘--no-color-moved-ws’
     移動検出を実行するときは、空白(whitespace)を無視しないでください。
     これは、構成設定を上書きするために使用できます。
     ‘--color-moved-ws=no’ と同じです。

‘--word-diff[=<mode>]’
     <mode> を使用して変更された単語を区切ることにより、単語のdiffを表示
     します。デフォルトでは、単語は空白で区切られます。 以下の
     ‘--word-diff-regex’ を参照してください。 <mode> のデフォルトは
     ’plain’です。 <mode> は以下のいずれかである必要があります:

     color
          変更された単語(word)を色のみを使用して強調表示します。
          ‘--color’ を意味します。

     plain
          単語を ‘[-removed-]’ および ‘{+added+}’ として表示します。 区
          切り文字が入力に表示されている場合、区切り文字をエスケープしよ
          うとしないため、出力があいまいになる可能性があります。

     porcelain
          スクリプトの使用を目的とした特別な行ベースの形式を使用します。
          追加/削除/無変更については、通常の統一されたdiff形式で印刷され
          、行の先頭の ‘+’/‘-’/‘ ‘ 文字で始まり、行の終わりまで続きます
          。入力の改行は、それ自体の行のチルダ ‘~’ で表されます。

     none
          単語(word)のdiffを再度無効にします。

     注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべ
     てのモードで変更された部分を強調するために色が使用されることに注意
     してください。

‘--word-diff-regex=<regex>’
     空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるか
     を決定します。また、すでに有効になっていない限り、この機能は
     ‘--word-diff’ の機能を含んでいます。

     <regex> の重複しないマッチはすべて、単語と見なされます。これらのマ
     ッチの間のすべては空白と見なされ、違いを見つけるためとしては無視さ
     れます！ 正規表現に ‘|[^[:space:]]’ を追加して、空白以外のすべての
     文字とマッチすることを確認することをお勧めします。改行を含むマッチ
     は、改行で黙って切り捨てられます！

     たとえば、 ‘--word-diff-regex=.’ は各文字を単語として扱い、それに応
     じて文字ごとの違いを表示します。

     正規表現は、diffドライバーまたは構成オプション(configuration
     option)を介して設定することもできます。 gitattributes(5) または
     git-config(1) を参照してください。これを指定すると、diffドライバー
     または構成設定(configuration settings)が明示的にオーバーライドされ
     ます。diffドライバーは構成設定を上書きします。

‘--color-words[=<regex>]’
     ‘--word-diff=color’ に ‘--word-diff-regex=<regex>’ を加えたものに相
     当します(正規表現が指定されている場合)。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--check’
     変更によって競合マーカーまたは空白エラーが発生した場合に警告します
     。空白エラーと見なされるものは、 ‘core.whitespace’ 構成によって制御
     されます。 デフォルトでは、末尾の空白(空白のみで構成される行を含む
     )と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空
     白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータ
     スで終了します。なお、 –exit-code とは互換性がありません。

‘--ws-error-highlight=<kind>’
     diffの ‘context’ または ‘old’ または ‘new’ 行の空白エラーを強調表示
     します。複数の値はコンマで区切られ、 ‘none’ は前の値をリセットし、
     ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は old、new、
     context の省略形です。このオプションが指定されておらず、構成変数
     ‘diff.wsErrorHighlight’ が設定されていない場合、 ‘new’ 行の空白エラ
     ーのみが強調表示されます。空白エラーは ‘color.diff.whitespace’ で色
     分けされています。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。 ‘--patch’ の機能を含んでいます。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     名前の変更(renames)を検知する。 ‘n’ が指定されている場合、それは類
     似性インデックスのしきい値です (つまり、ファイルのサイズと比較した
     追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以上が変更され
     ていない場合、 Gitが削除/追加のペアを名前変更と見なす必要があること
     を意味します。 ‘%’ 記号がない場合、数値は小数として読み取られ、その
     前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、‘-M50%’ と同
     じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検出を正確な
     名前変更に制限するには、 ‘-M100%’ を使用します。 デフォルトの類似性
     インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]’
     追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更
     (Rename)されたファイル、タイプが変更されたファイル(T)、マージされて
     いないファイル(U)、不明なファイル(X)、またはペアリングが壊れている
     ファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合
     わせを使用できます。 組み合わせに ‘*’ (全てまたは無し)が追加される
     と、比較で他の基準に一致するファイルがある場合、すべてのパスが選択
     されます。 他の基準に一致するファイルがない場合、何も選択されません
     。

     また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定し
     ます。例えば ‘--diff-filter=ad’ は、追加および削除されたパスを除外
     します。

     注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意
     してください。 たとえば、インデックスから作業ツリーへのdiffにエント
     リを追加することはできません(diffに含まれるパスのセットは、インデッ
     クスの内容によって制限されるため)。 同様に、これらのタイプの検出が
     無効になっている場合、コピーおよび名前変更されたエントリは表示され
     ません。

‘-S<string>’
     ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の
     差分を調べます。スクリプターが使用することを目的としています。

     (構造体など)コードの正確なブロックを探していて、そのブロックが最初
     に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し
     使用して、プリイメージ(preimage)内の興味深いブロックを ‘-S’ にフィ
     ードバックし、そしてあなたはそれをブロックの最初のバージョンを取得
     するまで続けます。

     バイナリファイルも検索されます。

‘-G<regex>’
     パッチテキストに <regex> にマッチする 追加/削除 された行が含まれて
     いる差分を探します。

     ‘-S<regex> --pickaxe-regex’ と ‘-G<regex>’ の違いを説明するために、
     同じファイル内で以下のdiffを使用してコミットすることを検討してくだ
     さい:

          +    return frotz(nitfol, two->ptr, 1, 0);
          ...
          -    hit = frotz(nitfol, mf2.ptr, 1, 0);

     ‘git log -G"frotz\(nitfol"’ はこのコミットを表示しますが、 ‘git log
     -S"frotz\(nitfol" --pickaxe-regex’ は表示しません(その文字列の出現
     回数が変更されなかったため)。

     ‘--text’ が提供されていない限り、 textconv フィルターのないバイナリ
     ファイルのパッチは無視されます。

     詳細については gitdiffcore(7) の「pickaxe」エントリを参照してくださ
     い。

‘--find-object=<object-id>’
     指定されたオブジェクトの出現回数を変更する違いを探します。 ‘-S’ と
     同様に、引数だけが異なり、特定の文字列ではなく特定のオブジェクト
     IDを検索します。

     オブジェクトは、ブロブまたはサブモジュールのコミットにすることがで
     きます。 これは、 ‘git-log’ の ‘-t’ オプションがツリーも探すことを
     意味します。

‘--pickaxe-all’
     ‘-S’ または ‘-G’ が変更を見つけたら、 <string> の変更を含むファイル
     だけでなく、その変更セット(changeset)のすべての変更を表示します。

‘--pickaxe-regex’
     ‘-S’ に指定した <string> を拡張POSIX正規表現として扱います。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘-R’
     2つの入力を交換します。 つまり、インデックスまたはディスク上のファ
     イルとツリーの内容の違いを表示します。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--exit-code’
     diff(1）と同様のコードでプログラムを終了させます。つまり、違いがあ
     った場合は 1 で終了し、 0 は違いがないことを意味します。

‘--quiet’
     プログラムのすべての出力を無効にします。 ‘--exit-code’ を意味します
     。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

‘-1 --base’
‘-2 --ours’
‘-3 --theirs’
‘-0’
     "base" バージョン または "our branch" または "their branch" とそれ
     ぞれ異なります。これらのオプションを使用すると、マージされたエント
     リのdiffは表示されません。

     デフォルトでは、 our branch (-2) とクリーンに解決されたパスに対して
     diffを取ります。オプション -0 を指定すると、マージされていないエン
     トリのdiff出力を省略し、 "Unmerged" と表示することができます。

‘-c’
‘--cc’
     これは、ステージ2（ブランチ）、ステージ3（ブランチ）、および作業ツ
     リーファイルを比較し、 _diff-tree_ がこれらのフラグを使用してマージ
     コミットを示すのと同様に、結合された差分を出力します。

‘-q’
     存在しないファイルでも黙っています

Raw output format
*****************

‘git-diff-index’ と ‘git-diff-tree’ と ‘git-diff-files’ と ‘git diff
--raw’ からの生の出力形式は非常に似ています。

   これらのコマンドはすべて、2つのセットを比較します。なお、比較されるも
のは異なります:

git-diff-index <tree-ish>
     <tree-ish> とファイルシステム上のファイルを比較します。

git-diff-index –cached <tree-ish>
     <tree-ish> とインデックスを比較します。

git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…]
     2つの引数で指定されたツリーを比較します。

git-diff-files [<pattern>…]
     インデックスとファイルシステム上のファイルを比較します。

   "git-diff-tree" コマンドは、比較対象のハッシュ値を出力することで出力
を開始します。その後、すべてのコマンドは、変更されたファイルごとに1つの
出力行を出力します。

   出力行は以下のようにフォーマットされます:

     in-place edit  :100644 100644 bcd1234 0123456 M file0
     copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2
     rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3
     create         :000000 100644 0000000 1234567 A file4
     delete         :100644 000000 1234567 0000000 D file5
     unmerged       :000000 000000 0000000 0000000 U file6

   つまり、左から右へ:

  1. コロン(:)

  2. "src" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  3. 空白

  4. "dst" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  5. 空白

  6. "src" のsha1。作成(creation)またはマージされていない(unmerged)場合
     は 0{40}

  7. 空白

  8. "dst" のsha1。作成(creation)またはマージされていない(unmerged)また
     は作業ツリーにある場合は 0{40}

  9. 空白

  10. ステータスの後に、オプションの「スコア数」("score" number)が続きま
     す

  11. ‘-z’ オプションが使用されている場合はタブまたはNUL

  12. "src" のパス

  13. ‘-z’ オプションが使用されている場合タブまたはNUL。ステータスCまた
     はRにのみ存在します

  14. "dst" のパス。ステータスCまたはRにのみ存在します

  15. LFでレコードを終了します。 ‘-z’ オプションが使用されている場合は
     NULでレコードを終了します。

   ステータス文字の種類は以下のとおり:

   • A: ファイルの追加

   • C: ファイルを新しいファイルにコピー

   • D: ファイルの削除

   • M: ファイルの内容やモードの変更

   • R: ファイル名の名前変更

   • T: ファイルのタイプを変更

   • U: ファイルはマージされていません(コミットする前にマージを完了する
     必要があります)

   • X: 「不明な」変更タイプ(おそらくバグです。報告してください)

   ステータス文字CとRの後には常にスコアが続きます(移動またはコピーのソー
スとターゲットの間の類似性のパーセンテージを示します)。ステータス文字Mの
後には、ファイルの書き換えのスコア(非類似度のパーセンテージを示す)が続く
場合があります。

   <sha1> は、ファイルがファイルシステム上で新規で、インデックスと同期し
ていない場合、すべて0として表示されます。

   例:

     :100644 100644 5be4a4a 0000000 M file.c

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、通常の文字以外(unusual characters)を含むパス名が引用符で囲
まれます(git-config(1) 参照)。 ‘-z’ を使用すると、ファイル名がそのまま出
力され、行はNULバイトで終了します。

diff format for merges
**********************

"git-diff-tree" と "git-diff-files" と "git-diff –raw" は、 ‘-c’ または
‘--cc’ オプションを使用して、マージコミットに対してもdiff出力を生成でき
ます。出力は、以下の点で上記の形式とは異なります:

  1. 親ごとにコロン(:)があります

  2. より多くの "src" モードと "src" sha1があります

  3. statusは、各親のステータス文字を連結したものです

  4. オプションの「スコア数」はありません

  5. ファイルのタブ区切りのパス名

   ‘-c’ および ‘ -cc‘ の場合、履歴のいずれかの側でファイルの名前が変更さ
れた場合でも、宛先(dst)または最終パスのみが表示されます。
‘--combined-all-paths’ を使用すると、各親のパスの名前が表示され、それに
続いてマージコミットのパスの名前が表示されます。

   例: ‘--combined-all-paths’ を使用しない ‘-c’ および ‘--cc’ の場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       phooey.c

   例: ‘-c’ または ‘--cc’ のいずれかに ‘--combined-all-paths’ が追加され
た場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c  desc.c  desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       foo.sh  bar.sh  bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       fooey.c fuey.c  phooey.c

   注意: ’combined diff’は、すべての親から変更されたファイルのみをリスト
することに注意してください。

Generating patch text with -p
*****************************

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、
git-diff-tree(1) 、 git-diff-files(1) に ‘-p’ オプションを付けて実行する
とパッチテキストを生成します。パッチテキストの作成は、
‘GIT_EXTERNAL_DIFF’ と ‘GIT_DIFF_OPTS’ 環境変数( git(1) 参照)、および
‘diff’ 属性( gitattributes(5) 参照)を介してカスタマイズできます。

   -pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります:

          diff --git a/file1 b/file2

     名前の変更/コピーが含まれない限り、 ‘a/’ と ‘b/’ のファイル名は同じ
     です。 特に、作成または削除の場合でも、 ‘a/’ または ‘b/’ ファイル名
     の代わりに ‘/dev/ null’ が使用されることはありません。

     名前変更/コピーが含まれる場合、 ‘file1’ と‘file2‘ は、それぞれ名前
     変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファ
     イルの名前を示します。

  2. その後に、1つ以上の拡張ヘッダー行達が続きます:

          old mode <mode>
          new mode <mode>
          deleted file mode <mode>
          new file mode <mode>
          copy from <path>
          copy to <path>
          rename from <path>
          rename to <path>
          similarity index <number>
          dissimilarity index <number>
          index <hash>..<hash> <mode>

     ファイルモードは、ファイルタイプとファイル許可ビットを含む6桁の8進
     数として出力されます。

     拡張ヘッダーのパス名には、 ‘a/’ および ‘b/’ プレフィックスは含まれ
     ません。

     類似インデックス(similarity index)は変更されていない行のパーセンテ
     ージであり、非類似インデックス(dissimilarity index)は変更された行の
     パーセンテージです。これは切り捨てられた整数であり、その後にパーセ
     ント記号が続きます。したがって、100％の類似インデックス値は2つの等
     しいファイルを表し、100％の非類似性は古いファイルから新しいファイル
     に移行された行がないことを意味します。

     インデックス行には、変更前後のブロブオブジェクト名が含まれます。
     <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の
     場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、
     構成変数 ‘core.quotePath’ で説明されているように引用符で囲まれてい
     ます( git-config(1)参照)。

  4. 出力内のすべての ‘file1’ ファイルはコミット前のファイルを参照し、す
     べての ‘file2’ ファイルはコミット後のファイルを参照します。各変更を
     各ファイルに順番に適用するのは誤りです。たとえば、以下のパッチはaと
     bを交換します:

          diff --git a/a b/b
          rename from a
          rename to b
          diff --git a/b b/a
          rename from b
          rename to a

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されていま
     す。特定の言語に合わせてこれを調整する方法の詳細については、
     gitattributes(5) の "Defining a custom hunk-header" を参照してくだ
     さい。

Combined diff format
********************

diffを生成するコマンドは、マージを表示するときに ‘-c’ または ‘--cc’ オプ
ションを使用して「合成diff」(combined diff)を生成できます。これは
git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形
式です。 注意: これらのコマンドのいずれかに適切な ‘--diff-merges’ オプシ
ョンを指定して、特定の形式で差分を強制的に生成できることにも注意してくだ
さい。

   合成diff形式は以下のようになります:

     diff --combined describe.c
     index fabadb8,cc95eb0..4866510
     --- a/describe.c
     +++ b/describe.c
     @@@ -98,20 -98,12 +98,20 @@@
             return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

     - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
     ++static void describe(char *arg, int last_one)
       {
      +      unsigned char sha1[20];
      +      struct commit *cmit;
             struct commit_list *list;
             static int initialized = 0;
             struct commit_name *n;

      +      if (get_sha1(arg, sha1) < 0)
      +              usage(describe_usage);
      +      cmit = lookup_commit_reference(sha1);
      +      if (!cmit)
      +              usage(describe_usage);
      +
             if (!initialized) {
                     initialized = 1;
                     for_each_ref(get_name);

  1. まず "git diff" ヘッダーがあり、以下のようになります( ‘-c’ オプショ
     ンが使用されている場合):

          diff --combined file

     または、以下のようになります( ‘--cc’ オプションが使用されている場合
     ):

          diff --cc file

  2. その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマ
     ージを示しています):

          index <hash>,<hash>..<hash>
          mode <mode>,<mode>..<mode>
          new file mode <mode>
          deleted file mode <mode>,<mode>

     ‘mode <mode>,<mode>..<mode>’ 行は、<mode> の少なくとも1つが他の
     <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動
     (名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの
     <tree-ish> のdiffで機能するように設計されており、合成diff形式では使
     用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます

          --- a/file
          +++ b/file

     従来の統一diff形式の2行ヘッダーと同様に、 ‘/dev/null’ は、作成また
     は削除されたファイルを通知するために使用されます。

     ただし、 –combined-all-paths オプションが指定されている場合、2行の
     from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダー
     が取得されます。ここで、 N はマージコミットの親の数です。

          --- a/file
          --- a/file
          --- a/file
          +++ b/file

     この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち
     、別の親のファイルの元の名前を確認できます。

  4. チャンクヘッダーの形式が変更され、誤って ‘patch-p1’ にフィードされ
     るのを防ぎます。合成差分形式は、マージコミットの変更を確認するため
     に作成されたものであり、適用されることを意図したものではありません
     。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:

          @@@ <from-file-range> <from-file-range> <to-file-range> @@@

     合成diff形式のチャンクヘッダーには親の数+1の ‘@’ 文字があります。

   従来の統一diff形式とは異なり、2つのファイルAとBが、 ‘-’ (マイナスは
Aに表示されますが、Bでは削除されます) または ‘+’ (プラスはAにはありませ
んが、Bには追加されます)、または ‘" "’（スペースは変更なし) プレフィック
スを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1,
file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示し
ます。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどの
ように異なるかを示します。

   列Nの ‘-’ 文字は、その行が fileN に表示されているが、結果には表示され
ていないことを意味します。 列Nの ‘+’ 文字は、結果に行が表示され、 fileN
にその行がないことを意味します(つまり、その親の観点から見て行が追加され
たことを示す)。

   上記の出力例では、関数のシグネチャが両方のファイルから見て変更されて
います(したがって、 file1 と file2 の両方から2つの ‘-’ が削除され、さら
に ‘++’ が追加されたため、 file1 と file2 のどちらにも表示されません)。
また、他の8行は file1 と同じですが、 file2 には表示されません(したがって
、接頭辞として ‘+’ が付けられます)。

   ‘git diff-tree -c’ で表示される場合、マージコミットの親をマージ結果と
比較します(つまり、 file1..fileN が親です)。 ‘git diff-files -c’ で表示
される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり
、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別
名「彼らのバージョン」です)。

other diff formats
******************

‘--summary’ オプションは、新しく追加、削除、名前変更、およびコピーされた
ファイルを説明します。‘--stat’ オプションは、 diffstat(1) グラフ を出力
に追加します。これらのオプションは、 ‘-p’ などの他のオプションと組み合わ
せることができ、人間が読むことを目的としています。

   名前の変更またはコピーを伴う変更を表示する場合、 ‘--stat’ 出力は、パ
ス名の共通のプレフィックスとサフィックスを組み合わせることにより、パス名
をコンパクトにフォーマットします。 たとえば、4行を変更(modify)しながら
‘arch/i386/Makefile’ を ‘arch/x86/Makefile’ に移動(move)する変更
(change)は、次のように表示されます:

     arch/{i386 => x86}/Makefile    |   4 +--

   ‘--numstat’ オプションは diffstat(1) 情報を提供しますが、人間ではなく
ソフトウェアで読むのを容易にするように設計されています。 ‘--numstat’ 出
力のエントリは以下のようになります:

     1       2       README
     3       1       arch/{i386 => x86}/Makefile

   この形式は、左から右へ:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. パス名(おそらく rename/copy 情報を含む)

  6. 改行

   ‘-z’ 出力オプションが有効な場合、出力は以下のようにフォーマットされま
す:

     1       2       README NUL
     3       1       NUL arch/i386/Makefile NUL arch/x86/Makefile NUL

   これは:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. NUL(rename/copy された場合のみ存在します)

  6. プリイメージのパス名

  7. NUL(rename/copy された場合のみ存在します)

  8. ポストイメージのパス名(rename/copy された場合のみ存在します)

  9. NUL

   名前が変更された場合のプリイメージパスの前の追加の ‘NUL’ は、出力を読
み取るスクリプトが、先読みせずに、読み取られている現在のレコードがシング
ルパスレコードであるか、名前変更/コピーレコードであるか、を判断できるよ
うにするためです。追加および削除された行を読み取った後、 ‘NUL’ まで読み
取るとパス名が生成されますが、それが ‘NUL’ の場合、レコードには2つのパス
が表示されます。

GIT
***

Part of the git(1) suite

Name
****

git-diff-index — ツリーを作業ツリーまたはインデックスと比較します

Synopsis
********

     git diff-index [-m] [–cached] [–merge-base] [<common diff options>] <tree-ish> [<path>…]

DESCRIPTION
***********

ツリーオブジェクトで見つかったブロブの内容とモードを、作業ツリー内の対応
する追跡中のファイルまたはインデックス内の対応するパスと比較します。
<path>引数が存在する場合、それらのパターンに一致するパスのみを比較します
。それ以外の場合は、追跡中のすべてのファイルが比較されます。

OPTIONS
*******

‘-p’
‘-u’
‘--patch’
     パッチを生成します(generating patches に関するセクションを参照)。

‘-s’
‘--no-patch’
     diff出力を抑制します。デフォルトでパッチを表示する ‘git show’ のよ
     うなコマンド、または ‘--patch’ の効果をキャンセルする場合に便利です
     。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。 ‘--patch’ の機
     能を含んでいます。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--raw’
     生形式(raw format)でdiffを生成します。 これがデフォルトです。

‘--patch-with-raw’
     ‘-p --raw’ の同義語。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--patch-with-stat’
     ‘-p --stat’ と同義語。

‘-z’
     ‘--raw’ または ‘--numstat’ または ‘--name-only’ または
     ‘--name-status’ が指定されている場合は パス名を変更せず、出力フィー
     ルドターミネータとしてNULLを使用してください。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、 通常の文字以外(unusual characters)を含むパス名が引用符で囲
     まれます(git-config(1) 参照)。

‘--name-only’
     変更されたファイルの名前のみを表示します。 多くの場合、ファイル名は
     UTF-8でエンコードされます。 詳細については、 git-log(1) のマニュア
     ルページにあるエンコーディングに関する議論(the discussion about
     encoding)を参照してください。

‘--name-status’
     変更されたファイルの名前とステータスのみを表示します。ステータス文
     字の意味については、 ‘--diff-filter’ オプションの説明を参照してくだ
     さい。 ‘--name-only’ と同じように、ファイル名はしばしばUTF-8でエン
     コードされます。

‘--submodule[=<format>]’
     サブモジュールの違いをどのように表示するかを指定します。
     ‘--submodule=short’ を指定する場合、 short形式が使用されます。この
     形式は、範囲の最初と最後にコミットの名前を表示するだけです。
     ‘--submodule’ または ‘--submodule=log’ が指定されている場合、 log形
     式が使用されます。この形式では、 git-submodule(1) ‘summary’ のよう
     に範囲内のコミットが一覧表示されます。 ‘--submodule=diff’ が指定さ
     れている場合、 diff形式が使用されます。この形式は、コミット範囲間の
     サブモジュールの内容の変更のインラインdiffを示します。configオプシ
     ョンが設定されていない場合、デフォルトは ‘diff.submodule’ または
     ‘short’ 形式です。

‘--color[=<when>]’
     色付きのdiffを表示します。 ‘--color’ (つまり、 ‘=<when>’ 無し) は
     ‘--color=always’ と同じです。 <when> は、 always または never また
     は auto のいずれかになります。

‘--no-color’
     カラーdiffをオフにします。 ‘--color=never’ と同じです。

‘--color-moved[=<mode>]’
     ソースコードの移動した行を別の色にします。 <mode>は、オプションが指
     定されていない場合はデフォルトで no になり、 モードが指定されていな
     いオプションが指定されている場合は zebra になります。 モードは以下
     のいずれかでなければなりません:

     no
          移動行をハイライトしません。

     default
          zebra の同義語です。これは、将来、より賢明なモードに変更される
          可能性があります。

     plain
          ある場所で追加され、別の場所で削除された行は、
          ‘color.diff.newMoved’ で色付けされます。 同様に、
          ‘color.diff.oldMoved’ は、差分の別の場所に追加された削除された
          行に使用されます。このモードは移動された行をピックアップします
          が、コードのブロックが順列なしで移動されたかどうかを判断するこ
          とはレビューではあまり役に立ちません。

     blocks
          少なくとも20文字の英数字の移動テキストのブロックが貪欲に検出さ
          れます。検出されたブロックは、 ‘color.diff.{old,new}Moved’ 色
          のいずれかを使用して色付けされます。隣接するブロックを区別する
          ことはできません。

     zebra
          移動されたテキストのブロックは、 _blocks_ モードの場合と同様に
          検出されます。 ブロックは、 _color.diff.{old,new}Moved_ 色また
          は _color.diff.{old,new}MovedAlternative_ 色のいずれかを使用し
          て色付けされます。2つの色の間の変化は、新しいブロックが検出さ
          れたことを示します。

     dimmed-zebra
          _zebra_ に似ていますが、移動されたコードの重要でない部分の追加
          の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は
          興味深いと見なされ、残りは興味深いものではありません。
          ‘dimmed_zebra’ は非推奨の同義語です。

‘--no-color-moved’
     移動検出をオフにします。 これは、構成設定を上書きするために使用でき
     ます。 ‘--color-moved=no’ と同じです。

‘--color-moved-ws=<modes>’
     これは、 ‘--color-moved’ の移動検出を実行するときに空白を無視する方
     法を設定します。 これらのモードは、コンマ区切りのリストとして指定で
     きます:

     no
          移動行検出を実行するときに、空白(whitespace)を無視しない。

     ignore-space-at-eol
          行末(EOL)での空白(whitespace)の変更を無視します。

     ignore-space-change
          空白(whitespace)の数の変更は無視してください。これは、行末の空
          白(whitespace)を無視し、1つ以上の空白文字(whitespace
          characters)の他のすべてのシーケンスを同等と見なします。

     ignore-all-space
          行を比較するときは空白(whitespace)を無視します。これにより、一
          方の行に空白があり、もう一方の行に空白がない場合でも、違いは無
          視されます。

     allow-indentation-change
          最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変
          更が行ごとに同じである場合にのみ、移動されたコードブロックをブ
          ロックにグループ化します。 これは他のモードと互換性がありませ
          ん。

‘--no-color-moved-ws’
     移動検出を実行するときは、空白(whitespace)を無視しないでください。
     これは、構成設定を上書きするために使用できます。
     ‘--color-moved-ws=no’ と同じです。

‘--word-diff[=<mode>]’
     <mode> を使用して変更された単語を区切ることにより、単語のdiffを表示
     します。デフォルトでは、単語は空白で区切られます。 以下の
     ‘--word-diff-regex’ を参照してください。 <mode> のデフォルトは
     ’plain’です。 <mode> は以下のいずれかである必要があります:

     color
          変更された単語(word)を色のみを使用して強調表示します。
          ‘--color’ を意味します。

     plain
          単語を ‘[-removed-]’ および ‘{+added+}’ として表示します。 区
          切り文字が入力に表示されている場合、区切り文字をエスケープしよ
          うとしないため、出力があいまいになる可能性があります。

     porcelain
          スクリプトの使用を目的とした特別な行ベースの形式を使用します。
          追加/削除/無変更については、通常の統一されたdiff形式で印刷され
          、行の先頭の ‘+’/‘-’/‘ ‘ 文字で始まり、行の終わりまで続きます
          。入力の改行は、それ自体の行のチルダ ‘~’ で表されます。

     none
          単語(word)のdiffを再度無効にします。

     注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべ
     てのモードで変更された部分を強調するために色が使用されることに注意
     してください。

‘--word-diff-regex=<regex>’
     空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるか
     を決定します。また、すでに有効になっていない限り、この機能は
     ‘--word-diff’ の機能を含んでいます。

     <regex> の重複しないマッチはすべて、単語と見なされます。これらのマ
     ッチの間のすべては空白と見なされ、違いを見つけるためとしては無視さ
     れます！ 正規表現に ‘|[^[:space:]]’ を追加して、空白以外のすべての
     文字とマッチすることを確認することをお勧めします。改行を含むマッチ
     は、改行で黙って切り捨てられます！

     たとえば、 ‘--word-diff-regex=.’ は各文字を単語として扱い、それに応
     じて文字ごとの違いを表示します。

     正規表現は、diffドライバーまたは構成オプション(configuration
     option)を介して設定することもできます。 gitattributes(5) または
     git-config(1) を参照してください。これを指定すると、diffドライバー
     または構成設定(configuration settings)が明示的にオーバーライドされ
     ます。diffドライバーは構成設定を上書きします。

‘--color-words[=<regex>]’
     ‘--word-diff=color’ に ‘--word-diff-regex=<regex>’ を加えたものに相
     当します(正規表現が指定されている場合)。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--check’
     変更によって競合マーカーまたは空白エラーが発生した場合に警告します
     。空白エラーと見なされるものは、 ‘core.whitespace’ 構成によって制御
     されます。 デフォルトでは、末尾の空白(空白のみで構成される行を含む
     )と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空
     白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータ
     スで終了します。なお、 –exit-code とは互換性がありません。

‘--ws-error-highlight=<kind>’
     diffの ‘context’ または ‘old’ または ‘new’ 行の空白エラーを強調表示
     します。複数の値はコンマで区切られ、 ‘none’ は前の値をリセットし、
     ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は old、new、
     context の省略形です。このオプションが指定されておらず、構成変数
     ‘diff.wsErrorHighlight’ が設定されていない場合、 ‘new’ 行の空白エラ
     ーのみが強調表示されます。空白エラーは ‘color.diff.whitespace’ で色
     分けされています。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。 ‘--patch’ の機能を含んでいます。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     名前の変更(renames)を検知する。 ‘n’ が指定されている場合、それは類
     似性インデックスのしきい値です (つまり、ファイルのサイズと比較した
     追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以上が変更され
     ていない場合、 Gitが削除/追加のペアを名前変更と見なす必要があること
     を意味します。 ‘%’ 記号がない場合、数値は小数として読み取られ、その
     前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、‘-M50%’ と同
     じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検出を正確な
     名前変更に制限するには、 ‘-M100%’ を使用します。 デフォルトの類似性
     インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]’
     追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更
     (Rename)されたファイル、タイプが変更されたファイル(T)、マージされて
     いないファイル(U)、不明なファイル(X)、またはペアリングが壊れている
     ファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合
     わせを使用できます。 組み合わせに ‘*’ (全てまたは無し)が追加される
     と、比較で他の基準に一致するファイルがある場合、すべてのパスが選択
     されます。 他の基準に一致するファイルがない場合、何も選択されません
     。

     また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定し
     ます。例えば ‘--diff-filter=ad’ は、追加および削除されたパスを除外
     します。

     注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意
     してください。 たとえば、インデックスから作業ツリーへのdiffにエント
     リを追加することはできません(diffに含まれるパスのセットは、インデッ
     クスの内容によって制限されるため)。 同様に、これらのタイプの検出が
     無効になっている場合、コピーおよび名前変更されたエントリは表示され
     ません。

‘-S<string>’
     ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の
     差分を調べます。スクリプターが使用することを目的としています。

     (構造体など)コードの正確なブロックを探していて、そのブロックが最初
     に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し
     使用して、プリイメージ(preimage)内の興味深いブロックを ‘-S’ にフィ
     ードバックし、そしてあなたはそれをブロックの最初のバージョンを取得
     するまで続けます。

     バイナリファイルも検索されます。

‘-G<regex>’
     パッチテキストに <regex> にマッチする 追加/削除 された行が含まれて
     いる差分を探します。

     ‘-S<regex> --pickaxe-regex’ と ‘-G<regex>’ の違いを説明するために、
     同じファイル内で以下のdiffを使用してコミットすることを検討してくだ
     さい:

          +    return frotz(nitfol, two->ptr, 1, 0);
          ...
          -    hit = frotz(nitfol, mf2.ptr, 1, 0);

     ‘git log -G"frotz\(nitfol"’ はこのコミットを表示しますが、 ‘git log
     -S"frotz\(nitfol" --pickaxe-regex’ は表示しません(その文字列の出現
     回数が変更されなかったため)。

     ‘--text’ が提供されていない限り、 textconv フィルターのないバイナリ
     ファイルのパッチは無視されます。

     詳細については gitdiffcore(7) の「pickaxe」エントリを参照してくださ
     い。

‘--find-object=<object-id>’
     指定されたオブジェクトの出現回数を変更する違いを探します。 ‘-S’ と
     同様に、引数だけが異なり、特定の文字列ではなく特定のオブジェクト
     IDを検索します。

     オブジェクトは、ブロブまたはサブモジュールのコミットにすることがで
     きます。 これは、 ‘git-log’ の ‘-t’ オプションがツリーも探すことを
     意味します。

‘--pickaxe-all’
     ‘-S’ または ‘-G’ が変更を見つけたら、 <string> の変更を含むファイル
     だけでなく、その変更セット(changeset)のすべての変更を表示します。

‘--pickaxe-regex’
     ‘-S’ に指定した <string> を拡張POSIX正規表現として扱います。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘-R’
     2つの入力を交換します。 つまり、インデックスまたはディスク上のファ
     イルとツリーの内容の違いを表示します。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--exit-code’
     diff(1）と同様のコードでプログラムを終了させます。つまり、違いがあ
     った場合は 1 で終了し、 0 は違いがないことを意味します。

‘--quiet’
     プログラムのすべての出力を無効にします。 ‘--exit-code’ を意味します
     。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

<tree-ish>
     diffするツリーオブジェクトのID。

‘--cached’
     ディスク上のファイルはまったく考慮しないでください。

‘--merge-base’
     <tree-ish>を直接比較する代わりに、<tree-ish>とHEADの間のマージベー
     スを使用してください。 <tree-ish>はコミットでなければなりません。

‘-m’
     デフォルトでは、インデックスに記録されているがチェックアウトされて
     いないファイルは削除済みとして報告されます。このフラグにより、 ‘git
     diff-index’ はチェックアウトされていないファイルは全て最新とします
     。

Raw output format
*****************

‘git-diff-index’ と ‘git-diff-tree’ と ‘git-diff-files’ と ‘git diff
--raw’ からの生の出力形式は非常に似ています。

   これらのコマンドはすべて、2つのセットを比較します。なお、比較されるも
のは異なります:

git-diff-index <tree-ish>
     <tree-ish> とファイルシステム上のファイルを比較します。

git-diff-index –cached <tree-ish>
     <tree-ish> とインデックスを比較します。

git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…]
     2つの引数で指定されたツリーを比較します。

git-diff-files [<pattern>…]
     インデックスとファイルシステム上のファイルを比較します。

   "git-diff-tree" コマンドは、比較対象のハッシュ値を出力することで出力
を開始します。その後、すべてのコマンドは、変更されたファイルごとに1つの
出力行を出力します。

   出力行は以下のようにフォーマットされます:

     in-place edit  :100644 100644 bcd1234 0123456 M file0
     copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2
     rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3
     create         :000000 100644 0000000 1234567 A file4
     delete         :100644 000000 1234567 0000000 D file5
     unmerged       :000000 000000 0000000 0000000 U file6

   つまり、左から右へ:

  1. コロン(:)

  2. "src" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  3. 空白

  4. "dst" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  5. 空白

  6. "src" のsha1。作成(creation)またはマージされていない(unmerged)場合
     は 0{40}

  7. 空白

  8. "dst" のsha1。作成(creation)またはマージされていない(unmerged)また
     は作業ツリーにある場合は 0{40}

  9. 空白

  10. ステータスの後に、オプションの「スコア数」("score" number)が続きま
     す

  11. ‘-z’ オプションが使用されている場合はタブまたはNUL

  12. "src" のパス

  13. ‘-z’ オプションが使用されている場合タブまたはNUL。ステータスCまた
     はRにのみ存在します

  14. "dst" のパス。ステータスCまたはRにのみ存在します

  15. LFでレコードを終了します。 ‘-z’ オプションが使用されている場合は
     NULでレコードを終了します。

   ステータス文字の種類は以下のとおり:

   • A: ファイルの追加

   • C: ファイルを新しいファイルにコピー

   • D: ファイルの削除

   • M: ファイルの内容やモードの変更

   • R: ファイル名の名前変更

   • T: ファイルのタイプを変更

   • U: ファイルはマージされていません(コミットする前にマージを完了する
     必要があります)

   • X: 「不明な」変更タイプ(おそらくバグです。報告してください)

   ステータス文字CとRの後には常にスコアが続きます(移動またはコピーのソー
スとターゲットの間の類似性のパーセンテージを示します)。ステータス文字Mの
後には、ファイルの書き換えのスコア(非類似度のパーセンテージを示す)が続く
場合があります。

   <sha1> は、ファイルがファイルシステム上で新規で、インデックスと同期し
ていない場合、すべて0として表示されます。

   例:

     :100644 100644 5be4a4a 0000000 M file.c

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、通常の文字以外(unusual characters)を含むパス名が引用符で囲
まれます(git-config(1) 参照)。 ‘-z’ を使用すると、ファイル名がそのまま出
力され、行はNULバイトで終了します。

diff format for merges
**********************

"git-diff-tree" と "git-diff-files" と "git-diff –raw" は、 ‘-c’ または
‘--cc’ オプションを使用して、マージコミットに対してもdiff出力を生成でき
ます。出力は、以下の点で上記の形式とは異なります:

  1. 親ごとにコロン(:)があります

  2. より多くの "src" モードと "src" sha1があります

  3. statusは、各親のステータス文字を連結したものです

  4. オプションの「スコア数」はありません

  5. ファイルのタブ区切りのパス名

   ‘-c’ および ‘ -cc‘ の場合、履歴のいずれかの側でファイルの名前が変更さ
れた場合でも、宛先(dst)または最終パスのみが表示されます。
‘--combined-all-paths’ を使用すると、各親のパスの名前が表示され、それに
続いてマージコミットのパスの名前が表示されます。

   例: ‘--combined-all-paths’ を使用しない ‘-c’ および ‘--cc’ の場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       phooey.c

   例: ‘-c’ または ‘--cc’ のいずれかに ‘--combined-all-paths’ が追加され
た場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c  desc.c  desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       foo.sh  bar.sh  bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       fooey.c fuey.c  phooey.c

   注意: ’combined diff’は、すべての親から変更されたファイルのみをリスト
することに注意してください。

Generating patch text with -p
*****************************

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、
git-diff-tree(1) 、 git-diff-files(1) に ‘-p’ オプションを付けて実行する
とパッチテキストを生成します。パッチテキストの作成は、
‘GIT_EXTERNAL_DIFF’ と ‘GIT_DIFF_OPTS’ 環境変数( git(1) 参照)、および
‘diff’ 属性( gitattributes(5) 参照)を介してカスタマイズできます。

   -pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります:

          diff --git a/file1 b/file2

     名前の変更/コピーが含まれない限り、 ‘a/’ と ‘b/’ のファイル名は同じ
     です。 特に、作成または削除の場合でも、 ‘a/’ または ‘b/’ ファイル名
     の代わりに ‘/dev/ null’ が使用されることはありません。

     名前変更/コピーが含まれる場合、 ‘file1’ と‘file2‘ は、それぞれ名前
     変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファ
     イルの名前を示します。

  2. その後に、1つ以上の拡張ヘッダー行達が続きます:

          old mode <mode>
          new mode <mode>
          deleted file mode <mode>
          new file mode <mode>
          copy from <path>
          copy to <path>
          rename from <path>
          rename to <path>
          similarity index <number>
          dissimilarity index <number>
          index <hash>..<hash> <mode>

     ファイルモードは、ファイルタイプとファイル許可ビットを含む6桁の8進
     数として出力されます。

     拡張ヘッダーのパス名には、 ‘a/’ および ‘b/’ プレフィックスは含まれ
     ません。

     類似インデックス(similarity index)は変更されていない行のパーセンテ
     ージであり、非類似インデックス(dissimilarity index)は変更された行の
     パーセンテージです。これは切り捨てられた整数であり、その後にパーセ
     ント記号が続きます。したがって、100％の類似インデックス値は2つの等
     しいファイルを表し、100％の非類似性は古いファイルから新しいファイル
     に移行された行がないことを意味します。

     インデックス行には、変更前後のブロブオブジェクト名が含まれます。
     <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の
     場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、
     構成変数 ‘core.quotePath’ で説明されているように引用符で囲まれてい
     ます( git-config(1)参照)。

  4. 出力内のすべての ‘file1’ ファイルはコミット前のファイルを参照し、す
     べての ‘file2’ ファイルはコミット後のファイルを参照します。各変更を
     各ファイルに順番に適用するのは誤りです。たとえば、以下のパッチはaと
     bを交換します:

          diff --git a/a b/b
          rename from a
          rename to b
          diff --git a/b b/a
          rename from b
          rename to a

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されていま
     す。特定の言語に合わせてこれを調整する方法の詳細については、
     gitattributes(5) の "Defining a custom hunk-header" を参照してくだ
     さい。

Combined diff format
********************

diffを生成するコマンドは、マージを表示するときに ‘-c’ または ‘--cc’ オプ
ションを使用して「合成diff」(combined diff)を生成できます。これは
git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形
式です。 注意: これらのコマンドのいずれかに適切な ‘--diff-merges’ オプシ
ョンを指定して、特定の形式で差分を強制的に生成できることにも注意してくだ
さい。

   合成diff形式は以下のようになります:

     diff --combined describe.c
     index fabadb8,cc95eb0..4866510
     --- a/describe.c
     +++ b/describe.c
     @@@ -98,20 -98,12 +98,20 @@@
             return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

     - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
     ++static void describe(char *arg, int last_one)
       {
      +      unsigned char sha1[20];
      +      struct commit *cmit;
             struct commit_list *list;
             static int initialized = 0;
             struct commit_name *n;

      +      if (get_sha1(arg, sha1) < 0)
      +              usage(describe_usage);
      +      cmit = lookup_commit_reference(sha1);
      +      if (!cmit)
      +              usage(describe_usage);
      +
             if (!initialized) {
                     initialized = 1;
                     for_each_ref(get_name);

  1. まず "git diff" ヘッダーがあり、以下のようになります( ‘-c’ オプショ
     ンが使用されている場合):

          diff --combined file

     または、以下のようになります( ‘--cc’ オプションが使用されている場合
     ):

          diff --cc file

  2. その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマ
     ージを示しています):

          index <hash>,<hash>..<hash>
          mode <mode>,<mode>..<mode>
          new file mode <mode>
          deleted file mode <mode>,<mode>

     ‘mode <mode>,<mode>..<mode>’ 行は、<mode> の少なくとも1つが他の
     <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動
     (名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの
     <tree-ish> のdiffで機能するように設計されており、合成diff形式では使
     用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます

          --- a/file
          +++ b/file

     従来の統一diff形式の2行ヘッダーと同様に、 ‘/dev/null’ は、作成また
     は削除されたファイルを通知するために使用されます。

     ただし、 –combined-all-paths オプションが指定されている場合、2行の
     from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダー
     が取得されます。ここで、 N はマージコミットの親の数です。

          --- a/file
          --- a/file
          --- a/file
          +++ b/file

     この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち
     、別の親のファイルの元の名前を確認できます。

  4. チャンクヘッダーの形式が変更され、誤って ‘patch-p1’ にフィードされ
     るのを防ぎます。合成差分形式は、マージコミットの変更を確認するため
     に作成されたものであり、適用されることを意図したものではありません
     。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:

          @@@ <from-file-range> <from-file-range> <to-file-range> @@@

     合成diff形式のチャンクヘッダーには親の数+1の ‘@’ 文字があります。

   従来の統一diff形式とは異なり、2つのファイルAとBが、 ‘-’ (マイナスは
Aに表示されますが、Bでは削除されます) または ‘+’ (プラスはAにはありませ
んが、Bには追加されます)、または ‘" "’（スペースは変更なし) プレフィック
スを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1,
file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示し
ます。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどの
ように異なるかを示します。

   列Nの ‘-’ 文字は、その行が fileN に表示されているが、結果には表示され
ていないことを意味します。 列Nの ‘+’ 文字は、結果に行が表示され、 fileN
にその行がないことを意味します(つまり、その親の観点から見て行が追加され
たことを示す)。

   上記の出力例では、関数のシグネチャが両方のファイルから見て変更されて
います(したがって、 file1 と file2 の両方から2つの ‘-’ が削除され、さら
に ‘++’ が追加されたため、 file1 と file2 のどちらにも表示されません)。
また、他の8行は file1 と同じですが、 file2 には表示されません(したがって
、接頭辞として ‘+’ が付けられます)。

   ‘git diff-tree -c’ で表示される場合、マージコミットの親をマージ結果と
比較します(つまり、 file1..fileN が親です)。 ‘git diff-files -c’ で表示
される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり
、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別
名「彼らのバージョン」です)。

other diff formats
******************

‘--summary’ オプションは、新しく追加、削除、名前変更、およびコピーされた
ファイルを説明します。‘--stat’ オプションは、 diffstat(1) グラフ を出力
に追加します。これらのオプションは、 ‘-p’ などの他のオプションと組み合わ
せることができ、人間が読むことを目的としています。

   名前の変更またはコピーを伴う変更を表示する場合、 ‘--stat’ 出力は、パ
ス名の共通のプレフィックスとサフィックスを組み合わせることにより、パス名
をコンパクトにフォーマットします。 たとえば、4行を変更(modify)しながら
‘arch/i386/Makefile’ を ‘arch/x86/Makefile’ に移動(move)する変更
(change)は、次のように表示されます:

     arch/{i386 => x86}/Makefile    |   4 +--

   ‘--numstat’ オプションは diffstat(1) 情報を提供しますが、人間ではなく
ソフトウェアで読むのを容易にするように設計されています。 ‘--numstat’ 出
力のエントリは以下のようになります:

     1       2       README
     3       1       arch/{i386 => x86}/Makefile

   この形式は、左から右へ:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. パス名(おそらく rename/copy 情報を含む)

  6. 改行

   ‘-z’ 出力オプションが有効な場合、出力は以下のようにフォーマットされま
す:

     1       2       README NUL
     3       1       NUL arch/i386/Makefile NUL arch/x86/Makefile NUL

   これは:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. NUL(rename/copy された場合のみ存在します)

  6. プリイメージのパス名

  7. NUL(rename/copy された場合のみ存在します)

  8. ポストイメージのパス名(rename/copy された場合のみ存在します)

  9. NUL

   名前が変更された場合のプリイメージパスの前の追加の ‘NUL’ は、出力を読
み取るスクリプトが、先読みせずに、読み取られている現在のレコードがシング
ルパスレコードであるか、名前変更/コピーレコードであるか、を判断できるよ
うにするためです。追加および削除された行を読み取った後、 ‘NUL’ まで読み
取るとパス名が生成されますが、それが ‘NUL’ の場合、レコードには2つのパス
が表示されます。

OPERATING MODES
***************

あなたはインデックスファイルを完全に信頼するか(‘--cached’ フラグを使用
)、diffロジックにてstat状態と一致しないファイルを「仮変更」(tentatively
changed)として表示するようにするかを選択できます。これらの操作はどちらも
非常に便利です。

CACHED MODE
***********

‘--cached’ が指定されている場合、あなたは以下のように問うことができます:

     HEADと、現在のインデックスの内容(`git write-tree` を
     使用して書き込むもの)との違いを見せてください

   たとえば、あなたがあなたの作業ディレクトリで作業して、インデックス内
のいくつかのファイルを更新し、コミットする準備ができました。あなたは何を
コミットしようとしているかを正確に確認したいのですが、比較のために新しい
ツリーオブジェクトを作成する必要はありません。そのためには、あなたは以下
のようにします。

     git diff-index --cached HEAD

   例: ‘commit.c’ の名前を ‘git-commit.c’ に変更し、それをインデックスフ
ァイルで有効にするために ‘update-index’ を実行したとします。 インデック
スファイルが私の作業ディレクトリと一致するため、 ‘git diff-files’ は何も
表示しません。 しかし、 ‘git diff-index’ を実行すると以下のようになりま
す:

     torvalds@ppc970:~/git> git diff-index --cached HEAD
     -100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        commit.c
     +100644 blob    4161aecc6700a2eb579e842af0b7f22b98443f74        git-commit.c

   あなたは上記が名前変更(rename)であることが簡単にわかります。

   実際、 ‘git diff-index --cached’ は、実際に ‘git write-tree’ を実行し
て比較することと常に完全に同等です。実際に実行するのではなくて、自分がど
ういう状態にあるかを確認したいだけの場合には、こちらの方がはるかに優れて
います。

   したがって、 ‘git diff-index --cached’ を実行することは、「コミット済
みとしてすでにマークしたものと、前のツリーとの違い」を自問するときに実に
役に立つのです。

NON-CACHED MODE
***************

非キャッシュモードは別のアプローチを取り、 ‘git write-tree’ + ‘ git
diff-tree‘ でエミュレートできないという点で、2つのモードの中でより便利に
なる可能性があります。したがって、これがデフォルトのモードです。非キャッ
シュバージョンは以下のように問いかけます:

     HEADと現在チェックアウトされているツリーの違いを
     表示 - インデックスの内容や最新でないファイル

   これは明らかに非常に役立つ質問です。何をコミットできるかがわかるから
です。 この場合も、出力は _git diff-tree -r_ の出力と完全に一致しますが
、更にひとひねりあります。

   そのひとひねりとは、一部のファイルがインデックスと一致しない場合、そ
のファイルには裏付けがないことです。これを示すために、魔法の「オールゼロ
」sha1を使用します。 ‘kernel/sched.c’ を編集したが、実際にはまだ _git
update-index_ を実行していないとしましょう。そうすると、新しい状態に関連
付けられた「オブジェクト」はなく、以下のようになります:

     torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
     :100644 100664 7476bb... 000000...      kernel/sched.c

   つまり、ツリーが変更され、 ‘kernel/sched.c’ が最新ではなく、新しいも
のが含まれている可能性があることを示しています。オールゼロのsha1は、実際
の差分を取得するには、オブジェクト間のdiffを行うのではなく、作業ディレク
トリ内のオブジェクトを直接確認する必要があることを意味します。

     *Note*

     このタイプの他のコマンドと同様に、 ‘git diff-index’ は実際にはファ
     イルの内容をまったく調べません。 つまり、 ‘kernel/sched.c’ は実際に
     は変更されておらず、触れた(touch)だけです。いずれの場合も、インデッ
     クスを同期させるには、 ‘gitu pdate-index’ する必要があることに注意
     してください。

     *Note*

     「has been updated」(更新されました)と「is still dirty in the
     working directory」(作業ディレクトリでまだダーティです)というファイ
     ルが混在している場合があります。「更新された」ファイルには有効な
     sha1が表示され、「インデックスと同期していない」ファイルには常に特
     別なすべてゼロのsha1が表示されるため、どのファイルがどの状態にある
     かをいつでも確認できます。

GIT
***

Part of the git(1) suite

Name
****

git-diff-tree — 2つのツリーオブジェクト間で、ブロブの内容とモードを比較
します

Synopsis
********

     git diff-tree [–stdin] [-m] [-s] [-v] [–no-commit-id] [–pretty]
                   [-t] [-r] [-c | –cc] [–combined-all-paths] [–root] [–merge-base]
                   [<common diff options>] <tree-ish> [<tree-ish>] [<path>…]

DESCRIPTION
***********

2つのツリーオブジェクト間で、ブロブの内容とモードを比較します

   <tree-ish> が1つだけ指定されている場合、コミットはその親と比較されま
す(以下の ‘--stdin’ 参照)。

   注意: ‘git diff-tree’ は、コミットオブジェクトにカプセル化されたツリ
ーを使用できます。

OPTIONS
*******

‘-p’
‘-u’
‘--patch’
     パッチを生成します(generating patches に関するセクションを参照)。

‘-s’
‘--no-patch’
     diff出力を抑制します。デフォルトでパッチを表示する ‘git show’ のよ
     うなコマンド、または ‘--patch’ の効果をキャンセルする場合に便利です
     。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。 ‘--patch’ の機
     能を含んでいます。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--raw’
     生形式(raw format)でdiffを生成します。 これがデフォルトです。

‘--patch-with-raw’
     ‘-p --raw’ の同義語。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--patch-with-stat’
     ‘-p --stat’ と同義語。

‘-z’
     ‘--raw’ または ‘--numstat’ または ‘--name-only’ または
     ‘--name-status’ が指定されている場合は パス名を変更せず、出力フィー
     ルドターミネータとしてNULLを使用してください。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、 通常の文字以外(unusual characters)を含むパス名が引用符で囲
     まれます(git-config(1) 参照)。

‘--name-only’
     変更されたファイルの名前のみを表示します。 多くの場合、ファイル名は
     UTF-8でエンコードされます。 詳細については、 git-log(1) のマニュア
     ルページにあるエンコーディングに関する議論(the discussion about
     encoding)を参照してください。

‘--name-status’
     変更されたファイルの名前とステータスのみを表示します。ステータス文
     字の意味については、 ‘--diff-filter’ オプションの説明を参照してくだ
     さい。 ‘--name-only’ と同じように、ファイル名はしばしばUTF-8でエン
     コードされます。

‘--submodule[=<format>]’
     サブモジュールの違いをどのように表示するかを指定します。
     ‘--submodule=short’ を指定する場合、 short形式が使用されます。この
     形式は、範囲の最初と最後にコミットの名前を表示するだけです。
     ‘--submodule’ または ‘--submodule=log’ が指定されている場合、 log形
     式が使用されます。この形式では、 git-submodule(1) ‘summary’ のよう
     に範囲内のコミットが一覧表示されます。 ‘--submodule=diff’ が指定さ
     れている場合、 diff形式が使用されます。この形式は、コミット範囲間の
     サブモジュールの内容の変更のインラインdiffを示します。configオプシ
     ョンが設定されていない場合、デフォルトは ‘diff.submodule’ または
     ‘short’ 形式です。

‘--color[=<when>]’
     色付きのdiffを表示します。 ‘--color’ (つまり、 ‘=<when>’ 無し) は
     ‘--color=always’ と同じです。 <when> は、 always または never また
     は auto のいずれかになります。

‘--no-color’
     カラーdiffをオフにします。 ‘--color=never’ と同じです。

‘--color-moved[=<mode>]’
     ソースコードの移動した行を別の色にします。 <mode>は、オプションが指
     定されていない場合はデフォルトで no になり、 モードが指定されていな
     いオプションが指定されている場合は zebra になります。 モードは以下
     のいずれかでなければなりません:

     no
          移動行をハイライトしません。

     default
          zebra の同義語です。これは、将来、より賢明なモードに変更される
          可能性があります。

     plain
          ある場所で追加され、別の場所で削除された行は、
          ‘color.diff.newMoved’ で色付けされます。 同様に、
          ‘color.diff.oldMoved’ は、差分の別の場所に追加された削除された
          行に使用されます。このモードは移動された行をピックアップします
          が、コードのブロックが順列なしで移動されたかどうかを判断するこ
          とはレビューではあまり役に立ちません。

     blocks
          少なくとも20文字の英数字の移動テキストのブロックが貪欲に検出さ
          れます。検出されたブロックは、 ‘color.diff.{old,new}Moved’ 色
          のいずれかを使用して色付けされます。隣接するブロックを区別する
          ことはできません。

     zebra
          移動されたテキストのブロックは、 _blocks_ モードの場合と同様に
          検出されます。 ブロックは、 _color.diff.{old,new}Moved_ 色また
          は _color.diff.{old,new}MovedAlternative_ 色のいずれかを使用し
          て色付けされます。2つの色の間の変化は、新しいブロックが検出さ
          れたことを示します。

     dimmed-zebra
          _zebra_ に似ていますが、移動されたコードの重要でない部分の追加
          の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は
          興味深いと見なされ、残りは興味深いものではありません。
          ‘dimmed_zebra’ は非推奨の同義語です。

‘--no-color-moved’
     移動検出をオフにします。 これは、構成設定を上書きするために使用でき
     ます。 ‘--color-moved=no’ と同じです。

‘--color-moved-ws=<modes>’
     これは、 ‘--color-moved’ の移動検出を実行するときに空白を無視する方
     法を設定します。 これらのモードは、コンマ区切りのリストとして指定で
     きます:

     no
          移動行検出を実行するときに、空白(whitespace)を無視しない。

     ignore-space-at-eol
          行末(EOL)での空白(whitespace)の変更を無視します。

     ignore-space-change
          空白(whitespace)の数の変更は無視してください。これは、行末の空
          白(whitespace)を無視し、1つ以上の空白文字(whitespace
          characters)の他のすべてのシーケンスを同等と見なします。

     ignore-all-space
          行を比較するときは空白(whitespace)を無視します。これにより、一
          方の行に空白があり、もう一方の行に空白がない場合でも、違いは無
          視されます。

     allow-indentation-change
          最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変
          更が行ごとに同じである場合にのみ、移動されたコードブロックをブ
          ロックにグループ化します。 これは他のモードと互換性がありませ
          ん。

‘--no-color-moved-ws’
     移動検出を実行するときは、空白(whitespace)を無視しないでください。
     これは、構成設定を上書きするために使用できます。
     ‘--color-moved-ws=no’ と同じです。

‘--word-diff[=<mode>]’
     <mode> を使用して変更された単語を区切ることにより、単語のdiffを表示
     します。デフォルトでは、単語は空白で区切られます。 以下の
     ‘--word-diff-regex’ を参照してください。 <mode> のデフォルトは
     ’plain’です。 <mode> は以下のいずれかである必要があります:

     color
          変更された単語(word)を色のみを使用して強調表示します。
          ‘--color’ を意味します。

     plain
          単語を ‘[-removed-]’ および ‘{+added+}’ として表示します。 区
          切り文字が入力に表示されている場合、区切り文字をエスケープしよ
          うとしないため、出力があいまいになる可能性があります。

     porcelain
          スクリプトの使用を目的とした特別な行ベースの形式を使用します。
          追加/削除/無変更については、通常の統一されたdiff形式で印刷され
          、行の先頭の ‘+’/‘-’/‘ ‘ 文字で始まり、行の終わりまで続きます
          。入力の改行は、それ自体の行のチルダ ‘~’ で表されます。

     none
          単語(word)のdiffを再度無効にします。

     注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべ
     てのモードで変更された部分を強調するために色が使用されることに注意
     してください。

‘--word-diff-regex=<regex>’
     空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるか
     を決定します。また、すでに有効になっていない限り、この機能は
     ‘--word-diff’ の機能を含んでいます。

     <regex> の重複しないマッチはすべて、単語と見なされます。これらのマ
     ッチの間のすべては空白と見なされ、違いを見つけるためとしては無視さ
     れます！ 正規表現に ‘|[^[:space:]]’ を追加して、空白以外のすべての
     文字とマッチすることを確認することをお勧めします。改行を含むマッチ
     は、改行で黙って切り捨てられます！

     たとえば、 ‘--word-diff-regex=.’ は各文字を単語として扱い、それに応
     じて文字ごとの違いを表示します。

     正規表現は、diffドライバーまたは構成オプション(configuration
     option)を介して設定することもできます。 gitattributes(5) または
     git-config(1) を参照してください。これを指定すると、diffドライバー
     または構成設定(configuration settings)が明示的にオーバーライドされ
     ます。diffドライバーは構成設定を上書きします。

‘--color-words[=<regex>]’
     ‘--word-diff=color’ に ‘--word-diff-regex=<regex>’ を加えたものに相
     当します(正規表現が指定されている場合)。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--check’
     変更によって競合マーカーまたは空白エラーが発生した場合に警告します
     。空白エラーと見なされるものは、 ‘core.whitespace’ 構成によって制御
     されます。 デフォルトでは、末尾の空白(空白のみで構成される行を含む
     )と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空
     白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータ
     スで終了します。なお、 –exit-code とは互換性がありません。

‘--ws-error-highlight=<kind>’
     diffの ‘context’ または ‘old’ または ‘new’ 行の空白エラーを強調表示
     します。複数の値はコンマで区切られ、 ‘none’ は前の値をリセットし、
     ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は old、new、
     context の省略形です。このオプションが指定されておらず、構成変数
     ‘diff.wsErrorHighlight’ が設定されていない場合、 ‘new’ 行の空白エラ
     ーのみが強調表示されます。空白エラーは ‘color.diff.whitespace’ で色
     分けされています。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。 ‘--patch’ の機能を含んでいます。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     名前の変更(renames)を検知する。 ‘n’ が指定されている場合、それは類
     似性インデックスのしきい値です (つまり、ファイルのサイズと比較した
     追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以上が変更され
     ていない場合、 Gitが削除/追加のペアを名前変更と見なす必要があること
     を意味します。 ‘%’ 記号がない場合、数値は小数として読み取られ、その
     前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、‘-M50%’ と同
     じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検出を正確な
     名前変更に制限するには、 ‘-M100%’ を使用します。 デフォルトの類似性
     インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]’
     追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更
     (Rename)されたファイル、タイプが変更されたファイル(T)、マージされて
     いないファイル(U)、不明なファイル(X)、またはペアリングが壊れている
     ファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合
     わせを使用できます。 組み合わせに ‘*’ (全てまたは無し)が追加される
     と、比較で他の基準に一致するファイルがある場合、すべてのパスが選択
     されます。 他の基準に一致するファイルがない場合、何も選択されません
     。

     また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定し
     ます。例えば ‘--diff-filter=ad’ は、追加および削除されたパスを除外
     します。

     注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意
     してください。 たとえば、インデックスから作業ツリーへのdiffにエント
     リを追加することはできません(diffに含まれるパスのセットは、インデッ
     クスの内容によって制限されるため)。 同様に、これらのタイプの検出が
     無効になっている場合、コピーおよび名前変更されたエントリは表示され
     ません。

‘-S<string>’
     ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の
     差分を調べます。スクリプターが使用することを目的としています。

     (構造体など)コードの正確なブロックを探していて、そのブロックが最初
     に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し
     使用して、プリイメージ(preimage)内の興味深いブロックを ‘-S’ にフィ
     ードバックし、そしてあなたはそれをブロックの最初のバージョンを取得
     するまで続けます。

     バイナリファイルも検索されます。

‘-G<regex>’
     パッチテキストに <regex> にマッチする 追加/削除 された行が含まれて
     いる差分を探します。

     ‘-S<regex> --pickaxe-regex’ と ‘-G<regex>’ の違いを説明するために、
     同じファイル内で以下のdiffを使用してコミットすることを検討してくだ
     さい:

          +    return frotz(nitfol, two->ptr, 1, 0);
          ...
          -    hit = frotz(nitfol, mf2.ptr, 1, 0);

     ‘git log -G"frotz\(nitfol"’ はこのコミットを表示しますが、 ‘git log
     -S"frotz\(nitfol" --pickaxe-regex’ は表示しません(その文字列の出現
     回数が変更されなかったため)。

     ‘--text’ が提供されていない限り、 textconv フィルターのないバイナリ
     ファイルのパッチは無視されます。

     詳細については gitdiffcore(7) の「pickaxe」エントリを参照してくださ
     い。

‘--find-object=<object-id>’
     指定されたオブジェクトの出現回数を変更する違いを探します。 ‘-S’ と
     同様に、引数だけが異なり、特定の文字列ではなく特定のオブジェクト
     IDを検索します。

     オブジェクトは、ブロブまたはサブモジュールのコミットにすることがで
     きます。 これは、 ‘git-log’ の ‘-t’ オプションがツリーも探すことを
     意味します。

‘--pickaxe-all’
     ‘-S’ または ‘-G’ が変更を見つけたら、 <string> の変更を含むファイル
     だけでなく、その変更セット(changeset)のすべての変更を表示します。

‘--pickaxe-regex’
     ‘-S’ に指定した <string> を拡張POSIX正規表現として扱います。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘-R’
     2つの入力を交換します。 つまり、インデックスまたはディスク上のファ
     イルとツリーの内容の違いを表示します。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--exit-code’
     diff(1）と同様のコードでプログラムを終了させます。つまり、違いがあ
     った場合は 1 で終了し、 0 は違いがないことを意味します。

‘--quiet’
     プログラムのすべての出力を無効にします。 ‘--exit-code’ を意味します
     。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

<tree-ish>
     ツリーオブジェクトのID。

<path>…
     <path>… が提供された場合、結果は提供されたパススペックの1つに一致す
     るファイルのサブセットに制限されます。

‘-r’
     サブツリーを再帰的に辿ります。

‘-t’
     ツリーエントリ自体とサブツリーを表示します。 ‘-r’ の機能を含みます
     。

‘--root’
     ‘--root’ が指定されている場合、最初のコミット(initial commit)は大き
     な作成イベント(big creation event)として表示されます。これは、
     NULLツリーに対する差分と同等です。

‘--merge-base’
     <tree-ish>を直接比較する代わりに、2つの<tree-ish>間のマージベースを
     before側として使用します。2つの<tree-ish>が指定されている必要があり
     、両方ともコミットである必要があります。

‘--stdin’
     ‘–stdin‘が指定されている場合、コマンドはコマンドラインから
     <tree-ish>引数を取りません。代わりに、2つの<tree> または 1つの
     <commit> または <commit>のリストのいずれかを含む行を標準入力から読
     み取ります。（区切り文字として空白1文字を使用します。）

     2つのツリーが与えられると、最初のツリーと2番目のツリーが比較されま
     す。単一のコミットが与えられると、そのコミットをその親と比較します
     。 残りのコミットは、指定されると、最初のコミットの親であるかのよう
     に使用されます。

     2つのツリーを比較する場合、違いの前に両方のツリーのID(スペースで区
     切られ、改行で終了)が出力されます。コミットを比較する場合、最初の
     (または唯一の)コミットのIDと、それに続く改行が出力されます。

     以下のフラグは、(ツリーではなく、)コミットを比較するときの動作に影
     響します。

‘-m’
     デフォルトでは、 ‘git diff-tree --stdin’ はマージコミットの違いを表
     示しません。 このフラグを使用すると、すべての親からのコミットとの違
     いが示されます。 ‘-c’ も参照してください。

‘-s’
     デフォルトでは、 ‘git diff-tree --stdin’ は、機械可読形式( ‘-p’ な
     し) または パッチ形式( ‘ -p‘ あり)のいずれかで違いを示します。この
     出力を抑制できます。 ‘-v’ フラグでのみ役立ちます。

‘-v’
     このフラグにより、 ‘git diff-tree --stdin’ は、違いの前にコミットメ
     ッセージも表示します。

‘--pretty[=<format>]’
‘--format=<format>’
     コミットログの内容を指定された形式できれいに印刷(pretty-print)しま
     す。 <format> は oneline、short、medium、full、fuller、reference、
     email、raw、format:<string>、tformat:<string> のいずれかになります
     。 <format> が上記のいずれでもなく、「%プレースホルダー」が含まれて
     いる場合、 ‘--pretty=tformat:<format>’ が指定されたかのように動作し
     ます。

     各フォーマットの詳細については、「PRETTY FORMATS」セクションを参照
     してください。 ‘=<format>’ の部分を省略すると、デフォルトで medium
     になります。

     注意: リポジトリー構成でデフォルトのpretty formatを指定できます
     (git-config(1) 参照)。

‘--abbrev-commit’
     40バイトの16進コミットオブジェクト名全体を表示する代わりに、オブジ
     ェクトに一意の名前を付けるプレフィックスを表示します。
     "–abbrev=<n>" (表示されている場合はdiff出力も変更します)オプション
     を使用して、プレフィックスの最小長を指定できます。

     これにより、80桁幅の端末を使用している人にとって "–pretty=oneline"
     がずっと読みやすくなるはずです。

‘--no-abbrev-commit’
     完全な40バイトの16進コミットオブジェクト名を表示します。 これにより
     、明示的または "–oneline" などの他のオプションによって暗黙的に示さ
     れる ‘--abbrev-commit’ が無効になります。また、 ‘log.abbrevCommit’
     変数をオーバーライドします。

‘--oneline’
     これは、 "–pretty=oneline –abbrev-commit" を一緒に使用するための省
     略形です。

‘--encoding=<encoding>’
     コミットオブジェクトは、ログメッセージに使用される文字エンコードを
     エンコードヘッダーに記録します。このオプションを使用して、ユーザー
     が好むエンコーディングでコミットログメッセージを再コーディングする
     ようにコマンドに指示できます。配管以外のコマンドの場合、これはデフ
     ォルトでUTF-8になります。オブジェクトが ‘X’ でエンコードされている
     と主張し、 ‘X’ で出力している場合、オブジェクトをそのまま出力するこ
     とに注意してください。これは、元のコミットの無効なシーケンスが出力
     にコピーされる可能性があることを意味します。同様に、 iconv(3) コミ
     ットの変換に失敗した場合、警告とともに元のオブジェクトをそのまま出
     力します。

‘--expand-tabs=<n>’
‘--expand-tabs’
‘--no-expand-tabs’
     出力に表示する前に、ログメッセージでタブ展開を実行します(タブ幅を
     <n> とみなして <n> 境界に揃うように空白で調整する)。
     ‘--expand-tabs’ は ‘--expand-tabs=8’ の省略形であり、
     ‘--no-expand-tabs’ は ‘--expand-tabs=0’ の省略形です。タブの展開を
     無効にします。

     デフォルトでは、タブはログメッセージを4つのスペースでインデントする
     きれいな形式(pretty formats)で展開されます(つまり、medium (これがデ
     フォルト) と full と fuller)。

‘--notes[=<ref>]’
     コミットログメッセージを表示するときに、コミットに注釈を付ける
     notes(git-notes(1) 参照)を表示します。これは、コマンドラインに
     ‘--pretty’ 、‘--format’ または ‘--oneline’ オプションが指定されてい
     ない場合の、 ‘git log’ と ‘git show’ と ‘ git whatchanged‘ コマンド
     のデフォルトです。

     デフォルトでは、表示されるnotesは、 ‘core.notesRef’ および
     ‘notes.displayRef’ 変数(または対応する環境変数オーバーライド)にリス
     トされているnote refからのものです。詳細については git-config(1) を
     参照してください。

     オプションの <ref> 引数を使用して、refを使用して表示するnotesを検索
     します。 refは、 ‘refs/notes/’ で始まる完全なrefnameを指定できます
     。 ‘notes/’ で始まるか、 ‘refs/’ で始まるか、それ以外で始まる場合、
     ‘refs/notes/’ が接頭辞として付けられ、refのフルネームを形成します。

     複数の –notes オプションを組み合わせて、表示するノートを制御できま
     す。 例: "–notes=foo" は "refs/notes/foo" からのnotesのみを表示しま
     す。 "–notes=foo –notes" は、 "refs/notes/foo" とデフォルトのnotes
     ref(s) の両方のnotesを表示します。

‘--no-notes’
     notesを表示しないでください。 これは、notesが表示されるnotes refの
     リストをリセットすることにより、上記の ‘--notes’ オプションを無効に
     します。 オプションは、コマンドラインで指定された順序で解析されます
     。 "–notes –notes=foo –no-notes –notes=bar" は、 "refs/notes/bar" か
     らのnotesのみを表示します。

‘--show-notes[=<ref>]’
‘--[no-]standard-notes’
     これらのオプションは非推奨です。 代わりに、上記の –notes/–no-notes
     オプションを使用してください。

‘--show-signature’
     署名を ‘gpg --verify’ に渡して、署名されたコミットオブジェクトの有
     効性を確認し、出力を表示します。

‘--no-commit-id’
     ‘git diff-tree’ は、該当する場合、コミットIDを含む行を出力します。
     このフラグは、コミットIDの出力を抑制します。

‘-c’
     このフラグは、マージコミットの表示方法を変更します(つまり、コマンド
     に1つの <tree-ish> 、または ‘--stdin’ が指定されている場合にのみ役
     立ちます)。これは、親と結果を一度に1つずつ表示するのではなく、各親
     とマージ結果の違いを同時に表示します(これは、 ‘-m’ オプションが行う
     ことです)。さらに、すべての親から変更されたファイルのみが一覧表示さ
     れます。

‘--cc’
     このフラグは、 ‘-c’ オプションと同様に、マージコミットパッチの表示
     方法を変更します。これは ‘-c’ と ‘-p’ オプションの機能を含んでいて
     、さらに、パッチの出力を圧縮するために、親のコンテンツが二つのバリ
     エーションしかなく、マージ結果がそのうちの一つをそのまま選んでしま
     うような、つまらないハンクは省きます。すべてのハンクがつまらない場
     合、他の「空の差分」の場合と同様に、コミット自体とコミットログメッ
     セージは表示されません。

‘--combined-all-paths’
     このフラグにより、結合された差分(combined diff)(マージコミットに使
     用)にすべての親からのファイルの名前が一覧表示されます。したがって、
     ‘-c’ または ‘--cc’ が指定されている場合にのみ有効であり、ファイル名
     の変更が検出された場合(つまり、名前変更またはコピーの検出が要求され
     た場合)にのみ役立つ可能性があります。

‘--always’
     差分自体が空の場合でも、コミット自体とコミットログメッセージを表示
     します。

PRETTY FORMATS
**************

コミットがマージであり、 pretty-format が ‘oneline’ または ‘email’ また
は ‘raw’ で無い場合、 ‘Author:’ 行の前に追加の行が挿入されます。この行は
"Merge: " で始まり、先祖のコミットのハッシュがスペースで区切られて出力さ
れます。履歴の表示を制限している場合、たとえば、特定のディレクトリまたは
ファイルに関連する変更のみに関心がある場合、リストされたコミットは必ずし
も *直接* の親コミットのリストではない可能性があることに注意してください
。

   いくつかの組み込みフォーマットがあります。そして以下で説明するように
、 pretty.<name> 構成オプション(config option)を別のフォーマット名または
‘format:’ 文字列に設定することで、追加のフォーマットを定義できます
(git-config(1) 参照)。組み込みフォーマットの詳細は以下のとおりです:

   • ‘oneline’

          <hash> <title line>

     これは、可能な限りコンパクトになるように設計されています。

   • ‘short’

          commit <hash>
          Author: <author>

          <title line>

   • ‘medium’

          commit <hash>
          Author: <author>
          Date:   <author date>

          <title line>

          <full commit message>

   • ‘full’

          commit <hash>
          Author: <author>
          Commit: <committer>

          <title line>

          <full commit message>

   • ‘fuller’

          commit <hash>
          Author:     <author>
          AuthorDate: <author date>
          Commit:     <committer>
          CommitDate: <committer date>

          <title line>

          <full commit message>

   • ‘reference’

          <abbrev hash> (<title line>, <short author date>)

     この形式は、コミットメッセージ内の別のコミットを参照するために使用
     され、 ‘--pretty='format:%C(auto)%h (%s, %ad)'’ と同じです。 デフォ
     ルトでは、別の ‘--date’ オプションが明示的に指定されていない限り、
     日付は ‘--date=short’ でフォーマットされます。formatプレースホルダ
     ーを使用する他の ‘format:’ と同様に、その出力は、 ‘--decorate’ や
     ‘--walk-reflogs’ などの他のオプションの影響を受けません。

   • ‘email’

          From <hash> <date>
          From: <author>
          Date: <author date>
          Subject: [PATCH] <title line>

          <full commit message>

   • ‘mboxrd’

     ‘email’ と同様ですが、コミットメッセージの "From " で始まる行(前に
     0個以上の ‘>’ が付いている)は ‘>’ でクォートされているため、新しい
     コミットの開始と混同されることはありません。

   • ‘raw’

     ‘raw’ 形式は、コミットオブジェクトに格納されているとおりにコミット
     全体を正確に表示します。とりわけ ‘--abbrev’ または ‘--no-abbrev’ の
     どちらが使用されているかに関係なく、ハッシュは完全に表示され、「親
     」(parents)情報は、移植や履歴の単純化を考慮せずに、真の親のコミット
     を示します。この形式は、コミットの表示方法に影響しますが、いわゆる
     ‘git log --raw’ の差分の表示方法ではありません。生のdiff形式で完全
     なオブジェクト名を取得するには、 ‘--no-abbrev’ を使用します。

   • ‘format:<string>’

     ‘format:<string>’ 形式を使用すると、表示する情報を指定できます。注
     意: これはprintf書式に少し似ていますが、 ‘\n’ の代わりに ‘%n’ を使
     用して改行を取得するという例外に注意してください。

     例: ‘format:"The author of %h was %an, %ar%nThe title was
     >>%s<<%n"’ は以下のように表示されます:

          The author of fe6e0ee was Junio C Hamano, 23 hours ago
          The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

     さて、以下がプレースホルダー達です:

        • 単一のリテラル文字に展開されるプレースホルダー:

          ‘%n’
               改行(newline)

          ‘%%’
               ‘%‘そのもの

          ‘%x00’
               16進数のバイト値を出力

        • うしろのプレースホルダーのフォーマッティングに影響するプレース
          ホルダー:

          ‘%Cred’
               赤色に切り替える

          ‘%Cgreen’
               緑色に切り替える

          ‘%Cblue’
               青色に切り替える。

          ‘%Creset’
               色をリセットする

          ‘%C(...)’
               git-config(1) の「CONFIGURATION FILE」の Values で説明さ
               れている色の指定。 デフォルトでは、色はログ出力が有効にな
               っている場合にのみ表示されます’(‘color.diff’ または
               ‘color.ui’ または ‘--color’ によって、ターミナルに出す場
               合は前者の ‘auto’ 設定を尊重します)。 ‘%C(auto,...)’ は、
               default の歴史的同義語として受け入れられます(例:
               ‘%C(auto,red)’)。 ‘%C(always,...)’ を指定すると、色が有効
               になっていない場合でも色が表示されます(この形式やgitが色
               付けする可能性のある他のすべてのものを含め、出力全体の色
               を有効にするために ‘--color=always’ の使用を検討してくだ
               さい)。 ‘auto’ のみ(つまり、 ‘%C(auto)’)は、色が再び切り
               替わるまで、これに続くプレースホルダーで自動色付けをオン
               にします。

          ‘%m’
               左(‘<’) または 右(‘>’) または 境界 (‘-’) の印

          ‘%w([<w>[,<i1>[,<i2>]]])’
               git-shortlog(1) の -w オプションのように、 行の折り返しを
               切り替えます。

          ‘%<(<N>[,trunc|ltrunc|mtrunc])’
               次のプレースホルダーに少なくともN列を使用させ、 必要に応
               じて右側にスペースを埋め込みます。オプションで、出力がN列
               より長い場合は、先頭(ltrunc)または中間(mtrunc)または末尾
               (trunc)で切り捨てます。注意: 切り捨ては、 N >= 2 でのみ正
               しく機能することに注意してください。

          ‘%<|(<N>)’
               次のプレースホルダーを少なくともN番目の列まで取得し、 必
               要に応じて右側にスペースを埋め込みます

          ‘%>(<N>)’, ‘%>|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 左側に
               スペースが埋め込まれています

          ‘%>>(<N>)’, ‘%>>|(<N>)’
               ‘%>(<N>)’ 、 ‘%>|(<N>)’ とそれぞれ似ていますが、 次のプレ
               ースホルダーが指定されたよりも多くのスペースを取り、その
               左側にスペースがある場合は、それらのスペースを使用します
               。

          ‘%><(<N>)’, ‘%><|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 両側に
               パディングがあります(つまり、テキストが中央に配置されます
               )

        • コミットから抽出された情報に展開するプレースホルダー:

          ‘%H’
               コミットハッシュ

          ‘%h’
               省略されたコミットハッシュ

          ‘%T’
               ツリーハッシュ

          ‘%t’
               省略されたツリーハッシュ

          ‘%P’
               親のハッシュ達

          ‘%p’
               省略された親のハッシュ達

          ‘%an’
               作者名

          ‘%aN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) を参照)

          ‘%ae’
               作者電子メールアドレス

          ‘%aE’
               作者電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) を参照)

          ‘%al’
               作者電子メールアドレスアカウント名(local-part)(‘@’ の前の
               部分)

          ‘%aL’
               作者電子メールアドレスアカウント名(local-part)(‘%al’ 参照
               ) .mailmap に関しては git-shortlog(1) または git-blame(1)
               参照)

          ‘%ad’
               作成日(フォーマットに関しては –date= オプション参照)

          ‘%aD’
               作成日 RFC2822形式

          ‘%ar’
               作成日 相対(relative)形式

          ‘%at’
               作成日 UNIXタイムスタンプ形式

          ‘%ai’
               作成日 ISO 8601風形式

          ‘%aI’
               作成日 厳密なISO 8601形式

          ‘%as’
               作成日 短い形式(‘YYYY-MM-DD’)

          ‘%ah’
               作成日 human形式( git-rev-list(1) の ‘--date=human’ オプ
               ションのようなかんじ)

          ‘%cn’
               コミッター名

          ‘%cN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ce’
               コミッター電子メールアドレス

          ‘%cE’
               コミッター電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%cl’
               コミッター電子メールアドレスアカウント名(local-part)( ‘@’
               の前の部分)

          ‘%cL’
               コミッター電子メールアドレスアカウント名(local-part)(
               ‘%cl’ 参照) .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%cd’
               コミッター日付(フォーマットに関しては ‘--date=’ オプショ
               ン参照)

          ‘%cD’
               コミッター日付 RFC2822形式

          ‘%cr’
               コミッター日付 相対(relative)形式

          ‘%ct’
               コミッター日付 UNIXタイムスタンプ形式

          ‘%ci’
               コミッター日付 ISO 8601風形式

          ‘%cI’
               コミッター日付 厳密なISO 8601形式

          ‘%cs’
               コミッター日付 短い形式(‘YYYY-MM-DD’)

          ‘%ch’
               コミッター日付 human形式(git-rev-list(1) の
               ‘--date=human’ オプションのようなかんじ)

          ‘%d’
               ref名 git-log(1) の –decorate オプションみたいなの

          ‘%D’
               " (", ")" で囲ってないref名

          ‘%(describe[:options])’
               git-describe(1) のような人間が読める名前。 説明できないコ
               ミットの場合は空の文字列。 ‘describe’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。タグが同時に追加または削除されると、説明に一貫性がな
               くなる可能性があります。

                  • ‘match=<pattern>’: ‘refs/tags/’ プレフィックスを除い
                    て、指定された ‘glob(7)’ パターンに一致するタグのみ
                    を考慮します。

                  • ‘exclude=<pattern>’: ‘refs/tags/’ プレフィックスを除
                    いて、指定された ‘glob(7)’ パターンに一致するタグを
                    対象にしません。

          ‘%S’
               コミットに到達したコマンドラインで指定されたref名 ( ‘git
               log --source’ など)は、 ‘git log’ でのみ機能します

          ‘%e’
               エンコーディング

          ‘%s’
               件名(subject)

          ‘%f’
               ファイル名に適した、サニタイズされた件名

          ‘%b’
               本文(body)

          ‘%B’
               生本文(raw body)(ラップされてない件名と本文)

          ‘%N’
               コミットノート(commit notes)

          ‘%GG’
               署名されたコミットの為のGPSからの生の検証メッセージ

          ‘%G?’

               G
                    良い(good)な(有効な)署名の場合はこの文字に置換されま
                    す。

               B
                    悪い署名(bad signature)の場合はこの文字に置換されま
                    す。

               U
                    有効性が不明(unknown validity)な良い署名の場合はこの
                    文字に置換されます。

               X
                    期限切れ(eXpired)の良い署名の場合はこの文字に置換さ
                    れます。

               Y
                    期限切れのキーで作成された良い署名の場合はこの文字に
                    置換されます。

               R
                    取り消されたキーによって作成された良い署名の場合はこ
                    の文字に置換されます。

               E
                    署名を確認できない場合(キーの欠落など)の場合はこの文
                    字に置換されます。

               N
                    署名がない場合の場合はこの文字に置換されます。

          ‘%GS’
               署名されたコミットの署名者の名前を表示する

          ‘%GK’
               署名されたコミットに署名するために使用されるキーを表示す
               る

          ‘%GF’
               署名されたコミットに署名するために使用されるキーのフィン
               ガープリントを表示する

          ‘%GP’
               署名されたコミットに署名するためにサブキーが使用された 主
               キーのフィンガープリントを表示します

          ‘%GT’
               署名されたコミットに署名するために使用されるキーの信頼レ
               ベル(trust level)を表示します

          ‘%gD’
               reflogセレクター(例:‘refs/stash@{1}’ or ‘refs/stash@{2
               minutes ago}’) この形式は、 ‘-g’ オプションで説明されてい
               る規則に従います。 ‘@’ の前の部分は、コマンドラインで指定
               されたrefnameです(したがって、 ‘git log -g
               refs/heads/master’ は ‘refs/heads/master@{0}’ を生成しま
               す)。

          ‘%gd’
               短縮されたreflogセレクター。 ‘%gD’ と同じですが、 人間が
               読みやすいようにrefname部分が短縮されています(したがって
               、 ‘refs/heads/master’ は単に ‘master’ になります)。

          ‘%gn’
               reflog ID名

          ‘%gN’
               reflog ID名( .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ge’
               reflog ID 電子メールアドレス

          ‘%gE’
               reflog ID 電子メールアドレス( .mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%gs’
               reflog 件名

          ‘%(trailers[:options])’
               git-interpret-trailers(1) によって解釈されるようにボディ
               のトレーラーを表示します。 ‘trailers’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。いずれかのオプションが複数回提供された場合、それぞれ
               最後のものが優先されます。

               ブール値オプションは、オプションの値 ‘[=<BOOL>]’ を受け入
               れます。 値 ‘true’ 、‘false’ 、 ‘on’ 、‘off’ などはすべて
               受け入れられます。 git-config(1) の "EXAMPLES" の
               "boolean" サブセクションを参照してください。ブール値オプ
               ションが値なしで指定された場合、それは有効を指定した事に
               なります。

                  • ‘key=<K>’ は指定されたキーを持つトレーラーのみを表示
                    します。マッチングは大文字と小文字を区別せずに行われ
                    、末尾のコロンはオプションです。オプションが複数回指
                    定されている場合、いずれかのキーに一致するトレーラー
                    行が表示されます。このオプションは自動的に ‘only’ オ
                    プションを有効にして、トレーラーブロック内の非トレー
                    ラー行が非表示になるようにします。それが望ましくない
                    場合は、 ‘only=false’ で無効にすることができます。 た
                    とえば、 ‘%(trailers:key=Reviewed-by)’ は、キーが
                    ‘Reviewed-by‘のトレーラー行を表示します。

                  • ‘only[=<BOOL>]’ はトレーラーブロックに非トレーラー行
                    を含めるかどうかを選択します。

                  • ‘separator=<SEP>’ はトレーラー行の間に挿入される区切
                    り文字を指定します。このオプションが指定されていない
                    場合、各トレーラー行は改行文字で終了します。文字列
                    SEPには、上記のリテラルフォーマットコードが含まれる
                    場合があります。区切り文字としてコンマを使用するには
                    、次のオプションとして解析されないよう ‘%x2C’ を使用
                    する必要があります。 たとえば、
                    ‘%(trailers:key=Ticket,separator=%x2C )’ は、キーが
                    ‘Ticket’ であるすべてのトレーラー行をカンマとスペー
                    スで区切って表示します。

                  • ‘unfold[=<BOOL>]’ は interpret-trailer の ‘--unfold’
                    オプションが指定されたかのように動作させます。たとえ
                    ば、 ‘%(trailers:only,unfold=true)’ が展開され、すべ
                    てのトレーラー行が表示されます。

                  • ‘keyonly[=<BOOL>]’ トレーラーのキー部分のみを表示。

                  • ‘valueonly[=<BOOL>]’ トレーラーの値部分のみ表示。

                  • ‘key_value_separator=<SEP>’ トレーラー行の間に挿入さ
                    れる区切り文字を指定します。このオプションが指定され
                    ていない場合、各トレーラーのキーと値のペアは ": " で
                    区切られます。 それ以外の場合は、上記の
                    ‘separator=<SEP>’ と同じセマンティクスを共有します。

     *Note*

     一部のプレースホルダーは、リビジョントラバーサルエンジンに指定され
     た他のオプションに依存する場合があります。 たとえば、 ‘%g*’ reflogオ
     プションは、reflogエントリをトラバースしない限り(たとえば、 ‘git
     log -g’ によって)空の文字列を挿入します。コマンドラインで
     ‘--decorate’ がまだ指定されていない場合、 ‘%d’ と ‘%D’ プレースホル
     ダーは「短い」(short)装飾形式を使用します。

   プレースホルダーの ‘%’ の後に ‘+’ (プラス記号)を追加すると、プレース
ホルダーが空でない文字列に展開される場合に限り、展開の直前に改行が挿入さ
れます。

   プレースホルダーの ‘%’ の後に ‘-’ (マイナス記号)を追加すると、プレー
スホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべて
の改行が削除されます。

   プレースホルダーの ‘%’ の後に " " (スペース)を追加すると、プレースホ
ルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入
されます。

   • ‘tformat:’

     ‘tformat:’ 形式は、 "separator" セマンティクスの代わりに
     "terminator" セマンティクスを提供することを除いて、 ‘format:’ とま
     ったく同じように機能します。 つまり、各コミットには、エントリ間に区
     切り文字を配置するのではなく、メッセージターミネータ文字(通常は改行
     )が追加されます。 これは、「1行」形式と同様に、1行形式の最終エント
     リが新しい行で適切に終了することを意味します。 例えば:

          $ git log -2 --pretty=format:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973 -- NO NEWLINE

          $ git log -2 --pretty=tformat:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973

     加えて、 ‘%’ が含まれている認識されない文字列は、その前に
     ‘tformat:’ があるかのように解釈(interpret)されます。 たとえば、以下
     の2つは同等です:

          $ git log -2 --pretty=tformat:%h 4da45bef
          $ git log -2 --pretty=%h 4da45bef

Raw output format
*****************

‘git-diff-index’ と ‘git-diff-tree’ と ‘git-diff-files’ と ‘git diff
--raw’ からの生の出力形式は非常に似ています。

   これらのコマンドはすべて、2つのセットを比較します。なお、比較されるも
のは異なります:

git-diff-index <tree-ish>
     <tree-ish> とファイルシステム上のファイルを比較します。

git-diff-index –cached <tree-ish>
     <tree-ish> とインデックスを比較します。

git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…]
     2つの引数で指定されたツリーを比較します。

git-diff-files [<pattern>…]
     インデックスとファイルシステム上のファイルを比較します。

   "git-diff-tree" コマンドは、比較対象のハッシュ値を出力することで出力
を開始します。その後、すべてのコマンドは、変更されたファイルごとに1つの
出力行を出力します。

   出力行は以下のようにフォーマットされます:

     in-place edit  :100644 100644 bcd1234 0123456 M file0
     copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2
     rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3
     create         :000000 100644 0000000 1234567 A file4
     delete         :100644 000000 1234567 0000000 D file5
     unmerged       :000000 000000 0000000 0000000 U file6

   つまり、左から右へ:

  1. コロン(:)

  2. "src" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  3. 空白

  4. "dst" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  5. 空白

  6. "src" のsha1。作成(creation)またはマージされていない(unmerged)場合
     は 0{40}

  7. 空白

  8. "dst" のsha1。作成(creation)またはマージされていない(unmerged)また
     は作業ツリーにある場合は 0{40}

  9. 空白

  10. ステータスの後に、オプションの「スコア数」("score" number)が続きま
     す

  11. ‘-z’ オプションが使用されている場合はタブまたはNUL

  12. "src" のパス

  13. ‘-z’ オプションが使用されている場合タブまたはNUL。ステータスCまた
     はRにのみ存在します

  14. "dst" のパス。ステータスCまたはRにのみ存在します

  15. LFでレコードを終了します。 ‘-z’ オプションが使用されている場合は
     NULでレコードを終了します。

   ステータス文字の種類は以下のとおり:

   • A: ファイルの追加

   • C: ファイルを新しいファイルにコピー

   • D: ファイルの削除

   • M: ファイルの内容やモードの変更

   • R: ファイル名の名前変更

   • T: ファイルのタイプを変更

   • U: ファイルはマージされていません(コミットする前にマージを完了する
     必要があります)

   • X: 「不明な」変更タイプ(おそらくバグです。報告してください)

   ステータス文字CとRの後には常にスコアが続きます(移動またはコピーのソー
スとターゲットの間の類似性のパーセンテージを示します)。ステータス文字Mの
後には、ファイルの書き換えのスコア(非類似度のパーセンテージを示す)が続く
場合があります。

   <sha1> は、ファイルがファイルシステム上で新規で、インデックスと同期し
ていない場合、すべて0として表示されます。

   例:

     :100644 100644 5be4a4a 0000000 M file.c

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、通常の文字以外(unusual characters)を含むパス名が引用符で囲
まれます(git-config(1) 参照)。 ‘-z’ を使用すると、ファイル名がそのまま出
力され、行はNULバイトで終了します。

diff format for merges
**********************

"git-diff-tree" と "git-diff-files" と "git-diff –raw" は、 ‘-c’ または
‘--cc’ オプションを使用して、マージコミットに対してもdiff出力を生成でき
ます。出力は、以下の点で上記の形式とは異なります:

  1. 親ごとにコロン(:)があります

  2. より多くの "src" モードと "src" sha1があります

  3. statusは、各親のステータス文字を連結したものです

  4. オプションの「スコア数」はありません

  5. ファイルのタブ区切りのパス名

   ‘-c’ および ‘ -cc‘ の場合、履歴のいずれかの側でファイルの名前が変更さ
れた場合でも、宛先(dst)または最終パスのみが表示されます。
‘--combined-all-paths’ を使用すると、各親のパスの名前が表示され、それに
続いてマージコミットのパスの名前が表示されます。

   例: ‘--combined-all-paths’ を使用しない ‘-c’ および ‘--cc’ の場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       phooey.c

   例: ‘-c’ または ‘--cc’ のいずれかに ‘--combined-all-paths’ が追加され
た場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c  desc.c  desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       foo.sh  bar.sh  bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       fooey.c fuey.c  phooey.c

   注意: ’combined diff’は、すべての親から変更されたファイルのみをリスト
することに注意してください。

Generating patch text with -p
*****************************

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、
git-diff-tree(1) 、 git-diff-files(1) に ‘-p’ オプションを付けて実行する
とパッチテキストを生成します。パッチテキストの作成は、
‘GIT_EXTERNAL_DIFF’ と ‘GIT_DIFF_OPTS’ 環境変数( git(1) 参照)、および
‘diff’ 属性( gitattributes(5) 参照)を介してカスタマイズできます。

   -pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります:

          diff --git a/file1 b/file2

     名前の変更/コピーが含まれない限り、 ‘a/’ と ‘b/’ のファイル名は同じ
     です。 特に、作成または削除の場合でも、 ‘a/’ または ‘b/’ ファイル名
     の代わりに ‘/dev/ null’ が使用されることはありません。

     名前変更/コピーが含まれる場合、 ‘file1’ と‘file2‘ は、それぞれ名前
     変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファ
     イルの名前を示します。

  2. その後に、1つ以上の拡張ヘッダー行達が続きます:

          old mode <mode>
          new mode <mode>
          deleted file mode <mode>
          new file mode <mode>
          copy from <path>
          copy to <path>
          rename from <path>
          rename to <path>
          similarity index <number>
          dissimilarity index <number>
          index <hash>..<hash> <mode>

     ファイルモードは、ファイルタイプとファイル許可ビットを含む6桁の8進
     数として出力されます。

     拡張ヘッダーのパス名には、 ‘a/’ および ‘b/’ プレフィックスは含まれ
     ません。

     類似インデックス(similarity index)は変更されていない行のパーセンテ
     ージであり、非類似インデックス(dissimilarity index)は変更された行の
     パーセンテージです。これは切り捨てられた整数であり、その後にパーセ
     ント記号が続きます。したがって、100％の類似インデックス値は2つの等
     しいファイルを表し、100％の非類似性は古いファイルから新しいファイル
     に移行された行がないことを意味します。

     インデックス行には、変更前後のブロブオブジェクト名が含まれます。
     <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の
     場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、
     構成変数 ‘core.quotePath’ で説明されているように引用符で囲まれてい
     ます( git-config(1)参照)。

  4. 出力内のすべての ‘file1’ ファイルはコミット前のファイルを参照し、す
     べての ‘file2’ ファイルはコミット後のファイルを参照します。各変更を
     各ファイルに順番に適用するのは誤りです。たとえば、以下のパッチはaと
     bを交換します:

          diff --git a/a b/b
          rename from a
          rename to b
          diff --git a/b b/a
          rename from b
          rename to a

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されていま
     す。特定の言語に合わせてこれを調整する方法の詳細については、
     gitattributes(5) の "Defining a custom hunk-header" を参照してくだ
     さい。

Combined diff format
********************

diffを生成するコマンドは、マージを表示するときに ‘-c’ または ‘--cc’ オプ
ションを使用して「合成diff」(combined diff)を生成できます。これは
git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形
式です。 注意: これらのコマンドのいずれかに適切な ‘--diff-merges’ オプシ
ョンを指定して、特定の形式で差分を強制的に生成できることにも注意してくだ
さい。

   合成diff形式は以下のようになります:

     diff --combined describe.c
     index fabadb8,cc95eb0..4866510
     --- a/describe.c
     +++ b/describe.c
     @@@ -98,20 -98,12 +98,20 @@@
             return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

     - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
     ++static void describe(char *arg, int last_one)
       {
      +      unsigned char sha1[20];
      +      struct commit *cmit;
             struct commit_list *list;
             static int initialized = 0;
             struct commit_name *n;

      +      if (get_sha1(arg, sha1) < 0)
      +              usage(describe_usage);
      +      cmit = lookup_commit_reference(sha1);
      +      if (!cmit)
      +              usage(describe_usage);
      +
             if (!initialized) {
                     initialized = 1;
                     for_each_ref(get_name);

  1. まず "git diff" ヘッダーがあり、以下のようになります( ‘-c’ オプショ
     ンが使用されている場合):

          diff --combined file

     または、以下のようになります( ‘--cc’ オプションが使用されている場合
     ):

          diff --cc file

  2. その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマ
     ージを示しています):

          index <hash>,<hash>..<hash>
          mode <mode>,<mode>..<mode>
          new file mode <mode>
          deleted file mode <mode>,<mode>

     ‘mode <mode>,<mode>..<mode>’ 行は、<mode> の少なくとも1つが他の
     <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動
     (名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの
     <tree-ish> のdiffで機能するように設計されており、合成diff形式では使
     用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます

          --- a/file
          +++ b/file

     従来の統一diff形式の2行ヘッダーと同様に、 ‘/dev/null’ は、作成また
     は削除されたファイルを通知するために使用されます。

     ただし、 –combined-all-paths オプションが指定されている場合、2行の
     from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダー
     が取得されます。ここで、 N はマージコミットの親の数です。

          --- a/file
          --- a/file
          --- a/file
          +++ b/file

     この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち
     、別の親のファイルの元の名前を確認できます。

  4. チャンクヘッダーの形式が変更され、誤って ‘patch-p1’ にフィードされ
     るのを防ぎます。合成差分形式は、マージコミットの変更を確認するため
     に作成されたものであり、適用されることを意図したものではありません
     。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:

          @@@ <from-file-range> <from-file-range> <to-file-range> @@@

     合成diff形式のチャンクヘッダーには親の数+1の ‘@’ 文字があります。

   従来の統一diff形式とは異なり、2つのファイルAとBが、 ‘-’ (マイナスは
Aに表示されますが、Bでは削除されます) または ‘+’ (プラスはAにはありませ
んが、Bには追加されます)、または ‘" "’（スペースは変更なし) プレフィック
スを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1,
file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示し
ます。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどの
ように異なるかを示します。

   列Nの ‘-’ 文字は、その行が fileN に表示されているが、結果には表示され
ていないことを意味します。 列Nの ‘+’ 文字は、結果に行が表示され、 fileN
にその行がないことを意味します(つまり、その親の観点から見て行が追加され
たことを示す)。

   上記の出力例では、関数のシグネチャが両方のファイルから見て変更されて
います(したがって、 file1 と file2 の両方から2つの ‘-’ が削除され、さら
に ‘++’ が追加されたため、 file1 と file2 のどちらにも表示されません)。
また、他の8行は file1 と同じですが、 file2 には表示されません(したがって
、接頭辞として ‘+’ が付けられます)。

   ‘git diff-tree -c’ で表示される場合、マージコミットの親をマージ結果と
比較します(つまり、 file1..fileN が親です)。 ‘git diff-files -c’ で表示
される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり
、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別
名「彼らのバージョン」です)。

other diff formats
******************

‘--summary’ オプションは、新しく追加、削除、名前変更、およびコピーされた
ファイルを説明します。‘--stat’ オプションは、 diffstat(1) グラフ を出力
に追加します。これらのオプションは、 ‘-p’ などの他のオプションと組み合わ
せることができ、人間が読むことを目的としています。

   名前の変更またはコピーを伴う変更を表示する場合、 ‘--stat’ 出力は、パ
ス名の共通のプレフィックスとサフィックスを組み合わせることにより、パス名
をコンパクトにフォーマットします。 たとえば、4行を変更(modify)しながら
‘arch/i386/Makefile’ を ‘arch/x86/Makefile’ に移動(move)する変更
(change)は、次のように表示されます:

     arch/{i386 => x86}/Makefile    |   4 +--

   ‘--numstat’ オプションは diffstat(1) 情報を提供しますが、人間ではなく
ソフトウェアで読むのを容易にするように設計されています。 ‘--numstat’ 出
力のエントリは以下のようになります:

     1       2       README
     3       1       arch/{i386 => x86}/Makefile

   この形式は、左から右へ:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. パス名(おそらく rename/copy 情報を含む)

  6. 改行

   ‘-z’ 出力オプションが有効な場合、出力は以下のようにフォーマットされま
す:

     1       2       README NUL
     3       1       NUL arch/i386/Makefile NUL arch/x86/Makefile NUL

   これは:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. NUL(rename/copy された場合のみ存在します)

  6. プリイメージのパス名

  7. NUL(rename/copy された場合のみ存在します)

  8. ポストイメージのパス名(rename/copy された場合のみ存在します)

  9. NUL

   名前が変更された場合のプリイメージパスの前の追加の ‘NUL’ は、出力を読
み取るスクリプトが、先読みせずに、読み取られている現在のレコードがシング
ルパスレコードであるか、名前変更/コピーレコードであるか、を判断できるよ
うにするためです。追加および削除された行を読み取った後、 ‘NUL’ まで読み
取るとパス名が生成されますが、それが ‘NUL’ の場合、レコードには2つのパス
が表示されます。

GIT
***

Part of the git(1) suite

Name
****

git-diff — コミット、コミット、作業ツリーなどの間の変更を表示する

Synopsis
********

     git diff [<options>] [<commit>] [–] [<path>…]
     git diff [<options>] –cached [–merge-base] [<commit>] [–] [<path>…]
     git diff [<options>] [–merge-base] <commit> [<commit>…] <commit> [–] [<path>…]
     git diff [<options>] <commit>…<commit> [–] [<path>…]
     git diff [<options>] <blob> <blob>
     git diff [<options>] –no-index [–] <path> <path>

DESCRIPTION
***********

作業ツリーとインデックスまたはツリー間の変更、インデックスとツリー間の変
更、2つのツリー間の変更、マージによる変更、2つのBLOBオブジェクト間の変更
、ディスク上の2つのファイル間の変更を表示します。

‘git diff [<options>] [--] [<path>...]’
     この形式は、インデックス(次のコミットのステージング領域)に関連して
     行った変更を表示するためのものです。 言い換えれば、差異は、Gitにさ
     らにインデックスに追加するように指示「可能な」ものですが、まだ追加
     していないものです。 git-add(1) を使用して、これらの変更をステージ
     ングできます。

‘git diff [<options>] --no-index [--] <path> <path>’
     この形式は、ファイルシステム上の指定された2つのパスを比較するための
     ものです。 Gitによって制御される作業ツリーでコマンドを実行し、パス
     の少なくとも1つが作業ツリーの外部を指す場合、またはGitによって制御
     される作業ツリーの外部でコマンドを実行する場合は、 ‘--no-index’ オ
     プションを省略できます。 この形式は、 ‘--exit-code’ の指定を含んで
     います。

‘git diff [<options>] --cached [--merge-base] [<commit>] [--] [<path>...]’
     この形式は、指定された<commit>に関連する次のコミットのためにステー
     ジングした変更を表示するためのものです。 通常、最新のコミットとの比
     較が必要になるため、<commit>を指定しない場合、デフォルトでHEADにな
     ります。 HEADが存在せず(つまり、まだブランチが無い)、かつ、
     <commit>が指定されていない場合、すべてのステージされた変更が表示さ
     れます。 ‘--staged’ は ‘--cached’ の同義語です。

     ‘--merge-base’ が指定されている場合は、<commit>を使用する代わりに、
     <commit>とHEADのマージベースを使用します。 ‘git diff --cached
     --merge-base A’ は ‘git diff --cached $(git merge-base A HEAD)’ と
     同等です。

‘git diff [<options>] [--merge-base] <commit> [--] [<path>...]’
     この形式は、指定された<commit>に関連する作業ツリーでの変更を表示す
     るためのものです。 HEADを使用して最新のコミットと比較したり、ブラン
     チ名を使用して別のブランチの先端と比較したりできます。

     ‘--merge-base’ が指定されている場合は、<commit>を使用する代わりに、
     <commit>とHEADのマージベースを使用します。 ‘git diff --merge-base
     A’ は ‘git diff $(git merge-base A HEAD)’ と同等です。

‘git diff [<options>] [--merge-base] <commit> <commit> [--] [<path>...]’
     これは、2つの任意の<commit>間の変更を表示するためのものです。

     ‘--merge-base’ が指定されている場合は、「前」側に2つのコミットのマ
     ージベースを使用します。 ‘git diff --merge-base A B’ は ‘git diff
     --merge-baseAB’ と同等です。

‘git diff [<options>] <commit> <commit>... <commit> [--] [<path>...]’
     この形式は、マージコミットの結果を表示するためのものです。 最初にリ
     ストされている<commit>は、マージ自体である必要があります。 残りの
     2つ以上のコミットはその親である必要があります。 必要なリビジョンの
     セットを作成する便利な方法は、 ‘^@’ サフィックスを使用することです
     。 たとえば、 ‘master’ がマージコミットに名前を付ける場合、 ‘git
     diff master master^@’ は ‘git show master’ と同一の結合された
     diff(combined diff)を与えます。

‘git diff [<options>] <commit>..<commit> [--] [<path>...]’
     これは、2つの任意の<commit>間の変更を表示するための以前の形式(‘..’
     なし)と同義です。片側の<commit>を省略すると、代わりにHEADを使用した
     場合と同じ効果があります。

‘git diff [<options>] <commit>\...<commit> [--] [<path>...]’
     この形式は、両方の<commit>の共通の祖先から開始して、2番目の
     <commit>を含むブランチの変更を表示するためのものです。 ‘git diff
     A...B’ は ‘git diff $(git merge-base A B) B’ と同等です。 <commit>の
     いずれかを省略できます。これは、代わりにHEADを使用するのと同じ効果
     があります。

   念のために書いておきますが、上記の説明で出てくる <commit> は、
‘--merge-base’ の場合と、最後の ‘..’ 表記を使っている2つの形式以外は、す
べて任意の <tree> にすることが可能です。

   <commit>を綴る方法のより完全なリストについては、 gitrevisions(7) の「
SPECIFYING REVISIONS」セクションを参照してください。 ただし、 diffは範囲
ではなく2つの「エンドポイント」を比較することであり、その範囲表記
(‘<commit>..<commit>’ や ‘<commit>...<commit>’)は、 gitrevisions(7) の「
SPECIFYING RANGES」セクションで定義されている範囲を意味するものではあり
ません。

‘git diff [<options>] <blob> <blob>’
     この形式は、2つのBLOBオブジェクトの生のコンテンツの違いを表示するた
     めのものです。

OPTIONS
*******

‘-p’
‘-u’
‘--patch’
     パッチを生成します(generating patches に関するセクションを参照)。 こ
     れがデフォルトです。

‘-s’
‘--no-patch’
     diff出力を抑制します。デフォルトでパッチを表示する ‘git show’ のよ
     うなコマンド、または ‘--patch’ の効果をキャンセルする場合に便利です
     。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。 ‘--patch’ の機
     能を含んでいます。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--raw’
     生形式(raw format)でdiffを生成します。

‘--patch-with-raw’
     ‘-p --raw’ の同義語。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--patch-with-stat’
     ‘-p --stat’ と同義語。

‘-z’
     ‘--raw’ または ‘--numstat’ または ‘--name-only’ または
     ‘--name-status’ が指定されている場合は パス名を変更せず、出力フィー
     ルドターミネータとしてNULLを使用してください。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、 通常の文字以外(unusual characters)を含むパス名が引用符で囲
     まれます(git-config(1) 参照)。

‘--name-only’
     変更されたファイルの名前のみを表示します。 多くの場合、ファイル名は
     UTF-8でエンコードされます。 詳細については、 git-log(1) のマニュア
     ルページにあるエンコーディングに関する議論(the discussion about
     encoding)を参照してください。

‘--name-status’
     変更されたファイルの名前とステータスのみを表示します。ステータス文
     字の意味については、 ‘--diff-filter’ オプションの説明を参照してくだ
     さい。 ‘--name-only’ と同じように、ファイル名はしばしばUTF-8でエン
     コードされます。

‘--submodule[=<format>]’
     サブモジュールの違いをどのように表示するかを指定します。
     ‘--submodule=short’ を指定する場合、 short形式が使用されます。この
     形式は、範囲の最初と最後にコミットの名前を表示するだけです。
     ‘--submodule’ または ‘--submodule=log’ が指定されている場合、 log形
     式が使用されます。この形式では、 git-submodule(1) ‘summary’ のよう
     に範囲内のコミットが一覧表示されます。 ‘--submodule=diff’ が指定さ
     れている場合、 diff形式が使用されます。この形式は、コミット範囲間の
     サブモジュールの内容の変更のインラインdiffを示します。configオプシ
     ョンが設定されていない場合、デフォルトは ‘diff.submodule’ または
     ‘short’ 形式です。

‘--color[=<when>]’
     色付きのdiffを表示します。 ‘--color’ (つまり、 ‘=<when>’ 無し) は
     ‘--color=always’ と同じです。 <when> は、 always または never また
     は auto のいずれかになります。 ‘color.ui’ と ‘color.diff’ 構成設定
     で 変更できます。

‘--no-color’
     カラーdiffをオフにします。 これは、構成設定(configuration
     settings)を上書きするために使用できます。 ‘--color=never’ と同じで
     す。

‘--color-moved[=<mode>]’
     ソースコードの移動した行を別の色にします。 これは、
     ‘diff.colorMoved’ 構成設定によって変更できます。 <mode>は、オプショ
     ンが指定されていない場合はデフォルトで no になり、 モードが指定され
     ていないオプションが指定されている場合は zebra になります。 モード
     は以下のいずれかでなければなりません:

     no
          移動行をハイライトしません。

     default
          zebra の同義語です。これは、将来、より賢明なモードに変更される
          可能性があります。

     plain
          ある場所で追加され、別の場所で削除された行は、
          ‘color.diff.newMoved’ で色付けされます。 同様に、
          ‘color.diff.oldMoved’ は、差分の別の場所に追加された削除された
          行に使用されます。このモードは移動された行をピックアップします
          が、コードのブロックが順列なしで移動されたかどうかを判断するこ
          とはレビューではあまり役に立ちません。

     blocks
          少なくとも20文字の英数字の移動テキストのブロックが貪欲に検出さ
          れます。検出されたブロックは、 ‘color.diff.{old,new}Moved’ 色
          のいずれかを使用して色付けされます。隣接するブロックを区別する
          ことはできません。

     zebra
          移動されたテキストのブロックは、 _blocks_ モードの場合と同様に
          検出されます。 ブロックは、 _color.diff.{old,new}Moved_ 色また
          は _color.diff.{old,new}MovedAlternative_ 色のいずれかを使用し
          て色付けされます。2つの色の間の変化は、新しいブロックが検出さ
          れたことを示します。

     dimmed-zebra
          _zebra_ に似ていますが、移動されたコードの重要でない部分の追加
          の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は
          興味深いと見なされ、残りは興味深いものではありません。
          ‘dimmed_zebra’ は非推奨の同義語です。

‘--no-color-moved’
     移動検出をオフにします。 これは、構成設定を上書きするために使用でき
     ます。 ‘--color-moved=no’ と同じです。

‘--color-moved-ws=<modes>’
     これは、 ‘--color-moved’ の移動検出を実行するときに空白を無視する方
     法を設定します。 ‘diff.colorMovedWS’ 構成設定で設定できます。 これ
     らのモードは、コンマ区切りのリストとして指定できます:

     no
          移動行検出を実行するときに、空白(whitespace)を無視しない。

     ignore-space-at-eol
          行末(EOL)での空白(whitespace)の変更を無視します。

     ignore-space-change
          空白(whitespace)の数の変更は無視してください。これは、行末の空
          白(whitespace)を無視し、1つ以上の空白文字(whitespace
          characters)の他のすべてのシーケンスを同等と見なします。

     ignore-all-space
          行を比較するときは空白(whitespace)を無視します。これにより、一
          方の行に空白があり、もう一方の行に空白がない場合でも、違いは無
          視されます。

     allow-indentation-change
          最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変
          更が行ごとに同じである場合にのみ、移動されたコードブロックをブ
          ロックにグループ化します。 これは他のモードと互換性がありませ
          ん。

‘--no-color-moved-ws’
     移動検出を実行するときは、空白(whitespace)を無視しないでください。
     これは、構成設定を上書きするために使用できます。
     ‘--color-moved-ws=no’ と同じです。

‘--word-diff[=<mode>]’
     <mode> を使用して変更された単語を区切ることにより、単語のdiffを表示
     します。デフォルトでは、単語は空白で区切られます。 以下の
     ‘--word-diff-regex’ を参照してください。 <mode> のデフォルトは
     ’plain’です。 <mode> は以下のいずれかである必要があります:

     color
          変更された単語(word)を色のみを使用して強調表示します。
          ‘--color’ を意味します。

     plain
          単語を ‘[-removed-]’ および ‘{+added+}’ として表示します。 区
          切り文字が入力に表示されている場合、区切り文字をエスケープしよ
          うとしないため、出力があいまいになる可能性があります。

     porcelain
          スクリプトの使用を目的とした特別な行ベースの形式を使用します。
          追加/削除/無変更については、通常の統一されたdiff形式で印刷され
          、行の先頭の ‘+’/‘-’/‘ ‘ 文字で始まり、行の終わりまで続きます
          。入力の改行は、それ自体の行のチルダ ‘~’ で表されます。

     none
          単語(word)のdiffを再度無効にします。

     注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべ
     てのモードで変更された部分を強調するために色が使用されることに注意
     してください。

‘--word-diff-regex=<regex>’
     空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるか
     を決定します。また、すでに有効になっていない限り、この機能は
     ‘--word-diff’ の機能を含んでいます。

     <regex> の重複しないマッチはすべて、単語と見なされます。これらのマ
     ッチの間のすべては空白と見なされ、違いを見つけるためとしては無視さ
     れます！ 正規表現に ‘|[^[:space:]]’ を追加して、空白以外のすべての
     文字とマッチすることを確認することをお勧めします。改行を含むマッチ
     は、改行で黙って切り捨てられます！

     たとえば、 ‘--word-diff-regex=.’ は各文字を単語として扱い、それに応
     じて文字ごとの違いを表示します。

     正規表現は、diffドライバーまたは構成オプション(configuration
     option)を介して設定することもできます。 gitattributes(5) または
     git-config(1) を参照してください。これを指定すると、diffドライバー
     または構成設定(configuration settings)が明示的にオーバーライドされ
     ます。diffドライバーは構成設定を上書きします。

‘--color-words[=<regex>]’
     ‘--word-diff=color’ に ‘--word-diff-regex=<regex>’ を加えたものに相
     当します(正規表現が指定されている場合)。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--check’
     変更によって競合マーカーまたは空白エラーが発生した場合に警告します
     。空白エラーと見なされるものは、 ‘core.whitespace’ 構成によって制御
     されます。 デフォルトでは、末尾の空白(空白のみで構成される行を含む
     )と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空
     白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータ
     スで終了します。なお、 –exit-code とは互換性がありません。

‘--ws-error-highlight=<kind>’
     diffの ‘context’ または ‘old’ または ‘new’ 行の空白エラーを強調表示
     します。複数の値はコンマで区切られ、 ‘none’ は前の値をリセットし、
     ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は old、new、
     context の省略形です。このオプションが指定されておらず、構成変数
     ‘diff.wsErrorHighlight’ が設定されていない場合、 ‘new’ 行の空白エラ
     ーのみが強調表示されます。空白エラーは ‘color.diff.whitespace’ で色
     分けされています。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。 ‘--patch’ の機能を含んでいます。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     名前の変更(renames)を検知する。 ‘n’ が指定されている場合、それは類
     似性インデックスのしきい値です (つまり、ファイルのサイズと比較した
     追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以上が変更され
     ていない場合、 Gitが削除/追加のペアを名前変更と見なす必要があること
     を意味します。 ‘%’ 記号がない場合、数値は小数として読み取られ、その
     前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、‘-M50%’ と同
     じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検出を正確な
     名前変更に制限するには、 ‘-M100%’ を使用します。 デフォルトの類似性
     インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]’
     追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更
     (Rename)されたファイル、タイプが変更されたファイル(T)、マージされて
     いないファイル(U)、不明なファイル(X)、またはペアリングが壊れている
     ファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合
     わせを使用できます。 組み合わせに ‘*’ (全てまたは無し)が追加される
     と、比較で他の基準に一致するファイルがある場合、すべてのパスが選択
     されます。 他の基準に一致するファイルがない場合、何も選択されません
     。

     また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定し
     ます。例えば ‘--diff-filter=ad’ は、追加および削除されたパスを除外
     します。

     注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意
     してください。 たとえば、インデックスから作業ツリーへのdiffにエント
     リを追加することはできません(diffに含まれるパスのセットは、インデッ
     クスの内容によって制限されるため)。 同様に、これらのタイプの検出が
     無効になっている場合、コピーおよび名前変更されたエントリは表示され
     ません。

‘-S<string>’
     ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の
     差分を調べます。スクリプターが使用することを目的としています。

     (構造体など)コードの正確なブロックを探していて、そのブロックが最初
     に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し
     使用して、プリイメージ(preimage)内の興味深いブロックを ‘-S’ にフィ
     ードバックし、そしてあなたはそれをブロックの最初のバージョンを取得
     するまで続けます。

     バイナリファイルも検索されます。

‘-G<regex>’
     パッチテキストに <regex> にマッチする 追加/削除 された行が含まれて
     いる差分を探します。

     ‘-S<regex> --pickaxe-regex’ と ‘-G<regex>’ の違いを説明するために、
     同じファイル内で以下のdiffを使用してコミットすることを検討してくだ
     さい:

          +    return frotz(nitfol, two->ptr, 1, 0);
          ...
          -    hit = frotz(nitfol, mf2.ptr, 1, 0);

     ‘git log -G"frotz\(nitfol"’ はこのコミットを表示しますが、 ‘git log
     -S"frotz\(nitfol" --pickaxe-regex’ は表示しません(その文字列の出現
     回数が変更されなかったため)。

     ‘--text’ が提供されていない限り、 textconv フィルターのないバイナリ
     ファイルのパッチは無視されます。

     詳細については gitdiffcore(7) の「pickaxe」エントリを参照してくださ
     い。

‘--find-object=<object-id>’
     指定されたオブジェクトの出現回数を変更する違いを探します。 ‘-S’ と
     同様に、引数だけが異なり、特定の文字列ではなく特定のオブジェクト
     IDを検索します。

     オブジェクトは、ブロブまたはサブモジュールのコミットにすることがで
     きます。 これは、 ‘git-log’ の ‘-t’ オプションがツリーも探すことを
     意味します。

‘--pickaxe-all’
     ‘-S’ または ‘-G’ が変更を見つけたら、 <string> の変更を含むファイル
     だけでなく、その変更セット(changeset)のすべての変更を表示します。

‘--pickaxe-regex’
     ‘-S’ に指定した <string> を拡張POSIX正規表現として扱います。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘-R’
     2つの入力を交換します。 つまり、インデックスまたはディスク上のファ
     イルとツリーの内容の違いを表示します。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--exit-code’
     diff(1）と同様のコードでプログラムを終了させます。つまり、違いがあ
     った場合は 1 で終了し、 0 は違いがないことを意味します。

‘--quiet’
     プログラムのすべての出力を無効にします。 ‘--exit-code’ を意味します
     。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

‘-1 --base’
‘-2 --ours’
‘-3 --theirs’
     作業ツリーを、「base」バージョン(ステージ #1)または「our branch」
     (私達のブランチ)(ステージ #2)または「their branch」(彼らのブランチ
     )(ステージ #3) と比較します。 インデックスには、マージされていない
     エントリの場合、つまり競合を解決している場合にのみ、これらのステー
     ジが含まれます。 詳細については、 git-read-tree(1) の「3-Way Merge」
     セクションを参照してください。

‘-0’
     マージされていないエントリのdiff出力を省略し、「Unmerged」とだけ表
     示します。 作業ツリーをインデックスと比較する場合にのみ使用できます
     。

<path>…
     <paths>パラメータを指定すると、diffを名前付きパスに制限するために使
     用されます(あなたはディレクトリ名を指定して、その下にあるすべてのフ
     ァイルのdiffを取得できます)。

Raw output format
*****************

‘git-diff-index’ と ‘git-diff-tree’ と ‘git-diff-files’ と ‘git diff
--raw’ からの生の出力形式は非常に似ています。

   これらのコマンドはすべて、2つのセットを比較します。なお、比較されるも
のは異なります:

git-diff-index <tree-ish>
     <tree-ish> とファイルシステム上のファイルを比較します。

git-diff-index –cached <tree-ish>
     <tree-ish> とインデックスを比較します。

git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>…]
     2つの引数で指定されたツリーを比較します。

git-diff-files [<pattern>…]
     インデックスとファイルシステム上のファイルを比較します。

   "git-diff-tree" コマンドは、比較対象のハッシュ値を出力することで出力
を開始します。その後、すべてのコマンドは、変更されたファイルごとに1つの
出力行を出力します。

   出力行は以下のようにフォーマットされます:

     in-place edit  :100644 100644 bcd1234 0123456 M file0
     copy-edit      :100644 100644 abcd123 1234567 C68 file1 file2
     rename-edit    :100644 100644 abcd123 1234567 R86 file1 file3
     create         :000000 100644 0000000 1234567 A file4
     delete         :100644 000000 1234567 0000000 D file5
     unmerged       :000000 000000 0000000 0000000 U file6

   つまり、左から右へ:

  1. コロン(:)

  2. "src" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  3. 空白

  4. "dst" のモード。作成(creation)またはマージされていない(unmerged)場
     合は 000000

  5. 空白

  6. "src" のsha1。作成(creation)またはマージされていない(unmerged)場合
     は 0{40}

  7. 空白

  8. "dst" のsha1。作成(creation)またはマージされていない(unmerged)また
     は作業ツリーにある場合は 0{40}

  9. 空白

  10. ステータスの後に、オプションの「スコア数」("score" number)が続きま
     す

  11. ‘-z’ オプションが使用されている場合はタブまたはNUL

  12. "src" のパス

  13. ‘-z’ オプションが使用されている場合タブまたはNUL。ステータスCまた
     はRにのみ存在します

  14. "dst" のパス。ステータスCまたはRにのみ存在します

  15. LFでレコードを終了します。 ‘-z’ オプションが使用されている場合は
     NULでレコードを終了します。

   ステータス文字の種類は以下のとおり:

   • A: ファイルの追加

   • C: ファイルを新しいファイルにコピー

   • D: ファイルの削除

   • M: ファイルの内容やモードの変更

   • R: ファイル名の名前変更

   • T: ファイルのタイプを変更

   • U: ファイルはマージされていません(コミットする前にマージを完了する
     必要があります)

   • X: 「不明な」変更タイプ(おそらくバグです。報告してください)

   ステータス文字CとRの後には常にスコアが続きます(移動またはコピーのソー
スとターゲットの間の類似性のパーセンテージを示します)。ステータス文字Mの
後には、ファイルの書き換えのスコア(非類似度のパーセンテージを示す)が続く
場合があります。

   <sha1> は、ファイルがファイルシステム上で新規で、インデックスと同期し
ていない場合、すべて0として表示されます。

   例:

     :100644 100644 5be4a4a 0000000 M file.c

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、通常の文字以外(unusual characters)を含むパス名が引用符で囲
まれます(git-config(1) 参照)。 ‘-z’ を使用すると、ファイル名がそのまま出
力され、行はNULバイトで終了します。

diff format for merges
**********************

"git-diff-tree" と "git-diff-files" と "git-diff –raw" は、 ‘-c’ または
‘--cc’ オプションを使用して、マージコミットに対してもdiff出力を生成でき
ます。出力は、以下の点で上記の形式とは異なります:

  1. 親ごとにコロン(:)があります

  2. より多くの "src" モードと "src" sha1があります

  3. statusは、各親のステータス文字を連結したものです

  4. オプションの「スコア数」はありません

  5. ファイルのタブ区切りのパス名

   ‘-c’ および ‘ -cc‘ の場合、履歴のいずれかの側でファイルの名前が変更さ
れた場合でも、宛先(dst)または最終パスのみが表示されます。
‘--combined-all-paths’ を使用すると、各親のパスの名前が表示され、それに
続いてマージコミットのパスの名前が表示されます。

   例: ‘--combined-all-paths’ を使用しない ‘-c’ および ‘--cc’ の場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       phooey.c

   例: ‘-c’ または ‘--cc’ のいずれかに ‘--combined-all-paths’ が追加され
た場合:

     ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM       desc.c  desc.c  desc.c
     ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM       foo.sh  bar.sh  bar.sh
     ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR       fooey.c fuey.c  phooey.c

   注意: ’combined diff’は、すべての親から変更されたファイルのみをリスト
することに注意してください。

Generating patch text with -p
*****************************

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、
git-diff-tree(1) 、 git-diff-files(1) に ‘-p’ オプションを付けて実行する
とパッチテキストを生成します。パッチテキストの作成は、
‘GIT_EXTERNAL_DIFF’ と ‘GIT_DIFF_OPTS’ 環境変数( git(1) 参照)、および
‘diff’ 属性( gitattributes(5) 参照)を介してカスタマイズできます。

   -pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります:

          diff --git a/file1 b/file2

     名前の変更/コピーが含まれない限り、 ‘a/’ と ‘b/’ のファイル名は同じ
     です。 特に、作成または削除の場合でも、 ‘a/’ または ‘b/’ ファイル名
     の代わりに ‘/dev/ null’ が使用されることはありません。

     名前変更/コピーが含まれる場合、 ‘file1’ と‘file2‘ は、それぞれ名前
     変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファ
     イルの名前を示します。

  2. その後に、1つ以上の拡張ヘッダー行達が続きます:

          old mode <mode>
          new mode <mode>
          deleted file mode <mode>
          new file mode <mode>
          copy from <path>
          copy to <path>
          rename from <path>
          rename to <path>
          similarity index <number>
          dissimilarity index <number>
          index <hash>..<hash> <mode>

     ファイルモードは、ファイルタイプとファイル許可ビットを含む6桁の8進
     数として出力されます。

     拡張ヘッダーのパス名には、 ‘a/’ および ‘b/’ プレフィックスは含まれ
     ません。

     類似インデックス(similarity index)は変更されていない行のパーセンテ
     ージであり、非類似インデックス(dissimilarity index)は変更された行の
     パーセンテージです。これは切り捨てられた整数であり、その後にパーセ
     ント記号が続きます。したがって、100％の類似インデックス値は2つの等
     しいファイルを表し、100％の非類似性は古いファイルから新しいファイル
     に移行された行がないことを意味します。

     インデックス行には、変更前後のブロブオブジェクト名が含まれます。
     <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の
     場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、
     構成変数 ‘core.quotePath’ で説明されているように引用符で囲まれてい
     ます( git-config(1)参照)。

  4. 出力内のすべての ‘file1’ ファイルはコミット前のファイルを参照し、す
     べての ‘file2’ ファイルはコミット後のファイルを参照します。各変更を
     各ファイルに順番に適用するのは誤りです。たとえば、以下のパッチはaと
     bを交換します:

          diff --git a/a b/b
          rename from a
          rename to b
          diff --git a/b b/a
          rename from b
          rename to a

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されていま
     す。特定の言語に合わせてこれを調整する方法の詳細については、
     gitattributes(5) の "Defining a custom hunk-header" を参照してくだ
     さい。

Combined diff format
********************

diffを生成するコマンドは、マージを表示するときに ‘-c’ または ‘--cc’ オプ
ションを使用して「合成diff」(combined diff)を生成できます。これは
git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形
式です。 注意: これらのコマンドのいずれかに適切な ‘--diff-merges’ オプシ
ョンを指定して、特定の形式で差分を強制的に生成できることにも注意してくだ
さい。

   合成diff形式は以下のようになります:

     diff --combined describe.c
     index fabadb8,cc95eb0..4866510
     --- a/describe.c
     +++ b/describe.c
     @@@ -98,20 -98,12 +98,20 @@@
             return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

     - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
     ++static void describe(char *arg, int last_one)
       {
      +      unsigned char sha1[20];
      +      struct commit *cmit;
             struct commit_list *list;
             static int initialized = 0;
             struct commit_name *n;

      +      if (get_sha1(arg, sha1) < 0)
      +              usage(describe_usage);
      +      cmit = lookup_commit_reference(sha1);
      +      if (!cmit)
      +              usage(describe_usage);
      +
             if (!initialized) {
                     initialized = 1;
                     for_each_ref(get_name);

  1. まず "git diff" ヘッダーがあり、以下のようになります( ‘-c’ オプショ
     ンが使用されている場合):

          diff --combined file

     または、以下のようになります( ‘--cc’ オプションが使用されている場合
     ):

          diff --cc file

  2. その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマ
     ージを示しています):

          index <hash>,<hash>..<hash>
          mode <mode>,<mode>..<mode>
          new file mode <mode>
          deleted file mode <mode>,<mode>

     ‘mode <mode>,<mode>..<mode>’ 行は、<mode> の少なくとも1つが他の
     <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動
     (名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの
     <tree-ish> のdiffで機能するように設計されており、合成diff形式では使
     用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます

          --- a/file
          +++ b/file

     従来の統一diff形式の2行ヘッダーと同様に、 ‘/dev/null’ は、作成また
     は削除されたファイルを通知するために使用されます。

     ただし、 –combined-all-paths オプションが指定されている場合、2行の
     from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダー
     が取得されます。ここで、 N はマージコミットの親の数です。

          --- a/file
          --- a/file
          --- a/file
          +++ b/file

     この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち
     、別の親のファイルの元の名前を確認できます。

  4. チャンクヘッダーの形式が変更され、誤って ‘patch-p1’ にフィードされ
     るのを防ぎます。合成差分形式は、マージコミットの変更を確認するため
     に作成されたものであり、適用されることを意図したものではありません
     。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:

          @@@ <from-file-range> <from-file-range> <to-file-range> @@@

     合成diff形式のチャンクヘッダーには親の数+1の ‘@’ 文字があります。

   従来の統一diff形式とは異なり、2つのファイルAとBが、 ‘-’ (マイナスは
Aに表示されますが、Bでは削除されます) または ‘+’ (プラスはAにはありませ
んが、Bには追加されます)、または ‘" "’（スペースは変更なし) プレフィック
スを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1,
file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示し
ます。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどの
ように異なるかを示します。

   列Nの ‘-’ 文字は、その行が fileN に表示されているが、結果には表示され
ていないことを意味します。 列Nの ‘+’ 文字は、結果に行が表示され、 fileN
にその行がないことを意味します(つまり、その親の観点から見て行が追加され
たことを示す)。

   上記の出力例では、関数のシグネチャが両方のファイルから見て変更されて
います(したがって、 file1 と file2 の両方から2つの ‘-’ が削除され、さら
に ‘++’ が追加されたため、 file1 と file2 のどちらにも表示されません)。
また、他の8行は file1 と同じですが、 file2 には表示されません(したがって
、接頭辞として ‘+’ が付けられます)。

   ‘git diff-tree -c’ で表示される場合、マージコミットの親をマージ結果と
比較します(つまり、 file1..fileN が親です)。 ‘git diff-files -c’ で表示
される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり
、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別
名「彼らのバージョン」です)。

other diff formats
******************

‘--summary’ オプションは、新しく追加、削除、名前変更、およびコピーされた
ファイルを説明します。‘--stat’ オプションは、 diffstat(1) グラフ を出力
に追加します。これらのオプションは、 ‘-p’ などの他のオプションと組み合わ
せることができ、人間が読むことを目的としています。

   名前の変更またはコピーを伴う変更を表示する場合、 ‘--stat’ 出力は、パ
ス名の共通のプレフィックスとサフィックスを組み合わせることにより、パス名
をコンパクトにフォーマットします。 たとえば、4行を変更(modify)しながら
‘arch/i386/Makefile’ を ‘arch/x86/Makefile’ に移動(move)する変更
(change)は、次のように表示されます:

     arch/{i386 => x86}/Makefile    |   4 +--

   ‘--numstat’ オプションは diffstat(1) 情報を提供しますが、人間ではなく
ソフトウェアで読むのを容易にするように設計されています。 ‘--numstat’ 出
力のエントリは以下のようになります:

     1       2       README
     3       1       arch/{i386 => x86}/Makefile

   この形式は、左から右へ:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. パス名(おそらく rename/copy 情報を含む)

  6. 改行

   ‘-z’ 出力オプションが有効な場合、出力は以下のようにフォーマットされま
す:

     1       2       README NUL
     3       1       NUL arch/i386/Makefile NUL arch/x86/Makefile NUL

   これは:

  1. 追加行数

  2. タブ

  3. 削除行数

  4. タブ

  5. NUL(rename/copy された場合のみ存在します)

  6. プリイメージのパス名

  7. NUL(rename/copy された場合のみ存在します)

  8. ポストイメージのパス名(rename/copy された場合のみ存在します)

  9. NUL

   名前が変更された場合のプリイメージパスの前の追加の ‘NUL’ は、出力を読
み取るスクリプトが、先読みせずに、読み取られている現在のレコードがシング
ルパスレコードであるか、名前変更/コピーレコードであるか、を判断できるよ
うにするためです。追加および削除された行を読み取った後、 ‘NUL’ まで読み
取るとパス名が生成されますが、それが ‘NUL’ の場合、レコードには2つのパス
が表示されます。

EXAMPLES
********

あなたの作業ツリーを確認するさまざまな方法
          $ git diff            (1)
          $ git diff --cached   (2)
          $ git diff HEAD       (3)

     See (1).
          次のコミットのためにまだステージングされていない作業ツリーの変
          更。

     See (2).
          インデックスと最後のコミットの間の変更。 ‘-a’ オプションなしで
          ‘git commit’ を実行した場合にコミットする内容です。

     See (3).
          最後のコミット以降の作業ツリーの変更。 ‘git commit -a’ を実行
          した場合にコミットする内容です。

任意のコミットとの比較
          $ git diff test            (1)
          $ git diff HEAD -- ./test  (2)
          $ git diff HEAD^ HEAD      (3)

     See (1).
          現在のブランチの先端を使用する代わりに、「テスト」ブランチの先
          端と比較してください。

     See (2).
          「test」ブランチの先端と比較する代わりに、現在のブランチの先端
          と比較しますが、比較をファイル「test」に限定します。

     See (3).
          最後のコミットと、最後のコミットのその前のバージョンを比較しま
          す。

Comparing branches
          $ git diff topic master    (1)
          $ git diff topic..master   (2)
          $ git diff topic...master  (3)

     See (1).
          topicの先端とmasterブランチの間の変更。

     See (2).
          上と同じ。

     See (3).
          topicブランチが開始されてからmasterブランチで発生した変更。

Limiting the diff output
          $ git diff --diff-filter=MRC            (1)
          $ git diff --name-status                (2)
          $ git diff arch/i386 include/asm-i386   (3)

     See (1).
          変更、名前変更、コピーのみを表示し、追加や削除は表示しません。

     See (2).
          名前と変更の性質のみを表示し、実際の差分出力は表示しません。

     See (3).
          diff出力を名前付きサブツリーに制限します。

diff出力をこねくりまわす(muging)
          $ git diff --find-copies-harder -B -C  (1)
          $ git diff -R                          (2)

     See (1).
          名前の変更、コピー、完全な書き換えを見つけるために余分なサイク
          ルを費やします(非常に高価です)。

     See (2).
          逆のdiffを出力します。

SEE ALSO
********

diff(1), git-difftool(1), git-log(1), gitdiffcore(7),
git-format-patch(1), git-apply(1), git-show(1)

GIT
***

Part of the git(1) suite

Name
****

git-difftool — 一般的なdiffツールを使用して変更を表示します

Synopsis
********

     git difftool [<options>] [<commit> [<commit>]] [–] [<path>…]

DESCRIPTION
***********

‘git difftool’ は、一般的なdiffツールを使用してリビジョン間でファイルを
比較および編集できるようにするGitコマンドです。 ‘git difftool’ は ‘git
diff’ のフロントエンドであり、同じオプションと引数を受け入れます。
git-diff(1) を参照してください。

OPTIONS
*******

‘-d’
‘--dir-diff’
     変更したファイルを一時的な場所にコピーし、それらに対してディレクト
     リdiffを実行します。 このモードは、diffツールを起動する前にプロンプ
     トを表示することはありません。

‘-y’
‘--no-prompt’
     diffツールを起動する前にプロンプトを表示しないでください。

‘--prompt’
     diffツールを呼び出す前にプロンプトを表示します。 これがデフォルトの
     振る舞いです。 オプションは、構成設定を上書きするために提供されてい
     ます。

‘--rotate-to=<file>’
     指定のパスのdiffの表示から開始します。これ以前のパスは最後の後ろに
     回されます(訳注: ‘git difftool’ で a,b,c,d,e の場合、
     ‘--rotate-to=c’ とすると、 c,d,e,a,b,c の順になる)

‘--skip-to=<file>’
     その前のすべてのパスをスキップして、指定されたパスのdiffの表示から
     開始します(訳注: a,b,c,d,e の場合、 ‘--skip-to=c’ は c,d,e)

‘-t <tool>’
‘--tool=<tool>’
     <tool> で指定されたdiffツールを使用します。 有効な値には emergeや
     kompareやmeldやvimdiffも含まれています。有効な<tool>設定のリストに
     ついては、 ‘git difftool --tool-help’ を実行してください。

     diffツールが指定されていない場合、 ‘git difftool’ は構成変数
     ‘diff.tool’ を使用します。 構成変数 ‘diff.tool’ が設定されていない
     場合、 ‘git difftool’ は適切なデフォルトを選択します。

     あなたは構成変数 ‘difftool.<tool>.path’ を設定することにより、ツー
     ル(<tool>)へのフルパスを明示的に指定できます。 たとえば、
     ‘difftool.kdiff3.path’ を設定することにより、kdiff3への絶対パスを構
     成できます。 それ以外の場合、 ‘git difftool’ は、ツールがPATH上にあ
     ると想定します。

     既知のdiffツールの1つを実行する代わりに、構成変数
     ‘difftool.<tool>.cmd’ で、呼び出すコマンドラインを指定することによ
     り、 ‘git difftool’ をカスタマイズして代替プログラムを実行できます
     。

     このツールを使用して(‘-t’ または ‘--tool’ オプションまたは
     ‘diff.tool’ 構成変数を介して、) ‘git difftool’ を呼び出すと、構成さ
     れたコマンドラインが次の変数を使用して呼び出されます。 ‘$LOCAL’ は
     、diff pre-imageの内容を含む一時ファイルの名前に設定され、
     ‘$REMOTE’ は、diff post-imageの内容を含む一時ファイルの名前に設定さ
     れます。 ‘$MERGED’ は、比較されるファイルの名前です。 ‘$BASE’ は、
     カスタムマージツールコマンドとの互換性のために提供されており、
     ‘$MERGED’ と同じ値です。

‘--tool-help’
     ‘--tool’ で使用できるdiffツールのリストを出力します。

‘--[no-]symlinks’
     ‘git difftool’ のデフォルトの動作は、 ‘--dir-diff’ モードで実行した
     ときに、作業ツリーへのシンボリックリンクを作成することです。つまり
     、比較の右側は、作業ツリーのファイルそのものです。

     ‘--no-symlinks’ を指定すると、代わりにコピーを作成するように ‘git
     difftool’ に指示します。 ‘--no-symlinks’ はWindowsのデフォルトです
     。

‘-x <command>’
‘--extcmd=<command>’
     diffを表示するためのカスタムコマンドを指定します。 ‘git-difftool’ は
     、構成されたデフォルトを無視し、このオプションが指定されている場合
     は ‘$command $LOCAL $REMOTE’ を実行します。 さらに、‘$BASE‘が環境に
     設定されます。

‘-g’
‘--[no-]gui’
     ‘git-difftool’ が ‘-g’ または ‘--gui’ オプションで呼び出されると、
     デフォルトのdiffツールが ‘diff.tool’ ではなく設定された
     ‘diff.guitool’ 変数から読み取られます。 ‘--no-gui’ オプションを使用
     して、この設定を上書きできます。 ‘diff.guitool’ が設定されていない
     場合、ツールが見つかるまで、 ‘merge.guitool’ 、 ‘diff.tool’ 、
     ‘merge.tool’ の順でフォールバックします。

‘--[no-]trust-exit-code’
     ‘git-difftool’ は、各ファイルで個別にdiffツールを呼び出します。
     diff分ツールによって報告されたエラーは、デフォルトでは無視されます
     。呼び出されたdiffツールがゼロ以外の終了コードを返したときに
     ‘--trust-exit-code`を使用して、 `git-difftool’ を終了させます。

     ‘git-difftool’ は、 ‘--trust-exit-code’ が使用されている場合、呼び
     出されたツールの終了コードを転送します。

   サポートされているオプションの完全なリストについては、 git-diff(1) を
参照してください。

CONFIG VARIABLES
****************

同等のdifftoolが定義されていない場合、 ‘git difftool’ は ‘git mergetool’
構成変数にフォールバックします。

diff.tool
     使用するデフォルトのdiffツール。

diff.guitool
     ‘--gui’ が指定されている場合に使用するデフォルトのdiffツール。

difftool.<tool>.path
     指定されたツール(<tool>)のパスを上書きします。 これは、あなたのツー
     ルがPATH上にない場合に役立ちます。

difftool.<tool>.cmd
     指定した差分ツール(<tool>)を呼び出すコマンドを指定します。

     詳細については、上記の ‘--tool=<tool>’ オプションを参照してください
     。

difftool.prompt
     diffツールを呼び出す前にプロンプトを表示します。

difftool.trustExitCode
     呼び出されたdiffツールがゼロ以外の終了ステータスを返した場合は、
     difftoolを終了します。

     詳細については、上記の ‘--trust-exit-code’ オプションを参照してくだ
     さい。

SEE ALSO
********

git-diff(1)
     コミット、コミット、作業ツリー等の間の変更を表示する

git-mergetool(1)
     マージ競合解決ツールを実行して、マージ競合を解決します

git-config(1)
     リポジトリまたはグローバルオプションの取得と設定

GIT
***

Part of the git(1) suite

Name
****

git-fast-export — Gitデータエクスポーター

Synopsis
********

     git fast-export [<options>] | git fast-import

DESCRIPTION
***********

このプログラムは、指定されたリビジョンを ‘git fast-import’ にパイプする
のに適した形式でダンプします。

   人間が読める形式のバンドル置換として(linkgit：git-bundle[1] 参照)、ま
たは履歴の書き換えを行うために ‘git fast-import’ にフィードする前に編集
できる形式として使用できます(‘git filter-repo’ などのツールの能力に依存
します)。

OPTIONS
*******

‘--progress=<n>’
     インポート中に ‘git fast-import’ で表示されるように、<n>オブジェク
     トごとに ‘progress’ ステートメントを挿入します。

‘--signed-tags=(verbatim|warn|warn-strip|strip|abort)’
     署名付きタグの処理方法を指定します。 エクスポート後の変換によってタ
     グ名が変更される可能性があるため(リビジョンを除外する場合にも発生す
     る可能性があります)、署名は一致しません。

     ‘abort’ (デフォルト)を要求すると、このプログラムは署名されたタグに
     遭遇すると停止します。 ‘strip’ を使用すると、タグは黙って署名なしに
     なり、 ‘warn-strip’ を使用すると、タグは署名なしになりますが、警告
     が表示されます。 ‘verbatim’ を使用すると、タグは黙ってにエクスポー
     トされ、 ‘warn’ を使用すると、 エクスポートされますが、警告が表示さ
     れます。

‘--tag-of-filtered-object=(abort|drop|rewrite)’
     タグ付けされたオブジェクトが除外される、タグの処理方法を指定します
     。 エクスポートするリビジョンとファイルはパスによって制限される可能
     性があるため、タグ付けされたオブジェクトは完全にフィルタリングされ
     る可能性があります。

     ‘abort’ (デフォルト)を要求すると、このプログラムはそのようなタグに
     遭遇すると停止します。 ‘drop’ を使用すると、そのようなタグが出力か
     ら省略されます。 ‘rewrite’ を使用すると、タグ付けされたオブジェクト
     がコミットの場合、タグを書き換えて祖先のコミットにタグを付けます(親
     の書き換えを介して、 git-rev-list(1) 参照)

‘-M’
‘-C’
     git-diff(1) のマニュアルページで説明されているように、移動 および
     /または コピーの検出を実行し、それを使用して、出力ダンプに rename お
     よび copy コマンドを生成します。

     注意: これらのオプションを指定した場合、このコマンドの以前のバージ
     ョンは警告を出さずに誤った結果を生成することに注意してください。

‘--export-marks=<file>’
     完了すると、内部マークテーブルを<file>にダンプします。 マークは1行
     に1つずつ ‘:markid SHA-1’ として書き込まれます。 リビジョンのマーク
     のみがダンプされます。 ブロブのマークは無視されます。 バックエンド
     はこのファイルを使用して、インポートが完了した後にインポートを検証
     したり、増分実行(incremental runs)全体でマークテーブルを保存したり
     できます。 <file>は完了時にのみ開かれ、切り捨てられるため、同じパス
     を ‘--import-marks’ に安全に指定することもできます。 新しいオブジェ
     クトが マーク/エクスポート されていない場合、ファイルは書き込まれま
     せん。

‘--import-marks=<file>’
     入力を処理する前に、<file>で指定されたマークをロードします。 入力フ
     ァイルは存在し、読み取り可能であり、 ‘--export-marks’ によって生成
     されたものと同じ形式を使用する必要があります。

‘--mark-tags’
     マークIDでブロブとコミットにラベルを付けることに加えて、タグにもラ
     ベルを付けます。 これは、 ‘--export-marks’ および ‘--import-marks’
     と組み合わせて使用すると便利です。また、ネストされたタグのエクスポ
     ートにも役立ちます(そして必要です)。 それは他のケースを損なうことは
     なく、デフォルトになりえますが、多くのfast-importフロントエンドは、
     マーク識別子を持つタグを受け入れる準備ができていません。

     すでにマークされているコミット(またはタグ)は、再度エクスポートされ
     ません。 バックエンドが同様の ‘--import-marks’ ファイルを使用する場
     合、これにより、複数実行に渡ってマークを同一に保つことにより、リポ
     ジトリの増分双方向エクスポートが可能になります。

‘--fake-missing-tagger’
     一部の古いリポジトリには、taggerのないタグがあります。 fast-importプ
     ロトコルはそれについてかなり厳格であり、それを許可しません。 したが
     って、出力を高速にインポートできるように、taggerを偽造します。

‘--use-done-feature’
     ‘feature done’ 句(stanza)でストリームを開始し、 ‘done’ コマンドで終
     了します。

‘--no-data’
     ブロブオブジェクトの出力をスキップし、代わりに元のSHA-1ハッシュを介
     してブロブを参照します。 これは、個々のファイルの内容に触れることな
     く、リポジトリのディレクトリ構造または履歴を書き換える場合に役立ち
     ます。 結果のストリームは、必要なオブジェクトがすでに含まれているリ
     ポジトリでのみ使用できることに注意してください。

‘--full-tree’
     このオプションにより、fast-exportは、コミットごとに ‘deleteall’ デ
     ィレクティブを発行し、その後にコミット内のすべてのファイルの完全な
     リストを発行します(コミットの最初の親とは異なるファイルをリストする
     だけではありません)。

‘--anonymize’
     履歴と保存されたツリーの形を維持しながら、リポジトリのコンテンツを
     匿名化(anonymize)します。 以下の「ANONYMIZING」のセクションを参照し
     てください。

‘--anonymize-map=<from>[:<to>]’
     匿名化(anonymized)された出力でトークン ‘<from>’ を ‘<to>’ に変換し
     ます。 ‘<to>`を省略した場合は、 `<from>’ をそれ自体にマップします
     (つまり、匿名化しません)。 以下の「ANONYMIZING」セクションを参照し
     てください。

‘--reference-excluded-parents’
     デフォルトでは、 ‘git fast-export master~5..master’ などのコマンド
     を実行すると、コミット master~5 が含まれなくなり、master~4 の親とし
     て master~5 がなくなります( ただし、古い master~4 と 新しい
     master~4 の両方に同じファイルがあります)。
     ‘--reference-excluded-parents’ を使用して、代わりに、sha1sum によっ
     て除外された履歴範囲内のコミットをストリームに参照させます。 結果の
     ストリームは、必要な親コミットがすでに含まれているリポジトリでのみ
     使用できることに注意してください。

‘--show-original-ids’
     コミットとブロブの出力に追加のディレクティブ ‘original-oid
     <SHA1SUM>’ を追加します。 このようなディレクティブは
     git-fast-import などのインポーターによって無視される可能性がありま
     すが、中間フィルター(たとえば、古いコミットを参照するコミットメッセ
     ージの書き換え、またはIDによるブロブの削除)に役立つ場合があります。

‘--reencode=(yes|no|abort)’
     コミットオブジェクトで ‘encoding’ ヘッダーを処理する方法を指定しま
     す。 ‘abort’ (デフォルト)を要求すると、このプログラムはそのようなコ
     ミットオブジェクトに遭遇すると停止します。 ‘yes’ を使用すると、コミ
     ットメッセージがUTF-8に再エンコードされます。 ‘no’ を使用すると、元
     のエンコーディングが保持されます。

‘--refspec’
     指定されたrefspecをエクスポートされた各refに適用します。複数指定す
     ることができます。

[<git-rev-list-args>…]
     エクスポートする特定のオブジェクトと参照を指定する、 ‘git
     rev-parse’ および ‘git rev-list’ に受け入れられる引数のリスト。 た
     とえば、 ‘master~10..master’ を使用すると、現在のmaster参照が、10番
     目の祖先のコミット以降に追加されたすべてのオブジェクト、および
     (–reference-excluded-parentsオプションが指定されていない場合、)
     master~9 と master~10 に共通のすべてのファイルとともにエクスポート
     されます。

EXAMPLES
********

     $ git fast-export --all | (cd /empty/repository && git fast-import)

   これにより、リポジトリ全体がエクスポートされ、既存の空のリポジトリに
インポートされます。 UTF-8でないコミットの再エンコードを除いて、1対1のミ
ラーになります。

     $ git fast-export master~5..master |
             sed "s|refs/heads/master|refs/heads/other|" |
             git fast-import

   これにより、 ‘master~5..master’ から ‘other’ という新しいブランチが作
成されます(つまり、 ‘master’ に線形履歴がある場合は、最後の5回のコミット
が必要になります)。

   注意: これは、そのリビジョン範囲によって参照されるブロブとコミットメ
ッセージのいずれにも文字列 ‘refs/heads/master’ が含まれていないことを前
提としていることに注意してください。

ANONYMIZING(匿名化)
*******************

‘--anonymize’ オプションが指定されている場合、gitは、いくつかのバグを再
現するのに十分な元のツリーと履歴パターンを保持しながら、リポジトリからす
べての識別情報(identifying information)を削除しようとします。 その目標は
、プライベートリポジトリで見つかったgitバグが匿名化されたリポジトリに残
り、匿名化されたリポジトリをgit開発者と共有してバグの解決に役立てること
です。

   このオプションを使用すると、gitは、出力内のすべての refname、パス、ブ
ロブコンテンツ、コミットメッセージ、タグメッセージ、名前、電子メールアド
レス を匿名化されたデータに置き換えます。 同じ文字列の2つのインスタンス
は同等に置き換えられます(たとえば、同じ作者による2つのコミットは、出力に
同じ匿名の作者が含まれますが、元の作者文字列とは類似していません)。 コミ
ット、ブランチ、タグの関係、コミット のタイムスタンプは保持されます(ただ
し、コミットメッセージとrefnameは元のメッセージとは似ていません)。 ツリ
ーの相対的な構成は保持されますが(たとえば、10個のファイルと3個のツリーを
持つルートツリーがある場合、出力も保持されます)、それらの名前とファイル
の内容は置き換えられます。

   あなたがgitのバグを見つけたと思う場合は、リポジトリ全体の匿名化された
ストリームをエクスポートすることから始めることができます:

     $ git fast-export --anonymize --all >anon-stream

   次に、そのストリームから作成されたリポジトリでバグが持続することを確
認します(多くのバグは、リポジトリの正確な内容に依存しているため、持続し
ません):

     $ git init anon-repo
     $ cd anon-repo
     $ git fast-import <../anon-stream
     $ ... test your bug ...

   匿名化されたリポジトリにバグが表示されている場合は、通常のバグレポー
トと一緒に ‘anon-stream’ を共有する価値があるかもしれません。 匿名化され
たストリームは非常によく圧縮されるため、gzipすることをお勧めします。スト
リームを調べてプライベートデータが含まれていないことを確認する場合は、送
信する前にストリームを直接確認できます。 また、試してみることもできます:

     $ perl -pe 's/\d+/X/g' <anon-stream | sort -u | less

   これは、すべての一意の行を表示します("User 0"、 "User 1" などを "User
X" に折りたたむために、数字を "X" に変換します)。 これにより、出力がはる
かに小さくなり、通常、ストリームにプライベートデータがないことをすばやく
確認するのは簡単です。

   一部のバグを再現するには、特定のコミットまたはパスを参照する必要があ
る場合があります。これは、refnameおよびパスが匿名化された後に困難になり
ます。 特定のトークンをそのままにするか、新しい値にマップするように要求
できます。 たとえば、 ‘git rev-list sensitive -- secret.c’ で再現される
バグがある場合は、以下のコマンドを実行できます:

     $ git fast-export --anonymize --all \
           --anonymize-map=sensitive:foo \
           --anonymize-map=secret.c:bar.c \
           >stream

   ストリームをインポートした後、匿名化されたリポジトリで ‘git rev-list
foo -- bar.c’ を実行できます。

   注意: パスとrefnameは、スラッシュ(‘/’)境界でトークンに分割されること
に注意してください。 上記のコマンドは、 ‘subdir/secret.c’ を
‘path123/bar.c’ のようなものとして匿名化します。 次に、あなたは匿名化さ
れたリポジトリで ‘bar.c’ を検索して、最終的なパス名を決定できます。

   最終パス名の参照を簡単にするために、各パスコンポーネントをマップでき
ます。 したがって、‘subdir’ も ‘publicdir’ に匿名化すると、最終的なパス
名は ‘publicdir/bar.c’ になります。

LIMITATIONS
***********

‘git fast-import’ はツリーにタグを付けることができないため、コミットでは
なくツリーを参照するタグが含まれている linux.git リポジトリを完全にエク
スポートすることはできません。

SEE ALSO
********

git-fast-import(1)

GIT
***

Part of the git(1) suite

Name
****

git-fast-import — 高速Gitデータインポーターのバックエンド

Synopsis
********

     frontend | git fast-import [<options>]

DESCRIPTION
***********

このプログラムは通常、エンドユーザーが直接実行したいものではありません。
ほとんどのエンドユーザーは、既存のフロントエンドプログラムの1つを使用し
たいと考えています。このプログラムは、特定の種類の外部ソースをパースし、
そこに保存されているコンテンツを ‘git fast-import’ に送ります。

   fast-importは、標準入力から 混合 コマンド/データストリーム を読み取り
、1つ以上のパックファイルを現在のリポジトリに直接書き込みます。 EOFが標
準入力で受信されると、高速インポートは更新されたブランチとタグの参照を書
き出し、新しくインポートされたデータで現在のリポジトリを完全に更新します
。

   高速インポートバックエンド自体は、空のリポジトリ(‘git init’ によって
すでに初期化されているリポジトリ)にインポートすることも、既存の入力済み
リポジトリを増分更新(incrementally update)することもできます。 特定の外
部ソースからの増分インポートがサポートされているかどうかは、使用している
フロントエンドプログラムによって異なります。

OPTIONS
*******

‘--force’
     コミットが失われる場合でも(新しいコミットには古いコミットが含まれて
     いないため)、変更された既存のブランチを強制的に更新します。

‘--quiet’
     ‘--stats’ で示される出力を無効にし、正常に実行されると、通常、
     fast-importをサイレントにします。 ただし、インポートストリームに、
     ユーザー出力を表示することを目的としたディレクティブ(‘progress‘ディ
     レクティブなど)がある場合も対応するメッセージが表示されます。

‘--stats’
     fast-importが作成したオブジェクト、それらが保存されたパックファイル
     、およびこの実行中にfast-importによって使用されたメモリに関するいく
     つかの基本的な統計を表示します。 この出力の表示は現在デフォルトです
     が、 ‘--quiet’ を使用して無効にすることができます。

‘--allow-unsafe-features’
     ‘feature’ または ‘option’ コマンドを使用して、高速インポートストリ
     ーム自体の一部として多くのコマンドラインオプションを提供できます。
     ただし、これらのオプションの一部は安全ではありません(たとえば、高速
     インポートでリポジトリの外部のファイルシステムにアクセスできるよう
     にするなど)。 これらのオプションはデフォルトで無効になっていますが
     、コマンドラインでこのオプションを指定することで許可できます。 これ
     は現在、 ‘export-marks’ と ‘import-marks’ と
     ‘import-marks-if-exists’ 機能コマンドにのみ影響します。

          高速インポートストリームを生成するプログラムを信頼する場合にのみ、このオプションを有効にしてください。
          このオプションは、独自のコードを実行することがすでに信頼されているため、 `import`
          機能を使用するリモートヘルパーに対して自動的に有効になります。

Options for Frontends
=====================

‘--cat-blob-fd=<fd>’
     ‘get-mark’ と ‘cat-blob’ と ‘ls’ クエリへの応答を、 ‘stdout’ ではな
     くファイルデスクリプタ<fd>に書き込みます。 エンドユーザー向けの
     ‘progress’ 出力を他の出力から分離できるようにします。

‘--date-format=<fmt>’
     フロントエンドが高速インポートに提供する日付のタイプを、 ‘author’ と
     ‘committer’ と‘tagger‘ コマンド内で指定します。 サポートされている
     フォーマットとその構文の詳細については、以下の「Date Formats」を参
     照してください。

‘--done’
     ストリームの最後に ‘done’ コマンドがない場合は、エラーで終了
     (terminate)します。 このオプションは、フロントエンドがストリームの
     書き込みを開始する前に終了する原因となるエラーを検出するのに役立つ
     場合があります。

Locations of Marks Files
========================

‘--export-marks=<file>’
     完了すると、内部マークテーブルを<file>にダンプします。 マークは1行
     に1つずつ ‘:markid SHA-1’ として書き込まれます。 フロントエンドは、
     このファイルを使用して、インポートが完了した後にインポートを検証し
     たり、増分実行(incremental runs)全体でマークテーブルを保存したりで
     きます。 <file>はチェックポイント(または完了)でのみ開かれ(open)、切
     り捨て(truncate)られるため、同じパスを ‘--import-marks’ に安全に指
     定することもできます。

‘--import-marks=<file>’
     入力を処理する前に、<file>で指定されたマークをロードします。 入力フ
     ァイルは存在し、読み取り可能であり、 ‘--export-marks’ によって生成
     されたものと同じ形式を使用する必要があります。 複数のマークのセット
     をインポートするために、オプションを複数回指定できます。 マークが異
     なる値に定義されている場合、最後のファイルが優先されます。

‘--import-marks-if-exists=<file>’
     ‘--import-marks’ と同様ですが、エラーが発生する代わりに、ファイルが
     存在しない場合は黙ってスキップします。

‘--[no-]relative-marks’
     ‘--relative-marks’ を指定した後、 ‘--import-marks=’ と
     ‘--export-marks=’ で指定されたパスは、現在のリポジトリの内部ディレ
     クトリからの相対パスになります。 git-fast-importでは、これはパスが
     ‘.git/info/fast-import’ ディレクトリから相対的であることを意味しま
     す。 ただし、他のインポーターは別の場所を使用する場合があります。

     ‘--(no-)-relative-marks’ を ‘--(import|export)-marks=’ と織り交ぜる
     ことで、相対マークと非相対マークを組み合わせることができます。

Submodule Rewriting
===================

‘--rewrite-submodules-from=<name>:<file>’
‘--rewrite-submodules-to=<name>:<file>’
     <name>で指定されたサブモジュールのオブジェクトIDを値から書き換えま
     す from <file> で使用されるものから to <file> で使用されるものまで
     。同じサブモジュールをインポートする場合、fromマークは ‘git
     fast-export’ によって作成され、toマークは ‘git fast-import’ によっ
     て作成されている必要があります。

     <name>は、コロン文字を含まない任意の文字列にすることができますが、
     対応するマークを指定するときは、両方のオプションで同じ値を使用する
     必要があります。 <name>の値が異なる複数のサブモジュールを指定できま
     す。 対応するペアでこれらのオプションを使用しないのはエラーです。

     これらのオプションは、リポジトリをあるハッシュアルゴリズムから別の
     ハッシュアルゴリズムに変換するときに主に役立ちます。 それらがないと
     、オブジェクトIDを新しいハッシュアルゴリズムに書き込む方法がないた
     め、サブモジュールが検出された場合、fast-importは失敗します。

Performance and Compression Tuning
==================================

‘--active-branches=<n>’
     一度にアクティブを維持するブランチの最大数。 詳細については、下記「
     Memory Utilization」(メモリ使用率)を参照してください。 デフォルトは
     5です。

‘--big-file-threshold=<n>’
     fast-importがデルタを作成しようとするブロブの最大サイズ(バイト単位
     )。 デフォルトは512m(512 MiB)です。 一部のインポーターは、メモリが
     制限されているシステムでこの値を下げることを希望する事があります。

‘--depth=<n>’
     ブロブとツリーの差分化(deltification)の最大デルタ深度。 デフォルト
     は50です。

‘--export-pack-edges=<file>’
     パックファイルを作成した後、データの行を<file>に出力して、パックフ
     ァイルのファイル名と、そのパックファイルに書き込まれた各ブランチの
     最後のコミットをリストします。 この情報は、オブジェクトセットの合計
     が4 GiBパックファイルの制限を超えるプロジェクトをインポートした後に
     役立つ場合があります。 これらのコミットは、 ‘git pack-objects’ の呼
     び出し中にエッジポイントとして使用できるためです。

‘--max-pack-size=<n>’
     各出力パックファイルの最大サイズ。 デフォルトは無制限です。

fastimport.unpackLimit
     git-config(1) 参照

PERFORMANCE
***********

高速インポートの設計により、最小限のメモリ使用量と処理時間で大規模なプロ
ジェクトをインポートできます。 フロントエンドが高速インポートに対応し、
一定のデータストリームをフィードできると仮定すると、10年以上の履歴を保持
し、100,000以上の個別のコミットを含むプロジェクトのインポート時間は、通
常、非常に控えめな(〜$2,000 USD)ハードウェアで、わずか1〜2時間で完了しま
す。

   ほとんどのボトルネックは、外部ソースデータアクセス(ソースがリビジョン
を十分に速く抽出できない)、またはディスクI/O(ディスクがデータを取得する
のと同じ速さで高速インポート書き込み)にあるように見えます。 ソースデータ
が宛先Gitリポジトリとは異なるドライブに保存されている場合、(I/Oの競合が
少ないため)、インポートはより高速に実行されます。

DEVELOPMENT COST
****************

fast-importの一般的なフロントエンドは、200行程度の Perl/Python/Ruby コー
ドを使用する傾向があります。 ほとんどの開発者は、fast-import、場合によっ
てはGitに初めて触れたとしても、わずか数時間で実用的なインポーターを作成
することができました。 ほとんどの変換ツールが使い捨て(一度使用すると、決
して振り返ることがない)であることを考えると、これは理想的な状況です。

PARALLEL OPERATION
******************

‘git push’ や ‘git fetch’ と同様に、fast-importによって処理されるインポ
ートは、並列の ‘git repack -a -d’ や ‘git gc’ の呼び出し、またはその他の
Git操作(‘git prune’ を含む、そしてfast-importでは緩いオブジェクト(loose
objects)は使用されないため。)と一緒に実行しても安全です。

   fast-importは、アクティブにインポートしているブランチまたはタグ参照を
ロックしません。 インポート後、refの更新フェーズで、fast-importは、既存
の各ブランチrefをテストして、更新が早送り更新(fast-forward update)になる
ことを確認(verifty)します(refに格納されているコミットは、書き込まれるコ
ミットの新しい履歴に含まれます)。 更新が早送り更新でない場合、
fast-importはその参照の更新をスキップし、代わりに警告メッセージを出力し
ます。 fast-importは常にすべてのブランチ参照を更新しようとし、最初の失敗
で停止(stop)しません。

   ブランチの更新は ‘--force’ を使用して強制できますが、それ以外の場合は
静かなリポジトリ(quiet repository)でのみ使用することをお勧めします。 空
のリポジトリへの最初のインポートには、 ‘--force’ を使用する必要はありま
せん。

TECHNICAL DISCUSSION
********************

fast-importは、メモリ内の一連のブランチを追跡します。 入力ストリームで
‘commit’ コマンドを送信することにより、インポートプロセス中の任意の時点
で任意のブランチを作成または変更できます。 この設計により、フロントエン
ドプログラムは無制限の数のブランチを同時に処理し、ソースデータから利用可
能な順序でコミットを生成できます。 また、フロントエンドプログラムを大幅
に簡素化します。

   fast-importは、現在の作業ディレクトリまたはその中のファイルを使用また
は変更しません。 (ただし、 ‘GIT_DIR’ で参照されるように、現在のGitリポジ
トリを更新します。) したがって、インポートフロントエンドは、外部ソースか
らファイルリビジョンを抽出するなど、独自の目的で作業ディレクトリを使用す
る場合があります。 この、作業ディレクトリの無感知により、ブランチを切り
替えるときにコストのかかるファイル更新操作を実行する必要がないため、
fast-importを非常に迅速に実行することもできます。

INPUT FORMAT
************

(Gitが解釈しない)生のファイルデータを除いて、fast-import入力形式はテキス
ト(ASCII)ベースです。 このテキストベースの形式は、特にPerl、Python、
Rubyなどの高級言語が使用されている場合に、フロントエンドプログラムの開発
とデバッグを簡素化します。

   fast-importは、入力に関して非常に厳密です。 以下でSPと言う場合、「正
確に」1つのスペースを意味します。 同様に、LFは1つ(そして1つだけ)の改行を
意味し、HTは1つ(そして1つだけ)の水平タブを意味します。追加の空白文字を指
定すると、名前の先頭または末尾にスペースが含まれるブランチ名やファイル名
などの予期しない結果が発生したり、予期しない入力が発生した場合に高速イン
ポートが早期に終了したりします。

Stream Comments
===============

フロントエンドのデバッグを支援するために、fast-importは、 ‘#’ (ASCII シ
ャープ/ハッシュ) で始まり、‘LF’ で終わる行を無視します。 コメント行には
、LFを含まないバイトのシーケンスを含めることができるため、フロントエンド
に固有でfast-importのデータストリームを検査するときに役立つ詳細なデバッ
グ情報を含めるために使用できます。

Date Formats
============

以下の日付形式がサポートされています。 フロントエンドは、
‘--date-format=<fmt>’ コマンドラインオプションで形式名を渡すことにより、
このインポートに使用する形式を選択する必要があります。

‘raw’
     これはGitのネイティブ形式であり、 ‘<time>SP<offutc>’ です。
     ‘--date-format’ が指定されていない場合は、fast-importのデフォルト形
     式でもあります。

     イベントの時刻は、UNIXエポック(1970年1月1日午前0時、UTC)からの秒数
     として ‘<time>’ で指定され、ASCIIの10進整数として書き込まれます。

     ローカルオフセットは、UTCからの正または負のオフセットとして
     ‘<offutc>’ によって指定されます。 たとえば、EST(UTCから5時間遅れて
     いる)は、UTCが「+0000」であるのに対し、「<tz>」は「-0500」で表され
     ます。 ローカルオフセットは ‘<time>’ には影響しません。 これは、フ
     ォーマットルーチンがタイムスタンプを表示するのに役立つアドバイスと
     してのみ使用されます。

     ローカルオフセットがソース素材で使用できない場合は、「+0000」、また
     は最も一般的なローカルオフセットを使用します。 たとえば、多くの組織
     には、同じ場所とタイムゾーンにいるユーザーだけがアクセスしたことの
     あるCVSリポジトリがあります。 この場合、UTCからの妥当なオフセットを
     想定できます。

     ‘rfc2822’ 形式とは異なり、この形式は非常に厳密です。 フォーマッティ
     ングに変化があると、fast-importが値を拒否し、数値の健全性チェックも
     実行される場合があります。

‘raw-permissive’
     これは、数値エポックとローカルオフセットの健全性チェックが実行され
     ないことを除いて、‘raw’ と同じです。 これは、例えば、偽のタイムゾー
     ン値を使用して既存の履歴をフィルタリングまたはインポートしようとす
     る場合に役立ちます。

‘rfc2822’
     これは、RFC2822で説明されている標準の電子メール形式です。

     この値は例えば ‘Tue Feb 6 11:22:18 2007 -0500’ です。 Gitパーサーは
     正確ですが、ちょっぴり寛大です。 これは、電子メールから受信したパッ
     チを適用するときに ‘git am’ によって使用されるのと同じパーサーです
     。

     一部の不正な形式の文字列が、有効な日付として受け入れられる場合があ
     ります。 これらの場合のいくつかでは、Gitは不正な形式の文字列から正
     しい日付を取得できます。 また、Gitが誤ってパースし、それでも有効と
     見なす不正な形式の文字列の種類もあります。 ひどくおかしい文字列は拒
     否されます。

     上記の‘raw‘形式とは異なり、RFC2822日付文字列に含まれる タイムゾーン
     /UTC オフセット情報は、保存前に日付値をUTCに調整するために使用され
     ます。 したがって、この情報が可能な限り正確であることが重要です。

     もしソース素材がRFC2822スタイルの日付を使っているなら、フロントエン
     ドは(自分でやろうとするよりも、)fast-importにパースと変換を任せるべ
     きです。なぜなら、Gitパーサーは実際によくテストされているからです。

     フロントエンドは、ソース素材がすでに UNIX-epoch フォーマットを使っ
     ていて、そのフォーマットで日付を与えるように言いくるめられる場合、
     あるいはパースに曖昧さがないため、そのフォーマットが簡単に ‘raw’ フ
     ォーマットに変換できる場合は、 ‘raw’ フォーマットを優先するべきです
     。

‘now’
     常に現在の時間とタイムゾーンを使用します。 ‘<when>’ には常に ‘now’
     というリテラルを指定しなければなりません。

     これはおもちゃのフォーマット(toy format)です。 このシステムの現在の
     時刻とタイムゾーンは、fast-importによって作成されるときに常にID文字
     列にコピーされます。 別の時間またはタイムゾーンを指定する方法はあり
     ません。

     この特定の形式は、実装が簡単なために提供されており、作業ディレクト
     リや ‘git update-index’ を使用せずに、今すぐ新しいコミットを作成し
     たいプロセスに役立つ場合があります。

     ‘commit’ で別々の ‘author’ コマンドと ‘committer’ コマンドが使用さ
     れている場合、システムクロックが2回(コマンドごとに1回)ポーリングさ
     れるため、タイムスタンプが一致しない可能性があります。 作者とコミッ
     ターの両方のID情報のタイムスタンプが同じであることを確認する唯一の
     方法は、 ‘author’ を省略するか(したがって ‘committer’ からコピーす
     る)、または ‘now’ 以外の日付形式を使用することです。

Commands
========

fast-importは、現在のリポジトリを更新し、現在のインポートプロセスを制御
するためのいくつかのコマンドを受け入れます。 各コマンドの詳細(例を含む
)については後述します。

‘commit’
     新しいコミットを作成し、新しく作成されたコミットを指すようにブラン
     チを更新することにより、新しいブランチを作成するか、既存のブランチ
     を更新します。

‘tag’
     既存のコミットまたはブランチから注釈付きタグオブジェクト(annotated
     tag object)を作成します。 軽量タグ(Lightweight tags)は、意味のある
     時点を記録するためには推奨されていないため、このコマンドではサポー
     トされていません。

‘reset’
     既存のブランチ(または新しいブランチ)を特定のリビジョンにリセットし
     ます。 このコマンドは、ブランチをコミットせずに特定のリビジョンに変
     更する目的で使用する必要があります。

‘blob’
     将来 ‘commit’ コマンドで使用するために、生のファイルデータをブロブ
     に変換します。 このコマンドはオプションであり、インポートを実行する
     ために必要ではありません。

‘alias’
     最初に新しいオブジェクトを作成せずに、マークが特定のオブジェクトを
     参照していることを記録します。 ‘--import-marks’ を使用し、欠落して
     いるマークを参照すると fast-import が失敗するため、エイリアスは、刈
     り込まれたコミットを有効な値(刈り込まれていない最も近い祖先など)に
     設定する方法を提供できます。

‘checkpoint’
     fast-importを強制して、現在のパックファイルを閉じ、一意のSHA-1チェ
     ックサムとインデックスを生成して、新しいパックファイルを開始します
     。 このコマンドはオプションであり、インポートを実行するために必須で
     はありません。

‘progress’
     fast-importにより、行全体が自身の標準出力にエコーされます。このコマ
     ンドはオプションであり、インポートを実行するために必要ではありませ
     ん。

‘done’
     ストリームの終わりを示します。 ‘--done’ コマンドラインオプションま
     たは ‘feature done’ コマンドを使用して ‘done’ 機能が要求された場合
     を除き、このコマンドはオプションです。

‘get-mark’
     fast-import により、マークに対応するSHA-1が、 ‘--cat-blob-fd’ にて
     設定されたファイルデスクリプタへ出力されるか、または、指定されてい
     ない場合は stdout のファイルデスクリプタへ出力されます。

‘cat-blob’
     fast-importにより、 ‘cat-file --batch’ 形式のブロブが、
     ‘--cat-blob-fd’ にて設定されたファイルデスクリプタへ出力されるか、
     または、指定されていない場合は stdout のファイルデスクリプタへ出力
     されます。

‘ls’
     fast-importにより、ディレクトリエントリを ‘ls-tree’ 形式で記述した
     行が、 ‘--cat-blob-fd’ にて設定されたファイルデスクリプタへ出力され
     るか、または、指定されていない場合は stdout のファイルデスクリプタ
     へ出力されます。

‘feature’
     指定された機能を有効にします。 これには、fast-importが指定された機
     能をサポートしている必要があり、サポートしていない場合は中止
     (abort)されます。

‘option’
     フロントエンドのニーズに合わせてストリームセマンティックを変更しな
     いオプションの下にリストされているオプションのいずれかを指定します
     。 このコマンドはオプションであり、インポートを実行するために必須で
     はありません。

commit
======

新しいコミットでブランチを作成または更新し、プロジェクトへの1つの論理的
な変更を記録します。

             'commit' SP <ref> LF
             mark?
             original-oid?
             ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
             'committer' (SP <name>)? SP LT <email> GT SP <when> LF
             ('encoding' SP <encoding>)?
             data
             ('from' SP <commit-ish> LF)?
             ('merge' SP <commit-ish> LF)*
             (filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
             LF?

   ここで、 ‘<ref>’ はコミットを行うブランチの名前です。 通常、Gitではブ
ランチ名の前に ‘refs/heads/’ が付いているため、CVSブランチシンボル
‘RELENG-1_0’ をインポートすると、 ‘<ref>’ の値に ‘refs/heads/RELENG-1_0’
が使用されます。 ‘<ref>’ の値は、Gitで有効なrefnameである必要があります
。 ‘LF’ はGit refnameでは無効であるため、ここではクォートやエスケープ構
文はサポートされていません。

   ‘mark’ コマンドがオプションで表示され、フロントエンドで将来使用するた
めに新しく作成されたコミットへの参照を保存するようにfast-importを要求す
る場合があります(形式については以下を参照)。 フロントエンドが作成するす
べてのコミットにマークを付けることは非常に一般的であり、これにより、イン
ポートされたコミットから将来のブランチを作成できます。

   ‘committer’ に続く ‘data’ コマンドは、コミットメッセージを提供する必
要があります(‘data’ コマンドの構文については以下を参照してください)。 空
のコミットメッセージをインポートするには、長さ0のデータを使用します。 コ
ミットメッセージは自由形式であり、Gitによって解釈されません。
fast-importでは他のエンコードを指定できないため、現在はUTF-8でエンコード
する必要があります。

   コミットを作成する前にブランチの内容を更新するために、0個以上の
‘filemodify’ 、 ‘filedelete’ 、 ‘filecopy’ 、 ‘filerename’ 、
‘filedeleteall’ 、 ‘notemodify’ コマンドを含めることができます。 これら
のコマンドは、任意の順序で指定できます。 ただし、 ‘filedeleteall’ はブラ
ンチをクリーンにワイプするため、 ‘filedeleteall’ コマンドを同じコミット
内のすべての ‘filemodify’ 、 ‘filecopy’ 、 ‘filerename’ 、 ‘ notemodify‘
コマンドの前に置くことをお勧めします(下記参照)。

   コマンドの後の ‘LF’ はオプションです(以前は必須でした)。 下位互換性の
理由から、コミットが ‘data’ コマンドで終了する場合(つまり、 ‘from’ 、
‘merge’ 、 ‘filemodify’ 、 ‘filedelete’ 、 ‘filecopy’ 、 ‘filerename’ 、
‘filedeleteall’ 、 ‘notemodify’ コマンドがないことに注意してください)の
場合、コマンドの最後に1つではなく2つの ‘LF’ コマンドが表示される場合があ
ります。

author
------

作者情報がコミッター情報と異なる場合は、オプションで ‘author’ コマンドが
表示されることがあります。 ‘author’ を省略すると、fast-importはコミット
の作者部分にコミッターの情報を自動的に使用します。 ‘author’ のフィールド
の説明については、 ‘committer’ と同じであるため、以下を参照してください
。

committer
---------

‘committer’ コマンドは、誰がこのコミットを行ったのか、いつ行ったのかを示
します。

   ここで、 ‘<name>’ は個人の表示名(たとえば、 "Com M Itter")であり、
‘<email>’ は個人の電子メールアドレス("cm@example.com")です。 ‘LT’ と
‘GT’ は、文字通りの小なり記号(\x3c)と大なり記号(\x3e)です。 これらは、行
の他のフィールドから電子メールアドレスを区切るために必要です。 ‘<name>’
と ‘<email>’ は自由形式であり、 ‘LT’ 、‘GT’ 、 ‘LF’ を除く任意のバイトシ
ーケンスを含むことができることに注意してください。 ‘<name>’ は通常
UTF-8でエンコードされています。

   変更時刻は、 ‘--date-format=<fmt>’ コマンドラインオプションで選択され
た日付形式を使用して ‘<when>’ で指定されます。サポートされている形式のセ
ットとその構文については、上記「Date Formats」を参照してください。

encoding
--------

オプションの ‘encoding’ コマンドは、コミットメッセージのエンコーディング
を示します。 ほとんどのコミットはUTF-8であり、エンコードは省略されていま
すが、これにより、最初に再エンコードせずにコミットメッセージをgitにイン
ポートできます。

from
----

‘from’ コマンドは、このブランチを初期化するコミットを指定するために使用
されます。 このリビジョンは、新しいコミットの最初の祖先になります。 この
コミットで構築されたツリーの状態は、 ‘from’ コミットでの状態で始まり、こ
のコミットでのコンテンツの変更によって交換(alter)されます。

   新しいブランチの最初のコミットで ‘from’ コマンドを省略すると、
fast-importが祖先なしでそのコミットを作成します。 これは、プロジェクトの
最初のコミットでのみ必要になる傾向があります。 新しいブランチを作成する
ときにフロントエンドがすべてのファイルを最初から作成する場合は、 ‘from’
の代わりに ‘merge’ コマンドを使用して、空のツリーでコミットを開始できま
す。 そのブランチの現在のコミットは自動的に新しいコミットの最初の祖先で
あると見なされるため、既存のブランチでは通常は ‘from’ コマンドを省略する
ことが望まれます。

   ‘LF’ は Git refname または SHA-1式では無効であるため、‘<commit-ish>’
内でのクォートまたはエスケープ構文はサポートされていません。

   ここで、‘<commit-ish>’ は以下のいずれかです:

   • fast-importの内部ブランチテーブルにすでに存在する既存のブランチの名
     前。 fast-importが名前を知らない場合は、SHA-1式として扱われます。

   • マーク参照: <idnum> 。ここで、 ‘<idnum>’ はマーク番号です。

     fast-importがマーク参照を示すために ‘:’ を使用する理由は、この文字
     がGitブランチ名では無効であるためです。 先頭 ‘:’ を使用すると、マー
     ク42(‘:42’)とブランチ42(‘42’ または ‘refs/heads/42’)、または、たま
     たま10進数で構成されていた省略形のSHA-1を、簡単に区別できます。

     マークは、使用する前に( ‘mark’ を介して)宣言する必要があります。

   • 完全な40バイトまたは省略された16進数のコミットSHA-1。

   • コミットに解決される有効な Git SHA-1式。 詳細については、
     gitrevisions(7) の「SPECIFYING REVISIONS」を参照してください。

   • 特別な null SHA-1(40個のゼロ)は、ブランチが削除されることを指定しま
     す。

   現在のブランチ値から増分インポート(incremental import)を再スタートす
る特殊なケースは、以下のように記述する必要があります:

             from refs/heads/branch^0

   fast-importはブランチをそれ自体から開始することを許可しないため、
‘^0’ サフィックスが必要です。ブランチは、 ‘from’ コマンドが入力から読み
取られる前にメモリに作成されます。 ‘^0’ を追加すると、fast-importは、内
部ブランチテーブルではなく、Gitのリビジョンパースライブラリを介してコミ
ットを解決し、ブランチの既存の値をロードします。

merge
-----

1つの追加の祖先コミットが含まれます。 追加の祖先リンクは、このコミットで
ツリー状態が構築される方法を変更しません。 新しいブランチを作成するとき
に ‘from’ コマンドを省略すると、最初の ‘merge’ コミットが現在のコミット
の最初の祖先になり、ブランチはファイルなしで開始されます。 fast-importで
は、コミットごとに無制限の数の ‘merge’ コマンドが許可されるため、n方向
(n-way)マージが確立されます。

   ここで、 ‘<commit-ish>’ は、 ‘from’ でも受け入れられるコミット仕様式
のいずれかです(上記参照)。

filemodify
----------

新しいファイルを追加したり、既存のファイルの内容を変更したりするために
‘commit’ コマンドに含まれています。 このコマンドには、ファイルの内容を指
定する2つの異なる方法があります。

External data format
     ファイルのデータコンテンツは、以前の ‘blob’ コマンドによってすでに
     提供されています。フロントエンドはそれに接続する必要があります。

                  'M' SP <mode> SP <dataref> SP <path> LF

     ここで通常、 ‘<dataref>’ は、前の ‘blob’ コマンドによって設定された
     マーク参照(‘:<idnum>’)か、既存のGitブロブオブジェクトの完全な40バイ
     トのSHA-1である必要があります。 ‘<mode>’ が ‘040000’ の場合、
     ‘<dataref>’ は既存のGitツリーオブジェクトの完全な40バイトのSHA-1ま
     たは ‘--import-marks’ で設定されたマーク参照である必要があります。

Inline data format
     ファイルのデータコンテンツはまだ提供されていません。 フロントエンド
     は、この変更コマンドの一部としてそれを提供したいと考えています。

                  'M' SP <mode> SP 'inline' SP <path> LF
                  data

     ‘data’ コマンドの詳細については下記参照。

   どちらの形式でも、 ‘<mode>’ はファイルエントリのタイプであり、8進数で
指定されます。 Gitは以下のモードのみをサポートします:

   • ‘100644’ または ‘644’ : 通常の(実行可能でない)ファイル。 ほとんどの
     プロジェクトのファイルの大部分はこのモードを使用しています。迷った
     らコレ。

   • ‘100755’ または ‘755’ : 通常の、しかし実行可能なファイル。

   • ‘120000’: シンボリックリンク。ファイルの内容がリンクターゲットにな
     ります。

   • ‘160000’ : gitlink、オブジェクトのSHA-1は、他のリポジトリのコミット
     を参照しています。 Gitリンクは、SHAまたはコミットマークを介してのみ
     指定できます。 これらは、サブモジュールを実装するために使用されます
     。

   • ‘040000’: サブディレクトリ。 サブディレクトリは、SHAによって、また
     は ‘--import-marks’ で設定されたツリーマークを介してのみ指定できま
     す。

   どちらの形式でも、 ‘<path>’ は、追加(まだ存在しない場合)または変更(す
でに存在する場合)するファイルの完全なパスです。

   ‘<path>’ 文字列はUNIXスタイルのディレクトリ区切り文字(スラッシュ
‘/’)を使用する必要があり、 ‘LF’ 以外のバイトを含めることができ、二重引用
符(‘"’)で始めることはできません。

   パスはC言語スタイルの文字列クォートを使用できます。 これはすべての場
合に受け入れられ、ファイル名が二重引用符で始まるか、‘LF’ を含む場合は必
須です。 C言語スタイルのクォートでは、完全な名前を二重引用符で囲み、
‘LF’、 バックスラッシュ(‘\’)、または二重引用符の文字の前に円記号を付けて
エスケープする必要があります(例: ‘"path/with\n, \\ and \" in it"’ )。

   ‘<path>’ の値は標準形(canonical form)でなければなりません。以下は禁止
です:

   • 空のディレクトリコンポーネントが含まれている(例: ‘foo//bar’ は無効
     )、

   • ディレクトリ区切り文字で終了する(例: ‘foo/’ は無効)、

   • ディレクトリ区切り文字で始まる(例: ‘/foo’ は無効)、

   • 特別なコンポーネント ‘.’ または ‘..’ を含む(例: ‘foo/./bar’ や
     ‘foo/../bar’ は無効)。

   ツリーのルートは、 ‘<path>’ に空の文字列を指定します。

   ‘<path>’ は常にUTF-8を使用してエンコードすることをお勧めします。

filedelete
----------

ファイルを削除したり、ブランチからディレクトリ全体を再帰的に削除したりす
るために ‘commit’ コマンドに含まれています。 ファイルまたはディレクトリ
を削除して、その親ディレクトリが空になると、親ディレクトリも自動的に削除
されます。 これは、最初の空でないディレクトリまたはルートに到達するまで
、ツリーを上流へ連鎖的にたどります(cascade up)。

             'D' SP <path> LF

   ここで、 ‘<path>’ は、ブランチから削除されるファイルまたはサブディレ
クトリの完全なパスです。 ‘<path>’ の詳細な説明については、上記の
‘filemodify’ を参照してください。

filecopy
--------

既存のファイルまたはサブディレクトリをブランチ内の別の場所に再帰的にコピ
ーします。 既存のファイルまたはディレクトリが存在する必要があります。 宛
先が存在する場合は、ソースからコピーされたコンテンツに完全に置き換えられ
ます。

             'C' SP <path> SP <path> LF

   ここで、最初の ‘<path>’ はソースの場所であり、2番目の ‘<path>’ は宛先
です。 ‘<path>’ がどのように見えるかの詳細な説明については、上記の
‘filemodify’ を参照してください。 SPを含むソースパスを使用するには、パス
を引用符で囲む必要があります。

   ‘filecopy’ コマンドの効果は即時です。ソースの場所が宛先にコピーされる
と、ソースの場所に適用される以降のコマンドは、コピーの宛先に影響を与えま
せん。

filerename
----------

既存のファイルまたはサブディレクトリの名前をブランチ内の別の場所に変更し
ます。 既存のファイルまたはディレクトリが存在する必要があります。 宛先が
存在する場合は、ソースディレクトリに置き換えられます。

             'R' SP <path> SP <path> LF

   ここで、最初の ‘<path>’ はソースの場所であり、2番目の ‘<path>’ は宛先
です。 ‘<path>’ がどのように見えるかの詳細な説明については、上記の
‘filemodify’ を参照してください。 SPを含むソースパスを使用するには、パス
を引用符で囲む必要があります。

   ‘filerename’ コマンドの効果は即時です。 ソースの場所の名前が宛先に変
更されると、ソースの場所に適用される将来のコマンドは、そこに新しいファイ
ルを作成し、名前変更の宛先に影響を与えません。

   注意: ‘filerename’ は、 ‘filecopy’ の後にソースの場所の ‘filedelete’
が続くのと同じであることに注意してください。 ‘filerename’ を使用すること
にはわずかなパフォーマンス上の利点がありますが、その利点は非常に小さいた
め、ソース素材の 削除/追加ペア を高速インポート用の名前変更に変換する価
値はありません。 この ‘filerename’ コマンドは、名前変更情報がすでにある
フロントエンドを単純化するために提供されており、それを ‘filecopy’ とそれ
に続く ‘filedelete’ に分解する必要はありません。

filedeleteall
-------------

ブランチからすべてのファイル(およびすべてのディレクトリ)を削除するために
‘commit’ コマンドに含まれています。 このコマンドは、内部ブランチ構造をリ
セットしてファイルを含まないようにし、フロントエンドの関心あるすべてのフ
ァイルを最初から追加できるようにします。

             'deleteall' LF

   このコマンドは、フロントエンドが現在ブランチ上にあるファイルを知らな
い(あるいは知ろうとしない)ため、コンテンツを更新するための適切な
‘filedelete’ コマンドを生成できない場合に非常に役立ちます。

   正しいコンテンツを設定するために ‘filedeleteall’ の後に必要な
‘filemodify’ コマンドを発行すると、必要な ‘filemodify’ および
‘filedelete’ コマンドのみを送信するのと同じ結果が得られます。 しかし、
‘filedeleteall’ のアプローチでは、fast-import がアクティブブランチごとに
若干多くのメモリの使用を必要する場合があります(ほとんどの大規模プロジェ
クトでも1 MiB未満ではありますが)。 したがって、コミットの影響を受けるパ
スのみを簡単に取得できるフロントエンドは、コミットの影響を受けるパスのみ
を取得することをお勧めします。

notemodify
----------

‘<commit-ish>’ に注釈する新しいノートを追加したり、この注釈の内容を変更
したりするために ‘commit’ ‘<notes_ref>’ コマンドに含まれています。 内部
的には、 ‘<commit-ish>’ パスの ‘filemodify 100644’ に似ています(サブディ
レクトリに分割されている可能性があります)。 ‘filedeleteall’ 以外のコマン
ドを使用して ‘<notes_ref>’ ツリーに書き込み、このツリー内の既存のノート
をすべて削除することはお勧めしません。 このコマンドには、ノートの内容を
指定する2つの異なる方法があります。

External data format
     ノートのデータコンテンツは、以前の ‘blob’ コマンドによってすでに提
     供されています。 フロントエンドは、注釈を付けるコミットに接続する必
     要があります。

                  'N' SP <dataref> SP <commit-ish> LF

     ここで、 ‘<dataref>’ は、前の ‘blob’ コマンドによって設定されたマー
     ク参照(‘:<idnum>’)、または既存のGitブロブオブジェクトの完全な40バイ
     トのSHA-1のいずれかです。

Inline data format
     ノートのデータ内容はまだ提供されていません。 フロントエンドは、この
     変更コマンドの一部としてそれを提供したいと考えています。

                  'N' SP 'inline' SP <commit-ish> LF
                  data

     ‘data’ コマンドの詳細については下記参照。

   どちらの形式でも、 ‘<commit-ish>’ は、 ‘from’ でも受け入れられるコミ
ット仕様式のいずれかです(上記参照)。

mark
====

fast-import を手配して現在のオブジェクトへの参照を保存し、フロントエンド
がSHA-1を知らなくても、将来の時点でこのオブジェクトを呼び出すことができ
るようにします。 ここで、現在のオブジェクトは、 ‘mark’ コマンドが含まれ
るオブジェクト作成コマンドです。 これは ‘commit’ や ‘tag’ や ‘blob’ にす
ることができますが、 ‘commit’ が最も一般的な使用法です。

             'mark' SP ':' <idnum> LF

   ここで、 ‘<idnum>’ は、フロントエンドによってこのマークに割り当てられ
た番号です。 ‘<idnum>’ の値は、ASCIIの10進整数として表されます。 値0は予
約されており、マークとして使用することはできません。 1以上の値のみをマー
クとして使用できます。

   新しいマークは自動的に作成されます。 同じ ‘<idnum>’ を別の ‘mark’ コ
マンドで再利用するだけで、既存のマークを別のオブジェクトに移動できます。

original-oid
============

元のソース管理システムのオブジェクトの名前を提供します。 fast-import は
このディレクティブを単に無視しますが、fast-importにフィードする前にスト
リームを操作および変更するフィルタープロセスは、この情報を使用する場合が
あります。

             'original-oid' SP <object-identifier> LF

   ここで、 ‘<object-identifier>’ は LF を含まない任意の文字列です。

tag
===

特定のコミットを参照する注釈付きタグ(annotated tag)を作成します。 軽量
(注釈なし)タグ(lightweight tag)を作成するには、下記 ‘reset’ コマンドを参
照してください。

             'tag' SP <name> LF
             mark?
             'from' SP <commit-ish> LF
             original-oid?
             'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
             data

   ここで、 ‘<name>’ は作成するタグの名前です。

   タグ名はGitに保存されるときに自動的に ‘refs/tags/’ のプレフィックスが
付けられるため、CVSブランチシンボル ‘RELENG-1_0-FINAL’ をインポートする
と、 ‘<name>’ に ‘RELENG-1_0-FINAL’ だけが使用され、 fast-importは対応す
るrefを ‘refs/tags/RELENG-1_0-FINAL’ として書き込みます。

   ‘<name>’ の値は、Gitで有効なrefnameである必要があるため、スラッシュを
含めることができます。 ‘LF’ はGit refnameでは無効であるため、ここではク
ォートやエスケープ構文はサポートされていません。

   ‘from’ コマンドは ‘commit’ コマンドと同じです。 詳細については、上記
を参照してください。

   ‘tagger’ コマンドは、 ‘commit’ 内の ‘committer’ と同じ形式を使用しま
す。 詳細については、再度上記を参照してください。

   ‘tagger’ に続く ‘data’ コマンドは、注釈付きのタグメッセージを提供する
必要があります(‘data’ コマンドの構文については以下を参照してください)。
空のタグメッセージをインポートするには、長さ0のデータを使用します。 タグ
メッセージは自由形式であり、Gitによって解釈されません。 fast-importでは
他のエンコードを指定できないため、現在はUTF-8でエンコードする必要があり
ます。

   fast-import内からのインポート中に注釈付きタグに署名することはサポート
されていません。 フロントエンドは通常そのような署名に入るバイトの完全な
セットに(簡単に)アクセスできないため、独自の PGP/GPG 署名を含めることは
お勧めしません。 署名が必要な場合は、 ‘reset’ を使用してfast-import内か
ら軽量タグを作成し、標準の ‘git tag’ プロセスを使用してそれらのタグの注
釈付きバージョンをオフラインで作成します。

reset
=====

名前付きブランチを作成(または再作成)します。オプションで、特定のリビジョ
ンから開始します。 resetコマンドを使用すると、フロントエンドは既存のブラ
ンチに対して新しい ‘from’ コマンドを発行したり、新しいコミットを作成せず
に既存のコミットから新しいブランチを作成したりできます。

             'reset' SP <ref> LF
             ('from' SP <commit-ish> LF)?
             LF?

   ‘<ref>’ と ‘<commit-ish>’ の詳細については、上記 ‘commit’ と ‘from’ を
参照してください。

   コマンドの後の ‘LF’ はオプションです(以前は必須でした)。

   ‘reset’ コマンドを使用して、軽量(注釈なし)タグ(lightweight tag)を作成
することもできます。 例えば:

     reset refs/tags/938
     from :938

   これはコミットマーク ‘:938’ が参照するものを参照して、軽量タグ
‘refs/tags/938’ を作成します。

blob
====

パックファイルに1つのファイルリビジョンを書き込むように要求します。 リビ
ジョンはコミットに接続されていません。 この接続は、割り当てられたマーク
を介してブロブを参照することにより、後続の ‘commit’ コマンドで形成する必
要があります。

             'blob' LF
             mark?
             original-oid?
             data

   一部のフロントエンドが独自にブロブのGitSHA-1を生成し、それを直接
‘commit’ にフィードすることを選択したため、ここではmarkコマンドはオプシ
ョンです。 ただし、マークは安価で保管しやすく、使い勝手も良いため、これ
は一般的にはマークより手間がかかると思われます。

data
====

生データ(ブロブ/ファイル コンテンツ または コミットメッセージ または 注
釈付きタグメッセージ として使用するため)をfast-importに提供します。 デー
タは、正確なバイトカウントを使用して提供することも、終了行で区切ることも
できます。 本番品質の変換を目的とした実際のフロントエンドは、より堅牢で
パフォーマンスが高いため、常に正確なバイトカウント形式を使用する必要があ
ります。 区切られた形式は、主にfast-importのテストを目的としています。

   ‘data’ コマンドの ‘<raw>’ 部分に表示されるコメント行は、常にデータの
本文の一部と見なされるため、fast-importによって無視されることはありませ
ん。 これにより、行が ‘#’ で始まる可能性のある ファイル/メッセージ コン
テンツを安全にインポートできます。

Exact byte count format
     フロントエンドは、データのバイト数を指定する必要があります。

                  'data' SP <count> LF
                  <raw> LF?

     ここで、‘<count>’ は ‘<raw>’ 内に表示される正確なバイト数です。
     ‘<count>’ の値はASCII10進整数として表されます。 ‘<raw>’ の両側の
     ‘LF’ は ‘<count>’ に含まれず、インポートされたデータに含まれません
     。

     ‘<raw>’ の後の ‘LF’ はオプションです(以前は必須でした)が、推奨され
     ます。 ‘<raw>’ が ‘LF’ で終わっていなくても、次のコマンドは常に次の
     行の列0で開始するため、常にこれを含めると、fast-importストリームの
     デバッグが容易になります。

Delimited format
     区切り文字列は、データの終わりを示すために使用されます。
     fast-importは、区切り文字を検索して長さを計算します。 この形式は主
     にテストに役立ち、実際のデータにはお勧めしません。

                  'data' SP '<<' <delim> LF
                  <raw> LF
                  <delim> LF
                  LF?

     ここで、‘<delim>’ は選択された区切り文字列です。 文字列 ‘<delim>’ は
     、 ‘<raw>’ 内の行に単独で表示されてはなりません。そうしないと、
     fast-importはデータが実際よりも早く終了すると見なします。 ‘<raw>’ の
     直後に続く ‘LF’ は ‘<raw>’ の一部です。 これは区切り形式の制限の1つ
     であり、最後のバイトとしてLFを持たないデータチャンクを提供すること
     はできません。

     ‘<delim> LF’ の後の ‘LF’ はオプションです(以前は必須でした)。

alias
=====

最初に新しいオブジェクトを作成せずに、マークが特定のオブジェクトを参照し
ていることを記録します。

             'alias' LF
             mark
             'to' SP <commit-ish> LF
             LF?

   ‘<commit-ish>’ の詳細については、上記の ‘from’ を参照してください。

checkpoint
==========

fast-importを強制して、現在のパックファイルを閉じ、新しいパックファイル
を開始し、現在のすべてのブランチ参照とタグとマークを保存します。

             'checkpoint' LF
             LF?

   注意: fast-importは、現在のパックファイルが ‘--max-pack-size’ または
4 GiB のいずれか小さい方の制限に達すると、パックファイルを自動的に切り替
えることに注意してください。 自動パックファイル切り替え中、fast-importは
、ブランチの参照またはタグまたはマーク を更新しません。

   ‘checkpoint’ はかなりのCPU時間とディスクI/Oを必要とする可能性があるた
め(パック全体のSHA-1チェックサムを計算し、対応するインデックスファイルを
生成し、refを更新するため)、単一の ‘checkpoint’ コマンド完了に数分かかる
場合があります。

   フロントエンドは、非常に大規模で長時間実行されるインポート中、または
別のGitプロセスにブランチへのアクセスを許可する必要があるときにチェック
ポイントを発行することを選択できます。 ただし、30 GiB Subversion リポジ
トリを fast-import によって約3時間でGitにロードできることを考えると、明
示的なチェックポイントは必要ない場合があります。

   コマンドの後の ‘LF’ はオプションです(以前は必須でした)。

progress
========

コマンドが入力ストリームから処理されるときに、fast-importが ‘progress’ 行
全体を変更せずに標準の出力チャネル(ファイルデスクリプタ 1)に出力します。
それ以外の場合、このコマンドは現在のインポートやfast-importの内部状態に
は影響しません。

             'progress' SP <any> LF
             LF?

   コマンドの ‘<any>’ 部分には、 ‘LF`を含まないバイトシーケンスを含める
ことができます。 コマンドの後の `LF’ はオプションです。 呼び出し元は、
sedなどのツールを使用して出力を処理し、行の先頭部分を削除したい場合があ
ります。以下に例を示します:

     frontend | git fast-import | sed 's/^progress //'

   ‘checkpoint’ の直後に ‘progress`コマンドを配置すると、 `checkpoint’ が
完了したときにリーダーに通知され、fast-importで更新されたrefに安全にアク
セスできます。

get-mark
========

fast-importが、標準出力または ‘--cat-blob-fd’ 引数であらかじめ指定された
ファイルディスクリプタに、マークに対応するSHA-1を表示するようにします。
それ以外の場合、コマンドは現在のインポートに影響を与えません。 その目的
は、後でコミットがコミットメッセージで参照する可能性のあるSHA-1を取得す
ることです。

             'get-mark' SP ':' <idnum> LF

   この出力を安全に読み取る方法の詳細については、以下の「Responses To
Commands」(コマンドへの応答)を参照してください。

cat-blob
========

fast-importにより、以前に ‘--cat-blob-fd’ 引数で設定されたファイルデスク
リプタにブロブが出力されます。 それ以外の場合、コマンドは現在のインポー
トに影響を与えません。 その主な目的は、fast-importのメモリにある可能性が
あるが、ターゲットリポジトリからはアクセスできないブロブを取得することで
す。

             'cat-blob' SP <dataref> LF

   ‘<dataref>’ は、以前に設定されたマーク参照(‘:<idnum>’)か、既存または
書き込みの準備ができているGitブロブの完全な40バイトのSHA-1のいずれかです
。

   出力は ‘git cat-file --batch’ と同一形式を使用します:

     <sha1> SP 'blob' SP <size> LF
     <contents> LF

   このコマンドは、 ‘filemodify’ ディレクティブを表示できる場所で使用で
き、コミットの途中で使用できます。 インラインディレクティブを使用する
‘filemodify’ の場合、 ‘data’ ディレクティブの直前に表示することもできま
す。

   この出力を安全に読み取る方法の詳細については、以下の「Responses To
Commands」(コマンドへの応答)を参照してください。

ls
==

パスにあるオブジェクトに関する情報を、事前に ‘--cat-blob-fd’ 引数で指定
したファイルディスクリプタへ出力します。 これにより、アクティブなコミッ
トからブロブを表示したり(‘cat-blob’ を使用)、以前のコミットからブロブや
ツリーをコピーして現在のコミットで使用したり(‘filemodify’ を使用))するこ
とができます。

   ‘ls’ コマンドは、 ‘filemodify’ ディレクティブを表示できる場所でも使用
でき、コミットの途中で使用できます。

Reading from the active commit
     この形式は、‘commit’ の途中でのみ使用できます。 パスは、
     fast-importのアクティブなコミット内のディレクトリエントリに名前を付
     けます。 この場合、パスはクォートする必要があります。

                  'ls' SP <path> LF

Reading from a named tree
     ‘<dataref>’ は、マーク参照(‘:<idnum>’)、またはGitタグ、コミット、ツ
     リーオブジェクトの完全な40バイトのSHA-1であり、既存または書き込みを
     待機しています。 パスは、 ‘<dataref>’ で指定されたツリーの最上位を
     基準にしています。

                  'ls' SP <dataref> SP <path> LF

   ‘<path>’ の詳細な説明については、上記の ‘filemodify’ を参照してくださ
い。

   出力は ‘git ls-tree <tree> -- <path>’ と同一形式を使用します:

     <mode> SP ('blob' | 'tree' | 'commit') SP <dataref> HT <path> LF

   <dataref>は、<path>にあるblob、tree、またはcommitオブジェクトを表し、
後の ‘get-mark’ 、 ‘cat-blob’ 、 ‘filemodify’ 、 ‘ls’ コマンドで使用でき
ます。

   そのパスにファイルまたはサブツリーがない場合、 ‘git fast-import’ が代
わりに報告します

     missing SP <path> LF

   この出力を安全に読み取る方法の詳細については、以下の「Responses To
Commands」(コマンドへの応答)を参照してください。

feature
=======

fast-importが指定の機能をサポートすることを要求するか、サポートしない場
合は中止(abort)します。

             'feature' SP <feature> ('=' <argument>)? LF

   コマンドの <feature> 部分は、以下のいずれかになります:

date-format
export-marks
relative-marks
no-relative-marks
force
     先頭に ‘--’ が付いた対応するコマンドラインオプションが、コマンドラ
     インで渡されたかのように動作します(上記 OPTIONS 参照)。

import-marks
import-marks-if-exists
     ‘--import-marks’ と同様ですが、2つの点が異なります。まず、ストリー
     ムごとに1つの ‘feature import-marks’ または ‘feature
     import-marks-if-exists’ コマンドのみが許可されます。 次に、
     ‘--import-marks=’ または ‘--import-marks-if-exists’ コマンドライン
     オプションは、ストリーム内のこれらの「feature」コマンドのいずれかを
     オーバーライドします。 第3に、対応するコマンドラインオプションのよ
     うな ‘feature import-marks-if-exists’ は、存在しないファイルを黙っ
     てスキップします。

get-mark
cat-blob
ls
     バックエンドがそれぞれ ‘get-mark’ または ‘cat-blob’ または ‘ls’ コ
     マンドをサポートしていることを要求します。 指定されたコマンドをサポ
     ートしていないバージョンのfast-importは、そのことを示すメッセージと
     ともに終了します。 これにより、サポートされていないコマンドが検出さ
     れる前にインポートの初期部分で時間を無駄にするのではなく、明確なメ
     ッセージでインポートエラーを早期に発生させることができます。

notes
     バックエンドが ‘commit’ コマンドの ‘notemodify’ (N) サブコマンドを
     サポートしていることを要求します。 ノートをサポートしていない
     fast-importのバージョンは、そのことを示すメッセージとともに終了しま
     す。

done
     _done_ コマンドなしでストリームが終了した場合はエラーになります。 こ
     の機能がないと、ストリーム内の便利なポイントでフロントエンドが突然
     終了する原因となるエラーが検出されなくなる可能性があります。 これは
     、たとえば、インポートフロントエンドがその下位のgit fast-importイン
     スタンスでSIGTERMまたはSIGKILLを発行せずに、操作の途中で停止した場
     合に発生する可能性があります。

option
======

指定されたオプションを処理して、git fast-importがフロントエンドのニーズ
に合った方法で動作するようにします。 フロントエンドで指定されたオプショ
ンは、ユーザーがgit fast-import自体に指定したオプションによって上書きさ
れることに注意してください。

         'option' SP <option> LF

   コマンドの ‘<option>’ 部分には、OPTIONSセクションにリストされているオ
プションのいずれかを含めることができます。これらのオプションは、先頭の
‘--’ がなくても、インポートのセマンティクスを変更せず、同じように扱われ
ます。

   optionコマンドは、非オプションコマンドがエラーになった後にオプション
コマンドを与えるために、入力の最初のコマンドである必要があります
(featureコマンドはカウントされません)。

   以下のコマンドラインオプションはインポートセマンティクスを変更するた
め、オプションとして渡されない場合があります:

   • date-format

   • import-marks

   • export-marks

   • cat-blob-fd

   • force

done
====

‘done’ 機能が使用されていない場合は、EOFが読み取られたかのように扱われま
す。 これを使用して、fast-importに早期に終了するように指示できます。

   ‘--done’ コマンドラインオプションまたは ‘feature done’ コマンドが使用
されている場合、 ‘done’ コマンドは必須であり、ストリームの終わりを示しま
す。

RESPONSES TO COMMANDS
*********************

fast-importによって作成された新しいオブジェクトはすぐには利用できません
。 ほとんどのfast-importコマンドは、次のチェックポイント(または完了)まで
目に見える効果はありません。 フロントエンドは、コマンドが有効になる速度
を気にせずに、fast-importの入力パイプを埋めるためのコマンドを送信できま
す。これにより、スケジューリングが簡素化され、パフォーマンスが向上します
。

   ただし、一部のフロントエンドでは、更新中に現在のリポジトリからデータ
を読み戻すことができると便利です(たとえば、ソース素材が、以前にインポー
トされたオブジェクトに適用されるパッチの観点からオブジェクトを記述してい
る場合)。 これは、フロントエンドとfast-importを双方向パイプを介して接続
することで実現できます:

     mkfifo fast-import-output
     frontend <fast-import-output |
     git fast-import >fast-import-output

   このように設定されたフロントエンドは、 ‘progress’ 、 ‘get-mark’ 、
‘ls’ 、 ‘cat-blob’ コマンドを使用して、進行中のインポートから情報を読み
取ることができます。

   デッドロックを回避するために、このようなフロントエンドは、ブロックす
る可能性のあるfast-importへの書き込みを実行する前に、 ‘progress’ 、 ‘ls’
、 ‘get-mark’ 、 ‘cat-blob’ からの保留中の出力を完全に消費する必要があり
ます。

CRASH REPORTS
*************

fast-importに無効な入力が指定された場合、ゼロ以外の終了ステータスで終了
し、インポート先のGitリポジトリのトップレベルにクラッシュレポートが作成
されます。 クラッシュレポートには、内部のfast-import状態のスナップショッ
トと、クラッシュにつながる最も最近のコマンドが含まれています。

   最近のすべてのコマンド(ストリームコメント、ファイル変更、進行状況コマ
ンドを含む)は、クラッシュレポート内のコマンド履歴に表示されますが、生の
ファイルデータとコミットメッセージはクラッシュレポートから除外されます。
この除外により、レポートファイル内のスペースが節約され、fast-importが実
行中に実行する必要のあるバッファリングの量が削減されます。

   クラッシュレポートを作成した後、fast-importは現在のパックファイルを閉
じ、マークテーブルをエクスポートします。 これにより、フロントエンド開発
者はリポジトリの状態を検査し、クラッシュしたポイントからインポートを再開
できます。 インポートが正常に完了しなかったため、変更されたブランチとタ
グはクラッシュ時に更新されません。 ブランチとタグの情報はクラッシュレポ
ートに記載されており、更新が必要な場合は手動で適用する必要があります。

   クラッシュ例:

     $ cat >in <<END_OF_INPUT
     # my very first test commit
     commit refs/heads/master
     committer Shawn O. Pearce <spearce> 19283 -0400
     # who is that guy anyway?
     data <<EOF
     this is my commit
     EOF
     M 644 inline .gitignore
     data <<EOF
     .gitignore
     EOF
     M 777 inline bob
     END_OF_INPUT

     $ git fast-import <in
     fatal: Corrupt mode: M 777 inline bob
     fast-import: dumping crash report to .git/fast_import_crash_8434

     $ cat .git/fast_import_crash_8434
     fast-import crash report:
         fast-import process: 8434
         parent process     : 1391
         at Sat Sep 1 00:58:12 2007

     fatal: Corrupt mode: M 777 inline bob

     Most Recent Commands Before Crash
     ---------------------------------
       # my very first test commit
       commit refs/heads/master
       committer Shawn O. Pearce <spearce> 19283 -0400
       # who is that guy anyway?
       data <<EOF
       M 644 inline .gitignore
       data <<EOF
     * M 777 inline bob

     Active Branch LRU
     -----------------
         active_branches = 1 cur, 5 max

     pos clock name ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1)      0 refs/heads/master

     Inactive Branches
     -----------------
     refs/heads/master:
       status      : active loaded dirty
       tip commit  : 0000000000000000000000000000000000000000
       old tree    : 0000000000000000000000000000000000000000
       cur tree    : 0000000000000000000000000000000000000000
       commit clock: 0
       last pack   :

     ------------------- END OF CRASH REPORT

TIPS AND TRICKS
***************

以下のヒントとコツは、fast-importのさまざまなユーザーから収集されたもの
であり、提案として提供されています。

Use One Mark Per Commit
=======================

リポジトリ変換を行うときは、コミットごとに一意のマーク(‘mark :<n>’)を使
用し、コマンドラインで ‘--export-marks’ オプションを指定します。
fast-importは、すべてのマークとそれに対応するGitオブジェクトSHA-1をリス
トするファイルをダンプします。 フロントエンドがマークをソースリポジトリ
に結び付けることができる場合、各Gitコミットを対応するソースリビジョンと
比較することで、インポートの正確性と完全性を簡単に確認できます。

   PerforceやSubversionなどのシステムから来る場合、これは非常に単純なは
ずです。fast-importマークは、Perforceのチェンジセット番号または
Subversionのリビジョン番号でもある可能性があるためです。

Freely Skip Around Branches
===========================

インポート中に一度に1つのブランチに固執するようにフロントエンドをわざわ
ざ最適化しようとしないでください。 これを行うと、fast-importの場合は少し
速くなる可能性がありますが、フロントエンドコードの複雑さが大幅に増す傾向
があります。

   高速インポートに組み込まれているブランチLRUは非常に適切に動作する傾向
があり、非アクティブなブランチをアクティブ化するコストは非常に低いため、
ブランチ間でのバウンスはインポートのパフォーマンスに実質的に影響しません
。

Handling Renames
================

名前を変更したファイルまたはディレクトリをインポートするときは、対応する
コミット中に古い名前を削除し、新しい名前を変更するだけです。 Gitは、コミ
ット中に明示的にではなく、事後に名前変更の検出を実行します。

Use Tag Fixup Branches
======================

他のいくつかのSCMシステムでは、ユーザーは同じ コミット/チェンジセット か
らではない複数のファイルからタグを作成できます。 または、リポジトリで使
用可能なファイルのサブセットであるタグを作成します。

   これらのタグをそのままGitにインポートするには、タグのコンテンツと一致
するようにファイルを「修正」するコミットを少なくとも1つ実行する必要があ
ります。 fast-importの ‘reset’ コマンドを使用して、通常のブランチスペー
スの外側にあるダミーブランチをタグのベースコミットにリセットし、1つ以上
のファイル修正コミットをコミットして、最後にダミーブランチにタグを付けま
す。

   たとえば、すべての通常のブランチは ‘refs/heads/’ の下に保存されるため
、タグ修正ブランチには ‘TAG_FIXUP’ という名前を付けます。 このように、イ
ンポーターによって使用される修正ブランチが、ソースからインポートされた実
際のブランチと名前空間の競合を持つことは不可能です((名前 ‘TAG_FIXUP’ は
‘refs/heads/TAG_FIXUP’ ではありません)。

   フィックスアップ(fixup)をコミットするときは、 ‘merge’ を使用してファ
イルリビジョンを提供しているコミットをフィックスアップブランチに接続する
ことを検討してください。 そうすることで、 ‘git blame’ などのツールが実際
のコミット履歴を追跡し、ソースファイルに適切に注釈を付けることができます
。

   fast-importが終了した後、フロントエンドはダミーブランチを削除するため
に ‘rm .git/TAG_FIXUP’ を実行する必要があります。

Import Now, Repack Later
========================

fast-importが完了するとすぐに、Gitリポジトリは完全に有効になり、使用でき
るようになります。 通常、これは非常に大規模なプロジェクト(100,000以上の
コミット)の場合でも、非常に短い時間しかかかりません。

   ただし、データの局所性とアクセスパフォーマンスを向上させるには、リポ
ジトリを再パックする必要があります。 また、非常に大規模なプロジェクトで
は数時間かかる場合があります(特に、 ‘-f’ および 大きな ‘--window’ パラメ
ーターが使用されている場合)。 再パックはリーダーやライターと一緒に実行し
ても安全なので、バックグラウンドで再パックを実行し、再パックが終了したら
リーダーやライターを終了させます。 あなたが新しいGitプロジェクトに挑戦す
るのを待たされる事はありません！

   あなたが再パックを待つことを選択した場合は、再パックが完了するまでベ
ンチマークやパフォーマンステストを実行しないでください。 その場合、
fast-importは、実際の使用状況では決して見られないような、最適でないパッ
クファイルを出力します。

Repacking Historical Data
=========================

非常に古くにインポートされたデータ(たとえば、昨年より古い)を再パックする
場合は、 ‘git repack’ を実行するときに、 ‘--window=50’ (またはそれ以上
)を指定して余分なCPU時間を費やすことを検討してください。 これには時間が
かかりますが、作成されるパックファイルも小さくなります。 あなたが労力を
費やす必要があるのは1回だけで、あなたのプロジェクトを使用するすべての人
が小さくなったリポジトリの恩恵を受けることができます。

Include Some Progress Messages
==============================

時々、フロントエンドに ‘progress’ メッセージを送信してfast-importします
。 メッセージの内容は完全に自由形式であるため、現在のコミット日が翌月に
移動するたびに、現在の月と年を出力することをお勧めします。あなたのユーザ
ーは、処理されたデータストリームの量をよりよく知ることができます。

PACKFILE OPTIMIZATION
*********************

ブロブを高速にパックする場合、インポートは常に最後に書き込まれたブロブに
対して削除を試みます。 フロントエンドによって特別に調整されていない限り
、これはおそらく同じファイルの以前のバージョンではないため、生成されるデ
ルタは可能な限り最小にはなりません。 結果のパックファイルは圧縮されます
が、最適ではありません。

   単一のファイルのすべてのリビジョンに効率的にアクセスできるフロントエ
ンド(たとえば、 RCS/CVS ,v file の読み取り)は、連続する ‘blob’ コマンド
のシーケンスとして、そのファイルのすべてのリビジョンを提供することを選択
できます。 これにより、fast-importでさまざまなファイルリビジョンを相互に
区別し、最終的なパックファイルのスペースを節約できます。 マークは、後で
一連の ‘commit’ コマンド中に個々のファイルリビジョンを識別するために使用
できます。

   fast-importによって作成されたパックファイルは、適切なディスクアクセス
パターンを促進しません。 これは、標準入力で受信した順序でデータを
fast-importで書き込むことが原因ですが、Gitは通常、パックファイル内のデー
タを整理して、最新の(現在の先端)データを履歴データの前に表示します。
Gitはまた、コミットをクラスター化し、キャッシュの局所性を向上させること
でリビジョンのトラバーサルを高速化します。

   このため、fast-importが完了した後、ユーザーがリポジトリを ‘git repack
-a -d’ で再パックし、Gitがパックファイルを再編成してデータアクセスを高速
化できるようにすることを強くお勧めします。 ブロブデルタが最適ではない場
合(上記参照)、すべてのデルタの再計算を強制するために ‘-f’ オプションを追
加すると、最終的なパックファイルサイズを大幅に減らすことができます(ほと
んどの場合30〜50%小さくなります)。

   ‘git repack’ を実行する代わりに、 ‘git gc --aggressive’ を実行するこ
ともできます。これにより、インポート後に他のものも最適化されます(たとえ
ば、loose refs をパックします)。 git-gc(1) の「AGGRESSIVE」セクションに
記載されているように、 ‘--aggressive`オプションは、
linkgit:git-repack[1] への `-f’ オプションを使用して新しいデルタを検索し
ます。 上記で詳しく説明した理由により、fast-importの後に ‘--aggressive’
を使用することは、価値があることがわかっている数少ないケースの1つです。

MEMORY UTILIZATION
******************

fast-importがインポートを実行するために必要なメモリの量に影響を与えるい
くつかの要因があります。 コアGitのクリティカルセクションと同様に、
fast-importは独自のメモリアロケータを使用して、mallocに関連するオーバー
ヘッドを減らします。 実際には、fast-importは、大きなブロック割り当てを使
用するため、mallocオーバーヘッドを0に減らす傾向があります。

per object
==========

fast-importは、この実行で書き込まれるすべてのオブジェクトのメモリ内構造
を維持します。 32ビットシステムでは、構造は32バイトですが、64ビットシス
テムでは、構造は40バイトです(ポインタサイズが大きいため)。 テーブル内の
オブジェクトは、fast-importが終了するまで割り当てが解除されません。 32ビ
ットシステムに200万個のオブジェクトをインポートするには、約64MiBのメモリ
が必要です。

   オブジェクトテーブルは、実際にはオブジェクト名(一意のSHA-1)をキーとす
るハッシュテーブルです。 このストレージ構成により、fast-importで既存また
は既に書き込まれたオブジェクトを再利用し、出力パックファイルへの重複の書
き込みを回避できます。 インポートでは、ブロブの重複が驚くほど一般的です
。これは通常、ソースでのブランチのマージが原因です。

per mark
========

マークは、マークごとに1つのポインター(ポインターのサイズに応じて4バイト
または8バイト)を使用して、まばらな配列に格納されます。 配列はまばらです
が、フロントエンドでは 1〜n のマークを使用することを強くお勧めします。こ
こで、n はこのインポートに必要なマークの総数です。

per branch
==========

ブランチはアクティブと非アクティブにクラス分けされます。 2つのクラスのメ
モリ使用量は大幅に異なります。

   非アクティブなブランチは、ブランチごとに96バイトまたは120バイト(それ
ぞれ32ビットまたは64ビットシステム)とブランチ名の長さ(通常は200バイト未
満)を使用する構造に格納されます。 fast-importは、2MiB未満のメモリで
10,000もの非アクティブなブランチを簡単に処理します。

   アクティブなブランチには非アクティブなブランチと同じオーバーヘッドが
ありますが、そのブランチで最近変更されたすべてのツリーのコピーも含まれて
います。 ブランチがアクティブになってからサブツリー ‘include’ が変更され
ていない場合、その内容はメモリに読み込まれませんが、ブランチがアクティブ
になってからコミットによってサブツリー ‘src’ が変更されている場合、その
内容はメモリに読み込まれます。

   アクティブなブランチは、そのブランチに含まれるファイルに関するメタデ
ータを格納するため、メモリ内のストレージサイズがかなり大きくなる可能性が
あります(以下参照)。

   fast-importは、単純な「最も最近使用されていない」アルゴリズム
(least-recently-used algorithm)に基づいて、アクティブなブランチを自動的
に非アクティブなステータスに移動します。 LRUチェーンは、‘commit’ コマン
ドごとに更新されます。 アクティブなブランチの最大数は、コマンドラインで
‘--active-branches=’ を使用して増減できます。

per active tree
===============

ツリー(別名ディレクトリ)は、エントリに必要なメモリに加えて、わずか12バイ
トのメモリを使用します(以下「per active file」参照)。 ツリーのオーバーヘ
ッドは個々のファイルエントリで償却されるため、ツリーのコストは実質的に
0です。

per active file entry
=====================

アクティブツリー内のファイル(およびサブツリーへのポインター)には、エント
リごとに52バイトまたは64バイト(32/64 ビットプラットフォーム)が必要です。
スペースを節約するために、ファイル名とツリー名は共通の文字列テーブルにプ
ールされ、ファイル名 ‘Makefile’ が(文字列ヘッダーのオーバーヘッドを含め
た後)、プロジェクト内で何度発生しても、わずか16バイトしか使用しないよう
にします。

   アクティブブランチLRUは、ファイル名文字列プールおよびサブツリーの遅延
読み込みと組み合わせると、fast-importにより、非常に限られたメモリフット
プリント(アクティブブランチあたり2.7 MiB未満)で2,000以上のブランチと
45,114以上のファイルを持つプロジェクトを効率的にインポートできます。

SIGNALS
*******

*SIGUSR1* を ‘git fast-import’ プロセスに送信すると、現在のパックファイ
ルが早期に終了し、 ‘checkpoint’ コマンドがシミュレートされます。 せっか
ちなオペレーターは、この機能を使用して、実行時間の追加と圧縮率の低下を犠
牲にして、進行中のインポートからオブジェクトとrefを確認できます。

SEE ALSO
********

git-fast-export(1)

GIT
***

Part of the git(1) suite

Name
****

git-fetch-pack — 別のリポジトリから不足しているオブジェクトを受け取りま
す

Synopsis
********

     git fetch-pack [–all] [–quiet|-q] [–keep|-k] [–thin] [–include-tag]
             [–upload-pack=<git-upload-pack>]
             [–depth=<n>] [–no-progress]
             [-v] <repository> [<refs>…]

DESCRIPTION
***********

通常は、代わりにこのコマンドの上位レベルのラッパーである ‘git fetch’ を
使用することをお勧めします。

   おそらくはリモートリポジトリで _git-upload-pack_ を起動し、このリポジ
トリから不足しているオブジェクトを送信し、名前付きの head を更新するよう
問合せます。ローカルで利用可能なコミットの一覧は、ローカルの refs/ 階層
をスキャンして見つけ、相手側で実行されている ‘git-upload-pack’ に送信さ
れます。

   このコマンドは、ローカル側に共通の祖先コミットがない場合には、リモー
ト側から要求された参照を完了するためにすべてをダウンロードするよう機能縮
退します。

OPTIONS
*******

‘--all’
     すべてのリモート参照をフェッチします。

‘--stdin’
     stdinから参照のリストを1行に1つずつ取得します。このオプションに加え
     てコマンドラインで参照が指定されている場合、stdinからの参照はコマン
     ドラインでの参照の後に処理されます。

     このオプションと一緒に ‘--stateless-rpc’ を指定する場合、参照のリス
     トはパケット形式(pkt-line)である必要があります。各refは個別のパケッ
     トに含まれている必要があり、リストはフラッシュパケットで終了してい
     る必要があります。

‘-q’
‘--quiet’
     ‘-q’ フラグを ‘git unpack-objects’ に渡します。 これにより、クロー
     ン作成プロセスのおしゃべりが減ります。

‘-k’
‘--keep’
     受信したデータに対して ‘git unpack-objects’ を呼び出さないでくださ
     い。代わりに、そのデータから単一のパックファイルを作成し、オブジェ
     クトデータベースに保存してください。このオプションが2回指定された場
     合、パックは再パックに対してロックされます(the pack is locked
     against repacking)。

‘--thin’
     ネットワークトラフィックを軽減するために、パックに含まれないオブジ
     ェクトを元に、オブジェクトを差分化(デルタ化)して記録する「薄い」パ
     ック(thin pack)をフェッチします。

‘--include-tag’
     リモート側がサポートしている場合、タグが参照するオブジェクトがダウ
     ンロードされると、注釈付きタグオブジェクトが他のオブジェクトと同じ
     接続(same connection)でダウンロードされます。それ以外の場合、呼び出
     し元は、このオプションで使用できるタグを決定する必要があります。

‘--upload-pack=<git-upload-pack>’
     あなたの $PATHに見つからない場合は、これを使用して、リモート側の
     ‘git-upload-pack’ へのパスを指定します。sshdをインストールすると、
     ログインシェル用のユーザーの環境設定スクリプト(‘.bash_profile’ など
     )が無視され、プライベートにインストールされたgitがシステムのデフォ
     ルトの$PATHで見つけられない場合があります。推奨される別の回避策は、
     ‘.bashrc’ に $PATHを設定することですが、このフラグは、(ほとんどのも
     のを.bash_profileに設定して、)中身の無い ‘.bashrc’ ファイルを使用し
     て非対話型シェルのオーバーヘッドを支払いたくない人向けです。

‘--exec=<git-upload-pack>’
     ‘--upload-pack=<git-upload-pack>’ と同じ。

‘--depth=<n>’
     フェッチを n 以下の祖先チェーンに制限します。 ‘git-upload-pack’ は
     、特別な深さ2147483647が指定された場合、その深さの祖先チェーンがあ
     る場合でも、それを無限として扱います。

‘--shallow-since=<date>’
     浅いリポジトリ(shallow repository)の履歴を更に深くするか更に浅くす
     るかして、 <date> 以降の到達可能なすべてのコミットを含めます。

‘--shallow-exclude=<revision>’
     浅いリポジトリ(shallow repository)の履歴を深くするか浅くするかして
     、指定されたリモートブランチまたはタグから到達可能なコミットを除外
     します。このオプションは複数回指定できます。

‘--deepen-relative’
     引数 ‘--depth’ は、各リモートブランチ履歴の先端からではなく、現在の
     浅い境界(shallow boundary)からのコミット数を指定します。

‘--no-progress’
     進捗状況を表示しないでください。

‘--check-self-contained-and-connected’
     受信したパックが自己完結型で接続されている場合は、
     "connectivity-ok" を出力します。

‘-v’
     おしゃべりになります。

<repository>
     リモートリポジトリへのURL。

<refs>…
     更新元のリモートヘッド。これは $GIT_DIR に関連しています(例: ‘HEAD’
     、 ‘refs/heads/master’ )。指定しない場合は、リモート側が持つすべて
     のヘッドから更新します。

     リモートがオプション ‘uploadpack.allowTipSHA1InWant’ または
     ‘uploadpack.allowReachableSHA1InWant’ または
     ‘uploadpack.allowAnySHA1InWant’ を有効にしている場合、それらはリモ
     ートに存在する 16進40桁 sha1 である可能性があります。

SEE ALSO
********

git-fetch(1)

GIT
***

Part of the git(1) suite

Name
****

git-fetch — 別のリポジトリからオブジェクトとrefsをダウンロードします

Synopsis
********

     git fetch [<options>] [<repository> [<refspec>…]]
     git fetch [<options>] <group>
     git fetch –multiple [<options>] [(<repository> | <group>)…]
     git fetch –all [<options>]

DESCRIPTION
***********

履歴を完成させるために必要なオブジェクトとともに、1つ以上の他のリポジト
リからブランチやタグ(総称して「refs」)を取得します。 リモート追跡ブラン
チが更新されます(この振る舞いを制御する方法については、以下の <refspec>
の説明を参照してください)。

   デフォルトでは、フェッチされている履歴を指すタグもフェッチされます。
その効果は、関心のあるブランチを指すタグをフェッチすることです。 このデ
フォルトの振る舞いは、 ‘--tags’ または ‘--no-tags’ オプションを使用する
か、 remote.<name>.tagOpt を構成することで変更できます。 あなたは、タグ
を明示的にフェッチするrefspecを使用することで、関心のあるブランチを指し
ていないタグもフェッチできます。

   ‘git fetch’ は、単一の名前付きリポジトリまたはURLから、あるいは、
<group> が指定され、かつ、構成ファイルに remotes.<group> エントリがある
場合は、一度に複数のリポジトリからフェッチできます。 (git-config(1) 参照
)。

   「リモート」が指定されていない場合、現在のブランチ用にアップストリー
ムブランチが構成されていない限り、デフォルトで ‘origin’ リモートが使用さ
れます。

   フェッチされたrefの名前は、それらが指すオブジェクト名とともに、
‘.git/FETCH_HEAD’ に書き込まれます。 この情報は、スクリプトまたは
git-pull(1) などの他のgitコマンドで使用される場合があります。

OPTIONS
*******

‘--all’
     すべてのリモートをフェッチします。

‘-a’
‘--append’
     フェッチされた参照の参照名とオブジェクト名を ‘.git/FETCH_HEAD’ の既
     存のコンテンツに追加します。 このオプションがないと、
     ‘.git/FETCH_HEAD’ の古いデータが上書きされます。

‘--atomic’
     アトミックトランザクションを使用して、ローカル参照を更新します。 す
     べての参照が更新されるか、あるいは、エラーが発生してすべての参照が
     新されないか、のいずれかです。

‘--depth=<depth>’
     各リモートブランチ履歴の先端からの指定されたコミット数にフェッチを
     制限します。 ‘--depth=<depth>’ オプションを指定して ‘git clone’ に
     よって作成された浅いリポジトリ(shallow repository)からフェッチする
     場合(git-clone(1) 参照)、指定されたコミット数まで履歴を深くするか浅
     くするかします。

‘--deepen=<depth>’
     ‘--depth’ に似ていますが、各リモートブランチ履歴の先端からではなく
     、現在の浅い境界(shallow boundary)からのコミット数を指定する点が異
     なります。

‘--shallow-since=<date>’
     浅い(shallow)リポジトリの履歴を深くしたり浅くしたりして、<date>以降
     の到達可能なすべてのコミットを含めます。

‘--shallow-exclude=<revision>’
     浅いリ(shallow)ポジトリの履歴を深くするか浅くするかして、指定された
     リモートブランチまたはタグから到達可能なコミットを除外します。 この
     オプションは複数回指定できます。

‘--unshallow’
     ソースリポジトリが完全な場合は、浅いリ(shallow)ポジトリを完全なリポ
     ジトリに変換し、浅い(shallow)リポジトリによって課せられるすべての制
     限を取り除きます。

     ソースリポジトリが浅い(shallow)場合は、現在のリポジトリがソースリポ
     ジトリと同じ履歴を持つように、可能な限りフェッチします。

‘--update-shallow’
     デフォルトでは、浅い(shallow)リポジトリからフェッチする場合、 ‘git
     fetch’ は ‘.git/shallow’ の更新が必要なrefを拒否します。 このオプシ
     ョンは ‘.git/should’ を更新し、そのようなrefを受け入れます。

‘--negotiation-tip=<commit|glob>’
     デフォルトでは、Gitは、受信するパックファイルのサイズを縮小するため
     に、すべてのローカルrefから到達可能なコミットをサーバーに報告して、
     共通のコミットを見つけます。 指定した場合、Gitは指定された先端から
     到達可能なコミットのみを報告します。 これは、フェッチされるアップス
     トリームrefと共通のコミットを持つ可能性のあるローカルrefがユーザー
     にわかっている場合に、フェッチを高速化するのに役立ちます。

     このオプションは複数回指定できます。 その場合、Gitは指定されたコミ
     ットのいずれかから到達可能なコミットを報告します。

     このオプションの引数は、ref名またはrefまたはコミットの(おそらく省略
     された)SHA-1のグロブである可能性があります。グロブを指定することは
     、一致するref名ごとに1つずつ、このオプションを複数回指定することと
     同じです。

     git-config(1) に記載されている ‘fetch.negotiationAlgorithm’ と
     ‘push.negotiate’ 構成変数、および、以下の ‘--negotiate-only’ オプシ
     ョンも参照してください。

‘--negotiate-only’
     サーバーから何もフェッチせず、代わりに、サーバーと共通している、提
     供された ‘--negotiation-tip=*’ 引数の祖先を出力します。

     内部的には、これは ‘push.negotiate’ オプションを実装するために使用
     されます。 git-config(1) を参照してください。

‘--dry-run’
     変更を加えずに、何が行われるかを示します。

‘--[no-]write-fetch-head’
     ‘$GIT_DIR’ のすぐ下の ‘FETCH_HEAD’ ファイルにフェッチされたリモート
     refのリストを書き込みます。 これがデフォルトです。 コマンドラインか
     ら ‘--no-write-fetch-head’ を渡すと、Gitにファイルを書き込まないよ
     うに指示します。 ‘--dry-run’ オプションでは、ファイルが書き込まれる
     ことはありません。

‘-f’
‘--force’
     ‘git fetch’ を ‘<src>:<dst>’ refspecと一緒に使用すると、既に説明し
     たようにローカルブランチの更新を拒否する場合があります 以下の
     ‘<refspec>’ の部分にあります。 このオプションは、そのチェックをオー
     バーライドします。

‘-k’
‘--keep’
     ダウンロードしたパックを保持してください。

‘--multiple’
     複数の<repository>および<group>引数を指定できるようにします。
     <refspec>を指定することはできません。

‘--[no-]auto-maintenance’
‘--[no-]auto-gc’
     最後に ‘git maintenance run --auto’ を実行して、必要に応じて自動リ
     ポジトリメンテナンスを実行します。 (‘--[no-]auto-gc’ は同義語です。
     ) これはデフォルトで有効になっています。

‘--[no-]write-commit-graph’
     フェッチ後にコミットグラフ(commit-graph)を記述します。 これは、構成
     設定 ‘fetch.writeCommitGraph’ をオーバーライドします。

‘--prefetch’
     構成されたrefspecを変更して、すべてのrefを ‘refs/prefetch/’ 名前空
     間に配置します。 git-maintenance(1)の ‘prefetch’ タスクを参照してく
     ださい。

‘-p’
‘--prune’
     フェッチする前に、リモートに存在しなくなったリモート追跡参照を削除
     します。 タグは、デフォルトのタグの自動追跡または ‘--tags’ オプショ
     ンのためにのみフェッチされた場合(コマンドラインまたはリモート構成の
     いずれかで、たとえば、リモートが ‘--mirror’ オプションでcloneされた
     場合)、刈り込み(pruning)の対象にはなりません。 ただし、明示的な
     refspecが原因でタグがフェッチされた場合、それらも刈り込み
     (pruning)の対象になります。 ‘--prune-tags’ を指定することは、タグ
     refspecを提供するための省略形です。

     詳細については、下記の「PRUNING」セクションを参照してください。

‘-P’
‘--prune-tags’
     ‘--prune’ が有効になっている場合は、フェッチする前に、リモートに存
     在しなくなったローカルタグをすべて削除します。 このオプションは、
     ‘--prune’ とは異なり、より慎重に使用する必要があります。作成された
     ローカル参照(ローカルタグ)はすべて削除されます。 このオプションは、
     明示的なタグrefspecを ‘--prune’ とともに提供するための省略形です。
     これについては、そのドキュメントの説明を参照してください。

     詳細については、下記の「PRUNING」セクションを参照してください。

‘-n’
‘--no-tags’
     デフォルトでは、リモートリポジトリからダウンロードされたオブジェク
     トを指すタグがフェッチされ、ローカルに保存されます。このオプション
     は、この自動タグ追跡を無効にします。 リモートのデフォルトの動作は、
     ‘remote.<name>.tagOpt’ 設定で指定できます。 git-config(1) を参照し
     てください。

‘--refmap=<refspec>’
     コマンドラインにリストされているrefをフェッチするときは、リモートリ
     ポジトリの ‘remote.*.fetch’ 構成変数の値の代わりに、指定された
     refspec(複数回指定可能)を使用してrefをリモート追跡ブランチにマップ
     します。 空の ‘<refspec>’ を ‘--refmap’ オプションに指定すると、
     Gitは構成されたrefspecsを無視し、コマンドライン引数として提供された
     refspecsに完全に依存します。 詳細については、「Configured
     Remote-tracking Branches」のセクションを参照してください。

‘-t’
‘--tags’
     他の方法でフェッチされるものに加えて、リモートからすべてのタグをフ
     ェッチします(つまり、リモートタグ ‘refs/tags/*’ を同じ名前のローカ
     ルタグにフェッチします)。 このオプションを単独で使用しても、
     ‘--prune’ が使用されている場合でも、タグは刈り込み(pruning)の対象に
     はなりません(ただし、タグが明示的なrefspecの宛先でもある場合は、タ
     グは刈り込み(pruning)される可能性があります。 ‘--prune’ を参照して
     ください)。

‘--recurse-submodules[=yes|on-demand|no]’
     このオプションは、入力されたサブモジュールの新しいコミットもフェッ
     チするかどうか、およびどのような条件でフェッチするかを制御します。
     これはブールオプションとして使用でき、 ‘no’ に設定すると再帰を完全
     に無効にしたり、 ‘yes’ に設定するとすべての入力済みサブモジュールに
     無条件に再帰します。 ‘yes’ は、このオプションを値なしで使用した場合
     のデフォルトです。 スーパープロジェクトが、ローカルサブモジュールク
     ローンにまだ存在しないコミットへのサブモジュールの参照を更新するコ
     ミットを取得する場合にのみ、 ‘on-demand’ を使用して、入力されたサブ
     モジュールに再帰します。 デフォルトでは、 ‘fetch.recurseSubmodules’
     が設定されていない限り、 ‘on-demand’ が使用されます(git-config(1) 参
     照)。

‘-j’
‘--jobs=<n>’
     すべての形式のフェッチに使用されるparallel childrenの数。

     ‘--multiple’ オプションが指定された場合、異なるリモートが並行してフ
     ェッチされます。 複数のサブモジュールがフェッチされる場合、それらは
     並行してフェッチされます。 それらを個別に制御するには、構成設定
     ‘fetch.parallel’ と ‘submodule.fetchJobs’ を使用します
     (git-config(1) 参照)。

     通常、並列再帰フェッチとマルチリモートフェッチの方が高速です。デフ
     ォルトでは、フェッチは並列ではなく順次実行されます。

‘--no-recurse-submodules’
     サブモジュールの再帰的フェッチを無効にします(これは、
     ‘--recurse-submodules=no’ オプションを使用するのと同一の効果があり
     ます)。

‘--set-upstream’
     リモートが正常にフェッチされた場合は、引数のない git-pull(1) および
     その他のコマンドで使用されるアップストリーム(追跡)参照を追加します
     。 詳細については、 git-config(1) の ‘branch.<name>.merge’ および
     ‘branch.<name>.remote’ を参照してください。

‘--submodule-prefix=<path>’
     「Fetching submodule foo」などの情報メッセージに出力されるパスの前
     に<path>を付けます。このオプションは、サブモジュールを再帰的に実行
     するときに内部的に使用されます。

‘--recurse-submodules-default=[yes|on-demand]’
     このオプションは、 ‘--recurse-submodules’ オプションに負でないデフ
     ォルト値を一時的に提供するために内部的に使用されます。 フェッチのサ
     ブモジュール再帰を構成する他のすべての方法(gitmodules(5) や
     git-config(1) の設定など) は、 ‘--[no-]recurse-submodules’ を直接指
     定する場合と同様に、このオプションをオーバーライドします。

‘-u’
‘--update-head-ok’
     デフォルトでは、 ‘git fetch’ は現在のブランチに対応するヘッドの更新
     を拒否します。 このフラグはそのチェックを無効にします。 これは純粋
     に ‘git pull’ が ‘git fetch’ と通信するための内部使用のためであり、
     あなたが独自の磁器コマンドを実装していない限り、あなたがそれを使用
     することは想定されていません。

‘--upload-pack <upload-pack>’
     指定され、フェッチ元のリポジトリが ‘git fetch-pack’ によって処理さ
     れると、 ‘--exec=<upload-pack>’ がコマンドに渡され、もう一方の端で
     実行されるコマンドのデフォルト以外のパスが指定されます。

‘-q’
‘--quiet’
     ‘--quiet’ を ‘git-fetch-pack’ に渡し、内部で使用される他のgitコマン
     ドをすべて静粛にさせます。 進行状況は標準エラーストリームに報告され
     ません。

‘-v’
‘--verbose’
     おしゃべりにします。

‘--progress’
     ‘-q’ が指定されていない限り、進行状況は、端末に接続されている場合、
     デフォルトで標準エラーストリームに報告されます。 このフラグは、標準
     エラーストリームが端末に送信されていない場合でも、進行状況を強制し
     ます。

‘-o <option>’
‘--server-option=<option>’
     プロトコルバージョン2を使用して通信する場合は、指定された文字列をサ
     ーバーに送信します。 指定された文字列には、NUL文字またはLF文字を含
     めることはできません。 不明なオプションを含むサーバーオプションのサ
     ーバー処理は、サーバー固有です。 複数の ‘--server-option=<option>’
     が指定されている場合、それらはすべてコマンドラインにリストされてい
     る順序で相手側に送信されます。

‘--show-forced-updates’
     デフォルトでは、gitはフェッチ中にブランチが強制的に更新されるかどう
     かをチェックします。 これは ‘fetch.showForcedUpdates’ を介して無効
     にすることができますが、 ‘--show-forced-updates’ オプションはこのチ
     ェックが行われることを保証します。 git-config(1) を参照してください
     。

‘--no-show-forced-updates’
     デフォルトでは、gitはフェッチ中にブランチが強制的に更新されるかどう
     かをチェックします。 ‘--no-show-forced-updates’ を渡すか、
     ‘fetch.showForcedUpdates’ を ‘false’ に設定して、パフォーマンス上の
     理由からこのチェックをスキップします。 ‘git-pull’ 処理中に使用され
     た場合、 ‘--ff-only’ オプションは、早送り(fast-forward)更新を試行す
     る前に、強制更新をチェックします。 git-config(1) を参照してください
     。

‘-4’
‘--ipv4’
     IPv6アドレスを無視して、IPv4アドレスのみを使用します。

‘-6’
‘--ipv6’
     IPv4アドレスを無視して、IPv6アドレスのみを使用します。

<repository>
     フェッチまたはプル操作のソースである「リモート」リポジトリ。このパ
     ラメーターは、URL(以下の GIT URLS セクションを参照)またはリモートの
     名前(以下の REMOTES セクションを参照)のいずれかです。

<group>
     構成ファイル内のリモート。 <group> の値としてリポジトリーのリストを
     参照する名前。(git-config(1) を参照)。

<refspec>
     フェッチするrefと更新するローカルrefを指定します。コマンドラインに
     <refspec> がない場合、フェッチするrefは代わりに
     ‘remote.<repository>.fetch’ 変数から読み取られます。 (下記
     CONFIGURED REMOTE-TRACKING BRANCHES (see [CRTB]) 参照)

     <refspec> パラメータの組織は、オプションのプラス ‘+’ に続いて ソー
     スの <src> 、コロン ‘:’ 宛先refの <dst> の順です。 <dst> が空の場合
     、コロン(‘:’)は省略できます。 <src> は通常、refですが、フルスペルの
     16進オブジェクト名にすることもできます。

     <refspec> の <src> には、単純なパターン一致を示すための ‘*’ が含ま
     れている場合があります。このようなrefspecは、同じプレフィックスを持
     つ任意のrefに一致するglobのように機能します。パターン<refspec>では
     、 <src> と <dst> の両方に ‘*’ が含まれている必要があります。 ‘*’ を
     ソースから一致したコンテンツに置き換えることにより、refを宛先にマッ
     ピングします。

     refspecの前に ‘^’ が付いている場合、それはネガティブのrefspecとして
     解釈されます。このようなrefspecは、フェッチするrefや更新するローカ
     ルrefを指定するのではなく、除外するrefを指定します。 refは、少なく
     とも1つのポジティブ(通常)のrefspecと一致し、ネガティブのrefspecと一
     致しない場合、一致すると見なされます。ネガティブのrefspecは、特定の
     refが含まれないように、パターンrefspecのスコープを制限するのに役立
     ちます。ネガティブのrefspecは、それ自体がパターンrefspecである可能
     性があります。 ただし、 <src> のみを含めることができ、 <dst> を指定
     することはできません。 フルスペルの16進オブジェクト名もサポートされ
     ていません。

     ‘tag <tag>’ は、 ‘refs/tags/<tag>:refs/tags/<tag>’ と同じ意味です。
     指定されたタグまでのすべてをフェッチするように要求します。

     <src> に一致するリモートrefがフェッチされ、 <dst> が空の文字列でな
     い場合は、それに一致するローカルrefを更新しようとします。

     その更新が ‘--force’ なしで許可されるかどうかは、フェッチ先のref名
     前空間、フェッチされるオブジェクトのタイプ、および更新が
     fast-forwardであると見なされるかどうかによって異なります。一般に、
     プッシュする場合と同じルールがフェッチに適用されます。それらが何で
     あるかについては、 git-push(1)の ‘<refspec>...’ セクションを参照し
     てください。 _git fetch_ に固有の例外ルールを以下に示します。

     Gitバージョン2.20までは、 git-push(1) でプッシュする場合とは異なり
     、 ‘refs/tags/*’ の更新は、 refspec に ‘+’ がなくても(または
     ‘--force’ 指定が無くても)受け入れられます。フェッチするとき、リモー
     トからのすべてのタグ更新を強制フェッチとしていました。Gitバージョン
     2.20以降では、 ‘refs/tags/*’ を更新するためのフェッチは、プッシュす
     る場合と同じように機能します。 つまり refspecに ‘+’ が無い場合(また
     は ‘--force’ が無い場合)、更新は拒否されます。

     git-push(1) でプッシュするときとは異なり、 ‘refs/{tags,heads}/*’ 以
     外の更新は、 refspecに ‘+’ がなくても(あるいは ‘--force’ 指定が無く
     ても)受け付けられます。例えば、ツリーオブジェクトとブロブを交換した
     り、あるコミットを、祖先を持たない別のコミットと交換したりできます
     。

     git-push(1) でプッシュする場合とは異なり、これらのルールを修正する
     構成はなく、 ‘pre-receive’ フックに類似した ‘pre-fetch’ フックのよ
     うなものはありません。

     git-push(1) を使用したプッシュと同様に、更新として許可されないもの
     に関する上記のすべてのルールは、refspec先頭にオプションで ‘+’ をに
     追加する(または ‘--force’ コマンドラインオプションを使用する)ことで
     オーバーライドできます。これに対する唯一の例外は、 ‘refs/heads/*’ 名
     前空間が非コミットオブジェクトを受け入れるように強制することはない
     ということです。

          *Note*

          フェッチするリモートブランチが定期的に巻き戻されてリベースされ
          ることがわかっている場合、その新しい先端は(最後にフェッチした
          ときにリモートトラッキングブランチに保存された)以前の先端の子
          孫ではないことが予想されます。あなたは ‘+’ 記号を使用して、そ
          のようなブランチにnon-fast-forwardの更新が必要であることを指示
          します。この操作でブランチがリポジトリで使用可能になることを決
          定または宣言する方法はありません。プルするユーザーは、これがブ
          ランチの予想される使用パターンであることを知っている必要があり
          ます。

‘--stdin’
     引数として提供されているものに加えて、標準入力からrefspecsを1行に
     1つずつ読み取ります。 「tag <name>」形式はサポートされていません。

GIT URLS
********

一般に、URLには、トランスポートプロトコル、リモートサーバーのアドレス、
およびリポジトリへのパスに関する情報が含まれています。トランスポートプロ
トコルによっては、一部の情報が欠落している場合があります。

   Gitはsshとgitとhttpとhttpsプロトコルをサポートします(さらにftpと
ftpsをフェッチに使用できますが、これは非効率的で非推奨です。使用しないで
ください)。

   ネイティブトランスポート(つまり、 git:// URL)は認証を行わないため、セ
キュリティで保護されていないネットワークでは注意して使用する必要がありま
す。

   以下の構文を使用できます:

   • ssh://[user@]host.xz[:port]/path/to/repo.git/

   • git://host.xz[:port]/path/to/repo.git/

   • http[s]://host.xz[:port]/path/to/repo.git/

   • ftp[s]://host.xz[:port]/path/to/repo.git/

   代替のscpのような構文をsshプロトコルで使用することもできます:

   • [user@]host.xz:path/to/repo.git/

   この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されま
す。これは、コロンを含むローカルパスを区別するのに役立ちます。たとえば、
ローカルパス ‘foo:bar’ を、絶対パスまたは ‘./foo:bar’ として指定して、
ssh url として誤って解釈されないようにすることができます。

   sshおよびgitプロトコルは、さらに ~username 拡張をサポートします:

   • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

   • git://host.xz[:port]/~[user]/path/to/repo.git/

   • [user@]host.xz:/~[user]/path/to/repo.git/

   Gitでもネイティブにサポートされているローカルリポジトリの場合、以下の
構文を使用できます:

   • /path/to/repo.git/

   • file:///path/to/repo.git/

   これらの2つの構文は、前者が ‘--local’ オプションの機能を含むクローン
作成の場合を除いて、ほとんど同等です。 詳細については、 git-clone(1) を
参照してください。

   「git clone」と「git fetch」と「git pull」は、「git push」と違って適
切なバンドルファイルを受け入れます。 git-bundle(1) を参照してください。

   Gitが特定のトランスポートプロトコルを処理する方法を知らない場合、
Gitは _remote-<transport>_ リモートヘルパー(存在する場合)を使用しようと
します。リモートヘルパーを明示的に要求するには、以下の構文を使用できます
:

   • <transport>::<address>

   ここで、 <address> は、パス、サーバーとパス、または呼び出されている特
定のリモートヘルパーによって認識される任意のURLのような文字列です。詳細
については、 gitremote-helpers(7) を参照してください。

   同じ名前のリモートリポジトリが多数あり、それらに異なる形式を使用する
場合(あなたの使用するURLが機能するURLに書き換えられるように)、以下の形式
の構成セクションを作成できます:

             [url "<actual url base>"]
                     insteadOf = <other url base>

   例えば、以下のようになります:

             [url "git://git.host.xz/"]
                     insteadOf = host.xz:/path/to/
                     insteadOf = work:

   "work:repo.git" や "host.xz:/path/to/repo.git" のようなURLは、任意の
コンテキストで、"git://git.host.xz/repo.git" に書き換えられます。

   プッシュ専用のURLを書き換えたい場合は、以下の形式の構成セクションを作
成できます:

             [url "<actual url base>"]
                     pushInsteadOf = <other url base>

   例えば、以下のようになります:

             [url "ssh://example.org/"]
                     pushInsteadOf = git://example.org/

   "git://example.org/path/to/repo.git" のようなURLは、プッシュの場合は
"ssh://example.org/path/to/repo.git" に書き換えられますが、プルは引き続
き元のURLのままです。

REMOTES
*******

‘<repository>’ 引数として、URLの代わりに以下のいずれかの名前を使用できま
す:

   • Git構成ファイル(configuration file)内のリモート(remote)として、
     ‘$GIT_DIR/config’ または

   • ‘$GIT_DIR/remotes’ ディレクトリ内のファイル または

   • ‘$GIT_DIR/branches’ ディレクトリ内のファイル

   これらはすべて、gitがデフォルトで使用するrefspecをそれぞれ含んでいる
ため、コマンドラインからrefspecを省略できます。

Named remote in configuration file
==================================

あなたは、 git-remote(1) を使うか、または git-config(1) を使うか、または
‘$GIT_DIR/config’ ファイルを手動で編集して、これ以前に構成したリモートの
名前から選択できます。このリモートのURLは、リポジトリへのアクセスに使用
されます。コマンドラインでrefspecを指定しない場合、このリモートの
refspecがデフォルトで使用されます。構成ファイルのエントリは以下のように
なります:

             [remote "<name>"]
                     url = <url>
                     pushurl = <pushurl>
                     push = <refspec>
                     fetch = <refspec>

   ‘<pushurl>’ はプッシュにのみ使用されます。 これはオプションであり、デ
フォルトは ‘<url>’ です。

Named file in $GIT_DIR/remotes
==============================

あなたは、 ‘$GIT_DIR/remotes’ でファイル名を指定できます。このファイルの
URLは、リポジトリへのアクセスに使用されます。コマンドラインでrefspecを指
定しない場合、このファイルのrefspecがデフォルトとして使用されます。この
ファイルの形式は以下のとおりです:

             URL: one of the above URL format
             Push: <refspec>
             Pull: <refspec>

   ‘Push:’ 行は ‘git push’ で使用され、 ‘Pull:’ 行は ‘git pull’ と ‘git
fetch’ で使用されます。追加のブランチマッピングのために、複数の ‘Push:’
および ‘Pull:’ 行を指定できます。

Named file in $GIT_DIR/branches
===============================

‘$GIT_DIR/branches’ でファイル名を指定できます。このファイルのURLは、リ
ポジトリへのアクセスに使用されます。 このファイルの形式は以下のとおりで
す:

             <url>#<head>

   ‘<url>’ は必須です。 ‘#<head>’ はオプションです。

   コマンドラインで指定しない場合、操作に応じて、gitは以下のrefspecのい
ずれかを使用します。 ‘<branch>’ は ‘$GIT_DIR/branchs’ 内のこのファイルの
名前であり、 ‘<head>`はデフォルトで `master’ になります。

   git fetch は以下を使用します:

             refs/heads/<head>:refs/heads/<branch>

   git push は以下を使用します:

             HEAD:refs/heads/<head>

CONFIGURED REMOTE-TRACKING BRANCHES
***********************************

あなたは、定期的かつ繰り返しフェッチすることで、同じリモートリポジトリと
やり取りすることがよくあります。 このようなリモートリポジトリの進行状況
を追跡するために、 ‘git fetch’ では ‘remote.<repository>.fetch’ 構成変数
を構成できます。

   通常、このような変数は以下のようになります:

     [remote "origin"]
             fetch = +refs/heads/*:refs/remotes/origin/*

   この構成は、以下の2つの方法で使用されます:

   • コマンドラインで取得するブランチやタグを指定せずに ‘git fetch’ を実
     行した場合、例えば ‘git fetch origin’ や ‘git fetch’ では
     ‘remote.<repository>.fetch’ の値が refspecs として使用され、取得す
     る ref と更新するローカル ref を指定します。 上記の例では、‘origin’
     に存在するすべてのブランチ(つまり、値の左辺 ‘refs/heads/*’ にマッチ
     するすべての ref)を取得し、対応するリモート追跡ブランチを
     ‘refs/remotes/origin/*’ 階層にあるものに更新します。

   • フェッチするブランチやタグをコマンドラインで明示的に指定して、 ‘git
     fetch’ を実行した場合、 たとえば ‘git fetch origin master’ すると、
     コマンドラインで指定された<refspec>が何をフェッチするかを決定し(た
     とえば、この例の ‘master`は、 `master:’ の省略形で、 「 ‘master' ブ
     ランチを取得しますが、どのリモート追跡ブランチを更新するかはコマン
     ドラインから明示的に指示しません」を意味します)、サンプルコマンドは
     「 'master' ブランチのみ」をフェッチします。
     `remote.<repository>.fetch’ 値は、更新されるリモート追跡ブランチが
     ある場合はそれを決定します。 このような使い方をすると、
     ‘remote.<repository>.fetch’ 値は、「何をフェッチするか」を決定する
     のに効果がありません(つまり、コマンドラインにrefspecsがリストされて
     いる場合、 ‘remote.<repository>.fetch’ 値はrefspecsとして使用されま
     せん)。 これらは、マッピングとして機能することにより、フェッチされ
     たrefがどこに保存されるかを決定するためにのみ使用されます。

   後者の ‘remote.<repository>.fetch’ 値の使用は、コマンドラインで
‘--refmap=<refspec>’ パラメーターを指定することでオーバーライドできます
。

PRUNING
*******

Gitには、明示的に破棄されない限り、データを保持するというデフォルトの性
質があります。 これは、ブランチを削除したリモートのブランチへのローカル
参照を保持することにまで及びます。

   蓄積したままにしておくと、これらの古い参照は、ブランチの撹拌が多い大
きく忙しいリポジトリでパフォーマンスを低下させる可能性があります。 ‘git
branch -a --contains <commit>’ のようなコマンドの出力を不必要に冗長にし
、既知の参照の完全なセットで機能する他のすべてに影響を与えます。

   これらのリモート追跡参照は、1回限りの利用で、以下のいずれかを使用して
削除できます:

     # While fetching
     $ git fetch --prune <name>

     # Only prune, don't fetch
     $ git remote prune <name>

   あなたの通常の作業フローの一部として参照を刈り込むには、それを実行す
ることを覚えておく必要はありません。設定で ‘fetch.prune’ をグローバルに
設定するか、 ‘remote.<name>.prune’ をリモート毎に設定します。
git-config(1) を参照してください。

   ここで、物事がトリッキーでより具体的になります。 刈り込み機能は実際に
はブランチを気にせず、代わりにリモートのrefspecの関数として ‘local <-->
remote-references’ を刈り込みます( ‘<refspec>’ および 上記 CONFIGURED
REMOTE-TRACKING BRANCHES (see [CRTB]) 参照)。

   したがって、リモートの refspec に、 たとえば
‘refs/tags/*:refs/tags/*’ が含まれていたり、 手動でたとえば ‘git fetch
--prune <name> "refs/tags/*:refs/tags/*"’ を実行したりすると、削除される
のは古いリモート追跡ブランチではなく、リモートには存在しないローカルタグ
が削除されます。

   これはあなたが期待したものではない可能性があります。つまり、リモート
‘<name>’ を刈り込むだけでなく、そこからタグを明示的にフェッチするため、
そこからフェッチするときに、すべてのローカルタグを削除します。 そのほと
んどは、そもそも ‘<name>’ リモートからのものではない可能性があります。

   したがって、これを ‘refs/tags/*:refs/tags/*’ のようなrefspec、または
複数のリモートからの参照を同じローカル名前空間にマップする可能性のある他
のrefspecで使用する場合は注意してください。

   リモートのブランチとタグの両方を最新に保つことはよくあることなので、
‘--prune’ と一緒に ‘--prune-tags’ オプションを指定することで、リモートに
存在しないローカルタグを削除し、異なるタグを強制更新することができます。
タグの刈り込みは、設定ファイルの ‘fetch.pruneTags’ や
‘remote.<name>.pruneTags’ で有効にすることもできます。 git-config(1) を
参照してください。

   ‘--prune-tags’ オプションは、「リモート」のrefspecsで
‘refs/tags/*:refs/tags/*’ を宣言するのと同じです。 これは、一見奇妙な相
互作用につながる可能性があります:

     # These both fetch tags
     $ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
     $ git fetch --no-tags --prune-tags origin

   ‘--prune’ またはその構成変数版なしで提供されたときにエラーにならない
理由は、構成変数版の柔軟性と、コマンドラインフラグの機能と構成変数版の機
能の間の 一対一 のマッピングを維持するためです。

   たとえば、 ‘~/.gitconfig’ で ‘fetch.pruneTags=true’ を構成して、
‘--prune’ なしで ‘git fetch’ を呼び出すたびにエラーが発生することなく、
‘git fetch --prune’ が実行されるたびにタグが刈り込まれるようにします。

   ‘--prune-tags’ によるタグの刈り込みは、名前付きリモートの代わりに URL
を取得するときにも機能します。 これらはすべて、origin で見つからなかった
タグを刈り込みます。

     $ git fetch origin --prune --prune-tags
     $ git fetch origin --prune 'refs/tags/*:refs/tags/*'
     $ git fetch <url of origin> --prune --prune-tags
     $ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'

OUTPUT
******

‘git fetch’ の出力は、使用する転送方法によって異なります。 このセクショ
ンでは、Gitプロトコル(ローカルまたはssh経由)およびスマートHTTPプロトコル
を介してフェッチする場合の出力について説明します。

   フェッチのステータスは表形式で出力され、各行は単一のrefのステータスを
表します。 各行の形式は以下のとおりです:

      <flag> <summary> <from> -> <to> [<reason>]

   最新のrefのステータスは、 ‘--verbose’ オプションが使用されている場合
にのみ表示されます。

   構成変数fetch.outputで指定されたコンパクト出力モードでは、他の文字列
に ‘<from>’ または ‘<to>’ 全体が見つかった場合、他の文字列内では ‘*’ に
置き換えられます。 たとえば、 ‘master -> origin/master’ は ‘master ->
origin/*’ になります。

flag
     refのステータスを示す1文字:

     (space)
          フェッチされた早送りの成功

     ‘+’
          強制更新の成功

     ‘-’
          refの刈り込みの成功

     ‘t’
          タグ更新の成功

     ‘*’
          新しいrefのフェッチの成功

     ‘!’
          拒否された、または更新に失敗したref

     ‘=’
          最新であり、フェッチする必要がなかったref

summary
     成功裏にフェッチされたrefの場合、概要には、refの古い値と新しい値が
     ‘git log’ の引数として使用するのに適した形式で表示されます(これはほ
     とんどの場合 ‘<old>..<new>’ であり、強制的な非早送り
     (non-fast-forward)更新の場合は ‘<old>...<new>’ です)。

from
     フェッチ元のリモートrefの名前から、その ‘refs/<type>/`プレフィック
     スを差し引いたもの。 削除の場合、リモートrefの名前は `(none)’ です
     。

to
     更新されるローカルrefの名前から、その ‘refs/<type>/’ プレフィックス
     を差し引いたもの。

reason
     人間が読める説明。 正常にフェッチされたrefの場合、説明は必要ありま
     せん。 失敗したrefについては、失敗の理由が説明されています。

EXAMPLES
********

   • リモートトラッキングブランチを更新します:

          $ git fetch origin

     上記のコマンドは、 branch.<name>.fetch オプションを使用してデフォル
     ト以外のrefspecを指定しない限り、すべてのブランチをリモート
     refs/heads/ 名前空間からコピーし、ローカル refs/remotes/origin/ 名
     前空間に格納します。

   • refspecsの明示的な使用:

          $ git fetch origin +seen:seen maint:tmp

     これにより、リモートリポジトリからブランチ ‘seen’ と ‘maint’ を(そ
     れぞれ)フェッチすることにより、ローカルリポジトリでブランチ ‘seen’
     と ‘tmp’ が更新(または必要に応じて作成)されます。

     ‘seen’ ブランチは、接頭辞にプラス記号(‘+’)が付いているため、早送り
     しなくても更新されます。 ‘tmp’ はそうしません。

   • あなたのローカルリポジトリで「リモート」を構成せずに、リモートのブ
     ランチをちらっと見ます(peek):

          $ git fetch git://git.kernel.org/pub/scm/git/git.git maint
          $ git log FETCH_HEAD

     最初のコマンドは ‘git://git.kernel.org/pub/scm/git/git.git’ のリポ
     ジトリから ‘maint’ ブランチをフェッチし、2番目のコマンドは
     ‘FETCH_HEAD’ を使用して git-log(1) でブランチを調べます。 フェッチ
     されたオブジェクトは、最終的にgitの組み込みの家政婦(housekeeping)に
     よって削除されます(git-gc(1) を参照)。

SECURITY
********

フェッチおよびプッシュプロトコルは、共有することを意図していない一方の側
が他方のリポジトリからデータを盗むのを防ぐようには設計されていません。悪
意のある者から保護する必要のあるプライベートデータがある場合、最善のオプ
ションはそれを別のリポジトリに保存することです。これは、クライアントとサ
ーバーの両方に適用されます。特に、サーバー上の名前空間は、読み取りアクセ
ス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼
できるクライアントにのみ、名前空間への読み取りアクセスを許可する必要があ
ります。

   既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は、明示的に共有することを意図していないオブジェクトのIDをア
     ドバタイズする "have" 行を送信しますが、他にもIDを持っている者が居
     る場合は、転送を最適化するために使用できます。攻撃者はオブジェクト
     ID Xを選択して盗み、refをXに送信しますが、被害者はすでにXのコンテン
     ツを持っているため、Xのコンテンツを送信する必要はありません。 これ
     で、被害者は攻撃者がXを持っていると信じ、Xのコンテンツを後で攻撃者
     に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間
     にXへのrefを作成してフェッチすることにより、クライアントがサーバー
     上で実行するのが最も簡単です。サーバーがクライアント上で実行する最
     も可能性の高い方法は、Xをパブリックブランチにマージし、ユーザーがこ
     のブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュ
     バックすることを期待します。)

  2. #1 と同様に、攻撃者は盗むオブジェクトID Xを選択します。被害者は、攻
     撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持
     っていると誤って主張するため、被害者はYをXに対するデルタとして送信
     します。デルタは、攻撃者にYに類似したXの領域を明らかにします。

BUGS
****

‘--recurse-submodules’ を使用すると、現在、すでにチェックアウトされてい
るサブモジュールでのみ新しいコミットをフェッチできます。 たとえば、アッ
プストリームは、スーパープロジェクトのフェッチされたばかりのコミットに新
しいサブモジュールを追加したとき、サブモジュール自体はフェッチできないた
め、後で再度フェッチを実行せずにそのサブモジュールをチェックアウトするこ
とはできません。 これは、将来のGitバージョンで修正される予定です。

SEE ALSO
********

git-pull(1)

GIT
***

Part of the git(1) suite

Name
****

git-filter-branch — ブランチを書き換えます

Synopsis
********

     git filter-branch [–setup <command>] [–subdirectory-filter <directory>]
             [–env-filter <command>] [–tree-filter <command>]
             [–index-filter <command>] [–parent-filter <command>]
             [–msg-filter <command>] [–commit-filter <command>]
             [–tag-name-filter <command>] [–prune-empty]
             [–original <namespace>] [-d <directory>] [-f | –force]
             [–state-branch <branch>] [–] [<rev-list options>…]

WARNING
*******

‘git filter-branch’ には、意図した履歴の書き換えに加えて明白でない変なも
のを生成することができる沢山の落とし穴があります(そして、酷い性能なので
、そのような問題を調査する時間がほとんどありません)。 これらの安全性とパ
フォーマンスの問題は、下位互換性を持って修正することはできないため、
‘git filter-branch’ 使用はお勧めしません。 git filter-repo
(https://github.com/newren/git-filter-repo/) などの代わりの履歴フィルタ
リングツールを使用してください。 それでもあなたが ‘git filter-branch’ を
使用する必要がある場合は、 see SAFETY (と PERFORMANCE)を注意
深く読んで、filter-branchの地雷について学び、リストされている危険の多く
を注意深く可能な限り回避してください。

DESCRIPTION
***********

あなたは <rev-list options> に記載されているブランチを書き換え、各リビジ
ョンにカスタムフィルターを適用することで、Gitリビジョン履歴を書き換える
ことができます。 これらのフィルターは、各ツリー(ファイルの削除やすべての
ファイルに対するperlリライトの実行など)または各コミットに関する情報を変
更できます。 それ以外の場合は、すべての情報(元のコミット時間またはマージ
情報を含む)が保持されます。

   このコマンドは、コマンドラインに記載されている「明らかな」
ref(positive ref)のみを書き換えます(たとえば、‘a..b’ を渡すと、 ‘b’ のみ
が書き換えられます)。 フィルタを指定しない場合、コミットは変更なしで再コ
ミットされますが、通常は効果がありません。 それでも、これは将来、Gitのバ
グなどを補うのに役立つ可能性があるため、このような使用は許可されています
。

     *Note*

     このコマンドは、 ‘.git/info/grafts’ ファイルと ‘refs/replace/’ 名前
     空間のrefを尊重します。 graftsまたは置換refが定義されている場合、こ
     のコマンドを実行するとそれらが永続的になります。

     *Warning*

     書き換えられた履歴は、すべてのオブジェクトに対して異なるオブジェク
     ト名を持ち、元のブランチに収束しません。 書き直されたブランチを元の
     ブランチの上に簡単にプッシュして配布することはできません。 あなたが
     完全な影響がわからない場合はこのコマンドを使用しないでください。 問
     題を解決するのに単純な単一のコミットで十分な場合は、とにかく使用し
     ないでください。 (公開された履歴の書き換えの詳細については、
     git-rebase(1) の「RECOVERING FROM UPSTREAM REBASE」セクションを参照
     してください。)

   書き換えられたバージョンが正しいことを常に確認(verify)してください。
書き換えられたものと異なる場合、元のrefは名前空間 ‘refs /original/’ に格
納されます。

   注意: この操作は入出力に非常にコストがかかるため、 ‘-d’ オプションを
使用して一時ディレクトリをディスク外にリダイレクト、たとえば tmpfs にす
ることをお勧めします。 聞いた限りでは、スピードアップは非常に顕著です。

Filters
=======

フィルタは、以下リストされた順序で適用されます。 <command> 引数は、(技術
的な理由より、コミットフィルターを除き、)常に ‘eval’ コマンドを使用して
シェルコンテキストで評価されます。 その前に ‘$GIT_COMMIT’ 環境変数は、書
き換えられるコミットのIDを含むように設定されます。 また、GIT_AUTHOR_NAME
と GIT_AUTHOR_EMAIL と GIT_AUTHOR_DATE と GIT_COMMITTER_NAME と
GIT_COMMITTER_EMAIL と GIT_COMMITTER_DATE 環境変数は現在のコミットから取
得されて環境変数にエクスポートされ、フィルター実行後に
git-commit-tree(1) が作成する代替コミット(replacement commit)の作者とコ
ミッターに影響を及ぼします。

   <command> のいずれかの評価がゼロ以外のexitステータスを返す場合、操作
全体が中止(abort)されます。

   「元のsha1 ID」引数を取り、コミットがすでに書き換えられている場合は「
書き換えられたsha1 ID」を出力し、それ以外の場合は「元のsha1 ID」を出力す
る「map」関数を使用できます。 コミットフィルターが複数のコミットを発行し
た場合、「map」関数は別々の行に複数のIDを返すことができます。

OPTIONS
*******

‘--setup <command>’
     これは、コミットごとに実行される実際のフィルターではなく、ループの
     直前に1回だけセットアップされます。 したがって、このフィルターコマ
     ンドではコミット固有の変数はまだ定義されていません。 ここで定義され
     た関数または変数は、技術的な理由により、コミットフィルターを除く次
     のフィルターステップで使用または変更できます。

‘--subdirectory-filter <directory>’
     指定のサブディレクトリにアクセスする履歴のみを探してください。 結果
     には、そのディレクトリ(かつ、それのみ)がプロジェクトルートとして含
     まれます。 Remap to ancestor を含んでいます。

‘--env-filter <command>’
     このフィルターは、コミットが実行される環境変数を変更するだけでよい
     場合に使用できます。 具体的には、 作者/コミッター名/電子メールアド
     レス/時間 の環境変数を書き直したい場合です(詳細については、
     git-commit-tree(1) 参照)。

‘--tree-filter <command>’
     これは、ツリーとその内容を書き換えるためのフィルターです。 フィルタ
     ーコマンドの引数は、チェックアウトされたツリーのルートに設定された
     作業ディレクトリを使用してシェルで評価されます。 その後、新しいツリ
     ーがそのまま使用されます(新しいファイルは自動的に追加され、消えたフ
     ァイルは自動的に削除されます。 ‘.gitignore’ ファイルも他の無視ルー
     ルも「効果がありません！」)。

‘--index-filter <command>’
     インデックスを書き換えるためのフィルタです。 これはツリーフィルター
     に似ていますが、ツリーをチェックアウトしないため、はるかに高速にな
     ります。 ‘git rm --cached --ignore-unmatch ...’ で頻繁に使用されま
     す。以下の例を参照してください。 ぞっとするほど危険なケースについて
     は、 git-update-index(1) を参照してください。

‘--parent-filter <command>’
     これは、コミットの親リストを書き換えるためのフィルターです。 フィル
     ターコマンドは stdinで親の文字列を受け取り、stdoutで新しい親の文字
     列を出力します。 親の文字列は、 git-commit-tree(1) で説明されている
     形式です。最初のコミットの場合は空、通常のコミットの場合は ‘-p
     parent’ 、 マージコミットの場合は ‘-p parent1 -p parent2 -p parent3
     ...’ です。

‘--msg-filter <command>’
     これは、コミットメッセージを書き換えるためのフィルターです。 フィル
     ターへの引数は、標準入力の元のコミットメッセージを使用してシェルで
     評価されます。 フィルターの標準出力は、新しいコミットメッセージとし
     て使用されます。

‘--commit-filter <command>’
     これは、コミットを実行するためのフィルターです。 このフィルターを指
     定すると、 ‘git commit-tree’ コマンドの代わりに、フィルターコマンド
     は ‘<TREE_ID> [(-p <PARENT_COMMIT_ID>)…]｀ 形式の引数とstdinのログ
     メッセージを使用して呼び出されます。 stdoutにはコミットIDを出力する
     ことが期待されています。

     特別な拡張機能として、コミットフィルターは複数のコミットIDを発行す
     る場合があります。 その場合、元のコミットの書き直された子は、それら
     すべてを親として持ちます。

     あなたはこのフィルターで「map」便利関数やその他の便利関数を使用する
     こともできます。 たとえば、 ‘skip_commit "$@"’ を呼び出すと、現在の
     コミットが除外されます(ただし、変更は除外されます！ 必要に応じて、
     代わりに ‘git rebase’ を使用してください)。

     単一の親でコミットを保持したくない場合は、 ‘git commit-tree "$@"’ の
     代わりに ‘git_commit_non_empty_tree "$@"’ を使用することもできます
     。これにより、ツリーは変更されることはありません。

‘--tag-name-filter <command>’
     これは、タグ名を書き換えるためのフィルターです。 このフィルタが渡さ
     れると、書き換えられたオブジェクト(または書き換えられたオブジェクト
     を指すタグオブジェクト)を指す全てのタグrefに対してこのフィルタが呼
     び出されます。 元のタグ名は標準入力を介して渡され、新しいタグ名を標
     準出力に出力することが期待されます。

     元のタグは削除されませんが、上書きできます。 ‘--tag-name-filter
     cat’ を使用して、タグを更新するだけです。 この場合、変換が失敗した
     場合に備えて、古いタグをバックアップしておくなど、十分な注意が必要
     です。

     タグオブジェクトは、ほぼ適切な書き換えがサポートされています。 タグ
     にメッセージが添付されている場合、同一のメッセージと作者とタイムス
     タンプを使用して新しいタグオブジェクトが作成されます。 タグに署名が
     付いている場合、署名は削除されます。 定義上、署名を保持することは不
     可能です。 これが「ほぼ」適切である理由は、理想的には、タグが変更さ
     れていない場合(同じオブジェクトを指している、同じ名前を持っているな
     ど)、署名を保持する必要があるためです。しかし署名は保持されません。
     署名は常に削除されます。 利用者は注意してください。 また、作者また
     はタイムスタンプ(またはそのことについてのタグメッセージ)を変更する
     こともサポートされていません。 他のタグを指すタグは、基になるコミッ
     トを指すように書き直されます。

‘--prune-empty’
     一部のフィルターは、ツリーをそのままにしておく空のコミットを生成し
     ます。 このオプションは、刈り込みされていない親が1個または0個しかな
     い場合に、そのようなコミットを削除するようにgit-filter-branchに指示
     します。 したがって、マージコミットはそのまま残ります。 このオプシ
     ョンは ‘--commit-filter’ と一緒に使用することはできませんが、コミッ
     トフィルターで提供されている ‘git_commit_non_empty_tree’ 関数を使用
     することで同じ効果を得ることができます。

‘--original <namespace>’
     このオプションを使用して、元のコミットが保存される名前空間を設定し
     ます。 デフォルト値は ‘refs/original’ です。

‘-d <directory>’
     このオプションを使用して、書き換えに使用される一時ディレクトリへの
     パスを設定します。 ツリーフィルターを適用する場合、コマンドは一時的
     にツリーをあるディレクトリにチェックアウトする必要があります。これ
     は、大規模なプロジェクトの場合、かなりのスペースを消費する可能性が
     あります。 デフォルトでは、これは ‘.git-rewrite/’ ディレクトリで行
     われますが、このパラメータでその選択を上書きできます。

‘-f’
‘--force’
     ‘git filter-branch’ は、強制されない限り、既存の一時ディレクトリで
     の開始を拒否するか、 ‘refs/original/’ で始まるrefがすでに存在する場
     合に拒否します。

‘--state-branch <branch>’
     このオプションを使用すると、古いオブジェクトから新しいオブジェクト
     へのマッピングが、起動時に名前付きブランチから読み込まれ、終了時に
     そのブランチへの新しいコミットとして保存され、大きなツリーの増分が
     可能になります。 ‘<branch>’ が存在しない場合は、作成されます。

<rev-list options>…
     ‘git rev-list’ の引数。 これらのオプションに含まれるすべての正の
     ref(positive refs)は書き直されます。 ‘--all’ などのオプションを指定
     することもできますが、それらを ‘git filter-branch’ のオプションから
     分離するには ‘--’ を使用する必要があります。 Remap to ancestor
     を含んでいます。

Remap to ancestor
=================

git-rev-list(1) の引数、たとえばパスリミッター、を使用すると、書き換えら
れるリビジョンのセットを制限できます。 ただし、コマンドラインの正のrefは
区別されます。このようなリミッターによって除外されることはありません。 こ
の目的のために、代わりに、除外されなかった最も近い祖先を指すように書き直
されます。

EXIT STATUS
***********

成功すると、終了ステータスは「0」になります。 フィルタが書き換えるコミッ
トを見つけられない場合、終了ステータスは「2」です。 その他のエラーの場合
、終了ステータスはその他のゼロ以外の値である可能性があります。

EXAMPLES
********

すべてのコミットからファイル(機密情報または著作権違反を含む)を削除すると
すると:

     git filter-branch --tree-filter 'rm filename' HEAD

   しかしながら、ファイルがコミットのツリーに存在しない場合、単純な ‘rm
filename’ はそのツリーとコミットで失敗します。 したがって、代わりにスク
リプトとして ‘rm -f filename’ を使用することをお勧めします。

   ‘--index-filter’ を ‘git rm’ と一緒に使用すると、非常に高速なバージョ
ンが生成されます。 ‘rm filename’ を使用する場合と同様に、ファイルがコミ
ットのツリーに存在しない場合、 ‘git rm --cached filename’ は失敗します。
ファイルを「完全に忘れる」場合は、ファイルがいつ履歴に入力されたかは関係
ないため、 ‘--ignore-unmatch’ :

     git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

   これで、書き換えられた履歴がHEADに保存されます。

   ‘foodir/’ がプロジェクトルートであるかのようにリポジトリを書き直し、
他のすべての履歴を破棄するには:

     git filter-branch --subdirectory-filter foodir -- --all

   したがって、たとえば、ライブラリサブディレクトリを独自のリポジトリに
変えることができます。 注意: ‘filter-branch’ オプションをリビジョンオプ
ションから分離する ‘--’ と、すべてのブランチとタグを書き換えるための
‘--all’ に注意してください。

   (通常は他の履歴の先端にある)あるコミットを現在の初期コミットの親に設
定し、他の履歴を現在の履歴の後ろに貼り付ける:

     git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD

   (親の文字列が空の場合 — それは最初のコミットを処理しているときに発生
します — 親として graftcommit を追加します)。 注意: これは、単一のルート
を持つ履歴を想定していることに注意してください(つまり、共通の祖先がない
とマージは発生しません)。 そうでない場合は、以下を使用してください:

     git filter-branch --parent-filter \
             'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD

   または、さらに簡単に:

     git replace --graft $commit-id $graft-id
     git filter-branch $graft-id..HEAD

   「Darl McBribe」によって作成されたコミットを履歴から削除するには:

     git filter-branch --commit-filter '
             if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
             then
                     skip_commit "$@";
             else
                     git commit-tree "$@";
             fi' HEAD

   関数 ‘skip_commit’ は以下のように定義されています:

     skip_commit()
     {
             shift;
             while [ -n "$1" ];
             do
                     shift;
                     map "$1";
                     shift;
             done;
     }

   シフトの魔法により、最初にツリーIDを破棄し、次に ‘-p’ パラメーターを
破棄します。 注意: このハンドルは適切にマージされます！ DarlがP1とP2の間
のマージをコミットした場合、それは適切に伝播され、マージのすべての子は、
マージコミットではなく、親としてP1、P2を持つマージコミットになります。

     *Note*

     コミットによって導入され、後続のコミットによって元に戻され無い変更
     は、引き続き書き換えられたブランチに残ります。 あなたがコミットと一
     緒に「変更」を破棄したい場合、 あなたは ‘git rebase’ の対話モードを
     使用する必要があります。

   ‘--msg-filter’ を使用してコミットログメッセージを書き換えることができ
ます。 たとえば、 ‘git svn’ によって作成されたリポジトリ内の "git
svn-id" 文字列は、以下の方法で削除できます:

     git filter-branch --msg-filter '
             sed -e "/^git-svn-id:/d"
     '

   たとえば、最後の10個のコミット(いずれもマージではない)に ‘Acked-by’ 行
を追加する必要がある場合は、以下のコマンドを使用します:

     git filter-branch --msg-filter '
             cat &&
             echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
     ' HEAD~10..HEAD

   ‘--env-filter’ オプションを使用して、コミッターや作者のIDを変更できま
す。 たとえば、user.emailの設定が間違っているためにコミットのIDが間違っ
ていることがわかった場合は、プロジェクトを公開する前に、以下のように修正
できます:

     git filter-branch --env-filter '
             if test "$GIT_AUTHOR_EMAIL" = "root@localhost"
             then
                     GIT_AUTHOR_EMAIL=john@example.com
             fi
             if test "$GIT_COMMITTER_EMAIL" = "root@localhost"
             then
                     GIT_COMMITTER_EMAIL=john@example.com
             fi
     ' -- --all

   履歴の一部のみに書き換えを制限するには、新しいブランチ名に加えてリビ
ジョン範囲を指定します。 新しいブランチ名は、この範囲の ‘git rev-list’ が
出力する最上位のリビジョンを指します。

   以下の履歴について考えてみましょう:

          D--E--F--G--H
         /     /
     A--B-----C

   コミット D,E,F,G,H だけを書き換えて、 A,B,C はそのままにするには、以
下のようにします:

     git filter-branch ... C..H

   コミット E,F,G,H を書き換えるには、以下のどちらかを使用します:

     git filter-branch ... C..H --not D
     git filter-branch ... D..H --not C

   ツリー全体をサブディレクトリに移動する、またはそこから削除するには:

     git filter-branch --index-filter \
             'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
                     GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
                             git update-index --index-info &&
              mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD

リポジトリ縮小チェックリスト
****************************

git-filter-branchは、ファイルのサブセットを取り除くために使用できます。
通常は、 ‘--index-filter’ と ‘--subdirectory-filter’ を組み合わせて使用
します。 人々は結果のリポジトリが元のリポジトリよりも小さいことを期待し
ていますが、Gitは指示があるまでオブジェクトを失わないように努力するため
、実際にリポジトリを小さくするにはさらにいくつかの手順が必要です。 まず
は以下のことを確認してください:

   • ブロブがその存続期間中に移動された場合、あなたはファイル名のすべて
     の派生を本当に削除したことになります。 ‘git log --name-only
     --follow --all -- filename’ は、名前の変更を見つけるのに役立ちます
     。

   • git-filter-branch を呼び出す際に ‘--tag-name-filter cat -- --all’ を
     使用すると、本当にすべての refs をフィルタリングすることができます
     。

   次に、より小さなリポジトリを取得する2つの方法があります。 より安全な
方法は、クローンを作成することです。これにより、あなたの元のファイルがそ
のまま保持されます。

   • ‘git clone file:///path/to/repo’ でクローンを作成します。 クローン
     には削除されたオブジェクトはありません。 git-clone(1) を参照してく
     ださい。 (注意: 普通のパス指定でクローンを作成すると、すべてがハー
     ドリンクされてしまうことに注意してください！)

   あなたがなんらかの理由でマヂでクローンを作成したくない場合は、代わり
に以下の点を(この順序で)確認してください。 これは非常に破壊的なアプロー
チであるため、「バックアップを作成」するか、クローン作成に戻ってください
。いいですね？我々はちゃんと警告しましたよ。

   • git-filter-branchによってバックアップされた元のrefを削除します。そ
     のためには ‘git for-each-ref --format="%(refname)" refs/original/ |
     xargs -n 1 git update-ref -d’ とします。

   • ‘git reflog expire --expire=now --all’ を使用してすべてのreflogを期
     限切れにします。

   • ガベージコレクションでは、参照されていないすべてのオブジェクトを
     ‘git gc --prune=now’ で収集します(または、git-gcが ‘--prune’ の引数
     をサポートするほど新しいバージョンでない場合は、代わりに ‘git
     repack -ad; git prune’ を使用します)。

PERFORMANCE
***********

git-filter-branch の性能は氷河の流れのように劇遅で、その設計上、後方互換
性のある実装が高速になることはあり得ません:

   • ファイルの編集では、git-filter-branchは設計上、元のリポジトリに存在
     していたすべてのコミットをチェックアウトします。 リポジトリに
     ‘10^5’(10万)個のファイルと ‘10^5’(10万)個のコミットがあり、それぞれ
     のコミットで変更されるのが5個のファイルしか変更していない場合、
     git-filter-branchを使用すると、(最大)‘5*10^5’(50万)個のユニークなブ
     ロブしかないにもかかわらず、あなたは ‘10^10’(百億)個の変更を行うハ
     メになります。

   • あなたがズルしようとして、コミットで変更されたファイルに対してのみ
     git-filter-branchが機能するようにしようとすると、2つのことが起こり
     ます。

        • ユーザーが単にファイルの名前を変更しようとすると、削除の問題が
          発生します(存在しないファイルを削除しようとすると、何もしない
          (no-op)ように見えるためです。 ユーザーが提供する任意のシェルを
          介して名前の変更が行われる場合、ファイルの名前変更全体で削除を
          再マップするには、多少の手間がかかります)

        • あなたが map-deletes-for-renames という奇策によって成功した場
          合でも、技術的に下位互換性に違反します。なぜなら、ユーザーはフ
          ァイルの内容や名前だけに基づいてフィルタリングするのではなく、
          コミットのトポロジに依存する方法でファイルをフィルタリングでき
          るからです(ただし、実際にこれが観察されたわけではありません)。

   • あなたはファイルを編集する必要はないが、たとえば 一部の名前を変更ま
     たは削除すると、各ファイルのチェックアウトを回避できます(つまり、
     ‘--index-filter’ を使用できます)が、あなたのフィルターのシェルスニ
     ペットは引き続き渡されます。つまり、コミットごとに、これらのフィル
     ターを実行できるgitリポジトリを準備する必要があります。 これは重要
     な設定です。

   • さらに、git-filter-branchによって、コミットごとにいくつかの追加ファ
     イルが作成または更新されます。 これらのいくつかは、
     git-filter-branchによって提供される便利な関数(map()など)をサポート
     するためのものであり、その他は内部状態を追跡するためのものです(ただ
     し、ユーザーフィルターによってアクセスされる可能性もあります。
     git-filter-branch の回帰(regression)テストはそうします)。 これは基
     本的に、ファイルシステムをgit-filter-branchとユーザー提供のフィルタ
     ー間のIPCメカニズムとして使用することを意味します。 ディスクは遅い
     IPCメカニズムになりがちで、これらのファイルを書くことは、コミットす
     るたびにぶつかる、別々のプロセス間の強制的な同期ポイントを効果的に
     表しています。

   • ユーザー提供のシェルコマンドには、コマンドのパイプラインが含まれる
     可能性が高く、コミットごとに多くのプロセスが作成されます。 別のプロ
     セスを作成して実行するのにかかる時間はOSによって大きく異なりますが
     、どのプラットフォームでも関数を呼び出すのに比べると非常に遅くなり
     ます。

   • git-filter-branch自体はシェルで記述されているため、少し時間がかかり
     ます。 これは、下位互換性で修正できるパフォーマンスの問題の1つです
     が、git-filter-branchの設計に固有の上記の問題と比較すると、ツール自
     体の言語は比較的小さな問題です。

        • 補足: 残念ながら、人々はシェルで書かれた側面に固執し、パフォー
          マンスの問題を修正するためにgit-filter-branchを別の言語で書き
          直すことができるかどうかを定期的に尋ねる傾向があります。それは
          、設計に内在する大きな問題を無視することになるばかりか、期待す
          るほどには役に立たないでしょう。 もし git-filter-branch 自体が
          shell でなかったら、便利な関数 (map(), skip_commit() など) と
          ‘--setup’ 引数はプログラムの最初に一度実行するだけでよくなり、
          代わりにすべてのユーザーフィルターで前置する必要がありました
          (つまりコミットごとに再実行されることになります)。

   git filter-repo (https://github.com/newren/git-filter-repo/) ツールは
、git-filter-branchの代替手段で、これらのパフォーマンスの問題や安全性の
問題(後述)の影響を受けません。 git-filter-branchに依存する既存のツールを
使用している場合、 ‘git filter-repo’ は filter-lamely
(https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely)
も提供し、これは差し込み式の git-filter-branch の代替品です(いくつかの注
意点があります)。 filter-lamelyは、git-filter-branchと同じ安全性の問題に
悩まされていますが、少なくともパフォーマンスの問題を少し改善します。

SAFETY
******

git-filter-branch は、様々な方法で簡単にリポジトリを破損させたり、最初よ
りもひどい状態に陥らせたりするゴチャゴチャがたくさんあります:

   • 誰かが「動作してテストされたフィルター」のセットを持っている可能性
     があり、それを文書化するか、同僚に提供し、同僚は、同じコマンドが 動
     作/テスト されていない別のOSでそれらを実行したとします
     (git-filter-branchのmanページのいくつかの例もこの影響を受けます)。
     BSDとGNUのユーザーランドの違いが本当に噛み付いてくる可能性がありま
     す(運が良ければ、エラーメッセージが表示されます)。 同様に、コマンド
     は要求されたフィルタリングを実行しないか、不要な変更を加えることで
     黙って破損させます。 不要な変更は、いくつかのコミットにのみ影響する
     可能性があるため、必ずしも明らかではありません。 (問題が明らかにな
     らないということは、書き換えた履歴がしばらく使われていないと気づか
     ない可能性が高く、気付いた時点で、もう一度書き換えるための正当な位
     置を探し出すのは本当に難しいのです。)

   • スペースを含むファイル名は、シェルパイプラインに問題を引き起こすた
     め、シェルスニペットによって誤って処理されることがよくあります。 誰
     もが ‘find -print0’ 、 ‘xargs -0’ 、‘git-ls-files -z’ などに精通し
     ているわけではありません。 これらに精通している人でさえ、フィルタリ
     ングを行っている人がプロジェクトに参加する前に、他の誰かが既にリポ
     ジトリ内のそのようなファイルの名前を変更済であったため、そのような
     フラグは関係ないと考えるかもしれません。 そして、しばしば、スペース
     を使用した引数の処理に精通している人でさえ、うまくいかない可能性の
     あるすべてのことを考えるという考え方を持っていないという理由でそう
     しない場合があります。

   • 非ASCIIファイル名は、目的のディレクトリにあるにもかかわらず、黙って
     削除できます。 必要なパスのみを保持することは、多くの場合、 ‘git
     ls-files | grep -v ^WANTED_DIR/ | xargs git rm’ のようなパイプライ
     ンを使用して行われます。 ls-filesは必要な場合にのみファイル名を引用
     するため、ファイルの1つが正規表現と一致しなかったことに気付かない場
     合があります(少なくとも手遅れになるまでは)。 ええ、 core.quotePath
     を知っている人は(‘\t’, ‘\n’, or ‘"’ などの他の特殊文字がなければ、
     )これを避けることができるし、 ‘ls-files -z’ を grep 以外のもので使
     う人はこれを避けることができますが、だからといって避けてくれるとは
     限りません。

   • 同様に、ファイルを移動すると、ASCII以外の文字または特殊文字を含むフ
     ァイル名が、二重引用符を含む別のディレクトリに配置されることがあり
     ます。 (これは技術的には上記のクォートと同じ問題ですが、おそらく興
     味深いことに、この問題は別の形で現れる可能性がありますし、実際に問
     題として現れています。)

   • 実に簡単に古い履歴と新しい履歴を誤って混同してしまいます。それはど
     のツールでも起こりうるのですが、git-filter-branch その多くをやらか
     します。 運が良ければ、唯一の欠点は、リポジトリを縮小して古いものを
     削除する方法がわからないことにユーザーが不満を感じることです。 運が
     悪ければ、古い履歴と新しい履歴がマージされ、各コミットの複数の「コ
     ピー」が作成されます。その中には、不要なファイルや機密ファイルが含
     まれるものと、含まれないものがあります。 これが複数の異なる方法で発
     生します。

        • 履歴の部分的な書き換えのみを行うデフォルト(‘--all’ はデフォル
          トではない。そして、これを示す例もほとんどない)。

        • 実行後の自動クリーンアップがないという事実

        • ‘--tag-name-filter’ (タグの名前を変更するために使用される場合
          )は古いタグを削除せず、新しい名前で新しいタグを追加するだけで
          あるという事実

        • 書き換えの影響や、古い履歴と新しい履歴の混在を避ける方法をユー
          ザーに知らせるための教育的な情報がほとんど提供されていないこと
          です。 たとえば、この man ページでは、すべてのブランチの変更を
          新しい履歴の上にリベースする((あるいは削除して再クローンする
          )必要があることをユーザーが理解する必要があることを述べていま
          すが、これは考慮すべき複数の懸念事項のうちのひとつにすぎません
          。 詳しくは、 ‘git filter-repo’ マニュアルページの「
          DISCUSSION」セクションをご覧ください。

   • 以下の2つの問題のいずれかが原因で、注釈付きタグが誤って軽量タグに変
     換される可能性があります:

        • 誰かが履歴の書き換えを行い、混乱したことに気づき、
          ‘refs/original/’ のバックアップから復元してから、
          git-filter-branchコマンドをやり直すことができます。
          (‘refs/original/’ のバックアップは実際のバックアップではありま
          せん。最初にタグを逆参照します。)

        • <rev-list options> で ‘--tags’ または ‘--all’ を指定して
          git-filter-branchを実行します。 注釈付きタグ(annotated tags)を
          注釈(annotated)として保持するには、 ‘--tag-name-filter’ を使用
          する必要があります(以前に失敗した書き換えで ‘refs/original/’ か
          ら復元してはいけません)。

   • エンコーディング指定のコミットメッセージは、書き換えによって破損し
     ます。 git-filter-branchはエンコーディングを無視し、元のバイトを取
     得して、適切なエンコーディングを通知せずにコミットツリーにフィード
     します。 (これは、 ‘--msg-filter’ が使用されているかどうかに関係な
     く発生します。)

   • コミットメッセージ(それが全てUTF-8であっても)はデフォルトでは更新さ
     れないため破損します — コミットメッセージ内の他のコミットハッシュへ
     の参照は、もはや存在しないコミットを参照するようになります。

   • ユーザーが削除すべき不純物を見つけるのを助ける機能はありません。つ
     まり、不完全または部分的なクリーンアップが行われる可能性が高く、時
     には混乱を招き、人々は理解しようとして時間を浪費することになります
     。 (たとえば、ユーザーは大きなディレクトリや拡張子ではなく、削除す
     べき大きなファイルを探す傾向があり、いったんそうしてしまうと、後で
     新しいリポジトリを使って履歴を調べている人たちは、いくつかのファイ
     ルがあるのに他のファイルがないビルド成果物ディレクトリや、いくつか
     のファイルがないので機能しなかったはずの依存関係のキャッシュ
     ((node_modules など)に気づくことになります)。

   • ‘--prune-empty’ が指定されていない場合、フィルタリングプロセスによ
     り、混乱を招く空のコミットが大量に発生する可能性があります

   • ‘--prune-empty’ が指定されている場合、フィルタリングルールによって
     空になったコミットを刈り込みするだけでなく、フィルタリング操作の前
     から意図的に配置された空のコミットも刈り込みされます。

   • ‘--prune-empty’ が指定されている場合、空のコミットが失われたり、と
     にかく全部残されることがあります(多少まれなバグですが、発生します…)

   • 些細なことですが、リポジトリ内のすべての名前と電子メールを更新する
     という目標を持っているユーザーは、著者とコミッターのみを更新し、タ
     ガー(tagger)を見逃す ‘--env-filter’ に誘導されるかもしれません。

   • ユーザーが複数のタグを同じ名前にマップする ‘--tag-name-filter’ を提
     供した場合、警告やエラーは提供されません。 git-filter-branchは、文
     書化されていない事前定義された順序で各タグを上書きするだけで、最後
     に1つのタグのみが生成されます。 (git-filter-branch回帰テストは、こ
     の驚くべき振る舞いがを要求します。)

   また、 ‘git-filter-branch’ のパフォーマンスが低いと、安全性の問題が発
生することがよくあります:

   • あなたが望むフィルタリングを行うための正しいシェルスニペットを考え
     出すことは、いくつかのファイルを削除するような些細な修正を行うので
     ない限り、時に困難なことです。 しかし、その正否は特殊な状況((ファイ
     ル名にスペースがある、非ASCIIのファイル名、おかしな著者名やメール、
     無効なタイムゾーン、grafts や replace オブジェクトがあるなど)によっ
     て異なるため、長い間待ってエラーになり、再起動しなければならないこ
     とがあります。 git-filter-branch の性能は非常に悪いので、このサイク
     ルは苦痛であり、慎重に再チェックする時間が減ってしまいます (たとえ
     技術的に余裕があったとしても、書き直す人の忍耐力に影響を与えること
     は言うまでもありません)。 壊れたフィルターによるエラーは長い間表示
     されなかったり、出力の海に紛れたりするので、この問題はさらに深刻に
     なります。 さらに悪いことに、フィルターが壊れていると、ただ黙って間
     違った書き直しをすることになりがちです。

   • さらに言えば、ユーザーがようやく動作するコマンドを見つけたら、それ
     を共有したいと思うのは自然なことです。 しかし、自分のリポジトリには
     ない特別なケースが他の人のリポジトリにはあることに気づいていないか
     もしれません。 そのため、異なるリポジトリを持つ他の人が同じコマンド
     を実行すると、上記のような問題に見舞われることになります。 あるいは
     、そのユーザーは、本当に特殊なケースを想定して吟味されたコマンドを
     実行しているだけなのですが、それを別のOSで実行すると、上に書いたよ
     うに、うまくいかないのです。

GIT
***

Part of the git(1) suite

Name
****

git-fmt-merge-msg — git-fmt-merge-msg-マージコミットメッセージを生成しま
す

Synopsis
********

     git fmt-merge-msg [-m <message>] [–log[=<n>] | –no-log]
     git fmt-merge-msg [-m <message>] [–log[=<n>] | –no-log] -F <file>

DESCRIPTION
***********

標準入力からマージされたオブジェクトのリストを取得し、マージコミットに使
用される適切なコミットメッセージを生成します。通常は、 _git merge_ の
_<merge-message>_ 引数として渡されます。

   このコマンドは主に、 _git merge_ を自動的に呼び出すスクリプトによる内
部使用を目的としています。

OPTIONS
*******

‘--log[=<n>]’
     ブランチ名に加えて、マージされている実際のコミットからの1行説明をロ
     グメッセージに入力します。各マージ親からの最大で <n> のコミットが使
     用されます(<n> が省略されている場合は20)。これは、 ‘merge.log’ 構成
     変数をオーバーライドします。

‘--no-log’
     マージされる実際のコミットからの1行説明をリストしません。

‘--[no-]summary’
     ‘--log’ や ‘--no-log’ の同義語。これは非推奨であり、将来削除される
     予定です。

‘-m <message>’
‘--message <message>’
     ログメッセージの最初の行に、ブランチ名の代わりに <message> を使用し
     ます。 ‘--log’ で使用します。

‘-F <file>’
‘--file <file>’
     標準入力の代わりに <file> からマージされたオブジェクトのリストを取
     得します。

CONFIGURATION
*************

merge.branchdesc
     ブランチ名に加えて、それらに関連付けられたブランチの説明テキストを
     ログメッセージに入力します。デフォルトはfalseです。

merge.log
     ブランチ名に加えて、マージされる実際のコミットからの最大「指定の数
     」の親コミットの1行説明をログメッセージに入力します。デフォルトは
     falseで、trueは20の同義語です。

merge.suppressDest
     統合ブランチの名前に一致するグロブをこの複数値の構成変数
     (multi-valued configuration variable)に追加することにより、これらの
     統合ブランチへのマージに対して計算されるデフォルトのマージメッセー
     ジは、タイトルから「into <branch name>」を省略します。

     空の値を持つ要素を使用して、以前の構成エントリから蓄積されたグロブ
     のリストをクリアできます。 ‘merge.suppressDest’ 変数が定義されてい
     ない場合、下位互換性のためにデフォルト値の ‘master’ が使用されます
     。

merge.summary
     ‘merge.log’ の同義語。これは非推奨であり、将来削除される予定です。

EXAMPLES
********

     $ git fetch origin master
     $ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD

   「origin」リモートからの「master」ブランチのマージを説明するログメッ
セージを出力します。

SEE ALSO
********

git-merge(1)

GIT
***

Part of the git(1) suite

Name
****

git-for-each-ref — 各refに関する情報を出力します

Synopsis
********

     git for-each-ref [–count=<count>] [–shell|–perl|–python|–tcl]
                        [(–sort=<key>)…] [–format=<format>] [<pattern>…]
                        [–points-at=<object>]
                        [–merged[=<object>]] [–no-merged[=<object>]]
                        [–contains[=<object>]] [–no-contains[=<object>]]

DESCRIPTION
***********

‘<pattern>’ に一致するすべてのrefを繰り返し、指定された ‘<key>’ の組に従
って並べ替えた後、指定の ‘<format>’ に従って表示します。 ‘<count>’ が指
定されている場合は、その数のrefを表示した後で停止します。 ‘<format>’ の
プレースホルダで差し込みされる値は、オプションで、指定のホストプログラム
言語の文字列リテラルとなるようクォートでき、そのホストプログラム言語で直
接評価できます。

OPTIONS
*******

<pattern>…
     1つ以上のパターンが指定されている場合、少なくとも1つのパターンに一
     致する参照のみが表示されます。fnmatch(3) を使用するか、文字通り
     (lietrally)に書くかです。文字通りに書いた場合場合、完全に一致するか
     、最初からスラッシュ(‘/’)まで一致するかです。

‘--count=<count>’
     デフォルトでは、コマンドは ‘<pattern>’ に一致するすべてのrefを表示
     します。このオプションは、指定の数のrefを表示した後に停止します。

‘--sort=<key>’
     並べ替えるフィールド名。 プレフィックス ‘-`を使用して、値の降順で並
     べ替えます。 並べ替えるフィールド名を指定しない場合 `refname’ が使
     用されます。 ‘--sort=<key>’ オプションは複数回使用できます。その場
     合、最後のキーが主キー(primary key)になります。

‘--format=<format>’
     表示されているrefとそれが指すオブジェクトを ‘%(fieldname)’ によって
     を差し込みする書式文字列。 ‘fieldname’ の前にアスタリスク(‘*’)が付
     いていて、refがタグオブジェクトを指している場合は、(タグオブジェク
     トのフィールドではなく)タグオブジェクトが参照するオブジェクトのフィ
     ールドの値を使用します。このオプションを指定しない場合、 ‘<format>’
     はデフォルトで ‘%(objectname) SPC %(objecttype) TAB %(refname)’ で
     す。また ‘%%’ は ‘%’ を差し込み、 ‘%xx’ (‘xx’ は16進数)は16進コード
     ‘xx’ の文字を差し込みます。 たとえば、‘%00’ は ‘\0’ (NUL) を、
     ‘%09’ は ‘\t’ (TAB) を、 ‘%0a’ は ‘\n’ (LF) を、それぞれ差し込みま
     す。

‘--color[=<when>]’
     ‘--format’ オプションで指定された色を尊重します。 ‘<when>’ フィール
     ドは ‘always’ または ‘never’ または ‘auto’ のいずれかでなければなり
     ません(‘<when>’ がない場合は、 ‘always’ が指定されたかのように動作
     します)。

‘--shell’
‘--perl’
‘--python’
‘--tcl’
     指定した場合、 ‘%(fieldname)’ プレースホルダーを置き換える文字列は
     、指定のホストプログラム言語に適した文字列リテラルとしてクォートし
     ます。これは、直接「評価」(eval)できるスクリプトレットを作成するこ
     とを目的としています。

‘--points-at=<object>’
     指定のオブジェクトを指すrefのみをリストします。

‘--merged[=<object>]’
     指定のコミット(指定されていない場合はHEAD)から先端に到達できるrefの
     みをリストします。

‘--no-merged[=<object>]’
     指定のコミット(指定されていない場合はHEAD)から先端に到達できない
     refのみをリストします。

‘--contains[=<object>]’
     指定のコミット(指定されていない場合はHEAD)を含むrefのみをリストしま
     す。

‘--no-contains[=<object>]’
     指定のコミット(指定されていない場合はHEAD)を含まないrefのみをリスト
     します。

‘--ignore-case’
     refの並べ替え(sort)とフィルタリングでは英大文字小文字を区別しません
     。

FIELD NAMES
***********

参照オブジェクトの構造化フィールドのさまざまな値を使用して、結果の出力に
差し込みしたり、ソートキーとして使用したりできます。

   すべてのオブジェクトで、以下の名前を使用できます:

refname
     refの名前( $GIT_DIR/ の後の部分)。refのあいまいでない短い名前の場合
     は、 ‘:short’ を追加します。オプション core.warnAmbiguousRefs は、
     厳密な省略形モードを選択するために使用されます。 ‘lstrip=<N>’
     (‘rstrip=<N>’) が追加された場合、refnameの前(後ろ)からスラッシュ
     (‘/’)で区切られたパスの部分を‘<N>‘ 個削除します(例:
     ‘%(refname:lstrip=2)’ は ‘refs/tags/foo’ を ‘foo’ に変換し、
     ‘%(refname:rstrip=2)’ は ‘refs/tags/foo’ を ‘refs’ に変換します。
     ‘<N>’ が負の数の場合、指定された端から必要な数のパスコンポーネント
     を削除して、 ‘-<N>’ パス部分を残します(たとえば、
     ‘%(refname:lstrip=-2)’ は ‘refs/tags/foo’ を ‘tags/foo’ に変換し、
     ‘%(refname:rstrip=-1)’ は ‘refs/tags/foo’ を ‘refs’ に変換します)。
     refに十分な数のパス部品がない場合、正の <N> でストリッピングすると
     結果は空の文字列になり、負の<N>でストリッピングすると完全な
     refnameになります。どちらもエラーではありません。

     ‘strip’ は ‘lstrip’ の同義語として使用できます。

objecttype
     オブジェクトのタイプ( ‘blob’ 、‘tree’ 、 ‘commit’ 、‘tag’ )。

objectsize
     オブジェクトのサイズ(‘git cat-file -s’ がレポートするものと同じです
     )。 ‘:disk’ を追加して、オブジェクトがディスク上で占めるサイズをバ
     イト単位で取得できます。以下の「CAVEATS」(注意事項)セクションのディ
     スク上のサイズに関する注記を参照してください。

objectname
     オブジェクト名(別名SHA-1)。オブジェクト名のあいまいでない省略形につ
     いては、 ‘:short’ を追加してください。目的の長さのオブジェクト名の
     省略形については、 ‘:short=<length>’ を追加します。ここで、最小の長
     さは MINIMUM_ABBREV です。一意のオブジェクト名を確保するために、指
     定の長さを超える場合があります。

deltabase
     デルタとして保存されている場合、これは指定されたオブジェクトのデル
     タベースのオブジェクト名に展開されます。それ以外の場合は、ヌルオブ
     ジェクト名(すべてゼロ)に展開されます。

upstream
     表示されたrefから「上流」(upstream)と見なすことができるローカル参照
     の名前。 上記の ‘refname’ と同じように、 ‘:short’ や ‘:lstrip’ や
     ‘:rstrip’ を尊重します。さらに、 ‘:track’ は ‘[ahead N, behind M]’
     を表示し、 ‘:trackshort’ は ‘>’ (ahead) または ‘<’ (behind) または
     "<>" (ahead and behind) または "=" (in sync) という簡潔なバージョン
     を表示します。 ‘:track’ は不明なアップストリーム参照が検出されるた
     びに ‘[gone]’ も出力します。 ‘:track,nobracket’ を追加すると角かっ
     こ(‘[’ と ‘]’ )無しで追跡情報を表示します（つまり、 ‘ahead N,
     behind M’ )。

     リモート追跡ブランチの ‘%(upstream)’ と ‘%(upstream:remotename)’ と
     ‘%(upstream:remoteref)`は、それぞれリモートの名前と追跡されたリモー
     トrefの名前を参照します。つまり、 refspec
     `%(upstream:remoteref):%(upstream)’ を使用して
     ‘%(upstream:remotename)’ からフェッチすることにより、リモートト追跡
     ブランチを明示的かつ個別に更新できます。

     refに追跡情報が関連付けられていない場合、効果はありません。
     ‘nobracket’ 以外のすべてのオプションは相互に排他的ですが、一緒に使
     用する場合は最後のオプションが選択されます。

push
     表示されたrefの ‘@{push}’ の場所を表すローカルrefの名前。
     ‘upstream’ と同様に ‘:short’ ・ ‘:lstrip’ ・ ‘:rstrip’ ・ ‘:track’
     ・ ‘:trackshort’ ・ ‘:remotename’ ・ ‘:remoteref’ オプションを尊重
     します。 ‘@{push}’ refが設定されていない場合、空の文字列を生成しま
     す。

HEAD
     HEADが現在のref (チェックアウトされたブランチ)と一致する場合は ‘*’
     、それ以外の場合は ’ ’ 。

color
     出力色を変更します。 その後に ‘:<colorname>’ が続きます。色の名前は
     、 git-config(1) の「CONFIGURATION FILE」セクションの「Values」で説
     明されています。 たとえば、 ‘%(color:bold red)’ です。

align
     コンテンツを %(align:…) から %(end) の間で左揃え、中央揃え、または
     右揃えにします。 ‘align:’ の後には、 ‘width=<width>’ と
     ‘position=<position>’ がコンマ(‘,’)で区切られた任意の順序で続きます
     。ここで、 ‘<position>’ は left または right または middle のいずれ
     かで、‘<position>’ の デフォルトは left で ‘<width>’ のデフォルトは
     配置されたコンテンツの全長です。 簡潔にするために、 ‘width=’ および
     /または ‘position=’ プレフィックスを省略して、代わりに裸の <width>
     および <position> を使用することができます。 たとえば、
     ‘%(align:<width>,<position>)’ です。 コンテンツの長さがwidthよりも
     大きい場合、位置合わせは実行されません。 ‘--quote’ とともに使用する
     と、 %(align:…) から %(end) の間のすべてがクォートされまれますが、
     ネストされている場合は、最上位レベルのみがクォートされます。

if
     %(if) … %(then) … %(end) または %(if) … %(then) … %(else) … %(end)
     として使用されます。 %(if) の後に値または文字列リテラルを持つアトム
     がある場合は、 %(then) の後のすべてが出力されます。そうでない場合、
     %(else) アトムが使用されている場合は、 %(else) の後のすべてが出力さ
     れます。 %(then) の前の文字列を評価するときはスペースを無視します。
     これは、 ‘*’ または ‘ ‘ のいずれかを出力する %(HEAD) アトムを使用し
     、 HEAD ref にのみ if 条件を適用する場合に役立ちます。
     ‘:equals=<string>’ または ‘:notequals=<string>’ を追加して、
     %(if:…) アトムと %(then) アトムの間の値を指定された文字列と比較しま
     す。(訳注:つまり、 %(if) から %(then) の間がconditionである)

symref
     与えられたシンボリックrefが参照するref。シンボリックrefでない場合、
     何も出力されません。上記の ‘refname’ と同じ方法で、 ‘:short’ と
     ‘:lstrip’ と ‘:rstrip’ オプションを尊重します。

worktreepath
     リンクされたワークツリー(linked worktree)でチェックアウトされている
     場合、refがチェックアウトされているワークツリーへの絶対パス。それ以
     外の場合は空文字列です。

   上記に加えて、commitとtagオブジェクトの場合、ヘッダーフィールド名
(‘tree’ と ‘parent’ と ‘object’ と ‘type’ と ‘tag’)を使用して、ヘッダー
フィールドの値を指定できます。 フィールド ‘tree’ と ‘parent’ は、
‘objectname’ と同じように、修飾子 ‘:short’ や ‘:short=<length>’ とともに
使用することもできます。

   commitオブジェクトとtagオブジェクトの場合、特別な ‘creatordate’ フィ
ールドと ‘creator’ フィールドは、オブジェクトタイプに応じて、
‘committer’ または ‘tagger’ フィールドの適切な日付または
name-email-dateタプルに対応します。これらは、注釈付きタグと軽量タグの組
み合わせでの作業を目的としています。

   name-email-dateタプルを値として持つフィールド(‘author’ と ‘committer’
と ‘tagger’)には、名前付きコンポーネントを抽出するために ‘name’ と
‘email’ と ‘date’ の接尾辞を付けることができます。メールフィールド
(‘authoremail’ と ‘committeremail’ と ‘taggeremail’)の場合、 ‘:trim’ を
追加すると山かっこ(‘<’, ‘>’)なしでメールを取得し、 ‘:localpart’ を追加す
ると電子メールアドレスをトリミングして ‘@’ 記号の前の部分を取得できます
。

   オブジェクトの生データは ‘raw’ です。

raw:size
     オブジェクトの生データサイズ。

   注意: ‘--format=%(raw)’ は、 ‘--python’ や ‘--shell’ や ‘--tcl’ と一
緒に使用できないことに注意してください。これらのプログラム言語は、文字列
変数タイプで任意のバイナリデータをサポートしていない可能性があるためです
。

   コミットまたはタグオブジェクト内のメッセージは ‘contents’ であり、そ
こから ‘contents:<part>’ を使用して以下によりさまざまな部分を抽出できま
す:

contents:size
     コミットメッセージまたはタグメッセージのバイト単位のサイズ。

contents:subject
     メッセージの最初の段落(通常は1行)は、コミットまたはタグメッセージの
     「件名」(subject)と見なされます。 ‘contents：subject’ の代わりに、
     フィールド ‘subject’ を使用して同じ結果を取得することもできます。
     ‘subject’ に追加できる ‘:sanitize’ は、件名行をファイル名に適した形
     にします。

contents:body
     コミットメッセージまたはタグメッセージの「件名」に続く残りの部分。

contents:signature
     タグのオプションのGPG署名。

contents:lines=N
     メッセージの最初の N行。

   加えて、 git-interpret-trailers(1) によって解釈されるトレーラーは、
‘trailers[:options]’ として(または履歴エイリアス
‘contents:trailers[:options]’ を使用して)取得されます。有効な [:option]
値については、 git-log(1) の ‘trailers’ セクションを参照してください。

   並べ替えの目的のため、数値のフィールドは数値順で並べ替えられます
(‘objectsize’ 、‘authordate’ 、 ‘committerdate’ 、‘creatordate’ 、
‘taggerdate’)。他のすべてのフィールドは、バイト値の順序で並べ替えられま
す。

   バージョンで並べ替えるオプションもあります。これは、フィールド名
‘version:refname’ またはそのエイリアス ‘v:refname’ を使用して行うことが
できます。

   いずれの場合も、refによって参照されるオブジェクトに適用できないフィー
ルドを参照するフィールド名はエラーを引き起こしません。代わりに空文字列を
返します。

   日付タイプフィールドの特殊なケースとして、 ‘:’ の後に日付フォーマット
名を追加して日付のフォーマットを指定できます(git-rev-list(1) の ‘--date’
オプションのが取る値を参照してください)。

   %(align) や %(if) などの一部のアトムには、常に対応する %(end) が必要
です。 %(align) や %(if) などの一部のアトムを「開始アトム」(opening
atoms)と呼び、 %($open) と表記することもあります。

   スクリプト言語固有のクォートが有効な場合、トップレベルの開始アトムと
それに対応する %(end) の間のすべてが、トップレベル開始アトムのセマンティ
クスに従って評価され、そのトップレベルからの結果のみがクォートされます。

EXAMPLES
********

フォーマットされたテキストを直接生成する例。 直近の3つのタグ付きコミット
を表示します:

     #!/bin/sh

     git for-each-ref --count=3 --sort='-*authordate' \
     --format='From: %(*authorname) %(*authoremail)
     Subject: %(*subject)
     Date: %(*authordate)
     Ref: %(*refname)

     %(*body)
     ' 'refs/tags'

   出力でのshell evalの使用を示す簡単な例で、‘--shell’ の使用を示してい
ます。 すべてのheadのプレフィックスを一覧表示します:

     #!/bin/sh

     git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
     while read entry
     do
             eval "$entry"
             echo `dirname $ref`
     done

   タグに関するもう少し手の込んだレポートで、スクリプト全体のフォーマッ
トである可能性があることを示しています:

     #!/bin/sh

     fmt='
             r=%(refname)
             t=%(*objecttype)
             T=${r#refs/tags/}

             o=%(*objectname)
             n=%(*authorname)
             e=%(*authoremail)
             s=%(*subject)
             d=%(*authordate)
             b=%(*body)

             kind=Tag
             if test "z$t" = z
             then
                     # could be a lightweight tag
                     t=%(objecttype)
                     kind="Lightweight tag"
                     o=%(objectname)
                     n=%(authorname)
                     e=%(authoremail)
                     s=%(subject)
                     d=%(authordate)
                     b=%(body)
             fi
             echo "$kind $T points at a $t object $o"
             if test "z$t" = zcommit
             then
                     echo "The commit was authored by $n $e
     at $d, and titled

         $s

     Its message reads as:
     "
                     echo "$b" | sed -e "s/^/    /"
                     echo
             fi
     '

     eval=`git for-each-ref --shell --format="$fmt" \
             --sort='*objecttype' \
             --sort=-taggerdate \
             refs/tags`
     eval "$eval"

   %(if) … %(then) … %(else) … %(end) の使用法を示す例。 これにより、現
在のブランチの前にアスタリスクが付けられます。

     git for-each-ref --format="%(if)%(HEAD)%(then)* %(else)  %(end)%(refname:short)" refs/heads/

   %(if) … %(then) … %(end) の使用法を示す例。 存在する場合、これは作者
名を出力します。

     git for-each-ref --format="%(refname)%(if)%(authorname)%(then) Authored by: %(authorname)%(end)"

CAVEATS
*******

注意: ディスク上のオブジェクトのサイズは正確に報告されますが、どのrefま
たはオブジェクトがディスクの使用に関与しているかについて結論を出す際には
注意が必要です。パックされた非デルタオブジェクトのサイズは、それに対して
デルタするオブジェクトのサイズよりもはるかに大きい場合がありますが、ベー
スとデルタのオブジェクトの選択は任意であり、再パック中に変更される可能性
があります。

   注意: オブジェクトの複数のコピーがオブジェクトデータベースに存在する
可能性があることにも注意してください。この場合、どのコピーのサイズまたは
デルタベースが報告されるかは未定義です。

NOTES
*****

複数の ‘--contains’ フィルターと ‘--no-contains’ フィルターを組み合わせ
る場合、少なくとも1つの ‘--contains’ コミットを含み、 ‘--no-contains’ コ
ミットを含まない参照のみが表示されます。

   複数の ‘--merged’ フィルターと ‘--no-merged’ フィルターを組み合わせる
と、少なくとも1つの ‘--merged’ コミットから到達可能で、 ‘--no-merged’ コ
ミットのいずれからも到達できない参照のみが表示されます。

SEE ALSO
********

git-show-ref(1)

GIT
***

Part of the git(1) suite

Name
****

git-for-each-repo — リポジトリのリストでGitコマンドを実行します

Synopsis
********

     git for-each-repo –config=<config> [–] <arguments>

DESCRIPTION
***********

リポジトリのリストでGitコマンドを実行します。既知のオプションや ‘--’ の
、後ろの引数は、Gitサブプロセスの引数として使用されます。

   ！！このコマンドは実験的なものです！！動作が変わる可能性があります！
！

   たとえば、以下を使用して、 ‘maintenance.repo’ 構成変数に格納されてい
るリポジトリのリストのそれぞれに対して maintenance を実行できます。

     git for-each-repo --config=maintenance.repo maintenance run

   これにより、複数値の構成変数である ‘maintenance.repo’ の各値である
‘<repo>’ ごとに ‘git -C <repo> maintenance run’ が実行されます。

OPTIONS
*******

‘--config=<config>’
     指定された構成変数を、絶対パス名を格納する複数値リストとして使用し
     ます。そのパスのリストを繰り返して(iterate)、指定された引数を実行し
     ます。

     これらの構成値は、利用可能な場合、システム、グローバル、およびロー
     カルのGit構成からロードされます。 ‘git for-each-repo’ がGitリポジト
     リではないディレクトリで実行される場合、システムとグローバル設定の
     みが使用されます。

SUBPROCESS BEHAVIOR
*******************

‘git -C <repo> <arguments>’ サブプロセスがゼロ以外の終了コードを返す場合
、 ‘git for-each-repo’ プロセスはそれ以上のサブプロセスを実行せずにその
終了コードを返します。

   各 ‘git -C <repo> <arguments>’ サブプロセスは、標準のファイルデスクリ
プタ ‘stdin’ と ‘stdout’ と ‘stderr’ を継承します。

GIT
***

Part of the git(1) suite

Name
****

git-format-patch — 電子メール送信用のパッチを準備します

Synopsis
********

     git format-patch [-k] [(-o|–output-directory) <dir> | –stdout]
                        [–no-thread | –thread[=<style>]]
                        [(–attach|–inline)[=<boundary>] | –no-attach]
                        [-s | –signoff]
                        [–signature=<signature> | –no-signature]
                        [–signature-file=<file>]
                        [-n | –numbered | -N | –no-numbered]
                        [–start-number <n>] [–numbered-files]
                        [–in-reply-to=<message id>] [–suffix=.<sfx>]
                        [–ignore-if-in-upstream]
                        [–cover-from-description=<mode>]
                        [–rfc] [–subject-prefix=<subject prefix>]
                        [(–reroll-count|-v) <n>]
                        [–to=<email>] [–cc=<email>]
                        [–[no-]cover-letter] [–quiet]
                        [–[no-]encode-email-headers]
                        [–no-notes | –notes[=<ref>]]
                        [–interdiff=<previous>]
                        [–range-diff=<previous> [–creation-factor=<percent>]]
                        [–filename-max-length=<n>]
                        [–progress]
                        [<common diff options>]
                        [ <since> | <revision range> ]

DESCRIPTION
***********

UNIXメールボックスに似た形式で、コミットごとに1つの「メッセージ」に「パ
ッチ」を含む各非マージコミットを準備します。このコマンドの出力は、電子メ
ールの送信や「git am」での使用に便利です。

   コマンドによって生成される「メッセージ」は、以下の3つの部分で構成され
ます:

   • 短いメタデータヘッダー。「file(1)」などのプログラムが、ファイルがこ
     のコマンドからの出力であることを認識できるように「From <commit>」と
     、固定の日付スタンプ「Mon Sep 17 00:00:00 2001」で始まり、 作者
     ID(author identity)や作者の日付(author date)や変更のタイトル(title
     of the change)(コミットログメッセージの最初の段落から取得)が記入さ
     れたフィールドがあります。

   • コミットログメッセージの2番目以降の段落。

   • コミットとその親の間の ‘diff -p --stat’ 出力(linkgit: git-diff[1] 参
     照)である「パッチ」。

   ログメッセージとパッチは、3本のダッシュ(‘---’)で区切られています。

   操作するコミットを指定する方法は2つあります。

  1. 単一のコミット<since>は、現在のブランチの先端につながるコミットで、
     <since>が出力される履歴にないことを指定します。

  2. 一般的な <revision range> 評価式 (gitrevisions(7) の「SPECIFYING
     REVISIONS」セクション参照)は、指定された範囲でのコミットを意味しま
     す。

   単一の <commit> の場合、最初のルールが優先されます。2番目のルールを適
用する、つまり、履歴の開始から <commit> までのすべてをフォーマットするに
は、 ‘--root’ オプションを使用します: ‘git format-patch --root <commit>’
とします。あなたが <commit> 自体のみをフォーマットしたい場合は、 ‘git
format-patch -1 <commit>’ を使用して行うことができます。

   デフォルトでは、各出力ファイルには1から順番に番号が付けられ、ファイル
名としてコミットメッセージの最初の行(パス名の安全のためにもみもみ
(massage)れます)が使用されます。 ‘--numbered-files’ オプションを使用する
と、出力ファイル名は数字のみになり、コミットの最初の行は追加されません。
‘–stdout‘オプションが指定されていない限り、出力ファイル名が標準出力に出
力されます。

   ‘-o’ を指定すると、出力ファイルは <dir> に作成されます。それ以外の場
合は、現在の作業ディレクトリに作成されます。デフォルトのパスは、
‘format.outputDirectory’ 構成オプションで設定できます。 ‘-o’ オプション
は ‘format.outputDirectory’ よりも優先されます。
‘format.outputDirectory’ が他の場所を指している場合でも、パッチを現在の
作業ディレクトリに保存したいときは、‘-o.’ を使用します。すべてのディレク
トリコンポーネントが作成されます。

   デフォルトでは、単一のパッチの件名は "[PATCH] " で、その後に、コミッ
トメッセージから最初の空白行までの行が連結されます (git-commit(1)の
DISCUSSION セクション参照)。

   複数のパッチが出力される場合、件名のプレフィックスは "[PATCH n/m] " に
なります。 1つのパッチに 1/1 を強制的に追加するには ‘-n’ を使用します。
件名からパッチ番号を省略するには ‘-N’ を使用します。

   ‘--thread’ を指定すると、 ‘git-format-patch’ は ‘In-Reply-To’ ヘッダ
ーと ‘References’ ヘッダーを生成し、2番目以降のパッチメールを最初のメー
ルへの返信として表示します。 これにより、参照する ‘Message-Id’ ヘッダー
も生成されます。

OPTIONS
*******

‘-p’
‘--no-stat’
     diffstatsなしでプレーンパッチを生成します。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     名前の変更(renames)を検知する。 ‘n’ が指定されている場合、それは類
     似性インデックスのしきい値です (つまり、ファイルのサイズと比較した
     追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以上が変更され
     ていない場合、 Gitが削除/追加のペアを名前変更と見なす必要があること
     を意味します。 ‘%’ 記号がない場合、数値は小数として読み取られ、その
     前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、‘-M50%’ と同
     じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検出を正確な
     名前変更に制限するには、 ‘-M100%’ を使用します。 デフォルトの類似性
     インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

‘-<n>’
     最上位から見て <n> 個目のコミットからパッチを準備します。

‘-o <dir>’
‘--output-directory <dir>’
     現在の作業ディレクトリの代わりに、 <dir> を使用して結果のファイルを
     保存します。

‘-n’
‘--numbered’
     単一のパッチでも、 ‘[PATCH n/m]’ 形式で名前を出力します。

‘-N’
‘--no-numbered’
     ‘[PATCH]’ 形式 で名前を出力します。

‘--start-number <n>’
     パッチの番号付けを1ではなく<n>から開始します。

‘--numbered-files’
     出力ファイル名群は、コミットのデフォルトの最初の行が追加されていな
     い単純な一連番号になります。

‘-k’
‘--keep-subject’
     コミットログメッセージの最初の行から ‘[PATCH]’ を削除/追加 しないで
     ください。

‘-s’
‘--signoff’
     あなた自身ののコミッターIDを使用して、コミットメッセージに
     ‘Signed-off-by’ トレーラーを追加します。詳細については、
     git-commit(1)の signoff オフオプションを参照してください。

‘--stdout’
     コミットごとにファイルを作成するのではなく、すべてのコミットを
     mbox形式で標準出力に出力します。

‘--attach[=<boundary>]’
     マルチパート/混合の添付(multipart/mixed attachment)を作成します。最
     初の部分はコミットメッセージで、2番目の部分はパッチ自体です。
     ‘Content-Disposition: attachment’ を使用します。

‘--no-attach’
     添付ファイルの作成を無効にして、構成設定を上書きします。

‘--inline[=<boundary>]’
     マルチパート/混合の添付(multipart/mixed attachment)を作成します。最
     初の部分はコミットメッセージで、2番目の部分はパッチ自体です。
     ‘Content-Disposition: inline’ を使用します。

‘--thread[=<style>]’
‘--no-thread’
     ‘In-Reply-To’ ヘッダーと ‘References’ ヘッダーの追加を制御して、2番
     目以降のメールを最初のメールへの返信として表示します。 また、参照す
     る ‘Message-Id’ ヘッダーの生成を制御します。

     オプションの <style> 引数は、 ‘shallow’ または ‘deep’ のいずれかで
     す。 「shallow」スレッドは、すべてのメールをシリーズの先頭に返信し
     ます。先頭は、送付状と ‘--in-reply-to’ と最初のパッチメールからこの
     順序で選択されます。「deep」スレッドは、すべてのメールを前のメール
     への返信にします。

     ‘format.thread’ 構成が設定されていない限り、デフォルトは
     ‘--no-thread’ です。 ‘--thread’ がスタイルなしで指定された場合、デ
     フォルトで ‘format.thread’ で指定されたスタイル、でなければ、 スタ
     イルは ‘shallow’ になります。

     ‘git send-email’ のデフォルトが、電子メール自体をスレッド化すること
     であることに注意してください。 ‘git format-patch’ でスレッド化を処
     理する場合は、 ‘git send-email’ でスレッド化が無効になっていること
     を確認する必要があります。

‘--in-reply-to=<message id>’
     最初のメール(または ‘--no-thread’ を含むすべてのメール)を、指定の
     <message id> への応答として表示します。これにより、スレッドが壊れて
     新しいパッチシリーズが提供されるのを防ぎます。

‘--ignore-if-in-upstream’
     ‘<until>..<since>’ のコミットに一致するパッチを含めないでください。
     これにより、<since>から到達可能で、<until>からは到達できないすべて
     のパッチが調べられ、生成されているパッチと比較されます。一致するパ
     ッチはすべて無視されます。

‘--cover-from-description=<mode>’
     ブランチの説明を使用して、送付状のどの部分に自動的に入力されるかを
     制御します。

     ‘<mode>’ が ‘message’ または ‘default’ の場合、送付状の件名にプレー
     スホルダーテキストが入力されます。送付状の本文には、ブランチの説明
     が入力されます。 これは、構成またはコマンドラインオプションが指定さ
     れていない場合のデフォルトモードです。

     ‘<mode>’ が ‘subject’ の場合、ブランチの説明の最初の段落を送付状の
     件名に入力します。ブランチの説明の残りの部分は、送付状の本文に入力
     されます。

     ‘<mode>’ が ‘auto’ の場合、 ブランチの説明の最初の段落 > 100バイト
     なら、モードは ‘message’ になり、そうでない場合は ‘subject’ が使用
     されます。

     ‘<mode>’ が ‘none’ の場合、送付状の件名と本文の両方にプレースホルダ
     ーテキストが入力されます。

‘--subject-prefix=<subject prefix>’
     件名の標準の _[PATCH]_ プレフィックスの代わりに、
     _[<subjectprefix>]_ を使用してください。これにより、パッチシリーズ
     の有用な命名が可能になり、 ‘--numbered’ オプションと組み合わせるこ
     とができます。

‘--filename-max-length=<n>’
     標準の64バイトの代わりに、生成された出力ファイル名を約 _<n>_ バイト
     に切り捨て(短すぎると、値が適切な長さに黙って引き上げられます)。 デ
     フォルトは ‘format.filenameMaxLength’ 構成変数の値、または構成され
     ていない場合は64です。

‘--rfc’
     ‘--subject-prefix="RFC PATCH"’ のエイリアス。 RFCは「Request For
     Comments」を意味します。アプリケーションではなく、議論のために実験
     的なパッチを送信するときにこれを使用します。

‘-v <n>’
‘--reroll-count=<n>’
     そのシリーズをトピックの <n> 番目の反復としてマークします。出力ファ
     イル名には ‘v<n>’ が付加され、件名接頭辞(デフォルトでは ‘PATCH’ で
     すが、 ‘--subject-prefix’ オプションで構成可能)には ‘v<n>’ が付加さ
     れます。例えば、 ‘--reroll-count=4’ は、 ‘Subject: [PATCH v4 1/20]
     Add makefile’ を含む ‘v4-0001-add-makefile.patch’ ファイルを生成し
     ます。‘<n>’ は整数である必要はありませんが（たとえば、
     ‘--reroll-count=4.4’ とか ‘--reroll-count= 4rev2’ とかでもOK)、この
     ようなreroll-countを使用することの欠点は、以前のバージョンとの
     range-diff/interdiff で、新しい相互作用(new interation)がどのバージ
     ョンと比較されるかを正確に表示できなくなります。

‘--to=<email>’
     メールヘッダーに ‘To:’ ヘッダーを追加します。 これは、任意の構成済
     みのヘッダー群に追加されるものであり、複数回使用される場合がありま
     す。 否定形式の ‘--no-to’ は、これまでに追加されたすべての ‘To:’ ヘ
     ッダーを(構成またはコマンドラインから)破棄します。

‘--cc=<email>’
     メールヘッダーに ‘Cc:’ ヘッダーを追加します。 これは、任意の構成済
     みのヘッダー群に追加されるものであり、複数回使用される場合がありま
     す。 否定形式の ‘--no-cc’ は、これまでに追加されたすべての ‘Cc:’ ヘ
     ッダーを(構成またはコマンドラインから)破棄します。

‘--from’
‘--from=<ident>’
     各コミットメールの ‘From:’ ヘッダーで <ident> を使用します。 コミッ
     トの作成者IDが、提供された <ident> とテキストで同一でない場合は、元
     の作成者とのメッセージの本文に ‘From:’ ヘッダーを配置します。
     <ident> が指定されていない場合は、コミッターIDを使用します。

     注意: このオプションは、実際にメールを送信していて、自分を送信者と
     して識別したいが、元の作成者を保持したい場合にのみ役立ちます(そして
     、 ‘git am’ は本文のヘッダーを正しく取得します)。 また、 ‘git
     send-email’ はすでにこの変換を処理するようになっているため、結果を
     ‘git send-email’ にフィードする場合は、このオプションを使用しないで
     ください。

‘--add-header=<header>’
     電子メールヘッダーに任意のヘッダーを追加します。これは、構成済みの
     ヘッダーに追加されるものであり、複数回使用される場合があります。 た
     とえば、 ‘--add-header="Organization: git-foo"’ です。 否定形式の
     ‘--no-add-header’ は、構成またはコマンドラインからこれまでに追加さ
     れた「すべての」(‘To:’ と ‘Cc:’ と カスタム)ヘッダーを破棄します。

‘--[no-]cover-letter’
     パッチに加えて、ブランチの説明、ショートログ、および全体的な
     diffstatを含むカバーレターファイルを生成します。あなたは、送信する
     前に、ファイルに説明を入力できます。

‘--encode-email-headers’
‘--no-encode-email-headers’
     ヘッダーをそのまま(verbatim)出力する代わりに、非ASCII文字を含む電子
     メールヘッダーを ‘Q-encoding’ (RFC 2047で説明)でエンコードします。
     デフォルトは、 ‘format.encodeEmailHeaders’ 構成変数の値です。

‘--interdiff=<previous>’
     レビュアーの補助として、カバーレターに、あるいは1パッチシリーズの単
     独パッチの解説として、パッチシリーズの前のバージョンと現在フォーマ
     ットされているシリーズとの違いを示す interdiff を挿入してください。
     ‘previous’ は、フォーマット中のシリーズと共通のベースを持つ、前のシ
     リーズの先端を示す単一のリビジョンです(例えば、 ‘git format-patch
     --cover-letter --interdiff=feature/v1 -3 feature/v2’ )。

‘--range-diff=<previous>’
     レビューの補助として、カバーレターに range-diff (git-range-diff(1)
     参照) を挿入するか、1パッチシリーズの単独パッチの解説として、そのパ
     ッチシリーズの前のバージョンと現在フォーマットされているシリーズと
     の相違を示します。 前バージョンは、フォーマットされるシリーズと共通
     のベースがある場合、前のシリーズの先端を示す単一のリビジョン(例えば
     ‘git format-patch --cover-letter --range-diff=feature/v1 -3
     feature/v2’ )、またはシリーズの二つのバージョンが分離している場合、
     リビジョンレンジ(例えば ‘git format-patch --cover-letter
     --range-diff=feature/v1~3..feature/v1 -3 feature/v2’ )が使用されま
     す。

     注意: コマンドに渡される diff オプションは、_format-patch_ の基本製
     造物の生成方法に影響し、カバーレターの実体を生成するために使用され
     る基礎となる ‘range-diff’ 機構には渡されないことに注意してください
     (これは将来変更される可能性があります)。

‘--creation-factor=<percent>’
     ‘--range-diff’ とともに使用すると、 作成/削除 のコストファッジ係数
     (cost fudge factor)を調整することにより、以前の一連のパッチと現在の
     一連のパッチの間でコミットを一致させるヒューリスティックを微調整し
     ます。 詳細については、 git-range-diff(1) を参照してください。

‘--notes[=<ref>]’
‘--no-notes’
     3つの破線(‘---’)行の後に、コミットのnotes (linkgit: git-notes[1] を
     参照)を追加します。

     この場合、コミットログメッセージに属さないコミットの説明を書いて、
     パッチを送信する際に添付することが期待されます。これらの説明は、単
     に ‘format-patch’ を実行した後で送信する前に書くこともできますが、
     Git notes として残しておくと、パッチシリーズのバージョン間でそれら
     を維持することができます(ただし、この作業フローを使用するには
     git-notes(1) の ‘notes.rewrite’ 設定オプションに関するdiscussionを
     参照してください)。

     ‘format.notes’ 構成が設定されていない限り、デフォルトは
     ‘--no-notes’ です。

‘--[no-]signature=<signature>’
     生成された各メッセージに署名を追加します。 RFC 3676に従い、署名は
     ‘– ‘ が付いた行で本文から区切られています。署名オプションを省略した
     場合、署名はデフォルトでGitバージョン番号になります。

‘--signature-file=<file>’
     署名がファイルから読み取られることを除いて、 ‘--signature’ と同じよ
     うに機能します。

‘--suffix=.<sfx>’
     生成されたファイル名のサフィックスとして ‘.patch’ を使用する代わり
     に、指定されたサフィックスを使用します。 一般的な代替手段は
     ‘--suffix=.txt’ です。 これを空のままにすると、 ‘.patch’ サフィック
     スが削除されます。

     注意: 先行する文字はドット(‘.’)である必要はないことに注意してくださ
     い。 たとえば、 ‘--suffix=-patch’ を使用して
     ‘0001-description-of-my-change-patch’ とかすることができます。

‘-q’
‘--quiet’
     生成されたファイルの名前を標準出力に出力しないでください。

‘--no-binary’
     バイナリファイルの変更内容を出力せず、代わりにそれらのファイルが変
     更されたという通知を表示します。このオプションを使用して生成された
     パッチは適切に適用できませんが、コードレビューには役立ちます。

‘--zero-commit’
     コミットのハッシュの代わりに、各パッチのFromヘッダーにすべてゼロの
     ハッシュを出力します。

‘--[no-]base[=<commit>]’
     ベースツリー情報を記録して、パッチシリーズが適用される状態を特定し
     ます。 詳細については、下記「BASE TREE INFORMATION」セクションを参
     照してください。 <commit> が ‘auto’ の場合、ベースコミットが自動的
     に選択されます。 ‘--no-base’ オプションは、 ‘format.useAutoBase’ 構
     成をオーバーライドします。

‘--root’
     単一のコミットであっても、リビジョン引数を <revision range> として
     扱います(通常は <since> として扱われます)。 指定された範囲に含まれ
     るルートコミットは、このフラグとは関係なく、常に作成パッチとしてフ
     ォーマットされることに注意してください。

‘--progress’
     パッチが生成されるときに、stderrへ進捗レポートを表示します。

CONFIGURATION
*************

あなたは、各メッセージに追加するメールヘッダー行の指定、件名のプレフィッ
クスとファイルのサフィックスのデフォルト、複数のパッチを出力する場合のパ
ッチ番号の指定、 ‘To:’ または ‘Cc:’ ヘッダーの追加、添付ファイルの設定、
パッチ出力ディレクトリの変更、設定変数によるパッチのサインオフ、が可能で
す。

     [format]
             headers = "Organization: git-foo\n"
             subjectPrefix = CHANGE
             suffix = .txt
             numbered = auto
             to = <email>
             cc = <email>
             attach [ = mime-boundary-string ]
             signOff = true
             outputDirectory = <directory>
             coverLetter = auto
             coverFromDescription = auto

DISCUSSION
**********

_git format-patch_ によって生成されたパッチはUNIXメールボックス形式であ
り、ファイルが実際のメールボックスではなくformat-patchから出力されること
を示す固定の「魔法の」タイムスタンプ(fixed "magic" time stamp)が付いてい
ます。

     From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
     From: Tony Luck <tony.luck@intel.com>
     Date: Tue, 13 Jul 2010 11:42:54 -0700
     Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
      =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
     MIME-Version: 1.0
     Content-Type: text/plain; charset=UTF-8
     Content-Transfer-Encoding: 8bit

     arch/arm config files were slimmed down using a python script
     (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)

     Do the same for ia64 so we can have sleek & trim looking
     ...

   通常、MUAの下書きフォルダに配置され、タイムリーなコメントを追加するよ
うに編集されます。このコメントは、3つのダッシュ(‘---’)の後に変更ログに記
録されないように編集され、メッセージとして送信されます。この例では、本文
は ‘arch/arm config files were...’ です。受信側では、読者は興味あるパッ
チをUNIXメールボックスに保存し、 git-am(1) を使用してそれらを適用できま
す。

   パッチが進行中の議論の一部である場合、 ‘git format-patch’ によって生
成されたパッチは、‘git am --scissors’ 機能を利用するように調整できます。
議論への応答の後に、‘-- >8 --’ （訳注: ‘>8’ は、ハサミを横にしたアスキー
アート(?))のみで構成される行があり、その後に不要なヘッダーフィールドが削
除されたパッチが続きます:

     ...
     > So we should do such-and-such.

     Makes sense to me.  How about this patch?

     -- >8 --
     Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet

     arch/arm config files were slimmed down using a python script
     ...

   この方法でパッチを送信する場合、ほとんどの場合、独自のパッチを送信す
るため、 ‘From $SHA1 $magic_timestamp’ マーカーに加えて、パッチファイル
から ‘From:’ と ‘Date:’ 行を省略する必要があります。パッチのタイトルは、
パッチが、応答するディスカッションの主題とは異なる可能性が高いため、上記
の例のように、 ‘Subject:’ 行を保持する必要がある可能性があります。

パッチの破損のチェック
======================

多くのメーラーは、適切に設定されていないと空白(whitespace)を破損します。
破損の一般的な2つのタイプは以下のとおりです:

   • どの空白(whitespace)もない空のコンテキスト行。

   • 先頭に1つの余分な空白(whitespace)がある空でないコンテキスト行。

   あなたのMUAが正しく設定されているかどうかをテストする方法のひとつは以
下のとおりです:

   • リストとメンテナのアドレスを含まない To: 行 と Cc: 行 を除き、全く
     同じ方法で、パッチを自分自身に送信します。

   • そのパッチをUNIXメールボックス形式のファイルに保存します。それを
     a.patch と呼ぶことにしましょう。

   • それをapplyします:

          $ git fetch <project> master:test-apply
          $ git switch test-apply
          $ git restore --source=HEAD --staged --worktree :/
          $ git am a.patch

   これが正しく適用されない場合、さまざまな理由が考えられます。

   • パッチ自体はきれいに適用されません。それは悪いことですが、しかしあ
     なたのMUAとはあまり関係がありません。この場合、パッチを再生成する前
     に、 git-rebase(1) を使用してパッチをリベースすることをお勧めします
     。

   • MUAがあなたのパッチ破損させました。 ‘am’ は、パッチが適用されないと
     文句を言います。 .git/rebase-apply/ サブディレクトリを調べて、
     ‘patch’ ファイルに含まれているものを確認し、上記の一般的な破損パタ
     ーンを確認します。

   • そのとき、 ‘info’ ファイルと ‘final-commit’ ファイルも確認してくだ
     さい。 ‘final-commit’ にあるものが、コミットログメッセージに表示し
     たいものと正確に一致しない場合、パッチを適用するときに受信者がログ
     メッセージを手作業で編集してしまう可能性が非常に高くなります。 パッ
     チの電子メールの "Hi, this is my first patch.\n" のようなものは、コ
     ミットメッセージの終わりを示す3本の破線(‘---’)の後に来るはずです。

MUA-SPECIFIC HINTS
******************

さまざまなメーラーを使用してパッチをインラインで正常に送信する方法に関す
るヒントをいくつか。

GMail
=====

Gmailには、Webインターフェイスでの行の折り返しをオフにする方法がないため
、送信するすべての電子メールが破損します。 ただし、 ‘git send-email’ を
使用して、GMail SMTPサーバーを介してパッチを送信するか、任意のIMAPメール
クライアントを使用してgoogle IMAPサーバーに接続し、それを介してメールを
転送することができます。

   ‘git send-email’ を使用して GMail SMTP サーバーを介してパッチを送信す
るためのヒントについては、 git-send-email(1) のEXAMPLEセクションを参照し
てください。

   IMAPインターフェースを使用した送信のヒントについては、
git-imap-send(1) の EXAMPLE セクションを参照してください。

Thunderbird
===========

デフォルトでは、Thunderbirdはメールの行を折り返す(wrap)だけでなく、
‘format=flowed’ としてフラグを立てます。このため、結果のメールはGitで使
用できなくなります。

   3つの異なるアプローチがあります: アドオンを使用して行の折り返し(line
wraps)をオフにする、またはパッチを切り刻まないようにThunderbirdを構成す
る、または外部エディターを使用してThunderbirdがパッチを切り刻まないよう
にします。

Approach #1 (add-on)
--------------------

https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/
(https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/) から
Toggle Word Wrap アドオンをインストールします。これは、コンポーザーの「
オプション」メニューに「Enable Word Wrap」というメニュー項目を追加し、チ
ェックを入れることができるようにします。これで、他の方法と同じようにメッ
セージを作成することができますが(カット＆ペースト、 ‘git format-patch |
git imap-send’ など)、入力したテキストには手動で改行を挿入する必要があり
ます。

Approach #2 (configuration)
---------------------------

3ステップ:

  1. メールサーバーの構成をプレーンテキストとして構成します。
     [Edit…Account Settings…Composition & Addressing] で、 [Compose
     Messages in HTML] のチェックを外します(訳注:手元のThunderBird
     91.7.0(64ビット)では、メールごとの[アカウント設定…編集とアドレス入
     力…編集][HTML形式でメッセージを編集する©])

  2. 行の折返しをしないように、あなたの一般作文ウィンドウ(general
     composition window)を設定します。

     Thunderbird 2: [Edit..Preferences..Composition] で、 [wrap plain
     text messages] を 0 にセットする。

     Thunderbird 3 : [Edit..Preferences..Advanced..ConfigEditor] で
     "mail.wrap_long_lines" を検索します。 それをトグルして ‘false’ に設
     定されていることを確認します。 また、 ‘mailnews.wraplength’ を検索
     し、値を0に設定します(訳注: ThunderBird 91.7.0(64ビット) 全体の設定
     …一般…の一番下にある[設定エディター…©]ボタン押下して「高度な設定」
     タブを開く。後は上記と一緒です)

  3. format=flowed の使用を無効にします:
     [Edit..Preferences..Advanced..Config Editor](訳注:上記[設定エディタ
     ー…©]参照) "mailnews.send_plaintext_flowed" を検索します。トグルし
     て ‘false’ に設定されていることを確認します。

   これで今後は、あなたは他の方法(カット＆ペーストや ‘git format-patch |
git imap-send’ など)で電子メールを作成できるようになり、パッチが破損する
ことはありません。

Approach #3 (external editor)
-----------------------------

Thunderbird拡張機能が必要です： AboutConfig (
http://aboutconfig.mozdev.org/ (http://aboutconfig.mozdev.org/) ) と
External Editor (http://globs.org/articles.php?lng=en&pg=8
(http://globs.org/articles.php?lng=en&pg=8)) です。

  1. あなたが選択した方法を使用して、パッチをテキストファイルとして準備
     します。

  2. 作文ウィンドウ(compose window)を開く前に、 [Edit…Account] を使用し
     て、パッチの送信に使用するアカウントの[Composition & Addressing]パ
     ネルの[Compose messages in HTML format]設定のチェックを外します(訳
     注:手元のThunderBird 91.7.0(64ビット)では、メールごとの[アカウント
     設定…編集とアドレス入力…編集][HTML形式でメッセージを編集する©])。

  3. Thunderbirdのメインウィンドウで、パッチの作成ウィンドウを開く前に、
     [Tools]→ [about:config] を使用して、以下を指定された値に設定します
     (訳注: ThunderBird 91.7.0(64ビット) 設定…一般…の一番下にある[設定エ
     ディター…©]ボタン押下して「高度な設定」タブを開く):

                  mailnews.send_plaintext_flowed  => false
                  mailnews.wraplength             => 0

  4. 作文ウィンドウを開き、外部エディターアイコンをクリックします。

  5. 外部エディタウィンドウで、パッチファイルを読み込み、通常どおりエデ
     ィタを終了します。

   補足: aboutconfig と以下の設定を使用して 手順2 を実行できる場合があり
ますが、まだ誰も試していません。

             mail.html_compose                       => false
             mail.identity.default.compose_html      => false
             mail.identity.id?.compose_html          => false

   contrib/thunderbird-patch-inline には、あなたがThunderbirdにパッチを
簡単にインクルードするのに役立つスクリプトがあります。これを使用するには
、上記の手順を実行してから、スクリプトを外部エディターとして使用します。

KMail
=====

これは、KMailを使用してパッチをインラインで送信するのに役立ちます。

  1. パッチをテキストファイルとして準備します。

  2. 「New Mail」をクリックします。

  3. Composer ウィンドウの [Options] の下に移動し、[Word wrap] が設定さ
     れていないことを確認します。

  4. Use Message → Insert file して、パッチを挿入します。

  5. 作文ウィンドウに戻ります。メッセージに他のテキストを追加し、アドレ
     ス指定フィールドと件名フィールドに入力して、送信を押します。

BASE TREE INFORMATION
*********************

ベースツリー情報ブロックは、メンテナやサードパーティテスタが、パッチシリ
ーズが適用される正確な状態を知るために使用されます。ベースツリー情報ブロ
ックは、「ベースコミット」（プロジェクトの安定した歴史の一部であり、他の
すべての人がそれを元に作業する）と、ゼロ個以上の「前提条件パッチ」(ベー
スコミットにまだ含まれない、よく知られたパッチで、パッチを適用する前にベ
ースコミットにトポロジカルに追加する必要があります)で構成されています。

   「ベースコミット」は、 ‘base-commit: ` の後にコミットオブジェクト名の
40進数が続くものとして表示されます。 `prerequisite patch’ は
‘prerequisite-patch-id: ` の後に40-hexの `patch id’ として表示されます。
これは、パッチを ‘git patch-id --stable’ コマンドに渡すことで取得できま
す。

   パブリックコミットPに加えて、他の誰かからのよく知られたパッチ X、Y、Z
を適用し、3つのパッチシリーズ A、B、C を作成したと想像してください。その
履歴は以下のようになります:

     ---P---X---Y---Z---A---B---C

   ‘git format-patch --base=P -3 C’ (またはその変形、たとえば
‘--cover-letter’ または ‘-3C’ の代わりに ‘Z..C’ を使用して範囲を指定する
)、 ベースツリー情報ブロックは、コマンドが出力する最初のメッセージ(最初
のパッチまたはカバーレターのいずれか)の最後に、以下のように表示されます:

     base-commit: P
     prerequisite-patch-id: X
     prerequisite-patch-id: Y
     prerequisite-patch-id: Z

   以下のようなのような非線形トポロジーの場合

     ---P---X---A---M---C
         \         /
          Y---Z---B

   ‘git format-patch --base=P -3 C’ を使用して A、B、C のパッチを生成す
ることもできます。そして P、X、Y、Z の識別子が最初のメッセージの最後に追
加されます。

   cmdlineで ‘--base=auto’ を設定すると、ベースコミットが自動的に追跡さ
れ、ベースコミットは、cmdlineで指定されたリモート追跡ブランチとリビジョ
ン範囲の先端コミットのマージベースになります。 ローカルブランチの場合、
このオプションを使用する前に、 ‘gitbranch --set-upstream-to’ でリモート
ブランチを追跡する必要があります。

EXAMPLES
********

   • リビジョンR1とR2の間のコミットを抽出します。そして、 それらをチェリ
     ーピックするために ‘git am’ を使用して現在のブランチの先頭にそれら
     を適用します:

          $ git format-patch -k --stdout R1..R2 | git am -3 -k

   • 現在のブランチにはあるが、元のブランチにはないすべてのコミットを抽
     出します:

          $ git format-patch origin

     コミットごとに、現在のディレクトリに個別のファイルが作成されます。

   • プロジェクトの開始以降で ‘origin’ につながるすべてのコミットを抽出
     します。

          $ git format-patch --root origin

   • 以下は上記と同一です:

          $ git format-patch -M -B origin

     さらに、名前変更を検出して処理し、名前変更パッチを生成するためにイ
     ンテリジェントに書き換えを完了します。 名前の変更パッチは、テキスト
     出力の量を減らし、一般的にレビューを容易にします。 Git以外の「パッ
     チ」プログラムはパッチの名前変更を理解しないため、受信者がGitを使用
     してパッチを適用していることがわかっている場合にのみ使用してくださ
     い。

   • 現在のブランチの先頭から3つのコミットを抽出し、それらを電子メールで
     送信可能なパッチとしてフォーマットします:

          $ git format-patch -3

CAVEATS
*******

注意: ‘format-patch‘は、要求された範囲の一部であっても、出力からマージコ
ミットを省略します。単純な「パッチ」には、受信側が同じマージコミットを再
現するための十分な情報が含まれていません。

SEE ALSO
********

git-am(1), git-send-email(1)

GIT
***

Part of the git(1) suite

Name
****

git-fsck-objects — データベース内のオブジェクトの接続性(connectivity)と
有効性(validity)を検証(verify)します

Synopsis
********

     git fsck-objects …

DESCRIPTION
***********

これは git-fsck(1) の同義語です。 git-fsck(1) の文書を参照してください。

GIT
***

Part of the git(1) suite

Name
****

git-fsck — データベース内のオブジェクトの接続性(connectivity)と有効性
(validity)を検証します

Synopsis
********

     git fsck [–tags] [–root] [–unreachable] [–cache] [–no-reflogs]
              [–[no-]full] [–strict] [–verbose] [–lost-found]
              [–[no-]dangling] [–[no-]progress] [–connectivity-only]
              [–[no-]name-objects] [<object>*]

DESCRIPTION
***********

データベース内のオブジェクトの接続性(connectivity)と有効性(validity)を検
証します

OPTIONS
*******

<object>
     到達不能追跡のheadとして扱うオブジェクト。

     オブジェクトが指定されていない場合、 _git fsck_ はデフォルトでイン
     デックスファイルと、 ‘refs’ 名前空間内のすべてのSHA-1参照と、
     (‘--no-reflogs’ が与えられて無い場合)すべてのreflogsを、headとして
     使用します。

‘--unreachable’
     存在するが、どの参照ノードからも到達できないオブジェクトを印刷しま
     す。

‘--[no-]dangling’
     存在するが「直接」使用されることのないオブジェクトを印刷します(デフ
     ォルト)。 ‘--no-dangling’ を使用して、この情報を出力から省略するこ
     とができます。

‘--root’
     ルートノードを報告します。

‘--tags’
     タグを報告します。

‘--cache’
     インデックスに記録されているオブジェクトを、到達不能追跡のheadノー
     ドとしても考慮します。

‘--no-reflogs’
     reflogのエントリによってのみ参照されるコミットが到達可能であるとは
     見なさないようにします。このオプションは、以前はrefに含まれていたが
     、現在は含まれていないが、対応するreflogに残っているコミットを検索
     することのみを目的としています。

‘--full’
     GIT_OBJECT_DIRECTORY（$GIT_DIR/objects) 内のオブジェクトだけでなく
     、GIT_ALTERNATE_OBJECT_DIRECTORIES または
     $GIT_DIR/objects/info/alternates にリストされている代替オブジェクト
     プール、および $GIT_DIR/objects/pack にあるパックされたGitアーカイ
     ブにあるオブジェクトもチェックします。サブディレクトリを代替オブジ
     ェクトプールにパックします。いまやこれがデフォルトになりました。
     ‘--no-full’ でオフにできます。

‘--connectivity-only’
     到達可能なオブジェクトの接続のみをチェックし、到達可能なタグ、コミ
     ット、またはツリーによって参照されるオブジェクトが存在することを確
     認します。これにより、ブロブの読み取りを完全に回避することで操作が
     高速化されます(ただし、参照されたブロブが存在するかどうかは引き続き
     チェックされます)。 これにより、コミットとツリーの破損が検出されま
     すが、セマンティックチェック(フォーマットエラーなど)は行われません
     。ブロブオブジェクトの破損はまったく検出されません。

     到達不能なタグ、コミット、およびツリーにもアクセスして、履歴のぶら
     下がっているセグメントのヒントを見つけることができます。この出力を
     気にせず、さらに高速化したい場合は、 ‘--no-dangling’ を使用してくだ
     さい。

‘--strict’
     より厳密なチェックを有効にします。つまり、古いバージョンのGitによっ
     て作成された g+w ビットセットで記録されたファイルモードをキャッチし
     ます。Linuxカーネル、Git自体、スパースリポジトリなどの既存のリポジ
     トリには、このチェックをトリガーする古いオブジェクトがありますが、
     このフラグを使用して新しいプロジェクトをチェックすることをお勧めし
     ます。

‘--verbose’
     おしゃべりになります。

‘--lost-found’
     タイプに応じて、ぶら下がっているオブジェクトを
     .git/lost-found/commit/ または .git/lost-found/other/ に書き込みま
     す。オブジェクトがブロブの場合、コンテンツはそのオブジェクト名では
     なくファイルに書き込まれます。

‘--name-objects’
     到達可能なオブジェクトの名前を表示する場合、SHA-1に加えて、それらが
     どのように到達可能であるかを説明する名前も表示します。
     git-rev-parse(1) と互換性があります。 例えば
     ‘HEAD@{1234567890}~25^2:src/’

‘--[no-]progress’
     ‘--no-progress’ または ‘--verbose’ が指定されていない限り、進行状況
     ステータスは、端末に接続されている場合、デフォルトで標準エラースト
     リームに報告されます。 ‘--progress’ は、標準エラーストリームが端末
     に送信されていない場合でも、進行状況出力を強制します。

CONFIGURATION
*************

fsck.<msg-id>
     fsck中に、gitは、現在のバージョンのgitでは生成されず、
     ‘transfer.fsckObjects’ が設定されている場合はネットワーク経由で送信
     されない、レガシーデータの問題を検出する場合があります。この機能は
     、そのようなデータを含むレガシーリポジトリの操作をサポートすること
     を目的としています。

     ‘fsck.<msg-id>’ 設定は、 git-fsck(1) によって取得されますが、代わり
     に、そのようなデータセット ‘receive.fsck.<msg-id>’ のプッシュを受け
     入れるか、または、クローンまたはフェッチのセットである
     ‘fetch.fsck.<msg-id>’ を使用します。

     この文書の残りの部分では、簡潔にするために ‘fsck.*’ 変数について説
     明していますが、対応する ‘receive.fsck.*’ 変数と ‘fetch.<msg-id>.*’
     変数にも同じことが当てはまります。

     ‘color.ui’ や ‘core.editor’ のような変数とは異なり、
     ‘receive.fsck.<msg-id>’ と ‘fetch.fsck.<msg-id>’ 変数は、設定されて
     いない場合、 ‘fsck.<msg-id>’ 構成にフォールバックしません。さまざま
     な状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設定す
     る必要があります。

     ‘fsck.<msg-id>’ が設定されている場合、 ‘fsck.<msg-id>’ の値を
     ‘error’ 、 ‘warn’ 、‘ignore’ のいずれか一つとすることにより、エラー
     を警告に切り替える事もでき、その逆も可能です。そして ‘<msg-id>’ の
     部分はメッセージIDです。便利なように、fsckはエラー/警告メッセージの
     前にメッセージIDを付けます。たとえば「missingEmail: invalid
     author/committer line - missing email」は、 ‘fsck.missingEmail =
     ignore’ を設定するとその問題が非表示になることを意味します。

     一般に、これらの問題のあるオブジェクトが共有する破損の種類をリスト
     して無視するのではなく、 ‘fsck.skipList’ に問題のある既存のオブジェ
     クトを列挙することをお勧めします。前者を実行すると、同じ破損の新し
     いインスタンスが見過ごされる可能性があります。

     不明な ‘fsck.<msg-id>’ 値を設定すると、fsckが停止(die)しますが、
     ‘receive.fsck.<msg-id>’ や ‘fetch.fsck.<msg-id>’ に対して同じことを
     行うと、gitは単に警告するだけです。

fsck.skipList
     非致命的な理由により既に壊れている(broken)ことが分かっているため無
     視する必要があるオブジェクト名(1行につき1つの省略されてないSHA-1)の
     リストへのパス。Git 2.20 以降では、コメント(‘#’)文字から行末までと
     、空行と、先頭と末尾の空白(whitespace)は無視されます。それより古い
     バージョンでは1行につき1つのSHA-1以外は全てエラーになります。

     この機能は、無効なコミッターの電子メールアドレスなど、初期のコミッ
     トにもかかわらず、安全に無視できるエラーを含む、確立されたプロジェ
     クトを受け入れる必要がある場合に役立ちます。 注意: この設定では、
     corruptオブジェクトをスキップすることはできません。

     ‘fsck.<msg-id>’ と同様に、この変数に対応する
     ‘receive.fsck.skipList’ 派生と ‘fetch.fsck.skipList’ 派生があります
     。

     ‘color.ui’ や ‘core.editor’ のような変数とは異なり、
     ‘receive.fsck.skipList’ 変数と ‘fetch.fsck.skipList’ 変数は、設定さ
     れていない場合、 ‘fsck.skipList’ 構成にフォールバックしません。さま
     ざまな状況で同じfsck設定を均一に構成するには、3つすべてを同じ値に設
     定する必要があります。

     古いバージョンのGit(2.20より前)では、オブジェクト名リストを並べ替え
     る必要があることが文書化されています。これは必須ではなく、オブジェ
     クト名は任意の順序で表示できますが、リストを読み取るときに、内部バ
     イナリ検索実装の目的でリストが並べ替えられているかどうかを追跡しま
     した。これにより、既に並べ替えられたリストでは作業を節約できます。
     膨大なリストがない限り、リストを事前に並べ替える必要はありませんで
     した。 Gitバージョン2.20以降では、代わりにハッシュ実装が使用される
     ため、リストを事前に並べ替える必要はありません。

DISCUSSION
**********

git-fsckは、SHA-1と一般的なオブジェクトの健全性をテストし、結果として得
られる到達可能性とその他すべてを完全に追跡します。検出した破損(オブジェ
クトの欠落または不良)を出力し、 ‘--unreachable’ フラグを使用すると、存在
するが指定されたheadノード(または上記デフォルト達)のいずれからも到達でき
ないオブジェクトも出力します。

   つまり、それは、あなたのバックアップや、他のアーカイブで見つけなけれ
ばならない破損したオブジェクトです(つまり、あなたは、それらを削除して、
他の誰かが破損したオブジェクトを持っていることを期待して、他のサイトと「
rsync」を実行できます)。

   core.commitGraph が true の場合、 commit-graph ファイルも「git
commit-graph verify」を使用して検査されます。 git-commit-graph(1) を参照
してください。

Extracted Diagnostics
*********************

unreachable <type> <object>
     <type> というタイプである <object> というオブジェクトは、表示される
     ツリーまたはコミットのいずれにおいても、実際には直接または間接的に
     参照されていません。これは、指定していない別のルートノードがあるか
     、ツリーが破損していることを意味している可能性があります。ルートノ
     ードを見逃していない場合は、到達不能なノードは使用できないため、削
     除することをお勧めします。

missing <type> <object>
     この <type> というタイプの <object> というオブジェクトは参照されて
     いますが、データベースに存在しません。

dangling <type> <object>
     この <type> タイプの <object> というオブジェクトはデータベースに存
     在しますが、「直接」使用されることはありません。 ぶら下がっているコ
     ミットはルートノードである可能性があります。

hash mismatch <object>
     データベースに、ハッシュがオブジェクトデータベースの値と一致しない
     オブジェクトがあります。これは、深刻なデータ整合性の問題を示してい
     ます。

Environment Variables
*********************

GIT_OBJECT_DIRECTORY
     オブジェクトデータベースのルート(通常は $GIT_DIR/objects )を指定す
     るために使用されます

GIT_INDEX_FILE
     インデックスのインデックスファイルを指定するために使用されます

GIT_ALTERNATE_OBJECT_DIRECTORIES
     追加のオブジェクトデータベースルートを指定するために使用されます(通
     常は未設定)

GIT
***

Part of the git(1) suite

Name
****

git-gc — 不要なファイルをクリーンアップし、ローカルリポジトリを最適化す
る

Synopsis
********

     git gc [–aggressive] [–auto] [–quiet] [–prune=<date> | –no-prune] [–force] [–keep-largest-pack]

DESCRIPTION
***********

ファイルリビジョンの圧縮(ディスクスペースの削減とパフォーマンスの向上)ま
たは、「git add」の以前の呼び出しから作成された可能性のある到達不能オブ
ジェクトの削除または、refのパッキングまたは、reflogの剪定(prune)または、
メタデータまたは古い作業ツリーのrerere、など、現在のリポジトリ内で多数の
ハウスキーピングタスクを実行します。 commit-graphなどの補助インデックス
も更新される場合があります。

   オブジェクトを作成する一般的な磁器コマンド操作を実行すると、最後のメ
ンテナンス以降にリポジトリが大幅に拡張されているかどうかが確認され、拡張
されている場合は、 ‘git gc’ が自動的に実行されます。この動作を無効にする
方法については、以下の ‘gc.auto’ を参照してください。

   ‘git gc’ を手動で実行する必要があるのは、そのような磁器コマンドを定期
的に実行せずにオブジェクトをリポジトリに追加する場合、1回限りのリポジト
リ最適化を行う場合などです。最適ではない大量インポートをクリーンアップし
ます。インポートの場合の詳細については、 git-fast-import(1)の「PACKFILE
OPTIMIZATION」セクションを参照してください。

OPTIONS
*******

‘--aggressive’
     通常、「git gc」は非常に高速に実行され、ディスクスペースの使用率と
     パフォーマンスは良好です。このオプションを使用すると、「git gc」は
     リポジトリをより積極的に最適化できますが、時間がかかります。この最
     適化の効果は割と持続性があります。詳細については、以下の「
     AGGRESSIVE」セクションを参照してください。

‘--auto’
     このオプションを使用すると、「git gc」はハウスキーピングが必要かど
     うかを確認します。 そうでない場合は、作業を実行せずに終了します。

     このヒューリスティックな作業がどのように機能するかについては、以下
     の「CONFIGURATION」セクションの「gc.auto」オプションを参照してくだ
     さい。

     ‘gc.auto’ や ‘gc.autoPackLimit’ などの構成オプションの制限を超えて
     ハウスキーピングがトリガーされると、他のすべてのハウスキーピングタ
     スク（rerere、working tree、reflogなど）も実行されます。

‘--prune=<date>’
     指定の日付より古いルーズオブジェクトを削除します(デフォルトは2週間
     前で、構成変数 ‘gc.pruneExpire’ で上書きできます)。 ‘--prune=now’ は
     、日付に関係なく緩いオブジェクトを削除し、別のプロセスが同時にリポ
     ジトリに書き込んでいる場合に破損のリスクが高まります。以下の「
     NOTES」を参照してください。 ‘--prune’ はデフォルトでオンになってい
     ます。

‘--no-prune’
     任意のルーズオブジェクトを剪定しません。

‘--quiet’
     すべての進捗レポートを抑制します。

‘--force’
     このリポジトリで別の ‘git gc’ インスタンスが実行されている場合でも
     、 ‘git gc’ を強制的に実行します。

‘--keep-largest-pack’
     最大のパックと ‘.keep’ ファイルでマークされたパックを除くすべてのパ
     ックが1つのパックに統合されます。このオプションを使用すると、
     ‘gc.bigPackThreshold’ は無視されます。

AGGRESSIVE
**********

‘--aggressive’ オプションが指定されている場合、 git-repack(1) は ‘-f’ フ
ラグを指定して呼び出され、次に ‘--no-reuse-delta’ が git-pack-objects(1)
に渡されます。これにより、既存のデルタが破棄されて再計算され、再パッキン
グに多くの時間を費します。

   この効果は割と長続きします。例えばパックとルーズオブジェクトが互いに
合体すると、そのパック内の既存のデルタが再利用される可能性がありますが、
代わりに新しいパックから次善のデルタを選択する場合もあります。

   さらに、 ‘--aggressive’ を指定すると、 git-repack(1) に渡される
‘--depth’ と ‘--window’ オプションが微調整されます。以下の
‘gc.aggressiveDepth’ と ‘gc.aggressiveWindow’ 設定を参照してください。よ
り大きなウィンドウサイズを使用することで、より最適なデルタを見つける可能
性が高くなります。

   カスタマイズされたパフォーマンスベンチマークを実行せずに、特定のリポ
ジトリでこのオプションを使用することはおそらく価値がありません。それには
もっと時間がかかり、結果として生じるスペース/デルタの最適化はそれだけの
価値があるかもしれませんし、そうでないかもしれません。これをまったく使用
しないことは、ほとんどのユーザーとそのリポジトリにとって正しいトレードオ
フです。

CONFIGURATION
*************

以下の文書は git-config(1) にあるものと同じです:

gc.aggressiveDepth
     ‘git gc --aggressive’ で使用されるデルタ圧縮アルゴリズムで使用され
     る深さパラメーター。これはデフォルトで50に設定されています。これは
     ‘--aggressive’ が使用されていない場合の ‘--depth’ オプションのデフ
     ォルトです。

     詳細については git-repack(1) の ‘--depth’ オプションの文書を参照し
     てください。

gc.aggressiveWindow
     ‘git gc --aggressive’ で使用されるデルタ圧縮アルゴリズムで使用され
     るウィンドウサイズパラメータ。これはデフォルトで250に設定されていま
     す。これは、 ‘--window’ のデフォルト値の10よりもはるかに積極的なウ
     ィンドウサイズです。

     詳細については、 git-repack(1) の ‘--window’ オプションの文書を参照
     してください。

gc.auto
     リポジトリにおおよそ指定の値より多くのルーズオブジェクトがある場合
     、 ‘git gc --auto’ はそれらをパックします。一部の磁器コマンドは、こ
     のコマンドを使用して、軽量のガベージコレクションを時々実行します。
     デフォルト値は6700です。

     これを0に設定すると、ルーズオブジェクトの数に基づく自動パッキングが
     無効にななります。また、他のヒューリスティックな ‘git gc --auto’ が
     、 ‘gc.autoPackLimit’ などの作業があるかどうかを判断するためにこの
     値を使用します。

gc.autoPackLimit
     リポジトリに ‘* .keep’ ファイルでマークされていないパックがこの設定
     値より多くある場合、 ‘git gc --auto’ はそれらを1つの大きなパックに
     統合します。デフォルト値は50です。これを0に設定すると、無効になりま
     す。 ‘gc.auto’ を0に設定すると、この設定も無効になります。

     以下の ‘gc.bigPackThreshold’ 構成変数を参照してください。この設定を
     使用中は、自動パックの制限がどのように機能するかに影響します。

gc.autoDetach
     システムがサポートしている場合は ‘git gc --auto’ は即座戻り、実行は
     バックグラウンドで行われます。デフォルトはtrueです。

gc.bigPackThreshold
     ゼロ以外の場合、 ‘git gc’ の実行時に、この設定値より大きいすべての
     パックが保持されます。これは ‘--keep-largest-pack’ と非常に似ていま
     すが、最大のパックだけでなく、しきい値を満たす全てのパックが保持さ
     れる点が異なります。デフォルトはゼロです。 _k_ 、 _m_ 、 _g_ の一般
     的な単位接尾辞がサポートされています。

     注意: 保持されるパックの数が gc.autoPackLimit を超える場合、この構
     成変数は無視され、基本パックを除くすべてのパックが再パックされるこ
     とに注意してください。再パック後、パックの数は gc.autoPackLimit を
     下回り、再び gc.bigPackThreshold が尊重されるでしょう。

     ‘git repack’ がスムーズに実行されると推定されるメモリ量が利用できず
     、かつ、 ‘gc.bigPackThreshold’ が設定されていない場合、最大のパック
     も除外されます(これは、 ‘--keep-largest-pack’ を指定して ‘git gc’ を
     実行するのと同じです)。

gc.writeCommitGraph
     trueの場合、 git-gc(1) が実行されると、 gcはcommit-graphファイルを
     書き換えます。 ‘git gc --auto’ を使用する場合、ハウスキーピングが必
     要な場合はコミットグラフが更新されます。デフォルトはtrueです。詳細
     については git-commit-graph(1) を参照してください。

gc.logExpiry
     ファイルgc.logが存在する場合、 ‘git gc --auto’ はそのコンテンツを出
     力し、そのファイルが「gc.logExpiry」より古い場合を除いて、実行する
     代わりにステータス0で終了します。デフォルトは「1.day」です。その他
     の値の指定方法については ‘gc.pruneExpire’ を参照してください。

gc.packRefs
     リポジトリで ‘git pack-refs’ を実行すると、HTTPなどの馬鹿プロトコル
     (dumb transport) を介して 1.5.1.2 より前のGitバージョンではクローン
     が作成できなくなります。この変数は、「git gc」が「git pack-refs」を
     実行するかどうかを決定します。これを ‘notbare’ に設定して、すべての
     非ベアリポジトリ内で有効にするか、ブール値に設定することができます
     。 デフォルトは ‘true’ です。

gc.pruneExpire
     「git gc」を実行すると、‘prune --expire 2.weeks.ago’ が呼び出されま
     す。この構成変数で猶予期間をオーバーライドします。 値「now」を使用
     してこの猶予期間を無効にし、到達不能なオブジェクトを常にすぐに剪定
     (prune)するか、「never」を使用して剪定を抑制することができます。こ
     の機能は「git gc」がリポジトリに書き込む別のプロセスと同時に実行さ
     れる場合の破損を防ぐのに役立ちます。 git-gc(1) の「NOTES」セクショ
     ンを参照してください。

gc.worktreePruneExpire
     _git gc_ が実行されると、 ‘git worktree prune --expire3.months.ago’
     が呼び出されます。この構成変数を使用して、別の猶予期間を設定できま
     す。値「now」を使用して猶予期間を無効にし、 ‘$GIT_DIR/worktrees’ を
     すぐに剪定(prune)するか、「never」を使用して剪定を抑制することがで
     きます。

gc.reflogExpire
gc.<pattern>.reflogExpire
     「git reflog expire」は、この時間より古いreflogエントリを削除します
     。デフォルトは90日です。値「now」はすべてのエントリをすぐに期限切れ
     にし、「never」は期限切れを完全に抑制します。中央に「<pattern>」(例
     :「refs/stash」)がある場合、設定は <pattern> に一致するrefにのみ適
     用されます。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable
     _git reflog expire_ は、この時間より古いreflogエントリを削除し、現
     在の先端(the current tip)から到達不能にします。デフォルトは30日です
     。値「now」はすべてのエントリをすぐに期限切れにし、「never」は期限
     切れを完全に抑制します。中央に「<pattern>」(例:「refs/stash」)があ
     る場合、設定は <pattern> に一致するrefにのみ適用されます。

     これらのタイプのエントリは通常、 ‘git commit--amend’ または ‘git
     rebase’ を使用した結果として作成され、修正またはリベースが発生する
     前のコミットです。これらの変更は現在のプロジェクトの一部ではないた
     め、ほとんどのユーザーはそれらをより早く期限切れにしたいと思うでし
     ょう。そのため、デフォルトは ‘gc.reflogExpire’ よりも積極的です。

gc.rerereResolved
     以前に解決した競合するマージの記録は、「git rerere gc」が実行される
     ときに、この設定値で指定の日数保持されます。より人間が読める「
     1.month.ago」などを使用することもできます。デフォルトは60日です。
     git-rerere(1) を参照してください。

gc.rerereUnresolved
     _git rerere gc_ が実行されると、解決していない競合するマージの記録
     がこの設定値の日数保持されます。より人間が読める「1.month.ago」など
     を使用することもできます。デフォルトは15日です。 git-rerere(1) を参
     照してください。

NOTES
*****

_git gc_ は、リポジトリ内のどこかで参照されているオブジェクトを削除しな
いように非常に努力しています。特に、現在のブランチとタグのセットによって
参照されるオブジェクトだけでなく、インデックス、リモートトラッキングブラ
ンチ、reflog（後で修正または巻き戻されたブランチのコミットを参照する可能
性がある）などによって参照されるオブジェクトも保持されます。それ以外の場
合は、 refs/* 名前空間にあります。オブジェクトに添付された(「git notes」
によって作成された種類の) noteは、オブジェクトの存続に寄与しないことに注
意してください。一部のオブジェクトが削除されることを期待していて、削除さ
れない場合は、それらの場所をすべて確認し、それらの参照を削除することが理
にかなっているかどうかを判断してください。

   一方、「git gc」が別のプロセスと同時に実行されると、他のプロセスが使
用しているが参照を作成していないオブジェクトが削除されるリスクがあります
。これにより、他のプロセスが失敗したり、他のプロセスが後で削除されたオブ
ジェクトへの参照を追加した場合にリポジトリが破損したりする可能性がありま
す。 Gitには、この問題を大幅に軽減する2つの機能があります:

  1. ‘--prune’ の日付よりも新しい変更時刻を持つオブジェクトは、そこから
     到達可能なすべてのモノと共にに保持されます。

  2. データベースにオブジェクトを追加するほとんどの操作は、オブジェクト
     がすでに存在する場合はその変更時刻を更新して、 #1 が適用されるよう
     にします。

   ただし、これらの機能は完全なソリューションには及ばないため、コマンド
を同時に実行するユーザーは、破損のリスクを抱えて生活する必要があります
(実際にはリスクは低いようです)。

HOOKS
*****

‘git gc --auto’ コマンドは、 _pre-auto-gc_ フックを実行します。 詳細につ
いては、 githooks(5) を参照してください。

SEE ALSO
********

git-prune(1) git-reflog(1) git-repack(1) git-rerere(1)

GIT
***

Part of the git(1) suite

Name
****

git-get-tar-commit-id — git-archiveを使用して作成されたアーカイブからコ
ミットIDを抽出します

Synopsis
********

     git get-tar-commit-id

DESCRIPTION
***********

_git archive_ によって作成されたtarアーカイブを標準入力から読み取り、そ
こに保存されているコミットIDを抽出します。入力の最初の1024バイトのみを読
み取るため、実行時間はtarアーカイブのサイズに大きく影響されることはあり
ません。

   コミットIDが見つからない場合、 _git get-tar-commit-id_ は何も出力せず
リターンコード1を返すだけです。これは、アーカイブが _git archive_ を使用
して作成されていない場合、または _git archive_ の最初のパラメーターが、
コミットIDまたはタグではなくツリーIDだった場合に発生する可能性があります
。(訳注:入力がtarアーカイブで無い場合はstderrにtarアーカイブで無い旨のエ
ラー出力があり、exit code は 128。入力がtarアーカイブの場合で、コミット
IDが見つからない場合は表記どおりstdout/stderr出力一切無しでexit code 1)

GIT
***

Part of the git(1) suite

Name
****

git-grep — パターンにマッチする行を出力します

Synopsis
********

     git grep [-a | –text] [-I] [–textconv] [-i | –ignore-case] [-w | –word-regexp]
                [-v | –invert-match] [-h|-H] [–full-name]
                [-E | –extended-regexp] [-G | –basic-regexp]
                [-P | –perl-regexp]
                [-F | –fixed-strings] [-n | –line-number] [–column]
                [-l | –files-with-matches] [-L | –files-without-match]
                [(-O | –open-files-in-pager) [<pager>]]
                [-z | –null]
                [ -o | –only-matching ] [-c | –count] [–all-match] [-q | –quiet]
                [–max-depth <depth>] [–[no-]recursive]
                [–color[=<when>] | –no-color]
                [–break] [–heading] [-p | –show-function]
                [-A <post-context>] [-B <pre-context>] [-C <context>]
                [-W | –function-context]
                [–threads <num>]
                [-f <file>] [-e] <pattern>
                [–and|–or|–not|(|)|-e <pattern>…]
                [–recurse-submodules] [–parent-basename <basename>]
                [ [–[no-]exclude-standard] [–cached | –no-index | –untracked] | <tree>…]
                [–] [<pathspec>…]

DESCRIPTION
***********

作業ツリーの追跡ファイル(tracked files)内または、インデックスファイルに
登録されているブロブまたは、指定のツリーオブジェクトのブロブ、で指定のパ
ターンを探します。 パターンは、改行文字(newline characters)で区切られた
1つ以上の検索式のリストです。 検索式としての空文字列は、すべての行にマッ
チします。

OPTIONS
*******

‘--cached’
     作業ツリーで追跡中のファイル(tracked files)を検索する代わりに、イン
     デックスファイルに登録されているブロブを検索します。

‘--no-index’
     Git管理管理下に無い、現在のディレクトリ内のファイルを検索します。

‘--untracked’
     作業ツリーで、追跡中のファイル(tracked files)を検索するだけでなく、
     追跡されていないファイル(untracked files)も検索します。

‘--no-exclude-standard’
     また、 ‘.gitignore’ メカニズムを尊重せずに、無視されたファイル
     (ignored files)を検索します。 ‘--untracked’ でのみ役立ちます。

‘--exclude-standard’
     ‘.gitignore’ メカニズムを介して指定されている、無視されたファイル
     (ignored files)に注意を払わないでください。 ‘--no-index’ を使用して
     現在のディレクトリ内のファイルを検索する場合にのみ役立ちます。

‘--recurse-submodules’
     リポジトリ内で、アクティブかつチェックアウトされている各サブモジュ
     ールを再帰的に検索します。 <tree> オプションと組み合わせて使用する
     と、すべてのサブモジュール出力のプレフィックスは、親プロジェクトの
     <tree> オブジェクトの名前になります。 ‘--no-index’ が指定されている
     場合、このオプションは効果がありません。

‘-a’
‘--text’
     バイナリファイルをテキストであるかのように処理します。

‘--textconv’
     textconvフィルター設定を尊重します。

‘--no-textconv’
     textconvフィルター設定を尊重しません。 これがデフォルトです。

‘-i’
‘--ignore-case’
     パターンとファイルの間で英大文字小文字の違いは無視(ignore case)して
     ください。

‘-I’
     バイナリファイルでパターンのマッチをしないでください。

‘--max-depth <depth>’
     コマンドラインで指定された<pathspec>ごとに、最大 <depth> レベルまで
     ディレクトリを降りていくかを指定します。 -1 は、制限がないことを意
     味します。 <pathspec> にアクティブなワイルドカード(active
     wildcards)が含まれている場合、このオプションは無視されます。言い換
     えると、 ‘a*’ が ‘a*’ という名前のディレクトリと一致する場合、 ‘*’
     は文字通り一致するため、 ‘--max-depth’ は引き続き有効です。

‘-r’
‘--recursive’
     ‘--max-depth=-1’ と同一です。これがデフォルトです。

‘--no-recursive’
     ‘--max-depth=0’ と同一です。

‘-w’
‘--word-regexp’
     パターンは単語(word)単位でのみ一致します(行頭で開始するかまたは単語
     以外の文字が先行するかのいずれか。行末で終わるか、単語以外の文字が
     続きます)。

‘-v’
‘--invert-match’
     一致しない行を選択します。

‘-h’
‘-H’
     デフォルトでは、コマンドは各々マッチしたファイル名を表示します。
     ‘-h’ オプションは、この出力を抑制するために使用されます。‘-H’ はオ
     プション機能として完全を期すためにあり、コマンドラインで ‘-H’ 以前
     に指定した ‘-h’ を打ち消す以外は何もしません。

‘--full-name’
     サブディレクトリから実行する場合、コマンドは通常、現在のディレクト
     リからの相対パスを出力します。 このオプションは、プロジェクトの最上
     位ディレクトリを基準にしたパスを出力します。

‘-E’
‘--extended-regexp’
‘-G’
‘--basic-regexp’
     パターンにはPOSIX 拡張/基本 正規表現を使用します。 デフォルトでは基
     本正規表現を使用します。

‘-P’
‘--perl-regexp’
     パターンにはPerl互換の正規表現を使用してください。

     これらのタイプの正規表現のサポートは、コンパイル時オプションに依存
     します。 Gitがこれらのサポート付きでコンパイルされていない場合、こ
     のオプションを指定するとGitが停止(die)します。

‘-F’
‘--fixed-strings’
     パターンには固定文字列を使用します(パターンを正規表現として解釈しな
     いでください)。

‘-n’
‘--line-number’
     マッチした行の前に行番号を付けます。

‘--column’
     マッチがあった行の中で(複数マッチするかもしれないので)、最初にマッ
     チしたぶんの行頭(行頭を0じゃなくて1とする)からのオフセットバイト
     (1-indexed byte-offset)を行頭に置きます。

‘-l’
‘--files-with-matches’
‘--name-only’
‘-L’
‘--files-without-match’
     一致したすべての行を表示する代わりに、一致を含む(または含まない
     ;‘--files-without-match’)ファイル名のみを表示します。 ‘git diff’ と
     の互換性を高めるために、‘--name-only’ が ‘--files-with-matches’ の
     同義語となっています。

‘-O[<pager>]’
‘--open-files-in-pager[=<pager>]’
     一致するファイルをページャーで開きます(ただし、 ‘grep’ の出力ではあ
     りません)。 ページャーがたまたま「less」または「vi」であり、ユーザ
     ーが1つのパターンのみを指定した場合、最初に開かれるファイルはファイ
     ルには自動的に最初のマッチになります。 ‘pager’ 引数はオプションです
     。 指定する場合は、スペースなしでオプションに固定する必要があります
     。 ‘pager’ が指定されていない場合、デフォルトのページャーが使用され
     ます(git-config(1) の‘core.pager‘ を参照)。(訳注:lessでは次のファイ
     ルに移動するには :n とタイプする。詳しくはmanページ参照)

‘-z’
‘--null’
     出力のパス名の区切り文字として ‘\0’ を使用し、そのまま(verbatim)出
     力します。 このオプションがないと、構成変数 core.quotePath で説明さ
     れているように、「異常な」文字を含むパス名がクォートされます
     (git-config(1) 参照)。

‘-o’
‘--only-matching’
     マッチがある行のマッチする(空でない)部分のみを出力し、行内で複数マ
     ッチした場合、そのような各部分を別々の行に出力します。(訳注: 例えば
     ‘git grep -n --break --column --only-matching hoge’)

‘-c’
‘--count’
     マッチした行を全て表示する代わりに、ファイル毎にマッチした行の行数
     を表示します。

‘--color[=<when>]’
     色付きのマッチ表示します。 値は always (デフォルト) または never ま
     たは auto である必要があります。

‘--no-color’
     構成ファイルがデフォルトでカラー出力を提供している場合でも、マッチ
     のハイライト表示をオフにします。 ‘--color=never’ と同じです。

‘--break’
     一致の出力で、異なるファイルの間に(区切りとして)1行の空行を出力しま
     す。(訳注:例 ‘git grep --break --heading hoge’)

‘--heading’
     マッチしたのを表示する各行の初めファイル名を表示するのではなく、表
     示するファイル毎に、その直前にファイル名だけの行を出力します。 (訳
     注:例 ‘git grep --break --heading hoge’)

‘-p’
‘--show-function’
     マッチした行が関数名そのものでない限り、マッチした関数名を含む先行
     行を表示します。名前は、 ‘git diff’ がパッチハンクヘッダーを処理す
     るのと同じ方法で決定されます (gitattributes(5) の「Defining a
     custom hunk-header」参照)。

‘-<num>’
‘-C <num>’
‘--context <num>’
     各マッチ行ごとに <num>行の先行行と後続行も表示し、マッチしたグルー
     プ毎に ‘--’ 行を挿入します。

‘-A <num>’
‘--after-context <num>’
     各マッチ行ごとに <num> 行の後続行も表示し、マッチしたグループ毎に
     ‘--’ 行を挿入します。

‘-B <num>’
‘--before-context <num>’
     各マッチした行ごとに <num> 行の先行行も表示し、マッチしたグループ毎
     に ‘--’ 行を挿入します。

‘-W’
‘--function-context’
     関数名を含む前の行から次の関数名の前の行までの周囲のテキストを表示
     し、マッチした関数全体を効果的に示します。 関数名は、 ‘git diff’ が
     パッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--threads <num>’
     使用するgrepワーカースレッドの数。 詳細については、「
     CONFIGURATION」の「grep.threads」を参照してください。

‘-f <file>’
     <file>から1行に1つずつパターンを読み取ります。

     <file>を介してパターンを渡すと、 ‘\0’ を含む検索パターンを指定でき
     ます。

     すべてのパターンタイプが ‘\0’ を含むパターンをサポートしているわけ
     ではありません。 特定のパターンタイプがそのようなパターンをサポート
     できない場合、Gitはエラーになります。 PCRE v2 バックエンドに対して
     コンパイルされた場合の ‘--perl-regexp’ パターンタイプは、これらのタ
     イプのパターンを最も広くサポートしています。

     Git の 2.23.0 より前のバージョンでは、 ‘\0’ を含むパターンは黙って
     修正されます。 これは全く文書化されておらず、また、例えば ‘\0’ を含
     む非ASCIIパターンと ‘--ignore-case’ との間の文書化されていない奇妙
     で相互作用がありました。

     将来のバージョンでは、より多くの検索バックエンドが ‘\0’ を含むパタ
     ーンをサポートする可能性がありますが、それまでは、問題のパターンタ
     イプがそれらをサポートしない場合は終了(die)します。

‘-e’
     これに続く次のパラメータはパターンであることを示します。 このオプシ
     ョンは、 ‘-’ で始まるパターンに使用する必要があり、ユーザー入力を
     grepに渡すスクリプトで使用する必要があります。複数のパターンは or 結
     合されます。

‘--and’
‘--or’
‘--not’
‘( ... )’
     ブール式を使用して、複数のパターンを組み合わせる方法を指定します。
     ‘--or’ はデフォルトの演算子です。 ‘--and’ は ‘--or’ よりも優先され
     ます。 ‘-e’ はすべてのパターンに使用する必要があります。

‘--all-match’
     ‘--or’ と組み合わせて複数のパターン式を指定する場合、このフラグを指
     定して、すべてにマッチする行を持つファイルにマッチを制限します。

‘-q’
‘--quiet’
     マッチした行を出力しないでください。 代わりに、マッチした場合は終了
     ステータス0で終了し、マッチしない場合は終了ステータスがゼロ以外で終
     了します。

‘<tree>...’
     作業ツリーで追跡中のファイル(tracked files)を検索する代わりに、指定
     のツリーでブロブを検索します。

‘--’
     コマンドにオプション指定の終了を教えます。 残りのパラメーターは
     <pathspec> リミッターです。

‘<pathspec>...’
     指定されている場合は、検索を少なくとも1つのパターンに一致するパスに
     制限します。 パスの先行一致 と glob(7)パターン の両方がサポートされ
     ます。

     <pathspec> 構文の詳細については、 gitglossary(7) の「pathspec」エン
     トリを参照してください。

EXAMPLES
********

‘git grep 'time_t' -- '*.[ch]'’
     作業ディレクトリとそのサブディレクトリで、追跡中(tracked)のすべての
     .c ファイルと .h ファイルで ‘time_t’ を探します。

‘git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)’
     ‘#define’ かつ、 ‘MAX_PATH’ または ‘PATH_MAX’ のいずれか、を持つ行
     を探します。

‘git grep --all-match -e NODE -e Unexpected’
     各ファイル内で ‘NODE’ または ‘Unexpected’ を探し、かつ、 ‘NODE’ と
     ‘Unexpected’ の両方を持つ行があるファイルだけを表示します。

‘git grep solution -- :^Documentation’
     ‘Documentation’ ファイルを除くファイル達から ‘solution’ を探します
     。

NOTES ON THREADS
****************

‘--open-files-in-pager’ が使用されている場合、 ‘ –threads‘ オプション(お
よび grep.threads 構成)は無視され、シングルスレッド実行が強制されます。

   オブジェクトストアを(‘--cached’ を使用して、またはツリーオブジェクト
を指定して)grepする場合、 ‘--textconv’ が指定され、テキスト変換が多すぎ
ると、複数のスレッドで実行するとシングルスレッドよりもパフォーマンスが低
下する可能性があります。 したがって、このような場合でパフォーマンスが低
下する時は、 ‘--threads=1’ を使用することが望ましい場合があります。

CONFIGURATION
*************

grep.lineNumber
     trueに設定すると、デフォルトで ‘-n’ オプションが有効になります。

grep.column
     trueに設定されている場合、デフォルトで ‘--column’ オプションを有効
     にします。

grep.patternType
     デフォルトのマッチ動作を設定します。 ‘basic’ or ‘extended’ or
     ‘fixed’ or ‘perl’ 値を使用すると、それぞれ ‘--basic-regexp’ or
     ‘--extended-regexp’ or ‘--fixed-strings’ or ‘--perl-regexp’ が有効
     になります。値 ‘default’ はデフォルトのマッチ動作に戻ります。

grep.extendedRegexp
     trueに設定されている場合、デフォルトで ‘--extended-regexp’ オプショ
     ンを有効にします。 ‘grep.patternType’ オプションが ‘default’ 以外の
     値に設定されている場合、このオプションは無視されます。

grep.threads
     使用するgrepワーカースレッドの数。 設定されていない(または0に設定さ
     れている)場合、Gitは使用可能な論理コアの数と同じ数のスレッドを使用
     します。

grep.fullName
     trueに設定されている場合、デフォルトで ‘--full-name’ オプションを有
     効にします。

grep.fallbackToNoIndex
     trueに設定すると、git grepがgitリポジトリの外部で実行される場合は、
     ‘git grep --no-index’ にフォールバックします。 デフォルトはfalseで
     す。

GIT
***

Part of the git(1) suite

Name
****

git-gui — Gitのための移植性の高いGUI

Synopsis
********

     git gui [<command>] [arguments]

DESCRIPTION
***********

Gitの為の Tcl/Tk ベースのGUIです。「git gui」は、ユーザーが新しいコミッ
トを作成し、既存のコミットを修正し、ブランチを作成し、ローカルマージを実
行し、リモートリポジトリにフェッチ/プッシュすることでリポジトリに変更を
加えることができるようにすることに重点を置いています。

   _gitk_ とは異なり、 _git gui_ はコミットの生成と単一ファイルの注釈に
焦点を合わせており、プロジェクトの履歴は表示しません。 ただし、「git
gui」内から「gitk」セッションを開始するためのメニュー操作を提供します。

   「git gui」は、すべての一般的なUNIXシステム、Mac OS X、および
Windows(CygwinとMSYSの両方)で動作することが知られています。可能な限り、
OS固有のユーザーインターフェイスガイドラインに従い、「git gui」を各OSの
ユーザーにとってかなり自然なインターフェイスにしようとしています。

COMMANDS
********

blame
     指定されたバージョンの指定されたファイル(または指定されていない場合
     は作業ディレクトリ)でblameビューアを起動します。

browser
     指定されたコミット内のすべてのファイルを表示するツリーブラウザを起
     動します。ブラウザで選択したファイルをblemeビューアで開きます。

citool
     _git gui_ を開始し、シェルを終了してシェルに戻る前に、正確に1つのコ
     ミットを行うように調整します。インターフェイスはコミットアクション
     のみに制限されているため、アプリケーションの起動時間がわずかに短縮
     され、メニューバーが簡素化されます。

version
     現在実行中の「git gui」のバージョンを表示します。

Examples
********

‘git gui blame Makefile’
     現在の作業ディレクトリにあるファイル「Makefile」の内容を表示し、各
     行の元の作成者と、その行を現在の場所に移動した人の両方に注釈を付け
     ます。コミットされていないファイルには注釈が付けられ、(存在する場合
     )コミットされていない変更は「まだコミットされていません」と明示され
     ます。

‘git gui blame v0.99.8 Makefile’
     リビジョン「v0.99.8」の「Makefile」の内容を表示し、各行に注釈を付け
     ます。上記の例とは異なり、ファイルは作業ディレクトリではなくオブジ
     ェクトデータベースから読み取られます。

‘git gui blame --line=100 Makefile’
     上記のように注釈をロードし、100行目を中心にビューを自動的にスクロー
     ルします。

‘git gui citool’
     1つのコミットを行い、完了したらシェルに戻ります。このコマンドは、コ
     ミットを行う以外の方法でウィンドウが閉じられた場合、ゼロ以外の終了
     コードを返します。

‘git gui citool --amend’
     インターフェイスの「Amend Last Commit」モードを自動的に開始します。

‘git gui citool --nocommit’
     通常のcitoolとして動作しますが、コミットを行う代わりに、ゼロの終了
     コードで終了します。インデックスにマージされていないエントリが含ま
     れていないことを引き続きチェックするため、 git-mergetool(1) のGUIバ
     ージョンとして使用できます。

‘git citool’
     ‘git gui citool’ (上記)と同じです。

‘git gui browser maint’
     _maint_ ブランチのツリーのブラウザを表示します。ブラウザで選択した
     ファイルは、内部のblameビューアで表示できます。

SEE ALSO
********

gitk(1)
     Gitリポジトリブラウザ。 ブランチ、コミット履歴、ファイルの差分を表
     示します。 gitkは、「git gui」のリポジトリ視覚化操作によって開始さ
     れるユーティリティです。

Other
*****

「git gui」は実際には独立したプロジェクトとして維持されていますが、エン
ドユーザーの便宜のために安定したバージョンがGitスイートの一部として配布
されています。

   ‘git gui’ プロジェクトの公式リポジトリは以下の場所にあります:

     https://github.com/prati0100/git-gui.git/

GIT
***

Part of the git(1) suite

Name
****

git-hash-object — オブジェクトIDを計算し、オプションでファイルからブロブ
を作成する

Synopsis
********

     git hash-object [-t <type>] [-w] [–path=<file>|–no-filters] [–stdin [–literally]] [–] <file>…
     git hash-object [-t <type>] [-w] –stdin-paths [–no-filters]

DESCRIPTION
***********

指定のファイル(作業ツリーの外部にある可能性あり)の内容を使用して、指定さ
れたタイプのオブジェクトのオブジェクトID値を計算し、オブジェクトIDを標準
出力に報告します。オプションで結果のオブジェクトをオブジェクトデータベー
スに書き込みます。 <type> が指定されていない場合、デフォルトで「blob」に
なります。

OPTIONS
*******

‘-t <type>’
     タイプの指定(デフォルト: "blob")。

‘-w’
     実際にオブジェクトをオブジェクトデータベースに書き込みます。

‘--stdin’
     ファイルからではなく、標準入力からオブジェクトを読み取ります。

‘--stdin-paths’
     コマンドラインからではなく、標準入力から1行に1つずつファイル名を読
     み取ります。

‘--path’
     指定されたパスにあるオブジェクトをハッシュします。ファイルの場所は
     ハッシュ値に直接影響しませんが、パスを使用して、オブジェクトデータ
     ベースに配置する前にオブジェクトに適用するGitフィルターを決定し、フ
     ィルターを適用した結果、実際のブロブを配置します。オブジェクトデー
     タベースへの入力は、指定されたファイルとは異なる場合があります。こ
     のオプションは主に、作業ディレクトリの外部にある一時ファイルまたは
     標準入力から読み取られたファイルをハッシュする場合に役立ちます。

‘--no-filters’
     行末変換など、属性メカニズムによって選択された入力フィルターを無視
     して、コンテンツをそのままハッシュします。 ファイルが標準入力から読
     み取られる場合、 ‘--path’ オプションが指定されていない限り、これは
     常に暗黙に指定されたものとみなします。

‘--literally’
     ‘--stdin’ が、標準のオブジェクトパースやgit-fsckチェックに合格しな
     い可能性のあるガベージをハッシュして緩いオブジェクトにできるように
     します。Git自体のストレステストや、野生で遭遇した破損または偽のオブ
     ジェクトの特性の再現に役立ちます。

GIT
***

Part of the git(1) suite

Name
****

git-help — Gitに関するヘルプ情報を表示します

Synopsis
********

     git help [-a|–all [–[no-]verbose]] [-g|–guides]
                [-i|–info|-m|–man|-w|–web] [COMMAND|GUIDE]

DESCRIPTION
***********

オプションがなく、コマンドまたはガイドが指定されていない場合、gitコマン
ドの概要と最も一般的に使用されるGitコマンドのリストが標準出力に出力され
ます。

   オプション ‘--all’ または ‘-a’ を指定すると、使用可能なすべてのコマン
ドが標準出力に出力されます。

   オプション ‘--guides’ または ‘-g’ を指定すると、Gitコンセプトガイドの
リストも標準出力に出力されます。

   コマンドまたはガイドが指定されると、そのコマンドまたはガイドのマニュ
アルページが表示されます。 ‘man’ プログラムは、この目的のためにデフォル
トで使用されますが、これは他のオプションまたは構成変数によってオーバーラ
イドできます。

   エイリアスが指定されている場合、gitは標準出力にエイリアスの定義を表示
します。 エイリアスコマンドのマニュアルページを取得するには、 ‘git
COMMAND --help’ を使用します。

   注意: ‘git --help...’ は ‘git help ...’ と同じであることに注意してく
ださい。これは、前者が内部で後者に変換されるためです。

   git(1) のマニュアルページを表示するには、 ‘git help git’ を使用します
。

   このページは、 ‘git help help’ または ‘git help --help’ で表示できま
す。

OPTIONS
*******

‘-a’
‘--all’
     使用可能なすべてのコマンドを標準出力に出力します。 このオプションは
     、指定されたコマンドまたはガイド名をオーバーライドします。

‘--verbose’
     ‘--all’ と一緒に使用すると、認識されたすべてのコマンドの説明が出力
     されます。 これがデフォルトです。

‘-c’
‘--config’
     使用可能なすべての構成変数をリストします。 これは、 git-config(1) の
     リストの簡単な要約です。

‘-g’
‘--guides’
     Gitコンセプトガイドのリストを標準出力に出力します。 このオプション
     は、指定されたコマンドまたはガイド名をオーバーライドします。

‘-i’
‘--info’
     コマンドのマニュアルページをinfo形式で表示します。 ‘info’ プログラ
     ムがその目的で使用されます。

‘-m’
‘--man’
     コマンドのマニュアルページをman形式で表示します。 このオプションは
     、 ‘help.format’ 構成変数に設定された値をオーバーライドするために使
     用できます。

     デフォルトでは、 ‘man’ プログラムを使用してマニュアルページを表示し
     ますが、 ‘man.viewer’ 構成変数を使用して他の表示プログラムを選択す
     ることもできます(後述)。

‘-w’
‘--web’
     コマンドのマニュアルページを ‘web’ (HTML)形式で表示します。その目的
     のためにウェブブラウザが使用されます。

     Webブラウザーは、構成変数 ‘help.browser’ または ‘web.browser’ を使
     用して指定できます。前者が設定されていない場合は、 ‘web.browser’ を
     使用します。 これらの構成変数のいずれも設定されていない場合、 (‘git
     help’ によって呼び出される、) ‘git web{litdd}browse’ ヘルパースクリ
     プトが適切なデフォルトを選択します。 詳細については、
     git-web–browse(1) を参照してください。

CONFIGURATION VARIABLES
***********************

help.format
===========

コマンドラインオプションが渡されない場合、 ‘help.format’ 構成変数がチェ
ックされます。 この変数では、以下の値がサポートされています。 これらは
‘git help’ の対応するコマンドラインオプションとして動作します:

   • ‘man’ は ‘-m|--man’ に対応します。

   • ‘info’ は ‘-i|--info’ に対応します。

   • ‘web’ または ‘html’ は ‘-w|--web’ に対応します。

help.browser と web.browser と browser.<tool>.path
==================================================

‘help.browser’ と ‘web.browser’ と ‘browser.<tool>.path’ は、 (コマンド
ラインオプションまたは構成変数のいずれかによって、) ‘web’ 形式が選択され
ているかどうかもチェックされます。上記「OPTIONS」セクションの ‘-w|--web’
と および git-web–browse(1) を参照してください。

man.viewer
==========

‘man’ 形式が選択されている場合、 ‘man.viewer’ 構成変数がチェックされます
。 現在、以下の値がサポートされています:

   • ‘man’ : 通常どおり ‘man’ プログラムを使用します。

   • ‘woman’ : ‘emacsclient’ を使用してemacsで ‘woman’ モードを起動しま
     す(これはemacsclientバージョン22以降でのみ機能します)。

   • ‘konqueror’ : ‘kfmclient’ を使用して、新しいkonquerorタブでマニュア
     ルページを開きます(以下の「Note about konqueror」を参照)。

   対応する ‘man.<tool>.cmd’ 構成エントリがある場合は、他のツールの値を
使用できます(後述)。

   ‘man.viewer’ 構成変数に複数値を指定できます。対応するプログラムは、構
成ファイルにリストされている順序で試されます。

   たとえば、以下の構成:

             [man]
                     viewer = konqueror
                     viewer = woman

   最初にkonquerorを使用しようと試みます。 ただし、これは失敗する可能性
があり(たとえば、DISPLAYが設定されていない場合)、その場合、emacsの
womanモードが試されます。

   すべてが失敗した場合、またはビューアが設定されていない場合は、
‘GIT_MAN_VIEWER’ 環境変数で指定されたビューアが試されます。それも失敗し
た場合は、とにかく ‘man’ プログラムが試されます。

man.<tool>.path
===============

構成変数 ‘man.<tool>.path’ を設定することにより、優先するmanビューアへの
フルパスを明示的に指定できます。 たとえば、 ‘man.konqueror.path’ を設定
することで、konquerorへの絶対パスを設定できます。 それ以外の場合、 ‘git
help’ はツールがPATH上にあると想定します。

man.<tool>.cmd
==============

‘man.viewer’ 構成変数で指定されたmanビューアがサポートされているものに含
まれていない場合、対応する ‘man.<tool>.cmd’ 構成変数が検索されます。 こ
の変数が存在する場合、指定されたツールはカスタムコマンドとして扱われ、シ
ェルのevalを使用して、引数として渡されたマニュアルページを使用してコマン
ドを実行します。

Note about konqueror
====================

‘man.viewer’ 構成変数で ‘konqueror’ が指定されている場合、可能であれば、
‘kfmclient’ を起動して、既に開いているkonquerorのmanページを新しいタブで
開こうとします。

   一貫性を保つために、 ‘man.konqueror.path’ が ‘A_PATH_TO/konqueror’ の
ようなものに設定されている場合にも、このようなトリックを試します。 つま
り、代わりに ‘A_PATH_TO/kfmclient’ を起動しようとします。

   あなたが本当に ‘konqueror’ を使用したい場合は、以下のようなものを使用
できます:

             [man]
                     viewer = konq

             [man "konq"]
                     cmd = A_PATH_TO/konqueror

Note about git config –global
=============================

注意: これらの構成変数はすべて、たとえば以下のように、 ‘--global’ フラグ
を使用して設定する必要があることに注意してください:

     $ git config --global help.format web
     $ git config --global web.browser firefox

   それらは、おそらくリポジトリ固有というよりはユーザー固有であるためで
す。 詳細については、 git-config(1) を参照してください。

GIT
***

Part of the git(1) suite

Name
****

git-http-backend — Git over HTTP のサーバー側実装

Synopsis
********

     git http-backend

DESCRIPTION
***********

‘http://’ と ‘https://’ プロトコルを介してリポジトリにアクセスするGitク
ライアントにGitリポジトリのコンテンツを提供するための単純なCGIプログラム
。 このプログラムは、スマートHTTPプロトコルと下位互換性のあるダムHTTPプ
ロトコルの両方を使用してフェッチするクライアント、およびスマートHTTPプロ
トコルを使用してプッシュするクライアントをサポートします。 適切に構成さ
れていれば、Gitのより効率的な「v2」プロトコルもサポートします。 以下の「
ENVIRONMENT」セクションの「GIT_PROTOCOL」の説明を参照してください。

   ディレクトリにマジックファイル ‘git-daemon-export-ok’ があることを確
認し、この方法でエクスポートのマークが明示されていないGitディレクトリの
エクスポートを拒否します(‘GIT_HTTP_EXPORT_ALL’ 環境変数が設定されている
場合を除く)。

   デフォルトでは、 ‘upload-pack’ サービスのみが有効になっており、 ‘git
fetch’ や ‘git pull’ や ‘git clone’ から呼び出される ‘git fetch-pack’ ク
ライアントと ‘git ls-remote’ クライアントにサービスを提供します。クライ
アントが認証されると、 ‘receive-pack’ サービスが有効になります。このサー
ビスは ‘git push’ から呼び出される ‘git send-pack’ クライアントにサービ
スを提供します。

SERVICES
********

これらのサービスは、リポジトリごとの構成ファイルを使用して有効/無効にで
きます。

http.getanyfile
     これは、アップロードパックサービスを使用できないバージョン1.6.6より
     古いGitクライアントにサービスを提供します。 有効にすると、クライア
     ントは、ブランチから到達できなくなったがまだ存在しているオブジェク
     トを含む、リポジトリ内の任意のファイルを読み取ることができます。 デ
     フォルトで有効になっていますが、リポジトリはこの構成アイテムを「
     false」に設定することで無効にできます。

http.uploadpack
     これは、 ‘git fetch-pack’ および ‘git ls-remote’ クライアントにサー
     ビスを提供します。 デフォルトで有効になっていますが、リポジトリはこ
     の構成アイテムを「false」に設定することで無効にできます。

http.receivepack
     これは ‘git send-pack’ クライアントにサービスを提供し、プッシュを可
     能にします。 匿名ユーザーの場合はデフォルトで無効になっており、
     Webサーバーによって認証されたユーザーの場合はデフォルトで有効になっ
     ています。 この項目を ‘false’ に設定することで無効にするか、 ‘true’
     に設定することで匿名ユーザーを含むすべてのユーザーに対して有効にす
     ることができます。

URL TRANSLATION
***************

ディスク上のリポジトリの場所を特定するために、 ‘git http-backend’ は、
Webサーバーによって自動的に設定される環境変数PATH_INFOと、Webサーバー構
成で手動で設定する必要があるGIT_PROJECT_ROOTを連結します。
GIT_PROJECT_ROOTが設定されていない場合、 ‘git http-backend’ は
PATH_TRANSLATEDを読み取ります。これも、Webサーバーによって自動的に設定さ
れます。

EXAMPLES
********

以下の例はすべて、 ‘http://$hostname/git/foo/bar.git’ を
‘/var/www/git/foo/bar.git’ にマップします。

Apache 2.x
     mod_cgiとmod_aliasとmod_envが有効になっていることを確認し、
     GIT_PROJECT_ROOT (またはDocumentRoot)を適切に設定して、CGIに
     ScriptAliasを作成します:

          SetEnv GIT_PROJECT_ROOT /var/www/git
          SetEnv GIT_HTTP_EXPORT_ALL
          ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/

          # This is not strictly necessary using Apache and a modern version of
          # git-http-backend, as the webserver will pass along the header in the
          # environment as HTTP_GIT_PROTOCOL, and http-backend will copy that into
          # GIT_PROTOCOL. But you may need this line (or something similar if you
          # are using a different webserver), or if you want to support older Git
          # versions that did not do that copying.
          #
          # Having the webserver set up GIT_PROTOCOL is perfectly fine even with
          # modern versions (and will take precedence over HTTP_GIT_PROTOCOL,
          # which means it can be used to override the client's request).
          SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0

     匿名の読み取りアクセスを有効にし、認証された書き込みアクセスを有効
     にするには、最初のref広告(クエリ文字列のサービスパラメーターを介し
     たプッシュとして検出)とreceive-pack呼び出し自体の両方の承認
     (authorization)が必要です。

          RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
          RewriteCond %{REQUEST_URI} /git-receive-pack$
          RewriteRule ^/git/ - [E=AUTHREQUIRED:yes]

          <LocationMatch "^/git/">
                  Order Deny,Allow
                  Deny from env=AUTHREQUIRED

                  AuthType Basic
                  AuthName "Git Access"
                  Require group committers
                  Satisfy Any
                  ...
          </LocationMatch>

     クエリ文字列と照合するために使用できる ‘mod_rewrite’ がない場合は、
     以下のように ‘git-receive-pack’ 自体を保護するだけで十分です:

          <LocationMatch "^/git/.*/git-receive-pack$">
                  AuthType Basic
                  AuthName "Git Access"
                  Require group committers
                  ...
          </LocationMatch>

     このモードでは、サーバーは、クライアントが最初の接続中ではなく、プ
     ッシュのオブジェクトネゴシエーションフェーズを実際に開始するまで、
     認証(authentication)を要求しません。 このため、プッシュを受け入れる
     必要のあるリポジトリでは、 ‘http.receivepack’ 設定オプションも有効
     にする必要があります。 ‘http.receivepack’ が設定されていない場合の
     デフォルトの動作は、認証されていないユーザーによるプッシュを拒否す
     ることです。 したがって、最初のリクエストは、認証の機会さえ与えずに
     、クライアントに ‘403 Forbidden’ を報告します。

     読み取りと書き込みの両方に認証を要求するには、リポジトリまたはその
     親ディレクトリの1つでLocationディレクティブを使用します:

          <Location /git/private>
                  AuthType Basic
                  AuthName "Private Git Access"
                  Require group committers
                  ...
          </Location>

     同一URLでgitwebを提供するには、ScriptAliasMatchを使用して ‘git
     http-backend’ が処理できるURLのみを取得し、残りをgitwebに転送します
     :

          ScriptAliasMatch \
                  "(?x)^/git/(.*/(HEAD | \
                                  info/refs | \
                                  objects/(info/[^/]+ | \
                                           [0-9a-f]{2}/[0-9a-f]{38} | \
                                           pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
                                  git-(upload|receive)-pack))$" \
                  /usr/libexec/git-core/git-http-backend/$1

          ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/

     単一のリポジトリで異なる gitnamespaces(7) から複数のリポジトリを提
     供するには:

          SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1
          ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1

Accelerated static Apache 2.x
     上記と同様ですが、Apacheを使用して、ディスクに保存されている静的フ
     ァイルを返すことができます。 多くのシステムでは、Apacheがカーネルに
     ファイルの内容をファイルシステムからネットワークに直接コピーするよ
     うに要求できるため、これはより効率的です:

          SetEnv GIT_PROJECT_ROOT /var/www/git

          AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /var/www/git/$1
          AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
          ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/

     これは、gitweb構成と組み合わせることができます:

          SetEnv GIT_PROJECT_ROOT /var/www/git

          AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /var/www/git/$1
          AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/www/git/$1
          ScriptAliasMatch \
                  "(?x)^/git/(.*/(HEAD | \
                                  info/refs | \
                                  objects/info/[^/]+ | \
                                  git-(upload|receive)-pack))$" \
                  /usr/libexec/git-core/git-http-backend/$1
          ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/

Lighttpd
     ‘mod_cgi’ 、 ‘mod_alias’ 、 ‘mod_auth’ 、 ‘mod_setenv’ がロードされ
     ていることを確認してから、 ‘GIT_PROJECT_ROOT’ を適切に設定し、すべ
     てのリクエストをCGIにリダイレクトします。

          alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
          $HTTP["url"] =~ "^/git" {
                  cgi.assign = ("" => "")
                  setenv.add-environment = (
                          "GIT_PROJECT_ROOT" => "/var/www/git",
                          "GIT_HTTP_EXPORT_ALL" => ""
                  )
          }

     匿名での読み取りアクセスを有効にする一方、認証された書き込みアクセ
     スを有効にするには:

          $HTTP["querystring"] =~ "service=git-receive-pack" {
                  include "git-auth.conf"
          }
          $HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
                  include "git-auth.conf"
          }

     ここで、 ‘git-auth.conf’ は以下のようになります:

          auth.require = (
                  "/" => (
                          "method" => "basic",
                          "realm" => "Git Access",
                          "require" => "valid-user"
                         )
          )
          # ...and set up auth.backend here

     読み取りと書き込みの両方に認証を要求するには:

          $HTTP["url"] =~ "^/git/private" {
                  include "git-auth.conf"
          }

ENVIRONMENT
***********

‘git http-backend’ は、呼び出し元のWebサーバーによって設定された ‘CGI’ 環
境変数に依存します:

   • PATH_INFO (GIT_PROJECT_ROOTが設定されている場合。それ以外の場合は
     PATH_TRANSLATED)

   • REMOTE_USER

   • REMOTE_ADDR

   • CONTENT_TYPE

   • QUERY_STRING

   • REQUEST_METHOD

   ‘GIT_HTTP_EXPORT_ALL’ 環境変数を ‘git-http-backend’ に渡して、各リポ
ジトリの ‘git-daemon-export-ok’ ファイルのチェックをバイパスしてから、そ
のリポジトリのエクスポートを許可することができます。

   ‘GIT_HTTP_MAX_REQUEST_BUFFER’ 環境変数(または ‘http.maxRequestBuffer’
構成変数)は、gitがフェッチ中に処理する最大のrefネゴシエーション要求を変
更するように設定できます。これより大きなバッファを必要とするフェッチは成
功しません。 通常、この値を変更する必要はありませんが、ref数が非常に多い
リポジトリからフェッチする場合に役立つことがあります。 値は単位毎に指定
できます(たとえば、100メガバイトの場合は「100M」)。 デフォルトは10メガバ
イトです。

   クライアントは、 ‘Git-Protocol’ HTTPヘッダーを使用して、オプションの
プロトコル機能（v2プロトコルなど）を探査(probe)できます。 これらをサポー
トするには、そのヘッダーの内容が ‘GIT_PROTOCOL’ 環境変数に含まれている必
要があります。 ほとんどのウェブサーバーはこのヘッダーを
‘HTTP_GIT_PROTOCOL’ 変数を介してCGIに渡し、‘git-http-backend’ はそれを
‘GIT_PROTOCOL’ に自動的にコピーします。 ただし、一部のWebサーバーは、渡
すヘッダーをより選択的にする場合があります。その場合には明示的に構成する
必要があります(上記EXAMPLESセクションのApache構成の「Git-Protocol」の説
明を参照してください)。

   バックエンドプロセスは、GIT_COMMITTER_NAMEを ‘$REMOTE_USER’ に設定し
、 GIT_COMMITTER_EMAILを ‘$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}’ に設定
して、 ‘git-receive-pack’ によって作成されたreflogにプッシュを実行したリ
モートユーザの識別情報が含まれるようにします。

   すべての ‘CGI’ 環境変数は、 ‘git-receive-pack’ によって呼び出される各
フックで使用できます。

GIT
***

Part of the git(1) suite

Name
****

git-http-fetch — HTTPでリモートGitリポジトリからダウンロード

Synopsis
********

     git http-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [–recover] [–stdin | –packfile=<hash> | <commit>] <url>

DESCRIPTION
***********

HTTPでリモートGitリポジトリからダウンロード

   このコマンドは常にすべてのオブジェクトを取得します。歴史的に、ダウン
ロードするオブジェクトを選択するには、 ‘-a’ と ‘-c’ と ‘-t’ の3つのオプ
ションがありました。それらは現在、何も警告を出さずに無視されます。

OPTIONS
*******

commit-id
     プルするハッシュ、または [URL]/refs/ 下のファイル名 のいずれか。

‘-a, -c, -t’
     これらのオプションは、歴史的な理由により無視されます。

‘-v’
     ダウンロードしたものを報告します。

‘-w <filename>’
     転送が完了した後、ローカル側ドの $GIT_DIR/refs/<filename> の下のフ
     ァイル名にcommit-idを書き込みます。

‘--stdin’
     (この場合は期待されていない)コマンドラインのコミットIDの代わりに、
     _githttp-fetch_ は標準入力からの行を以下の形式であると期待します

          <commit-id>['\t'<filename-as-in--w>]

‘--packfile=<hash>’
     内部使用のみ。 (この場合は期待されていない)コマンドラインのコミット
     IDの代わりに、 _git http-fetch_ は指定されたURLで直接パックファイル
     をフェッチし、 index-pack を使用して対応する .idx ファイルと .keep
     ファイルを生成します。ハッシュは一時ファイルの名前を決定するために
     使用され、任意です。 index-pack の出力は stdout に出力されます。
     ‘--index-pack-args’ が必要です。

‘--index-pack-args=<args>’
     内部使用のみ。 ダウンロードしたパックの内容に対して実行するコマンド
     。引数はスペースで区切られURLエンコードされます。

‘--recover’
     ターゲットから到達可能なすべてのものがフェッチされていることを確認
     します。以前のフェッチが中断された後に使用されます。

GIT
***

Part of the git(1) suite

Name
****

git-http-push — HTTP/DAV を介してオブジェクトを別のリポジトリにプッシュ
する

Synopsis
********

     git http-push [–all] [–dry-run] [–force] [–verbose] <url> <ref> [<ref>…]

DESCRIPTION
***********

リモートに不足しているオブジェクトをリモートリポジトリに送信し、リモート
ブランチを更新します。

   *注* : libcurlが7.16より古い場合、このコマンドは一時的に無効になりま
す。 これは、組み合わせが機能しないことが報告されており、 リポジトリが破
損する場合があるためです。

OPTIONS
*******

‘--all’
     リモートリポジトリが現在の状態で完全であると想定しません。また、ロ
     ーカルrefの履歴全体のすべてのオブジェクトがリモートリポジトリに存在
     することを確認します。

‘--force’
     通常、コマンドは、上書きに使用されたローカルrefの祖先ではないリモー
     トrefの更新を拒否します。このフラグはこのチェックを無効にします。こ
     れが意味するのは、リモートリポジトリがコミットを失う可能性があると
     いうことです。注意して使用してください。

‘--dry-run’
     実際に更新を送信する以外はすべて行います。

‘--verbose’
     ローカルでウォークされているオブジェクトのリストと、リモートリポジ
     トリに正常に送信されたオブジェクトのリストを報告します。

‘-d’
‘-D’
     リモートリポジトリから <ref> を削除します。指定のブランチをリモート
     HEADにすることはできません。 ‘-d’ を指定する場合は、以下の他の条件
     も満たす必要があります:

        • リモートHEADは、ローカルに存在するオブジェクトに名前解決
          (resolve)できなければなりません。

        • 指定のブランチは、ローカルに存在するオブジェクトに名前解決
          (resolve)します。

        • 指定のブランチは、リモートHEADの祖先です。

<ref>…
     更新したいリモートrefs

SPECIFYING THE REFS
*******************

_<ref>_ 指定は、単一のパターン、またはコロン ":" で区切られた、そのよう
なパターンのペアのいずれかです(これは、ref名にコロンを含めることができな
いことを意味します)。 単一のパターン _<name>_ は、 _<name>:<name>_ の短
縮形です。

   各パターンペアは、送信元側(コロンの前)と宛先側(コロンの後)で構成され
ます。プッシュされるrefは、ソース側に一致する一致を見つけることによって
決定され、プッシュされる場所は、宛先側を使用して決定されます。

   • <src> がローカルrefの1つと正確に一致しない場合は、エラーになります
     。

   • <dst> がどのリモートrefとも一致しない場合、以下のどちらかです

        • "refs/" で始まる必要があります。この場合、文字通り <dst> が宛
          先として使用されます。

        • <src> == <dst> かつ <src> に一致するrefは、リモートrefのセット
          に存在してはなりません。ローカルで一致するref <src> は、宛先の
          名前として使用されます。

   ‘--force’ の指定が無く、<dst> が存在しない場合または <dst> が <src> の
適切なサブセット(つまり、祖先)である場合のみリモートに保存されます。
"fast-forward check" (早送りチェック)と呼ばれるこのチェックは、リモート
refを誤って上書きして、そこから他の人のコミットを失うことを回避するため
に実行されます。

   ‘--force’ を使用すると、すべてのrefに対して fast-forward check が無効
になります。

   オプションで、<ref> パラメーターの前に「+」記号を付けて、そのrefでの
み fast-forward check を無効にすることができます。

GIT
***

Part of the git(1) suite

Name
****

git-imap-send — 標準入力からIMAPフォルダへパッチのコレクションを送信しま
す

Synopsis
********

     git imap-send [-v] [-q] [–[no-]curl]

DESCRIPTION
***********

このコマンドは、 ‘git format-patch’ で生成されたmailboxをIMAPドラフトフ
ォルダーにアップロードします。これにより、mailboxファイルを直接読み取る
ことができないメールクライアントを使用している場合と同じように、パッチを
送信できます。このコマンドは、電子メールのフィールドが「From」、「Date」
、「Subject」の順になっている一般的なmailboxでも機能します。

   一般的な使用法は以下のようになります:

   git format-patch –signoff –stdout –attach origin | git imap-send

OPTIONS
*******

‘-v’
‘--verbose’
     にぎやかにしろや。

‘-q’
‘--quiet’
     静かにしろや。

‘--curl’
     トンネリングしない限り、libcurl を使用してIMAPサーバーと通信します
     。Gitが USE_CURL_FOR_IMAP_SEND オプションを設定せずにビルドされた場
     合は無視されます。

‘--no-curl’
     libcurl を使用する代わりに、git独自のIMAPルーチンを使用してIMAPサー
     バーと通信します。Gitが NO_OPENSSL オプションを設定してビルドされた
     場合は無視されます。

CONFIGURATION
*************

このツールを使用するには、 ‘imap.folder’ と、 ‘imap.tunnel’ または
‘imap.host’ のいずれかを、適切な値に設定する必要があります。

imap.folder
     メールをドロップするフォルダー。通常はドラフトフォルダーです。 例：
     「INBOX.Drafts」とか「INBOX/Drafts」とか「[Gmail]/Drafts」です。必
     須です。

imap.tunnel
     サーバーへの直接ネットワーク接続を使用する代わりに、コマンドがパイ
     プされるIMAPサーバーへのトンネルをセットアップするために使用される
     コマンド。 imap.host が設定されていない場合に必須です。

imap.host
     サーバーを識別するURL。 非セキュア接続には ‘imap://’ プレフィックス
     を使用し、セキュア接続には ‘imaps://’ プレフィックスを使用します。
     imap.tunnel が設定されている場合は無視されますが、それ以外の場合は
     必須です。

imap.user
     サーバーにログインするときに使用するユーザー名。

imap.pass
     サーバーにログインするときに使用するパスワード。

imap.port
     サーバー上で接続する整数のポート番号。 デフォルトは、 imap:// ホス
     トの場合は143、 imaps:// ホストの場合は993です。 imap.tunnel が設定
     されている場合は無視されます。

imap.sslverify
     SSL/TLS接続で使用されるサーバー証明書の検証を有効/無効にするブール
     値。デフォルトは ‘true’ です。 imap.tunnel が設定されている場合は無
     視されます。

imap.preformattedHTML
     パッチを送信するときにhtmlエンコーディングの使用を有効/無効にするブ
     ール値。 htmlでエンコードされたパッチは <pre> で囲まれ、コンテンツ
     タイプは text/html になります。皮肉なことに、このオプションを有効に
     すると、Thunderbirdはパッチを plane/text の format=fixed メールとし
     て送信します。デフォルトは ‘false’ です。

imap.authMethod
     IMAPサーバーでの認証の認証方法を指定します。GitがNO_CURLオプション
     を使用してビルドされた場合、curlバージョンが7.34.0より古い場合、ま
     たはgit-imap-sendを ‘--no-curl’ オプションを指定して実行している場
     合、サポートされるメソッドは _CRAM-MD5_ のみです。これが設定されて
     いない場合、「git imap-send」は基本的なIMAPプレーンテキストLOGINコ
     マンドを使用します。

EXAMPLES
********

トンネル(tunnel)モード使用:

     [imap]
         folder = "INBOX.Drafts"
         tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null"

   直接(direct)モード使用:

     [imap]
         folder = "INBOX.Drafts"
         host = imap://imap.example.com
         user = bob
         pass = p4ssw0rd

   SSLで直接モードを使用:

     [imap]
         folder = "INBOX.Drafts"
         host = imaps://imap.example.com
         user = bob
         pass = p4ssw0rd
         port = 123
         ; sslVerify = false

     *Note*

     接続の問題が、セットアップしようとしている(またはセットアップ済の
     )プライベートサーバー ‘example.com’ で使用している証明書が正しく検
     証されていないことが原因であると思われる場合、トラブルシューティン
     グ中に ‘sslVerify=false’ を使用することをお勧めします。

   GmailのIMAPインターフェースの使用:

     [imap]
             folder = "[Gmail]/Drafts"
             host = imaps://imap.gmail.com
             user = user@gmail.com
             port = 993

     *Note*

     "Folder doesn’t exist" というエラーが発生した場合は、代わりに
     ‘folder = "[Google Mail]/Drafts"’ を使用する必要があります。

     *Note*

     Gmailアカウントが英語以外の言語に設定されている場合、 "Drafts" フォ
     ルダの名前がローカライズされます。

   コミットを送信する準備ができたら、以下のコマンドを実行します:

     $ git format-patch --cover-letter -M --stdout origin/master | git imap-send

   メールクライアントで行の折り返しを無効にしてください(GmailのWebインタ
ーフェイスは何があっても行を折り返すため、実際のIMAPクライアント(real
IMAP client)を使用する必要があります)。

CAUTION
*******

電子メールプログラムによって送信される電子メールメッセージがプロジェクト
の基準を満たしていることを確認するのは、依然としてあなたの責任です。多く
のプロジェクトは、パッチを電子メールに添付することを好みません。一部のメ
ールエージェントは、パッチを失敗させる方法でパッチを変換します(たとえば
、行を折り返し、format=flowed として送信します)。これをチェックしておか
ないと、怒りの炎があなたを襲います。

   特に Thunderbird は問題があることが知られています。 Thunderbird のユ
ーザーは右記のWebページにアクセスして詳細を確認できます:
http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email
(http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email)

SEE ALSO
********

git-format-patch(1), git-send-email(1), mbox(5)

GIT
***

Part of the git(1) suite

Name
****

git-index-pack — 既存のパックされたアーカイブのパックインデックスファイ
ル構築

Synopsis
********

     git index-pack [-v] [-o <index-file>] [–[no-]rev-index] <pack-file>
     git index-pack –stdin [–fix-thin] [–keep] [-v] [-o <index-file>]
                       [–[no-]rev-index] [<pack-file>]

DESCRIPTION
***********

指定されたファイルからパックされたアーカイブ(.pack)を読み取り、そのため
のパックインデックスファイル(.idx)を作成します。オプションで、指定された
パックの逆インデックス(reverse-index)(.rev)を書き込みます。パックされた
アーカイブは、パックインデックスとともに、Gitリポジトリの objects/pack/
ディレクトリに配置できます。

OPTIONS
*******

‘-v’
     進捗状況など、何が起こっているかについて詳しく説明します。

‘-o <index-file>’
     生成されたパックインデックスを指定のファイルに書き込みます。このオ
     プションがない場合、パックインデックスファイルの名前は、 .pack を
     .idx に置き換えることにより、パックされたアーカイブファイルの名前か
     ら作成されます(パックされたアーカイブの名前が .pack で終わらない場
     合、プログラムは失敗します)。

‘--[no-]rev-index’
     このフラグが指定されている場合、指定されたパックに対応する逆インデ
     ックス(reverse index)(‘.rev’ ファイル)を生成します。 ‘--verify’ が
     指定されている場合は、既存の逆インデックスが正しいことを確認し保証
     (ensure)します。 ‘pack.writeReverseIndex’ よりも優先されます。

‘--stdin’
     このフラグが指定されると、コマンドラインの代わりにパックがstdinから
     読み取られ、コピーが <pack-file> に書き込まれます。 <pack-file> が
     指定されていない場合、パックは現在のGitリポジトリの objects/pack/ デ
     ィレクトリに書き込まれ、デフォルト名はパックの内容から決定されます
     。 <pack-file> が指定されていない場合は、 ‘--keep’ を使用して、この
     プロセスと ‘git repack’ の間の競合状態を防ぐことを検討してください
     。

‘--fix-thin’
     デルタ化オブジェクトが基づいている除外されたオブジェクトをパックに
     追加することにより、 ‘git pack-objects --thin’ によって生成された「
     薄い」パックを修正します(詳細は git-pack-objects(1) を参照)。 この
     オプションは、‘--stdin’ と組み合わせた場合にのみ意味があります。

‘--keep’
     インデックスを最終的な宛先に移動する前に、関連するパックファイル用
     に空の .keep ファイルを作成します。このオプションは通常、 ‘--stdin’
     と一緒に指定する必要があります。これは、パックに含まれるオブジェク
     トを使用するようにrefを更新する前に、 ‘git repack’ プロセスが新しく
     構築されたパックとインデックスを同時に削除しないようにするためです
     。

‘--keep=<msg>’
     ‘--keep’ のように、インデックスを最終的な宛先に移動する前に .keep フ
     ァイルを作成しますが、空のファイルを作成するのではなく、 .keep ファ
     イル内で <msg> の後にLFを配置します。 後ですべての .keep ファイル内
     で <msg> メッセージを検索して、使い古されたものを見つけることができ
     ます。

‘--index-version=<version>[,<offset>]’
     これは、テストスイートでのみ使用することを目的としています。 生成さ
     れたパックインデックスのバージョンを強制し、指定されたオフセットに
     あるオブジェクトに64ビットインデックスエントリを強制することができ
     ます。

‘--strict’
     パックに壊れたオブジェクトやリンクが含まれている場合は、終了します
     (die)。

‘--progress-title’
     内部使用のみ。

     プログレスバーのタイトルを設定します。 タイトルはデフォルトで「
     Receiving objects」(オブジェクトの受信)であり、 ‘--stdin’ が指定さ
     れている場合は「Indexing objects」(オブジェクトのインデックス作成
     )です。

‘--check-self-contained-and-connected’
     パックに壊れたリンクが含まれている場合は終了(die)します。内部使用の
     み。

‘--fsck-objects’
     内部使用のみ。

     パックに壊れたオブジェクトが含まれている場合は終了(die)します。 存
     在しない .gitmodulesblob を指すツリーがパックに含まれている場合、
     pack/idx ファイルの名前に含まれるハッシュの後に、(呼び出し元が確認
     できるように)そのブロブのハッシュを出力します(「Notes」参照)。

‘--threads=<n>’
     デルタを解決するときに生成するスレッドの数を指定します。これには、
     インデックスパックを pthreads でコンパイルする必要があります。そう
     でない場合、このオプションは警告とともに無視されます。これは、マル
     チプロセッサマシンでのパッキング時間を短縮することを目的としていま
     す。ただし、デルタ検索ウィンドウに必要なメモリ量は、スレッド数で乗
     算されます。0を指定すると、GitはCPUの数を自動検出し、最大3つのスレ
     ッドを使用します。

‘--max-input-size=<size>’
     パックが <size> を超える場合は、終了(die)します。

‘--object-format=<hash-algorithm>’
     パックに指定するオブジェクト形式(ハッシュアルゴリズム)を指定します
     。有効な値は ‘sha1’ と ‘sha256’ (有効な場合) です。デフォルトは、
     (‘extensions.objectFormat’ で設定する、)現在のリポジトリのアルゴリ
     ズム、または値が設定されていないかリポジトリの外部にある場合は
     _sha1_ です。

     このオプションは ‘--stdin’ オプションと一緒に使用することはできませ
     ん。

     このオプションは実験的なものです！ SHA-256のサポートは実験的なもの
     であり、まだ初期段階です。 SHA-256リポジトリは、通常、「通常の」
     SHA-1リポジトリと作業を共有できません。 たとえば、SHA-256リポジトリ
     に関連するGit内部ファイル形式は、下位互換性のない方法で変更される可
     能性があると想定する必要があります。テスト目的でのみ
     ‘--object-format=sha256’ を使用してください。

NOTES
*****

一旦インデックスが作成されると、 pack/idx ファイルの名前に含まれるハッシ
ュがstdoutに出力されます。 ‘--stdin’ も使用された場合、これには ‘pack\t’
または新しい.keepファイルが正常に作成された場合は ‘keep\t’ のいずれかの
プレフィックスが付きます。 .これは、上記の ‘git repack’ との競合を防ぐた
めにロックとして使用されているkeepファイルを 削除するのに役立ちます。

GIT
***

Part of the git(1) suite

Name
****

git-init-db — 空のGitリポジトリを作成

Synopsis
********

     git init-db [-q | –quiet] [–bare] [–template=<template_directory>] [–separate-git-dir <git dir>] [–shared[=<permissions>]]

DESCRIPTION
***********

これは git-init(1) の同義語です。 git-init(1) コマンドの文書を参照してく
ださい。

GIT
***

Part of the git(1) suite

Name
****

git-init — 空のGitリポジトリを作成するか、既存のリポジトリを再初期化しま
す

Synopsis
********

     git init [-q | –quiet] [–bare] [–template=<template_directory>]
               [–separate-git-dir <git dir>] [–object-format=<format>]
               [-b <branch-name> | –initial-branch=<branch-name>]
               [–shared[=<permissions>]] [directory]

DESCRIPTION
***********

このコマンドは、空のGitリポジトリを作成します。基本的には、 ‘objects’ と
‘refs/heads’ と ‘refs/tags’ と テンプレートファイルのためのサブディレク
トリを持つ ‘.git’ ディレクトリです。コミットのない初期ブランチが作成され
ます(初期ブランチの名前については、以下の ‘--initial-branch’ オプション
を参照してください)。

   ‘$GIT_DIR’ 環境変数が設定されている場合、リポジトリのベースに
‘./.git’ の代わりに、 ‘$GIT_DIR’ で指定されたパスを使います。

   オブジェクトストレージディレクトリが ‘$GIT_OBJECT_DIRECTORY’ 環境変数
を介して指定されている場合、sha1ディレクトリがその下に作成されます。それ
以外の場合は、デフォルトの ‘$GIT_DIR/objects’ ディレクトリが使用されます
。

   既存のリポジトリで「git init」を実行しても安全です。すでに存在するも
のを上書きすることはありません。「git init」を再実行する主な理由は、新し
く追加されたテンプレートを取得することです(または、 ‘--separate-git-dir’
が指定されている場合はリポジトリを別の場所に移動します)。

OPTIONS
*******

‘-q’
‘--quiet’
     エラーメッセージと警告メッセージのみを出力します。 他のすべての出力
     は抑制されます。

‘--bare’
     ベア(bare)リポジトリを作成します。 ‘GIT_DIR’ 環境変数が設定されてい
     ない場合は、現在の作業ディレクトリに設定されます。

‘--object-format=<format>’
     リポジトリに設定するブジェクト形式(ハッシュアルゴリズム)を指定しま
     す。 有効な値は「sha1」および、(有効な場合、)「sha256」です。「
     sha1」がデフォルトです。

     このオプションは実験的なものです！ SHA-256のサポートは実験的なもの
     であり、まだ初期段階です。 SHA-256リポジトリは、通常、「通常の」
     SHA-1リポジトリと作業を共有できません。 たとえば、SHA-256リポジトリ
     に関連するGit内部ファイル形式は、下位互換性のない方法で変更される可
     能性があると想定する必要があります。テスト目的でのみ
     ‘--object-format=sha256’ を使用してください。

‘--template=<template_directory>’
     テンプレートが使用するディレクトリを指定します。 (以下の「TEMPLATE
     DIRECTORY」セクションを参照してください。)

‘--separate-git-dir=<git dir>’
     リポジトリをディレクトリとして ‘$GIT_DIR’ または ‘./.git/’ に初期化
     する代わりに、実際のリポジトリへのパスを含むテキストファイルをそこ
     に作成します。 このファイルは、ファイルシステムに依存しない、リポジ
     トリへのGitシンボリックリンクとして機能します。

     これが再初期化の場合、リポジトリは指定されたパスに移動されます。

‘-b <branch-name>’
‘--initial-branch=<branch-name>’
     新しく作成されたリポジトリの最初のブランチには、指定された名前を使
     用します。 指定しない場合は、デフォルト名にフォールバックします(現
     在は ‘master’ ですが、将来変更される可能性があります。名前は
     ‘init.defaultBranch’ 構成変数を使用してカスタマイズできます)。

‘--shared[=(false|true|umask|group|all|world|everybody|0xxx)]’
     Gitリポジトリを複数のユーザー間で共有することを指定します。 これに
     より、同じグループに属するユーザーがそのリポジトリにプッシュできる
     ようになります。 指定すると、構成変数 ‘core.sharedRepository’ が設
     定され、 ‘$GIT_DIR’ の下のファイルとディレクトリが要求された権限で
     作成されます。 指定しない場合、Gitは umask(2) によって報告された権
     限を使用します。

     オプションには以下の値を指定できます。値が指定されていない場合、デ
     フォルトで ‘group’ になります。

     ‘umask’ (or ‘false’)
          umask(2) によって報告されたアクセス許可を使用します。
          ‘--shared’ が指定されていない場合のデフォルトです。

     ‘group’ (or ‘true’)
          リポジトリをグループ書き込み可能にします(gitグループがすべての
          ユーザーのプライマリグループではない可能性があるため、 ‘g+sx’
          )。 これは、そうしないでいれば安全な umask(2) 値の権限を緩める
          ために使用されます。 注意: umaskは他の権限ビットにも適用される
          ことに注意してください(たとえば、umaskが ‘0022’ の場合、
          ‘group’ を使用しても他の(グループ以外の)ユーザーからの読み取り
          権限は削除されません)。 リポジトリの権限を正確に指定する方法に
          ついては、 ‘0xxx’ を参照してください。

     ‘all’ (または ‘world’ または ‘everybody’)
          ‘group’ と同じですが、すべてのユーザーからリポジトリを読めるよ
          うにします。

     ‘0xxx’
          ‘0xxx’ は8進数で、各ファイルのモードは ‘0xxx’ になります。
          ‘0xxx’ はユーザーのumask(2) 値をオーバーライドします(‘group’ や
          ‘all’ のように権限を緩めるだけではありません)。 ‘0640’ ならば
          、グループで読み取り可能であるが、グループで書き込み可能または
          他のユーザーがアクセスできないリポジトリを作成します。 ‘0660’
          ならば、現在のユーザーとグループには読み取りと書き込みが可能で
          すが、他のユーザーにはアクセスできないリポジトリを作成します。

   デフォルトでは、共有リポジトリ内で、構成フラグ
‘receive.denyNonFastForwards’ が有効(ture)になっているため、早送り
(fast-forward)以外のプッシュを強制することはできません。

   directory(ディレクトリ)を指定すると、コマンドはその内部で実行されます
。指定のディレクトリが存在しない場合は、作成されます。

TEMPLATE DIRECTORY
******************

名前がドット(‘.’)で始まらないテンプレートディレクトリ内のファイルとディ
レクトリは、作成後に ‘$GIT_DIR’ にコピーされます。

   テンプレートディレクトリは、以下のいずれかになります(この優先順位です
):

   • ‘--template’ オプションで指定された引数

   • ‘$GIT_TEMPLATE_DIR’ 環境変数の内容

   • ‘init.templateDir’ 構成変数

   • デフォルトのテンプレートディレクトリ:
     ‘/usr/share/git-core/templates’

   デフォルトのテンプレートディレクトリには、いくつかのディレクトリ構造
、推奨される「除外パターン」(exclude patterns)(gitignore(5) 参照)、およ
びサンプルフックファイルが含まれています。

   サンプルフックはデフォルトですべて無効になっています。 サンプルフック
を有効にするには、 ‘.sample’ サフィックスを削除して名前を変更します。

   フックの実行に関するより一般的な情報については、 githooks(5) を参照し
てください。

EXAMPLES
********

既存のコードベースの新しいGitリポジトリを開始します
          $ cd /path/to/my/codebase
          $ git init      (1)
          $ git add .     (2)
          $ git commit    (3)

     See (1).
          /path/to/my/codebase/.git ディレクトリを作成します。

     See (2).
          既存のすべてのファイルをインデックスに追加します。

     See (3).
          履歴の最初のコミットとして、初期の状態を記録します。

GIT
***

Part of the git(1) suite

Name
****

git-instaweb — gitwebで作業リポジトリをインスタントにブラウズします

Synopsis
********

     git instaweb [–local] [–httpd=<httpd>] [–port=<port>]
                    [–browser=<browser>]
     git instaweb [–start] [–stop] [–restart]

DESCRIPTION
***********

ローカルリポジトリを参照するための ‘gitweb’ とWebサーバーを設定するため
の簡単なスクリプト。

OPTIONS
*******

‘-l’
‘--local’
     WebサーバーをローカルIP(127.0.0.1)にのみバインドします。

‘-d’
‘--httpd’
     実行されるHTTPデーモンのコマンドライン。コマンドラインオプションは
     ここで指定でき、構成ファイルはコマンドラインの最後に追加されます。
     現在、apache2、lighttpd、mongoose、plackup、python、webrickがサポー
     トされています。（デフォルト：lighttpd）

‘-m’
‘--module-path’
     モジュールパス(httpdがApacheの場合にのみ必要)。(デフォルト:
     /usr/lib/apache2/modules )

‘-p’
‘--port’
     httpdをバインドするポート番号。(デフォルト: 1234)

‘-b’
‘--browser’
     gitwebページを表示するために使用する必要があるWebブラウザー。これは
     、gitwebインスタンスのURLとともに _git web–browse_ ヘルパースクリプ
     トに渡されます。詳細については、 git-web–browse(1) を参照してくださ
     い。スクリプトが失敗した場合、URLはstdoutに出力されます。

start
‘--start’
     httpdインスタンスを開始して本コマンドを終了します。新しいインスタン
     スを生成するために、必要に応じて構成ファイルを再生成します。

stop
‘--stop’
     httpdインスタンスを停止して本コマンドを終了します。これにより、新し
     いインスタンスを生成するための構成ファイルが生成されたり、ブラウザ
     ーが閉じられたりすることはありません。

restart
‘--restart’
     httpdインスタンスを再起動して本コマンドを終了します。 新しいインス
     タンスを生成するために、必要に応じて構成ファイルを再生成します。

CONFIGURATION
*************

あなたは .git/config で構成を指定できます

     [instaweb]
             local = true
             httpd = apache2 -f
             port = 4321
             browser = konqueror
             modulePath = /usr/lib/apache2/modules

   構成変数 ‘instaweb.browser’ が設定されていない場合に、‘web.browser’ が
定義されていれば、代わりに ‘web.browser’ が使用されます。詳細については
、 git-web–browse(1) を参照してください。

SEE ALSO
********

gitweb(1)

GIT
***

Part of the git(1) suite

Name
****

git-interpret-trailers — コミットメッセージの構造化情報を追加またはパー
スします

Synopsis
********

     git interpret-trailers [<options>] [(–trailer <token>[(=|:)<value>])…] [<file>…]
     git interpret-trailers [<options>] [–parse] [<file>…]

DESCRIPTION
***********

コミットメッセージの自由形式の部分の最後に、RFC 822 電子メールヘッダーに
似たトレーラー(trailer)行の、追加またはパースを支援します。

   このコマンドは、<file> 引数または、 <file>が指定されていない場合は標
準入力のいずれかから、いくつかのパッチまたはコミットメッセージを読み取り
ます。 ‘--parse’ が指定されている場合、出力はパースされたトレーラーで構
成されます。

   それ以外の場合、このコマンドは、 ‘--trailer’ オプション(存在する場合
)を使用して渡された引数を、各入力ファイルのコミットメッセージ部分に適用
します。結果は標準出力に出力されます。

   一部の構成変数は、 ‘--trailer’ 引数が各コミットメッセージに適用される
方法と、コミットメッセージ内の既存のトレーラーが変更される方法を制御しま
す。また、トレーラーを自動的に追加することもできます。

   デフォルトでは、 ‘--trailer’ で指定された _<token>=<value>_ または
_<token>:<value>_ 引数は、既存の最後のトレーラーのペア(<token>,
<value>)が指定のペア異なる場合(または、既存のに無い場合)にのみ、指定した
モノが既存のトレーラーの後に追加されます。 <token>と<value>の部分は、先
頭と末尾の空白がトリミングされ、以下のようなメッセージとして出力されます
:

     token: value

   これは、トリミングされた<token>と<value>が ‘: ‘ (1つのコロンとそれに
続く1つのスペース)で区切られることを意味します。

   デフォルトでは、新しいトレーラーは既存のすべてのトレーラーの後に出力
されます。既存のトレーラーがない場合は、出力のコミットメッセージ部分の後
に新しいトレーラーが出力されます。コミットメッセージ部分の最後に空白しか
ない行が存在しない場合は、新しいトレーラーの前に空行を1行追加します。

   既存のトレーラーは、(i)すべてのトレーラーであるか、または、(ii)少なく
とも1つのGit生成またはユーザー構成のトレーラーを含む少なくとも25％のトレ
ーラーで構成される、1行以上のグループが入力メッセージから抽出されます。
グループの前には、1行以上の空行(または空白のみの行)が必要です。グループ
は、メッセージの最後にあるか、 ‘---’ で始まる行の前の最後の非空白行であ
る必要があります(その後にスペースまたは行の終わりが続きます)。このような
3つのマイナス記号(‘---’)は、メッセージのパッチ部分を開始します。 以下の
‘--no-divider’ も参照してください。

   トレーラーを読み取る場合、トークンと区切り文字と値の後に空白
(whitespaces)を含めることができます。トークンと値の中に空白を含めること
もできます。値は、RFC 822の "folding"(折りたたみ)のように、空白で始まる
後続の各行で複数の行に分割される場合があります。

   注意: トレーラーはRFC822ヘッダー規則の多くに従うことを意図してません
し、従わないことに注意してください。たとえば、それらはエンコーディング規
則や、おそらく他の多くの規則に従いません。

OPTIONS
*******

‘--in-place’
     その場でファイルを編集します。

‘--trim-empty’
     トレーラーの <value> 部分に空白(whitespace)のみが含まれている場合、
     結果のメッセージからトレーラー全体が削除されます。これは、新しいト
     レーラーだけでなく、既存のトレーラーにも適用されます。

‘--trailer <token>[(=|:)<value>]’
     入力メッセージのトレーラーとして適用する必要があるペア（<token>、
     <value>）を指定します。詳しくはこのコマンドの説明を参照してください
     。

‘--where <placement>’
‘--no-where’
     すべての新しいトレーラーが追加される場所を指定します。 ‘--where’ で
     指定する設定は、すべての構成変数をオーバーライドし、 _–where_ また
     は _–no-where_ が次に出現するまですべての ‘--trailer’ オプションに
     適用されます。 <placement> として可能な値は、 ‘after’ または
     ‘before’ または ‘end’ または ‘start’ です。

‘--if-exists <action>’
‘--no-if-exists’
     メッセージに同じ <token> を持つトレーラーがすでに少なくとも1つある
     場合に、実行される操作を指定します。 ‘--if-exists’ で指定する設定は
     、すべての構成変数をオーバーライドし、 ‘--if-exists’ または
     ‘--no-if-exists’ が次に出現するまですべての ‘--trailer’ オプション
     に適用されます。可能な操作は、 ‘addIfDifferent’ または
     ‘addIfDifferentNeighbor’ または ‘add’ または ‘replace’ または
     ‘doNothing’ です。

‘--if-missing <action>’
‘--no-if-missing’
     メッセージに同じ <token> を持つ他のトレーラーがない場合に実行される
     操作を指定します。 ‘--if-missing’ で指定する設定は、すべての構成変
     数をオーバーライドし、 ‘--if-missing’ または ‘--no-if-missing’ が次
     に出現するまですべての ‘--trailer’ オプションに適用されます。可能な
     操作は ‘doNothing’ または ‘add’ です。

‘--only-trailers’
     トレーラーのみを出力し、入力の他の部分は出力しません。

‘--only-input’
     入力に存在するトレーラーのみを出力します。コマンドラインや、構成さ
     れた ‘trailer.*’ ルールに従って追加することはありません。

‘--unfold’
     トレーラーの複数行に渡る先頭空白による継続を解除して、各トレーラー
     が1行で完結するよう出力します。

‘--parse’
     ‘--only-trailers --only-input --unfold’ の便利なエイリアス。

‘--no-divider’
     ‘---’ をコミットメッセージの終わりとして扱わないでください。(電子メ
     ールや ‘git format-patch‘の出力が含まれておらず、)入力にコミットメ
     ッセージ自体だけが含まれていることがわかっている場合にこれを使用し
     ます。

CONFIGURATION VARIABLES
***********************

trailer.separators
     このオプションは、どの文字がトレーラー区切り文字として認識されるか
     を示します。 デフォルトでは、 ‘:’ のみがトレーラー区切り文字として
     認識されます。ただし、他のgitコマンドとの互換性のために、コマンドラ
     インでは ‘=’ が常に受け入れられます。

     このオプションで指定された最初の1文字は、このトレーラーの構成で別の
     区切り文字が指定されていない場合に使用されるデフォルトの文字になり
     ます。

     たとえば、このオプションの値が "%=$" の場合、 _<token><sep><value>_
     の形式を使用し、<sep> に ‘%’ または ‘=’ または ‘$’ と、空白達を含む
     行のみトレーラーと見なされます。 また、 ‘%’ がデフォルトの区切り文
     字として使用されるため、デフォルトでは、トレーラーは ‘<token>%
     <value>’ と出力されます(デフォルトの場合はこのようにトークンと値の
     間に1つの区切り文字列の最初の文字(パーセント記号)と「1つのスペース
     」が出力されます)。

trailer.where
     このオプションは、新しいトレーラーが追加される場所を示します。

     これは、デフォルトの ‘end’ の他に ‘start’ または ‘after’ または
     ‘before’ にすることができます。

     ‘end’ の場合、新しいトレーラーはそれぞれ、既存のトレーラーの最後に
     出力されます。

     ‘start’ の場合、新しい各トレーラーは、既存のトレーラーの最後ではな
     く、最初に出力されます。

     ‘after’ の場合、新しいトレーラーはそれぞれ、同じ <token> を持つ最後
     のトレーラーの直後に出力されます。

     ‘before’ の場合、新しい各トレーラーは、同じ <token> を持つ最初のト
     レーラーの直前に出力されます。

trailer.ifexists
     このオプションを使用すると、メッセージに同じ <token> を持つトレーラ
     ーがすでに少なくとも1つある場合に、実行する操作を選択できます。

     このオプションの有効な値は、 ‘addIfDifferentNeighbor’ (デフォルト
     )、 または ‘addIfDifferent’ または ‘add’ または ‘replace’ または
     ‘doNothing’ です。

     ‘addIfDifferentNeighbor’ を使用すると、同一のペア(<token>、
     <value>)のトレーラーが、新しいトレーラーが追加される行の上または下
     にない場合にのみ、新しいトレーラーが追加されます。

     ‘addIfDifferent’ を使用すると、同じペア(<token>、<value>)のトレーラ
     ーがメッセージに含まれていない場合にのみ、新しいトレーラーが追加さ
     れます。

     ‘add’ を使用すると、同じペア（<token>、<value>）のトレーラーがすで
     にメッセージに含まれている場合でも、新しいトレーラーが追加されます
     。

     ‘replace’ を使用すると、同じ <token> を持つ既存のトレーラーが削除さ
     れ、新しいトレーラーが追加されます。削除されるトレーラーは、新しい
     トレーラーが追加される場所に最も近い(同じ <token> を持つ)トレーラー
     になります。

     ‘doNothing’ を使用すると、何も実行されません。 つまり、メッセージに
     同じ <token> を持つトレーラーがすでに存在する場合、新しいトレーラー
     は追加されません。

trailer.ifmissing
     このオプションを使用すると、メッセージに同じ <token> を持つトレーラ
     ーがまだない場合に実行する操作を選択できます。

     このオプションの有効な値は、 ‘add’ (デフォルト)と ‘doNothing’ です
     。

     ‘add‘を使用すると、新しいトレーラーが追加されます。

     ‘doNothing’ を使用すると、何も実行されません。

trailer.<token>.key
     この キー(key) は、トレーラーで <token> の代わりに使用されます。こ
     のキーの後ろに、区切り文字を出力してから、いくつかのスペース文字を
     出力できます。デフォルトでは、有効な区切り文字は ‘:’ のみですが、こ
     れは ‘trailer.separators’ 構成変数を使用して変更できます。

     トレーラーを追加するときに、この構成値内に区切り文字がある場合、
     <token> とデフォルトの区切り文字の両方(つまり、<token><区切り文字
     ><空白1つ>)がキーで置き換えられます。

trailer.<token>.where
     このオプションは、「trailer.where」構成変数と同じ値を取り、指定され
     た <token> を持つトレーラーに対してそのオプションで指定されたものを
     オーバーライドします。

trailer.<token>.ifexists
     このオプションは、「trailer.ifexists」構成変数と同じ値を取り、指定
     された <token> を持つトレーラーに対してそのオプションで指定されたも
     のをオーバーライドします。

trailer.<token>.ifmissing
     このオプションは、「trailer.ifmissing」構成変数と同じ値を取り、指定
     された <token> を持つトレーラーに対してそのオプションで指定されたも
     のをオーバーライドします。

trailer.<token>.command
     このオプションは、指定のコマンドに引数として何も渡さないことを除い
     て、 ‘trailer.<token>.cmd’ と同じように動作します。代わりに、文字列
     に最初に現れる置換文字列 $ARG のみ、引数として渡される値に置き換え
     られます。

     _trailer.<token>.command_ オプションは非推奨になり
     ’trailer.<token>.cmd’ が採用されました。これは、ユーザーのコマンド
     の $ARG が一度だけ置き換えられることと、 $ARG を置き換える独創的な
     方法が安全でないためです。

     _trailer.<token>.cmd_ と _trailer.<token>.command_ の両方が同じ
     <token>で指定されている場合、 _trailer.<token>.cmd_ が使用され、
     _trailer.<token>.command_ は無視されます。

trailer.<token>.cmd
     このオプションを使用して、呼び出されるシェルコマンドを指定できます
     。最初の1回は、指定の <token> を持つトレーラーを自動的に追加し、そ
     の後、毎回 _–trailer <token>=<value>_ 引数を使用して、このオプショ
     ンが生成するトレーラーの <value> を変更します。

     指定のコマンドを最初に呼び出して、指定の <token> のトレーラーを追加
     すると、動作は、「git interpret-trailers」コマンドの先頭に特別な
     ‘--trailer <token>=<value>’ 引数が追加されたかのように振る舞います
     。ここで、 <value> は、先頭と末尾の空白が削除された、コマンドからの
     標準出力と見なされます。

     いくつかの ‘--trailer <token>=<value>' 引数がコマンドラインで渡され
     た場合、同じ <token> を持つこれらの引数ごとにコマンドが1回呼び出さ
     れます。そして、これらの引数の <value> 部分は、もしあれば、最初の引
     数としてコマンドに渡されます。このようにして、コマンドは `--trailer
     <token>=<value>’ 引数で渡された <value> から計算された <value> を生
     成できます。

EXAMPLES
********

   • 「Signed-off-by」キーを使用して「sign」トレーラーを構成してから、こ
     れらのトレーラーのうち2つをメッセージに追加します:

          $ git config trailer.sign.key "Signed-off-by"
          $ cat msg.txt
          subject

          message
          $ cat msg.txt | git interpret-trailers --trailer 'sign: Alice <alice@example.com>' --trailer 'sign: Bob <bob@example.com>'
          subject

          message

          Signed-off-by: Alice <alice@example.com>
          Signed-off-by: Bob <bob@example.com>

   • ‘--in-place’ オプションを使用して、メッセージファイルをその場で編集
     します:

          $ cat msg.txt
          subject

          message

          Signed-off-by: Bob <bob@example.com>
          $ git interpret-trailers --trailer 'Acked-by: Alice <alice@example.com>' --in-place msg.txt
          $ cat msg.txt
          subject

          message

          Signed-off-by: Bob <bob@example.com>
          Acked-by: Alice <alice@example.com>

   • 最後のコミットをパッチとして抽出し、それに「Cc」トレーラーと「
     Reviewed-by」トレーラーを追加します:

          $ git format-patch -1
          0001-foo.patch
          $ git interpret-trailers --trailer 'Cc: Alice <alice@example.com>' --trailer 'Reviewed-by: Bob <bob@example.com>' 0001-foo.patch >0001-bar.patch

   • 「Signed-off-by: 」がまだない場合にのみ、作者情報を含む「
     Signed-off-by: 」を自動的に追加するコマンドを伴って「sign」トレーラ
     ーを構成し、それがどのように機能するかを示します:

          $ git config trailer.sign.key "Signed-off-by: "
          $ git config trailer.sign.ifmissing add
          $ git config trailer.sign.ifexists doNothing
          $ git config trailer.sign.command 'echo "$(git config user.name) <$(git config user.email)>"'
          $ git interpret-trailers <<EOF
          > EOF

          Signed-off-by: Bob <bob@example.com>
          $ git interpret-trailers <<EOF
          > Signed-off-by: Alice <alice@example.com>
          > EOF

          Signed-off-by: Alice <alice@example.com>

   • trailer.fix.key に 区切り文字 ‘#’ を含み、その後ろにスペースを含ま
     ないキーを使用して「fix」トレーラーを構成し、それがどのように機能す
     るかを示します:

          $ git config trailer.separators ":#"
          $ git config trailer.fix.key "Fix #"
          $ echo "subject" | git interpret-trailers --trailer fix=42
          subject

          Fix #42

   • cmdを使用して「ヘルプ」トレーラーを構成します。スクリプト
     ‘glog-find-author’ を使用して、gitリポジトリのgitログから指定された
     作成者IDを検索し、その動作を示します。

          $ cat ~/bin/glog-find-author
          #!/bin/sh
          test -n "$1" && git log --author="$1" --pretty="%an <%ae>" -1 || true
          $ git config trailer.help.key "Helped-by: "
          $ git config trailer.help.ifExists "addIfDifferentNeighbor"
          $ git config trailer.help.cmd "~/bin/glog-find-author"
          $ git interpret-trailers --trailer="help:Junio" --trailer="help:Couder" <<EOF
          > subject
          >
          > message
          >
          > EOF
          subject

          message

          Helped-by: Junio C Hamano <gitster@pobox.com>
          Helped-by: Christian Couder <christian.couder@gmail.com>

   • cmdを使用して _ref_ トレーラーを構成し、スクリプト ‘glog-grep’ を使
     用して、gitリポジトリのgitログから最後の関連するコミットをgrepし、
     それがどのように機能するかを示します。

          $ cat ~/bin/glog-grep
          #!/bin/sh
          test -n "$1" && git log --grep "$1" --pretty=reference -1 || true
          $ git config trailer.ref.key "Reference-to: "
          $ git config trailer.ref.ifExists "replace"
          $ git config trailer.ref.cmd "~/bin/glog-grep"
          $ git interpret-trailers --trailer="ref:Add copyright notices." <<EOF
          > subject
          >
          > message
          >
          > EOF
          subject

          message

          Reference-to: 8bc9a0c769 (Add copyright notices., 2005-04-07)

   • 関連するコミットの件名を出力し、それがどのように機能するかを示すコ
     マンドを使用して、「see」トレーラーを構成します:

          $ git config trailer.see.key "See-also: "
          $ git config trailer.see.ifExists "replace"
          $ git config trailer.see.ifMissing "doNothing"
          $ git config trailer.see.command "git log -1 --oneline --format=\"%h (%s)\" --abbrev-commit --abbrev=14 \$ARG"
          $ git interpret-trailers <<EOF
          > subject
          >
          > message
          >
          > see: HEAD~2
          > EOF
          subject

          message

          See-also: fe3187489d69c4 (subject of related commit)

   • 空の値を持ついくつかのトレーラーを使用してコミットテンプレートを構
     成し(sedを使用してトレーラーの後に末尾のスペースを出力および保持し
     ます)、次に、「git interpret-trailers」を使用するcommit-msgフックを
     構成して、値が空のトレーラーを削除し、「git-version」トレーラーを追
     加します:

          $ sed -e 's/ Z$/ /' >commit_template.txt <<EOF
          > ***subject***
          >
          > ***message***
          >
          > Fixes: Z
          > Cc: Z
          > Reviewed-by: Z
          > Signed-off-by: Z
          > EOF
          $ git config commit.template commit_template.txt
          $ cat >.git/hooks/commit-msg <<EOF
          > #!/bin/sh
          > git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new"
          > mv "\$1.new" "\$1"
          > EOF
          $ chmod +x .git/hooks/commit-msg

SEE ALSO
********

git-commit(1), git-format-patch(1), git-config(1)

GIT
***

Part of the git(1) suite

Name
****

git-log — コミットのログを表示

Synopsis
********

     git log [<options>] [<revision range>] [[–] <path>…]

DESCRIPTION
***********

コミットのログを表示します。

   指定されたコミットから「親」リンクをたどることによって到達可能なコミ
ットをリストしますが、その前に ^ が付いているコミットから到達可能なコミ
ットは除外します。デフォルトでは、出力は時系列の逆順で表示されます。

   これは集合演算と考えることができます。 コマンドラインで指定されたコミ
ットのいずれかから到達可能なコミットのセットを形成し、 ^ が前に付いたコ
ミットのいずれかから到達可能なコミットがそのセットから差し引かれます。差
し引かれた残りのコミットは、コマンドの出力に出力されるものです。他のさま
ざまなオプションとパスパラメータ(pats parameters)を使用して、結果をさら
に制限できます。

   したがって、以下のコマンド:

     $ git log foo bar ^baz

   は、「foo または bar から到達可能であるが、 baz からは到達できないす
べてのコミットをリストする」を意味します。

   特別な表記 ‘<commit1>..<commit2>’ は、 ‘^<commit1> <commit2>’ の省略
形として使用できます。たとえば、以下のどちらかを同じ意味で使用できます:

     $ git log origin..HEAD
     $ git log HEAD ^origin

   もう1つの特別な表記法は、マージに役立つ ‘<commit1>...<commit2>’ です
。結果として得られるコミットのセットは、2つのオペランド間の対称差
(symmetric difference)です。以下の2つのコマンドは同等です:

     $ git log A B --not $(git merge-base --all A B)
     $ git log A...B

   このコマンドは、 git-rev-list(1) コマンドに適用可能なオプションを使用
して、表示内容と方法を制御し、そして git-diff(1) コマンドに適用可能なオ
プションを使用して、各コミットによって導入される変更の表示方法を制御しま
す。

OPTIONS
*******

‘--follow’
     ファイル名が途中でリネームされていてもそこで中断することなく、その
     ファイルの一覧を続けて表示します(単一のファイルに対してのみ機能しま
     す)。

‘--no-decorate’
‘--decorate[=short|full|auto|no]’
     表示されているコミットのref名を出力します。 short が指定されている
     場合、ref名の接頭辞 refs/heads/ と refs/tags/ と refs/remotes/ は出
     力されません。 full が指定されている場合、完全なref名(接頭辞を含む
     )が出力されます。 auto が指定されている場合、出力が端末に送られると
     、ref名は short が指定されているかのように表示され、それ以外の場合
     はref名は表示されません。オプション ‘--decorate’ は
     ‘--decorate=short’ の省略形です。構成されている場合はデフォルトで構
     成値の ‘log.decorate’ になり、構成されていない場合は ‘auto’ になり
     ます。

‘--decorate-refs=<pattern>’
‘--decorate-refs-exclude=<pattern>’
     ‘--decorate-refs’ が指定されていない場合は、すべてのrefが含まれてい
     るように見せかけます。候補ごとに、‘--decorate-refs-exclude’ に指定
     されたパターンのいずれにもマッチしない場合、または
     ‘--decorate-refs’ に指定されたパターンのいずれにもマッチしない場合
     は、装飾に使用しないでください。 ‘log.excludeDecoration’ 構成オプシ
     ョンを使用すると、装飾からrefを除外できますが、明示的な
     ‘--decorate-refs’ パターンは ‘log.excludeDecoration’ のマッチングを
     オーバーライドします。

‘--source’
     各コミットがコマンドラインで指定のコミットのいずれかから到達できる
     祖先である場合、当該コミット毎にコマンドラインで指定のコミットの
     ref名で表示します。

‘--[no-]mailmap’
‘--[no-]use-mailmap’
     mailmapファイルを使用して、作者名(author names)とコミッター名
     (committer names)と電子メールアドレス(email addresses)を、正式な本
     名と電子メールアドレスにマップします。 git-shortlog(1) 参照。

‘--full-diff’
     このフラグがない場合、 ‘git log -p <path>...’ は、指定されたパスに
     関連(touch)するコミットを示し、その指定されたパスについての差分を取
     ります。これにより、指定されたパスに関連するコミットの完全な差分が
     表示されます。これは、 "<path>…" がコミットのみを制限し、それらのコ
     ミットの差分を制限しないことを意味します。

     これは、例えば ‘--stat’ によって生成されたものなど、すべての差分ベ
     ースの出力タイプに影響することに注意してください。

‘--log-size’
     各コミットの出力に “log size <number>” という行を含めます。ここで、
     <number> はそのコミットのメッセージの長さ(バイト単位)です。プログラ
     ムがスペースをコミットのメッセージ読み込み前に割り当てられるように
     して、 ‘git log’ 出力からログメッセージを読み取るツールを高速化する
     ことを目的としています。

‘-L<start>,<end>:<file>’
‘-L:<funcname>:<file>’
     <file> 内で、 ‘<start>,<end>’ 、または正規表現の関数名 <funcname> で
     指定された行範囲をトレースします。pathspec リミッターを指定すること
     はできません。これは現在、単一のリビジョンから開始するウォークに制
     限されています。つまり、0個または1個の正のリビジョン引数のみを指定
     でき、 <start> と <end> (または <funcname>) が開始リビジョンに存在
     する必要があります。このオプションは複数回指定できます。これは
     ‘--patch’ オプションの機能を含んでいます。パッチ出力は ‘--no-patch’
     を使用して抑制できますが、他の差分形式(つまり、 ‘--raw’,
     ‘--numstat’, ‘--shortstat’, ‘--dirstat’, ‘--summary’,
     ‘--name-only’, ‘--name-status’, ‘--check’)は現在実装されていません
     。

     <start> と <end> は、以下のいずれかの形式です:

        • 数値

          <start> または <end> が数値の場合、絶対行番号を指定します(行は
          1から数えます)。

        • ‘/regex/’

          この形式は、指定されたPOSIX正規表現に一致する最初の行を使用し
          ます。 <start> が正規表現の場合、前の ‘-L’ 範囲の末尾から検索
          します。それ以外の場合は、ファイルの先頭から検索します。
          <start> が ‘^/regex/’ の場合、ファイルの先頭から検索します。
          <end> が正規表現の場合、 <start> で指定された行から検索開始し
          ます。

        • +offset or -offset

          これは <end> に対してのみ有効であり、 <start> で指定された行の
          前後の行数を指定します。

     <start> と <end> の代わりに ‘:<funcname>’ が指定されている場合、こ
     れは <funcname> に一致する最初の関数名行から次の関数名行までの範囲
     を示す正規表現です。 ‘:<funcname>’ は、前の ‘-L’ 範囲の末尾から検索
     します。それ以外の場合は、ファイルの先頭から検索します。
     ‘^:<funcname>’ はファイルの先頭から検索します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

<revision range>
     指定されたリビジョン範囲のコミットのみを表示します。 <revision
     range> が指定されていない場合、デフォルトで ‘HEAD’ (つまり、現在の
     コミットにつながる履歴全体)になります。 ‘origin..HEAD’ は、現在のコ
     ミット(つまり、‘HEAD’)から到達可能なすべてのコミットを指定しますが
     、‘origin‘からは指定しません。 <revision range> の綴り方の完全なリ
     ストについては、 gitrevisions(7) の「Specifying Ranges」節を参照し
     てください。

[–] <path>…
     指定されたパスに一致するファイルがどのようになったかを説明するのに
     必要十分なコミットのみを表示します。詳細およびその他の簡略化モード
     については、以下の「History Simplification」を参照してください。

     混乱が生じた場合、パスをオプションまたはリビジョン範囲から分離する
     ために、パスの前に ‘--’ を付ける必要がある場合があります。

Commit Limiting
===============

ここで説明されている特別な表記法を使用してリストする必要があるコミットの
範囲を指定することに加えて、追加のコミット制限が適用される場合があります
。

   より多くのオプションを使用すると、通常、出力がさらに制限されます(たと
えば、‘--since=<date1>`は’<date1>‘より新しいコミットに制限され、
’–grep=<pattern>‘と一緒に使用すると、ログメッセージに’<pattern>‘と一致す
る行があるコミットにさらに制限されます)。

   注意: これらは、‘–reverse‘などのコミット順序およびフォーマットオプシ
ョンの前に適用されることに注意してください。

‘-<number>’
‘-n <number>’
‘--max-count=<number>’
     出力するコミットの数を制限します。

‘--skip=<number>’
     コミット出力の表示を開始する前に、number 個のコミットをスキップしま
     す。

–since=<date>
‘--after=<date>’
     指定の日付よりも新しいコミットを表示します。

‘--until=<date>’
‘--before=<date>’
     指定の日付より古いコミットを表示します。

‘--author=<pattern>’
‘--committer=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致する作者
     (author)/コミッター(committer)ヘッダー行を持つものに制限します。複
     数の ‘--author=<pattern>’ がある場合、作者が指定されたパターンのい
     ずれかに一致するコミットが選択されます(複数の
     ‘--committer=<pattern>’ の場合も同様)。

‘--grep-reflog=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致するreflogエント
     リを持つものに制限します。複数の‘–grep-reflog‘を使用すると、指定さ
     れたパターンのいずれかに一致するreflogメッセージを持つコミットが選
     択されます。‘–walk-reflogs‘が使用されていない限り、このオプションを
     使用するとエラーになります。

‘--grep=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致するログメッセー
     ジを持つものに制限します。複数の‘–grep=<pattern>‘を使用すると、指定
     されたパターンのいずれかにメッセージが一致するコミットが選択されま
     す(全てに一致するコミットだけを選択したい場合、’–all-match‘を参照し
     てください)。

     ‘–notes‘が有効な場合、ノートからのメッセージは、ログメッセージの一
     部であるかのようにマッチングされます。

‘--all-match’
     コミット出力を、少なくとも1つに一致するものではなく、指定されたすべ
     ての‘–grep‘に一致するものに制限します。

‘--invert-grep’
     コミット出力を、‘–grep=<pattern>‘で指定されたパターンと一致しないロ
     グメッセージを持つものに制限します。

‘-i’
‘--regexp-ignore-case’
     大文字小文字に関係なく、正規表現の制限パターンに一致します。

‘--basic-regexp’
     制限パターンを基本正規表現として扱います。これがデフォルトです。

‘-E’
‘--extended-regexp’
     制限パターンを、デフォルトの基本正規表現の代わりに拡張正規表現とし
     て扱います。

‘-F’
‘--fixed-strings’
     制限パターンを固定文字列として扱います(パターンを正規表現として解釈
     しないでください)。

‘-P’
‘--perl-regexp’
     制限パターンをPerl互換の正規表現として扱います。

     これらのタイプの正規表現のサポートは、コンパイル時オプションに依存
     します。Gitが当該のサポート付きでコンパイルされていない場合、このオ
     プションを提供すると、Gitが死にます(die)。

‘--remove-empty’
     指定されたパスがツリーから見えなくなったら停止(stop)します。

‘--merges’
     マージコミットのみを印刷します。これは‘–min-parents=2‘とまったく同
     じです。

‘--no-merges’
     複数の親を持つコミットを出力しない。これは‘–max-parents=1‘とまった
     く同じです。

‘--min-parents=<number>’
‘--max-parents=<number>’
‘--no-min-parents’
‘--no-max-parents’
     量の多少に関わらず、とにかく複数の親コミットがあるコミットのみを表
     示します。特に、‘--max-parents=1`は’–no-merges‘と同じであり、
     ‘--min-parents=2`は’–merges‘と同じです。‘--max-parents=0`はすべての
     ルートコミットを提供し、’–min-parents=3‘はすべてのタコ足マージ
     (octopus merges)を示します。

     ‘--no-min-parents`と’–no-max-parents‘は、これらの制限を(制限なしに
     )再度リセットします。同等の形式は、‘--min-parents=0’(すべてのコミッ
     トに0個以上の親があります)および‘–max-parents=-1‘(マイナスの数は上
     限がないことを示します)です。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを探索します。この
     オプションは、特定のトピックブランチの進化を表示するときに、より良
     い概要を提供できます。トピックブランチへのマージは、時々更新される
     アップストリームに調整することだけである傾向があり、このオプション
     を使用すると、そのようなマージによって履歴に取り込まれた個々のコミ
     ットを無視できます。

     このオプションは、マージコミットのデフォルトのdiff形式も
     ‘first-parent‘に変更します。詳細については、
     ‘–diff-merges=first-parent‘を参照してください。

‘--not’
     次に現れる ‘--not’ までの間、後続のすべてのリビジョン指定子の ‘^’(カ
     レット)接頭辞(またはその欠如)の意味を逆にします。

‘--all’
     ‘refs/’ 内のすべてのrefが HEAD とともに、コマンドラインに <commit>
     としてリストされているかのように見せかけます。

‘--branches[=<pattern>]’
     ‘refs/heads’ 内のすべてのrefがコマンドラインに <commit> としてリス
     トされているかのように見せかけます。 <pattern> が指定されている場合
     、ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限
     します。パターンに "?" または "*" または "[" がない場合、最後に
     "/*" が含まれます。

‘--tags[=<pattern>]’
     ‘refs/tags’ 内のすべてのrefがコマンドラインに <commit> としてリスト
     されているかのように見せかけます。 <pattern> が指定されている場合は
     、指定されたシェルグロブ(shell glob)に一致するタグにタグを制限しま
     す。パターンに "?" または "*" または "[" がない場合、最後に "/*" が
     含まれます。

‘--remotes[=<pattern>]’
     ‘refs/remotes’ 内のすべてのrefがコマンドラインに <commit> としてリ
     ストされているかのように見せかけます。 <pattern> が指定されている場
     合、リモート追跡ブランチを指定されたシェルグロブ(shell glob)に一致
     するものに制限します。パターンに "?" または "*" または "[" がない場
     合、最後に "/*" が含まれます。

‘--glob=<glob-pattern>’
     シェルグロブ <glob-pattern> に一致するすべてのrefがコマンドラインに
     <commit> としてリストされているかのように見せかけます。先頭の
     ‘refs/’ は、欠落している場合は自動的に先頭に追加されます。パターン
     に "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

‘--exclude=<glob-pattern>’
     次の ‘--all’ または ‘--branches’ または ‘--tags’ または ‘--remotes’
     または ‘--glob’ が別の方法で考慮する <glob-pattern> に一致するrefを
     含めないでください。このオプションを繰り返すと、次の ‘--all’ または
     ‘--branches’ または ‘--tags’ または ‘--remotes’ または ‘--glob’ オ
     プションまで除外パターンが蓄積されます(他のオプションまたは引数は、
     蓄積されたパターンをクリアしません)。

     与えられたパターンは、それぞれ ‘--branches’ または ‘--tags’ または
     ‘--remotes’ に適用される場合、 ‘refs/heads’ または ‘refs/tags’ また
     は ‘refs/remotes’ で始まるべきではありません。 ‘--glob’ または
     ‘--all’ に適用する場合は、 ‘refs/’ で始める必要があります。末尾の
     "/*" を意図している場合は、明示的に指定する必要があります。

‘--reflog’
     reflogsで言及されているすべてのオブジェクトがコマンドラインに
     <commit> としてリストされているかのように見せかけます。

‘--alternate-refs’
     代替リポジトリのref先端として言及されているすべてのオブジェクトがコ
     マンドラインにリストされているかのように見せかけます。代替リポジト
     リは、オブジェクトディレクトリが‘objects/info/alternates‘で指定され
     ているリポジトリです。インクルードされたオブジェクトのセットは、
     ‘core.alternateRefsCommand‘などによって変更できます。
     git-config(1)を参照してください。

‘--single-worktree’
     デフォルトでは、作業ツリーが複数ある場合、‘--all`と’-reflog‘と
     ‘–indexed-objects‘では、すべての作業ツリーが検査されます
     (git-worktree(1)を参照)。このオプションは、現在の作業ツリーのみを調
     べるように強制します。

‘--ignore-missing’
     入力に無効なオブジェクト名が含まれている場合、そもそもその不正な入
     力が行われていないかのように見せかけます。

‘--bisect’
     コマンドラインで、bad bisection ref ‘refs/bisect/bad’ がリストされ
     、その後に ‘--not’ と good bisection ref ‘refs/bisect/good-*’ が続
     くかのように見せかけます。

‘--stdin’
     コマンドラインにリストされている <commit> に加えて、標準入力からそ
     れらを読み取ります。 ‘--’ 区切り文字が表示された場合は、コミットの
     読み取りを停止し、パスの読み取りを開始して結果を制限します。

‘--cherry-mark’
     ‘--cherry-pick’（以下を参照）と同様ですが、同等のコミットを省略せず
     に ‘=’ と印し、同等でないコミットを ‘+’ と印します。

‘--cherry-pick’
     コミットの組を対称差(symmetric difference)に制限する場合、「反対側
     」の別のコミットと同じ変更を導入するコミットを省略します。

     たとえば、‘A’ と ‘B’ の2つのブランチがある場合、それらの片側だけで
     すべてのコミットを一覧表示する通常の方法は、 ‘--left-right’ を使用
     することです(‘--left-right’ オプションの説明の以下の例を参照してく
     ださい)。ただし、他のブランチからは(ブランチAと重複しない)厳選され
     たコミットが表示されます(たとえば、「3rd onb」はブランチAからチェリ
     ーピックされる可能性があります)。このオプションを使用すると、そのよ
     うなコミットのペアは出力から除外されます。

‘--left-only’
‘--right-only’
     リストは、対称差のそれぞれの側でのみコミットします。つまり、
     ‘--left-right`で `<’ と印されるのだけか、あるいは‘–left-right‘で
     ‘>‘と印されるものだけです。

     たとえば、‘--cherry-pick --right-only A...B`は、`A`にある、または
     `A`のコミットとパッチと同等のコミットを`B`から省略します。つまり、
     これは`git cherry A B`からの’+‘コミットをリストします。より正確に書
     くと、’–cherry-pick –right-only –no-merges‘により正確なリストを提供
     します。

‘--cherry’
     ‘–right-only –cherry-mark –no-merges‘の同義語です。出力を私たちの側
     のコミットに制限し、フォークされた履歴の反対の側に適用されたものを
     、‘git cherry upstream mybranch‘と同様に‘git log –cherry
     upstream…mybranch‘で印するのに役立ちます。

‘-g’
‘--walk-reflogs’
     コミットの祖先チェーンをたどる代わりに、reflogエントリを最新のもの
     から古いものに移動します。このオプションを使用する場合、除外するコ
     ミットを指定することはできません(つまり、 "^commit" や
     ‘commit1..commit2’ や ‘commit1...commit2’ 表記は使用できません)。

     (明らかな理由で、)‘oneline`と`reference`以外の’–pretty‘形式では、こ
     れにより、出力にreflogから取得された2行の追加情報が含まれます。出力
     のreflog指定子は、‘ref@{Nth}’ (‘Nth’ はreflogの逆時系列インデックス
     (reverse-chronological index))または ‘ref@{timestamp}’ (そのエント
     リのタイムスタンプ付き)として表示されます。表示は下記のいくつかのル
     ールに依存します:

       1. 開始点が ‘ref@{Nth}’ として指定されている場合は、インデックス
          形式を表示します。

       2. 開始点が ‘ref@{now}’ として指定されている場合は、タイムスタン
          プ形式を表示します。

       3. 上記のどちらも使用されていないが、コマンドラインで‘–date‘が指
          定されている場合は、‘–date‘で要求された形式でタイムスタンプを
          表示します。

       4. それ以外の場合は、インデックス形式を表示します。

     ‘--pretty = oneline`では、コミットメッセージの前にこの情報が同じ行
     に付けられます。このオプションを’–reverse‘と組み合わせることはでき
     ません。git-reflog(1)も参照してください。

     ‘–pretty=reference‘では、この情報はまったく表示されません。

‘--merge’
     マージが失敗した後、競合があり、マージするすべてのheadに存在しない
     ファイルに関連(touch)するrefを表示します。

‘--boundary’
     除外された境界コミットを出力します。 境界コミットの前には ‘-‘が付い
     ています。

History Simplification
======================

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があり
ます。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成
ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つは
コミットの選択であり、もう1つはそれを行う方法です。

   以下のオプションは、表示するコミットを選択します:

<paths>
     指定された<パス>を変更するコミットが選択されます。

‘--simplify-by-decoration’
     いくつかのブランチまたはタグによって参照されるコミットが選択されま
     す。

   注意: 意味のある重要な履歴のために、追加のコミットを表示できることに
注意してください。

   以下のオプションは、簡略化の実行方法に影響します。

Default mode
     履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最
     終結果が同じである場合(つまり、同じコンテンツのブランチをマージする
     場合)、いくつかの傍流ブランチ(side branches)を削除するため、最も単
     純です。

‘--show-pulls’
     デフォルトモードからのすべてのコミットを含めますが、最初の親への
     TREESAMEではなく、後の親へのTREESAMEであるマージコミットも含めます
     。このモードは、ブランチに変更を「最初に導入した」マージコミットを
     表示するのに役立ちます。(訳注:TREESAME=pathspecが全く同一であるツリ
     ー)

‘--full-history’
     デフォルトモードと同じですが、一部の履歴を削除しません。

‘--dense’
     選択したコミットのみが表示され、重大で意味のある履歴を持つコミット
     もいくつか表示されます。

‘--sparse’
     簡略化された履歴内のすべてのコミットが表示されます。

‘--simplify-merges’
     このマージに寄与する選択されたコミットがないため、結果の履歴からい
     くつかの不要なマージを削除するための‘–full-history‘への追加オプショ
     ン。

‘--ancestry-path’
     表示するコミットの範囲が指定されている場合(たとえば、
     ‘commit1..commit2’ または "commit2 ^commit1")、 commit1 と commit2
     の間の祖先チェーンに直接存在するコミットのみ、つまり、 commit1 の子
     孫であり、 commit2 の祖先であるコミットを表示します。

   より詳細な説明は以下のとおりです。

   <paths> として ‘foo’ を指定したとします。 ‘foo’ !TREESAME を変更する
コミットを呼び出し、残りをTREESAMEと呼びます。( ‘foo’ のためにフィルタリ
ングされた差分では、それぞれ異なって見えたりたり等しく見えたりします。）

   以下、簡略化設定の違いを説明するために、同じ履歴例を使います。このコ
ミットグラフでは、ファイル ‘foo’ をフィルタリングしていると想定していま
す:

               .-A---M---N---O---P---Q
              /     /   /   /   /   /
             I     B   C   D   E   Y
              \   /   /   /   /   /
               `-------------'   X

   履歴 A—Q の水平線は、各マージの最初の親と見なされます。その各コミット
は以下のとおりです:

   • ‘I’ は最初のコミットであり、ファイル foo が内容 “asdf” で存在し、フ
     ァイル quux は内容 “quux” で存在します。最初のコミットは空のツリー
     と比較されるため、‘I’ は !TREESAME です。

   • ‘A’ では、 foo には “foo” だけが含まれています。

   • ‘B’ には ‘A’ と同じ変更が含まれています。そのマージ ‘M’ は些細なこ
     とであり、したがってすべての親にとって TREESAME です。

   • ‘C’ は ‘foo’ を変更しませんが、そのマージ ‘N’ はそれを “foobar” に
     変更するので、どの親にとっても TREESAME ではありません。

   • ‘D’ は ‘foo’ を “baz” に設定します。そのマージ ‘O’ は、 ‘N’ と ‘D’
     から “foobarbaz” への文字列を結合します。つまり、どの親にとっても
     TREESAME ではありません。

   • ‘E’ は ‘quux’ を “xyzzy” に変更し、そのマージ ‘P’ は文字列を
     “quuxxyzzy” に結合します。 ‘P’ は ‘O’ に対して TREESAME ですが、
     ‘E’ に対してはそうではありません。

   • ‘X’ は、新ファイル ‘side’ を追加し、 ‘Y’ がそれを変更した独立したル
     ートコミットです。 ‘Y’ は ‘X’ へのTREESAMEです。そのマージ ‘Q’ は
     ‘P’ に ‘side’ を追加し、 ‘Q’ は ‘P’ にはTREESAMEですが、‘Y’ に対し
     てはそうではありません。

   ‘rev-list’ は、 ‘--full-history’ および/または、( ‘--parents’ または
‘--children’ を介して)親の書き換えが使用されているかどうかに基づいて、コ
ミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下
の設定が可能です。

Default mode
     コミットは、どの親に対してもTREESAMEでない場合に含まれます(これは変
     更できますが、以下の ‘--sparse’ を参照してください)。コミットがマー
     ジであり、一方の親に対するTREESAMEであった場合は、その親のみをフォ
     ローします。(TREESAMEの親が複数ある場合でも、そのうちの1つだけをフ
     ォローします)。それ以外の場合は、すべての親をフォローします。

     これにより、以下のようになります:

                    .-A---N---O
                   /     /   /
                  I---------D

     TREESAMEの親のみに従うルールが利用可能な場合は、 ‘B’ を検討対象から
     完全に削除したことに注意してください。 ‘C’ は ‘N’ を介して考慮され
     ましたが、しかしそれはTREESAMEです。ルートコミットは空のツリーと比
     較されるため、 ‘I’ は !TREESAME です。

     親子関係は ‘--parents’ でのみ表示されますが、デフォルトモードで選択
     されたコミットには影響しないため、親の行を示しました。

‘--full-history without parent rewriting’
     このモードは、デフォルトとはある一点で異なります。つまり、いずれか
     の親に対してTREESAMEであっても、常にマージのすべての親に従います。
     マージの複数の側にコミットが含まれている場合でも、これはマージ自体
     が含まれていることを意味するものではありません！ 例では以下のように
     なります。

                  I  A  B  N  D  O  P  Q

     ‘M’ は、両方の親にとってTREESAMEであるため、除外されました。 ‘E’ と
     ‘C’ と ‘B’ をすべて巡りましたが、 ‘B’ だけが !TREESAME だったので、
     他は表示されません。

     注意: 親の書き換え(rewrite)がないと、コミット間の親子関係について話
     す(talk)ことは実際には不可能であるため、それらが切断されている
     (disconnected)ことを示していることに注意してください。

‘--full-history with parent rewriting’
     通常のコミットは !TREESAME の場合にのみ含まれます(これは変更できま
     すが、以下の ‘--sparse’ を参照してください)。

     マージは常に含まれます。ただし、親リストは書き直されます。各親に沿
     って、自分自身に含まれていないコミットを削除します。 これにより以下
     のようになります。

                    .-A---M---N---O---P---Q
                   /     /   /   /   /
                  I     B   /   D   /
                   \   /   /   /   /
                    `-------------'

     上記を書き直さずに ‘--full-history’ と比較してください。 ‘E’ は
     TREESAMEであるため削除されましたが、Pの親リストは ‘E’ の親 ‘I’ を含
     むように書き直されていることに注意してください。 ‘C’ と ‘N’ および
     ‘X’ と ‘Y’ と ‘Q’ についても同じことが起こりました。

   上記の設定に加えて、あなたはTREESAMEが包含に影響を与えるかどうかを変
更できます:

‘--dense’
     巡ったコミットは、親にとってTREESAMEでない場合に含まれます。

‘--sparse’
     巡ったすべてのコミットが含まれます。

     ‘--full-history’ がなくても、これによりマージが単純化されることに注
     意してください。親の1つがTREESAMEの場合、その1つだけに従うため、マ
     ージの反対側を巡ることはありません。

‘--simplify-merges’
     最初に、親を書き換えた ‘--full-history’ と同じ方法で履歴グラフを作
     成します(上記を参照)。

     それから、以下のルールに従って、各コミット ‘C’ を最終履歴内の置換
     ‘C'’ に単純化します:

        • ‘C'’ を ‘C’ にセットします。

        • ‘C'’ の各親 ‘P’ をその簡略化された ‘P'’ に置き換えます。その過
          程で、他の親の祖先であるか、ルートである親を削除すると、
          TREESAMEが空のツリーにコミットされ、重複が削除されますが、
          TREESAMEであるすべての親を削除しないように注意してください。

        • この親の書き換え後、 ‘C'’ がルートまたはマージコミット(0または
          >1 の親を持つ)、境界コミット、または !TREESAMEである場合、それ
          は残ります。それ以外の場合は、唯一の親に置き換えられます。

     この効果は、親の書き換えを使用した ‘--full-history’ と比較すること
     で最もよく示されます。例は以下のようになります:

                    .-A---M---N---O
                   /     /       /
                  I     B       D
                   \   /       /
                    `---------'

     注意: ‘--full-history’ に対する ‘N’ と ‘P’ と ‘Q’ の主な違いに注意
     してください:

        • ‘N’ の親リストは、他の親 ‘M’ の祖先であるため、 ‘I’ が削除され
          ました。それでも、 !TREESAME なので ‘N’ が残りました。

        • ‘P’ の親リストも同様に ‘I’ が削除されました。 ‘P’ は、親が1つ
          で TREESAMEであるため、完全に削除されました。

        • ‘Q’ の親リストでは、 ‘Y’ が ‘X’ に簡略化されていました。その後
          、 ‘X’ はTREESAMEルートであったため、削除されました。 ‘Q’ は、
          親が1つで TREESAMEであるため、完全に削除されました。

   利用可能な別の簡略化モードがあります:

‘--ancestry-path’
     表示されるコミットを、指定されたコミット範囲内の “from” コミットと
     “to” コミットの間の祖先チェーンに直接あるコミットに制限します。つま
     り、 “to” コミットの祖先であるコミットと “from” コミットの子孫であ
     るコミットのみを表示します。

     ユースケースの例として、以下のコミット履歴について考えます:

                      D---E-------F
                     /     \       \
                    B---C---G---H---I---J
                   /                     \
                  A-------K---------------L--M

     通常の ‘D..M’ は、 ‘M’ の祖先であるコミットのセットを計算しますが、
     ‘D’ の祖先であるコミットは除外します。 これは、「 ‘M’ には ‘D’ には
     存在しなかったものがある」という意味で、 ‘D’ 以降の ‘M`に至るまでの
     歴史に何が起こったのかを知るのに役立ちます。この例の結果は、 `A’ と
     ‘B’ (そしてもちろん ‘D’ 自体)を除くすべてのコミットになります。

     ただし、 ‘M’ のコミットが ‘D’ で入ったバグで汚染されており、修正が
     必要な場合は、実際には ‘D’ の子孫である ‘D..M’ のサブセットのみを表
     示する必要があります。つまり、 ‘C’ と ‘K’ を除外します。これはまさ
     に ‘--ancestry-path’ オプションが行うことです。これを ‘D..M’ 範囲に
     適用すると、以下のようになります:

                          E-------F
                           \       \
                            G---H---I---J
                                         \
                                          L--M

   別のオプション ‘--show-pulls’ について説明する前に、新しいサンプル履
歴を作成する必要があります。

   簡略化された履歴を見るときにユーザーが直面する一般的な問題は、ファイ
ルを変更したことがわかっているコミットが、ファイルの簡略化された履歴に表
示されないことです。そこで、新しい例を示し、その場合に ‘--full-history’
や ‘--simplify-merges’ などのオプションがどのように機能するかを示しまし
ょう。

               .-A---M-----C--N---O---P
              /     / \  \  \/   /   /
             I     B   \  R-'`-Z'   /
              \   /     \/         /
               \ /      /\        /
                `---X--'  `---Y--'

   この例では、 ‘I’ が ‘file.txt’ を作成し、それが ‘A’ と‘B‘ と ‘X’ にて
さまざまな方法で変更されたとします。ひとり親のコミット ‘C’ と ‘Z’ と ‘Y’
は ‘file.txt’ を変更していません。マージコミット ‘M’ は、マージの競合を
解決して、 ‘A’ と ‘B’ の両方の変更を含めることによって作成されたため、ど
ちらにもTREESAMEではありません。ただし、マージコミット ‘R’ は、 ‘M’ の
‘file.txt`の内容を無視し、 `X’ の ‘file.txt’ の内容のみを取得することに
よって作成されました。 したがって、 ‘R’ は ‘X’ へのTREESAMEですが、 ‘M’
はそうではありません。最後に、 ‘N’ を作成するための自然なマージ解決は、
‘R’ で ‘file.txt’ の内容を取得することです。したがって、 ‘N’ は ‘C’ では
なく ‘R’ へのTREESAMEです。マージコミット ‘O’ と ‘P’ は、最初の親には
TREESAMEですが、2番目の親である ‘Z’ と ‘Y’ にはついてはそうではありませ
ん。

   デフォルトモードを使用する場合、 ‘N’ と ‘R’ は両方ともTREESAMEの親を
持っているため、これらのエッジはウォークされ、他のエッジは無視されます。
結果の履歴グラフは以下のとおりです:

             I---X

   ‘--full-history’ を使用する場合、Gitはすべてのエッジを巡ります。これ
により、コミット ‘A’ と ‘B’ と マージ ‘M’ が検出されますが、マージコミッ
ト ‘O’ と ‘P’ も明らかになります。 親を書き換えると、結果のグラフは以下
のようになります:

               .-A---M--------N---O---P
              /     / \  \  \/   /   /
             I     B   \  R-'`--'   /
              \   /     \/         /
               \ /      /\        /
                `---X--'  `------'

   ここで、マージコミット ‘O’ と ‘P’ は、実際には ‘file.txt’ への変更を
提供しなかったため、余分なノイズを提供します。古いバージョンの
‘file.txt’ に基づいたトピックのみをマージしました。これは、多くの寄稿者
が並行して作業し、トピックブランチを単一のトランクに沿ってマージするワー
クフローを使用するリポジトリの一般的な問題です。開発に関係のないマージが
‘--full-history’ の結果に表示されます。

   ‘--simplify-merges’ オプションを使用すると、コミット ‘O’ と ‘P’ が結
果から消えます。 これは、 ‘O’ と ‘P’ の書き直された2番目の親が、最初の親
から到達可能であるためです。これらのエッジが削除されると、コミットは、親
にとってTREESAMEである単一の親のコミットのように見えます。これはコミット
‘N’ にも発生し、以下のような履歴ビューが表示されます:

               .-A---M--.
              /     /    \
             I     B      R
              \   /      /
               \ /      /
                `---X--'

   このビューでは、 ‘A’ と ‘B’ と ‘X’ からの重要なひとり親の変更がすべて
表示されます。また、慎重に解決されたマージ ‘M’ とそれほど慎重に解決され
ていないマージ ‘R’ も表示されます。これは通常、コミット ‘A’ と ‘B’ がデ
フォルトのビューの履歴から「消えた」理由を判断するのに十分な情報です。た
だし、このアプローチにはいくつかの問題があります。

   最初の問題はパフォーマンスです。以前のオプションとは異なり、
‘--simplify-merges’ オプションでは、単一の結果を返す前にコミット履歴全体
をウォークする必要があります。これにより、非常に大規模なリポジトリでこの
オプションを使用するのが難しくなる可能性があります。

   2番目の問題は監査の1つです。多くの寄稿者が同じリポジトリで作業してい
る場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。
上記の問題のあるマージ ‘R’ は、重要なブランチにマージするために使用され
たマージコミットではない可能性があります。 代わりに、マージ ‘N’ を使用し
て ‘R’ と ‘X’ を重要なブランチにマージしました。このコミットには、変更
‘X’ がコミットメッセージの ‘A’ と ‘B’ からの変更を上書きするようになった
理由に関する情報が含まれている可能性があります。

‘--show-pulls’
     デフォルトの履歴に表示されるコミットに加えて、最初の親には
     TREESAMEではなく、後の親にはTREESAMEである各マージコミットを表示し
     ます。

     マージコミットが ‘--show-pulls’ に含まれている場合、マージは別のブ
     ランチから変更を「プル」したかのように扱われます。この例で
     ‘--show-pulls’ を使用すると(他のオプションは使用しない場合、)結果の
     グラフは行かのようになります:

                  I---X---R---N

     ここで、コミット ‘X’ と ‘R’ をそれぞれベースブランチにプルしたため
     、マージコミット ‘R’ と ‘N’ が含まれています。これらのマージは、コ
     ミット ‘A’ と ‘B’ がデフォルトの履歴に表示されない理由です。

     ‘--show-pulls’ が ‘--simplify-merges’ とペアになっている場合、グラ
     フには必要なすべての情報が含まれます:

                    .-A---M--.   N
                   /     /    \ /
                  I     B      R
                   \   /      /
                    \ /      /
                     `---X--'

     ‘M’ は ‘R’ から到達可能であるため、 ‘N’ から ‘M’ へのエッジが単純化
     されていることに注意してください。ただし、 ‘N’ は、変更 ‘R’ をメイ
     ンブランチに「プル」したため、重要なコミットとして履歴に表示されま
     す。

   ‘--simplify-by-decoration’ オプションを使用すると、タグで参照されてい
ないコミットを省略して、履歴のトポロジの全体像のみを表示できます。コミッ
トは、(1)タグによって参照されている場合、または (2)コマンドラインで指定
されたパスの内容を変更した場合に、!TREESAMEとしてマークされます(つまり、
上記の履歴簡略化ルールの後に保持されます)。他のすべてのコミットは
TREESAMEとしてマークされます(簡略化される可能性があります)。

Commit Ordering
===============

デフォルトでは、コミットは新しい順に表示されます。

‘--date-order’
     すべての子が表示されるまで親を表示しませんが、それ以外の場合はコミ
     ットタイムスタンプの順序でコミットを表示します。

‘--author-date-order’
     すべての子が表示されるまで親を表示しませんが、それ以外の場合は、作
     者(author)のタイムスタンプ順にコミットを表示します。

‘--topo-order’
     すべての子が表示されるまで親を表示せず、複数の履歴行が混在するコミ
     ットを表示しないようにします。

     たとえば、以下のようなコミット履歴があります:

              ---1----2----4----7
                  \              \
                   3----5----6----8---

     ここで、数字はコミットタイムスタンプの順序を示し、 ‘gitrev-list’ と
     ‘--date-order’ のある友達は、タイムスタンプの順序でコミットを示しま
     す。つまり、8 7 6 5 4 3 2 1

     ‘--topo-order’ を使用すると、8 6 5 3 7 4 2 1（または8 7 4 2 6 5 3
     1）が表示されます。2つの並列開発トラックからのコミットが混在して表
     示されないようにするために、いくつかの古いコミットが新しいコミット
     の前に表示されます。

‘--reverse’
     表示するように選択したコミットを逆の順序で出力します(上記の Commit
     Limiting 節を参照)。 ‘--walk-reflogs’ と組み合わせることはできませ
     ん。

Object Traversal
================

これらのオプションは、主にGitリポジトリのパッキングを対象としています。

‘--unsorted-input’
     コミット時間で時系列の逆順に並べ替えるのではなく、コマンドラインで
     指定された順序でコミットを表示します。‘--no-walk’ または
     ‘--no-walk=sorted’ と組み合わせることはできません。

‘--no-walk[=(sorted|unsorted)]’
     指定されたコミットのみを表示し、祖先をトラバースしない。範囲が指定
     されている場合、これは効果がありません。引数 ‘unsorted’ が指定され
     ている場合、コミットはコマンドラインで指定された順序で表示されます
     。それ以外の場合( ‘sorted’ または引数が指定されていない場合)、コミ
     ットはコミット時間の逆順に表示されます。 ‘--graph’ と組み合わせるこ
     とはできません。 ‘sorted’ または引数が指定されていない場合、
     ‘--unsorted-input’ と組み合わせることはできません。

‘--do-walk’
     以前の ‘--no-walk’ を上書きします。

Commit Formatting
=================

‘--pretty[=<format>]’
‘--format=<format>’
     コミットログの内容を指定された形式できれいに印刷(pretty-print)しま
     す。 <format> は oneline、short、medium、full、fuller、reference、
     email、raw、format:<string>、tformat:<string> のいずれかになります
     。 <format> が上記のいずれでもなく、「%プレースホルダー」が含まれて
     いる場合、 ‘--pretty=tformat:<format>’ が指定されたかのように動作し
     ます。

     各フォーマットの詳細については、「PRETTY FORMATS」セクションを参照
     してください。 ‘=<format>’ の部分を省略すると、デフォルトで medium
     になります。

     注意: リポジトリー構成でデフォルトのpretty formatを指定できます
     (git-config(1) 参照)。

‘--abbrev-commit’
     40バイトの16進コミットオブジェクト名全体を表示する代わりに、オブジ
     ェクトに一意の名前を付けるプレフィックスを表示します。
     "–abbrev=<n>" (表示されている場合はdiff出力も変更します)オプション
     を使用して、プレフィックスの最小長を指定できます。

     これにより、80桁幅の端末を使用している人にとって "–pretty=oneline"
     がずっと読みやすくなるはずです。

‘--no-abbrev-commit’
     完全な40バイトの16進コミットオブジェクト名を表示します。 これにより
     、明示的または "–oneline" などの他のオプションによって暗黙的に示さ
     れる ‘--abbrev-commit’ が無効になります。また、 ‘log.abbrevCommit’
     変数をオーバーライドします。

‘--oneline’
     これは、 "–pretty=oneline –abbrev-commit" を一緒に使用するための省
     略形です。

‘--encoding=<encoding>’
     コミットオブジェクトは、ログメッセージに使用される文字エンコードを
     エンコードヘッダーに記録します。このオプションを使用して、ユーザー
     が好むエンコーディングでコミットログメッセージを再コーディングする
     ようにコマンドに指示できます。配管以外のコマンドの場合、これはデフ
     ォルトでUTF-8になります。オブジェクトが ‘X’ でエンコードされている
     と主張し、 ‘X’ で出力している場合、オブジェクトをそのまま出力するこ
     とに注意してください。これは、元のコミットの無効なシーケンスが出力
     にコピーされる可能性があることを意味します。同様に、 iconv(3) コミ
     ットの変換に失敗した場合、警告とともに元のオブジェクトをそのまま出
     力します。

‘--expand-tabs=<n>’
‘--expand-tabs’
‘--no-expand-tabs’
     出力に表示する前に、ログメッセージでタブ展開を実行します(タブ幅を
     <n> とみなして <n> 境界に揃うように空白で調整する)。
     ‘--expand-tabs’ は ‘--expand-tabs=8’ の省略形であり、
     ‘--no-expand-tabs’ は ‘--expand-tabs=0’ の省略形です。タブの展開を
     無効にします。

     デフォルトでは、タブはログメッセージを4つのスペースでインデントする
     きれいな形式(pretty formats)で展開されます(つまり、medium (これがデ
     フォルト) と full と fuller)。

‘--notes[=<ref>]’
     コミットログメッセージを表示するときに、コミットに注釈を付ける
     notes(git-notes(1) 参照)を表示します。これは、コマンドラインに
     ‘--pretty’ 、‘--format’ または ‘--oneline’ オプションが指定されてい
     ない場合の、 ‘git log’ と ‘git show’ と ‘ git whatchanged‘ コマンド
     のデフォルトです。

     デフォルトでは、表示されるnotesは、 ‘core.notesRef’ および
     ‘notes.displayRef’ 変数(または対応する環境変数オーバーライド)にリス
     トされているnote refからのものです。詳細については git-config(1) を
     参照してください。

     オプションの <ref> 引数を使用して、refを使用して表示するnotesを検索
     します。 refは、 ‘refs/notes/’ で始まる完全なrefnameを指定できます
     。 ‘notes/’ で始まるか、 ‘refs/’ で始まるか、それ以外で始まる場合、
     ‘refs/notes/’ が接頭辞として付けられ、refのフルネームを形成します。

     複数の –notes オプションを組み合わせて、表示するノートを制御できま
     す。 例: "–notes=foo" は "refs/notes/foo" からのnotesのみを表示しま
     す。 "–notes=foo –notes" は、 "refs/notes/foo" とデフォルトのnotes
     ref(s) の両方のnotesを表示します。

‘--no-notes’
     notesを表示しないでください。 これは、notesが表示されるnotes refの
     リストをリセットすることにより、上記の ‘--notes’ オプションを無効に
     します。 オプションは、コマンドラインで指定された順序で解析されます
     。 "–notes –notes=foo –no-notes –notes=bar" は、 "refs/notes/bar" か
     らのnotesのみを表示します。

‘--show-notes[=<ref>]’
‘--[no-]standard-notes’
     これらのオプションは非推奨です。 代わりに、上記の –notes/–no-notes
     オプションを使用してください。

‘--show-signature’
     署名を ‘gpg --verify’ に渡して、署名されたコミットオブジェクトの有
     効性を確認し、出力を表示します。

‘--relative-date’
     ‘--date=relative’ と同じ。

‘--date=<format>’
     ‘--pretty’ を使用する場合など、人間が読める形式で表示される日付に対
     してのみ有効になります。 ‘log.date’ 構成変数(config variable)は、
     logコマンドの ‘--date’ オプションのデフォルト値を設定します。デフォ
     ルトでは、日付は元のタイムゾーン(コミッターの、または作者のいずれか
     )で表示されます。フォーマットに ‘-local’ が追加されている場合(例:
     ‘iso-local’ )、代わりにユーザーのローカルタイムゾーンが使用されます
     。

     ‘--date=relative’ は、現在の時刻を基準にした日付を示します。例: “2
     hours ago” 。 ‘-local’ オプションは ‘--date = relative’ には効果が
     ありません。

     ‘--date=local’ は ‘--date=default-local’ のエイリアスです。

     ‘--date=iso’ (または ‘--date=iso8601’ )は、タイムスタンプをISO
     8601のような形式で表示します。厳密なISO 8601形式との違いは以下のと
     おりです:

        • ‘T’ 日付/時刻区切り文字の代わりにスペース

        • 時間とタイムゾーンの間のスペース

        • タイムゾーンの時間と分の間にコロンがありません

     ‘--date=iso-strict’ (または ‘--date=iso8601-strict’ )は、タイムスタ
     ンプを厳密なISO 8601形式で表示します。

     ‘--date=rfc’ (または ‘--date=rfc2822’ )は、RFC 2822形式のタイムスタ
     ンプを示します。これは、電子メールメッセージでよく見られます。

     ‘--date=short’ は、日付のみを表示し、時刻は表示せず、 ‘YYYY-MM-DD’
     形式で表示します。

     ‘--date=raw’ は、エポック(1970-01-01 00:00:00 UTC)からの秒数、スペ
     ース、UTCからのオフセット(‘+’ または ‘-’ の付いた4桁数字で、最初の
     2つは時間、次の2つは分です)。つまり、タイムスタンプが ‘strftime("%s
     %z")’ でフォーマットされているかのようになります。 ‘-local’ オプシ
     ョンは、seconds-since-epoch値(常にUTCで測定されます)には影響しませ
     んが、付随するタイムゾーン値を切り替えることに注意してください。

     ‘--date=human’ は、タイムゾーンが現在のタイムゾーンと一致しない場合
     はタイムゾーンを表示し、一致する場合は日付全体を印刷しません(つまり
     、「今年」の日付の場合は年の印刷をスキップしますが、何があったか覚
     えてるような過去数日については日付自体もスキップします)。 古い日付
     の場合、時と分も省略されます。

     ‘--date=unix’ は、日付をUnixエポックタイムスタンプ(1970年からの秒数
     )として表示します。 ‘--raw’ と同様に、これは常にUTCであるため、 ‘
     -local‘ は効果がありません。

     ‘--date=format:...’ は、内部で処理される%zと%Zを除いて、フォーマッ
     ト ‘...’ をあなたのシステムの ‘strftime’ に送ります。
     ‘--date=format:%c’ を使用して、システムロケールの推奨形式で日付を表
     示します。フォーマットプレースホルダーの完全なリストについては、
     ‘strftime’ マニュアルを参照してください。 ‘-local’ を使用する場合、
     正しい構文は ‘--date=format-local:...’ です。

     ‘--date=default’ はデフォルトの形式であり、いくつかの例外を除いて
     ‘--date=rfc2822’ に似ています:

        • 曜日の後にコンマはありません

        • ローカルタイムゾーンを使用する場合、タイムゾーンは省略されます

‘--parents’
     コミットの親も出力します( "commit parent…" の形式で)。親の書き換え
     も可能にします。上記「History Simplification」を参照してください。

‘--children’
     コミットの子も出力します( "commit child…" の形式で)。親の書き換えも
     可能にします。上記「History Simplification」を参照してください。

‘--left-right’
     対称差のどちら側からコミットに到達できるかをマークします。左側から
     のコミットには ‘<’ が付けられ、右側からのコミットには ‘>’ が付けら
     れます。 ‘--boundary’ と組み合わせると、それらのコミットの前に ‘-’
     が付きます。

     たとえば、以下のトポロジーの場合:

                       y---b---b  branch B
                      / \ /
                     /   .
                    /   / \
                   o---x---a---a  branch A

     以下のような出力が得られます:

                  $ git rev-list --left-right --boundary --pretty=oneline A...B

                  >bbbbbbb... 3rd on b
                  >bbbbbbb... 2nd on b
                  <aaaaaaa... 3rd on a
                  <aaaaaaa... 2nd on a
                  -yyyyyyy... 1st on b
                  -xxxxxxx... 1st on a

‘--graph’
     出力の左側に、コミット履歴のテキストベースのグラフィック表現を描画
     します。グラフ履歴を適切に描画するために、コミットの間に余分な行が
     出力される可能性があります。 ‘--no-walk’ と組み合わせることはできま
     せん。

     これにより、親の書き換えが可能になります。上記「History
     Simplification」を参照してください。

     これは、デフォルトで ‘--topo-order’ オプションを意味しますが、
     ‘--date-order’ オプションも指定できます。

‘--show-linear-break[=<barrier>]’
     –graph を使用しない場合、すべての履歴ブランチがフラット化されるため
     、2つの連続するコミットが線形ブランチに属していないことがわかりにく
     くなる可能性があります。このオプションは、その場合、それらの間に障
     壁を置きます。 ‘<barrier>’ が指定されている場合、デフォルトの障壁文
     字列の代わりに ‘<barrier>’ が表示されます。

PRETTY FORMATS
**************

コミットがマージであり、 pretty-format が ‘oneline’ または ‘email’ また
は ‘raw’ で無い場合、 ‘Author:’ 行の前に追加の行が挿入されます。この行は
"Merge: " で始まり、先祖のコミットのハッシュがスペースで区切られて出力さ
れます。履歴の表示を制限している場合、たとえば、特定のディレクトリまたは
ファイルに関連する変更のみに関心がある場合、リストされたコミットは必ずし
も *直接* の親コミットのリストではない可能性があることに注意してください
。

   いくつかの組み込みフォーマットがあります。そして以下で説明するように
、 pretty.<name> 構成オプション(config option)を別のフォーマット名または
‘format:’ 文字列に設定することで、追加のフォーマットを定義できます
(git-config(1) 参照)。組み込みフォーマットの詳細は以下のとおりです:

   • ‘oneline’

          <hash> <title line>

     これは、可能な限りコンパクトになるように設計されています。

   • ‘short’

          commit <hash>
          Author: <author>

          <title line>

   • ‘medium’

          commit <hash>
          Author: <author>
          Date:   <author date>

          <title line>

          <full commit message>

   • ‘full’

          commit <hash>
          Author: <author>
          Commit: <committer>

          <title line>

          <full commit message>

   • ‘fuller’

          commit <hash>
          Author:     <author>
          AuthorDate: <author date>
          Commit:     <committer>
          CommitDate: <committer date>

          <title line>

          <full commit message>

   • ‘reference’

          <abbrev hash> (<title line>, <short author date>)

     この形式は、コミットメッセージ内の別のコミットを参照するために使用
     され、 ‘--pretty='format:%C(auto)%h (%s, %ad)'’ と同じです。 デフォ
     ルトでは、別の ‘--date’ オプションが明示的に指定されていない限り、
     日付は ‘--date=short’ でフォーマットされます。formatプレースホルダ
     ーを使用する他の ‘format:’ と同様に、その出力は、 ‘--decorate’ や
     ‘--walk-reflogs’ などの他のオプションの影響を受けません。

   • ‘email’

          From <hash> <date>
          From: <author>
          Date: <author date>
          Subject: [PATCH] <title line>

          <full commit message>

   • ‘mboxrd’

     ‘email’ と同様ですが、コミットメッセージの "From " で始まる行(前に
     0個以上の ‘>’ が付いている)は ‘>’ でクォートされているため、新しい
     コミットの開始と混同されることはありません。

   • ‘raw’

     ‘raw’ 形式は、コミットオブジェクトに格納されているとおりにコミット
     全体を正確に表示します。とりわけ ‘--abbrev’ または ‘--no-abbrev’ の
     どちらが使用されているかに関係なく、ハッシュは完全に表示され、「親
     」(parents)情報は、移植や履歴の単純化を考慮せずに、真の親のコミット
     を示します。この形式は、コミットの表示方法に影響しますが、いわゆる
     ‘git log --raw’ の差分の表示方法ではありません。生のdiff形式で完全
     なオブジェクト名を取得するには、 ‘--no-abbrev’ を使用します。

   • ‘format:<string>’

     ‘format:<string>’ 形式を使用すると、表示する情報を指定できます。注
     意: これはprintf書式に少し似ていますが、 ‘\n’ の代わりに ‘%n’ を使
     用して改行を取得するという例外に注意してください。

     例: ‘format:"The author of %h was %an, %ar%nThe title was
     >>%s<<%n"’ は以下のように表示されます:

          The author of fe6e0ee was Junio C Hamano, 23 hours ago
          The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

     さて、以下がプレースホルダー達です:

        • 単一のリテラル文字に展開されるプレースホルダー:

          ‘%n’
               改行(newline)

          ‘%%’
               ‘%‘そのもの

          ‘%x00’
               16進数のバイト値を出力

        • うしろのプレースホルダーのフォーマッティングに影響するプレース
          ホルダー:

          ‘%Cred’
               赤色に切り替える

          ‘%Cgreen’
               緑色に切り替える

          ‘%Cblue’
               青色に切り替える。

          ‘%Creset’
               色をリセットする

          ‘%C(...)’
               git-config(1) の「CONFIGURATION FILE」の Values で説明さ
               れている色の指定。 デフォルトでは、色はログ出力が有効にな
               っている場合にのみ表示されます’(‘color.diff’ または
               ‘color.ui’ または ‘--color’ によって、ターミナルに出す場
               合は前者の ‘auto’ 設定を尊重します)。 ‘%C(auto,...)’ は、
               default の歴史的同義語として受け入れられます(例:
               ‘%C(auto,red)’)。 ‘%C(always,...)’ を指定すると、色が有効
               になっていない場合でも色が表示されます(この形式やgitが色
               付けする可能性のある他のすべてのものを含め、出力全体の色
               を有効にするために ‘--color=always’ の使用を検討してくだ
               さい)。 ‘auto’ のみ(つまり、 ‘%C(auto)’)は、色が再び切り
               替わるまで、これに続くプレースホルダーで自動色付けをオン
               にします。

          ‘%m’
               左(‘<’) または 右(‘>’) または 境界 (‘-’) の印

          ‘%w([<w>[,<i1>[,<i2>]]])’
               git-shortlog(1) の -w オプションのように、 行の折り返しを
               切り替えます。

          ‘%<(<N>[,trunc|ltrunc|mtrunc])’
               次のプレースホルダーに少なくともN列を使用させ、 必要に応
               じて右側にスペースを埋め込みます。オプションで、出力がN列
               より長い場合は、先頭(ltrunc)または中間(mtrunc)または末尾
               (trunc)で切り捨てます。注意: 切り捨ては、 N >= 2 でのみ正
               しく機能することに注意してください。

          ‘%<|(<N>)’
               次のプレースホルダーを少なくともN番目の列まで取得し、 必
               要に応じて右側にスペースを埋め込みます

          ‘%>(<N>)’, ‘%>|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 左側に
               スペースが埋め込まれています

          ‘%>>(<N>)’, ‘%>>|(<N>)’
               ‘%>(<N>)’ 、 ‘%>|(<N>)’ とそれぞれ似ていますが、 次のプレ
               ースホルダーが指定されたよりも多くのスペースを取り、その
               左側にスペースがある場合は、それらのスペースを使用します
               。

          ‘%><(<N>)’, ‘%><|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 両側に
               パディングがあります(つまり、テキストが中央に配置されます
               )

        • コミットから抽出された情報に展開するプレースホルダー:

          ‘%H’
               コミットハッシュ

          ‘%h’
               省略されたコミットハッシュ

          ‘%T’
               ツリーハッシュ

          ‘%t’
               省略されたツリーハッシュ

          ‘%P’
               親のハッシュ達

          ‘%p’
               省略された親のハッシュ達

          ‘%an’
               作者名

          ‘%aN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) を参照)

          ‘%ae’
               作者電子メールアドレス

          ‘%aE’
               作者電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) を参照)

          ‘%al’
               作者電子メールアドレスアカウント名(local-part)(‘@’ の前の
               部分)

          ‘%aL’
               作者電子メールアドレスアカウント名(local-part)(‘%al’ 参照
               ) .mailmap に関しては git-shortlog(1) または git-blame(1)
               参照)

          ‘%ad’
               作成日(フォーマットに関しては –date= オプション参照)

          ‘%aD’
               作成日 RFC2822形式

          ‘%ar’
               作成日 相対(relative)形式

          ‘%at’
               作成日 UNIXタイムスタンプ形式

          ‘%ai’
               作成日 ISO 8601風形式

          ‘%aI’
               作成日 厳密なISO 8601形式

          ‘%as’
               作成日 短い形式(‘YYYY-MM-DD’)

          ‘%ah’
               作成日 human形式( git-rev-list(1) の ‘--date=human’ オプ
               ションのようなかんじ)

          ‘%cn’
               コミッター名

          ‘%cN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ce’
               コミッター電子メールアドレス

          ‘%cE’
               コミッター電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%cl’
               コミッター電子メールアドレスアカウント名(local-part)( ‘@’
               の前の部分)

          ‘%cL’
               コミッター電子メールアドレスアカウント名(local-part)(
               ‘%cl’ 参照) .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%cd’
               コミッター日付(フォーマットに関しては ‘--date=’ オプショ
               ン参照)

          ‘%cD’
               コミッター日付 RFC2822形式

          ‘%cr’
               コミッター日付 相対(relative)形式

          ‘%ct’
               コミッター日付 UNIXタイムスタンプ形式

          ‘%ci’
               コミッター日付 ISO 8601風形式

          ‘%cI’
               コミッター日付 厳密なISO 8601形式

          ‘%cs’
               コミッター日付 短い形式(‘YYYY-MM-DD’)

          ‘%ch’
               コミッター日付 human形式(git-rev-list(1) の
               ‘--date=human’ オプションのようなかんじ)

          ‘%d’
               ref名 git-log(1) の –decorate オプションみたいなの

          ‘%D’
               " (", ")" で囲ってないref名

          ‘%(describe[:options])’
               git-describe(1) のような人間が読める名前。 説明できないコ
               ミットの場合は空の文字列。 ‘describe’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。タグが同時に追加または削除されると、説明に一貫性がな
               くなる可能性があります。

                  • ‘match=<pattern>’: ‘refs/tags/’ プレフィックスを除い
                    て、指定された ‘glob(7)’ パターンに一致するタグのみ
                    を考慮します。

                  • ‘exclude=<pattern>’: ‘refs/tags/’ プレフィックスを除
                    いて、指定された ‘glob(7)’ パターンに一致するタグを
                    対象にしません。

          ‘%S’
               コミットに到達したコマンドラインで指定されたref名 ( ‘git
               log --source’ など)は、 ‘git log’ でのみ機能します

          ‘%e’
               エンコーディング

          ‘%s’
               件名(subject)

          ‘%f’
               ファイル名に適した、サニタイズされた件名

          ‘%b’
               本文(body)

          ‘%B’
               生本文(raw body)(ラップされてない件名と本文)

          ‘%N’
               コミットノート(commit notes)

          ‘%GG’
               署名されたコミットの為のGPSからの生の検証メッセージ

          ‘%G?’

               G
                    良い(good)な(有効な)署名の場合はこの文字に置換されま
                    す。

               B
                    悪い署名(bad signature)の場合はこの文字に置換されま
                    す。

               U
                    有効性が不明(unknown validity)な良い署名の場合はこの
                    文字に置換されます。

               X
                    期限切れ(eXpired)の良い署名の場合はこの文字に置換さ
                    れます。

               Y
                    期限切れのキーで作成された良い署名の場合はこの文字に
                    置換されます。

               R
                    取り消されたキーによって作成された良い署名の場合はこ
                    の文字に置換されます。

               E
                    署名を確認できない場合(キーの欠落など)の場合はこの文
                    字に置換されます。

               N
                    署名がない場合の場合はこの文字に置換されます。

          ‘%GS’
               署名されたコミットの署名者の名前を表示する

          ‘%GK’
               署名されたコミットに署名するために使用されるキーを表示す
               る

          ‘%GF’
               署名されたコミットに署名するために使用されるキーのフィン
               ガープリントを表示する

          ‘%GP’
               署名されたコミットに署名するためにサブキーが使用された 主
               キーのフィンガープリントを表示します

          ‘%GT’
               署名されたコミットに署名するために使用されるキーの信頼レ
               ベル(trust level)を表示します

          ‘%gD’
               reflogセレクター(例:‘refs/stash@{1}’ or ‘refs/stash@{2
               minutes ago}’) この形式は、 ‘-g’ オプションで説明されてい
               る規則に従います。 ‘@’ の前の部分は、コマンドラインで指定
               されたrefnameです(したがって、 ‘git log -g
               refs/heads/master’ は ‘refs/heads/master@{0}’ を生成しま
               す)。

          ‘%gd’
               短縮されたreflogセレクター。 ‘%gD’ と同じですが、 人間が
               読みやすいようにrefname部分が短縮されています(したがって
               、 ‘refs/heads/master’ は単に ‘master’ になります)。

          ‘%gn’
               reflog ID名

          ‘%gN’
               reflog ID名( .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ge’
               reflog ID 電子メールアドレス

          ‘%gE’
               reflog ID 電子メールアドレス( .mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%gs’
               reflog 件名

          ‘%(trailers[:options])’
               git-interpret-trailers(1) によって解釈されるようにボディ
               のトレーラーを表示します。 ‘trailers’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。いずれかのオプションが複数回提供された場合、それぞれ
               最後のものが優先されます。

               ブール値オプションは、オプションの値 ‘[=<BOOL>]’ を受け入
               れます。 値 ‘true’ 、‘false’ 、 ‘on’ 、‘off’ などはすべて
               受け入れられます。 git-config(1) の "EXAMPLES" の
               "boolean" サブセクションを参照してください。ブール値オプ
               ションが値なしで指定された場合、それは有効を指定した事に
               なります。

                  • ‘key=<K>’ は指定されたキーを持つトレーラーのみを表示
                    します。マッチングは大文字と小文字を区別せずに行われ
                    、末尾のコロンはオプションです。オプションが複数回指
                    定されている場合、いずれかのキーに一致するトレーラー
                    行が表示されます。このオプションは自動的に ‘only’ オ
                    プションを有効にして、トレーラーブロック内の非トレー
                    ラー行が非表示になるようにします。それが望ましくない
                    場合は、 ‘only=false’ で無効にすることができます。 た
                    とえば、 ‘%(trailers:key=Reviewed-by)’ は、キーが
                    ‘Reviewed-by‘のトレーラー行を表示します。

                  • ‘only[=<BOOL>]’ はトレーラーブロックに非トレーラー行
                    を含めるかどうかを選択します。

                  • ‘separator=<SEP>’ はトレーラー行の間に挿入される区切
                    り文字を指定します。このオプションが指定されていない
                    場合、各トレーラー行は改行文字で終了します。文字列
                    SEPには、上記のリテラルフォーマットコードが含まれる
                    場合があります。区切り文字としてコンマを使用するには
                    、次のオプションとして解析されないよう ‘%x2C’ を使用
                    する必要があります。 たとえば、
                    ‘%(trailers:key=Ticket,separator=%x2C )’ は、キーが
                    ‘Ticket’ であるすべてのトレーラー行をカンマとスペー
                    スで区切って表示します。

                  • ‘unfold[=<BOOL>]’ は interpret-trailer の ‘--unfold’
                    オプションが指定されたかのように動作させます。たとえ
                    ば、 ‘%(trailers:only,unfold=true)’ が展開され、すべ
                    てのトレーラー行が表示されます。

                  • ‘keyonly[=<BOOL>]’ トレーラーのキー部分のみを表示。

                  • ‘valueonly[=<BOOL>]’ トレーラーの値部分のみ表示。

                  • ‘key_value_separator=<SEP>’ トレーラー行の間に挿入さ
                    れる区切り文字を指定します。このオプションが指定され
                    ていない場合、各トレーラーのキーと値のペアは ": " で
                    区切られます。 それ以外の場合は、上記の
                    ‘separator=<SEP>’ と同じセマンティクスを共有します。

     *Note*

     一部のプレースホルダーは、リビジョントラバーサルエンジンに指定され
     た他のオプションに依存する場合があります。 たとえば、 ‘%g*’ reflogオ
     プションは、reflogエントリをトラバースしない限り(たとえば、 ‘git
     log -g’ によって)空の文字列を挿入します。コマンドラインで
     ‘--decorate’ がまだ指定されていない場合、 ‘%d’ と ‘%D’ プレースホル
     ダーは「短い」(short)装飾形式を使用します。

   プレースホルダーの ‘%’ の後に ‘+’ (プラス記号)を追加すると、プレース
ホルダーが空でない文字列に展開される場合に限り、展開の直前に改行が挿入さ
れます。

   プレースホルダーの ‘%’ の後に ‘-’ (マイナス記号)を追加すると、プレー
スホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべて
の改行が削除されます。

   プレースホルダーの ‘%’ の後に " " (スペース)を追加すると、プレースホ
ルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入
されます。

   • ‘tformat:’

     ‘tformat:’ 形式は、 "separator" セマンティクスの代わりに
     "terminator" セマンティクスを提供することを除いて、 ‘format:’ とま
     ったく同じように機能します。 つまり、各コミットには、エントリ間に区
     切り文字を配置するのではなく、メッセージターミネータ文字(通常は改行
     )が追加されます。 これは、「1行」形式と同様に、1行形式の最終エント
     リが新しい行で適切に終了することを意味します。 例えば:

          $ git log -2 --pretty=format:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973 -- NO NEWLINE

          $ git log -2 --pretty=tformat:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973

     加えて、 ‘%’ が含まれている認識されない文字列は、その前に
     ‘tformat:’ があるかのように解釈(interpret)されます。 たとえば、以下
     の2つは同等です:

          $ git log -2 --pretty=tformat:%h 4da45bef
          $ git log -2 --pretty=%h 4da45bef

DIFF FORMATTING
***************

デフォルトでは、 ‘git log’ はdiff出力を生成しません。以下のオプションを
使用して、各コミットによって行われた変更を表示できます。

   注意: ‘--diff-merges’ のバリエーション(短い ‘-m’、 ‘-c’、 ‘--cc’ オプ
ションを含む)の1つが明示的に指定されていない限り、マージコミットはdiffを
表示しませんし、‘--patch`のようなdiff書式が選択されていても、’-S‘のよう
な検索オプションと一致しません。例外は、‘–first-parent‘が使用されている
場合です。この場合、‘first-parent‘がデフォルトの書式です。

‘-p’
‘-u’
‘--patch’
     パッチを生成します(generating patches に関するセクションを参照)。

‘-s’
‘--no-patch’
     diff出力を抑制します。デフォルトでパッチを表示する ‘git show’ のよ
     うなコマンド、または ‘--patch’ の効果をキャンセルする場合に便利です
     。

‘--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc)’
‘--no-diff-merges’
     マージコミットに使用するdiff形式を指定します。 ‘--first-parent’ が
     使用されている場合を除き、デフォルトは ‘off’ です。使用されている場
     合は、 ‘first-parent’ がデフォルトです。

     ‘--diff-merges=(off|none)’
     ‘--no-diff-merges’
          マージコミットのdiffの出力を無効にします。暗黙の値を上書きする
          のに便利です。

     ‘--diff-merges=on’
     ‘--diff-merges=m’
     ‘-m’
          このオプションにより、マージコミットのdiff出力がデフォルトの形
          式で表示されます。 ‘-m’ は、 ‘-p’ も指定されている場合にのみ出
          力を生成します。デフォルトの形式は、 ‘log.diffMerges’ 構成パラ
          メーター(configuration parameter)を使用して変更できます。デフ
          ォルト値は ‘separate’ です。

     ‘--diff-merges=first-parent’
     ‘--diff-merges=1’
          このオプションにより、マージコミットは最初の親に関してのみ完全
          なdiffを表示します。

     ‘--diff-merges=separate’
          これにより、マージコミットは各親に関して完全なdiffを表示します
          。親ごとに個別のログエントリとdiffが生成されます。

     ‘--diff-merges=combined’
     ‘--diff-merges=c’

‘-c:’
     このオプションを使用すると、マージコミットのdiff出力は、親と結果の
     ペアごとの差分を一度に1つずつ表示するのではなく、各親からの差分をマ
     ージ結果に同時に表示します。さらに、すべての親から変更されたファイ
     ルのみが一覧表示されます。 ‘-c’ は ‘-p’ の機能を含んでいます。

     ‘--diff-merges=dense-combined’
     ‘--diff-merges=cc’
     ‘--cc’
          このオプションを使用すると、 ‘--diff-merges=Combined’ によって
          生成される出力は、親のコンテンツに2つの派生(variants)しかない
          、興味のないハンクを省略してさらに圧縮され、マージ結果は変更な
          しでそのうちの1つを選択します。 ‘--cc’ は ‘-p’ の機能を含んで
          います。

‘--combined-all-paths’
     このフラグにより、結合された差分(マージコミットに使用)にすべての親
     からのファイルの名前が一覧表示されます。したがって、これは
     ‘--diff-merges=[dense-]combined’ が使用されている場合にのみ有効であ
     り、ファイル名の変更が検出された場合(つまり、名前の変更またはコピー
     の検出が要求された場合)にのみ役立つ可能性があります。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。 ‘--patch’ の機
     能を含んでいます。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--raw’
     コミットごとに、生の差分形式を使用して変更の概要を表示します。
     git-diff(1) の "RAW OUTPUT FORMAT" セクションを参照してください。 こ
     れは、ログ自体をraw形式で表示することとは異なります。 これは
     ‘--format=raw’ で 実現できます。

‘--patch-with-raw’
     ‘-p --raw’ の同義語。

‘-t’
     diff出力にツリーオブジェクトを表示します。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--patch-with-stat’
     ‘-p --stat’ と同義語。

‘-z’
     改行(newline)ではなく、NULでコミットを区切ります。

     また、 ‘--raw’ または ‘--numstat’ を指定した場合は、パス名を難読化
     (munge)したり、出力フィールドターミネータとしてNULを使用したりしな
     いでください。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、 通常の文字以外(unusual characters)を含むパス名が引用符で囲
     まれます(git-config(1) 参照)。

‘--name-only’
     変更されたファイルの名前のみを表示します。 多くの場合、ファイル名は
     UTF-8でエンコードされます。 詳細については、 git-log(1) のマニュア
     ルページにあるエンコーディングに関する議論(the discussion about
     encoding)を参照してください。

‘--name-status’
     変更されたファイルの名前とステータスのみを表示します。ステータス文
     字の意味については、 ‘--diff-filter’ オプションの説明を参照してくだ
     さい。 ‘--name-only’ と同じように、ファイル名はしばしばUTF-8でエン
     コードされます。

‘--submodule[=<format>]’
     サブモジュールの違いをどのように表示するかを指定します。
     ‘--submodule=short’ を指定する場合、 short形式が使用されます。この
     形式は、範囲の最初と最後にコミットの名前を表示するだけです。
     ‘--submodule’ または ‘--submodule=log’ が指定されている場合、 log形
     式が使用されます。この形式では、 git-submodule(1) ‘summary’ のよう
     に範囲内のコミットが一覧表示されます。 ‘--submodule=diff’ が指定さ
     れている場合、 diff形式が使用されます。この形式は、コミット範囲間の
     サブモジュールの内容の変更のインラインdiffを示します。configオプシ
     ョンが設定されていない場合、デフォルトは ‘diff.submodule’ または
     ‘short’ 形式です。

‘--color[=<when>]’
     色付きのdiffを表示します。 ‘--color’ (つまり、 ‘=<when>’ 無し) は
     ‘--color=always’ と同じです。 <when> は、 always または never また
     は auto のいずれかになります。

‘--no-color’
     カラーdiffをオフにします。 ‘--color=never’ と同じです。

‘--color-moved[=<mode>]’
     ソースコードの移動した行を別の色にします。 <mode>は、オプションが指
     定されていない場合はデフォルトで no になり、 モードが指定されていな
     いオプションが指定されている場合は zebra になります。 モードは以下
     のいずれかでなければなりません:

     no
          移動行をハイライトしません。

     default
          zebra の同義語です。これは、将来、より賢明なモードに変更される
          可能性があります。

     plain
          ある場所で追加され、別の場所で削除された行は、
          ‘color.diff.newMoved’ で色付けされます。 同様に、
          ‘color.diff.oldMoved’ は、差分の別の場所に追加された削除された
          行に使用されます。このモードは移動された行をピックアップします
          が、コードのブロックが順列なしで移動されたかどうかを判断するこ
          とはレビューではあまり役に立ちません。

     blocks
          少なくとも20文字の英数字の移動テキストのブロックが貪欲に検出さ
          れます。検出されたブロックは、 ‘color.diff.{old,new}Moved’ 色
          のいずれかを使用して色付けされます。隣接するブロックを区別する
          ことはできません。

     zebra
          移動されたテキストのブロックは、 _blocks_ モードの場合と同様に
          検出されます。 ブロックは、 _color.diff.{old,new}Moved_ 色また
          は _color.diff.{old,new}MovedAlternative_ 色のいずれかを使用し
          て色付けされます。2つの色の間の変化は、新しいブロックが検出さ
          れたことを示します。

     dimmed-zebra
          _zebra_ に似ていますが、移動されたコードの重要でない部分の追加
          の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は
          興味深いと見なされ、残りは興味深いものではありません。
          ‘dimmed_zebra’ は非推奨の同義語です。

‘--no-color-moved’
     移動検出をオフにします。 これは、構成設定を上書きするために使用でき
     ます。 ‘--color-moved=no’ と同じです。

‘--color-moved-ws=<modes>’
     これは、 ‘--color-moved’ の移動検出を実行するときに空白を無視する方
     法を設定します。 これらのモードは、コンマ区切りのリストとして指定で
     きます:

     no
          移動行検出を実行するときに、空白(whitespace)を無視しない。

     ignore-space-at-eol
          行末(EOL)での空白(whitespace)の変更を無視します。

     ignore-space-change
          空白(whitespace)の数の変更は無視してください。これは、行末の空
          白(whitespace)を無視し、1つ以上の空白文字(whitespace
          characters)の他のすべてのシーケンスを同等と見なします。

     ignore-all-space
          行を比較するときは空白(whitespace)を無視します。これにより、一
          方の行に空白があり、もう一方の行に空白がない場合でも、違いは無
          視されます。

     allow-indentation-change
          最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変
          更が行ごとに同じである場合にのみ、移動されたコードブロックをブ
          ロックにグループ化します。 これは他のモードと互換性がありませ
          ん。

‘--no-color-moved-ws’
     移動検出を実行するときは、空白(whitespace)を無視しないでください。
     これは、構成設定を上書きするために使用できます。
     ‘--color-moved-ws=no’ と同じです。

‘--word-diff[=<mode>]’
     <mode> を使用して変更された単語を区切ることにより、単語のdiffを表示
     します。デフォルトでは、単語は空白で区切られます。 以下の
     ‘--word-diff-regex’ を参照してください。 <mode> のデフォルトは
     ’plain’です。 <mode> は以下のいずれかである必要があります:

     color
          変更された単語(word)を色のみを使用して強調表示します。
          ‘--color’ を意味します。

     plain
          単語を ‘[-removed-]’ および ‘{+added+}’ として表示します。 区
          切り文字が入力に表示されている場合、区切り文字をエスケープしよ
          うとしないため、出力があいまいになる可能性があります。

     porcelain
          スクリプトの使用を目的とした特別な行ベースの形式を使用します。
          追加/削除/無変更については、通常の統一されたdiff形式で印刷され
          、行の先頭の ‘+’/‘-’/‘ ‘ 文字で始まり、行の終わりまで続きます
          。入力の改行は、それ自体の行のチルダ ‘~’ で表されます。

     none
          単語(word)のdiffを再度無効にします。

     注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべ
     てのモードで変更された部分を強調するために色が使用されることに注意
     してください。

‘--word-diff-regex=<regex>’
     空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるか
     を決定します。また、すでに有効になっていない限り、この機能は
     ‘--word-diff’ の機能を含んでいます。

     <regex> の重複しないマッチはすべて、単語と見なされます。これらのマ
     ッチの間のすべては空白と見なされ、違いを見つけるためとしては無視さ
     れます！ 正規表現に ‘|[^[:space:]]’ を追加して、空白以外のすべての
     文字とマッチすることを確認することをお勧めします。改行を含むマッチ
     は、改行で黙って切り捨てられます！

     たとえば、 ‘--word-diff-regex=.’ は各文字を単語として扱い、それに応
     じて文字ごとの違いを表示します。

     正規表現は、diffドライバーまたは構成オプション(configuration
     option)を介して設定することもできます。 gitattributes(5) または
     git-config(1) を参照してください。これを指定すると、diffドライバー
     または構成設定(configuration settings)が明示的にオーバーライドされ
     ます。diffドライバーは構成設定を上書きします。

‘--color-words[=<regex>]’
     ‘--word-diff=color’ に ‘--word-diff-regex=<regex>’ を加えたものに相
     当します(正規表現が指定されている場合)。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--check’
     変更によって競合マーカーまたは空白エラーが発生した場合に警告します
     。空白エラーと見なされるものは、 ‘core.whitespace’ 構成によって制御
     されます。 デフォルトでは、末尾の空白(空白のみで構成される行を含む
     )と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空
     白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータ
     スで終了します。なお、 –exit-code とは互換性がありません。

‘--ws-error-highlight=<kind>’
     diffの ‘context’ または ‘old’ または ‘new’ 行の空白エラーを強調表示
     します。複数の値はコンマで区切られ、 ‘none’ は前の値をリセットし、
     ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は old、new、
     context の省略形です。このオプションが指定されておらず、構成変数
     ‘diff.wsErrorHighlight’ が設定されていない場合、 ‘new’ 行の空白エラ
     ーのみが強調表示されます。空白エラーは ‘color.diff.whitespace’ で色
     分けされています。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。 ‘--patch’ の機能を含んでいます。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     diffを生成する場合は、コミットごとに名前の変更を検出して報告します
     。 履歴をトラバースしながら名前を変更してファイルをフォローする方法
     については、 ‘--follow’ を参照してください。 ‘n’ が指定されている場
     合、それは類似性インデックスのしきい値です (つまり、ファイルのサイ
     ズと比較した追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以
     上が変更されていない場合、 Gitが削除/追加のペアを名前変更と見なす必
     要があることを意味します。 ‘%’ 記号がない場合、数値は小数として読み
     取られ、その前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、
     ‘-M50%’ と同じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検
     出を正確な名前変更に制限するには、 ‘-M100%’ を使用します。 デフォル
     トの類似性インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]’
     追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更
     (Rename)されたファイル、タイプが変更されたファイル(T)、マージされて
     いないファイル(U)、不明なファイル(X)、またはペアリングが壊れている
     ファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合
     わせを使用できます。 組み合わせに ‘*’ (全てまたは無し)が追加される
     と、比較で他の基準に一致するファイルがある場合、すべてのパスが選択
     されます。 他の基準に一致するファイルがない場合、何も選択されません
     。

     また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定し
     ます。例えば ‘--diff-filter=ad’ は、追加および削除されたパスを除外
     します。

     注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意
     してください。 たとえば、インデックスから作業ツリーへのdiffにエント
     リを追加することはできません(diffに含まれるパスのセットは、インデッ
     クスの内容によって制限されるため)。 同様に、これらのタイプの検出が
     無効になっている場合、コピーおよび名前変更されたエントリは表示され
     ません。

‘-S<string>’
     ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の
     差分を調べます。スクリプターが使用することを目的としています。

     (構造体など)コードの正確なブロックを探していて、そのブロックが最初
     に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し
     使用して、プリイメージ(preimage)内の興味深いブロックを ‘-S’ にフィ
     ードバックし、そしてあなたはそれをブロックの最初のバージョンを取得
     するまで続けます。

     バイナリファイルも検索されます。

‘-G<regex>’
     パッチテキストに <regex> にマッチする 追加/削除 された行が含まれて
     いる差分を探します。

     ‘-S<regex> --pickaxe-regex’ と ‘-G<regex>’ の違いを説明するために、
     同じファイル内で以下のdiffを使用してコミットすることを検討してくだ
     さい:

          +    return frotz(nitfol, two->ptr, 1, 0);
          ...
          -    hit = frotz(nitfol, mf2.ptr, 1, 0);

     ‘git log -G"frotz\(nitfol"’ はこのコミットを表示しますが、 ‘git log
     -S"frotz\(nitfol" --pickaxe-regex’ は表示しません(その文字列の出現
     回数が変更されなかったため)。

     ‘--text’ が提供されていない限り、 textconv フィルターのないバイナリ
     ファイルのパッチは無視されます。

     詳細については gitdiffcore(7) の「pickaxe」エントリを参照してくださ
     い。

‘--find-object=<object-id>’
     指定されたオブジェクトの出現回数を変更する違いを探します。 ‘-S’ と
     同様に、引数だけが異なり、特定の文字列ではなく特定のオブジェクト
     IDを検索します。

     オブジェクトは、ブロブまたはサブモジュールのコミットにすることがで
     きます。 これは、 ‘git-log’ の ‘-t’ オプションがツリーも探すことを
     意味します。

‘--pickaxe-all’
     ‘-S’ または ‘-G’ が変更を見つけたら、 <string> の変更を含むファイル
     だけでなく、その変更セット(changeset)のすべての変更を表示します。

‘--pickaxe-regex’
     ‘-S’ に指定した <string> を拡張POSIX正規表現として扱います。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘-R’
     2つの入力を交換します。 つまり、インデックスまたはディスク上のファ
     イルとツリーの内容の違いを表示します。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

Generating patch text with -p
*****************************

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、
git-diff-tree(1) 、 git-diff-files(1) に ‘-p’ オプションを付けて実行する
とパッチテキストを生成します。パッチテキストの作成は、
‘GIT_EXTERNAL_DIFF’ と ‘GIT_DIFF_OPTS’ 環境変数( git(1) 参照)、および
‘diff’ 属性( gitattributes(5) 参照)を介してカスタマイズできます。

   -pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります:

          diff --git a/file1 b/file2

     名前の変更/コピーが含まれない限り、 ‘a/’ と ‘b/’ のファイル名は同じ
     です。 特に、作成または削除の場合でも、 ‘a/’ または ‘b/’ ファイル名
     の代わりに ‘/dev/ null’ が使用されることはありません。

     名前変更/コピーが含まれる場合、 ‘file1’ と‘file2‘ は、それぞれ名前
     変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファ
     イルの名前を示します。

  2. その後に、1つ以上の拡張ヘッダー行達が続きます:

          old mode <mode>
          new mode <mode>
          deleted file mode <mode>
          new file mode <mode>
          copy from <path>
          copy to <path>
          rename from <path>
          rename to <path>
          similarity index <number>
          dissimilarity index <number>
          index <hash>..<hash> <mode>

     ファイルモードは、ファイルタイプとファイル許可ビットを含む6桁の8進
     数として出力されます。

     拡張ヘッダーのパス名には、 ‘a/’ および ‘b/’ プレフィックスは含まれ
     ません。

     類似インデックス(similarity index)は変更されていない行のパーセンテ
     ージであり、非類似インデックス(dissimilarity index)は変更された行の
     パーセンテージです。これは切り捨てられた整数であり、その後にパーセ
     ント記号が続きます。したがって、100％の類似インデックス値は2つの等
     しいファイルを表し、100％の非類似性は古いファイルから新しいファイル
     に移行された行がないことを意味します。

     インデックス行には、変更前後のブロブオブジェクト名が含まれます。
     <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の
     場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、
     構成変数 ‘core.quotePath’ で説明されているように引用符で囲まれてい
     ます( git-config(1)参照)。

  4. 出力内のすべての ‘file1’ ファイルはコミット前のファイルを参照し、す
     べての ‘file2’ ファイルはコミット後のファイルを参照します。各変更を
     各ファイルに順番に適用するのは誤りです。たとえば、以下のパッチはaと
     bを交換します:

          diff --git a/a b/b
          rename from a
          rename to b
          diff --git a/b b/a
          rename from b
          rename to a

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されていま
     す。特定の言語に合わせてこれを調整する方法の詳細については、
     gitattributes(5) の "Defining a custom hunk-header" を参照してくだ
     さい。

Combined diff format
********************

diffを生成するコマンドは、マージを表示するときに ‘-c’ または ‘--cc’ オプ
ションを使用して「合成diff」(combined diff)を生成できます。これは
git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形
式です。 注意: これらのコマンドのいずれかに適切な ‘--diff-merges’ オプシ
ョンを指定して、特定の形式で差分を強制的に生成できることにも注意してくだ
さい。

   合成diff形式は以下のようになります:

     diff --combined describe.c
     index fabadb8,cc95eb0..4866510
     --- a/describe.c
     +++ b/describe.c
     @@@ -98,20 -98,12 +98,20 @@@
             return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

     - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
     ++static void describe(char *arg, int last_one)
       {
      +      unsigned char sha1[20];
      +      struct commit *cmit;
             struct commit_list *list;
             static int initialized = 0;
             struct commit_name *n;

      +      if (get_sha1(arg, sha1) < 0)
      +              usage(describe_usage);
      +      cmit = lookup_commit_reference(sha1);
      +      if (!cmit)
      +              usage(describe_usage);
      +
             if (!initialized) {
                     initialized = 1;
                     for_each_ref(get_name);

  1. まず "git diff" ヘッダーがあり、以下のようになります( ‘-c’ オプショ
     ンが使用されている場合):

          diff --combined file

     または、以下のようになります( ‘--cc’ オプションが使用されている場合
     ):

          diff --cc file

  2. その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマ
     ージを示しています):

          index <hash>,<hash>..<hash>
          mode <mode>,<mode>..<mode>
          new file mode <mode>
          deleted file mode <mode>,<mode>

     ‘mode <mode>,<mode>..<mode>’ 行は、<mode> の少なくとも1つが他の
     <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動
     (名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの
     <tree-ish> のdiffで機能するように設計されており、合成diff形式では使
     用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます

          --- a/file
          +++ b/file

     従来の統一diff形式の2行ヘッダーと同様に、 ‘/dev/null’ は、作成また
     は削除されたファイルを通知するために使用されます。

     ただし、 –combined-all-paths オプションが指定されている場合、2行の
     from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダー
     が取得されます。ここで、 N はマージコミットの親の数です。

          --- a/file
          --- a/file
          --- a/file
          +++ b/file

     この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち
     、別の親のファイルの元の名前を確認できます。

  4. チャンクヘッダーの形式が変更され、誤って ‘patch-p1’ にフィードされ
     るのを防ぎます。合成差分形式は、マージコミットの変更を確認するため
     に作成されたものであり、適用されることを意図したものではありません
     。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:

          @@@ <from-file-range> <from-file-range> <to-file-range> @@@

     合成diff形式のチャンクヘッダーには親の数+1の ‘@’ 文字があります。

   従来の統一diff形式とは異なり、2つのファイルAとBが、 ‘-’ (マイナスは
Aに表示されますが、Bでは削除されます) または ‘+’ (プラスはAにはありませ
んが、Bには追加されます)、または ‘" "’（スペースは変更なし) プレフィック
スを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1,
file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示し
ます。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどの
ように異なるかを示します。

   列Nの ‘-’ 文字は、その行が fileN に表示されているが、結果には表示され
ていないことを意味します。 列Nの ‘+’ 文字は、結果に行が表示され、 fileN
にその行がないことを意味します(つまり、その親の観点から見て行が追加され
たことを示す)。

   上記の出力例では、関数のシグネチャが両方のファイルから見て変更されて
います(したがって、 file1 と file2 の両方から2つの ‘-’ が削除され、さら
に ‘++’ が追加されたため、 file1 と file2 のどちらにも表示されません)。
また、他の8行は file1 と同じですが、 file2 には表示されません(したがって
、接頭辞として ‘+’ が付けられます)。

   ‘git diff-tree -c’ で表示される場合、マージコミットの親をマージ結果と
比較します(つまり、 file1..fileN が親です)。 ‘git diff-files -c’ で表示
される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり
、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別
名「彼らのバージョン」です)。

EXAMPLES
********

‘git log --no-merges’
     コミット履歴全体を表示しますが、マージはスキップします

‘git log v2.6.12.. include/scsi drivers/scsi’
     バージョン v2.6.12 以降で include/scsi または drivers/scsi サブディ
     レクトリ内のファイルの変更がある、すべてのコミットを表示します

‘git log --since="2 weeks ago" -- gitk’
     gitk ファイルの変更について過去2週間の範囲で表示します。 ‘--’ は「
     ブランチ名のgitk」と混同しないようにするために必要です。

‘git log --name-status release..test’
     「test」ブランチにはあるがまだ「release」ブランチにはないコミットを
     、各コミットが変更するパスのリストとともに表示します。

‘git log --follow builtin/rev-list.c’
     ファイルに現在の名前が付けられる前に発生したコミット(訳注:つまりフ
     ァイル名が変更される前の当該ファイル)を含め、‘builtin/rev-list.c’ を
     変更したコミットを表示します。

‘git log --branches --not --remotes=origin’
     ローカルブランチ origin にあり、 origin のリモート追跡ブランチのい
     ずれにも存在していないコミットを表示します。

‘git log master --not --remotes=*/master’
     ローカルmasterにはあるが、リモートリポジトリmasterブランチにはない
     すべてのコミットを表示します。

‘git log -p -m --first-parent’
     変更の差分を含む履歴を表示しますが、「主ブランチ」の観点からのみ、
     マージされたブランチからのコミットをスキップし、マージによって導入
     された変更の完全な差分を表示します。これは、単一の統合ブランチにと
     どまり、そのブランチにすべてのトピックブランチをマージするという厳
     格なポリシーに従う場合にのみ意味があります。

‘git log -L '/int main/',/^}/:main.c’
     ファイル ‘main.c’ の関数 ‘main()’ が時間の経過とともにどのように進
     化したかを示します。

‘git log -3’
     表示するコミットの数を3個に制限します。

DISCUSSION
**********

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

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

   • パス名はUTF-8正規化形式C(UTF-8 normalization form C)でエンコードさ
     れます。これは、ツリーオブジェクト、インデックスファイル、ref名、お
     よびコマンドライン引数、環境変数、構成ファイル( ‘.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. ‘git commit’ と ‘git commit-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への再コーディングは必ずしも可逆的な操作ではないため、我々はコミ
ットが行われたときにコミットログメッセージを再コーディングしないことを意
図的に選択したことに注意してください。

CONFIGURATION
*************

コア変数については git-config(1) を、diff生成に関連する設定については
git-diff(1) を参照してください。

format.pretty
     ‘--format’ オプションのデフォルト。(上記「Pretty Formats」を参照し
     てください。)デフォルトは medium です。

i18n.logOutputEncoding
     ログを表示するときに使用するエンコーディング。(上記「Discussion」を
     参照してください。)デフォルトでは、設定されている場合は
     ‘i18n.commitEncoding’ の値になり、そうでない場合は UTF-8 になります
     。

log.date
     人間が読める形式の日付のデフォルト形式。 (‘--date’ オプションと比べ
     てみてください。) デフォルトは default です。これは、‘Sat May 8
     19:35:34 2010 -0500’ のような日付を書き込むことを意味します。

     フォーマットが auto:foo に設定されていて、かつ、ページャーが使用さ
     れている場合、フォーマット foo が日付フォーマットに使用されます。そ
     れ以外の場合は default が使用されます。

log.follow
     trueの場合、‘git log’ は、単一の<path>が指定されたときに ‘--follow’
     オプションが使用されたかのように機能します。これには ‘--follow’ と
     同じ制限があります。つまり、複数のファイルを追跡するために使用する
     ことはできず、非線形履歴(non-linear history)ではうまく機能しません
     。

log.showRoot
     falseの場合、 ‘git log’ および関連するコマンドは最初のコミットを大
     きな作成イベント(big creation event)として扱いません。 ‘git log -p’
     出力のルートコミットは、差分を添付せずに表示されます。デフォルトは
     true です。

log.showSignature
     trueの場合、 ‘git log’ および関連するコマンドは ‘--show-signature’
     オプションが渡されたかのように動作します。

mailmap.*
     git-shortlog(1) 参照。

notes.displayRef
     ‘core.notesRef‘または GIT_NOTES_REF によって設定されたデフォルトに
     加えて、コマンドのlogファミリーでコミットメッセージを表示するときに
     メモを読み取るためのrefs。git-notes(1)を参照してください。

     省略されていないref名またはグロブ(glob)である可能性があり、複数回指
     定される可能性があります。存在しないrefsに対しては警告が発行されま
     すが、どのrefsとも一致しないグロブ(glob)は黙って無視されます。

     この設定は、‘--no-notes’ オプションで無効にしたり、
     GIT_NOTES_DISPLAY_REF 環境変数で上書きしたり、 ‘--notes=<ref>’ オプ
     ションで上書きしたりできます。

GIT
***

Part of the git(1) suite

Name
****

git-ls-files — インデックスと作業ツリーのファイルに関する情報を表示する

Synopsis
********

     git ls-files [-z] [-t] [-v] [-f]
                     (–[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
                     (-[c|d|o|i|s|u|k|m])*
                     [–eol]
                     [–deduplicate]
                     [-x <pattern>|–exclude=<pattern>]
                     [-X <file>|–exclude-from=<file>]
                     [–exclude-per-directory=<file>]
                     [–exclude-standard]
                     [–error-unmatch] [–with-tree=<tree-ish>]
                     [–full-name] [–recurse-submodules]
                     [–abbrev[=<n>]] [–] [<file>…]

DESCRIPTION
***********

これにより、インデックス内のファイルリストが実際の作業ディレクトリリスト
とマージされ、2つのさまざまな組み合わせが表示されます。

   以下の1つ以上のオプションを使用して、表示されるファイルを判別できます
:

OPTIONS
*******

‘-c’
‘--cached’
     キャッシュされたファイルを出力に表示します(デフォルト)

‘-d’
‘--deleted’
     削除されたファイルを出力に表示します

‘-m’
‘--modified’
     変更されたファイルを出力に表示

‘-o’
‘--others’
     その他(たとえば 追跡されていない)ファイルを出力に表示します

‘-i’
‘--ignored’
     無視されたファイル(ignored files)のみを出力に表示します。インデック
     のファイルを表示する場合は、除外パターンに一致するファイルのみを印
     刷してください。 「その他」のファイルを表示する場合は、除外パターン
     に一致するファイルのみを表示してください。標準の無視ルールは自動的
     にアクティブ化されないため、少なくとも1つの ‘--exclude*’ オプション
     が必要です。

‘-s’
‘--stage’
     ステージングされたコンテンツのモードビット、オブジェクト名、ステー
     ジ番号を出力に表示します。

‘--directory’
     ディレクトリ全体が「その他」に分類される場合は、(末尾にスラッシュを
     付けて)そのディレクトリ名だけを表示し、ディレクトリの内容を表示しな
     いでください。

‘--no-empty-directory’
     空のディレクトリをリストしないでください。 ‘--directory’ を指定して
     いないと効果がありません。

‘-u’
‘--unmerged’
     マージされていないファイルを出力に表示します(‘--stage’ の機能を含む
     )

‘-k’
‘--killed’
     checkout-indexを成功させるために、ファイル/ディレクトリの競合のため
     に削除する必要があるファイルシステム上のファイルを表示します。

‘-z’
     \ 0出力での行の終了であり、ファイルをクォートしません。 詳細につい
     ては、以下の「OUTPUT」を参照してください。

‘--deduplicate’
     ファイル名のみが表示されている場合は、マージ中に複数のステージがあ
     ること、または ‘--deleted’ と ‘--modified’ オプションを同時に指定す
     ることで発生する可能性のある重複を抑制します。 ‘-t’ または
     ‘--unmerged’ または ‘--stage’ オプションのいずれかが使用されている
     場合、このオプションは効果がありません。

‘-x <pattern>’
‘--exclude=<pattern>’
     パターンに一致する追跡されていないファイルをスキップします。パター
     ンはシェルワイルドカードパターンであることに注意してください。 詳細
     については、以下の「EXCLUDE PATTERNS」を参照してください。

‘-X <file>’
‘--exclude-from=<file>’
     <file> から除外パターンを読み取ります。1行に1つづつです。

‘--exclude-per-directory=<file>’
     各ディレクトリとサブディレクトリにのみ適用される、追加の除外パター
     ンを、そのディレクトリの <file> から読み取ります。(通常は
     ‘.gitignore’ )

‘--exclude-standard’
     標準のGit除外を追加します: .git/info/exclude と 各ディレクトリの
     .gitignore と ユーザーのグローバル除外ファイル。

‘--error-unmatch’
     <file> がインデックスに現れない場合は、これをエラーとして扱います
     (1を返します)。

‘--with-tree=<tree-ish>’
     ‘--error-unmatch’ を使用して、ユーザーが指定した <file>（つまり、パ
     スパターン）引数をパスに展開する場合、名前付きの <tree-ish> がまだ
     存在するためにインデックスから削除されたパスを装います。 このオプシ
     ョンを ‘-s’ または ‘-u’ オプションと一緒に使用しても意味がありませ
     ん。

‘-t’
     この機能は準非推奨です。スクリプト化の目的では、 git-status(1)
     ‘--porcelain’ と git-diff-files(1) ‘--name-status’ がほとんどの場合
     優れた代替手段であり、さらにユーザーフレンドリーな代替手段について
     は、 git-status(1) ‘--short’ または git-diff(1) ‘--name-status’ を
     ご覧下さい。

     このオプションは、各行の先頭にある以下のタグ(スペースが続く)でファ
     イルのステータスを識別します:

     H
          cached

     S
          skip-worktree

     M
          unmerged

     R
          removed/deleted

     C
          modified/changed

     K
          to be killed

     ?
          other

‘-v’
     ‘-t’ に似ていますが、「assume unchanged」(変更されていないと仮定す
     る)とマークされたファイルには小文字を使用します(git-update-index(1)
     を参照)。

‘-f’
     ‘-t’ に似ていますが、「fsmonitor valid」とマークされているファイル
     には小文字を使用します(git-update-index(1) を参照)。

‘--full-name’
     サブディレクトリから実行する場合、コマンドは通常、現在のディレクト
     リからの相対パスを出力します。 このオプションは、プロジェクトの最上
     位ディレクトリを基準にしたパスを強制的に出力します。

‘--recurse-submodules’
     リポジトリ内のアクティブなサブモジュールごとに ls-files を再帰的に
     呼び出します。 現在、 ‘--cached’ モードのみがサポートされています。

‘--abbrev[=<n>]’
     40バイトの16進数のオブジェクト行全体を表示する代わりに、オブジェク
     トを一意に参照する、少なくとも <n> の長さ16進数の長さの最短のプレフ
     ィックスを表示します。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で指
     定できます。

‘--debug’
     ファイルを説明する各行の後に、そのキャッシュエントリに関するデータ
     を追加します。これは、手動検査のために可能な限り多くの情報を表示す
     ることを目的としています。正確な形式は予告なく変更される可能性があ
     ります。

‘--eol’
     ファイルの <eolinfo> と <eolattr> を表示します。 <eolinfo> は、「
     text」属性が「auto」の場合(または設定されておらず、 core.autocrlf が
     false でない場合)にGitが使用するファイルコンテンツIDです。
     <eolinfo> は、「-text」、「none」、「lf」、「crlf」、「mixed」、「
     」のいずれかです。

     「」は、ファイルが通常のファイルではない、インデックスにない、また
     は作業ツリーでアクセスできないことを意味します。

     <eolattr> は、チェックアウトまたはコミット時に使用される属性であり
     、「」・「-text」・「text」・「text=auto」・「text eol=lf」・「text
     eol=crlf」 のいずれかです。 Git 2.10以降では「text=auto eol=lf」と
     「text=auto eol=crlf」がサポートされています。

     通常のファイルの場合、インデックス("i/<eolinfo>")と作業ツリー
     ("w/<eolinfo>")の両方の<eolinfo>が表示され、そのうしろに
     "attr/<eolattr>" が続きます。

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

<file>
     表示するファイル。ファイルが指定されていない場合、他の指定された基
     準に一致するすべてのファイルが表示されます。

OUTPUT
******

_git ls-files_ は、 ‘--stage’ が指定されていない限り、ファイル名を出力す
るだけです。指定されている場合は、以下のように出力されます:

     [<tag> ]<mode> <object> <stage> <file>

   _git ls-files –eol_ の場合:
i/<eolinfo><SPACES>w/<eolinfo><SPACES>attr/<eolattr><SPACE*><TAB><file>

   ‘git ls-files --unmerged’ と ‘git ls-files --stage’ を使用して、マー
ジされていないパスの詳細情報を調べることができます。

   マージされていないパスの場合、単一の モード/SHA-1 ペアを記録する代わ
りに、インデックスは最大3つのそのようなペアを記録します。 ステージ1のツ
リーOから一つと、ステージ2のAから一つと、ステージ3のBからの一つです。こ
の情報は、ユーザー(または磁器コマンド)がパスに最終的に記録する内容を確認
するために使用できます。(状態の詳細については、 git-read-tree(1) を参照
してください)

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、「異常な」文字を含むパス名がクォートされます(git-config(1)
を参照)。 ‘-z’ を使用すると、ファイル名がそのまま出力され、行はNULバイト
で終了します。

EXCLUDE PATTERNS
****************

_git ls-files_ は、ディレクトリツリーをトラバースし、フラグ ‘--others’ ま
たは ‘--ignored’ が指定されている場合に表示するファイルを検索するときに
、「除外パターン」(exclude patterns)のリストを使用できます。
gitignore(5) は、除外パターンの形式を指定します。

   これらの除外パターンは、以下の順序で取得されます:

  1. コマンドラインフラグ ‘--exclude=<pattern>’ は、単一のパターンを指定
     します。 パターンは、コマンドラインに現れるのと同じ順序で並べられま
     す。

  2. コマンドラインフラグ ‘--exclude-from=<file>’ は、パターンのリストを
     含むファイルを指定します。 パターンは、ファイルに現れるのと同じ順序
     で並べられます。

  3. コマンドラインフラグ ‘--exclude-per-directory=<name> ` は、 'git
     ls-files' が調べる各ディレクトリ内のファイルの名前(通常は
     `.gitignore’ )を指定します。 より深いディレクトリ内のファイルが優先
     されます。パターンは、ファイルに現れるのと同じ順序で並べられます。

   コマンドラインで ‘--exclude’ で指定されたパターン、または
‘--exclude-from’ で指定されたファイルから読み取られたパターンは、ディレ
クトリツリーの最上位を基準にしています。 ‘--exclude-per-directory’ で指
定されたファイルから読み取られたパターンは、パターンファイルが置かれてい
るディレクトリを基準にしています。

SEE ALSO
********

git-read-tree(1), gitignore(5)

GIT
***

Part of the git(1) suite

Name
****

git-ls-remote — リモートリポジトリの参照を一覧表示する

Synopsis
********

     git ls-remote [–heads] [–tags] [–refs] [–upload-pack=<exec>]
                   [-q | –quiet] [–exit-code] [–get-url] [–sort=<key>]
                   [–symref] [<repository> [<refs>…]]

DESCRIPTION
***********

リモートリポジトリで有効な参照を、関連するコミットIDとともに表示します。

OPTIONS
*******

‘-h’
‘--heads’
‘-t’
‘--tags’
     それぞれ、refs/heads と refs/tags のみに制限します。これらのオプシ
     ョンは相互に排他的ではありません。両方を指定すると、 refs/heads と
     refs/tags に保存されている参照が表示されます。コマンドラインで他に
     何も指定せずに使用された ‘git ls-remote -h’ は、他のgitサブコマンド
     と同じようにヘルプを提供することに注意してください。

‘--refs’
     ピーリングされたタグ(peeled tag)や ‘HEAD’ のような疑似参照
     (pseudoref)を出力に表示しないでください。

‘-q’
‘--quiet’
     stderrにリモートURLを出力しないでください。

‘--upload-pack=<exec>’
     リモートホストの「git-upload-pack」のフルパスを指定します。これによ
     り、SSH経由でアクセスされ、SSHデーモンがユーザーによって構成された
     PATHを使用しないリポジトリからの参照を一覧表示できます。

‘--exit-code’
     リモートリポジトリに一致する参照が見つからない場合は、ステータス「
     2」で終了します。通常、コマンドはステータス「0」で終了し、一致する
     参照が見つかったかどうかに関係なく、リモートリポジトリと正常に通信
     したことを示します。

‘--get-url’
     ‘url.<base>.insteadOf’ 構成設定(git-config(1)を参照)を考慮して、指
     定されたリモートリポジトリのURLを展開し、リモートと通信せずに終了し
     ます。

‘--symref’
     それが指すオブジェクトに加えて、シンボリックrefを表示するときに、そ
     れが指す基になるrefを表示します。 現在、upload-packはsymref HEADの
     みを表示するため、ls-remoteによって表示されるのはこれだけです。

‘--sort=<key>’
     指定されたキーに基づいて並べ替えます。接頭辞 ‘-’ を使用して、値の降
     順で並べ替えます。 ‘version:refname’ または ‘v:refname’ をサポート
     します(タグ名はバージョンとして扱われます)。 ‘version:refname’ のソ
     ート順は、 ‘versionsort.suffix’ 構成変数の影響も受ける可能性があり
     ます。 その他の並べ替えオプションについては git-for-each-ref(1) を
     参照してください。ただし、オブジェクト自体へのアクセスを必要とする
     ‘committerdate’ のようなキーは、オブジェクトがまだリモートからフェ
     ッチされていないrefに対しては機能せず、 ‘missing object’ エラーが発
     生することに注意してください。

‘-o <option>’
‘--server-option=<option>’
     プロトコルバージョン2を使用して通信する場合は、指定された文字列をサ
     ーバーに送信します。指定された文字列には、NULまたはLF文字を含めるこ
     とはできません。 複数の ‘--server-option=<option>’ が指定されている
     場合、それらはコマンドラインにリストされている順序で送信されます。

<repository>
     クエリする「リモート」リポジトリ。 このパラメーターは、URLまたはリ
     モートの名前のいずれかです(git-fetch(1) の「GIT URLS」と「REMOTES」
     セクションを参照してください)。

<refs>…
     指定しない場合、 ‘--heads’ と ‘--tags’ でフィルタリングを行った後の
     すべての参照が表示されます。 <refs>… を指定すると、指定したパターン
     に一致する参照のみが表示されます。

EXAMPLES
********

     $ git ls-remote --tags ./.
     d6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99
     f25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1
     7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3
     c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2
     0918385dbd9656cab0d1d81ba7453d49bbc16250        refs/tags/junio-gpg-pub
     $ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
     5fe978a5381f1fbad26a80e682ddd2a401966740        refs/heads/master
     c781a84b5204fb294c9ccc79f8b3baceeb32c061        refs/heads/seen
     $ git remote add korg http://www.kernel.org/pub/scm/git/git.git
     $ git ls-remote --tags korg v\*
     d6602ec5194c87b0fc87103ca4d67251c76f233a        refs/tags/v0.99
     f25a265a342aed6041ab0cc484224d9ca54b6f41        refs/tags/v0.99.1
     c5db5456ae3b0873fc659c19fafdde22313cc441        refs/tags/v0.99.2
     7ceca275d047c90c0c7d5afb13ab97efdf51bd6e        refs/tags/v0.99.3

SEE ALSO
********

git-check-ref-format(1).

GIT
***

Part of the git(1) suite

Name
****

git-ls-tree — ツリーオブジェクトの内容を一覧表示します

Synopsis
********

     git ls-tree [-d] [-r] [-t] [-l] [-z]
                 [–name-only] [–name-status] [–full-name] [–full-tree] [–abbrev[=<n>]]
                 <tree-ish> [<path>…]

DESCRIPTION
***********

「/bin/ls -a」が現在の作業ディレクトリで行うことのように、特定のツリーオ
ブジェクトの内容を一覧表示します。 ただし以下の点に注意してください:

   • 動作は「/bin/ls」の動作とは少し異なり、「<path>」は一致するパターン
     のリストのみを示します。 したがって、( ‘-r’ なしで)ディレクトリ名を
     指定すると動作が異なり、引数の順序は重要ではありません。

   • _<path>_ が現在の作業ディレクトリを基準にして取得されるという点で、
     動作は「/bin/ls」の動作と似ています。例えば、あなたの現在の作業ディ
     レクトリが「sub」で、その下にサブディレクトリ「dir」がある場合は、
     「git ls-tree -r HEAD dir」を実行すると、「dir」ツリーの内容を一覧
     表示できます(つまり、「HEAD」の「sub/dir」) 。あなたが、ルートレベ
     ル以外のツリーを直接指定したいとします(たとえば ‘git ls-tree -r
     HEAD:sub dir’ と指定します)。しかし、この場合は結果として ‘HEAD’ コ
     ミットで ‘sub/sub/dir’ を要求したことになります(そしてそんなディレ
     クトリはないので何も表示されない)。ただし、 ‘--full-tree’ プション
     を渡すと、現在の作業ディレクトリを無視できます(つまり、 ‘git
     ls-tree --fulltree -r HEAD:sub dir’ とすれば意図したとおりに動く)

OPTIONS
*******

<tree-ish>
     ツリーっぽい何か(tree-ish)のID

‘-d’
     名前付きツリーエントリ自体のみを表示し、その子供たちは表示しません
     。

‘-r’
     サブツリーに再帰的に入っていきます

‘-t’
     サブツリーに再帰的入っていく場合でも、ツリーエントリを表示します。
     ‘-r’ が渡されなかった場合は効果がありません。 ‘-d’ は ‘-t’ の意味を
     含んでいます。

‘-l’
‘--long’
     ブロブ(ファイル)エントリのオブジェクトサイズを表示します。

‘-z’
     ‘\0’ (NULバイト)出力での行終了であり、ファイル名をクォートしません
     。 詳細については、以下の OUTPUT FORMAT を参照してください。

‘--name-only’
‘--name-status’
     (「long」出力ではなく)ファイル名のみを1行に1つずつリストします。

‘--abbrev[=<n>]’
     40バイトの16進オブジェクト行全体を表示する代わりに、オブジェクトを
     一意に参照できる、少なくとも _<n>_ 以上の長さの最短のプレフィックス
     を表示します。デフォルト以外の桁数は ‘--abbrev=<n>’ で指定できます
     。(訳注:手元ではデフォルトは10桁で表示された。 ‘--abbrev=1’ とする
     と5桁(一部6桁)表示となった)

‘--full-name’
     現在の作業ディレクトリに関連するパス名を表示する代わりに、フルパス
     名を表示します。

‘--full-tree’
     現在の作業ディレクトリを無視して、ルートレベルを起点として一覧表示
     します。 ‘--full-name’ の意味を含んでいます。

[<path>…]
     パスが指定されたら、それらを表示します(これは実際には生のパス名では
     なく、一致するパターンのリストであることに注意してください)。 それ
     以外の場合は、ツリーのルートレベルを唯一のパス引数として暗黙的に使
     用します。

Output Format
*************

     <mode> SP <type> SP <object> TAB <file>

   この出力形式は、「git update-index」の「–index-info—stdin」が期待する
ものと互換性があります。

   ‘-l’ オプションを使用すると、形式が以下のように変わります

     <mode> SP <type> SP <object> SP <object size> TAB <file>

   <object> で識別されるオブジェクトサイズはバイト単位で指定され、最小幅
7文字で右寄せされます。オブジェクトサイズは、ブロブ(ファイル)エントリに
対してのみ指定されます。他のエントリの場合、サイズの代わりに ‘-’ 文字が
使用されます。

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、「異常な」文字を含むパス名が引用符で囲まれます
(git-config(1) を参照)。 ‘-z’ を使用すると、ファイル名がそのまま出力され
、行はNULバイトで終了します。

GIT
***

Part of the git(1) suite

Name
****

git-mailinfo — 単一の電子メールメッセージからパッチと作成者を抽出します

Synopsis
********

     git mailinfo [-k|-b] [-u | –encoding=<encoding> | -n]
                    [–[no-]scissors] [–quoted-cr=<action>]
                    <msg> <patch>

DESCRIPTION
***********

標準入力から単一の電子メールメッセージを読み取り、コミットログメッセージ
を <msg> ファイルに書き込み、パッチを <patch> ファイルに書き込みます。作
者名と電子メールアドレスと電子メールの件名は、コミットを作成する ‘git
am’ で使用するために標準出力に書き出されます。通常、このコマンドをユーザ
ーが直接使用する必要はありません。代わりに git-am(1) を参照してください
。

OPTIONS
*******

‘-k’
     通常、プログラムは、 ‘Subject:’ ヘッダー行から電子メール特有の断片
     文字列を取り除き、コミットログメッセージのタイトル行を取り出します
     。このオプションは、この変更をある程度防ぎ、 ‘git format-patch -k’
     出力を読み返すために使用する場合に最も役立つようにします。

     具体的には、以下のものがなくなるまでは削除を行います:

        • 先頭と末尾の空白(whitespace)を削除。

        • 先頭の ‘Re:’ や ‘re:’ や ‘:’ を削除。

        • 先頭のブラケットで囲まれた文字列( ‘[’ 〜 ‘]’ 、 通常は
          ‘[PATCH]’ ) 。

     最後に、空白類(whitespace)は単一のASCIIスペース文字(\x20)に正規化さ
     れます。

‘-b’
     ‘-k’ が有効でない場合、 先頭のブラケット ‘[’ と ‘]’ のペアで囲まれ
     たすべての文字列が削除されます。このオプションは、括弧で囲まれた文
     字列に ‘PATCH’ という単語が含まれているペアのみに削除を制限します。

‘-u’
     コミットログメッセージ、作者名、作者の電子メールアドレスは電子メー
     ルから取得され、MIME転送エンコーディングを最小限にデコードした後、
     それらを変換することにより、 ‘i18n.commitEncoding’ (デフォルトは
     UTF-8) で指定された文字セットに再コーディングされます。これは以前は
     オプションでしたが、現在はデフォルトです。

     注意: このフラグがあっても、パッチは常に文字セット変換なしでそのま
     ま使用されることに注意してください。

‘--encoding=<encoding>’
     ‘-u’ に似ています。 ただし、再コーディング時には、
     ‘i18n.commitEncoding’ で指定された文字セットまたはUTF-8の代わりに、
     ここで指定した文字セットが使用されます。

‘-n’
     メタデータのすべての文字セットの再コーディングを無効にします。

‘-m’
‘--message-id’
     コミットメッセージの最後にあるMessage-IDヘッダーをコピーします。こ
     れは、コミットをメーリングリストのディスカッションに関連付けるのに
     役立ちます。

‘--scissors’
     本文で切り取り線(例えば ‘-- >8 --’ )の前にあるすべてを取り除きます
     。 この線は、はさみ(scissors)とミシン目マークを表しており、その行で
     メッセージをカットするように読者に要求するために使用されます。パッ
     チの前のメッセージの本文にその行が表示されている場合、このオプショ
     ンを使用すると、その行の前のすべて(切り取り線の行自体を含む)が無視
     されます(訳注: ‘>8’ や ‘8<’ は「ハサミ」を示す絵文字)。

     これは、返信するメッセージに関するコメントと提案を含むディスカッシ
     ョンスレッドでメッセージを開始し、パッチの送信でメッセージを終了し
     、ディスカッションと提案されたコミットログメッセージの開始を切り取
     り線で区切る場合に役立ちます。

     これは、構成オプション mailinfo.scissors を使用してデフォルトで有効
     にできます。

‘--no-scissors’
     切り取り線を無視します。 mailinfo.scissors 設定を上書きするのに便利
     です。

‘--quoted-cr=<action>’
     base64またはquoted-printableエンコーディングで送信された電子メール
     メッセージを処理し、デコードされた行が単純なLFではなくCRLFで終了す
     る場合の操作(action)を指定。

     有効な操作(action)は:

        • ‘nowarn’: そのようなCRLFが見つかった場合、Gitは何もしません。

        • ‘warn’: そのようなCRLFが見つかった場合、 Gitはメッセージごとに
          警告を発行します。

        • ‘strip’: GitはそれらのCRLFをLFに変換します。

     デフォルトの操作(action)は、構成オプション ‘mailinfo.quotedCR’ で設
     定できます。そのような構成オプションが設定されていない場合、 ‘warn’
     が使用されます。

<msg>
     電子メールから抽出されたコミットログメッセージ。通常、電子メールの
     件名から抽出したタイトル行は除きます。

<patch>
     電子メールから抽出されたパッチ。

GIT
***

Part of the git(1) suite

Name
****

git-mailsplit — 簡易 UNIX mbox 分割プログラム

Synopsis
********

     git mailsplit [-b] [-f<nn>] [-d<prec>] [–keep-cr] [–mboxrd]
                     -o<directory> [–] [(<mbox>|<Maildir>)…]

DESCRIPTION
***********

mboxファイルまたはMaildirを指定のディレクトリ内でファイルのリストに分割
し("0001" "0002" ..)、そこからさらに処理できるようにします。

     *Important*

     Maildirの分割は、ファイル名が正しい順序でパッチを出力するためにソー
     トされていることに依存しています。

OPTIONS
*******

<mbox>
     分割するmboxファイル。指定しない場合、mboxは標準入力から読み取られ
     ます。

<Maildir>
     分割するMaildirのルート。このディレクトリには、cur と tmp とnew サ
     ブディレクトリが含まれている必要があります。

‘-o<directory>’
     個々のメッセージを配置するディレクトリ。

‘-b’
     ファイルがFrom行で始まらない場合は、エラーにするのではなく、単一の
     メールメッセージであると想定してください。

‘-d<prec>’
     先行ゼロを含むデフォルトの4桁の代わりに、生成するファイル名に異なる
     桁数を指定できます。

‘-f<nn>’
     出力ファイル名の最初の <nn> 番号までをスキップします。たとえば、
     -f3 が指定されている場合は、番号を0004から始めます。

‘--keep-cr’
     ‘\r\n’ で終わる行から ‘\r’ を削除しないでください。

‘--mboxrd’
     入力は「mboxrd」形式であり、 "^>+From " 行のエスケープは逆になりま
     す。

GIT
***

Part of the git(1) suite

Name
****

git-maintenance — Gitリポジトリのデータを最適化するためのタスクの実行

Synopsis
********

     git maintenance run [<options>]

DESCRIPTION
***********

タスクを実行してGitリポジトリデータを最適化し、他のGitコマンドを高速化し
、リポジトリのストレージ使用量を減らします。

   リポジトリのデータを追加するGitコマンド、例えば ‘git add’ や ‘git
fetch’ は、応答性の良いユーザー体験(user experience)を実現するために最適
化されています。これらのコマンドは、Gitデータを最適化するのに時間がかか
りません。なぜなら、これらのユーザーコマンドはそれぞれ比較的小さなアクシ
ョンを実行するのに対して、その最適化はリポジトリのフルサイズでスケールす
るからです。

   ‘git maintenance’ コマンドはGitリポジトリを最適化する方法に柔軟性を提
供します。

SUBCOMMANDS
***********

register
     Git構成値を初期化して、スケジュールされたメンテナンスが、このリポジ
     トリで実行を開始するようにします。 これにより、現在のユーザーのグロ
     ーバル構成の ‘maintenance.repo’ 構成変数にリポジトリが追加され、
     ‘maintenance.<task>.schedule’ の推奨構成値が有効になります。 有効に
     なっているタスクは、フォアグラウンドプロセスを中断することなく、バ
     ックグラウンドで安全に実行できます。

     ‘register’ サブコマンドは、‘maintenance.strategy’ 構成値が以前に設
     定されていない場合、‘maintenance.strategy’ を ‘incremental’ に設定
     します。 ‘incremental’ 戦略では、メンテナンスタスクごとに以下のスケ
     ジュールを使用します:

        • ‘gc’: disabled.

        • ‘commit-graph’: hourly.

        • ‘prefetch’: hourly.

        • ‘loose-objects’: daily.

        • ‘incremental-repack’: daily.

     ‘git maintenance register’ は、現在のリポジトリで ‘maintenance.auto
     = false’ を設定することにより、フォアグラウンドメンテナンスも無効に
     します。 この設定設定は、 ‘git maintenance unregister’ コマンドの後
     も残ります。

run
     1つ以上のメンテナンスタスクを実行します。 1つ以上の ‘--task’ オプシ
     ョンが指定されている場合、それらのタスクは指定した順序で実行されま
     す。 それ以外の場合、タスクは、どの ‘maintenance.<task>.enabled’ 構
     成オプションがtrueであるかによって決定されます。 デフォルトでは、
     ‘maintenance.gc.enabled’ のみがtrueです。

start
     現在のリポジトリでメンテナンスの実行を開始します。 これにより、
     ‘register’ サブコマンドと同一構成の更新が実行され、バックグラウンド
     スケジューラが更新されて、1時間ごとに ‘git maintenance run
     --scheduled’ が実行されます。

stop
     バックグラウンドメンテナンススケジュールを停止します。 バックグラウ
     ンドメンテナンスが後で再開された場合に備えて、現在のリポジトリはメ
     ンテナンスされたリポジトリのリストから削除されません。

unregister
     現在のリポジトリをバックグラウンドメンテナンスから削除します。 構成
     済みリストからリポジトリが削除されるだけです。 バックグラウンドメン
     テナンスプロセスの実行を停止することはありません。

TASKS
*****

commit-graph
     ‘commit-graph’ ジョブは ‘commit-graph’ ファイルを段階的に更新し、書
     き込まれたデータが正しいことを確認します。段階的書き込みは、前の
     ‘commit-graph-chain’ ファイルにあった ‘.graph’ ファイルを期限切れに
     しないため、並行Gitプロセスと一緒に安全に実行できます。 それらは、
     有効期限延長に基づいて、のちの実行で削除されます。

prefetch
     ‘prefetch’ タスクは、登録されているすべてのリモートからの最新のオブ
     ジェクトでオブジェクトディレクトリを更新します。 リモートごとに、
     ‘git fetch’ コマンドが実行されます。 構成されたrefspecは、要求され
     たすべてのrefを ‘refs/prefetch/’ 内に配置するように変更されます。 ま
     た、タグは更新されません。

     これは、リモート追跡ブランチの一時不通(disrupting)を回避するために
     行われます。 エンドユーザーは、フェッチを開始しない限り、これらの
     refが移動されないままになることを期待しています。 ただし、
     prefetchタスクでは、後で実際のフェッチを完了するために必要なオブジ
     ェクトがすでに取得されているため、実際のフェッチはより高速になりま
     す。 理想的なケースでは、オブジェクトを転送せずに、一連のリモート追
     跡ブランチの更新ができます。

gc
     不要なファイルをクリーンアップし、ローカルリポジトリを最適化します
     。 「GC」は「ガベージコレクション」の略で、このタスクは多くの小さな
     タスクを実行します。 このタスクは、すべてのGitオブジェクトを単一の
     パックファイルに再パックするため、大規模なリポジトリではコストがか
     かる可能性があります。 また、古いデータを削除するため、状況によって
     は混乱を招く可能性があります。 Gitでのガベージコレクションの詳細に
     ついては、 git-gc(1) を参照してください。

loose-objects
     ‘loose-objects’ ジョブは、緩いオブジェクト(loose objects)をクリーン
     アップし、パックファイルに配置します。 並行Gitコマンドによる競合状
     態を防ぐために、2段階で処理を行います。 まず、パックファイルにすで
     に存在する緩いオブジェクトを削除します。 並行Gitプロセスは、緩いオ
     ブジェクトではなく、オブジェクトデータのパックファイルを調べます。
     次に、緩いオブジェクトのバッチを含む新しいパックファイル(‘loose-’ で
     始まる)を作成します。 バッチサイズは5万オブジェクトに制限されており
     、多量の緩いオブジェクトがあるリポジトリでジョブに時間がかかりすぎ
     るのを防ぎます。 ‘gc’ タスクは、到達不能なオブジェクトを、パックフ
     ァイルに再追加されない場合にのみ、後の段階でクリーンアップされる緩
     いオブジェクトとして書き込みます。 このため、 ‘loose-objects’ タス
     クと ‘gc’ タスクの両方を同時に有効にすることはお勧めできません。

incremental-repack
     ‘incremental-repack’ ジョブは、 ‘multi-pack-index’ 機能を使用してオ
     ブジェクトディレクトリを再パックします。 並行Gitコマンドによる競合
     状態を防ぐために、2段階の処理を行います。 まず、
     ‘gitmulti-pack-indexexpire’ を呼び出して ‘multi-pack-index’ ファイ
     ルによって参照されていないパックファイルを削除します。 次に、 ‘git
     multi-pack-index repack’ を呼び出して、いくつかの小さなパックファイ
     ルを選択し、それらをより大きなファイルに再パックし、次に、小さなパ
     ックファイルを参照する ‘multi-pack-index’ エントリを更新して、新し
     いパックファイルを参照します。 これにより、これらの小さなパックファ
     イルは、次回の ‘gitmulti-pack-indexexpire’ の実行時に削除できるよう
     になります。 小さいパックファイルの選択は、大きいパックファイルの予
     想サイズが少なくともバッチサイズになるように行われます。
     git-multi-pack-index(1) の ‘repack’ サブコマンドの ‘--batch-size’ オ
     プションを参照してください。 デフォルトのバッチサイズはゼロです。こ
     れは、すべてのパックファイルを単一のパックファイルに再パックしよう
     とする特殊なケースです。

pack-refs
     ‘pack-refs’ タスクは、緩い参照ファイル(loose reference files)を収集
     し、それらを1つのファイルに纏めます。 これにより、多くの参照間で反
     復する必要のある操作が高速化されます。 詳細については、
     git-pack-refs(1) を参照してください。

OPTIONS
*******

‘--auto’
     ‘run’ サブコマンドと組み合わせると、特定のしきい値が満たされた場合
     にのみメンテナンスタスクを実行します。 たとえば、 ‘gc’ タスクは、緩
     いオブジェクトの数が ‘gc.auto’ 構成設定に格納されている数を超えた場
     合、またはパックファイルの数が ‘gc.autoPackLimit’ 構成設定を超えた
     場合に実行されます。 ‘--schedule’ オプションとは互換性がありません
     。

‘--schedule’
     ‘run’ サブコマンドと組み合わせると、 各 ‘<task>’ の
     ‘maintenance.<task>.schedule’ 構成値で指定されているように、特定の
     時間条件が満たされた場合にのみメンテナンスタスクを実行します。 この
     構成値は、‘maintenance.<task>.lastRun’ 構成値に従って、そのタスクが
     最後に実行されてからの秒数を指定します。 テストされるタスクは、
     ‘--task=<task>’ オプションによって提供されるタスク、または
     ‘maintenance.<task>.enabled’ がtrueに設定されているタスクです。

‘--quiet’
     (stderrを介して)進捗状況やその他の情報を報告しないでください。

‘--task=<task>’
     このオプションを1回以上指定した場合は、指定したタスクを指定した順序
     でのみ実行してください。 ‘--task=<task>’ 引数が指定されていない場合
     、 ‘maintenance.<task>.enabled’ が ‘true’ として構成されているタス
     クのみが考慮されます。 受け入れられる ‘<task>’ 値のリストについては
     、「TASKS」セクションを参照してください。

‘--scheduler=auto|crontab|systemd-timer|launchctl|schtasks’
     ‘start’ サブコマンドと組み合わせる場合は、 ‘git maintenance run’ を
     毎時(hourly)、毎日(daily)、毎週(weekly)に実行するスケジューラーを指
     定します。 ‘<scheduler>’ に指定できる値は、 ‘auto’ 、
     ‘crontab’(POSIX)、 ‘systemd-timer’(Linux)、 ‘launchctl’(macOS)、
     ‘schtasks’(Windows) です。 ‘auto’ が指定されている場合、適切なプラ
     ットフォーム固有のスケジューラが使用されます。 Linuxでは、使用可能
     な場合は ‘systemd-timer’ が使用され、 ‘systemd-timer’ が使用できな
     い場合は ‘crontab’ が使用されます。 デフォルトは‘auto‘です。

TROUBLESHOOTING
***************

‘git maintenance’ コマンドは、Gitコマンド実行中のユーザーの待ち時間を最
小限に抑えながら、リポジトリのメンテナンスパターンを簡素化するように設計
されています。この処理をカスタマイズできるように、さまざまな構成オプショ
ンを利用できます。 デフォルトのメンテナンスオプションは、大規模なリポジ
トリであっても、迅速に完了する操作に重点を置いています。

   スケジュールされたメンテナンスタスクが、ユーザーが意図したほど頻繁に
実行されない場合があります。 各 ‘git maintenance run’ コマンドは、リポジ
トリのオブジェクトデータベースをロックします。これにより、他の並列の
‘git maintenance run’ コマンドが同じリポジトリで実行されなくなります。こ
の安全柵がないと、競合するプロセスによってリポジトリが予測できない状態に
なる可能性があります。

   バックグラウンドメンテナンススケジュールは、1時間ごとに ‘git
maintenance run’ プロセスを実行します。 実行するたびに、「毎時」のタスク
が実行されます。 深夜に、そのプロセスは「毎日」のタスクも実行します。 週
の最初の日の深夜に、そのプロセスは「毎週」のタスクも実行します。 単一の
プロセスが登録された各リポジトリを反復処理し、その頻度でスケジュールされ
たタスクを実行します。 登録されているリポジトリの数とそのサイズによって
は、このプロセスに1時間以上かかる場合があります。 この場合、複数の ‘git
maintenance run’ コマンドが同じリポジトリで同時に実行され、オブジェクト
データベースのロックを引き起こす可能性があります。 これにより、2つのタス
クのどちらかが実行されなくなります。

   一部のメンテナンスウィンドウの完了に1時間以上かかる場合は、メンテナン
スタスクの複雑さを軽減することを検討してください。 たとえば、
‘incremental-repack’ タスクは ‘gc’ タスクよりもはるかに高速です。しかし
、その代償として、オブジェクトデータベースが若干大きくなってしまいます。
より高価なタスクを移動して、実行頻度を減らすことを検討してください。

   エキスパートユーザーは、 ‘git maintenance start’ およびGit構成オプシ
ョンで利用できるスケジュールとは異なるスケジュールを使用して独自のメンテ
ナンスタスクをスケジュールすることを検討できます。 これらのユーザーは、
オブジェクトデータベースのロックと、並列実行の ‘git maintenance run’ コ
マンドの動作に注意する必要があります。 さらに、‘git gc’ コマンドを ‘git
maintenance run’ コマンドと組み合わせないでください。 ‘git gc’ はオブジ
ェクトデータベースを変更しますが、 ‘git maintenance run’ のようにロック
を取得しません。 可能であれば、 ‘git gc’ の代わりに ‘git maintenance run
--task=gc’ を使用してください。

   次のセクションでは、 ‘git maintenance start’ によるバックグラウンドメ
ンテナンスを実行するために導入されたメカニズムとそれらをカスタマイズする
方法について説明します。

BACKGROUND MAINTENANCE ON POSIX SYSTEMS
***************************************

POSIXシステムでバックグラウンドタスクをスケジュールするための標準メカニ
ズムは cron(8) です。 このツールは、指定されたスケジュールに基づいてコマ
ンドを実行します。 ユーザーがスケジュールしたタスクの現在のリストは、
‘crontab -l’ を実行することで見つけることができます。 ‘git maintenances
tart’ が書いたスケジュールは以下のようになります:

     # BEGIN GIT MAINTENANCE SCHEDULE
     # The following schedule was created by Git
     # Any edits made in this region might be
     # replaced in the future by a Git command.

     0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly
     0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily
     0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly

     # END GIT MAINTENANCE SCHEDULE

   コメントは、Gitによって作成されたスケジュールをマークするための領域と
して使用されます。 この領域内の変更は、 ‘git maintenance stop’ によって
完全に削除されるか ‘git maintenance start’ によって上書きされます。

   ‘crontab’ エントリは、実行された ‘git’ コマンドが ‘PATH’ とは無関係に
‘git maintenance start’ が発行したものと同じであることを保証するために
‘git’ 実行可能ファイルのフルパスを指定します。 同じユーザーが複数のGit実
行可能ファイルで ‘git maintenance start’ を実行する場合、最新の実行可能
ファイルのみが使用されます。

   これらのコマンドは、 ‘git for-each-repo --config=maintenance.repo’ を
使用して、複数値の ‘maintenance.repo’ 構成オプションにリストされている各
リポジトリで ‘git maintenance run --schedule=<frequency>’ を実行します。
これらは通常、ユーザー固有のグローバル構成からロードされます。 次に、
‘git maintenance’ プロセスは ‘maintenance.<task>.schedule’ 設定オプショ
ンを使用して、 各 ‘<frequency>’ で各リポジトリで実行するように設定されて
いるメンテナンスタスクを決定します。 これらの値は、グローバルまたはリポ
ジトリ構成値からロードされます。

   構成値が、目的のバックグラウンドメンテナンススケジュールを達成するに
は不十分な場合は、あなた独自のスケジュールを作成できます。 ‘crontab -e’
を実行すると、エディターはユーザー固有の ‘cron’ スケジュールをロードしま
す。 そのエディターでは、独自のスケジュール行を追加できます。 あなたは前
述のデフォルトのスケジュールを採用することから始めるか、あるいは高度なス
ケジューリング手法について crontab(5) のドキュメントを読むことができます
。 あなたのスケジュールで正しいバイナリを実行していることを確認するため
に、デフォルトのスケジュールから、フルパスと ‘--exec-path’ の手法を流用
してください。

BACKGROUND MAINTENANCE ON LINUX SYSTEMD SYSTEMS
***********************************************

Linux は ‘cron’ をサポートしていますが、ディストリビューションによっては
‘cron’ はオプションパッケージで、必ずしもインストールされるとは限りませ
ん。最近の Linux ディストリビューションでは、systemd タイマー がこれに取
って代わっています。

   ユーザーsystemdタイマーが使用可能な場合、それらが ‘cron’ の代わりに使
用されます。

   この場合、 ‘git Maintenance start’ はユーザーsystemdタイマーユニット
を作成し、タイマーを開始します。 ユーザーがスケジュールしたタスクの現在
のリストは、 ‘systemctl --user list-timers’ を実行することで見つけること
ができます。 ‘git maintenance start’ によって書かれたタイマー以下のよう
な感じになります:

     $ systemctl --user list-timers
     NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
     Thu 2021-04-29 19:00:00 CEST 42min left    Thu 2021-04-29 18:00:11 CEST 17min ago  git-maintenance@hourly.timer git-maintenance@hourly.service
     Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago    git-maintenance@daily.timer  git-maintenance@daily.service
     Mon 2021-05-03 00:00:00 CEST 3 days left   Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service

   ‘--schedule=<frequency>’ オプションごとに1つのタイマーが登録されます
。

   systemdユニットの定義は、以下のファイルで調べることができます:

     ~/.config/systemd/user/git-maintenance@.timer
     ~/.config/systemd/user/git-maintenance@.service
     ~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
     ~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
     ~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer

   ‘git maintenance start’ はこれらのファイルを上書きし、 ‘systemctl
--user’ でタイマーを再開するため、カスタマイズは差し込み式ファイル
(drop-in file)ドロップインファイル、つまり
‘~/.config/systemd/user/git-maintenance@.service.d’ ディレクトリに
‘.conf’ 拡張子のファイルを作成して行う必要があります。

   ‘git maintenance stop’ は、ユーザーのsystemdタイマーを停止し、上記の
ファイルを削除します。

   詳細は ‘systemd.timer(5)’ を参照して下さい。

BACKGROUND MAINTENANCE ON MACOS SYSTEMS
***************************************

macOSは技術的には ‘cron’ をサポートしていますが、 ‘crontab -e’ を使用す
るには昇格された権限が必要であり、実行されるプロセスには完全なユーザーコ
ンテキストがありません。 完全なユーザーコンテキストがないと、Gitとその資
格情報ヘルパーは保存されている資格情報にアクセスできないため、一部のメン
テナンスタスクは機能しません。

   代わりに、 ‘git maintenance start’ は ‘launchctl’ ツールと相呼応しま
す。これはmacOSで時限ジョブをスケジュールするための推奨される方法です。
‘git maintenance (start|stop)’ によるメンテナンスのスケジュールには、
macOS10.11以降でのみ利用可能ないくつかの ‘launchctl’ 機能が必要です。

   ユーザー固有のスケジュールされたタスクは、XML形式の ‘.plist’ ファイル
として ‘~/Library/LaunchAgents/’ に保存されます。 あなたは以下のコマンド
を使用して、現在登録されているタスクを確認できます:

     $ ls ~/Library/LaunchAgents/org.git-scm.git*
     org.git-scm.git.daily.plist
     org.git-scm.git.hourly.plist
     org.git-scm.git.weekly.plist

   ‘--schedule=<frequency>’ オプションごとに1つのタスクが登録されます。
XML形式で各スケジュールがどのように記述されているかを調べるには、これら
の ‘.plist’ ファイルの1つをエディターで開き、
‘<key>StartCalendarInterval</key>’ 要素に続く‘<array>‘ 要素を調べます。

   ‘git maintenance start’ はこれらのファイルを上書きし、タスクを
‘launchctl’ に再度登録するため、カスタマイズは、個別の名前で独自の
‘.plist’ ファイルを作成して行う必要があります。 同様に、 ‘git
maintenance stop’ コマンドは ‘launchctl’ でタスクの登録を解除し、
‘.plist’ ファイルを削除します。

   バックグラウンドタスクのより高度なカスタマイズの作成の詳細については
launchctl.plist(5) を参照してください。

BACKGROUND MAINTENANCE ON WINDOWS SYSTEMS
*****************************************

Windowsは ‘cron’ をサポートしておらず、代わりにバックグラウンドタスクを
スケジュールするための独自のシステムを備えています。 ‘git maintenance
start’ コマンドは、 ‘schtasks’ コマンドを使用してこのシステムにタスクを
送信します。 タスクスケジューラアプリケーションを使用して、すべてのバッ
クグラウンドタスクを検査できます。 Gitによって追加されたタスクには、
‘Git Maintenance (<frequency>)’ という形式の名前が付いています。 タスク
スケジューラGUIには、これらのタスクを検査する方法がありますが、タスクを
XMLファイルにエクスポートして、そこで詳細を表示することもできます。

   注意: Gitはコンソールアプリケーションであるため、これらのバックグラウ
ンドタスクにより、現在のユーザーに表示されるコンソールウィンドウが作成さ
れることに注意してください。 これは、タスクスケジューラの「Run whether
user is logged in or not」(ユーザーがログインしているかどうかに関係なく
実行する)オプションを選択することで手動で変更できます。 この変更にはパス
ワードの入力が必要で、そのため ‘git maintenance start’ はデフォルトでは
このオプションを選択しません。

   バックグラウンドタスクをカスタマイズする場合は、タスクの名前を変更し
て、その後に ‘git maintenance (start|stop)’ 」を呼び出してもカスタムタス
クが上書きされないようにしてください。

GIT
***

Part of the git(1) suite

Name
****

git-merge-base — マージのために可能な限り良い共通の祖先を見つけます

Synopsis
********

     git merge-base [-a|–all] <commit> <commit>…
     git merge-base [-a|–all] –octopus <commit>…
     git merge-base –is-ancestor <commit> <commit>
     git merge-base –independent <commit>…
     git merge-base –fork-point <ref> [<commit>]

DESCRIPTION
***********

‘git merge-base’ は、3方向マージで使用する2つのコミット間で最良の共通の
祖先を探します。「ある共通の祖先」の祖先が、「別の共通の祖先」である場合
、「ある共通の祖先」は「別の共通の祖先」よりも「より良い」です。より良い
共通の祖先を持たない共通の祖先は、「最良の共通の祖先」、つまり「マージベ
ース」です。注意: コミットのペアに対して複数のマージベースが存在する可能
性があることに注意してください。

OPERATION MODES
***************

最も一般的な特別のケースとして、コマンドラインで2つのコミットのみを指定
することは、指定された2つのコミット間のマージベースを計算することを意味
します。

   より一般的には、マージベースを計算する2つのコミットのうち、1つはコマ
ンドラインの最初のコミット引数で指定されます。もう1つのコミットは、コマ
ンドラインの残りのすべてのコミットをマージする(おそらく仮想の)コミットで
す。

   結果として、3つ以上のコミットが指定されている場合、「マージベース」は
必ずしも各コミット引数に含まれているとは限りません。 これは、
‘--merge-base’ オプションを伴った git-show-branch(1) とは異なります。

‘--octopus’
     n方向マージの準備として、提供されたすべてのコミットの最良の共通の祖
     先を計算します。これは、 ‘git show-branch --merge-base’ の振る舞い
     を模倣しています。

‘--independent’
     マージベースを出力する代わりに、提供されたコミットの最小限のサブセ
     ットを同一祖先で出力します。言い換えれば、与えられたコミットの中に
     で他から到達できないコミットをリストします。これは、 ‘git
     show-branch --independent’ の振る舞いを模倣しています。

‘--is-ancestor’
     1番目の <commit> が2番目の <commit> の祖先であるかどうかを確認し、
     trueの場合はステータス0で終了し、そうでない場合はステータス1で終了
     します。 エラーは、1では無い、かつ、ゼロ以外のステータスによって通
     知されます。

‘--fork-point’
     ブランチ(または <commit> につながる履歴)が、別のブランチ(または参照
     ) <ref> から分岐したポイントを見つけます。これは、2つのコミットの共
     通の祖先を探すだけでなく、 <ref> のreflogを考慮して、 <commit> につ
     ながる履歴がブランチ <ref> の以前の実体(incarnation)から分岐したか
     どうかを確認します(下記の、このモードに関するdiscussionを参照してく
     ださい)。

OPTIONS
*******

‘-a’
‘--all’
     1つだけではなく、コミットのすべてのマージベースを出力します。

DISCUSSION
**********

2つのコミット「A」と「B」が与えられると、「git merge-base A B」は、親子
関係を辿って「A」と「B」の両方から到達可能なコミットを出力します。

   たとえば、このトポロジでは以下のようになります:

              o---o---o---B
             /
     ---o---1---o---o---o---A

   「A」と「B」の間のマージベースは「1」です。

   3つのコミット「A」、「B」、「C」が与えられると、「git merge-base A B
C」は、「A」と仮想のコミット「M」の間のマージベースを計算します。仮想の
コミット「M」は、「B」と「C」のマージです。たとえば、このトポロジでは以
下のようになります:

            o---o---o---o---C
           /
          /   o---o---o---B
         /   /
     ---2---1---o---o---o---A

   ‘git merge-base A B C’ の結果は「1」です。 これは、「B」と「C」の間に
マージコミット「M」がある同等のトポロジが以下のとおりであるためです:

            o---o---o---o---o
           /                 \
          /   o---o---o---o---M
         /   /
     ---2---1---o---o---o---A

   そして、 ‘git merge-base A M’ の結果は「1」です。 コミット「2」も「
A」と「M」の間の共通の祖先ですが、「2」は「1」の祖先であるため、「1」の
方がよりよい共通の祖先です。 したがって、「2」はマージベースではありませ
ん。

   ‘git merge-base --octopus A B C’ の結果は「2」です。これは、「2」がす
べてのコミットの中で最も共通の祖先であるためです。

   履歴に交差マージ(criss-cross merges)が含まれる場合、2つのコミットに対
して「最良の」共通の祖先が複数存在する可能性があります。 たとえば、この
トポロジでは以下のようになります:

     ---1---o---A
         \ /
          X
         / \
     ---2---o---o---B

   「1」と「2」はどちらもAとBのマージベースです。どちらももう一方よりも
優れているわけではありません（どちらも「最良の」マージベースです）。
‘--all’ オプションが指定されていない場合、どちらの最良のマージベースが出
力されるかは指定されていません。

   2つのコミットAとBの間の「早送り性」(fast-forward-ness)をチェックする
、という慣用句は、AとBの間のマージベースを計算し(少なくとも以前はそうで
した)、それがAと同一かどうかをチェックすることで、その場合AはBの祖先です
。この慣用句は古いスクリプトでよく使用されます。

     A=$(git rev-parse --verify A)
     if test "$A" = "$(git merge-base A B)"
     then
             ... A is an ancestor of B ...
     fi

   現在gitでは、あなたは以下のように、これをより直接的な方法で言うことが
できます:

     if git merge-base --is-ancestor A B
     then
             ... A is an ancestor of B ...
     fi

   このように、上記にとって代わります。

Discussion on fork-point mode
*****************************

‘git switch -c topic origin/master’ で作成された ‘topic’ ブランチで作業
した後、リモート追跡ブランチ ‘origin/master’ の履歴が巻き戻されて再構築
された可能性があり、以下形の履歴につながります:

                      o---B2
                     /
     ---o---o---B1--o---o---o---B (origin/master)
             \
              B0
               \
                D0---D1---D (topic)

   ここで、 ‘origin/master’ はコミットB0、B1、B2を指していましたが、現在
はBを指しています。そして、 ‘origin/master’ がB0にあったときに、あなたの
‘topic’ ブランチがその上で開始されました。あなたは、その上に、D0、D1、
Dの3つのコミットを作成しました。あなたは更新された origin/master の上に
、トピックで行った作業をリベースしたいとします。

   このような場合、 ‘git merge-base origin/master topic’ は上の図のB0の
親を返しますが、 ‘B0^..D’ はBの上でリプレイしたいコミットの範囲ではあり
ません(これには、あなたが書いたものではないB0が含まれます。これは、先端
をB0からB1に移動したときに破棄された自分側で無い側(the other side)のコミ
ットです)。

   ‘git merge-base --fork-point origin/master topic’ は、このような場合
に役立つように設計されています。 Bだけでなく、B0、B1、およびB2も(つまり
、リポジトリのreflogが知っているリモート追跡ブランチの古い先端も)考慮に
入れて、あなたのtopicブランチが構築されたコミットを確認し、B0を見つけま
す。これにより、topicのコミットのみをリプレイできます。ただし、自分の側
で無い側(the other side)で後で破棄されるコミットは除きます。

   したがって、以下は

     $ fork_point=$(git merge-base --fork-point origin/master topic)

   B0 を見つけ、そして

     $ git rebase --onto origin/master $fork_point topic

   以下の形の新しい履歴を作成するために、B の上で D0 と D1 と D をリプレ
イします:

                      o---B2
                     /
     ---o---o---B1--o---o---o---B (origin/master)
             \                   \
              B0                  D0'--D1'--D' (topic - updated)
               \
                D0---D1---D (topic - old)

   注意点としては、リポジトリ内の古いreflogエントリが ‘git gc’ によって
期限切れになる可能性があることです。 B0がリモート追跡ブランチ ‘origin/
master’ のreflogに表示されなくなった場合、‘--fork-point’ モードは明らか
にそれを見つけることができず失敗し、ランダムで役に立たない結果
(‘--fork-point’ オプション無しの同じコマンドが返すB0の親など)を与えるこ
とを避けます。

   また、 ‘--fork-point’ モードを使用するリモート追跡ブランチは、あなた
のトピックがその先端から分岐したものである必要があります。先端よりも古い
コミットからフォークした場合、このモードではフォークポイントが見つかりま
せん。(上記の履歴例でB0が存在せず、 origin/master がB1で始まり、B2、次に
Bに移動し、 origin/master がB1のときに、 ‘origin/master^’ でトピックをフ
ォークしたと想像してください。履歴の形は上記と同じですが、B0はありません
。B1の親は、 ‘git merge-base origin/master topic’ が正しく検出するもので
すが、 ‘--fork-point’ モードは検出しません。なぜなら origin/master の先
端にあったコミットの1つではないためです。）

See also
********

git-rev-list(1), git-show-branch(1), git-merge(1)

GIT
***

Part of the git(1) suite

Name
****

git-merge-file — 3方向ファイルマージを実行する

Synopsis
********

     git merge-file [-L <current-name> [-L <base-name> [-L <other-name>]]]
             [–ours|–theirs|–union] [-p|–stdout] [-q|–quiet] [–marker-size=<n>]
             [–[no-]diff3] <current-file> <base-file> <other-file>

DESCRIPTION
***********

_git merge-file_ は、 ‘<base-file>’ から ‘<other-file>’ へのすべての変更
を ‘<current-file>’ に組み込みます。結果は通常 ‘<current-file>’ に入りま
す。 _git merge-file_ は、元のファイルへの個別の変更を組み合わせるのに役
立ちます。 ‘<base-file>’ がオリジナルであり、 ‘<current-file>’ と
‘<other-file>’ の両方が ‘<base-file>’ の変更であるとすると、 _git
merge-file_ は両方の変更を結合します。

   ‘<current-file>’ と ‘<other-file>’ の両方の行の共通セグメントに変更が
ある場合、競合が発生します。競合が見つかった場合、「git merge-file」は通
常、警告を出力し、 ‘<<<<<<<’ および ‘>>>>>>>’ マーカーを含む行で競合を囲
みます。典型的な競合は以下のようになります:

     <<<<<<< A
     lines in file A
     =======
     lines in file B
     >>>>>>> B

   競合がある場合、ユーザーは結果を編集して、選択肢の1つを削除する必要が
あります。 ただし ‘--ours’ または ‘--theirs’ または ‘--union’ オプション
が有効な場合、これらの競合は、 ‘<current-file>’ の行または
‘<other-file>’ の行または両方からの行を優先して解決します。競合マーカー
の長さは ‘--marker-size’ オプションで指定できます。

   このプログラムの終了値は、エラーの場合は負数であり、それ以外の場合は
競合した数です(競合たくさんの場合は127に切り捨てられます)。マージがクリ
ーンだった場合、終了値は0です。

   _git merge-file_ は、RCS用マージの最小限のクローンになるように設計さ
れています。つまり git(1) に必要なRCSのマージ機能をすべて実装します。

OPTIONS
*******

‘-L <label>’
     このオプションは最大3回指定でき、競合レポートで対応するファイル名の
     代わりに使用するラベルを指定します。 つまり ‘git merge-file -L x -L
     y -L z a b c’ は、ファイルa、b、cからではなく、ファイルx、y、zから
     来たように見える出力を生成します。

‘-p’
     ‘<current-file>’ を上書きする代わりに、結果を標準出力に送信します。

‘-q’
     静かにします(quiet)。競合について警告しないでください。

‘--diff3’
     「diff3」スタイルで競合を表示します。

‘--ours’
‘--theirs’
‘--union’
     ファイルに競合を残す代わりに、競合部分の、our (または their または
     両方)側に有利な競合解決します。

EXAMPLES
********

‘git merge-file README.my README README.upstream’
     README以降のREADME.myとREADME.upstreamの変更を組み合わせて、それら
     をマージしようとし、結果をREADME.myに書き込みます。

‘git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345’
     tmp/a123 と tmp/c345 をベースの tmp/b234 とマージしますが、
     ‘tmp/a123’ と ‘tmp/c345’ の代わりにラベル ‘a’ と ‘c’ を使用します。

GIT
***

Part of the git(1) suite

Name
****

git-merge-index — マージが必要なファイルのマージを実行します

Synopsis
********

     git merge-index [-o] [-q] <merge-program> (-a | [–] <file>*)

DESCRIPTION
***********

これにより、インデックス内の <file> が検索され、マージエントリがある場合
は、それらのファイルのSHA-1ハッシュが引数1、2、3（ファイルがない場合は空
の引数）として、および、引数4として <file> が渡されます。引数1、2、3の
3つのファイルのファイルモードは、引数5、6、7として渡されます。

OPTIONS
*******

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

‘-a’
     インデックス内のマージが必要なすべてのファイルに対してマージを実行
     します。

‘-o’
     最初に失敗したマージで停止するのではなく、すべてを一度に実行します
     。前のマージでエラーが返された場合でもマージを続行し、すべてのマー
     ジ後にエラーコードを返します。

‘-q’
     マージプログラムの失敗について文句を言わないでください(マージプログ
     ラムの失敗は通常、マージ中の競合を示します)。 これは、カスタムメッ
     セージを送信する可能性のある磁器コマンド用です。

   _git merge-index_ が複数の <file> (または ‘-a’ )で呼び出された場合、
それらを順番に処理し、マージがゼロ以外の終了コードを返した場合にのみ停止
します。

   通常、これは、RCSパッケージの「マージ」コマンドのGitの模倣を呼び出す
スクリプトで実行されます。

   _git merge-one-file_ というサンプルスクリプトがディストリビューション
に含まれています。

   警告！警告！警告！ Gitの「オブジェクトのマージ順序」は、RCSの「マージ
」プログラムのオブジェクトのマージ順序とは異なります。上記の順番では、オ
リジナルが最初です。しかし、3方向マージプログラム「マージ」の引数の順序
は、オリジナルを中央に置きます。理由は聞かないで…

   例:

     torvalds@ppc970:~/merge-test> git merge-index cat MM
     This is MM from the original tree.              # original
     This is modified MM in the branch A.            # merge1
     This is modified MM in the branch B.            # merge2
     This is modified MM in the branch B.            # current contents

   または

     torvalds@ppc970:~/merge-test> git merge-index cat AA MM
     cat: : No such file or directory
     This is added AA in the branch A.
     This is added AA in the branch B.
     This is added AA in the branch B.
     fatal: merge program failed

   後者の例は、何かがエラーを返した後、「git merge-index」がマージの試行
を停止する方法を示しています(つまり、「cat」は元のファイルに存在しなかっ
たため、AAファイルのエラーを返しました。 _git merge-index_ はMMをマージ
しようとさえしませんでした)。

GIT
***

Part of the git(1) suite

Name
****

git-merge-one-file — git-merge-indexで使用する標準のヘルパープログラム

Synopsis
********

     git merge-one-file

DESCRIPTION
***********

これは、 _git merge-index_ で行われた簡単なマージの後にマージを解決する
ために、 _git read-tree -m_ で使用する標準のヘルパープログラムです。

GIT
***

Part of the git(1) suite

Name
****

git-merge-tree — インデックスに触れずに(without touching)3者間マージを表
示する

Synopsis
********

     git merge-tree <base-tree> <branch1> <branch2>

DESCRIPTION
***********

3つのツリーっぽいものを読み取り、些細なマージ結果と競合するステージを標
準出力に出力します。 これは、3者間の _git read-tree -m_ と似ていますが、
結果をインデックスに格納する代わりに、コマンドはエントリを標準出力に出力
します。

   これは、インデックスの外部でマージ結果を計算し、結果をインデックスに
戻すために、より高いレベルのスクリプトによって使用されることを意図してい
ます。 このため、コマンドからの出力では、 <branch1> ツリーに一致するエン
トリが省略されます。

GIT
***

Part of the git(1) suite

Name
****

git-merge — 2つまたはそれ以上の開発履歴を結合します

Synopsis
********

     git merge [-n] [–stat] [–no-commit] [–squash] [–[no-]edit]
             [–no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
             [–[no-]allow-unrelated-histories]
             [–[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>…]
     git merge (–continue | –abort | –quit)

DESCRIPTION
***********

名前付きのコミット(その履歴が現在のブランチから分岐した時点以降のもの)か
らの変更を現在のブランチに取り込みます。 このコマンドは、別のリポジトリ
からの変更を組み込むために ‘git pull’ によって使用され、そして、あるブラ
ンチから別のブランチに変更をマージするために手動で使用できます。

   以下の履歴が存在し、現在のブランチが ‘master’ であるとします:

               A---B---C topic
              /
         D---E---F---G master

   次に、‘git merge topic’ は、 ‘master’ から分岐(ここでは ‘E’)してから
、‘topic’ ブランチの現在のコミット(‘C’)まで ‘topic`ブランチに加えられた
変更を `master’ 上で再生(replay)します。 その結果を、2つの親コミットの名
前と、変更を説明するユーザーからのログメッセージとともに、新しいコミット
に記録します。

               A---B---C topic
              /         \
         D---E---F---G---H master

   2番目の構文(‘git merge --abort’)は、マージによって競合が発生した後に
のみ実行できます。 ‘git merge --abort`はマージ処理を中止し、マージ前の状
態を再構築しようとします。 ただし、マージの開始時にコミットされていない
変更があった場合(特に、マージの開始後にそれらの変更がさらに変更された場
合)、 `git merge --abort’ は、元の(マージ前の)変更を再構築できない場合が
あります。つまり以下の事が言えます:

     *Warning*

     自明でない未コミットの変更に対して ‘git merge’ を実行することは推奨
     されません。 可能ではありますが、 競合が発生した場合に元に戻すのが
     難しい状態になる可能性があります。

   3番目の構文(‘git merge --continue’)は、マージによって競合が発生した後
にのみ実行できます。

OPTIONS
*******

‘--commit’
‘--no-commit’
     マージを実行し、結果をコミットします。 このオプションは、
     ‘--no-commit’ をオーバーライドするために使用できます。

     ‘--no-commit’ を使用すると、マージを実行し、マージコミットを作成す
     る直前に停止して、ユーザーに、コミットする前にマージ結果を検査し、
     さらに微調整する機会を提供します。

     注意: 早送り(fast-forward)更新はマージコミットを作成しないため、
     ‘--no-commit’ を使用してこれらのマージを停止する方法はないことに注
     意してください。 したがって、mergeコマンドによってブランチが変更ま
     たは更新されないようにする場合は、 ‘--no-ff’ と ‘--no-commit’ を使
     用します。

‘--edit’
‘-e’
‘--no-edit’
     機械的マージがを成功する前にエディターを呼び出して、自動生成された
     マージメッセージをさらに編集し、ユーザーがマージについて説明して正
     当化できるようにします。 ‘--no-edit’ オプションを使用して、自動生成
     されたメッセージを受け入れることができます(これは一般的には推奨され
     ていません)。 _–edit_(または _-e_) オプションは、あなたがコマンドラ
     インから ‘-m’ オプションで与えた下書きメッセージをエディタで編集し
     たい場合にも便利です。

     古いスクリプトは、ユーザーがマージログメッセージを編集できないよう
     にするという過去の動作に依存している可能性があります。 そのような場
     合は ‘git merge’ を実行すると、エディターを開く事になります。 この
     ようなスクリプトを簡単に最新の挙動に合わせるために、環境変数
     ‘GIT_MERGE_AUTOEDIT’ をスクリプトの先頭で ‘no’ に設定できます。

‘--cleanup=<mode>’
     このオプションは、コミットする前にマージメッセージをクリーンアップ
     する方法を決定します。 詳細については、 git-commit(1)を参照してくだ
     さい。 加えて、 ‘<mode>’ に ‘scissors’ 値が指定されている場合、マー
     ジの競合が発生した時に、切り取り線(scissors)はコミット機構に渡され
     る前に ‘MERGE_MSG’ に追加されます。

‘--ff’
‘--no-ff’
‘--ff-only’
     マージされた履歴がすでに現在の履歴の子孫である場合に、マージがどの
     ように処理されるかを指定します。 ‘--ff’ は、 ‘refs/tags/’ 階層の自
     然な場所に格納されていない注釈付き(および場合によっては署名済み)タ
     グをマージしない限り、デフォルトです。マージする場合は、‘--no-ff’ が
     想定されます。

     ‘--ff’ を使用すると、可能であれば、マージを早送り(fast-forward)(マ
     ージされたブランチに一致するようにブランチポインタを更新するだけで
     す。マージコミットは作成しません)として解決します。 不可能な場合(マ
     ージされた履歴が現在の履歴の子孫ではない場合)は、マージコミットを作
     成します。

     ‘--no-ff’ を使用すると、マージが早送り(fast-forward)として解決でき
     る場合でも、すべての場合にマージコミットを作成します。

     ‘--ff-only’ を使用して、可能な場合はマージを早送り(fast-forward)と
     して解決します。不可能な場合は、マージを拒否し、ゼロ以外のステータ
     スで終了します。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     マージコミット結果にGPG署名します。 ‘keyid’ 引数はオプションであり
     、デフォルトでコミッターIDになります。 指定する場合は、スペースなし
     でオプションに串刺しする必要があります。 ‘--no-gpg-sign’ は、
     ‘commit.gpgSign’ 構成変数と、これ以前に指定した ‘--gpg-sign’ の両方
     を打ち消すのに役立ちます。

‘--log[=<n>]’
‘--no-log’
     ブランチ名に加えて、マージされている実際のコミットから最大<n>個のコ
     ミットの1行説明をログメッセージに入力します。 git-fmt-merge-msg(1)
     も参照してください。

     ‘--no-log’ を使用すると、マージされる実際のコミットからの1行説明が
     一覧表示されません。

‘--signoff’
‘--no-signoff’
     コミットログメッセージの最後に、コミッターによる「Signed-off-by」ト
     レーラーを追加します。signoffの意味は、コミットしているプロジェクト
     によって異なります。たとえば、コミッターがプロジェクトのライセンス
     に基づいて作品を提出する権利を持っていることを証明したり、開発者の
     原産地証明書などの寄稿者の代表に同意したりする場合があります。
     (LinuxカーネルおよびGitプロジェクトで使用されるものについては、
     http：//developercertificate.orgを参照してください)。プロジェクトで
     signoffがどのように使用されるかを理解するには、貢献しているプロジェ
     クトのドキュメントまたはリーダーシップ(leadership)を参照してくださ
     い。

     ‘--no-signoff’ オプションを使用すると、コマンドラインで以前の
     ‘--signoff’ オプションを無効にすることができます。

‘--stat’
‘-n’
‘--no-stat’
     マージの最後にdiffstatを表示します。 diffstatは、構成オプション
     merge.statによっても制御されます。

     ‘-n’ または ‘--no-stat’ を使用すると、マージの最後に diffstat が表
     示されません。

‘--squash’
‘--no-squash’
     (マージ情報を除く)実際のマージが発生したかのように作業ツリーとイン
     デックスの状態を生成しますが、実際にコミットしたり、 ‘HEAD’ を移動
     したり、 (次の ‘git commit’ コマンドでマージコミットを作成する、)
     ‘$GIT_DIR/MERGE_HEAD’ を記録したりしないでください。 これにより、現
     在のブランチの上に単一のコミットを作成できます。その効果は、別のブ
     ランチ(または octopusの場合はそれ以上)をマージするのと同じです。

     ‘--no-squash’ を使用してマージを実行し、結果をコミットします。 この
     オプションは、 ‘--squash’ をオーバーライドするために使用できます。

     ‘--squash’ を使用すると、 ‘--commit’ は許可されず、失敗します。

‘--no-verify’
     このオプションは、pre-mergeフックとcommit-msgフックをバイパスします
     。 githooks(5) も参照してください。

‘-s <strategy>’
‘--strategy=<strategy>’
     指定されたマージ戦略を使用します。 試行する順序を指定するために、複
     数回指定できます。 ‘-s’ オプションがない場合は、代わりに組み込みの
     戦略リストが使用されます(単一のヘッドをマージする場合は ‘ort’、それ
     以外の場合は ‘octopus’)。

‘-X <option>’
‘--strategy-option=<option>’
     マージ戦略固有のオプションをマージ戦略に渡します。

‘--verify-signatures’
‘--no-verify-signatures’
     マージされるサイドブランチの先端コミットが有効なキー、つまり有効な
     uidを持つキーで署名されていることを確認します。デフォルトの信頼モデ
     ルでは、これは署名キーが信頼できるキーによって署名されていることを
     意味します。サイドブランチの先端コミットが有効なキーで署名されてい
     ない場合、マージは中止されます。

‘--summary’
‘--no-summary’
     ‘--stat’ および ‘--no-stat’ の同義語。 これらは非推奨であり、将来削
     除される予定です。

‘-q’
‘--quiet’
     静かに実行します。 ‘--no-progress’ の指定を含んでいます。

‘-v’
‘--verbose’
     にぎやかにします。

‘--progress’
‘--no-progress’
     進行状況を明示的にオン/オフにします。 どちらも指定されていない場合
     、標準エラーが端末に接続されていれば進行状況が表示されます。 すべて
     のマージ戦略が進捗レポートをサポートしているわけではないことに注意
     してください。

‘--autostash’
‘--no-autostash’
     操作を開始する前に一時的なスタッシュエントリを自動的に作成し、それ
     を特別なref ‘MERGE_AUTOSTASH’ に記録し、操作の終了後にapplyします。
     これは、ダーティワークツリーで操作を実行できることを意味します。 た
     だし、注意して使用してください。マージが成功した後の最後のstashアプ
     リケーションは、深刻な競合を引き起こす可能性があります。

‘--allow-unrelated-histories’
     デフォルトでは、 ‘git merge’ コマンドは、共通の祖先を共有しない履歴
     のマージを拒否します。 このオプションは、独立して産まれた2つのプロ
     ジェクトの履歴をマージするときにこのセーフティを無効にするために使
     用できます。 これは非常にまれなケースであるため、これをデフォルトで
     有効にする構成変数は存在せず、今後も追加されません。

‘-m <msg>’
     マージコミットに使用するコミットメッセージを設定します(マージコミッ
     トが作成された場合)。

     ‘--log’ が指定されている場合、マージされるコミットのショートログが
     与えられたメッセージに追加されます。

     ‘git fmt-merge-msg’ コマンドを使用して、自動化された ‘git merge’ 呼
     び出しに適切なデフォルトを与えることができます。 自動メッセージには
     、ブランチの説明を含めることができます。

‘-F <file>’
‘--file=<file>’
     マージコミットに使用されるコミットメッセージを読み取ります(マージコ
     ミットが作成された場合)。

     ‘--log’ が指定されている場合、マージされるコミットのショートログが
     与えられたメッセージに追加されます。

‘--rerere-autoupdate’
‘--no-rerere-autoupdate’
     可能であれば、rerereメカニズムが自動競合解決の結果でインデックスを
     更新できるようにします。

‘--overwrite-ignore’
‘--no-overwrite-ignore’
     マージ結果から無視されたファイルを黙って上書きします。 これがデフォ
     ルトの動作です。 中止(abort)するには、 ‘--no-overwrite-ignore’ を使
     用します。

‘--abort’
     現在の競合解決プロセスを中止(abort)し、マージ前の状態を再構築してみ
     てください。 自動スタッシュエントリが存在する場合は、それをワークツ
     リーに適用します。

     マージの開始時にコミットされていないワークツリーの変更が存在した場
     合、 ‘git merge --abort’ は、これらの変更を再構築できない場合があり
     ます。 したがって、 ‘git merge’ を実行する前に、常にあなたの変更を
     コミット、またはスタッシュしておくことをお勧めします。

     ‘git merge --abort’ は、 ‘MERGE_HEAD’ がある場合は ‘git reset
     --merge’ と同じです。ただし ‘MERGE_AUTOSTASH’ もある場合は ‘git
     merge --abort’ はスタッシュエントリをワークツリーに適用しますが、
     ‘git reset --merge’ は スタッシュリストにスタッシュした変更を保持し
     たままにします。

‘--quit’
     進行中の現在のマージを忘れさせます。 インデックスと作業ツリーはその
     ままにしておきます。 ‘MERGE_AUTOSTASH’ が存在する場合、スタッシュエ
     ントリはスタッシュリストに保存されます。

‘--continue’
     競合が原因で ‘git merge’ が停止(stop)した後で、 ‘git merge
     --continue’ を実行してマージを終了できます(下記「HOW TO RESOLVE
     CONFLICTS」セクション参照)。

<commit>…
     私たちのブランチにマージするコミットです。通常は他のブランチヘッド
     です。 複数のコミットを指定すると、3つ以上の親とのマージが作成され
     ます(Octopusマージという愛称で親しまれています)。

     コマンドラインからコミットが指定されていない場合は、現在のブランチ
     がアップストリームとして使用するように構成されているリモート追跡ブ
     ランチをマージします。 このマニュアルページの構成(configuration)セ
     クションも参照してください。

     FETCH_HEAD‘ が指定された場合(他のコミットは指定しない場合)、直前の
     ‘git fetch’ によるマージによって ‘.git/FETCH_HEAD’ ファイルに記録さ
     れたブランチは、現在のブランチにマージされます。

PRE-MERGE CHECKS
****************

外部の変更を適用する前に、自分の作業を良好な状態にしてローカルでコミット
しとく必要があります。これにより、競合が発生した場合に作業が中断されるこ
とはなくなります。 git-stash(1) も参照してください。 ‘git pull’/‘git
merge’ は、ローカルのコミットされていない変更が ‘git pull’/‘git merge’ の
更新が必要なファイルと重複する場合、何もせずに停止(stop)します。

   マージコミットに無関係な変更が記録されないようにするために、 ‘HEAD’ コ
ミットに関連する変更がインデックスに登録されている場合、 ‘git pull’ と
‘git merge’ も中止(abort)されます。 (使用されているマージ戦略によっては
、このルールに対する特別な狭い例外が存在する場合がありますが、通常、イン
デックスはHEADと一致する必要があります。)

   すべての名前付きコミットがすでに ‘HEAD’ の祖先である場合、‘git merge’
は "Already up to date."  (既に最新です)というメッセージで早期に終了
(exit)します。

FAST-FORWARD MERGE
******************

多くの場合、現在のブランチヘッドは、指定のコミットの祖先です。 これは、
特に ‘git pull’ から呼び出された場合に最も一般的なケースです: 例えば、あ
なたはアップストリームリポジトリを追跡していて、ローカルの変更をコミット
していないので、新しいアップストリームリビジョンに更新する必要があります
。 この場合、結合された履歴を保存するために新しいコミットは必要ありませ
んが、代わりに、「HEAD」（およびインデックス）は、追加のマージコミットを
作成せずに、指定のコミットを指すように更新されます。

   この振る舞いは、‘--no-ff’ オプションで抑制できます。

TRUE MERGE
**********

早送りマージ(fast-forward merge)(上記参照)を除いて、マージされるブランチ
は、両方を親として持つマージコミットによって結合する必要があります。

   マージされるすべてのブランチの変更を調整したマージバージョンがコミッ
トされ、‘HEAD’、インデックス、作業ツリーがそのコミットに更新されます。 作
業ツリーには、重ならない限りは変更を加えることができます。

   変更を調停する方法が明確でない場合、以下のようになります:

  1. ‘HEAD’ ポインタは同一のままです。

  2. ‘MERGE_HEAD’ ref は、他方のブランチヘッド(the other branch head)を
     指すように設定されています。

  3. 正常にマージされたパスは、インデックスファイルとあなたの作業ツリー
     の両方で更新されます。

  4. 競合するパスの場合、インデックスファイルには最大3つのバージョンが記
     録されます: ステージ1は、共通の祖先からのバージョンを格納し、ステー
     ジ2 は ‘HEAD’ からのバージョン、 ステージ3 は ‘MERGE_HEAD’ からのバ
     ージョンです(あなたは ‘git ls-files -u’ でステージを検査できます)。
     作業ツリーファイルには、「マージ」プログラムの結果が含まれています
     。 つまり、おなじみの競合マーカー ‘<<<’ ‘===’ ‘>>>’ を使用した3方向
     マージの結果です。

  5. その他の変更は行われません。 特に、マージを開始する前に行ったローカ
     ルの変更は同じままであり、それらのインデックスエントリはそのまま、
     つまり「HEAD」と一致します。

   試しにマージした結果、複雑な競合が発生してしまったのでやり直したいと
いう場合は、 ‘git merge --abort’ で回復(recover)することができます。

MERGING TAG
***********

注釈付きの(可能ならば署名された)タグをマージする場合、早送りマージが可能
であっても、Gitは常にマージコミットを作成し、コミットメッセージテンプレ
ートはタグメッセージ付きで準備されます。 さらに、タグが署名されている場
合、シグネチャチェックはメッセージテンプレートのコメントとして報告されま
す。 git-tag(1) も参照してください。

   たまたまタグ付けされたコミットにつながる作業と統合し、例えば、アップ
ストリームのリリースポイントと同期したい場合、あなたは不要なマージコミッ
トを作成したくない場合があります。

   このような場合、タグを ‘git merge’ にフィードする前に自分で「包装を解
く」(unwrap)か、自分で作業を行わない場合は ‘--ff-only’ を渡すことができ
ます。 例えば以下ようにします

     git fetch origin
     git merge v1.2.3^0
     git merge --ff-only v1.2.3

HOW CONFLICTS ARE PRESENTED
***************************

マージ中に、作業ツリーのファイルが更新されてマージの結果が反映されます。
共通の祖先のバージョンに加えられた変更の中で、重複しないもの(つまり、フ
ァイルの領域を変更し、反対側がその領域をそのままにしておく、またはその逆
)が最終結果にそのまま組み込まれます。 ただし、両方の側が同じ領域に変更を
加えた場合、Gitは一方の側をもう一方の側からランダムに選択することはでき
ず、両方の側がその領域に行ったことをファイルに残してあなたに解決するよう
に求めます。

   デフォルトでは、GitはRCSスイートの「マージ」プログラムで使用されるも
のと同じスタイルを使用して、以下のように競合するハンクを表示します:

     Here are lines that are either unchanged from the common
     ancestor, or cleanly resolved because only one side changed.
     <<<<<<< yours:sample.txt
     Conflict resolution is hard;
     let's go shopping.
     =======
     Git makes conflict resolution easy.
     >>>>>>> theirs:sample.txt
     And here is another line that is cleanly resolved or unmodified.

   競合する変更のペアが発生した領域は、マーカー ‘<<<<<<<’ 、 ‘=======’ 、
‘>>>>>>>’ でマークされます。 ‘=======’ の前の部分は通常あなた側(your
side)であり、後の部分は通常彼ら側(their side)です。

   デフォルトの形式では、競合している部分でオリジナルが何を言っているの
かは分かりません。 自分側の何行が削除され、バービー人形の発言に置き換え
られているのかは分かりません。 唯一わかるのは、あなた側(your side)は大変
だから買い物に行きたいと言いたいのに、相手側(the other size)は簡単だと主
張したいということです。

   ‘merge.conflictStyle’ 構成変数を ‘diff3’ に設定することで、別のスタイ
ルを使用できます。 ‘diff3’ スタイルでは、上記の競合は以下のようになりま
す:

     Here are lines that are either unchanged from the common
     ancestor, or cleanly resolved because only one side changed.
     <<<<<<< yours:sample.txt
     Conflict resolution is hard;
     let's go shopping.
     |||||||
     Conflict resolution is hard.
     =======
     Git makes conflict resolution easy.
     >>>>>>> theirs:sample.txt
     And here is another line that is cleanly resolved or unmodified.

   ‘<<<<<<<’ 、 ‘=======’ 、 ‘>>>>>>>’ マーカーに加えて、‘|||||||’ マー
カーにオリジナルのテキストが続きます。 オリジナルは事実を述べただけであ
り、あなたの側(your side)は単にその声明に屈して諦めたのに対し、他の側
(the oter side)はより前向きな態度をとろうとしたことがわかります。 オリジ
ナルを表示することで、より良い解決策を思い付くことができる場合があります
。

HOW TO RESOLVE CONFLICTS
************************

競合を目にした後、あなたは以下の2つのことができます:

   • マージしないことを決定します。 必要なクリーンアップは、インデックス
     ファイルを ‘HEAD’ コミットにリセットして (2) をリバースし、 (2) と
     (3) によって行われた作業ツリーの変更をクリーンアップすることだけで
     す。 これには ‘git merge --abort’ を使用できます。

   • 競合を解決します。 Gitは、作業ツリーの競合をマークします。 ファイル
     を編集して形にし、‘git add’ してインデックスに追加します。 ‘git
     commit’ または ‘git merge --continue’ を使用して、取引を成立させま
     す。 後者のコマンドは、 ‘git commit’ を呼び出す前に、進行中の(中断
     (interrupted)された)マージがあるかどうかをチェックします。

   あなたはいくつかの道具を使用して、競合を解決できます:

   • mergetoolの利用。 あなたが ‘git mergetool’ を実行すると、グラフィカ
     ルな mergetool が起動し、マージ作業を行えます。

   • diffを見てください。 ‘git diff’ は3方向の差分を表示し、‘HEAD’ バー
     ジョンと ‘MERGE_HEAD’ バージョンの両方からの変更を強調表示します。

   • 各ブランチからのdiffを見てください。 ‘git log --merge -p <path>’ は
     、最初に ‘HEAD’ バージョンの差分を表示し、次に ‘MERGE_HEAD’ バージ
     ョンを表示します。

   • オリジナルを見てください。 ‘git show :1:filename’ は共通の祖先を示
     し、 ‘git show :2:filename’ は ‘HEAD’ バージョンを示し、 ‘git show
     :3:filename’ は ‘MERGE_HEAD’ バージョンを示します。

EXAMPLES
********

   • 現在のブランチにブランチ ‘fixes’ と ‘enhancements’ をマージし、
     octopusマージします:

          $ git merge fixes enhancements

   • ‘ours’ マージ戦略を使用して、ブランチ ‘obsolete’ を現在のブランチに
     マージします:

          $ git merge -s ours obsolete

   • ブランチ ‘maint’ を現在のブランチにマージしますが、新しいコミットを
     自動的に行わないでください:

          $ git merge --no-commit maint

     これは、マージにさらに変更を加えたい場合、または独自のマージコミッ
     トメッセージを作成したい場合に使用できます。

     大幅な変更をマージコミットに忍び込ませるために、このオプションを悪
     用することは控えてください。 bumping release(微修正)/version name(バ
     ージョン名変更) のような小さな修正は許容されます。

MERGE STRATEGIES
****************

マージ機構(‘git merge’ と ‘git pull’ コマンド)では、バックエンドの「マー
ジ戦略」を ‘-s’ オプションで選択することができます。 いくつかの戦略では
、独自のオプションを指定することができます。これは、 ‘git merge’ や ‘git
pull’ に ‘-X<option>’ 引数として渡すことができます。

ort
     これは、1つのブランチをプルまたはマージするときのデフォルトのマージ
     戦略です。この戦略では、3方向マージアルゴリズムを使用して2つのヘッ
     ドのみを解決できます。3方向マージに使用できる共通の祖先が複数ある場
     合は、共通の祖先のマージされたツリーを作成し、それを3方向のマージの
     参照ツリーとして使用します。これにより、Linux 2.6カーネルの開発履歴
     から取得した実際のマージコミットで実行されたテストによって、誤った
     マージを引き起こすことなく、マージの競合が少なくなることが報告され
     ています。さらに、この戦略では、名前の変更を伴うマージを検出して処
     理できます。検出されたコピーは使用しません。このアルゴリズムの名前
     は "Ostensibly Recursive’s Twin" (表面上は再帰の双子)の頭文字を取っ
     たものであり、以前のデフォルトのアルゴリズムである「recursive」の代
     わりとして作成されたという事実に由来しています。

     ‘ort’ 戦略は、以下のオプションを取ることができます:

     ours
          このオプションは、「our」バージョンを優先することにより、競合
          するハンクをクリーンに自動解決するように強制します。 our側と競
          合しない他のツリーからの変更は、マージ結果に反映されます。 バ
          イナリファイルの場合、内容全体がour側から取得されます。

          これを「ours」マージ戦略と混同しないでください。この戦略では、
          他のツリーに何が含まれているのかさえまったく調べません。それは
          他のツリーが行ったすべてを破棄し、「our」履歴にはその中で起こ
          ったすべてが含まれていると宣言します。

     theirs
          これは「ours」の反対です。 「ours」とは異なり、このmergeオプシ
          ョンを混同する「theirs」マージ戦略はないことに注意してください
          。

     ignore-space-change
     ignore-all-space
     ignore-space-at-eol
     ignore-cr-at-eol
          指示されたタイプの空白(whitespace)の変更を含む行を、3方向マー
          ジのために変更されていないものとして扱います。行に対する、他の
          変更と空白(whitespace)の変更との混合は、無視されません。
          git-diff(1) の ‘-b’ と ‘-w’ と ‘--ignore-space-at-eol’ と
          ‘--ignore-cr-at-eol’ も参照してください。

             • 「their」バージョンが行に空白の変更のみを導入する場合、「
               our」バージョンが使用されます。

             • 「our」バージョンで空白の変更が導入されたが、「their」バ
               ージョンに大幅な変更が含まれている場合は、「their」バージ
               ョンが使用されます。

             • それ以外の場合、マージは通常の方法で進行します。

     renormalize
          これにより、3方向マージを解決するときに、ファイルの3つのステー
          ジすべての仮想チェックアウトとチェックインが実行されます。この
          オプションは、ブランチをさまざまなクリーンフィルターまたは行末
          正規化ルールとマージするときに使用することを目的としています。
          詳細については、 gitattributes(5) の「Merging branches with
          differing checkin/checkout attributes」(チェックイン/チェック
          アウト属性が異なるブランチのマージ)を参照してください。

     no-renormalize
          ‘renormalize’ オプションを無効にします。 これは、
          ‘merge.renormalize’ 構成変数をオーバーライドします。

     find-renames[=<n>]
          名前変更(rename)の検出をオンにし、オプションで類似性のしきい値
          (similarity threshold)を設定します。これがデフォルトです。 こ
          れは、 ‘merge.renames’ 構成変数をオーバーライドします。
          git-diff(1) の ‘--find-renames’ も参照してください。

     rename-threshold=<n>
          ‘find-renames=<n>’ の非推奨の同義語。

     subtree[=<path>]
          このオプションは「subtree」戦略をさらに発展させたもので、2つの
          木をマージする際に、どのようにずらせば互いにマッチするかを推測
          するものである。その代わり、指定されたパスは、2つの木の形が一
          致するように前置される(または、最初から取り除かれる)。

recursive
     これは、3方向マージアルゴリズムを使用して2つのヘッドのみを解決でき
     ます。3方向マージに使用できる共通の祖先が複数ある場合は、共通の祖先
     のマージされたツリーを作成し、それを3方向のマージの参照ツリーとして
     使用します。 これにより、Linux 2.6カーネルの開発履歴から取得した実
     際のマージコミットで実行されたテストによって、誤ったマージを引き起
     こすことなく、マージの競合が少なくなることが報告されています。 さら
     に、これにより、名前変更を含むマージを検出して処理できます。 検出さ
     れたコピーは使用しません。 これは、Git v0.99.9k 〜 v2.33.0 まで、
     2つのヘッドを解決するためのデフォルトの戦略でした。

     「recursive」(再帰的)戦略は「ort」と同じオプションを取る。 しかし、
     「ort」が無視する3つのオプション(上記には書かれていない)があり、 「
     recursive」戦略で有用となる可能性がある:

     patience
          ‘diff-algorithm=patience’ の非推奨の同義語。

     diff-algorithm=[patience|minimal|histogram|myers]
          マージ中に別の差分アルゴリズムを使用すると、重要でない一致行
          (異なる関数の中括弧など)が原因で発生するミスマージを回避できま
          す。 git-diff(1) ‘--diff-algorithm’ も参照してください。注意:
          特に、「ort」は ‘diff-algorithm=histogram’ を使用しますが、「
          recursive」はデフォルトで 「diff.algorithm」 設定を使う事に注
          意して下さい。

     no-renames
          名前変更(rename)の検出をオフにします。 これは、‘merge.renames’
          構成変数をオーバーライドします。 git-diff(1) の ‘--no-renames’
          も参照してください。

resolve
     これは、3方向マージアルゴリズムを使用して、2つのヘッド（つまり、現
     在のブランチとプルした別のブランチ）のみを解決できます。 交差マージ
     (criss-cross merge)のあいまいさを注意深く検出しようとします。 名前
     の変更は処理しません。

octopus
     これにより、3つ以上のヘッドを持つケースが解決されますが、手動解決が
     必要な複雑なマージの実行は拒否されます。これは主に、トピックの分岐
     ヘッドを纏めるために使用されることを意図しています。これは、複数の
     ブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

ours
     これにより、任意の数のヘッドが解決されますが、結果として得られるマ
     ージのツリーは常に現在のブランチヘッドのツリーであり、他のすべての
     ブランチからのすべての変更を事実上無視します。 これは、サイドブラン
     チの古い開発履歴に取って代わるために使用されることを意図しています
     。 これは、「recursive」マージ戦略の ‘-Xours’ オプションとは異なる
     ことに注意してください。

subtree
     これは改造された「ort」戦略です。 ツリーAとBをマージするとき、Bが
     Aのサブツリーに対応する場合、同じレベルのツリーを読み取るのではなく
     、Bは最初にAのツリー構造に一致するように調整されます。 この調整は、
     共通の祖先ツリーに対しても行われます。

   3方向マージ(デフォルトの「ort」を含む)を使用する戦略では、両方のブラ
ンチで変更が行われたが、後で一方のブランチで元に戻された場合、その変更は
マージされた結果に表示されます。一部の人々は、この振る舞いを混乱させると
感じています。これは、個々のコミットではなく、ヘッドとマージベースのみが
マージの実行時に考慮されるために発生します。したがって、マージアルゴリズ
ムは、元に戻された変更をまったく変更なしと見なし、代わりに変更されたバー
ジョンに置き換えます。

CONFIGURATION
*************

merge.conflictStyle
     マージ時に競合するハンクが作業ツリーファイルに書き出されるスタイル
     を指定します。 デフォルトは「merge」です。これは、 ‘<<<<<<<’ 競合マ
     ーカー、一方の側で行われた変更、 ‘=======’ マーカー、もう一方の側で
     行われた変更、そして ‘>>>>>>>’ マーカーというスタイルです。 別のス
     タイル「diff3」は、 ‘|||||||’ マーカーと元のテキストを ‘=======’ マ
     ーカーの前に追加します。

merge.defaultToUpstream
     コミット引数なしでmergeが呼び出された場合は、リモート追跡ブランチに
     格納されている最後に観測された値を使用して、現在のブランチ用に構成
     されたアップストリームブランチをマージします。
     ‘branch.<currentbranch>.remote’ によって指定されたリモートのブラン
     チに名前を付ける ‘branch.<currentbranch>.merge’ の値が参照され、次
     に、それらは ‘remote.<remote>.fetch’ を介して対応するリモート追跡ブ
     ランチにマッピングされ、そして、これらの追跡ブランチの先端がマージ
     されます。 デフォルトはtrueです。

merge.ff
     デフォルトでは、Gitは、現在のコミットの子孫であるコミットをマージす
     るときに、追加のマージコミットを作成しません。 代わりに、現在のブラ
     ンチの先端が早送り(fast-forward)されます。 ‘false’ に設定すると、こ
     の変数はGitにそのような場合に追加のマージコミットを作成するように指
     示します(コマンドラインから ‘--no-ff’ オプションを指定するのと同じ
     です)。 ‘only’ に設定すると、そのような早送りマージのみが許可されま
     す(コマンドラインから ‘--ff-only’ オプションを指定するのと同じです
     )。

merge.verifySignatures
     trueの場合、これは ‘--verify-signatures’ コマンドラインオプションと
     同等です。 詳細については、 git-merge(1) を参照してください。

merge.branchdesc
     ブランチ名に加えて、それらに関連付けられたブランチの説明テキストを
     ログメッセージに入力します。デフォルトはfalseです。

merge.log
     ブランチ名に加えて、マージされる実際のコミットからの最大「指定の数
     」の親コミットの1行説明をログメッセージに入力します。デフォルトは
     falseで、trueは20の同義語です。

merge.suppressDest
     統合ブランチの名前に一致するグロブをこの複数値の構成変数
     (multi-valued configuration variable)に追加することにより、これらの
     統合ブランチへのマージに対して計算されるデフォルトのマージメッセー
     ジは、タイトルから「into <branch name>」を省略します。

     空の値を持つ要素を使用して、以前の構成エントリから蓄積されたグロブ
     のリストをクリアできます。 ‘merge.suppressDest’ 変数が定義されてい
     ない場合、下位互換性のためにデフォルト値の ‘master’ が使用されます
     。

merge.renameLimit
     マージ処理中に名前変更検出の網羅的な部分で考慮するファイルの数。 指
     定されない場合、デフォルトは diff.renameLimit の値です。
     merge.renameLimit と diff.renameLimit の両方が指定されていない場合
     、現在のデフォルトは 7000 です。 この設定は、名前変更検出がオフの場
     合は効果がありません。

merge.renames
     Gitが名前の変更を検出するかどうか。 「false」に設定すると、名前変更
     の検出が無効になります。 「true」に設定すると、基本的な名前変更の検
     出が有効になります。 デフォルトは diff.renames の値です。

merge.directoryRenames
     Gitがディレクトリの名前変更を検出するかどうか。これは、履歴の一方の
     側でディレクトリが名前変更されたときに、もう一方の側で追加された新
     しいファイルがマージ時にどうなるのかに影響します。
     merge.directoryRenames を ‘false’ に設定すると、ディレクトリの名前
     変更の検出は無効になります。つまり、そのような新しいファイルは古い
     ディレクトリに残されます。 ‘true’ に設定すると、ディレクトリの名前
     変更検出が有効になり、そのような新しいファイルは新しいディレクトリ
     に移動されることを意味します。 ‘conflict’ に設定すると、そのような
     パスに対して競合が報告されます。 merge.renames が false の場合、
     merge.directoryRenames は無視され、false として扱われます。 デフォ
     ルトは ‘conflict’ です。

merge.renormalize
     リポジトリ内のファイルの標準の表現が時間の経過とともに変更されたこ
     とをGitに伝えます(たとえば、以前はCRLF行末のレコードテキストファイ
     ルをコミットしていましたが、最近のファイルはLF行末を使用している)。
     このようなリポジトリでは、Gitは、不必要な競合を減らすために、マージ
     を実行する前に、コミットに記録されたデータを標準形式に変換できます
     。 詳細については、gitattributes(5) の「Merging branches with
     differing checkin/checkout attributes」(チェックイン/チェックアウト
     属性が異なるブランチのマージ)のセクションを参照してください。

merge.stat
     マージの最後にORIG_HEADとマージ結果の間のdiffstatを出力するかどうか
     。 デフォルトではtrue。

merge.autoStash
     trueに設定すると、操作を開始する前に一時的なstashエントリを自動的に
     作成し、操作の終了後に適用します。 これは、ダーティ作業ツリーでマー
     ジを実行できることを意味します。 ただし、注意して使用してください。
     マージが成功した後の最後のstashアプリケーションは、重要な競合を引き
     起こす可能性があります。 このオプションは、 git-merge(1)の
     ‘--no-autostash’ および ‘--autostash’ オプションでオーバーライドで
     きます。 デフォルトはfalseです。

merge.tool
     git-mergetool(1) が使用するマージツールを制御します。 以下のリスト
     は、有効な組み込み値を示しています。その他の値はカスタムマージツー
     ルとして扱われ、対応する mergetool.<tool>.cmd 変数が定義されている
     必要があります。

merge.guitool
     ‘-g’/‘--gui’ フラグが指定されている場合に、 git-mergetool(1) が使用
     するマージツールを制御します。以下のリストは、有効な組み込み値を示
     しています。 その他の値はカスタムマージツールとして扱われ、対応する
     mergetool.<guitool>.cmd 変数が定義されている必要があります。

        • araxis

        • bc

        • bc3

        • bc4

        • codecompare

        • deltawalker

        • diffmerge

        • diffuse

        • ecmerge

        • emerge

        • examdiff

        • guiffy

        • gvimdiff

        • gvimdiff1

        • gvimdiff2

        • gvimdiff3

        • kdiff3

        • meld

        • nvimdiff

        • nvimdiff1

        • nvimdiff2

        • nvimdiff3

        • opendiff

        • p4merge

        • smerge

        • tkdiff

        • tortoisemerge

        • vimdiff

        • vimdiff1

        • vimdiff2

        • vimdiff3

        • winmerge

        • xxdiff

merge.verbosity
     再帰的マージ戦略によって示される出力の量を制御します。 レベル0は、
     競合が検出された場合の最終エラーメッセージ以外は何も出力しません。
     レベル1は競合のみを出力し、レベル2は競合とファイル変更を出力します
     。 レベル5以上はデバッグ情報を出力します。 デフォルトはレベル2です
     。 ‘GIT_MERGE_VERBOSITY’ 環境変数でオーバーライドできます。

merge.<driver>.name
     カスタムの低レベルマージドライバーの人間が読める名前を定義します。
     詳細については、 gitattributes(5) を参照してください。

merge.<driver>.driver
     カスタムの低レベルのマージドライバーを実装するコマンドを定義します
     。 詳細については、 gitattributes(5) を参照してください。

merge.<driver>.recursive
     共通の祖先間で内部マージを実行するときに使用される低レベルのマージ
     ドライバーに名前を付けます。 詳細については、 gitattributes(5) を参
     照してください。

branch.<name>.mergeOptions
     ブランチ <name> にマージするためのデフォルトオプションを設定します
     。 構文とサポートされているオプションは ‘git merge’ のものと同じで
     すが、空白文字を含むオプション値は現在サポートされていません。

SEE ALSO
********

git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1),
git-diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)

GIT
***

Part of the git(1) suite

Name
****

git-mergetool–lib — 共通 Gitマージツール シェル スクリプレット群

Synopsis
********

     TOOL_MODE=(diff|merge) . "$(git –exec-path)/git-mergetool–lib"

DESCRIPTION
***********

これは、全くもってエンドユーザー向けコマンドではありません。この文書は、
磁器風のスクリプトを研究している、および/または 新しいスクリプトを書いて
いる人々を対象としています。

   _git-mergetool–lib_ スクリプトレットは、Gitマージツールを操作するため
の関数を設定するために、他のシェルスクリプトから( ‘.‘を使用して)呼び出さ
れる(source)されるように設計されています。

   _git-mergetool–lib_ を(sourceで)実行する前に、スクリプトで
‘TOOL_MODE’ を設定して、以下にリストされている関数の操作モードを定義する
必要があります。 _diff_ と _merge_ は有効な値です。

FUNCTIONS
*********

get_merge_tool
     マージツールを返します。推測されたマージツールを返した場合、戻りコ
     ードは1です。それ以外の場合は0です。適切なGUIツールを検索するために
     、 _$GIT_MERGETOOL_GUI_ を _true_ に設定できます。

get_merge_tool_cmd
     マージツールのカスタムコマンドを返します。

get_merge_tool_path
     マージツールのカスタムパスを返します。

initialize_merge_tool
     マージツール固有の関数をスコープに入れて、使用またはオーバーライド
     できるようにします。

run_merge_tool
     ツール名と true/false フラグを指定してマージツールを起動し、マージ
     ベースが存在するかどうかを示します。 _$MERGED_ ・ _$LOCAL_ ・
     _$REMOTE_ ・ _$BASE_ は、マージツールで使用するために定義する必要が
     あります。

GIT
***

Part of the git(1) suite

Name
****

git-mergetool — マージ競合解決ツールを実行して、マージ競合を解決します

Synopsis
********

     git mergetool [–tool=<tool>] [-y | –[no-]prompt] [<file>…]

DESCRIPTION
***********

‘git mergetool’ を使用して、いくつかのマージユーティリティの1つを実行し
、マージの競合を解決します。通常、 ‘git merge’ の後に実行されます。

   1つ以上の <file> パラメーターが指定されている場合、マージツールプログ
ラムが実行され、その各ファイルの違いが解決されます(競合のないものはスキ
ップされます)。ディレクトリを指定すると、そのパスにあるすべての未解決の
ファイルが含まれます。ファイル名が指定されていない場合、 ‘git mergetool’
は、マージで競合するすべてのファイルに対してマージツールプログラムを実行
します。

OPTIONS
*******

‘-t <tool>’
‘--tool=<tool>’
     <tool> で指定したマージ解決プログラムを使用します。 有効な値には
     emerge、gvimdiff、kdiff3、meld、vimdiff、tortoisemerge が含まれます
     。有効な <tool> 設定のリストについては、 ‘git mergetool
     --tool-help’ を実行してください。

     マージ解決プログラムが指定されていない場合、 ‘git mergetool’ は構成
     変数 ‘merge.tool’ を使用します。 構成変数 ‘merge.tool’ が設定されて
     いない場合、 _git mergetool_ は適切なデフォルトを選択します。

     あなたは構成変数 ‘mergetool.<tool>.path’ を設定することにより、ツー
     ルへのフルパスを明示的に指定できます。たとえば、
     ‘mergetool.kdiff3.path’ を設定することにより、kdiff3への絶対パスを
     構成できます。それ以外の場合、 _git mergetool_ はツールがPATHで使用
     可能であると想定します。

     既知のマージツールプログラムの1つを実行する代わりに、構成変数
     ‘mergetool.<tool>.cmd’ で呼び出すコマンドラインを指定することにより
     、 _git mergetool_ をカスタマイズして代替プログラムを実行できます。

     ( ‘-t’ または ‘--tool’ または ‘merge.tool’ 構成変数のいずれかを介し
     て) ‘git mergetool’ をこのツールで呼び出すと、構成されたコマンドラ
     インが呼び出され、 ‘$BASE’ がマージの共通ベースを含む一時ファイルの
     名前に設定され、使用可能な場合、 ‘$LOCAL’ は現在のブランチのファイ
     ルの内容を含む一時ファイルの名前に設定され、 ‘$REMOTE’ はマージされ
     るファイルの内容を含む一時ファイルの名前に設定され、 ‘$REMOTE’ はマ
     ージされるファイルの内容を含む一時ファイルの名前に設定されます。

     カスタムマージツールがその終了コードでマージ解決の成功を正確に示し
     ている場合、構成変数 ‘mergetool.<tool>.trustExitCode’ を ‘true’ に
     設定できます。それ以外の場合、 ‘git mergetool’ は、カスタムツールが
     終了した後、解決の成功を示すようにユーザーに促します。

‘--tool-help’
     ‘--tool’ で使用できるマージツールのリストを出力します。

‘-y’
‘--no-prompt’
     マージ解決プログラムを呼び出す前にプロンプトを表示しないでください
     。これは、マージ解決プログラムが ‘--tool’ オプションまたは
     ‘merge.tool’ 構成変数で明示的に指定されている場合のデフォルトです。

‘--prompt’
     マージ解決プログラムを呼び出す前にプロンプトを表示して、ユーザーに
     パス(path)をスキップする機会を与えます。

‘-g’
‘--gui’
     ‘git-mergetool’ が ‘-g’ または ‘--gui’ オプションを伴って呼び出され
     ると、デフォルトのマージツールは ‘merge.tool’ ではなく設定された
     ‘merge.guitool’ 変数から読み取られます。 ‘merge.guitool’ が設定され
     ていない場合、 ‘merge.tool’ で構成されたツールにフォールバックしま
     す。

‘--no-gui’
     これにより、以前の ‘-g’ または ‘--gui’ 設定が上書きされ、デフォルト
     のマージツールは構成された ‘merge.tool’ 変数から読み取られます。

‘-O<orderfile>’
     <orderfile> で指定された順序でファイルを処理します。これには、1行に
     1つのシェルグロブパターンがあります。 これは ‘diff.orderFile’ 構成
     変数をオーバーライドします(git-config(1) を参照)。 ‘diff.orderFile’
     をキャンセルするには、 ‘-O/dev/null’ を使用します。

CONFIGURATION
*************

mergetool.<tool>.path
     指定のツール(<tool>)のパスを上書きします。 これは、ツールがPATH上に
     ない場合に役立ちます。

mergetool.<tool>.cmd
     指定のマージツール(<tool>)を呼び出すコマンドを指定します。指定され
     たコマンドは、次の変数を使用してシェルで評価されます: ‘BASE’ は、マ
     ージされるファイルの共通ベースを含む一時ファイルの名前です(使用可能
     な場合)。 ‘LOCAL’ は、現在のブランチのファイルの内容を含む一時ファ
     イルの名前です。 ‘REMOTE’ は、マージされるブランチのファイルの内容
     を含む一時ファイルの名前です。 ‘MERGED’ は、マージツールが正常なマ
     ージの結果を書き込むファイルの名前が含まれています。

mergetool.<tool>.hideResolved
     ユーザーが特定のツール(<tool>)のグローバルな
     ‘mergetool.hideResolved’ 値をオーバーライドできるようにします。 詳
     細については、 ‘mergetool.hideResolved’ を参照してください。

mergetool.<tool>.trustExitCode
     カスタムマージコマンドの場合、マージコマンドの終了コードを使用して
     マージが成功したかどうかを判断できるかどうかを指定します。 これが
     trueで無い場合、マージターゲットファイルのタイムスタンプがチェック
     され、ファイルが更新されている場合はマージが成功したと見なされます
     。そうでない場合、ユーザーはマージの成功を示すように求められます。

mergetool.meld.hasOutput
     古いバージョンの ‘meld’ は ‘--output’ オプションをサポートしていま
     せん。 Gitは、 ‘meld --help’ の出力を調べることで、 ‘meld’ が
     ‘--output’ をサポートしているかどうかを検出しようとします。
     ‘mergetool.meld.hasOutput’ を設定すると、Gitはこれらのチェックをス
     キップし、代わりに設定された値を使用します。
     ‘mergetool.meld.hasOutput’ を ‘true’ に設定すると、Gitは無条件に
     ‘--output’ オプションを使用するようになり、 ‘false’ は ‘--output’ の
     使用を回避します。

mergetool.meld.useAutoMerge
     meld は ‘--auto-merge’ が指定されると、競合しないすべての部分を自動
     的にマージし、競合する部分を強調表示して、ユーザーの決定を待ちます
     。 ‘mergetool.meld.useAutoMerge’ を‘true‘に設定すると、Gitは
     ‘--auto-merge’ オプションを ‘meld’ で無条件に使用するようになります
     。 この値を ‘auto’ に設定すると、gitは ‘--auto-merge’ がサポートさ
     れているかどうかを検出し、使用可能な場合にのみ ‘--auto-merge’ を使
     用します。 ‘false’ の値はデフォルト値で、‘ –auto-merge‘ の使用を完
     全に回避します。

mergetool.hideResolved
     マージ処理中、Gitは可能な限り多くの競合を自動的に解決し、解決できな
     い競合の周りに競合マーカーを含ませた ‘MERGED’ ファイルを書き込みま
     す。 「LOCAL」と「REMOTE」は通常、Gitの競合解決前のファイルのバージ
     ョンを表します。 この設定により、「LOCAL」と「REMOTE」が上書きされ
     、未解決の競合のみがマージツールに表示されます。
     ‘mergetool.<tool>.hideResolved’ 構成変数を介してツールごとに構成で
     きます。 デフォルトは ‘false’ です。

mergetool.keepBackup
     マージを実行した後、競合マーカーを含む元のファイルを、拡張子
     ‘.orig’ のファイルとして保存できます。 この変数が ‘false’ に設定さ
     れている場合、このファイルは保存されません。 デフォルトは ‘true’ で
     す(つまり、バックアップファイルを保持します)。

mergetool.keepTemporaries
     カスタムマージツールを呼び出すとき、Gitは一時ファイルの組をツールに
     渡します。 ツールがエラーを返し、この変数が ‘true’ に設定されている
     場合、これらの一時ファイルは保持されます。それ以外の場合、ツールの
     終了後に削除されます。 デフォルトは ‘false’ です。

mergetool.writeToTemp
     Gitは、デフォルトで、競合するファイルの一時的な 「BASE」バージョン
     と「LOCAL」バージョンと「REMOTE」バージョンをワークツリーに書き込み
     ます。 ‘true’ に設定すると、Gitはこれらのファイルに一時ディレクトリ
     を使用しようとします。 デフォルトは ‘false’ です。

mergetool.prompt
     マージ解決プログラムを呼び出す前にプロンプトを表示します。

TEMPORARY FILES
***************

‘git mergetool’ は、マージの解決中に ‘*.orig’ バックアップファイルを作成
します。これらは、ファイルがマージされ、その ‘git mergetool’ セッション
が完了したら安全に削除できます。

   ‘mergetool.keepBackup’ 構成変数を ‘false’ に設定すると、ファイルが正
常にマージされたときに、 ‘git mergetool’ がバックアップを自動的に削除し
ます。

GIT
***

Part of the git(1) suite

Name
****

git-mktag — 追加の検証(extra validation)でタグオブジェクトを作成します

Synopsis
********

     git mktag

DESCRIPTION
***********

標準入力でタグの内容を読み取り、タグオブジェクトを作成します。 出力は、
新しいタグの <object> IDです。

   このコマンドは、 git-hash-object(1) を ‘-t tag -w --stdin’ オプション
で呼び出すのとほとんど同じです。例:以下は両方とも、 ‘my-tag’ ファイル中
からタグの記述を見つけ、見つけたタグの記述からをタグオブジェクトを作成し
て書き込みます。

     git mktag <my-tag
     git hash-object -t tag -w --stdin <my-tag

   git-hash-object(1) の違いは、タグが git-fsck(1) チェックに合格しない
場合、タグを書き込む前にmktagが停止することです。

   mktagで実行される「fsck」チェックは、すべての ‘fsck.<msg-id>’ メッセ
ージが警告からエラーに昇格されるという点で git-fsck(1) がデフォルトで実
行するものよりも厳密(strict)です(たとえば、tagger行の欠落はエラーです)。

   オブジェクトの余分なヘッダーもmktagではエラーになりますが、
git-fsck(1) では無視されます。この追加のチェックは、適切な
‘fsck.<msg-id>’ 変数を設定することでオフにできます:

     git -c fsck.extraHeaderEntry=ignore mktag <my-tag-with-headers

OPTIONS
*******

‘--strict’
     デフォルトでは、mktagは git-fsck(1) の ‘--strict’ モードに相当する
     ものをオンにします。無効にするには、 ‘--no-strict’ を使用します。

Tag Format
**********

このコマンドの標準入力に供給されるタグ署名ファイル(tag signature file)は
、非常に単純な固定形式です。それは以下の4行からなります。

     object <hash>
     type <typename>
     tag <tagname>
     tagger <tagger>

   この後ろにいくつかのオプションの自由形式のメッセージが続きます(古い
Gitによって作成された一部のタグには ‘tagger’ 行がない場合があります)。メ
ッセージが存在する場合は、ヘッダーとは空白行で区切られます。メッセージ部
分には、Git自体は気にしない署名が含まれている場合がありますが、それは
gpgで確認できます。

GIT
***

Part of the git(1) suite

Name
****

git-mktree — ls-tree形式のテキストからツリーオブジェクトを構築する

Synopsis
********

     git mktree [-z] [–missing] [–batch]

DESCRIPTION
***********

非再帰的な ‘ls-tree’ 出力形式で標準入力を読み取り、ツリーオブジェクトを
作成します。ツリーエントリの順序はmktreeによって正規化されるため、入力を
事前に並べ替える必要はありません。構築されたツリーオブジェクトのオブジェ
クト名が標準出力に書き出されます。

OPTIONS
*******

‘-z’
     通常の ls-tree 出力形式の代わりに、(行終端がNULLである) ‘ls-tree
     -z’ 出力形式を読み取ります。

‘--missing’
     欠落しているオブジェクトを許可します。 (このオプションなしでの)デフ
     ォルトの動作では、各ツリーエントリのSHA1が、存在するオブジェクトを
     識別していることを確認します。なお、このオプションは、常に欠落して
     いることが許可されている gitlink エントリ(別名「サブモジュール」)の
     処理には影響しません。

‘--batch’
     終了せずに、複数のツリーオブジェクトの構築をする事を許可します。入
     力の各ツリーは、空白行1行で区切られています。最後の改行はオプション
     です。注意: ‘-z’ オプションを使用すると、行はNUL終端になります。

GIT
***

Part of the git(1) suite

Name
****

git-multi-pack-index — multi-pack-indexを書き出し・検証します

Synopsis
********

     git multi-pack-index [–object-dir=<dir>] [–[no-]progress]
             [–preferred-pack=<pack>] [–[no-]bitmap] <subcommand>

DESCRIPTION
***********

multi-pack-index (MIDX) ファイルを書き出し・検証します。

OPTIONS
*******

‘--object-dir=<dir>’
     Gitオブジェクトの場所として、指定されたディレクトリを使用します。 現
     在のMIDXファイルについては ‘<dir>/packs/multi-pack-index’ をチェッ
     クし、インデックスを作成するパックファイルについては ‘<dir>/packs’
     をチェックします。

     ‘<dir>’ は、現在のリポジトリの代替(alternate)である必要があります。

‘--[no-]progress’
     進行状況を明示的にオン/オフにします。どちらも指定されていない場合、
     標準エラーが端末に接続されていれば進行状況が表示されます。

   以下のサブコマンドを使用できます:

write
     新しいMIDXファイルを書き込みます。 ‘write’ サブコマンドでは、以下の
     オプションを使用できます:

     ‘--preferred-pack=<pack>’
          オプションで、複数のパックに同じオブジェクトが含まれている場合
          に使用されるタイブレークパッキング(tie-breaking pack)を指定し
          ます。 ‘<pack>’ には少なくとも1つのオブジェクトが含まれている
          必要があります。与えられていない場合、mtimeが最も低いパックを
          優先して採用(ties are broken)します。

     ‘--[no-]bitmap’
          マルチパックビットマップ(multi-pack bitmap)を書き込むかどうか
          を制御します。

verify
     MIDXファイルの内容を検証(verify)します。

expire
     MIDXファイルによって追跡されているが、MIDXによって参照されているオ
     ブジェクトがないパックファイルを削除します。その後、MIDXファイルを
     書き直して、これらのパックファイルへのすべての参照を削除します。

repack
     マルチパックインデックス(multi-pack-index)によって参照される小さな
     パックファイル(pack-files)にオブジェクトを含む新しいパックファイル
     を作成します。 ‘--batch-size=<size>’ 引数で指定されたサイズがゼロの
     場合、マルチパックインデックスによって参照されるすべてのオブジェク
     トを含むパックを作成します。ゼロ以外のバッチサイズの場合は、パック
     を古いものから新しいものへと調べてパックファイルを選択します。マル
     チパックインデックスによって参照されるパック内のオブジェクトの数を
     カウントすることにより、「予想サイズ」を計算します。次に、予想サイ
     ズをパック内のオブジェクトの総数で割り、パックサイズを掛けます。パ
     ックのセットが少なくともバッチサイズの合計予想サイズになるまで、ま
     たはすべてのパックファイルが考慮されるまで、予想サイズがバッチサイ
     ズよりも小さいパックを選択します。パックファイルが1つだけ選択されて
     いる場合は、何もしません。 新しいパックファイルが作成された場合は、
     マルチパックインデックスを書き直して(rewrite)、新しいパックファイル
     を参照します。後で ‘git multi-pack-index expire’ を実行すると、この
     バッチの一部であったパックファイルが削除されます。

     ‘repack.packKeptObjects’ が ‘false`の場合、 `.keep’ ファイルが関連
     付けられているパックファイルはバッチで再パックするために選択されま
     せん。

EXAMPLES
********

   • 現在の.gitフォルダーにpackfilesのMIDXファイルを書き込みます。

          $ git multi-pack-index write

   • 対応するビットマップを使用して、現在の ‘.git’ フォルダー内の
     packfilesのMIDXファイルを書き込みます。

          $ git multi-pack-index write --preferred-pack=<pack> --bitmap

   • 代替オブジェクトストア(alternate object store)にパックファイルの
     MIDXファイルを書き込みます。

          $ git multi-pack-index --object-dir <alt> write

   • 現在の ‘.git’ フォルダー内のpackfilesのMIDXファイルを検証(verify)し
     ます。

          $ git multi-pack-index verify

SEE ALSO
********

マルチパックインデックス機能の詳細については、 The Multi-Pack-Index
Design Document (technical/multi-pack-index.html) と The
Multi-Pack-Index Format (technical/pack-format.html) を参照してください
。

GIT
***

Part of the git(1) suite

Name
****

git-mv — ファイルまたはディレクトリまたはシンボリックリンクを移動
(move)または名前変更(rename)します

Synopsis
********

     git mv <options>… <args>…

DESCRIPTION
***********

ファイルまたはディレクトリまたはシンボリックリンクを移動または名前変更し
ます。

     git mv [-v] [-f] [-n] [-k] <source> <destination>
     git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>

   最初の形式では、ファイル・シンボリックリンク・ディレクトリのいずれか
である必要がある <source> の名前を <destination> に変更します。2番目の形
式では、最後の引数は既存のディレクトリである必要があります。指定のソース
はこのディレクトリに移動されます。

   正常に完了するとインデックスは更新されますが、変更はコミットする必要
があります。

OPTIONS
*******

‘-f’
‘--force’
     ターゲットが存在する場合でも、ファイルの名前変更または移動を強制し
     ます

‘-k’
     エラー状態になる移動または名前変更をスキップします。ソースが存在せ
     ず、Gitによって制御されていない場合、または ‘-f’ が指定されていない
     限り、ソースが既存のファイルを上書きする場合、エラーが発生します。

‘-n’
‘--dry-run’
     何も操作しない。何が起こるかを示すだけです。

‘-v’
‘--verbose’
     移動するファイルの名前を報告します。

SUBMODULES
**********

gitfile(つまり、Gitバージョン1.7.8以降で複製された)を使用してサブモジュ
ールを移動すると、gitfileとcore.worktreeの設定が更新され、サブモジュール
が新しい場所で機能するようになります。また、 gitmodules(5) ファイルの
submodule.<name>.path 設定を更新し、そのファイルをステージングしようとし
ます( ‘-n’ が使用されている場合を除く)。

BUGS
****

スーパープロジェクトの更新により、入力されたサブモジュールが移動されるた
びに(たとえば、移動の前後でコミットを切り替える場合)、古いサブモジュール
のチェックアウトは古い場所に残り、空のディレクトリが新しい場所に表示され
ます。新しい場所にサブモジュールを再度入力するには、後で「git submodule
update」を実行する必要があります。古いディレクトリの削除は、gitfileを使
用している場合にのみ安全です。そうでなければ、サブモジュールの履歴も削除
されます。再帰的なサブモジュールの更新が実装されている場合、これらの手順
は廃止されるでしょう。

GIT
***

Part of the git(1) suite

Name
****

git-name-rev — 指定のrevのシンボリック名を検索します

Synopsis
********

     git name-rev [–tags] [–refs=<pattern>]
                    ( –all | –stdin | <commit-ish>… )

DESCRIPTION
***********

_gitrev-parse_ で解析可能な任意の形式で指定されたリビジョンの、人間にと
って読みやすい記号名を検索します。

OPTIONS
*******

‘--tags’
     ブランチ名は使用せず、コミットに名前を付けるためにタグのみを使用し
     ます

‘--refs=<pattern>’
     名前が特定のシェルパターンに一致するrefのみを使用します。 パターン
     は、ブランチ名、タグ名、または完全修飾ref名のいずれかです。複数回指
     定する場合は、指定したシェルパターンのいずれかに名前が一致する
     refsを使用します。 ‘--no-refs’ を使用して、既に指定済のrefパターン
     をクリアします。

‘--exclude=<pattern>’
     名前が特定のシェルパターンと一致するrefは使用しない。 パターンは、
     ブランチ名、タグ名、または完全修飾ref名のいずれかです。複数回指定さ
     れた場合、指定されたパターンのいずれかに一致するrefは除外されます。
     ‘--refs’ と一緒に使用すると、refは少なくとも1つの ‘--refs’ パターン
     に一致し、 ‘--exclude’ パターンに一致しない場合にのみ一致として使用
     されます。 ‘--no-exclude’ を使用して、除外パターンのリストをクリア
     します。

‘--all’
     すべてのrefから到達可能なすべてのコミットを一覧表示します

‘--stdin’
     16死ん40文字のSHA-1($hexとする)をすべて "$hex ($rev_name)" に置き換
     えて、stdinを変換します。 ‘--name-only’ と一緒に使用する場合は、
     "$rev_name" に置き換えて、 $hex を完全に省略します。スクリプトで使
     用することを目的としています。

‘--name-only’
     SHA-1と名前の両方を印刷する代わりに、名前のみを印刷します。
     ‘--tags’ を指定すると、通常のタグプレフィックス "tags/" も名前から
     省略され、 ‘git-describe‘の出力とより厳密に一致します。

‘--no-undefined’
     参照が未定義の場合、 ‘undefined’ を出力する代わりに、エラーコード
     != 0 で終了します。

‘--always’
     一意を保つように省略されたコミットオブジェクトをフォールバックとし
     て表示します。

EXAMPLES
********

コミットが与えられたら、そのローカルrefsとの相対的な位置を見つけます。 誰
かがその素晴らしいコミット 33db5f4d9027a10e477ccf054b2c1ab94f74c85a につ
いてあなたに述べたとしましょう。もちろん、あなたはそのコミットを調べます
が、そこでは何が起こったのかを教えてくれるだけで、文脈は教えてくれません
。

   _git name-rev_ に入力します:

     % git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
     33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940

   あなたは今や、v0.99より前に940のリビジョンが発生したことが分かりまし
たね。

   別の方法:

     % git log | git name-rev --stdin

GIT
***

Part of the git(1) suite

Name
****

git-notes — オブジェクトノートを追加または検査します

Synopsis
********

     git notes [list [<object>]]
     git notes add [-f] [–allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
     git notes copy [-f] ( –stdin | <from-object> [<to-object>] )
     git notes append [–allow-empty] [-F <file> | -m <msg> | (-c | -C) <object>] [<object>]
     git notes edit [–allow-empty] [<object>]
     git notes show [<object>]
     git notes merge [-v | -q] [-s <strategy> ] <notes-ref>
     git notes merge –commit [-v | -q]
     git notes merge –abort [-v | -q]
     git notes remove [–ignore-missing] [–stdin] [<object>…]
     git notes prune [-n] [-v]
     git notes get-ref

DESCRIPTION
***********

オブジェクト自体に触れることなく、オブジェクトに添付のノートを追加、削除
、または読み取ります。

   デフォルトでは、ノートは ‘refs/notes/commits’ に保存され、そこから読
み取られますが、このデフォルトはオーバーライドできます。 以下の「
OPTIONS」セクション、「CONFIGURATION」セクション、「ENVIRONMENT」のセク
ションを参照してください。 このrefが存在しない場合、ノートを保存するため
に最初に必要になったときに黙って作成されます。

   ノートの一般的な使用法は、コミット自体を変更せずにコミットメッセージ
を補足することです。 ノートは、元のコミットメッセージとともに ‘git log’
で表示できます。 コミットオブジェクトに格納されているメッセージと区別す
るために、ノートはメッセージと同様にインデントされます。インデントされて
いない行には "Notes (<refname>):" (‘refs/notes/commits’ の場合は
"Notes:") と書かれています。

   ‘--notes’ オプションを使用して、 ‘git format-patch’ で作成されたパッ
チにノートを追加することもできます。 このようなノートは、3つのダッシュの
区切り行の後にパッチの解説として追加されます。

   ‘git log’ で表示されるノートを変更するには、 git-log(1) の
‘notes.displayRef’ 構成を参照してください。

   コミットを書き換えるコマンド間でノートを渡す法については、
‘notes.rewrite.<command>’ 構成を参照してください。

SUBCOMMANDS
***********

list
     指定のオブジェクトのノートオブジェクトを一覧表示します。 オブジェク
     トが指定されていない場合は、すべてのノートオブジェクトとそれらが注
     釈を付けるオブジェクトのリストを表示します("<note object>
     <annotated object>" 形式)。 サブコマンドが指定されていない場合、こ
     れはデフォルトのサブコマンドです。

add
     指定のオブジェクトにメモを追加します(デフォルトはHEAD)。 オブジェク
     トにすでにノートがある場合は中止(abort)します(既存のノートを上書き
     するには ‘-f’ を使用します)。 ただし、 ‘add’ を対話的に使用している
     場合(エディタを使用してノートの内容を入力する場合)、中止する代わり
     に、(‘edit’ サブコマンドのように、)既存のノートがエディタで開かれま
     す。

copy
     最初のオブジェクトのノートを2番目のオブジェクト(デフォルトはHEAD)に
     コピーします。 2番目のオブジェクトにすでにノートがある場合、または
     最初のオブジェクトにノートがない場合は中止(abort)します(‘-f’ を使用
     して2番目のオブジェクトの既存のノートを上書きします)。このサブコマ
     ンドは ‘git notes add [-f] -C $(git notes list <from-object>)
     <to-object>’ と同等です。

     ‘--stdin’ モードでは、以下の形式で行を取得します

          <from-object> SP <to-object> [ SP <rest> ] LF

     標準入力で、各<from-object>から対応する<to-object>にノートをコピー
     します。 (オプションの ‘<rest>’ は無視されるため、コマンドは
     ‘post-rewrite’ フックに与えられた入力を読み取ることができます。)

append
     既存のオブジェクトのノートに追加します(デフォルトはHEAD)。 必要に応
     じて、新しいノートオブジェクトを作成します。

edit
     指定のオブジェクトのノートを編集します(デフォルトはHEAD)。

show
     指定のオブジェクトのノートを表示します(デフォルトはHEAD)。

merge
     指定のノートrefを現在のノートrefにマージします。 これにより、マージ
     ベース(存在する場合)以降に指定されたnote参照(「remote」と呼ばれる）
     によって行われた変更が現在のノートref(「local」と呼ばれる)にマージ
     されます。

     競合が発生し、競合するノートを自動的に解決するための戦略(「NOTES
     MERGE STRATEGIES」セクション参照)が指定されていない場合は、「
     manual」(手動)リゾルバーが使用されます。 このリゾルバーは、特別なワ
     ークツリー(‘.git/NOTES_MERGE_WORKTREE’)内の競合するノートをチェック
     アウトし、そこで競合を手動で解決するようにユーザーに指示します。 完
     了したら、ユーザーは ‘git notes merge --commit’ を使用してマージを
     完了するか、 ‘git notes merge --abort’ を使用してマージを中止
     (abort)できます。

remove
     指定のオブジェクトのノートを削除します(デフォルトはHEAD)。 コマンド
     ラインから0個または1個のオブジェクトを指定する場合、これは ‘edit’ サ
     ブコマンドに空のノートメッセージを指定することと同じです。

prune
     存在しない(non-existing)/到達できない(unreachable) オブジェクトのす
     べてのノートを削除します。

get-ref
     現在のノートを出力します。これにより、現在のノートrefを(スクリプト
     などから)簡単に取得する方法が提供されます。

OPTIONS
*******

‘-f’
‘--force’
     すでにノートがあるオブジェクトにノートを追加する場合は、(中止するの
     ではなく、)既存のノートを上書きします。

‘-m <msg>’
‘--message=<msg>’
     (プロンプトを表示する代わりに、)指定のノートメッセージを使用します
     。 複数の ‘-m’ オプションが指定されている場合、それらの値は個別の段
     落として連結されます。 ‘#’ で始まる行と、段落間の1行以外の空行は削
     除されます。

‘-F <file>’
‘--file=<file>’
     指定のファイルからメモメッセージを取得します。 ‘-’ を使用すると、標
     準入力からメモメッセージを読み取ります。 ‘#’ で始まる行と、段落間の
     1行以外の空行は削除されます。

‘-C <object>’
‘--reuse-message=<object>’
     指定のブロブオブジェクト(たとえば、別のノート)をノートメッセージと
     して受け取ります。 (オブジェクト間でメモをコピーするには、代わりに
     ‘git notes copy <object>’ を使用してください。)

‘-c <object>’
‘--reedit-message=<object>’
     _-C_ と同様ですが、 ‘-c’ を使用するとエディタが呼び出されるため、ユ
     ーザーはノートメッセージをさらに編集できます。

‘--allow-empty’
     空のノートオブジェクトを保存できるようにします。 デフォルトの動作で
     は、空のノートは自動的に削除されます。

‘--ref <ref>’
     <ref>のノートツリーを操作します。 これは、 ‘GIT_NOTES_REF’ と、
     ‘core.notesRef’ 構成をオーバーライドします。 refは、 ‘refs/notes/’
     で始まる完全なref名を指定します。 ‘notes/’ で始まる場合、 ‘refs/’ が
     接頭辞として付けられ、それ以外の場合は ‘refs/notes/’ が接頭辞として
     付けられ、refのフルネームを形成します。

‘--ignore-missing’
     ノートが添付されていないオブジェクトからノートの削除を要求すること
     をエラーと見なさないでください。

‘--stdin’
     また、ノートを削除するために標準入力からオブジェクト名を読み取る(コ
     マンドラインからオブジェクト名と組み合わせることができないわけでは
     ありません)。

‘-n’
‘--dry-run’
     何も削除しないでください。 ノートが削除されるオブジェクト名を報告す
     るだけです。

‘-s <strategy>’
‘--strategy=<strategy>’
     ノートをマージするときは、指定の戦略を使用してノートの競合を解決し
     ます。 次の戦略が認識されます: ‘manual’(デフォルト)、 ‘ours’ 、
     ‘theirs’ 、 ‘union’ 、 ‘cat_sort_uniq’ 。 このオプションは、
     ‘notes.mergeStrategy’ 構成設定をオーバーライドします。 各ノートマー
     ジ戦略の詳細については、以下の「NOTES MERGE STRATEGIES」セクション
     を参照してください。

‘--commit’
     進行中の ‘git notes merge’ を完了させます。
     ‘.git/NOTES_MERGE_WORKTREE’ に保存されている ‘git notes merge’ の競
     合を解決した場合は、このオプションを使用します。 これにより、
     ‘.git/NOTES_MERGE_WORKTREE’ にノートを追加することで、 ‘git notes
     merge’ (‘.git/NOTES_MERGE_PARTIAL’ に保存)によって作成された部分的
     なマージコミットが修正されます。 ‘.git/NOTES_MERGE_REF’ symref に保
     存されているノートrefは、結果のコミットに更新されます。

‘--abort’
     進行中の ‘git notes merge’ を 中止(abort)/リセット します。つまり、
     ノートのマージは競合を伴います。これにより、ノートのマージに関連す
     るすべてのファイルが削除されます。

‘-q’
‘--quiet’
     ノートをマージするときは、黙って作業します。

‘-v’
‘--verbose’
     ノートをマージするときは、よりおしゃべりになります。ノートを刈り込
     むときは、ノートが削除されたすべてのオブジェクト名を報告してくださ
     い。

DISCUSSION
**********

コミットノートは、オブジェクトに関する追加情報(通常はコミットのメッセー
ジを補足する情報)を含むブロブです。 これらのブロブは、ノートrefから取得
されます。 ノートrefは通常、パスが記述されたオブジェクトのオブジェクト名
である「ファイル」を含むブランチであり、パフォーマンス上の理由からいくつ
かのディレクトリ区切り文字が含まれています。 (1)

   ノートを変更するたびに、指定したノート参照に新しいコミットが作成され
ます。 したがって、たとえば ‘git log -p notes/commits’ を実行することで
、ノートの履歴を調べることができます。 現在のところ、コミットメッセージ
には更新のきっかけとなった操作が記録されているだけで、コミットの作者は通
常のルールに従って決定されます(git-commit(1) 参照)。 これらの詳細は、将
来的に変更される可能性があります。

   ノートrefがツリーオブジェクトを直接指すことも許可されています。その場
合、ノートの履歴は ‘git log -p -g <refname>’ で読み取ることができます。

NOTES MERGE STRATEGIES
**********************

デフォルトのノートマージ戦略は「manual」です。これは、ノートの競合を解決
するために特別な作業ツリー(‘.git/NOTES_MERGE_WORKTREE’)で競合するノート
をチェックアウトし、そのワークツリーで競合を解決するようにユーザーに指示
します。完了したら、ユーザーは ‘git notes merge --commit’ を使用してマー
ジを完了するか、 ‘git notes merge --abort’ を使用してマージを中止できま
す。

   ユーザーは、‘-s’/‘--strategy’ オプションを使用するか、
notes.mergeStrategy を適宜構成して、以下の中から自動マージ戦略を選択でき
ます:

   「ours」は、競合するノートを自動的に解決して、ローカルバージョン(つま
り、現在のノートref)を優先します。

   「theirs」は、リモートバージョンを優先してノートの競合を自動的に解決
します(つまり、指定されたノートrefが現在のノートrefにマージされます)。

   「union」は、ローカルバージョンとリモートバージョンを連結することによ
り、ノートの競合を自動的に解決します。

   「cat_sort_uniq」は ‘union’ に似ていますが、この戦略は、ローカルバー
ジョンとリモートバージョンを連結することに加えて、結果の行を並べ替え、結
果から重複する行を削除します。 これは、 ‘cat | sort | uniq’ シェルパイプ
ラインをローカルバージョンとリモートバージョンに適用するのと同じです。こ
の戦略は、ノートが行ベースの形式に従っていて、マージ結果で行が重複しない
ようにする場合に役立ちます。 ローカルバージョンまたはリモートバージョン
のいずれかにマージ前に既に重複行が含まれている場合、これらもこのノートマ
ージ戦略によって削除されることに注意してください。

EXAMPLES
********

あなたはノートを使用して、コミットが書き込まれた時点では利用できなかった
情報を含む注釈を追加できます。

     $ git notes add -m 'Tested-by: Johannes Sixt <j6t@kdbg.org>' 72a144e2
     $ git show -s 72a144e
     [...]
         Signed-off-by: Junio C Hamano <gitster@pobox.com>

     Notes:
         Tested-by: Johannes Sixt <j6t@kdbg.org>

   原則として、ノートは通常のGitブロブであり、あらゆる種類の形式(または
非形式)が受け入れられます。 ‘git hash-object’ を使用して、任意のファイル
から安全にノートを作成できます:

     $ cc *.c
     $ blob=$(git hash-object -w a.out)
     $ git notes --ref=built add --allow-empty -C "$blob" HEAD

   (これはバイナリセーフ(binary-safe)ではないため、単純に ‘git notes
--ref=built add -F a.out HEAD’ を使用することはできません。) もちろん、
テキスト形式以外のノートを ‘git log’ で表示することはあまり意味がありま
せん。なので、あなたがそのようなノートを使用する場合は、それらを使用して
何か便利なことを行うために、あなたはおそらくいくつかの特別な目的のツール
を作成する必要があります。

CONFIGURATION
*************

core.notesRef
     ‘refs/notes/commits’ の代わりに読み取りおよび操作するノートref。省
     略されていないref名である必要があります。この設定は、環境およびコマ
     ンドラインから上書きできます。

notes.mergeStrategy
     ノートの競合を解決するときにデフォルトで選択するマージ戦略。
     ‘manual’ 、‘ ours‘、 ‘theirs’、‘ union‘ 、‘cat_sort_uniq’ のいずれ
     かである必要があります。 デフォルトは ‘manual’ です。 各戦略の詳細
     については、 「NOTES MERGE STRATEGIES」セクションを参照してください
     。

     この設定は、 ‘--strategy’ オプションを渡すことで上書きできます。

notes.<name>.mergeStrategy
     ‘refs/notes/<name>’ にノートをマージするときに、どのマージ戦略を選
     択するか。 これは、より一般的な ‘notes.mergeStrategy’ をオーバーラ
     イドします。 利用可能な戦略の詳細については、 「NOTES MERGE
     STRATEGIES」セクションを参照してください。

notes.displayRef
     ‘git log’ 系のコマンドでコミットメッセージを表示する際に、
     ‘core.notesRef’ や ‘GIT_NOTES_REF’ で設定したデフォルトに加えて、ど
     のref(あるいはグロブ(glob)で複数回指定した場合は複数のreef)からノー
     トを読み込むかを指定します。 この設定は、コマンドラインや環境変数
     ‘GIT_NOTES_DISPLAY_REF’ で上書きすることができます。 git-log(1) を
     参照してください。

notes.rewrite.<command>
     <command> (現在は ‘amend’ または ‘rebase’)を使用してコミットを書き
     換える時、この変数が ‘false’ の場合、gitは元のコミットから書き換え
     られたコミットにノートをコピーしません。 デフォルトは ‘true’ です。
     以下の ‘notes.rewriteRef’ も参照してください。

     この設定は、 ‘GIT_NOTES_REWRITE_REF’ 環境変数で上書きできます。

notes.rewriteMode
     書き換え中にノートをコピーするときに、ターゲットコミットにすでにノ
     ートがある場合の対処方法。 ‘overwrite’ 、 ‘concatenate’ 、
     ‘cat_sort_uniq’ 、 ‘ignore’ のいずれかである必要があります。 デフォ
     ルトは ‘concatenate’ です。

     この設定は、 ‘GIT_NOTES_REWRITE_MODE’ 環境変数でオーバーライドでき
     ます。

notes.rewriteRef
     書き換え中にノートをコピーする時に、ノートをコピーする(完全修飾され
     た)refを指定します。グロブ(glob)の可能性があります。その場合、一致
     するすべてのrefのノートがコピーされます。この構成を複数回指定するこ
     ともできます。

     デフォルト値はありません。 あなたがノートの書き換えを有効にするには
     、この変数を構成しなければなりません。

     ‘GIT_NOTES_REWRITE_REF’ 環境変数でオーバーライドできます。

ENVIRONMENT
***********

‘GIT_NOTES_REF’
     ‘refs/notes/commits’ の代わりに、どのrefからノートを操作するか。 こ
     れは ‘core.notesRef’ 設定を上書きします。

‘GIT_NOTES_DISPLAY_REF’
     コロンで区切られた ref または glob のリスト。コミットメッセージを表
     示する際に、デフォルトの ‘core.notesRef’ または ‘GIT_NOTES_REF’ に
     加えて、どの ref からノートを読み込むかを指定します。 これは
     ‘notes.displayRef’ の設定よりも優先されます。

     存在しないrefに対して警告が発行されますが、どのrefとも一致しないグ
     ロブ(glob)は黙って無視されます。

‘GIT_NOTES_REWRITE_MODE’
     書き換え中にノートをコピーするときに、ターゲットコミットにすでにノ
     ートがある場合の対処方法。 ‘overwrite’ 、‘concatenate’ 、
     ‘cat_sort_uniq’ 、‘ignore’ のいずれかである必要があります。 これは
     ‘core.rewriteMode’ 設定を上書きします。

‘GIT_NOTES_REWRITE_REF’
     コミットを書き換える場合、元のコミットから書き換えられたコミットに
     コピーするためのノート。refまたはグロブ(glob)のコロンで区切られたリ
     ストである必要があります。

     環境で設定されていない場合、コピーするノートのリストは、
     ‘notes.rewrite.<command>’ および ‘notes.rewriteRef’ の設定によって
     異なります。

GIT
***

Part of the git(1) suite

   ---------- Footnotes ----------

   (1) 許可されるパス名の形式は ‘bf/fe/30/.../680d5a...’ です。2桁の16進
数のディレクトリ名のシーケンスそれぞれの後に、残りのオブジェクトIDを含む
ファイル名が続きます。

Name
****

git-p4 — Perforceリポジトリからのインポートと、Perforceリポジトリへの
submit

Synopsis
********

     git p4 clone [<sync options>] [<clone options>] <p4 depot path>…
     git p4 sync [<sync options>] [<p4 depot path>…]
     git p4 rebase
     git p4 submit [<submit options>] [<master branch name>]

DESCRIPTION
***********

このコマンドは、Gitを使用してp4リポジトリと対話する方法を提供します。

   ’git p4 clone’を使用して既存のp4リポジトリから新しいGitリポジトリを作
成し、1つ以上のp4デポパス(depot path)を指定します。’git p4sync’を使用し
てp4の変更からの新しいコミットを組み込みます。’sync’コマンドは、他のp4デ
ポパスからの新しいブランチを含めるためにも使用されます。’git p4 submit’を
使用してGitの変更をp4に送信します。 コマンド’git p4 rebase’は同期を実行
し、現在のブランチを更新されたp4リモートブランチにリベースします。

EXAMPLES
********

   • リポジトリをクローンします:

          $ git p4 clone //depot/path/project

   • 新しく作成されたGitリポジトリでいくつかの作業を行います:

          $ cd project
          $ vi foo.h
          $ git commit -a -m "edited foo.h"

   • p4からの最近の変更でGitリポジトリを更新し、あなたの作業ツリーにリベ
     ースします:

          $ git p4 rebase

   • あなたのコミットを送信しp4へ戻します:

          $ git p4 submit

COMMANDS
********

Clone
=====

通常、’git p4 clone’は、既存のp4リポジトリから新しいGitディレクトリを作
成するために使用されます:

     $ git p4 clone //depot/path/project

   これは以下の事を行います:

  1. _project_ というサブディレクトリに空のGitリポジトリを作成します。

  2. 指定されたp4デポパス(p4 depot path)からGitブランチ
     _refs/remotes/p4/master_ の単一のコミットにヘッドリビジョンの全内容
     をインポートします。

  3. このリモートからローカルブランチ _master_ を作成し、チェックアウト
     します。

   Gitでp4履歴全体を再現するには、デポパス(dept path)で _@all_ 修飾子を
使用します:

     $ git p4 clone //depot/path/project@all

Sync
====

p4リポジトリで開発が継続されていて、それらの変更をGitリポジトリに取り込
むには以下を使用します:

     $ git p4 sync

   このコマンドは、p4の新しい変更を検出し、Gitがコミットするときにそれら
をインポートします。

   P4リポジトリは、 _git p4 sync_ を使用して既存のGitリポジトリに追加す
ることもできます:

     $ mkdir repo-git
     $ cd repo-git
     $ git init
     $ git p4 sync //path/in/your/perforce/depot

   これにより、指定したデポが既存のGitリポジトリの
_refs/remotes/p4/master_ にインポートされます。 ‘--branch’ オプションを
使用して、p4コンテンツに使用する別のブランチを指定することも可能です。

   Gitリポジトリにブランチ ‘refs/remotes/origin/p4’ が含まれている場合、
これらは ‘git p4 sync’ 実行中に最初にフェッチされて調べ(consult)られます
。p4から直接インポートするのは、Gitリモートから変更をプルするよりもかな
り遅いため、これは複数開発者環境(multi-developer environment)で役立ちま
す。

   複数のブランチがある場合、 ‘git p4 sync’ を実行すると、「BRANCH
DETECTION」アルゴリズムが自動的に使用され、新しい変更を適切なブランチに
分割しようとします。 これを ‘--branch’ オプションでオーバーライドして、
更新するブランチを1つだけ指定できます。

Rebase
======

一般的な動作パターンは、p4デポから最新の変更をフェッチし、それらをローカ
ルのコミットされていない変更とマージすることです。多くの場合、p4リポジト
リはすべてのコードの最終的な場所であるため、リベース作業フローは理にかな
っています。このコマンドは、 ‘git p4 sync’ に続いて ‘git rebase’ を実行
して、更新されたp4の変更に加えてローカルコミットを移動します。

     $ git p4 rebase

Submit
======

Gitリポジトリからp4リポジトリに変更を送信するには、別のp4クライアントワ
ークスペース(p4 client workspace)が必要です。 これは、 ‘P4CLIENT’ 環境変
数またはGit構成変数 ‘git-p4.client’ を使用して指定する必要があります。
p4クライアントは存在する必要がありますが、クライアントルート(client
root)がまだ存在しない場合は、クライアントルートが作成されて入力されます
。

   現在のGitブランチにはあるが、 ‘p4/master’ ブランチにはないすべての変
更を送信するには、以下を使用します:

     $ git p4 submit

   現在のブランチ以外のブランチを指定するには、以下を使用します:

     $ git p4 submit topicbranch

   単一のコミットまたはコミットの範囲を指定するには、以下を使用します:

     $ git p4 submit --commit <sha1>
     $ git p4 submit --commit <sha1..sha1>

   アップストリーム参照は一般的には _refs/remotes/p4/master_ ですが、
‘--origin=’ コマンドラインオプションを使用してオーバーライドできます。

   p4の変更は、ユーザーが ‘git p4 submit’ を呼び出すと作成されます。
‘--preserve-user’ オプションを使用すると、Gitコミットの作者(author)に応
じて所有権が変更されます。このオプションには、 ‘p4 protect’ を使用して付
与できるp4の管理者権限が必要です。

   送信する代わりに変更を保存するには、以下のように ‘--shelve’ と
‘--update-shelve’ を使用します:

     $ git p4 submit --shelve
     $ git p4 submit --update-shelve 1234 --update-shelve 2345

Unshelve
========

Unshelvingは、棚上げされたP4チェンジリスト(shelved P4 changelist)を取得
し、ブランチ refs/remotes/p4-unshelved/<changelist> で同等のgit commitを
生成します。

   git commitは、現在のoriginリビジョン(デフォルトではHEAD)を基準にして
作成されます。親コミットはoriginに基づいて作成され、次にunshelveコミット
はそれに基づいて作成されます。

   originリビジョンは、 ‘--origin’ オプションで変更できます。

   refs/remotes/p4-unshelved のターゲットブランチがすでに存在する場合、
古いブランチの名前が変更されます。

     $ git p4 sync
     $ git p4 unshelve 12345
     $ git show p4-unshelved/12345
     <submit more changes via p4 to the same files>
     $ git p4 unshelve 12345
     <refuses to unshelve until git is in sync with p4 again>

OPTIONS
*******

General options
===============

cloneを除くすべてのコマンドは、これらのオプションを受け入れます。

‘--git-dir <dir>’
     ‘GIT_DIR’ 環境変数を設定します。 git(1) 参照。

‘-v’
‘--verbose’
     より多くの進捗情報を提供します。

Sync options
============

これらのオプションは、最初の「クローン」(clone)操作と後続の「同期」
(sync)操作で使用できます。

‘--branch <ref>’
     変更を ‘refs/remotes/p4/master’ ではなく <ref> にインポートします。
     <ref>が ‘refs/’ で始まる場合は、そのまま使用されます。それ以外の場
     合、 ‘p4/’ で始まらない場合は、その接頭辞が追加されます。

     デフォルトでは、 ‘refs/’ で始まらない<ref>は、リモート追跡ブランチ
     の名前として扱われます(‘refs/remotes/’ の下)。この動作は、
     ‘--import-local’ オプションを使用して変更できます。

     <ref> のデフォルトは "master" です。

     この例では、新しい remote "p4/proj2" を既存のGitリポジトリにインポ
     ートします:

              $ git init
              $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2

‘--detect-branches’
     ブランチ検出アルゴリズムを使用して、p4の新しいパスを見つけます。 こ
     れは、以下の「BRANCH DETECTION」で解説してあります。

‘--changesfile <file>’
     <file> にリストされているp4変更番号(p4 change numbers)を1行に1つず
     つ正確にインポートします。 通常、 ‘git p4’ は、現在のp4リポジトリの
     状態を検査し、インポートする必要のある変更を検出します。

‘--silent’
     進捗情報を出力しません。

‘--detect-labels’
     デポパス(depot paths)に関連付けられているラベルをp4に問い合わせ、
     Gitにタグとして追加します。新しいチェンジリストに関連付けられたラベ
     ルのみをインポートするため、有用性は限られています。非推奨です。

‘--import-labels’
     p4からGitにラベルをインポートします。

‘--import-local’
     デフォルトでは、p4ブランチは ‘refs/remotes/p4/’ に保存され、
     git-branch(1) およびその他のコマンドによってリモート追跡ブランチと
     して扱われます。 このオプションは、代わりにp4ブランチを
     ‘refs/heads/p4/’ に配置します。このオプション使用後、今後の同期操作
     では、 ‘refs/heads’ でp4ブランチを見つけることができるように、
     ‘--import-local’ も指定する必要があることに注意してください。

‘--max-changes <n>’
     指定されたリビジョン指定子(revision specifier)に含まれる変更の全範
     囲ではなく、最大で <n> 個の変更をインポートします。通常の使用法は、
     リビジョン指定子として ‘@all’ を使用しますが、 ‘--max-changes 1000’
     を使用して、リビジョン履歴全体ではなく、最後の1000リビジョンのみを
     インポートします。

‘--changes-block-size <n>’
     ‘@all’ などのリビジョン指定子を特定の変更番号のリストに変換するとき
     に使用する内部ブロックサイズ。変換の変更の完全なリストを見つけるた
     めに ‘p4 changes’ への単一の呼び出しを使用する代わりに、 ‘p4
     changes -m’ への一連の呼び出しがあり、それぞれが指定のサイズの変更
     の1ブロックを要求します。デフォルトのブロックサイズは500で、通常は
     これが適切です。

‘--keep-path’
     デフォルトでは、p4デポパスからGitへのファイル名のマッピングには、デ
     ポパス全体の削除が含まれます。このオプションを使用すると、完全な
     p4デポパスがGitに保持されます。 たとえば、パス
     ‘//depot/main/foo/bar.c’ は、 ‘//depot/main/’ からインポートすると
     、 ‘foo/bar.c’ になります。 ‘--keep-path`を使用すると、Gitパスは代
     わりに `depot/main/foo/bar.c’ になります。

‘--use-client-spec’
     クライアント仕様(client spec)を使用して、p4でinterestingファイルの
     リストを見つけます。以下の「CLIENT SPEC」セクションを参照してくださ
     い。

‘-/ <path>’
     クローン作成または同期時に、選択したデポパスを除外します。

Clone options
=============

これらのオプションは、上記の「sync」オプションとともに、最初の「clone」
で使用できます。

‘--destination <directory>’
     Gitリポジトリを作成する場所。 指定しない場合、p4デポパス(p4 depot
     path)の最後のコンポーネントを使用して新しいディレクトリを作成します
     。

‘--bare’
     ベアクローン(bare clone)を実行します。 git-clone(1) を参照してくだ
     さい。

Submit options
==============

これらのオプションを使用して、「git p4 submit」の動作を変更できます。

‘--origin <commit>’
     p4に送信するコミットが識別される上流の場所。デフォルトでは、これは
     ‘HEAD’ から到達可能な最新のp4コミットです。

‘-M’
     名前の変更(renames)を検出します。 git-diff(1) を参照してください。
     名前の変更は、p4ででは明示的な「移動」操作を使用して表されます。コ
     ピーを検出するための対応するオプションはありませんが、移動とコピー
     の両方に変数があります。

‘--preserve-user’
     p4に送信する前に、p4の変更を再作成(re-author)してください。このオプ
     ションには、p4管理者権限が必要です。

‘--export-labels’
     Gitからタグをp4ラベルとしてエクスポートします。Gitで見つかったタグ
     は、perforce 作業ディレクトリに適用されます。

‘-n’
‘--dry-run’
     どのコミットがp4に送信されるかだけを表示します。Gitまたはp4の状態を
     変更しないでください。

‘--prepare-p4-only’
     通常の送信操作と同様に、p4ワークスペースにコミットを適用し、p4でフ
     ァイルを開いたり、追加したり、削除したりします。 最後の「p4送信」を
     発行しません。代わりに、手動で送信する方法または元に戻す方法に関す
     るメッセージを表示します。このオプションは、最初の(最も古い)コミッ
     ト後に常に停止(stop)します。Gitタグはp4にエクスポートされません。

‘--shelve’
     送信する代わりに、一連の棚上げされたチェンジリスト(shelved
     changelists)を作成します。各シェルフ(shelve)を作成した後、関連する
     ファイルは元に戻され(revert)/削除(delete)されます。保留中のコミット
     が複数ある場合は、複数のシェルフが作成されます。

‘--update-shelve CHANGELIST’
     このコミットで既存の棚上げされたチェンジリスト(shelved changelist)を
     更新します。 ‘--shelve’ の指定を含んでいます。複数の棚上げされたチ
     ェンジリストに対して繰り返します。

‘--conflict=(ask|skip|quit)’
     p4にコミットを適用すると、競合が発生する可能性があります。 これが発
     生した場合、デフォルトの動作("ask")は、このコミットをスキップして続
     行するか、終了するかを尋ねる動作です。このオプションを使用すると、
     プロンプトをバイパスして、競合するコミットを自動的にスキップしたり
     、プロンプトを表示せずにコミットの適用を中止(quit)したりできます。

‘--branch <branch>’
     送信後、デフォルトの p4/master の代わりに、この名前付きブランチを同
     期します。詳細については、上記の「Sync options」セクションを参照し
     てください。

‘--commit <sha1>|<sha1..sha1>’
     現在のGitブランチにある変更の完全なリストではなく、指定されたコミッ
     トまたはコミットの範囲のみを送信します。

‘--disable-rebase’
     すべてのコミットが正常に送信された後の自動リベースを無効にします。
     git-p4.disableRebase で設定することもできます。

‘--disable-p4sync’
     コミットが送信された後、Perforceからのp4/masterの自動同期を無効にし
     ます。 ‘--disable-rebase’ の指定を含んでいます。
     git-p4.disableP4Sync で設定することもできます。 可能であれば、
     origin/master との同期は引き続き続行されます。

Hooks for submit
****************

p4-pre-submit
=============

‘p4-pre-submit’ フックが存在し、実行可能である場合に実行されます。フック
はパラメータを受け取らず、標準入力からも何も受け取りません。このスクリプ
トをゼロ以外のステータスで終了すると、 ‘git-p4 submit’ が起動しなくなり
ます。 ‘--no-verify’ コマンドラインオプションでバイパスできます。

   使用シナリオの１つは、フックで単体テストを実行することです。

p4-prepare-changelist
=====================

‘p4-prepare-changelist’ フックは、デフォルトのチェンジリストメッセージを
準備した直後、エディタが起動する前に実行されます。 これは、変更リストの
テキストを含むファイルの名前という1つのパラメーターを取ります。スクリプ
トをゼロ以外のステータスで終了すると、プロセスが中止(abort)されます。

   フックの目的は、メッセージファイルをその場で編集することであり、
‘--no-verify’ オプションによって抑制されることはありません。このフックは
、 ‘--prepare-p4-only’ が設定されている場合でも呼び出されます。

p4-changelist
=============

‘p4-changelist’ フックは、ユーザーがチェンジリストメッセージを編集した後
に実行されます。 ‘--no-verify’ オプションでバイパスできます。提案された
チェンジリストテキストを保持するファイルの名前という単一のパラメータを取
ります。ゼロ以外のステータスで終了すると、コマンドは中止(abort)されます
。

   フックはチェンジリストファイルの編集を許可されており、テキストをプロ
ジェクトの標準形式に正規化するために使用できます。 また、メッセージファ
イルを検査した後に送信を拒否するために使用することもできます。

p4-post-changelist
==================

‘p4-post-changelist’ フックは、submitがP4で正常に発生した後に呼び出され
ます。 これはパラメーターを必要とせず、主に通知を目的としており、git p4
submitアクションの結果に影響を与えることはできません。

Rebase options
==============

これらのオプションを使用して、「git p4 rebase」の動作を変更できます。

‘--import-labels’
     p4ラベルのインポート。

Unshelve options
================

‘--origin’
     棚上げされたP4チェンジリスト(shelved P4 changelist)が比較される git
     refspec を設定します。デフォルトは p4/master です。

DEPOT PATH SYNTAX
*****************

‘git p4 sync’ と ‘gitp4 clone’ へのp4デポパス引数は、1つ以上のスペースで
区切られたp4デポパスにすることができ、最後にオプションのp4リビジョン指定
子があります:

"//depot/my/project"
     そのツリーの下の「#head」変更内のすべてのファイルを含む1つのコミッ
     トをインポートします。

"//depot/my/project@all"
     そのデポパスの履歴の変更ごとに1つのコミットをインポートします。

"//depot/my/project@1,6"
     1から6の変更のみをインポートする。

"//depot/proj1@all //depot/proj2@all"
     両方の名前付きのデポパスからのすべての変更を単一のリポジトリにイン
     ポートします。これらのディレクトリの下にあるファイルのみが含まれま
     す。 Gitには、「proj1」と「proj2」ごとのサブディレクトリはありませ
     ん。複数のデポパスを指定する場合は、‘--destination’ オプションを使
     用する必要があります。 リビジョン指定子は、各デポパスで同じように指
     定する必要があります。 同じ名前のファイルがデポパスにある場合、ファ
     イルの最新バージョンのパスがGitに表示されるパスになります。

   p4リビジョン指定子の完全な構文については、「p4 help revisions」を参照
してください。

CLIENT SPEC
***********

p4クライアントの仕様は、 ‘p4 client’ コマンドで維持され、他のフィールド
の中でも、デポがクライアントリポジトリにマップされる方法を指定するビュー
が含まれています。 ‘clone’ と ‘sync`コマンドは、 `--use-client-spec’ オ
プションが指定されているか、または useClientSpec 変数がtrueの場合に、ク
ライアント仕様(client spec)を参照できます。 ‘git p4 clone’ の後、
useClientSpec変数がリポジトリ構成ファイルに自動的に設定されます。これに
より、将来の ‘git p4 submit’ コマンドが正しく機能するようになります。
submitコマンドは変数のみを調べ、コマンドラインオプションはありません。

   p4ビューの完全な構文は、「p4 help views」に記載されています。 ‘git
p4’ は、ビュー構文のサブセットのみを認識します。 複数行のマッピング、「
+」のオーバーレイ、「-」の除外、空白の前後の二重引用符(‘"’)を理解します
。可能なワイルドカードのうち、 ‘git p4’ は ‘...’ のみを処理し、パスの最
後にある場合にのみ処理します。 ‘git p4’ は、未実装のワイルドカードに遭遇
すると文句を言います。

   バグ: オーバーラップマッピングの実装にはバグがあります。複数のデポパ
スがオーバーレイを介してリポジトリ内の同じ場所にマップされる場合、 ‘git
p4’ は間違ったパスを選択する可能性があります。 これは、 ‘git p4’ 専用の
クライアント仕様を使用せずに解決するのは困難です。

   クライアントの名前は、複数の方法で ‘git p4’ に指定できます。 変数
‘git-p4.client’ が存在する場合は、それが優先されます。 それ以外の場合は
、クライアントを決定する通常のp4メカニズムが使用されます。それは、環境変
数 ‘P4CLIENT’ または‘P4CONFIG‘ によって参照されるファイル または ローカ
ルホスト名 です。

BRANCH DETECTION
****************

P4には、Gitと同じブランチの概念はありません。代わりに、p4はそのコンテン
ツをディレクトリツリーとして編成します。慣例により、さまざまな論理ブラン
チがツリー内のさまざまな場所にあります。 ‘p4 branch’ コマンドは、ツリー
内の異なる領域間のマッピングを維持し、関連するコンテンツを示すために使用
されます。 ‘git p4’ は、これらのマッピングを使用してブランチの関係を判別
できます。

   対象のすべてのブランチが単一のデポパスのサブディレクトリとして存在す
るリポジトリがある場合、クローン作成または同期時に ‘--detect-branches’ を
使用して、 ‘git p4’ がp4内のサブディレクトリを自動的に検出し、これらを
Gitのブランチとして生成できます。

   たとえば、P4リポジトリ構造が以下の場合:

     //depot/main/...
     //depot/branch1/...

   そして、「p4 branch -o branch1」は、以下のようなビューライン(View
line)を表示します:

     //depot/main/... //depot/branch1/...

   それから、以下の _git p4 clone_ コマンドを実行します:

     git p4 clone --detect-branches //depot@all

   ‘refs/remotes/p4/’ には ‘//depot/main’ 用の ‘master’ というブランチと
‘//depot/branch1’ 用の ‘depot/branch1’ というブランチが別々に作成される
ことになります。

   ただし、ブランチのように使用できるようにするために、p4でブランチを作
成する必要はありません。ブランチ関係を自動的に推測することは難しいため、
Git構成設定 ‘git-p4.branchList’ を使用して、ブランチ関係を明示的に識別す
ることができます。これは、単純なp4ブランチ仕様のような
"source:destination" ペアのリストであり、 "source" と "destination" は
p4リポジトリ内のパス要素です。上記の例は、p4ブランチの存在に依存していま
した。 p4ブランチがない場合、同じ結果が以下の場合に発生します:

     git init depot
     cd depot
     git config git-p4.branchList main:branch1
     git p4 clone --detect-branches //depot@all .

PERFORMANCE
***********

‘git p4’ で使用される高速インポートメカニズムは、 ‘git p4 sync’ の呼び出
しごとに1つのパックファイルを作成します。通常、Gitガベージ圧縮
(git-gc(1))は、これらをより少ないパックファイルに自動的に圧縮しますが、
‘git repack -adf’ を明示的に呼び出すと、パフォーマンスが向上する場合があ
ります。

CONFIGURATION VARIABLES
***********************

以下の構成設定を使用して、 ‘git p4’ の振る舞いを変更できます。全てを見た
い時は「git-p4」セクションを参照してください。

General variables
=================

git-p4.user
     すべてのp4コマンドのオプションとして、 ‘-u <user>’ で指定されるユー
     ザー。代わりに環境変数 ‘P4USER’ を使用することができます。

git-p4.password
     すべてのp4コマンドのオプションとして、 ‘-P <password>’ で指定される
     パスワード。代わりに環境変数 ‘P4PASS’ を使用することができます。

git-p4.port
     すべてのp4コマンドのオプションとして ‘-p <port>’ で指定されるポート
     。代わりに、環境変数 ‘P4PORT’ を使用することができます。

git-p4.host
     全てのp4コマンドのオプションとして ‘-h <host>’ で指定されるホスト。
     代わりに環境変数 ‘P4HOST’ を使用することができます。

git-p4.client
     全てのp4コマンドのオプションとして ‘-c <client>’ で指定されるクライ
     アント。クライアントスペック(client spec)を含んでいます。

git-p4.retries
     ネットワークがタイムアウトした場合にp4コマンド(特に ‘p4 sync’)を再
     試行する回数を指定します。デフォルト値は 3 です。再試行を無効にする
     場合、またはp4バージョンが再試行をサポートしていない場合(2012.2より
     前)は、値を0に設定します。

Clone and sync variables
========================

git-p4.syncFromOrigin
     他のGitリポジトリからコミットをインポートする方がp4からインポートす
     るよりもはるかに高速であるため、Gitのリモートで最初にp4の変更を見つ
     けるメカニズムが存在します。 ‘refs/remote/origin/p4’ の下にブランチ
     が存在する場合、それらはp4から同期するときにフェッチされて使用され
     ます。 この変数を ‘false’ に設定して、この動作を無効にすることがで
     きます。

git-p4.branchUser
     ブランチ検出のフェーズの一つでは、p4ブランチを調べて、インポートす
     る新しいブランチを見つけます。デフォルトでは、すべてのブランチが検
     査されます。 このオプションは、検索を、変数で指定した単一のユーザー
     が所有するものだけに制限します。

git-p4.branchList
     ブランチ検出が有効になっている場合にインポートされるブランチのリス
     ト。各エントリは、コロン(‘:’)で区切られたブランチ名のペアである必要
     があります。以下の例では、branchAとbranchBの両方がmainから作成され
     たことを宣言しています:

          git config       git-p4.branchList main:branchA
          git config --add git-p4.branchList main:branchB

git-p4.ignoredP4Labels
     無視するp4ラベルのリスト。これは、インポートできないラベルが検出さ
     れると自動的に作成されます。

git-p4.importLabels
     ‘--import-labels’ に従って、p4ラベルをgitにインポートします。

git-p4.labelImportRegexp
     この正規表現にマッチするp4ラベルのみがインポートされます。 デフォル
     ト値は ‘[a-zA-Z0-9_\-.]+$’ です。

git-p4.useClientSpec
     対象のp4デポパスを識別するためにp4クライアント仕様(p4 client spec)を
     使用する必要があることを指定します。これは、オプション
     ‘--use-client-spec’ を指定するのと同じです。上記の「CLIENT SPEC」セ
     クションを参照してください。 この変数はブール値であり、p4クライアン
     トの名前ではありません。

git-p4.pathEncoding
     Perforceは、元のOSによって指定されたパスのエンコーディングを保持し
     ます。 Gitは、UTF-8としてエンコードされたパスを想定しています。 こ
     の設定を使用して、PERFORCEがパスに使用したエンコーディングを
     git-p4に通知します。 このエンコーディングは、パスのエンコーディング
     をUTF-8に変換するために使用されます。例として、Windows上の
     PERFORCEは、パス名をエンコードするために "cp1252" を使用することが
     よくあります。

git-p4.largeFileSystem
     大きな(バイナリ)ファイルに使用されるシステムを指定します。ラージフ
     ァイルシステム(large file systems)は ‘git p4 submit’ コマンドをサポ
     ートしていないことに注意してください。 現在、Git LFSのみが実装され
     ています(詳細については、 https://git-lfs.github.com/
     (https://git-lfs.github.com/) を参照してください)。このオプションを
     使用して以下のように構成するには、Git LFSコマンドライン拡張機能をダ
     ウンロードしてインストールします:

          git config       git-p4.largeFileSystem GitLFS

git-p4.largeFileExtensions
     リスト内のファイル拡張子に一致するすべてのファイルは、ラージファイ
     ルシステムによって処理されます。 拡張子の前に ‘.’ を付けないでくだ
     さい。

git-p4.largeFileThreshold
     非圧縮サイズがしきい値を超えるすべてのファイルは、ラージファイルシ
     ステム(large file system)によって処理されます。デフォルトでは、しき
     い値はバイト単位で定義されています。 単位を変更するには、接尾辞k、
     m、gを追加します。

git-p4.largeFileCompressedThreshold
     圧縮サイズがしきい値を超えるすべてのファイルは、ラージファイルシス
     テム(large file system)によって処理されます。このオプションを使用す
     ると、クローン/同期プロセスの速度が低下する可能性があります。デフォ
     ルトでは、しきい値はバイト単位で定義されています。 単位を変更するに
     は、接尾辞k、m、gを追加します。

git-p4.largeFilePush
     大きなファイルをサーバーに自動的にプッシュするかどうかを定義するブ
     ール変数。

git-p4.keepEmptyCommits
     このブールオプションがtrueに設定されている場合、除外されたファイル
     のみを含むチェンジリストは空のコミットとしてインポートされます。

git-p4.mapUser
     P4 user をGitのnameとemail addressにマッピングします。以下の形式の
     文字列を使用して、マッピングを作成します:

          git config --add git-p4.mapUser "p4user = First Last <mail@address.com>"

     マッピングは、P4からのユーザー情報を上書きします。複数のP4ユーザー
     のマッピングを定義できます。

Submit variables
================

git-p4.detectRenames
     名前の変更(renames)を検出します。git-diff(1) を参照してください。 こ
     れは、true または、false または ‘git diff -M’ で期待されるスコアに
     なります。

git-p4.detectCopies
     コピーを検出します。 git-diff(1) を参照してください。 これは、true
     または false または ‘git diff -C’ で期待されるスコアになります。

git-p4.detectCopiesHarder
     コピーをより厳しく検出します。 git-diff(1) を参照してください。 ブ
     ール値です。

git-p4.preserveUser
     送信時に、誰が ‘git p4 submit’ を呼び出したかに関係なく、Git作者
     (author)を反映するように変更を再作成(re-author)します。

git-p4.allowMissingP4Users
     ‘preserveUser’ がtrueの場合、 ‘git p4’ は通常、p4ユーザーマップで作
     者(author)が見つからない場合に停止(die)します。この設定は、それを気
     にせずに変更を送信します。

git-p4.skipSubmitEdit
     送信プロセスは、各p4変更が送信される前にエディタを呼び出します。た
     だし、この設定がtrueの場合、編集手順はスキップされます。

git-p4.skipSubmitEditCheck
     p4変更メッセージを編集した後、 ‘git p4’ は、ファイルの変更時刻を調
     べて、説明が実際に変更されたことを確認します。このオプションは、そ
     の変更時刻を調べるテストを無効にします。

git-p4.allowSubmit
     デフォルトでは、任意のブランチを ‘git p4 submit’ 操作のソースとして
     使用できます。 この構成変数が設定されている場合、指定されたブランチ
     のみを送信ソースとして使用できます。ブランチ名は短い名前
     (‘refs/heads/’ は不可)である必要があり、スペースを入れずにコンマ
     (‘,’)で区切る必要があります。

git-p4.skipUserNameCheck
     ‘git p4 submit’ を実行しているユーザーがp4ユーザーマップに存在しな
     い場合、 ‘git p4’ は終了(exit)します。このオプションは、関係なく送
     信を強制するために使用できます。

git-p4.attemptRCSCleanup
     有効にすると、 ‘git p4submit’ はRCSキーワード($Header$ など)のクリ
     ーンアップを試みます。そうしないと、マージの競合が発生し、送信が続
     行できなくなります。 このオプションは、現時点では実験的なものと見な
     す必要があります。

git-p4.exportLabels
     ‘--export-labels’ に従って、Gitタグをp4ラベルにエクスポートします。

git-p4.labelExportRegexp
     この正規表現にマッチするp4ラベルのみがエクスポートされます。 デフォ
     ルト値は ‘[a-zA-Z0-9_\-.]+$’ です。

git-p4.conflict
     ‘--conflict’ に従って、p4との競合が見つかった場合の送信動作を指定し
     ます。デフォルトの動作は「ask」です。

git-p4.disableRebase
     送信後に p4/master に対してツリーをリベースしないでください。

git-p4.disableP4Sync
     送信後に p4/master を Perforce と同期しないでください。
     git-p4.disableRebase の指定を含んでいます。

IMPLEMENTATION DETAILS
**********************

   • p4からのチェンジセットは、Git fast-import を使用してインポートされ
     ます。

   • クローン作成または同期には、p4クライアントは必要ありません。ファイ
     ルの内容は ‘p4 print’ を使用して収集されます。

   • 送信するには、Gitリポジトリと同じ場所にないp4クライアントが必要です
     。パッチは、このp4クライアントに一度に1つずつ適用され、そこから送信
     されます。

   • ‘git p4’ によってインポートされた各コミットには、ログメッセージの最
     後にp4デポの場所と変更番号を示す行があります。 この行は、後の ‘git
     p4 sync’ 操作で、どのp4の変更が新しいかを知るために使用されます。

GIT
***

Part of the git(1) suite

Name
****

git-pack-objects — オブジェクトのパックされたアーカイブを作成する

Synopsis
********

     git pack-objects [-q | –progress | –all-progress] [–all-progress-implied]
             [–no-reuse-delta] [–delta-base-offset] [–non-empty]
             [–local] [–incremental] [–window=<n>] [–depth=<n>]
             [–revs [–unpacked | –all]] [–keep-pack=<pack-name>]
             [–stdout [–filter=<filter-spec>] | base-name]
             [–shallow] [–keep-true-parents] [–[no-]sparse] < object-list

DESCRIPTION
***********

標準入力からオブジェクトのリストを読み取り、指定されたベース名を持つ1つ
以上のパックされたアーカイブをディスクに書き込むか、パックされたアーカイ
ブを標準出力に書き出します。

   パックされたアーカイブは、2つのリポジトリ間でオブジェクトのセットを転
送するための効率的な方法であり、アクセス効率の高いアーカイブ形式でもあり
ます。パックされたアーカイブでは、オブジェクトはその全体を圧縮したものと
して、または他のオブジェクトとの差分として保存されます。後者はしばしばデ
ルタ(delta)と呼ばれます。

   パックされたアーカイブ形式(.pack)は、自己完結型であるように設計されて
いるため、それ以上の情報がなくても解凍できます。したがって、デルタが依存
する各オブジェクトがパック内に存在する必要があります。

   パックインデックスファイル(.idx)が、パック内のオブジェクトへの高速で
ランダムなアクセスのために生成されます。インデックスファイル(.idx)とパッ
クされたアーカイブ(.pack)の両方を $GIT_OBJECT_DIRECTORY の pack/ サブデ
ィレクトリ（または $GIT_ALTERNATE_OBJECT_DIRECTORIES の任意のディレクト
リ)に配置すると、Gitはパックアーカイブから読み取ることができます。

   _git unpack-objects_ コマンドは、パックされたアーカイブを読み取り、パ
ックに含まれるオブジェクトを「1ファイル1オブジェクト」形式に展開できます
。これは通常、ピアによる効率的なネットワーク転送のためにパックがオンザフ
ライで作成されるときに、smart-pullコマンドによって実行されます。

OPTIONS
*******

base-name
     ファイルのペア(.packと.idx)に書き込み、そして、 <base-name> を使用
     して、作成されたファイルの名前を決定します。このオプションを使用す
     ると、ペアの2つのファイルが <base-name>-<SHA-1>.{pack,idx} ファイル
     に書き込まれます。 <SHA-1>は、パックの内容に基づくハッシュであり、
     コマンドの標準出力にも書き込まれます。

‘--stdout’
     パックの内容(.packファイルに書き込まれる内容)を標準出力に書き込みま
     す。

‘--revs’
     個々のオブジェクト名ではなく、標準入力からリビジョン引数を読み取り
     ます。リビジョン引数は、 ‘git rev-list’ と同じ方法で処理され、
     ‘--objects’ フラグはその「commit」引数を使用して、出力するオブジェ
     クトのリストを作成します。結果のリストのオブジェクトはパックされま
     す。リビジョンに加えて、 ‘--not’ または ‘--shallow <SHA-1>’ 行も受
     け入れられます。

‘--unpacked’
     これは ‘--revs’ の指定を含んでいます。標準入力から読み取られたリビ
     ジョン引数のリストを処理するときは、オブジェクトのパッキングを未だ
     パックされていないオブジェクトに制限してください。

‘--all’
     これは ‘--revs’ の指定を含んでいます。標準入力から読み取られたリビ
     ジョン引数のリストに加えて、 ‘refs/’ の下のすべてのrefが含まれるよ
     うに指定してあるかのように振る舞います。

‘--include-tag’
     参照するオブジェクトが結果のパックファイルに含まれている場合は、要
     求されていない注釈付きタグを含めます。これは、ネイティブGitクライア
     ントに新しいタグを送信するのに役立ちます。

‘--stdin-packs’
     オブジェクト名やリビジョン引数ではなく、標準入力からパックファイル
     (例: ‘pack-1234abcd.pack’)のベース名を読み取ります。 結果のパックに
     は、除外されたパック( ‘^`で始まる)にリストされているオブジェクトを
     除く、含まれているパック(’^‘ で始まらないもの)にリストされているす
     べてのオブジェクトが含まれます。

     互換性のある ‘--unpacked’ を除いて、‘ –revs‘ または、 ‘--revs’ を含
     むオプション(‘ –all‘ など)とは互換性がありません。

‘--window=<n>’
‘--depth=<n>’
     これらの2つのオプションは、パックに含まれるオブジェクトをデルタ圧縮
     を使用して格納する方法に影響します。オブジェクトは最初にタイプとサ
     イズ、および、オプションで名前で、内部的にソートされ、 ‘--window’ 内
     の他のオブジェクトと比較されて、デルタ圧縮を使用することでスペース
     が節約されるかどうかが確認されます。 ‘--depth’ は、最大デルタ深度を
     制限します。 深くしすぎると、必要なオブジェクトに到達するために差分
     データを何度も適用する必要があるため、パック解凍側のパフォーマンス
     に影響します。

     ‘--window’ のデフォルト値は10で、 ‘--depth’ のデフォルト値は50です
     。 ‘--depth’ の最大深度は4095です。

‘--window-memory=<n>’
     このオプションは、 ‘--window’ に加えて追加の制限を提供します。ウィ
     ンドウサイズは、メモリ内で ‘<n>’ バイトを超えないように動的に縮小さ
     れます。これは、大きなオブジェクトと小さなオブジェクトが混在するリ
     ポジトリで、大きなウィンドウでメモリを使い果たさないようにしつつ、
     小さなオブジェクトには大きなウィンドウを活用できるようにするために
     有効です。サイズには、「k」または「m」または「g」の接尾辞を付けるこ
     とができます。 ‘--window-memory=0’ は、メモリ使用量を無制限にします
     。デフォルトは、 ‘pack.windowMemory’ 構成変数から取得されます。

‘--max-pack-size=<n>’
     めったにないシナリオですが、ファイルシステム上に特定のサイズより大
     きいファイルを作成できない場合があります。このオプションを使用して
     、出力パックファイルをそれぞれ指定されたサイズ以下の複数の独立した
     パックファイルに分割するようにコマンドに指示できます。 サイズには、
     「k」または「m」または「g」の接尾辞を付けることができます。許可され
     る最小サイズは1MiBに制限されています。 構成変数
     ‘pack.packSizeLimit’ が設定されていない限り、デフォルトは無制限です
     。このオプションを使用すると、リポジトリが大きくなり、速度が低下す
     る可能性があることに注意してください。 ‘pack.packSizeLimit’ の説明
     を参照してください。

‘--honor-pack-keep’
     このフラグにより、.keepファイルを含むローカルパックにすでに含まれて
     いるオブジェクトは、他の方法でパックされていたとしても無視されます
     。

‘--keep-pack=<pack-name>’
     このフラグにより、指定のパックにすでに含まれているオブジェクトは、
     他の方法でパックされていたとしても無視されます。 ‘<pack-name>’ は、
     先頭にディレクトリ名がないパックファイル名です(例:
     ‘pack-123.pack’)。このオプションは、複数のパックを保持するために複
     数回指定できます。

‘--incremental’
     このフラグにより、すでにパックされているオブジェクトは、他の方法で
     パックされていたとしても無視されます。

‘--local’
     このフラグにより、代替オブジェクトストアから借用されたオブジェクト
     は、他の方法でパックされていたとしても無視されます。

‘--non-empty’
     少なくとも1つのオブジェクトが含まれる場合にのみパックされたアーカイ
     ブを作成します。

‘--progress’
     ‘-q’ が指定されていない場合、進行状況は、端末に接続されている場合、
     デフォルトで標準エラーストリームに報告されます。このフラグは、標準
     エラーストリームが端末に送信されていない場合でも、進行状況を強制し
     ます。

‘--all-progress’
     ‘--stdout’ を指定すると、進行状況レポートはオブジェクトのカウントお
     よび圧縮フェーズでは表示されますが、書き込みフェーズでは禁止されま
     す。その理由は、場合によっては、出力ストリームが別のコマンドに直接
     リンクされており、受信パックデータを処理するときに独自の進行状況を
     表示したい場合があるためです。このフラグは ‘--progress’ に似ていま
     すが、 ‘--stdout’ が使用されている場合でも、書き込みフェーズの進行
     状況レポートを強制する点が異なります。

‘--all-progress-implied’
     これは、進行状況の表示がアクティブになるたびに ‘--all-progress’ の
     指定を含ませるために使用されます。 ‘--all-progress’ とは異なり、こ
     のフラグは実際には進行状況の表示を強制しません。

‘-q’
     このフラグにより、コマンドは標準エラーストリームで進行状況を報告し
     なくなります。

‘--no-reuse-delta’
     既存のパックがあるリポジトリに、パックされたアーカイブを作成する場
     合、コマンドは既存のデルタを再利用します。これにより、パックがわず
     かに最適化されない場合があります。このフラグは、既存のデルタを再利
     用せずに最初から計算するようにコマンドに指示します。

‘--no-reuse-object’
     このフラグは、削除されていないオブジェクトを含め、既存のオブジェク
     トデータをまったく再利用しないようにコマンドに指示し、すべてを強制
     的に再圧縮します。 これは、 ‘--no-reuse-delta’ の指定を含みます。パ
     ックされたデータに異なる圧縮レベルを大規模に適用する必要がある曖昧
     模糊なケースでのみ役立ちます。

‘--compression=<n>’
     生成するパック内の新しく圧縮するデータの圧縮レベルを指定します。指
     定しない場合、パックの圧縮レベルは pack.compression 、
     core.compression の順で取得します。どちらも設定されていない場合は、
     zlibのデフォルトである -1 になります。ソースに関係なくすべてのデー
     タに均一な圧縮レベルを強制する場合は、 ‘-no-reuse-object’ オプショ
     ンを追加します。

‘--[no-]sparse’
     ‘--revs’ オプションと組み合わせた場合、「スパース」(sparse)アルゴリ
     ズムを切り替えて、パックに含めるオブジェクトを決定します。このアル
     ゴリズムは、新しいオブジェクトを導入するパスに現れるツリーのみをウ
     ォークします。これは、小さな変更を送信するためのパックを計算すると
     きに、パフォーマンスに大きなメリットをもたらす可能性があります。た
     だし、含まれているコミットに特定の種類の直接名前変更(direct
     renames)含まれている場合は、パックファイルに追加のオブジェクトが追
     加される可能性があります。このオプションが含まれていない場合、デフ
     ォルトで ‘pack.useSparse’ の値になります。 ‘pack.useSparse’ の値は
     、特に指定されていない限りtrueです。

‘--thin’
     ネットワーク転送を減らすために、送信者と受信者の間の共通オブジェク
     トを省略して「薄い」(thin)パックを作成します。このオプションは、
     ‘--stdout’ と組み合わせた場合にのみ意味があります。

     注意: 薄いパックは、必要なオブジェクトを省略するという理由でパック
     されたアーカイブ形式に違反するため、Gitは自己完結型にしないと使用で
     きません。 ‘git index-pack --fix-thin’ (git-index-pack(1) を参照)を
     使用して、自己完結型のプロパティを復元します。

‘--shallow’
     浅いリポジトリ(shallow repository)を持つクライアントに提供されるパ
     ックを最適化します。このオプションを ‘--thin’ と組み合わせると、速
     度を犠牲にしてパックを小さくすることができます。

‘--delta-base-offset’
     パックされたアーカイブは、デルタのベースオブジェクトを20バイトのオ
     ブジェクト名またはストリーム内のオフセットのいずれかで表現できます
     が、Gitの古いバージョンは後者を理解していません。 デフォルトでは、
     ‘git pack-objects’ は互換性を高めるために前者の形式のみを使用します
     。このオプションを使用すると、コマンドで後者の形式を使用してコンパ
     クトにすることができます。平均デルタチェーンの長さに応じて、このオ
     プションは通常、結果のパックファイルを3〜5パーセント縮小します。

     注意: 最新のGitでは、 ‘git gc’ (git-gc(1) 参照)や ‘git repack’
     (git-repack(1) 参照)などの磁器コマンドは、あなたのリポジトリ内のフ
     ァイルをパックファイルに入れるときに、デフォルトでこのオプションを
     渡します。バンドルを作成する ‘git bundle’ (git-bundle(1) 参照)も同
     様です。

‘--threads=<n>’
     最適なデルタマッチングを検索するときに生成するスレッドの数を指定し
     ます。これには、pack-objectsをpthreadでコンパイルする必要があります
     。そうでない場合、このオプションは警告とともに無視されます。これは
     、マルチプロセッサマシンでのパッキング時間を短縮することを目的とし
     ています。ただし、デルタ検索ウィンドウに必要なメモリ量は、スレッド
     数で乗算されます。 0を指定すると、GitはCPUの数を自動検出し、それに
     応じてスレッドの数を設定します。

‘--index-version=<version>[,<offset>]’
     これは、テストスイートでのみ使用することを目的としています。生成す
     るパックインデックスのバージョンを強制し、指定のオフセット上にある
     オブジェクトに64ビットインデックスエントリを強制することができます
     。

‘--keep-true-parents’
     このオプションを使用すると、graftsによって隠されている親はそれでも
     パックされます。

‘--filter=<filter-spec>’
     ‘--stdout’ が必要です。結果のパックファイルから特定のオブジェクト
     (通常はブロブ)を省略します。 有効な ‘<filter-spec>’ 形式ついては、
     git-rev-list(1) を参照してください。

‘--no-filter’
     以前の任意の ‘--filter=’ 引数をオフにします。

‘--missing=<missing-action>’
     将来の「partial clone」(部分クローン)開発に役立つデバッグオプション
     。このオプションは、欠落しているオブジェクトの処理方法を指定します
     。

     _–missing=error_ は、欠落しているオブジェクトが検出された場合に、
     pack-objectsがエラーで停止することを要求します。リポジトリが部分ク
     ローン(partial clone)の場合は、欠落していると言う前に、欠落している
     オブジェクトをフェッチしようとします。 _–missing=error_ がデフォル
     トの操作です。

     _–missing=allow-any_ は、欠落しているオブジェクトが検出された場合で
     も、オブジェクトの走査(object traversal)を続行できます。欠落してい
     るオブジェクトのフェッチは発生しません。欠落しているオブジェクトは
     、結果から警告無しに黙って省略されます。

     _–missing=allow-promisor_ は _allow-any_ に似ていますが、オブジェク
     トの走査は、「予想される」promisorが欠落しているオブジェクトに対し
     てのみ続行できます。欠落しているオブジェクトのフェッチは発生しませ
     ん。予期しないオブジェクトの欠落により、エラーが発生します。

‘--exclude-promisor-objects’
     promisorリモートにあることがわかっているオブジェクトを省略します。
     (このオプションは、ローカルで作成されたオブジェクトのみを操作するこ
     とを目的としているため、再パックするときに、ローカルで作成されたオ
     ブジェクト[.promisor なし]とpromisorリモートのオブジェクト
     [.promisor あり]の区別を維持します。) これは部分クローン(partial
     clone)で使用されます。

‘--keep-unreachable’
     ‘--unpacked=’ オプションで指定されたパック内の参照から到達不能なオ
     ブジェクトは、 ‘*.keep’ ファイルでマークされたパック内にない到達可
     能オブジェクトに加えて、結果のパックに追加されます。 これは
     ‘--revs’ の指定を含んでいます。

‘--pack-loose-unreachable’
     到達不能な緩いオブジェクト(loose objects)をパックします(そしてそれ
     らの緩いオブジェクトを削除します)。 これは ‘--revs’ の指定を含んで
     います。

‘--unpack-unreachable’
     到達不能なオブジェクトは緩い(loose)オブジェクト形式のままにしてくだ
     さい。これは ‘--revs’ の指定を含んでいます。

‘--delta-islands’
     「islands」に基づいてデルタのマッチを制限します。 以下の DELTA
     ISLANDS を参照してください。

DELTA ISLANDS
*************

可能な場合、 ‘pack-objects’ は既存のディスク上のデルタを再利用して、その
場で新しいデルタを検索する必要がないようにします。これは、フェッチを提供
するための重要な最適化です。つまりこれは、サーバーがほとんどのオブジェク
トの展開作業を回避し、ディスクから直接バイトを送信できることを意味するた
めです。この最適化は、受信側が持っていない(そしてまだ送信していない)ベー
スに対するデルタとしてオブジェクトが保存されている場合は機能しません。そ
の場合、サーバーはデルタを「壊し」、CPUコストの高い新しいデルタを見つけ
る必要があります。したがって、パフォーマンスにとって重要なのは、ディスク
上のデルタ関係にあるオブジェクトのセットが、クライアントがフェッチするも
のと一致することです。

   通常のリポジトリでは、これは自動的に機能する傾向があります。オブジェ
クトのほとんどはブランチとタグから到達可能であり、それがクライアントがフ
ェッチするものです。サーバー上で検出されたデルタは、クライアントが既に持
っているモノとこれから持つ予定のオブジェクトの間にある可能性があります。

   ただし、一部のリポジトリ設定では、いくつかの関連しているが別個のref先
端のグループがあり、クライアントはそれらのグループを個別にフェッチする傾
向があります。 たとえば、単一の共有オブジェクトストアでリポジトリの複数
の「フォーク」をホストし、クライアントがそれらを ‘GIT_NAMESPACE’ を介し
て個別のリポジトリとして、または代替メカニズムを使用して個別のリポジトリ
として表示できるようにする場合を考えてみます。素朴な再パックでは、オブジ
ェクトの最適なデルタが、別のフォークでのみ検出されるベースに対してのもの
であることがわかる場合があります。ただし、クライアントがフェッチするとき
、クライアントにはベースオブジェクトがないため、その場で新しいデルタを見
つける必要があります。

   関連するオブジェクトを指す ‘refs/heads/’ と ‘refs/tags/’ のほかに多く
の参照がある場合(たとえば一部のホスティングプロバイダーで使用される
‘refs/pull’ や ‘refs/Changes’ )、同様の状況が存在する可能性があります。
デフォルトでは、クライアントはヘッドとタグのみをフェッチし、それらの他の
グループでのみ見つかったオブジェクトに対するデルタをそのまま送信すること
はできません。

   デルタ島(delta islands)は、refを個別の「島」にグループ化できるように
することで、この問題を解決します。 Pack-objectsは、どのオブジェクトがど
の島から到達可能かを計算し、全く ‘A’ 島に存在しないベースに対してオブジ
ェクト ‘A’ からデルタを作成することを拒否します。これにより、パックがわ
ずかに大きくなります(デルタ化の機会を逃すため)が、1つの島のフェッチで、
島の境界を越えるためにその場でデルタを再計算する必要がないことが保証され
ます。

   デルタ島(delta islands)で再パックする場合、デルタ窓は、構成によって禁
止されている候補で詰まる傾向があります。大きな ‘--window’ で再梱包するこ
とが助けになります(コンテンツに対して計算を行う前に、島に基づいて一部の
オブジェクトペアを拒否できるため、他の方法ほど長くはかかりません)。

   島は、複数回指定できる ‘pack.island’ オプションを介して構成されます。
各値は、refnames に一致する左アンカーの正規表現(left-anchored regular
expressions)です。 例えば:

     [pack]
     island = refs/heads/
     island = refs/tags/

   ヘッドとタグを島に配置します(名前は空の文字列です。名前の詳細について
は、以下を参照してください)。 これらの正規表現に一致しない参照(例:
‘refs/pull/123’)は、どの島にもありません。 したがって、 ‘refs/pull/’ か
らのみ到達可能(ヘッドやタグは不可)のオブジェクトは、 ‘refs/heads/’ のベ
ースとして使用される候補にはなりません。

   参照は「名前」に基づいて島にグループ化され、同じ名前を生成する2つの正
規表現は同じ島にあると見なされます。名前は、正規表現で間に「-」ダッシュ
があるキャプチャグループを連結することにより、正規表現から計算されます
(訳注:[0-9]+ の部分)。(キャプチャグループがない場合、上記の例のように、
名前は空の文字列になります。) これにより、任意の数の島を作成できます。 た
だし、このようなキャプチャグループは最大14個しかサポートされていません。

   たとえば、各フォークの参照を ‘refs/virtual/ID’ に格納するとします。こ
こで、 ‘ID’ は数値識別子です。 次に、以下を構成します:

     [pack]
     island = refs/virtual/([0-9]+)/heads/
     island = refs/virtual/([0-9]+)/tags/
     island = refs/virtual/([0-9]+)/(pull)/

   これにより、各フォークのヘッドとタグがそれぞれの島( "1234” などの名前
)に配置され、それぞれのプルrefsが独自の "1234-pull" になります。

   注意: 「最後の1つが勝つ」順序を使用して、正規表現ごとに1つの島を選択
することに注意してください(これにより、リポジトリ固有の構成がユーザー全
体の構成よりも優先されます)。

CONFIGURATION
*************

さまざまな構成変数がパッキングに影響します。 git-config(1) を参照してく
ださい( pack および delta を検索してください)。

   特に、デルタ圧縮は、 ‘core.bigFileThreshold’ 構成変数より大きいオブジ
ェクト、および属性 ‘delta’ がfalseに設定されているファイルでは使用されま
せん。

SEE ALSO
********

git-rev-list(1) git-repack(1) git-prune-packed(1)

GIT
***

Part of the git(1) suite

Name
****

git-pack-redundant — 無駄なパックファイルを探す

Synopsis
********

     git pack-redundant [ –verbose ] [ –alt-odb ] < –all | .pack filename … >

DESCRIPTION
***********

このプログラムは、リポジトリ内のどのパックが無駄であるかを計算します。あ
なたがリポジトリのルートにいる場合、出力は ‘xargsrm’ へのパイプに適して
います。

   _git pack-redundant_ は、標準入力のオブジェクトのリストを受け入れます
。無駄でない必要なパックを確認するとき、指定した任意のオブジェクトはすべ
て無視されます。これにより、到達不能なオブジェクトを含むパックを削除する
場合に、以下のコマンドが役立ちます。

   git fsck –full –unreachable | cut -d ’ ’ -f3 | \ git pack-redundant
–all | xargs rm

OPTIONS
*******

‘--all’
     すべてのパックを処理します。コマンドラインのファイル名はすべて無視
     されます。

‘--alt-odb’
     代替オブジェクトディレクトリのパックに存在するオブジェクトがローカ
     ルパックに存在する必要なしとします。

‘--verbose’
     いくつかの統計をstderrに出力します。 パフォーマンスの低下はわずかで
     す。

SEE ALSO
********

git-pack-objects(1) git-repack(1) git-prune-packed(1)

GIT
***

Part of the git(1) suite

Name
****

git-pack-refs — 効率的なリポジトリアクセスのためにヘッド(heads)とタグ
(tags)をパックします

Synopsis
********

     git pack-refs [–all] [–no-prune]

DESCRIPTION
***********

旧来、ブランチとタグのヒント(まとめて「refs」と呼ばれます)は、refごとに
1つのファイルを ‘$GIT_DIR/refs’ ディレクトリの下のディレクトリ(サブディ
レクトリ)に保存していました。多くのブランチヒントは頻繁に更新される傾向
がありますが、ほとんどのタグと一部のブランチヒントは更新されません。リポ
ジトリに数百または数千のタグがある場合、この 1ファイル毎に1ref形式 はス
トレージを浪費し、パフォーマンスを低下させます。

   このコマンドは、refを単一のファイル ‘$GIT_DIR/packed-refs’ に保存する
ことにより、ストレージとパフォーマンスの問題を解決するために使用されます
。旧来の ‘$GIT_DIR/refs’ ディレクトリ階層にrefがない場合、このファイルの
中から探し、見つかればそれが使用されます。

   その後のブランチの更新では、常に ‘$GIT_DIR/refs’ ディレクトリ階層の下
に新しいファイルが作成されます。

   refが多すぎるリポジトリを処理するための推奨される方法は、refを
‘--all’ で一度パックし、ときどき ‘git pack-refs’ を実行することです。タ
グは定義上静止しており、変更されることは期待されていません。ブランチヘッ
ドは最初の ‘pack-refs --all’ でパックされますが、現在アクティブなブラン
チヘッドのみはアンパックされ、その後 ‘pack-refs’ ( ‘--all’ なし)ではアン
パックされたままになります。

OPTIONS
*******

‘--all’
     このコマンドはデフォルトでは、すでにパックされているすべてのタグと
     refをパックし、他のrefはそのままにします。これは、ブランチが積極的
     に開発されることが期待されており、そのヒントをパックしてもパフォー
     マンスが向上しないためです。このオプションを使用すると、ブランチの
     ヒントもパックされます。 歴史的な関心のある多くのブランチがあるリポ
     ジトリに役立ちます。

‘--no-prune’
     コマンドは通常、それらをパックした後、 ‘$GIT_DIR/refs’ 階層の下の緩
     いrefを削除します。このオプションは、そうしないように指示します。

BUGS
****

pack-refs メカニズムが導入される前に作成された古い文書では、 "branch
<branch> exists" という意味の場合でも ".git/refs/heads/<branch> file
exists" などと紹介される場合があります。

GIT
***

Part of the git(1) suite

Name
****

git-patch-id — パッチの一意のIDを計算します

Synopsis
********

     git patch-id [–stable | –unstable]

DESCRIPTION
***********

標準入力からパッチを読み取り、そのパッチIDを計算します。

   「パッチID」は、パッチに関連付けられたファイル差分のSHA-1の合計に過ぎ
ず、空白と行番号は無視されます。そのため、「適度に安定」していますが、同
時に適度に一意です。つまり、同じ「パッチID」を持つ2つのパッチは、ほぼ同
じものであることが保証されています。

   つまり、これを使用して、重複している可能性のあるコミットを探すことが
できます。

   _git diff-tree_ 出力を処理する場合、パッチの前にコミットのオブジェク
ト名が付いているという事実を利用して、2つの40バイトの16進文字列を出力し
ます。最初の文字列はパッチIDで、2番目の文字列はコミットIDです。これを使
用して、パッチIDからコミットIDへのマッピングを作成できます。

OPTIONS
*******

‘--stable’
     パッチIDとして「安定した」ハッシュの合計を使用します。 このオプショ
     ンを使用すると:

        • パッチを構成するファイル差分を並べ替えても、IDには影響しません
          。特に、 "-O<orderfile>" の異なる2つの設定で同じ2つのツリーを
          比較することによって生成された2つのパッチは、同じパッチIDにな
          ります。これにより、計算結果をキーとして使用して、 2本のツリー
          間の変更に関するメタ情報にインデックスを付ける事ができます。

        • 結果として、 "-O<orderfile>" を使用せずに取得されたdiff出力で
          使用された場合でも、 git 1.9 以前で生成された値、または「
          unstable」ハッシュ(以下 ‘--unstable’ を参照)が構成されたときに
          生成された値とは異なります。これにより、そのような「不安定な」
          または過去のパッチIDを格納している既存のデータベースが使用でき
          なくなります。

               patchid.stable が true に設定されている場合は、こちらがデフォルトになります。

‘--unstable’
     パッチIDとして「不安定な」ハッシュを使用します。このオプションを使
     用すると、生成される結果は git1.9 以前で生成される patch-id 値と互
     換性があります。git 1.9 以前で作成されたパッチIDを保存している既存
     のデータベースを使用しているユーザー(並べ替えられたパッチを処理しな
     いユーザー)は、このオプションを使用することをお勧めします。

          ※これがデフォルトです。

GIT
***

Part of the git(1) suite

Name
****

git-prune-packed — すでにパックファイルにある余分なオブジェクトを削除し
ます

Synopsis
********

     git prune-packed [-n|–dry-run] [-q|–quiet]

DESCRIPTION
***********

このプログラムは、 パックファイルに現在存在するすべてのオブジェクトを、
‘$GIT_OBJECT_DIRECTORY’ で検索し、独立したオブジェクトディレクトリでも検
索します。

   余分なオブジェクトはすべて削除されます。

   パックは、個別に圧縮され、デルタ圧縮が適用され、単一のファイルに格納
され、関連付けられたインデックスファイルを持つオブジェクトのコレクション
です。

   パックは、ミラーシステム、バックアップエンジン、ディスクストレージな
どの負荷を軽減するために使用されます。

OPTIONS
*******

‘-n’
‘--dry-run’
     実際にオブジェクトを削除するのではなく、削除されるはずのオブジェク
     トの表示のみを行います。

‘-q’
‘--quiet’
     進行状況インジケーターを黙らせます。

SEE ALSO
********

git-pack-objects(1) git-repack(1)

GIT
***

Part of the git(1) suite

Name
****

git-prune — オブジェクトデータベースで、到達不能なすべてのオブジェクトを
剪定(prune)します

Synopsis
********

     git prune [-n] [-v] [–progress] [–expire <time>] [–] [<head>…]

DESCRIPTION
***********

     *Note*

     ほとんどの場合、ユーザーは _git prune_ を呼び出す _git gc_ を実行す
     る必要があります。 以下の「NOTES」セクションを参照してください。

   これは、 ‘refs/’ で使用可能なすべてのrefを使用して _git fsck
–unreachable_ を実行し、オプションでコマンドラインで指定されたオブジェク
トの追加セットを使用して、オブジェクトデータベースのこれらのヘッドオブジ
ェクトから到達できないすべてのアンパックされたオブジェクトを剪定
(prune)します。さらに、「git prune-packed」を実行することにより、パック
内にも同じモノがあるアンパックされたオブジェクトを剪定します。 また、ど
のrefからも到達できないエントリを .git/shallow から削除(removes)します。

   注意: 到達不能なパックされたオブジェクトが残ることに注意してください
。これが望ましくない場合は、 git-repack(1) を参照してください。

OPTIONS
*******

‘-n’
‘--dry-run’
     何も削除しません。何が削除される予定かを報告するだけです。

‘-v’
‘--verbose’
     削除されたすべてのオブジェクトを報告します。

‘--progress’
     進捗状況を表示します。

‘--expire <time>’
     <time> より古いルーズオブジェクトのみを期限切れにします。

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

<head>…
     我々の任意の参照から到達可能なオブジェクトに加えて、リストされた
     <head>s から到達可能なオブジェクトを保持します。

EXAMPLES
********

リポジトリで使用されていないオブジェクト、またはリポジトリから
‘.git/objects/info/alternates’ を介して借用しているオブジェクトを剪定
(prune)するには:

     $ git prune $(cd ../another && git rev-parse --all)

NOTES
*****

ほとんどの場合、ユーザーは「git prune」を直接呼び出す必要はありませんが
、代わりに「git gc」を呼び出す必要があります。これは、他の多くのハウスキ
ーピングタスクとともに剪定(plune)を処理します。

   剪定(prune)の対象と見なされるオブジェクトの説明については、「git
fsck」の ‘--unreachable’ オプションを参照してください。

SEE ALSO
********

git-fsck(1), git-gc(1), git-reflog(1)

GIT
***

Part of the git(1) suite

Name
****

git-pull — 別のリポジトリまたはローカルブランチから取得して統合する

Synopsis
********

     git pull [<options>] [<repository> [<refspec>…]]

DESCRIPTION
***********

リモートリポジトリからの変更を現在のブランチに組み込みます。 現在のブラ
ンチがリモートの後追いの場合、デフォルトでは、リモートに一致するように現
在のブランチを早送り(fast-forward)します。 現在のブランチとリモートが分
岐している場合、ユーザーは分岐したブランチを ‘--rebase’ または
‘--no-rebase’ (または ‘pull.rebase’ の対応する構成オプション) と調整する
方法を指定する必要があります。

   より正確には、 ‘git pull’ は指定されたパラメーターで ‘git fetch’ を実
行し、構成オプションまたはコマンドラインフラグに応じて、 ‘git rebase’ ま
たは ‘git merge’ を呼び出して、分岐するブランチを調整します。

   <repository> は、 git-fetch(1) に渡されるリモートリポジトリの名前であ
る必要があります。 <refspec>は、任意のリモートref(たとえば、タグの名前
)、または、対応するリモート追跡ブランチを持つrefのコレクション(例:
refs/heads/*:refs/remotes/origin/* )に名前を付けることができますが、通常
はリモートリポジトリ内のブランチの名前です。

   <repository>と<branch>のデフォルト値は、 git-branch(1) の ‘--track’ に
よって設定された現在のブランチの「リモート」および「マージ」構成から読み
取られます。

   次の履歴が存在し、現在のブランチが ‘master’ であると想定します:

               A---B---C master on origin
              /
         D---E---F---G master
             ^
             origin/master in your repository

   次に、 ‘git pull’ は、リモートの ‘master’ ブランチから変更をフェッチ
してリプレイします。これは、ローカルの ‘master’ (つまり、 ‘E’)から分岐し
てから、 ‘master’ 上の現在のコミット(‘C’)までです。 そして、2つの親コミ
ットの名前と変更を説明するユーザーからのログメッセージとともに、結果を新
しいコミットに記録します。

               A---B---C origin/master
              /         \
         D---E---F---G---H master

   競合の表示方法や処理方法などの詳細については、 git-merge(1) を参照し
てください。

   Git 1.7.0 以降では、競合するマージをキャンセルするには、 ‘git reset
--merge’ を使用します。 *警告* :古いバージョンのGitでは、コミットされて
いない変更を加えて ‘git pull’ を実行することはお勧めしません。それは可能
ではありますが、競合が発生した場合に元に戻すのが厳しい状態になります。

   リモートの変更のいずれかがローカルのコミットされていない変更と重複す
る場合、マージは自動的にキャンセルされ、作業ツリーは変更されません。 一
般に、 プルまたは、git-stash(1) を使用してそれらを隠しておく前に、作業対
象のローカルの変更を取得するのが最善です。

OPTIONS
*******

‘-q’
‘--quiet’
     これは、 転送中のレポートを黙らせる為に git-fetch と、マージ中の出
     力を黙らせるために git-merge の、両方に渡されます。

‘-v’
‘--verbose’
     ‘--verbose’ を git-fetch や git-merge に渡します。

‘--[no-]recurse-submodules[=yes|on-demand|no]’
     このオプションは、入力されたサブモジュールの新しいコミットをフェッ
     チする必要があるかどうか、およびアクティブなサブモジュールの作業ツ
     リーも更新する必要があるかどうかを制御します(git-fetch(1) 、
     git-config(1) 、gitmodules(5) を参照)。

     チェックアウトがリベースを介して行われる場合、ローカルサブモジュー
     ルのコミットもリベースされます。

     更新がマージを介して行われる場合、サブモジュールの競合は解決され、
     チェックアウトされます。

Options related to merging
==========================

‘--commit’
‘--no-commit’
     マージを実行し、結果をコミットします。 このオプションは、
     ‘--no-commit’ をオーバーライドするために使用できます。 マージする場
     合にのみ役立ちます。

     ‘--no-commit’ を使用すると、マージを実行し、マージコミットを作成す
     る直前に停止して、ユーザーに、コミットする前にマージ結果を検査し、
     さらに微調整する機会を提供します。

     注意: 早送り(fast-forward)更新はマージコミットを作成しないため、
     ‘--no-commit’ を使用してこれらのマージを停止する方法はないことに注
     意してください。 したがって、mergeコマンドによってブランチが変更ま
     たは更新されないようにする場合は、 ‘--no-ff’ と ‘--no-commit’ を使
     用します。

‘--edit’
‘-e’
‘--no-edit’
     機械的マージがを成功する前にエディターを呼び出して、自動生成された
     マージメッセージをさらに編集し、ユーザーがマージについて説明して正
     当化できるようにします。 ‘--no-edit’ オプションを使用して、自動生成
     されたメッセージを受け入れることができます(これは一般的には推奨され
     ていません)。

     古いスクリプトは、ユーザーがマージログメッセージを編集できないよう
     にするという過去の動作に依存している可能性があります。 そのような場
     合は ‘git merge’ を実行すると、エディターを開く事になります。 この
     ようなスクリプトを簡単に最新の挙動に合わせるために、環境変数
     ‘GIT_MERGE_AUTOEDIT’ をスクリプトの先頭で ‘no’ に設定できます。

‘--cleanup=<mode>’
     このオプションは、コミットする前にマージメッセージをクリーンアップ
     する方法を決定します。 詳細については、 git-commit(1)を参照してくだ
     さい。 加えて、 ‘<mode>’ に ‘scissors’ 値が指定されている場合、マー
     ジの競合が発生した時に、切り取り線(scissors)はコミット機構に渡され
     る前に ‘MERGE_MSG’ に追加されます。

‘--ff-only’
     分岐する(divergent)ローカル履歴がない場合にのみ、新しい履歴に更新し
     ます。 これは、(‘--rebase=*’ フラグを介して)分岐する(divergent)履歴
     を調整する方法が提供されていない場合のデフォルトです。

‘--ff’
‘--no-ff’
     リベースではなくマージする場合、マージされた履歴がすでに現在の履歴
     の子孫である場合に、マージがどのように処理されるかを指定します。 マ
     ージが要求された場合、 ‘refs/tags/’ 階層の自然な場所に格納されてい
     ない注釈付き(および場合によっては署名された)タグをマージしない限り
     、 ‘--ff’ がデフォルトです。マージする場合は ‘--no-ff’ が想定されま
     す。

     ‘--ff’ を使用すると、可能であれば、マージを早送り(fast-forward)(マ
     ージされたブランチに一致するようにブランチポインタを更新するだけで
     す。マージコミットは作成しません)として解決します。 不可能な場合(マ
     ージされた履歴が現在の履歴の子孫ではない場合)は、マージコミットを作
     成します。

     ‘--no-ff’ を使用すると、マージが早送り(fast-forward)として解決でき
     る場合でも、すべての場合にマージコミットを作成します。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     マージコミット結果にGPG署名します。 ‘keyid’ 引数はオプションであり
     、デフォルトでコミッターIDになります。 指定する場合は、スペースなし
     でオプションに串刺しする必要があります。 ‘--no-gpg-sign’ は、
     ‘commit.gpgSign’ 構成変数と、これ以前に指定した ‘--gpg-sign’ の両方
     を打ち消すのに役立ちます。

‘--log[=<n>]’
‘--no-log’
     ブランチ名に加えて、マージされている実際のコミットから最大<n>個のコ
     ミットの1行説明をログメッセージに入力します。 git-fmt-merge-msg(1)
     も参照してください。 マージする場合にのみ役立ちます。

     ‘--no-log’ を使用すると、マージされる実際のコミットからの1行説明が
     一覧表示されません。

‘--signoff’
‘--no-signoff’
     コミットログメッセージの最後に、コミッターによる「Signed-off-by」ト
     レーラーを追加します。signoffの意味は、コミットしているプロジェクト
     によって異なります。たとえば、コミッターがプロジェクトのライセンス
     に基づいて作品を提出する権利を持っていることを証明したり、開発者の
     原産地証明書などの寄稿者の代表に同意したりする場合があります。
     (LinuxカーネルおよびGitプロジェクトで使用されるものについては、
     http：//developercertificate.orgを参照してください)。プロジェクトで
     signoffがどのように使用されるかを理解するには、貢献しているプロジェ
     クトのドキュメントまたはリーダーシップ(leadership)を参照してくださ
     い。

     ‘--no-signoff’ オプションを使用すると、コマンドラインで以前の
     ‘--signoff’ オプションを無効にすることができます。

‘--stat’
‘-n’
‘--no-stat’
     マージの最後にdiffstatを表示します。 diffstatは、構成オプション
     merge.statによっても制御されます。

     ‘-n’ または ‘--no-stat’ を使用すると、マージの最後に diffstat が表
     示されません。

‘--squash’
‘--no-squash’
     (マージ情報を除く)実際のマージが発生したかのように作業ツリーとイン
     デックスの状態を生成しますが、実際にコミットしたり、 ‘HEAD’ を移動
     したり、 (次の ‘git commit’ コマンドでマージコミットを作成する、)
     ‘$GIT_DIR/MERGE_HEAD’ を記録したりしないでください。 これにより、現
     在のブランチの上に単一のコミットを作成できます。その効果は、別のブ
     ランチ(または octopusの場合はそれ以上)をマージするのと同じです。

     ‘--no-squash’ を使用してマージを実行し、結果をコミットします。 この
     オプションは、 ‘--squash’ をオーバーライドするために使用できます。

     ‘--squash’ を使用すると、 ‘--commit’ は許可されず、失敗します。

     マージする場合にのみ役立ちます。

‘--no-verify’
     このオプションは、pre-mergeフックとcommit-msgフックをバイパスします
     。 githooks(5) も参照してください。 マージする場合にのみ役立ちます
     。

‘-s <strategy>’
‘--strategy=<strategy>’
     指定されたマージ戦略を使用します。 試行する順序を指定するために、複
     数回指定できます。 ‘-s’ オプションがない場合は、代わりに組み込みの
     戦略リストが使用されます(単一のヘッドをマージする場合は ‘ort’、それ
     以外の場合は ‘octopus’)。

‘-X <option>’
‘--strategy-option=<option>’
     マージ戦略固有のオプションをマージ戦略に渡します。

‘--verify-signatures’
‘--no-verify-signatures’
     マージされるサイドブランチの先端コミットが有効なキー、つまり有効な
     uidを持つキーで署名されていることを確認します。デフォルトの信頼モデ
     ルでは、これは署名キーが信頼できるキーによって署名されていることを
     意味します。サイドブランチの先端コミットが有効なキーで署名されてい
     ない場合、マージは中止されます。

     マージする場合にのみ役立ちます。

‘--summary’
‘--no-summary’
     ‘--stat’ および ‘--no-stat’ の同義語。 これらは非推奨であり、将来削
     除される予定です。

‘--autostash’
‘--no-autostash’
     操作を開始する前に一時的なスタッシュエントリを自動的に作成し、それ
     を特別なref ‘MERGE_AUTOSTASH’ に記録し、操作の終了後にapplyします。
     これは、ダーティワークツリーで操作を実行できることを意味します。 た
     だし、注意して使用してください。マージが成功した後の最後のstashアプ
     リケーションは、深刻な競合を引き起こす可能性があります。

‘--allow-unrelated-histories’
     デフォルトでは、 ‘git merge’ コマンドは、共通の祖先を共有しない履歴
     のマージを拒否します。 このオプションは、独立して産まれた2つのプロ
     ジェクトの履歴をマージするときにこのセーフティを無効にするために使
     用できます。 これは非常にまれなケースであるため、これをデフォルトで
     有効にする構成変数は存在せず、今後も追加されません。

     マージする場合にのみ役立ちます。

‘-r’
‘--rebase[=false|true|merges|preserve|interactive]’
     trueの場合、フェッチ後に現在のブランチをアップストリームブランチの
     上にリベースします。 アップストリームブランチに対応するリモートトラ
     ッキングブランチがあり、アップストリームブランチが最後にフェッチさ
     れてからリベースされた場合、リベースはその情報を使用して、非ローカ
     ル変更のリベースを回避します。

     ‘merges’ に設定すると、 ‘git rebase --rebase-merges’ を使用してリベ
     ースし、ローカルマージコミットがリベースに含まれるようにします(詳細
     については、 git-rebase(1) を参照してください)。

     ‘preserve’ に設定されている場合(非推奨。 ‘merges’ が優先されます)、
     ローカルで作成されたマージコミットがフラット化されないように
     ‘--preserve-merges’ オプションを ‘git rebase’ に渡してリベースしま
     す。

     falseの場合、アップストリームブランチを現在のブランチにマージします
     。

     ‘interactive’ の場合、リベースの対話モードを有効にします。

     ‘git pull’ がマージする代わりに、常に ‘--rebase’ を使用するようにし
     たいなら、 git-config(1) の ‘pull.rebase’ と ‘branch.<name>.rebase’
     と ‘branch.autoSetupRebase’ を参照してください。

          *Note*

          これは潜在的に「危険」な操作モードです。 それは履歴を塗り替え
          てしまいます。その履歴はすでに公開されているのですから、良くな
          い兆候です。 git-rebase(1) を注意深く読んでいない限り、このオ
          プションを使用しないでください。

‘--no-rebase’
     これは ‘--rebase=false’ の省略形です。

Options related to fetching
===========================

‘--all’
     すべてのリモートをフェッチします。

‘-a’
‘--append’
     フェッチされた参照の参照名とオブジェクト名を ‘.git/FETCH_HEAD’ の既
     存のコンテンツに追加します。 このオプションがないと、
     ‘.git/FETCH_HEAD’ の古いデータが上書きされます。

‘--atomic’
     アトミックトランザクションを使用して、ローカル参照を更新します。 す
     べての参照が更新されるか、あるいは、エラーが発生してすべての参照が
     新されないか、のいずれかです。

‘--depth=<depth>’
     各リモートブランチ履歴の先端からの指定されたコミット数にフェッチを
     制限します。 ‘--depth=<depth>’ オプションを指定して ‘git clone’ に
     よって作成された浅いリポジトリ(shallow repository)からフェッチする
     場合(git-clone(1) 参照)、指定されたコミット数まで履歴を深くするか浅
     くするかします。

‘--deepen=<depth>’
     ‘--depth’ に似ていますが、各リモートブランチ履歴の先端からではなく
     、現在の浅い境界(shallow boundary)からのコミット数を指定する点が異
     なります。

‘--shallow-since=<date>’
     浅い(shallow)リポジトリの履歴を深くしたり浅くしたりして、<date>以降
     の到達可能なすべてのコミットを含めます。

‘--shallow-exclude=<revision>’
     浅いリ(shallow)ポジトリの履歴を深くするか浅くするかして、指定された
     リモートブランチまたはタグから到達可能なコミットを除外します。 この
     オプションは複数回指定できます。

‘--unshallow’
     ソースリポジトリが完全な場合は、浅いリ(shallow)ポジトリを完全なリポ
     ジトリに変換し、浅い(shallow)リポジトリによって課せられるすべての制
     限を取り除きます。

     ソースリポジトリが浅い(shallow)場合は、現在のリポジトリがソースリポ
     ジトリと同じ履歴を持つように、可能な限りフェッチします。

‘--update-shallow’
     デフォルトでは、浅い(shallow)リポジトリからフェッチする場合、 ‘git
     fetch’ は ‘.git/shallow’ の更新が必要なrefを拒否します。 このオプシ
     ョンは ‘.git/should’ を更新し、そのようなrefを受け入れます。

‘--negotiation-tip=<commit|glob>’
     デフォルトでは、Gitは、受信するパックファイルのサイズを縮小するため
     に、すべてのローカルrefから到達可能なコミットをサーバーに報告して、
     共通のコミットを見つけます。 指定した場合、Gitは指定された先端から
     到達可能なコミットのみを報告します。 これは、フェッチされるアップス
     トリームrefと共通のコミットを持つ可能性のあるローカルrefがユーザー
     にわかっている場合に、フェッチを高速化するのに役立ちます。

     このオプションは複数回指定できます。 その場合、Gitは指定されたコミ
     ットのいずれかから到達可能なコミットを報告します。

     このオプションの引数は、ref名またはrefまたはコミットの(おそらく省略
     された)SHA-1のグロブである可能性があります。グロブを指定することは
     、一致するref名ごとに1つずつ、このオプションを複数回指定することと
     同じです。

     git-config(1) に記載されている ‘fetch.negotiationAlgorithm’ と
     ‘push.negotiate’ 構成変数、および、以下の ‘--negotiate-only’ オプシ
     ョンも参照してください。

‘--negotiate-only’
     サーバーから何もフェッチせず、代わりに、サーバーと共通している、提
     供された ‘--negotiation-tip=*’ 引数の祖先を出力します。

     内部的には、これは ‘push.negotiate’ オプションを実装するために使用
     されます。 git-config(1) を参照してください。

‘--dry-run’
     変更を加えずに、何が行われるかを示します。

‘-f’
‘--force’
     ‘git fetch’ を ‘<src>:<dst>’ refspecと一緒に使用すると、既に説明し
     たようにローカルブランチの更新を拒否する場合があります git-fetch(1)
     ドキュメントの ‘<refspec>’ の部分にあります。 このオプションは、そ
     のチェックをオーバーライドします。

‘-k’
‘--keep’
     ダウンロードしたパックを保持してください。

‘--prefetch’
     構成されたrefspecを変更して、すべてのrefを ‘refs/prefetch/’ 名前空
     間に配置します。 git-maintenance(1)の ‘prefetch’ タスクを参照してく
     ださい。

‘-p’
‘--prune’
     フェッチする前に、リモートに存在しなくなったリモート追跡参照を削除
     します。 タグは、デフォルトのタグの自動追跡または ‘--tags’ オプショ
     ンのためにのみフェッチされた場合(コマンドラインまたはリモート構成の
     いずれかで、たとえば、リモートが ‘--mirror’ オプションでcloneされた
     場合)、刈り込み(pruning)の対象にはなりません。 ただし、明示的な
     refspecが原因でタグがフェッチされた場合、それらも刈り込み
     (pruning)の対象になります。 ‘--prune-tags’ を指定することは、タグ
     refspecを提供するための省略形です。

‘--no-tags’
     デフォルトでは、リモートリポジトリからダウンロードされたオブジェク
     トを指すタグがフェッチされ、ローカルに保存されます。このオプション
     は、この自動タグ追跡を無効にします。 リモートのデフォルトの動作は、
     ‘remote.<name>.tagOpt’ 設定で指定できます。 git-config(1) を参照し
     てください。

‘--refmap=<refspec>’
     コマンドラインにリストされているrefをフェッチするときは、リモートリ
     ポジトリの ‘remote.*.fetch’ 構成変数の値の代わりに、指定された
     refspec(複数回指定可能)を使用してrefをリモート追跡ブランチにマップ
     します。 空の ‘<refspec>’ を ‘--refmap’ オプションに指定すると、
     Gitは構成されたrefspecsを無視し、コマンドライン引数として提供された
     refspecsに完全に依存します。 詳細については、「Configured
     Remote-tracking Branches」のセクションを参照してください。

‘-t’
‘--tags’
     他の方法でフェッチされるものに加えて、リモートからすべてのタグをフ
     ェッチします(つまり、リモートタグ ‘refs/tags/*’ を同じ名前のローカ
     ルタグにフェッチします)。 このオプションを単独で使用しても、
     ‘--prune’ が使用されている場合でも、タグは刈り込み(pruning)の対象に
     はなりません(ただし、タグが明示的なrefspecの宛先でもある場合は、タ
     グは刈り込み(pruning)される可能性があります。 ‘--prune’ を参照して
     ください)。

‘-j’
‘--jobs=<n>’
     すべての形式のフェッチに使用されるparallel childrenの数。

     ‘--multiple’ オプションが指定された場合、異なるリモートが並行してフ
     ェッチされます。 複数のサブモジュールがフェッチされる場合、それらは
     並行してフェッチされます。 それらを個別に制御するには、構成設定
     ‘fetch.parallel’ と ‘submodule.fetchJobs’ を使用します
     (git-config(1) 参照)。

     通常、並列再帰フェッチとマルチリモートフェッチの方が高速です。デフ
     ォルトでは、フェッチは並列ではなく順次実行されます。

‘--set-upstream’
     リモートが正常にフェッチされた場合は、引数のない git-pull(1) および
     その他のコマンドで使用されるアップストリーム(追跡)参照を追加します
     。 詳細については、 git-config(1) の ‘branch.<name>.merge’ および
     ‘branch.<name>.remote’ を参照してください。

‘--upload-pack <upload-pack>’
     指定され、フェッチ元のリポジトリが ‘git fetch-pack’ によって処理さ
     れると、 ‘--exec=<upload-pack>’ がコマンドに渡され、もう一方の端で
     実行されるコマンドのデフォルト以外のパスが指定されます。

‘--progress’
     ‘-q’ が指定されていない限り、進行状況は、端末に接続されている場合、
     デフォルトで標準エラーストリームに報告されます。 このフラグは、標準
     エラーストリームが端末に送信されていない場合でも、進行状況を強制し
     ます。

‘-o <option>’
‘--server-option=<option>’
     プロトコルバージョン2を使用して通信する場合は、指定された文字列をサ
     ーバーに送信します。 指定された文字列には、NUL文字またはLF文字を含
     めることはできません。 不明なオプションを含むサーバーオプションのサ
     ーバー処理は、サーバー固有です。 複数の ‘--server-option=<option>’
     が指定されている場合、それらはすべてコマンドラインにリストされてい
     る順序で相手側に送信されます。

‘--show-forced-updates’
     デフォルトでは、gitはフェッチ中にブランチが強制的に更新されるかどう
     かをチェックします。 これは ‘fetch.showForcedUpdates’ を介して無効
     にすることができますが、 ‘--show-forced-updates’ オプションはこのチ
     ェックが行われることを保証します。 git-config(1) を参照してください
     。

‘--no-show-forced-updates’
     デフォルトでは、gitはフェッチ中にブランチが強制的に更新されるかどう
     かをチェックします。 ‘--no-show-forced-updates’ を渡すか、
     ‘fetch.showForcedUpdates’ を ‘false’ に設定して、パフォーマンス上の
     理由からこのチェックをスキップします。 ‘git-pull’ 処理中に使用され
     た場合、 ‘--ff-only’ オプションは、早送り(fast-forward)更新を試行す
     る前に、強制更新をチェックします。 git-config(1) を参照してください
     。

‘-4’
‘--ipv4’
     IPv6アドレスを無視して、IPv4アドレスのみを使用します。

‘-6’
‘--ipv6’
     IPv4アドレスを無視して、IPv6アドレスのみを使用します。

<repository>
     フェッチまたはプル操作のソースである「リモート」リポジトリ。このパ
     ラメーターは、URL(以下の GIT URLS セクションを参照)またはリモートの
     名前(以下の REMOTES セクションを参照)のいずれかです。

<refspec>
     フェッチするrefと更新するローカルrefを指定します。コマンドラインに
     <refspec> がない場合、フェッチするrefは代わりに
     ‘remote.<repository>.fetch’ 変数から読み取られます。 (git-fetch(1)
     の 「CONFIGURED REMOTE-TRACKING BRANCHES」セクション参照)

     <refspec> パラメータの組織は、オプションのプラス ‘+’ に続いて ソー
     スの <src> 、コロン ‘:’ 宛先refの <dst> の順です。 <dst> が空の場合
     、コロン(‘:’)は省略できます。 <src> は通常、refですが、フルスペルの
     16進オブジェクト名にすることもできます。

     <refspec> の <src> には、単純なパターン一致を示すための ‘*’ が含ま
     れている場合があります。このようなrefspecは、同じプレフィックスを持
     つ任意のrefに一致するglobのように機能します。パターン<refspec>では
     、 <src> と <dst> の両方に ‘*’ が含まれている必要があります。 ‘*’ を
     ソースから一致したコンテンツに置き換えることにより、refを宛先にマッ
     ピングします。

     refspecの前に ‘^’ が付いている場合、それはネガティブのrefspecとして
     解釈されます。このようなrefspecは、フェッチするrefや更新するローカ
     ルrefを指定するのではなく、除外するrefを指定します。 refは、少なく
     とも1つのポジティブ(通常)のrefspecと一致し、ネガティブのrefspecと一
     致しない場合、一致すると見なされます。ネガティブのrefspecは、特定の
     refが含まれないように、パターンrefspecのスコープを制限するのに役立
     ちます。ネガティブのrefspecは、それ自体がパターンrefspecである可能
     性があります。 ただし、 <src> のみを含めることができ、 <dst> を指定
     することはできません。 フルスペルの16進オブジェクト名もサポートされ
     ていません。

     ‘tag <tag>’ は、 ‘refs/tags/<tag>:refs/tags/<tag>’ と同じ意味です。
     指定されたタグまでのすべてをフェッチするように要求します。

     <src> に一致するリモートrefがフェッチされ、 <dst> が空の文字列でな
     い場合は、それに一致するローカルrefを更新しようとします。

     その更新が ‘--force’ なしで許可されるかどうかは、フェッチ先のref名
     前空間、フェッチされるオブジェクトのタイプ、および更新が
     fast-forwardであると見なされるかどうかによって異なります。一般に、
     プッシュする場合と同じルールがフェッチに適用されます。それらが何で
     あるかについては、 git-push(1)の ‘<refspec>...’ セクションを参照し
     てください。 _git fetch_ に固有の例外ルールを以下に示します。

     Gitバージョン2.20までは、 git-push(1) でプッシュする場合とは異なり
     、 ‘refs/tags/*’ の更新は、 refspec に ‘+’ がなくても(または
     ‘--force’ 指定が無くても)受け入れられます。フェッチするとき、リモー
     トからのすべてのタグ更新を強制フェッチとしていました。Gitバージョン
     2.20以降では、 ‘refs/tags/*’ を更新するためのフェッチは、プッシュす
     る場合と同じように機能します。 つまり refspecに ‘+’ が無い場合(また
     は ‘--force’ が無い場合)、更新は拒否されます。

     git-push(1) でプッシュするときとは異なり、 ‘refs/{tags,heads}/*’ 以
     外の更新は、 refspecに ‘+’ がなくても(あるいは ‘--force’ 指定が無く
     ても)受け付けられます。例えば、ツリーオブジェクトとブロブを交換した
     り、あるコミットを、祖先を持たない別のコミットと交換したりできます
     。

     git-push(1) でプッシュする場合とは異なり、これらのルールを修正する
     構成はなく、 ‘pre-receive’ フックに類似した ‘pre-fetch’ フックのよ
     うなものはありません。

     git-push(1) を使用したプッシュと同様に、更新として許可されないもの
     に関する上記のすべてのルールは、refspec先頭にオプションで ‘+’ をに
     追加する(または ‘--force’ コマンドラインオプションを使用する)ことで
     オーバーライドできます。これに対する唯一の例外は、 ‘refs/heads/*’ 名
     前空間が非コミットオブジェクトを受け入れるように強制することはない
     ということです。

          *Note*

          フェッチするリモートブランチが定期的に巻き戻されてリベースされ
          ることがわかっている場合、その新しい先端は(最後にフェッチした
          ときにリモートトラッキングブランチに保存された)以前の先端の子
          孫ではないことが予想されます。あなたは ‘+’ 記号を使用して、そ
          のようなブランチにnon-fast-forwardの更新が必要であることを指示
          します。この操作でブランチがリポジトリで使用可能になることを決
          定または宣言する方法はありません。プルするユーザーは、これがブ
          ランチの予想される使用パターンであることを知っている必要があり
          ます。

          *Note*

          _git pull_ コマンドラインに直接複数の <refspec> をリストするこ
          とと、 <repository> の構成に複数の ‘remote.<repository>.fetch’
          エントリを含めることと、明示的な <refspec> パラメーターなしで
          _git pull_ コマンドを実行することには違いがあります。コマンド
          ラインに明示的にリストされている <refspec> は、フェッチ後に常
          に現在のブランチにマージされます。いいかえると、複数のリモート
          refをリストする場合 ‘git pull’ はOctopusマージを作成します。一
          方、コマンドラインに明示的な <refspec> パラメータをリストしな
          い場合 _git pull_ は ‘remote.<repository>.fetch’ 構成で見つか
          ったすべての <refspec> をフェッチし、最初に見つかった
          <refspec> のみを現在のブランチにマージします。これはリモート
          refからOctopusを作成することはめったに行われない為ですが、複数
          のリモートヘッドを追跡するために複数のリモートヘッドを一度にフ
          ェッチすると便利なことがよくあります。

GIT URLS
********

一般に、URLには、トランスポートプロトコル、リモートサーバーのアドレス、
およびリポジトリへのパスに関する情報が含まれています。トランスポートプロ
トコルによっては、一部の情報が欠落している場合があります。

   Gitはsshとgitとhttpとhttpsプロトコルをサポートします(さらにftpと
ftpsをフェッチに使用できますが、これは非効率的で非推奨です。使用しないで
ください)。

   ネイティブトランスポート(つまり、 git:// URL)は認証を行わないため、セ
キュリティで保護されていないネットワークでは注意して使用する必要がありま
す。

   以下の構文を使用できます:

   • ssh://[user@]host.xz[:port]/path/to/repo.git/

   • git://host.xz[:port]/path/to/repo.git/

   • http[s]://host.xz[:port]/path/to/repo.git/

   • ftp[s]://host.xz[:port]/path/to/repo.git/

   代替のscpのような構文をsshプロトコルで使用することもできます:

   • [user@]host.xz:path/to/repo.git/

   この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されま
す。これは、コロンを含むローカルパスを区別するのに役立ちます。たとえば、
ローカルパス ‘foo:bar’ を、絶対パスまたは ‘./foo:bar’ として指定して、
ssh url として誤って解釈されないようにすることができます。

   sshおよびgitプロトコルは、さらに ~username 拡張をサポートします:

   • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

   • git://host.xz[:port]/~[user]/path/to/repo.git/

   • [user@]host.xz:/~[user]/path/to/repo.git/

   Gitでもネイティブにサポートされているローカルリポジトリの場合、以下の
構文を使用できます:

   • /path/to/repo.git/

   • file:///path/to/repo.git/

   これらの2つの構文は、前者が ‘--local’ オプションの機能を含むクローン
作成の場合を除いて、ほとんど同等です。 詳細については、 git-clone(1) を
参照してください。

   「git clone」と「git fetch」と「git pull」は、「git push」と違って適
切なバンドルファイルを受け入れます。 git-bundle(1) を参照してください。

   Gitが特定のトランスポートプロトコルを処理する方法を知らない場合、
Gitは _remote-<transport>_ リモートヘルパー(存在する場合)を使用しようと
します。リモートヘルパーを明示的に要求するには、以下の構文を使用できます
:

   • <transport>::<address>

   ここで、 <address> は、パス、サーバーとパス、または呼び出されている特
定のリモートヘルパーによって認識される任意のURLのような文字列です。詳細
については、 gitremote-helpers(7) を参照してください。

   同じ名前のリモートリポジトリが多数あり、それらに異なる形式を使用する
場合(あなたの使用するURLが機能するURLに書き換えられるように)、以下の形式
の構成セクションを作成できます:

             [url "<actual url base>"]
                     insteadOf = <other url base>

   例えば、以下のようになります:

             [url "git://git.host.xz/"]
                     insteadOf = host.xz:/path/to/
                     insteadOf = work:

   "work:repo.git" や "host.xz:/path/to/repo.git" のようなURLは、任意の
コンテキストで、"git://git.host.xz/repo.git" に書き換えられます。

   プッシュ専用のURLを書き換えたい場合は、以下の形式の構成セクションを作
成できます:

             [url "<actual url base>"]
                     pushInsteadOf = <other url base>

   例えば、以下のようになります:

             [url "ssh://example.org/"]
                     pushInsteadOf = git://example.org/

   "git://example.org/path/to/repo.git" のようなURLは、プッシュの場合は
"ssh://example.org/path/to/repo.git" に書き換えられますが、プルは引き続
き元のURLのままです。

REMOTES
*******

‘<repository>’ 引数として、URLの代わりに以下のいずれかの名前を使用できま
す:

   • Git構成ファイル(configuration file)内のリモート(remote)として、
     ‘$GIT_DIR/config’ または

   • ‘$GIT_DIR/remotes’ ディレクトリ内のファイル または

   • ‘$GIT_DIR/branches’ ディレクトリ内のファイル

   これらはすべて、gitがデフォルトで使用するrefspecをそれぞれ含んでいる
ため、コマンドラインからrefspecを省略できます。

Named remote in configuration file
==================================

あなたは、 git-remote(1) を使うか、または git-config(1) を使うか、または
‘$GIT_DIR/config’ ファイルを手動で編集して、これ以前に構成したリモートの
名前から選択できます。このリモートのURLは、リポジトリへのアクセスに使用
されます。コマンドラインでrefspecを指定しない場合、このリモートの
refspecがデフォルトで使用されます。構成ファイルのエントリは以下のように
なります:

             [remote "<name>"]
                     url = <url>
                     pushurl = <pushurl>
                     push = <refspec>
                     fetch = <refspec>

   ‘<pushurl>’ はプッシュにのみ使用されます。 これはオプションであり、デ
フォルトは ‘<url>’ です。

Named file in $GIT_DIR/remotes
==============================

あなたは、 ‘$GIT_DIR/remotes’ でファイル名を指定できます。このファイルの
URLは、リポジトリへのアクセスに使用されます。コマンドラインでrefspecを指
定しない場合、このファイルのrefspecがデフォルトとして使用されます。この
ファイルの形式は以下のとおりです:

             URL: one of the above URL format
             Push: <refspec>
             Pull: <refspec>

   ‘Push:’ 行は ‘git push’ で使用され、 ‘Pull:’ 行は ‘git pull’ と ‘git
fetch’ で使用されます。追加のブランチマッピングのために、複数の ‘Push:’
および ‘Pull:’ 行を指定できます。

Named file in $GIT_DIR/branches
===============================

‘$GIT_DIR/branches’ でファイル名を指定できます。このファイルのURLは、リ
ポジトリへのアクセスに使用されます。 このファイルの形式は以下のとおりで
す:

             <url>#<head>

   ‘<url>’ は必須です。 ‘#<head>’ はオプションです。

   コマンドラインで指定しない場合、操作に応じて、gitは以下のrefspecのい
ずれかを使用します。 ‘<branch>’ は ‘$GIT_DIR/branchs’ 内のこのファイルの
名前であり、 ‘<head>`はデフォルトで `master’ になります。

   git fetch は以下を使用します:

             refs/heads/<head>:refs/heads/<branch>

   git push は以下を使用します:

             HEAD:refs/heads/<head>

MERGE STRATEGIES
****************

マージ機構(‘git merge’ と ‘git pull’ コマンド)では、バックエンドの「マー
ジ戦略」を ‘-s’ オプションで選択することができます。 いくつかの戦略では
、独自のオプションを指定することができます。これは、 ‘git merge’ や ‘git
pull’ に ‘-X<option>’ 引数として渡すことができます。

ort
     これは、1つのブランチをプルまたはマージするときのデフォルトのマージ
     戦略です。この戦略では、3方向マージアルゴリズムを使用して2つのヘッ
     ドのみを解決できます。3方向マージに使用できる共通の祖先が複数ある場
     合は、共通の祖先のマージされたツリーを作成し、それを3方向のマージの
     参照ツリーとして使用します。これにより、Linux 2.6カーネルの開発履歴
     から取得した実際のマージコミットで実行されたテストによって、誤った
     マージを引き起こすことなく、マージの競合が少なくなることが報告され
     ています。さらに、この戦略では、名前の変更を伴うマージを検出して処
     理できます。検出されたコピーは使用しません。このアルゴリズムの名前
     は "Ostensibly Recursive’s Twin" (表面上は再帰の双子)の頭文字を取っ
     たものであり、以前のデフォルトのアルゴリズムである「recursive」の代
     わりとして作成されたという事実に由来しています。

     ‘ort’ 戦略は、以下のオプションを取ることができます:

     ours
          このオプションは、「our」バージョンを優先することにより、競合
          するハンクをクリーンに自動解決するように強制します。 our側と競
          合しない他のツリーからの変更は、マージ結果に反映されます。 バ
          イナリファイルの場合、内容全体がour側から取得されます。

          これを「ours」マージ戦略と混同しないでください。この戦略では、
          他のツリーに何が含まれているのかさえまったく調べません。それは
          他のツリーが行ったすべてを破棄し、「our」履歴にはその中で起こ
          ったすべてが含まれていると宣言します。

     theirs
          これは「ours」の反対です。 「ours」とは異なり、このmergeオプシ
          ョンを混同する「theirs」マージ戦略はないことに注意してください
          。

     ignore-space-change
     ignore-all-space
     ignore-space-at-eol
     ignore-cr-at-eol
          指示されたタイプの空白(whitespace)の変更を含む行を、3方向マー
          ジのために変更されていないものとして扱います。行に対する、他の
          変更と空白(whitespace)の変更との混合は、無視されません。
          git-diff(1) の ‘-b’ と ‘-w’ と ‘--ignore-space-at-eol’ と
          ‘--ignore-cr-at-eol’ も参照してください。

             • 「their」バージョンが行に空白の変更のみを導入する場合、「
               our」バージョンが使用されます。

             • 「our」バージョンで空白の変更が導入されたが、「their」バ
               ージョンに大幅な変更が含まれている場合は、「their」バージ
               ョンが使用されます。

             • それ以外の場合、マージは通常の方法で進行します。

     renormalize
          これにより、3方向マージを解決するときに、ファイルの3つのステー
          ジすべての仮想チェックアウトとチェックインが実行されます。この
          オプションは、ブランチをさまざまなクリーンフィルターまたは行末
          正規化ルールとマージするときに使用することを目的としています。
          詳細については、 gitattributes(5) の「Merging branches with
          differing checkin/checkout attributes」(チェックイン/チェック
          アウト属性が異なるブランチのマージ)を参照してください。

     no-renormalize
          ‘renormalize’ オプションを無効にします。 これは、
          ‘merge.renormalize’ 構成変数をオーバーライドします。

     find-renames[=<n>]
          名前変更(rename)の検出をオンにし、オプションで類似性のしきい値
          (similarity threshold)を設定します。これがデフォルトです。 こ
          れは、 ‘merge.renames’ 構成変数をオーバーライドします。
          git-diff(1) の ‘--find-renames’ も参照してください。

     rename-threshold=<n>
          ‘find-renames=<n>’ の非推奨の同義語。

     subtree[=<path>]
          このオプションは「subtree」戦略をさらに発展させたもので、2つの
          木をマージする際に、どのようにずらせば互いにマッチするかを推測
          するものである。その代わり、指定されたパスは、2つの木の形が一
          致するように前置される(または、最初から取り除かれる)。

recursive
     これは、3方向マージアルゴリズムを使用して2つのヘッドのみを解決でき
     ます。3方向マージに使用できる共通の祖先が複数ある場合は、共通の祖先
     のマージされたツリーを作成し、それを3方向のマージの参照ツリーとして
     使用します。 これにより、Linux 2.6カーネルの開発履歴から取得した実
     際のマージコミットで実行されたテストによって、誤ったマージを引き起
     こすことなく、マージの競合が少なくなることが報告されています。 さら
     に、これにより、名前変更を含むマージを検出して処理できます。 検出さ
     れたコピーは使用しません。 これは、Git v0.99.9k 〜 v2.33.0 まで、
     2つのヘッドを解決するためのデフォルトの戦略でした。

     「recursive」(再帰的)戦略は「ort」と同じオプションを取る。 しかし、
     「ort」が無視する3つのオプション(上記には書かれていない)があり、 「
     recursive」戦略で有用となる可能性がある:

     patience
          ‘diff-algorithm=patience’ の非推奨の同義語。

     diff-algorithm=[patience|minimal|histogram|myers]
          マージ中に別の差分アルゴリズムを使用すると、重要でない一致行
          (異なる関数の中括弧など)が原因で発生するミスマージを回避できま
          す。 git-diff(1) ‘--diff-algorithm’ も参照してください。注意:
          特に、「ort」は ‘diff-algorithm=histogram’ を使用しますが、「
          recursive」はデフォルトで 「diff.algorithm」 設定を使う事に注
          意して下さい。

     no-renames
          名前変更(rename)の検出をオフにします。 これは、‘merge.renames’
          構成変数をオーバーライドします。 git-diff(1) の ‘--no-renames’
          も参照してください。

resolve
     これは、3方向マージアルゴリズムを使用して、2つのヘッド（つまり、現
     在のブランチとプルした別のブランチ）のみを解決できます。 交差マージ
     (criss-cross merge)のあいまいさを注意深く検出しようとします。 名前
     の変更は処理しません。

octopus
     これにより、3つ以上のヘッドを持つケースが解決されますが、手動解決が
     必要な複雑なマージの実行は拒否されます。これは主に、トピックの分岐
     ヘッドを纏めるために使用されることを意図しています。これは、複数の
     ブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

ours
     これにより、任意の数のヘッドが解決されますが、結果として得られるマ
     ージのツリーは常に現在のブランチヘッドのツリーであり、他のすべての
     ブランチからのすべての変更を事実上無視します。 これは、サイドブラン
     チの古い開発履歴に取って代わるために使用されることを意図しています
     。 これは、「recursive」マージ戦略の ‘-Xours’ オプションとは異なる
     ことに注意してください。

subtree
     これは改造された「ort」戦略です。 ツリーAとBをマージするとき、Bが
     Aのサブツリーに対応する場合、同じレベルのツリーを読み取るのではなく
     、Bは最初にAのツリー構造に一致するように調整されます。 この調整は、
     共通の祖先ツリーに対しても行われます。

   3方向マージ(デフォルトの「ort」を含む)を使用する戦略では、両方のブラ
ンチで変更が行われたが、後で一方のブランチで元に戻された場合、その変更は
マージされた結果に表示されます。一部の人々は、この振る舞いを混乱させると
感じています。これは、個々のコミットではなく、ヘッドとマージベースのみが
マージの実行時に考慮されるために発生します。したがって、マージアルゴリズ
ムは、元に戻された変更をまったく変更なしと見なし、代わりに変更されたバー
ジョンに置き換えます。

DEFAULT BEHAVIOUR
*****************

‘git pull’ は多くの場合パラメータを指定せずに使われます。伝統的にこれは
‘git pull origin’ と言うのと同じです。 ただし、ブランチ ‘<name>’ に設定
‘branch.<name>.remote’ が存在する場合は、 ‘origin’ の代わりにその値が使
用されます。

   フェッチに使用するURLを決定するために、構成 ‘remote.<origin>.url’ の
値が参照され、そのような変数がない場合は、 ‘$GIT_DIR/remotes/<origin>’ の
‘URL:’ 行の値が使用されます。

   コマンドラインにrefspecパラメーターを指定せずにコマンドを実行したとき
にフェッチする(およびオプションでリモート追跡ブランチに格納する)リモート
ブランチを決定するには、構成変数 ‘remote.<origin>.fetch’ の値を参照しま
す。 構成変数 ‘remote.<origin>.fetch’ が存在しない場合は、
‘$GIT_DIR/remotes/<origin>’ が参照され、その ‘Pull:’ 行が使用されます。
「OPTIONS」セクションで説明されているrefspec形式に加えて、以下のような
refspecグロブを作成できます:

     refs/heads/*:refs/remotes/origin/*

   グロブのrefspecには空でないRHSが必要であり(つまり、リモート追跡ブラン
チでフェッチされたものを格納する必要があります)、そのLHSとRHSは ‘/*’ で
終わる必要があります。 上記では、すべてのリモートブランチが、同じ名前の
‘refs/remotes/origin/’ 階層のリモート追跡ブランチを使用して追跡されるこ
とを指定しています。

   下位互換性を損なわないために、フェッチ後にマージするリモートブランチ
を決定するルールは少し複雑です。

   ‘git pull’ のコマンドラインで明示的なrefspecが指定されている場合、そ
れらはすべてマージされます。

   コマンドラインでrefspecが指定されていない場合、 ‘git pull’ は 構成 ま
たは ‘$GIT_DIR/remotes/<origin>’ からのrefspecを使用します。このような場
合、以下のルールが適用されます:

  1. 現在のブランチ ‘<name>’ の ‘branch.<name>.merge’ 構成が存在する場合
     、それはマージされるリモートサイトのブランチの名前です。

  2. refspecがグロブのものである場合、何もマージされません。

  3. それ以外の場合は、最初のrefspecのリモートブランチがマージされます。

EXAMPLES
********

   • クローンを作成したリポジトリのリモート追跡ブランチを更新し、そのう
     ちの1つを現在のブランチにマージします:

          $ git pull
          $ git pull origin

     通常、マージされるブランチはリモートリポジトリのHEADですが、選択は
     branch.<name>.remote および branch.<name>.merge オプションによって
     決定されます。 詳細については、 git-config(1) を参照してください。

   • 現在のブランチにリモートブランチ ‘next’ をマージします:

          $ git pull origin next

     これにより、 ‘next’ のコピーが一時的にFETCH_HEADに残され、リモート
     追跡ブランチの ‘origin/next’ が更新されます。 フェッチとマージを呼
     び出すことで同じことができます:

          $ git fetch origin
          $ git merge origin/next

   あなたがプルを試みた結果、複雑な競合が発生し、最初からやり直したい場
合は、 ‘git reset’ で回復できます。

SECURITY
********

フェッチおよびプッシュプロトコルは、共有することを意図していない一方の側
が他方のリポジトリからデータを盗むのを防ぐようには設計されていません。悪
意のある者から保護する必要のあるプライベートデータがある場合、最善のオプ
ションはそれを別のリポジトリに保存することです。これは、クライアントとサ
ーバーの両方に適用されます。特に、サーバー上の名前空間は、読み取りアクセ
ス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼
できるクライアントにのみ、名前空間への読み取りアクセスを許可する必要があ
ります。

   既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は、明示的に共有することを意図していないオブジェクトのIDをア
     ドバタイズする "have" 行を送信しますが、他にもIDを持っている者が居
     る場合は、転送を最適化するために使用できます。攻撃者はオブジェクト
     ID Xを選択して盗み、refをXに送信しますが、被害者はすでにXのコンテン
     ツを持っているため、Xのコンテンツを送信する必要はありません。 これ
     で、被害者は攻撃者がXを持っていると信じ、Xのコンテンツを後で攻撃者
     に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間
     にXへのrefを作成してフェッチすることにより、クライアントがサーバー
     上で実行するのが最も簡単です。サーバーがクライアント上で実行する最
     も可能性の高い方法は、Xをパブリックブランチにマージし、ユーザーがこ
     のブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュ
     バックすることを期待します。)

  2. #1 と同様に、攻撃者は盗むオブジェクトID Xを選択します。被害者は、攻
     撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持
     っていると誤って主張するため、被害者はYをXに対するデルタとして送信
     します。デルタは、攻撃者にYに類似したXの領域を明らかにします。

BUGS
****

‘--recurse-submodules’ を使用すると、現在、すでにチェックアウトされてい
るサブモジュールでのみ新しいコミットをフェッチできます。 例えば、スーパ
ープロジェクトのフェッチされたばかりのコミットにアップストリームが新しい
サブモジュールを追加すると、サブモジュール自体をフェッチできなくなり、後
で再度フェッチを実行せずにそのサブモジュールをチェックアウトすることがで
きなくなります。 これは、将来のGitバージョンで修正される予定です。

SEE ALSO
********

git-fetch(1), git-merge(1), git-config(1)

GIT
***

Part of the git(1) suite

Name
****

git-push — 関連するオブジェクトとともにリモートrefを更新します

Synopsis
********

     git push [–all | –mirror | –tags] [–follow-tags] [–atomic] [-n | –dry-run] [–receive-pack=<git-receive-pack>]
                [–repo=<repository>] [-f | –force] [-d | –delete] [–prune] [-v | –verbose]
                [-u | –set-upstream] [-o <string> | –push-option=<string>]
                [–[no-]signed|–signed=(true|false|if-asked)]
                [–force-with-lease[=<refname>[:<expect>]] [–force-if-includes]]
                [–no-verify] [<repository> [<refspec>…]]

DESCRIPTION
***********

指定のrefを完全にするために必要なオブジェクトを送信により、ローカルrefを
使用してリモートrefを更新します。

   リポジトリに「フック」を設定することで、あなたがリポジトリにプッシュ
するたびに興味深いことが起こります。 git-receive-pack(1) のドキュメント
を参照してください。

   コマンドラインで ‘<repository>’ 引数を使用してプッシュする場所が指定
されてい無い場合、現在のブランチの ‘branch.*.remote’ 構成を参照して、プ
ッシュする場所を決定します。 ‘branch.*.remote’ 構成が無い場合、デフォル
トは ‘origin’ になります。

   コマンドラインで ‘<refspec>...’ 引数や ‘--all’, ‘--mirror’, ‘--tags’
オプションを使って何をプッシュするか指定し無かった場合、コマンドは
‘remote.*.push’ 構成を参照してデフォルトの ‘<refspec>’ を探し、それで見
つからなかった場合は ‘push.default’ 構成に準拠して何をプッシュするか決定
します(‘push.default’ の意味は git-config(1) を参照ください)。

   コマンドラインと構成のどちらもプッシュする対象を指定しない場合、デフ
ォルトの振る舞いが使用されます。それは、 ‘push.default’ の ‘simple’ 値に
対応します。 現在のブランチは対応する上流ブランチにプッシュされますが、
安全対策として、上流ブランチがローカルブランチと同じ名前でない場合はプッ
シュが中断(abort)されます。

OPTIONS
*******

<repository>
     「リモート」(remote)リポジトリはプッシュ操作の宛先です。 このパラメ
     ーターは、URL(下記セクション GIT URLS 参照)、または、リモートの名前
     (下記セクション REMOTES 参照)のどちらかです。

<refspec>…
     どの宛先refをどのソースオブジェクトで更新するかを指定します。
     <refspec> パラメータの形式は、オプションのプラス ‘+’ 、ソースオブジ
     ェクト <src> 、コロン ‘:’ 、宛先ref <dst> の順です。

     <src> は、プッシュするブランチの名前であることがよくありますが、
     ‘master~4’ とか ‘HEAD’ などの任意の「SHA-1式」にすることができます
     (gitrevisions(7) 参照)。

     <dst>は、このプッシュでリモート側のどのrefが更新されるかを示します
     。 ここでは任意の式を使用できません。実際のrefには名前を付ける必要
     があります。 ‘git push [<repository>]’ に ‘<refspec>’ 引数を指定せ
     ず、 ‘remote.<repository>.push’ 構成変数で ‘<src>’ を指定して同一の
     refを更新する場合、 ‘:<dst>’ の部分を省略することができるようになり
     ました — このようなプッシュは、コマンドラインで ‘<refspec>’ を指定
     しなくても、 ‘<src>’ が通常更新するrefを更新することになります。 そ
     れ以外の場合、 ‘:<dst>’ がないということは、‘<src>’ と同一のrefを更
     新することを意味します。

     <dst> が ‘refs/’(例: ‘refs/heads/master’)で始まらない場合、プッシュ
     される <src> の種類と <dst> があいまいかどうかから、それが ‘refs/*’
     上のどこに属するか推測しようとします。

        • <dst> が <repository> リモートのrefを明確に参照している場合は
          、そのrefにプッシュします。

        • <src>が ‘refs/heads/’ または ‘refs/tags/’ で始まるrefに解決さ
          れる場合は、その解決されたrefを <dst> の前に追加します。

        • 将来、他のあいまいさの解決策が追加される可能性がありますが、今
          のところ、他の場合では、試行した内容を示すエラー出力し、そして
          ‘advice.pushUnqualifiedRefname’ 構成に応じて、あなたがプッシュ
          したい ‘refs/’ 名前空間を提案します。

     <src>によって参照されるオブジェクトは、リモート側の<dst>参照を更新
     するために使用されます。 これが許可されるかどうかは、以下で詳細に説
     明するように、 ‘refs/*’ のどこに<dst>参照が存在するかによって異なり
     ます。これらのセクションでは、「更新」(update)とは、削除以外の変更
     を意味します。

     ‘refs/heads/*’ 名前空間はcommitオブジェクトのみを受け入れ、早送り
     (fast-forward)できる場合にのみ更新します。

     ‘refs/tags/*’ 名前空間は(コミット、ツリー、ブロブにタグを付けること
     ができるため、)あらゆる種類のオブジェクトを受け入れ、それらへの更新
     は拒否(reject)されます。

     ‘refs/{tags,heads}/*’ の外側の任意の名前空間に任意のタイプのオブジ
     ェクトをプッシュすることが可能です。 タグとコミットの場合、更新が許
     可されるかどうかの判断のために、これらは ‘refs/heads/*’ 内のコミッ
     トであるかのように扱われます。

     つまり、‘refs/{tags,heads}/*’ の外部でのコミットやタグの早送りは、
     早送りされるものがコミットではなく、たまたま置き換えられる最後のタ
     グ(またはコミット)の早送りである新しいコミットを指しているタグオブ
     ジェクトであっても、許可されます。 タグを全く別のタグに置き換えるこ
     とも、同一のコミットを指していれば可能です。また、剥かれたタグ
     (peeled tag)をプッシュすることもできます。つまり、既存のタグオブジ
     ェクトが指しているコミット、または既存のコミットが指している新しい
     タグオブジェクトをプッシュします。

     ‘refs/{tags,heads}/*’ の外側にあるツリーオブジェクトとブロブオブジ
     ェクトは、 ‘refs/tags/*’ の内側にある場合と同一の扱いであり、更新は
     拒否されます。

     更新が許可されていないものに関する上記のすべてのルールは、オプショ
     ンの先頭の ‘+’ をrefspecに追加する(または ‘--force’ コマンドライン
     オプションを使用する)ことでオーバーライドできます。 これに対する唯
     一の例外は、 ‘refs/heads/*’ 名前空間が非コミットオブジェクトを受け
     入れるように強制することはないということです。 フックと構成は、これ
     らのルールをオーバーライドまたは修正することもできます。たとえば、
     git-config(1) の ‘receive.denyNonFastForwards’ と、 githooks(5) の
     ‘pre-receive’ や ‘update’ を参照してください。

     空の <src> をプッシュすると、リモートリポジトリから <dst> ref を削
     除できます。 構成またはフックによって禁止されている場合を除き、削除
     は常に refspec の先頭に ‘+’ を付けずに受け入れられます(または
     ‘--force’)。 git-config(1) の ‘receive.denyDeletes’ と、
     githooks(5) の ‘pre-receive’ や ‘update’ を参照してください。

     特別なrefspec ‘:’ (または非早送り更新を許可する場合は ‘+:’)は、
     Gitに、「一致する」ブランチをプッシュするように指示します。 ローカ
     ル側に存在するすべてのブランチについて、同じ名前のブランチがリモー
     ト側にすでに存在する場合、リモート側が更新されます。

     ‘tag <tag>’ は、 ‘refs/tags/<tag>:refs/tags/<tag>’ と同じ意味です。

‘--all’
     すべてのブランチ(つまり、 ‘refs/heads/’ の下のrefs)をプッシュします
     。 他の<refspec>と一緒に使用することはできません。

‘--prune’
     ローカルに対応するものがないリモートブランチを削除します。 たとえば
     、同じ名前のローカルブランチがもう存在しない場合、リモートブランチ
     ‘tmp’ は削除されます。 これは refspecs も尊重し、 ‘git push --prune
     remote refs/heads/*:refs/tmp/*’ は、リモートの ‘refs/tmp/foo’ が
     ‘refs/heads/foo’ が存在しない場合に削除されることを確認するものです
     。

‘--mirror’
     プッシュする各refに名前を付ける代わりに、 ‘refs/’ の下のすべての参
     照(‘refs/heads/’ と ‘refs/remotes/’ と ‘refs/tags/’ を含むがこれら
     に限定されない)がリモートリポジトリへミラーリングされるように指定し
     ます。 新しく作成されたローカルrefはリモートエンドにプッシュされ、
     ローカルで更新されたrefはリモートエンドで強制的に更新され、削除され
     たrefはリモートエンドから削除されます。 これは、構成オプション
     ‘remote.<remote>.mirror’ が設定されている場合のデフォルトです。

‘-n’
‘--dry-run’
     実際に更新を送信する以外はすべて行います。

‘--porcelain’
     機械可読出力を生成します。 各refの出力ステータス行はタブで区切られ
     、stderrではなくstdoutに送信されます。 refの完全な記号名が表示され
     ます。

‘-d’
‘--delete’
     リストされているすべてのrefがリモートリポジトリから削除されます。 こ
     れは、すべてのrefの前にコロン(‘:’)を付けるのと同一です。

‘--tags’
     コマンドラインに明示的にリストされているrefspecsに加えて、
     ‘refs/tags’ の下にあるすべてのrefがプッシュされます。

‘--follow-tags’
     このオプションがなければプッシュされるであろうすべてのrefをプッシュ
     し、さらに ‘refs/tags’ にある、リモートからは見つからないがプッシュ
     されるrefから到達可能なコミットっぽい何かを指す注釈付きタグをプッシ
     ュします。 これは、設定変数 ‘push.followTags’ で指定することもでき
     ます。 詳しくは git-config(1) にある ‘push.followTags’ を参照してく
     ださい。

‘--[no-]signed’
‘--signed=(true|false|if-asked)’
     プッシュ要求をGPG署名して、受信側のrefを更新し、フックでチェックし
     たり、ログに記録したりできるようにします。 ‘false’ または
     ‘--no-signed’ の場合、署名は試行されません。 ‘true’ または
     ‘--signed’ の場合、サーバーが署名付きプッシュをサポートしていないと
     、プッシュは失敗します。 ‘if-asked’ に設定されている場合、サーバー
     が署名されたプッシュをサポートしている場合にのみ署名します。 ‘gpg
     --sign’ の実際の呼び出しが失敗した場合も、プッシュは失敗します。 受
     信側の詳細については、 git-receive-pack(1) を参照してください。

‘--[no-]atomic’
     可能な場合は、リモート側でアトミック取引(atomic transaction)を使用
     します。 すべてのrefが更新されるか、エラーが発生した場合、refは更新
     されません。 サーバーがアトミックプッシュをサポートしていない場合、
     プッシュは失敗します。

‘-o <option>’
‘--push-option=<option>’
     指定の文字列をサーバーに送信します。サーバーは、それらを受信前
     (pre-receive)フックと受信後(post-receive)フックに渡します。 指定の
     文字列には、NUL文字またはLF文字を含めることはできません。 複数の
     ‘--push-option=<option>’ が指定されている場合、それらはすべてコマン
     ドラインにリストされている順序で相手側に送信されます。 コマンドライ
     ンで ‘--push-option=<option>’ が指定されていない場合は、代わりに構
     成変数 ‘push.pushOption’ の値が使用されます。

‘--receive-pack=<git-receive-pack>’
‘--exec=<git-receive-pack>’
     リモート側の ‘git-receive-pack’ プログラムへのパス。 sshを介してリ
     モートリポジトリにプッシュするときや、デフォルトの$PATHのディレクト
     リに当該プログラムが無いときに便利です。

‘--[no-]force-with-lease’
‘--force-with-lease=<refname>’
‘--force-with-lease=<refname>:<expect>’
     通常、「git push」は、上書きに使用されたローカルrefの祖先ではないリ
     モートrefの更新を拒絶(refuse)します。

     リモートrefの現在の値が期待の(expect)値である場合、このオプションは
     この制限をオーバーライドします。 それ以外の場合、「git push」は失敗
     します。

     あなたが、すでに公開しているものをリベースする必要があると想像して
     ください。 最初に公開した履歴をリベースされた履歴に置き換えるには、
     「早送りしなければならない」ルールをバイパスする必要があります。 あ
     なたのリベース作業中に他の誰かがあなたの元の履歴の上に構築した場合
     、リモートのブランチの先端は彼らのコミットで前進するかもしれません
     、そして、あなたが ‘--force’ を伴って盲目的にプッシュすると彼らの作
     業内容は失われてしまいます。

     このオプションを使用すると、更新している履歴がリベースされ、置き換
     えたいものであると期待していると言う事ができます。 リモートrefがま
     だあなたが指定したコミットを指している場合は、誰もrefに対して何もし
     なかったことの確認になります。 これは、参照を明示的にロックせずに「
     リース」(lease;賃借権期間)を取得するようなものであり、リモートrefは
     「リース」がまだ有効な場合にのみ更新されます。

     ‘--force-with-lease’ 単独では、詳細を指定しないため、現在の値がリモ
     ート追跡ブランチと同じである必要があり、更新されるすべてのリモート
     refを保護します。

     ‘--force-with-lease=<refname>’ では、期待する値(expected value)を指
     定しないので、名前付きrefを(単独で)保護します。更新される場合は、現
     在の値をリモート追跡ブランチと同じにする必要があります。

     ‘--force-with-lease=<refname>:<expect>’ は、現在の値が指定の値
     ‘<expect>’ と同じである必要があることで、指定のref(単独)を保護しま
     す(これは、refnameに対して持っているリモート追跡ブランチとは異なる
     ことが許可されています。または、この形式を使用する場合は、そのよう
     なリモート追跡ブランチを持つ必要はありません)。 ‘<expect>’ が空の文
     字列である場合、指定のrefはまだ存在していてはなりません。

     注意: refの期待される現在の値を明示的に指定する
     ‘--force-with-lease=<refname>:<expect>’ 以外のすべての形式はまだ実
     験的であり、この機能の経験を積むにつれてセマンティクスが変わる可能
     性があることに注意してください。

     ‘--no-force-with-lease’ は、コマンドラインでそれ以前に指定した全て
     の ‘--force-with-lease’ をキャンセルします。

     安全性に関する一般的な注意: このオプションを期待値(expected value)な
     しに指定すると、たとえば cronjob でリポジトリの ‘git fetch origin’
     のように、プッシュ先のリモートで暗黙的に ‘git fetch’ を実行するもの
     と非常に悪い相互作用が発生します。

     ‘--force’ に対して提供される保護は、作業の基になっていない後続の変
     更が破壊されないようにすることですが、バックグラウンドプロセスがバ
     ックグラウンドでrefを更新している場合、これは簡単に無効になります。
     私達は、あなたには既に分かっているはずの参照をやっつけるヒューリス
     ティックとして使用することができるリモートトラッキング情報以外何も
     持っていません。

     あなたのエディターまたは他のシステムがバックグラウンドで ‘git
     fetch’ を実行している場合、これを軽減する方法は、単に別のリモートを
     セットアップすることです:

          git remote add origin-push $(git config remote.origin.url)
          git fetch origin-push

     これで、バックグラウンドプロセスが ‘git fetch origin’ を実行すると
     きは、 ‘origin-push’ の参照は更新されないため、以下のようにコマンド
     を実行します:

          git push --force-with-lease origin-push

     これは、あなたが手動で ‘git fetch origin-push’ を実行しない限り、失
     敗するでしょう。 もちろん、この方法は ‘git fetch --all’ の実行によ
     って完全に破綻します。この場合、あなたはそれを無効にするか、以下の
     ようになもっと退屈なことをする必要があります:

          git fetch              # update 'master' from remote
          git tag base master    # mark our base point
          git rebase -i master   # rewrite some commits
          git push --force-with-lease=master:base master:master

     つまり、上流のコードを見て、上書きしても良いと思ったバージョンの
     ‘base’ タグを作成し、履歴を書き換え、最後にリモートバージョンがまだ
     ‘base’ にあれば、ローカルの ‘remotes/origin/master’ がバックグラウ
     ンドで何を更新したかに関わらず、変更を ‘master’ に強制的にプッシュ
     します。

     あるいは、 ‘--force-with-lease[=<refname>]’ と共に補助オプションと
     して ‘--force-if-includes’ を指定すると(つまり、リモート側の ref が
     正確にどのコミットを指す必要があるか、あるいはリモート側のどの ref
     を保護しているのかを明示せずに)、 プッシュ時に、バックグラウンドで
     暗黙的に更新されていたかもしれないリモート追跡 ref からの更新がロー
     カルで統合されているかを、強制更新ができる前に確認することができる
     ようになります。

‘-f’
‘--force’
     通常、コマンドは、上書きに使用されたローカルrefの祖先ではないリモー
     トrefの更新を拒否します。 また、 ‘--force-with-lease’ オプションを
     使用すると、コマンドは、現在(current)値が期待(expect)値と一致しない
     リモートrefの更新を拒否します。

     このフラグはこれらのチェックを無効にし、リモートリポジトリがコミッ
     トを失う原因となる可能性があります。 注意して使用してください。

     注意: ‘--force`は、プッシュされるすべてのrefに適用されることに注意
     してください。 したがって、 `push.default’ を ‘matching’ に設定した
     り、 ‘remote.*.push’ で構成された複数のプッシュ先で使用すると、現在
     のブランチ以外のref(リモートの対応物の背後にあるローカル参照を含む
     )が上書きされる可能性があります。 1つのブランチのみにプッシュを強制
     するには、 refspecの前に ‘+’ を使用してプッシュします(例: ‘git push
     origin +master’ を使用して、 ‘master’ ブランチにプッシュを強制しま
     す)。 詳細については、上記「<refspec>…」セクションを参照してくださ
     い。

‘--[no-]force-if-includes’
     リモート追跡refの先端がローカルに統合されている場合にのみ、更新を強
     制します。

     このオプションを使用すると、リモートトラッキング参照の先端が、書き
     換えのためにそれに基づいているローカルブランチの「ref log」エントリ
     の1つから到達可能かどうかを確認(verify)するチェックが有効になります
     。 このチェックでは、リモートからの更新がローカルに取り込まれていな
     い場合、強制更新を拒否することで、更新がローカルに取り込まれている
     ことを確認します。

     オプションが ‘--force-with-lease’ を指定せずに渡された場合、または
     ‘--force-with-lease=<refname>:<expect>’ と一緒に指定された場合、そ
     れは「何もしません」(no-op)。

     ‘--no-force-if-includes’ を指定すると、この振る舞いが無効になります
     。

‘--repo=<repository>’
     このオプションは、<repository> 引数と同等です。 両方を指定すると、
     このオプションではなくコマンドライン引数が優先されます。

‘-u’
‘--set-upstream’
     最新の、または正常にプッシュされたすべてのブランチについて、引数の
     ない git-pull(1) および その他のコマンドで使用されるアップストリー
     ム(追跡)参照を追加します。 詳細については git-config(1) の
     ‘branch.<name>.merge’ を参照してください。

‘--[no-]thin’
     これらのオプションは git-send-pack(1) に渡されます。 送信側と受信側
     が同一オブジェクトを多く共有している場合、thin転送は送信データの量
     を大幅に削減します。 デフォルトは ‘--thin’ です。

‘-q’
‘--quiet’
     エラーが発生しない限り、更新されたrefのリストを含むすべての出力を抑
     制します。 進行状況を標準エラーストリームに報告しません。

‘-v’
‘--verbose’
     おしゃべりな実行を行います。

‘--progress’
     ‘-q’ が指定されていない限り、進行状況は、端末に接続されている場合、
     デフォルトで標準エラーストリームに報告されます。 このフラグは、標準
     エラーストリームが端末に送信されていない場合でも、進行状況を強制し
     ます。

‘--no-recurse-submodules’
‘--recurse-submodules=check|on-demand|only|no’
     プッシュされるリビジョンによって使用されるすべてのサブモジュールコ
     ミットがリモート追跡ブランチで使用可能であることを確認するために使
     用できます。 ‘check’ が使用されている場合、Gitは、プッシュされるリ
     ビジョンで変更されたすべてのサブモジュールコミットが、サブモジュー
     ルの少なくとも1つのリモートで使用可能であることを確認します。 コミ
     ットが欠落している場合、プッシュは中止され、ゼロ以外のステータスで
     終了(exit)します。 ‘on-demand’ が使用されている場合、プッシュされる
     リビジョンで変更されたすべてのサブモジュールがプッシュされます。
     on-demand で必要なすべてのリビジョンをプッシュできなかった場合も中
     止(abort)され、ゼロ以外のステータスで終了(exit)します。 ‘only’ が使
     用されている場合、スーパープロジェクトがプッシュされないままである
     間、すべてのサブモジュールが再帰的にプッシュされます。 サブモジュー
     ルの再帰が必要ない場合は、値 ‘no’ または ‘--no-recurse-submodules’
     を使用して、 ‘push.recurseSubmodules’ 構成変数をオーバーライドでき
     ます。

‘--[no-]verify’
     pre-push フックをON/OFFします(githooks(5) 参照)。 デフォルトは
     ‘--verify｀ で、フックにプッシュを防ぐ機会を与えます。
     `--no-verify’ を使用すると、フックは完全にバイパスされます。

‘-4’
‘--ipv4’
     IPv6アドレスを無視して、IPv4アドレスのみを使用します。

‘-6’
‘--ipv6’
     IPv4アドレスを無視して、IPv6アドレスのみを使用します。

GIT URLS
********

一般に、URLには、トランスポートプロトコル、リモートサーバーのアドレス、
およびリポジトリへのパスに関する情報が含まれています。トランスポートプロ
トコルによっては、一部の情報が欠落している場合があります。

   Gitはsshとgitとhttpとhttpsプロトコルをサポートします(さらにftpと
ftpsをフェッチに使用できますが、これは非効率的で非推奨です。使用しないで
ください)。

   ネイティブトランスポート(つまり、 git:// URL)は認証を行わないため、セ
キュリティで保護されていないネットワークでは注意して使用する必要がありま
す。

   以下の構文を使用できます:

   • ssh://[user@]host.xz[:port]/path/to/repo.git/

   • git://host.xz[:port]/path/to/repo.git/

   • http[s]://host.xz[:port]/path/to/repo.git/

   • ftp[s]://host.xz[:port]/path/to/repo.git/

   代替のscpのような構文をsshプロトコルで使用することもできます:

   • [user@]host.xz:path/to/repo.git/

   この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されま
す。これは、コロンを含むローカルパスを区別するのに役立ちます。たとえば、
ローカルパス ‘foo:bar’ を、絶対パスまたは ‘./foo:bar’ として指定して、
ssh url として誤って解釈されないようにすることができます。

   sshおよびgitプロトコルは、さらに ~username 拡張をサポートします:

   • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

   • git://host.xz[:port]/~[user]/path/to/repo.git/

   • [user@]host.xz:/~[user]/path/to/repo.git/

   Gitでもネイティブにサポートされているローカルリポジトリの場合、以下の
構文を使用できます:

   • /path/to/repo.git/

   • file:///path/to/repo.git/

   これらの2つの構文は、前者が ‘--local’ オプションの機能を含むクローン
作成の場合を除いて、ほとんど同等です。 詳細については、 git-clone(1) を
参照してください。

   「git clone」と「git fetch」と「git pull」は、「git push」と違って適
切なバンドルファイルを受け入れます。 git-bundle(1) を参照してください。

   Gitが特定のトランスポートプロトコルを処理する方法を知らない場合、
Gitは _remote-<transport>_ リモートヘルパー(存在する場合)を使用しようと
します。リモートヘルパーを明示的に要求するには、以下の構文を使用できます
:

   • <transport>::<address>

   ここで、 <address> は、パス、サーバーとパス、または呼び出されている特
定のリモートヘルパーによって認識される任意のURLのような文字列です。詳細
については、 gitremote-helpers(7) を参照してください。

   同じ名前のリモートリポジトリが多数あり、それらに異なる形式を使用する
場合(あなたの使用するURLが機能するURLに書き換えられるように)、以下の形式
の構成セクションを作成できます:

             [url "<actual url base>"]
                     insteadOf = <other url base>

   例えば、以下のようになります:

             [url "git://git.host.xz/"]
                     insteadOf = host.xz:/path/to/
                     insteadOf = work:

   "work:repo.git" や "host.xz:/path/to/repo.git" のようなURLは、任意の
コンテキストで、"git://git.host.xz/repo.git" に書き換えられます。

   プッシュ専用のURLを書き換えたい場合は、以下の形式の構成セクションを作
成できます:

             [url "<actual url base>"]
                     pushInsteadOf = <other url base>

   例えば、以下のようになります:

             [url "ssh://example.org/"]
                     pushInsteadOf = git://example.org/

   "git://example.org/path/to/repo.git" のようなURLは、プッシュの場合は
"ssh://example.org/path/to/repo.git" に書き換えられますが、プルは引き続
き元のURLのままです。

REMOTES
*******

‘<repository>’ 引数として、URLの代わりに以下のいずれかの名前を使用できま
す:

   • Git構成ファイル(configuration file)内のリモート(remote)として、
     ‘$GIT_DIR/config’ または

   • ‘$GIT_DIR/remotes’ ディレクトリ内のファイル または

   • ‘$GIT_DIR/branches’ ディレクトリ内のファイル

   これらはすべて、gitがデフォルトで使用するrefspecをそれぞれ含んでいる
ため、コマンドラインからrefspecを省略できます。

Named remote in configuration file
==================================

あなたは、 git-remote(1) を使うか、または git-config(1) を使うか、または
‘$GIT_DIR/config’ ファイルを手動で編集して、これ以前に構成したリモートの
名前から選択できます。このリモートのURLは、リポジトリへのアクセスに使用
されます。コマンドラインでrefspecを指定しない場合、このリモートの
refspecがデフォルトで使用されます。構成ファイルのエントリは以下のように
なります:

             [remote "<name>"]
                     url = <url>
                     pushurl = <pushurl>
                     push = <refspec>
                     fetch = <refspec>

   ‘<pushurl>’ はプッシュにのみ使用されます。 これはオプションであり、デ
フォルトは ‘<url>’ です。

Named file in $GIT_DIR/remotes
==============================

あなたは、 ‘$GIT_DIR/remotes’ でファイル名を指定できます。このファイルの
URLは、リポジトリへのアクセスに使用されます。コマンドラインでrefspecを指
定しない場合、このファイルのrefspecがデフォルトとして使用されます。この
ファイルの形式は以下のとおりです:

             URL: one of the above URL format
             Push: <refspec>
             Pull: <refspec>

   ‘Push:’ 行は ‘git push’ で使用され、 ‘Pull:’ 行は ‘git pull’ と ‘git
fetch’ で使用されます。追加のブランチマッピングのために、複数の ‘Push:’
および ‘Pull:’ 行を指定できます。

Named file in $GIT_DIR/branches
===============================

‘$GIT_DIR/branches’ でファイル名を指定できます。このファイルのURLは、リ
ポジトリへのアクセスに使用されます。 このファイルの形式は以下のとおりで
す:

             <url>#<head>

   ‘<url>’ は必須です。 ‘#<head>’ はオプションです。

   コマンドラインで指定しない場合、操作に応じて、gitは以下のrefspecのい
ずれかを使用します。 ‘<branch>’ は ‘$GIT_DIR/branchs’ 内のこのファイルの
名前であり、 ‘<head>`はデフォルトで `master’ になります。

   git fetch は以下を使用します:

             refs/heads/<head>:refs/heads/<branch>

   git push は以下を使用します:

             HEAD:refs/heads/<head>

OUTPUT
******

‘git push’ の出力は、使用する転送方法によって異なります。 このセクション
では、Gitプロトコルで(ローカルまたはssh経由で)プッシュするときの出力につ
いて説明します。

   プッシュのステータスは表形式で出力され、各行は単一のrefのステータスを
表します。 各行の形式は以下のとおりです:

      <flag> <summary> <from> -> <to> (<reason>)

   ‘--porcelain’ が使用されている場合、出力の各行は以下の形式になります:

      <flag> \t <from>:<to> \t <summary> (<reason>)

   最新のrefのステータスは、 ‘--porcelain’ または ‘--verbose’ オプション
が使用されている場合にのみ表示されます。

flag
     refのステータスを示す単一の文字:

     (space)
          早送り(fast-forward)プッシュに成功した

     ‘+’
          強制更新に成功した

     ‘-’
          refの削除に成功した

     ‘*’
          新しいrefのプッシュに成功した

     ‘!’
          プッシュが拒否された、またはプッシュに失敗したref

     ‘=’
          すでに最新でプッシュする必要がなかったref

summary
     正常にプッシュされたrefの場合、概要には、refの古い値と新しい値が
     ‘git log’ の引数として使用するのに適した形式で表示されます(ほとんど
     の場合は ‘<old>..<new>’ で、強制的な非早送り更新の場合は
     ‘<old>...<new>’ です)。

     失敗した更新については、以下の詳細が示されます:

     rejected
          Gitはrefをまったく送信しようと試みませんでした。これは通常、そ
          れが早送り(fast-forward)では無く、かつ、あなたが更新を強制しな
          かったためです。

     remote rejected
          リモートエンドが更新を拒否しました。 通常、リモート側のフック
          が原因で発生するか、リモートリポジトリで次の安全オプションのい
          ずれかが有効になっていることが原因です:
          ‘receive.denyCurrentBranch’ (チェックアウトされたブランチへの
          プッシュ用) または ‘receive.denyNonFastForwards’ (強制的な非早
          送り更新用) または ‘receive.denyDeletes’ または
          ‘receive.denyDeleteCurrent’ です。 git-config(1) を参照してく
          ださい。

     remote failure
          リモート側は、おそらくリモート側での一時的なエラー、または、ネ
          ットワーク接続の切断、または、その他の一時的なエラーのために、
          refの正常な更新を報告しませんでした。

from
     プッシュされるローカルrefの名前から、その ‘refs/<type>/’ プレフィッ
     クスを取り除いたもの。 削除の場合、ローカルrefの名前は省略されます
     。

to
     更新されるリモートrefの名前から、 ‘refs/<type>/’ プレフィックスを取
     り除いたもの。

reason
     人間が読める説明。 正常にプッシュされたrefの場合、説明は必要ありま
     せん。 失敗したrefについては、失敗の理由が説明されています。

NOTE ABOUT FAST-FORWARDS
************************

更新によって、コミットAをポイントしていたブランチ(またはより一般的には
ref)が別のコミットBをポイントするように変更された場合、BがAの子孫である
場合に限り、早送り(fast-forward)更新と呼ばれます。

   AからBへの早送り(fast-forward)更新では、元のコミットA上に構築されたコ
ミットのセットは、新しいコミットB上に構築されたコミットのサブセットです
。 したがって、履歴が失われることはありません。

   対照的に、非早送り更新は履歴を失います。 たとえば、あなたと他の誰かが
同じコミットXで開始し、あなたがコミットBにつながる履歴を作成し、他の人が
コミットAにつながる履歴を作成したとします。そうすると履歴は以下のように
なります:

           B
          /
      ---X---A

   さらに、もう一人が既に A につながる変更を元のリポジトリにプッシュして
おり、そこからあなたたち二人が元のコミット X を取得したとします。

   他の人が行ったプッシュにより、コミットXをポイントしていたブランチがコ
ミットAをポイントするように更新されました。これは早送りです。

   しかし、あなたがプッシュしようとすると、コミットBでブランチ(現在はAを
指している)を更新しようとします。これは早送りにはなりません。 そうすると
、コミットAによって導入された変更は失われます。なぜなら、全員がB上に構築
を開始するためです。

   このコマンドは、デフォルトでは、このような履歴の損失を防ぐための早送
り(fast-forward)ではない更新を許可していません。

   自分の作業(XからBへの履歴)または他の人の作業(XからAへの履歴)を失いた
くない場合は、最初にリポジトリから履歴をフェッチし、行われた変更を含む履
歴を作成する必要があり、両方の当事者によって行われた変更を含む履歴を作成
し、結果をプッシュバックします。

   あなたは ‘git pull’ を実行し、潜在的な競合を解決して、結果を ‘git
push’ することができます。 ‘git pull’ は、コミットAとBの間にマージコミッ
トCを作成します。

           B---C
          /   /
      ---X---A

   結果のマージコミットでAを更新すると、早送り(fast-forward)され、そして
、プッシュが受け入れられます。

   または、あなたは ‘git pull --rebase’ を使用して、A上のXとBの間のあな
たの変更をリベースし、結果をプッシュバックすることもできます。 リベース
は、A上のXとBの間の変更を構築する新しいコミットDを作成します。

           B   D
          /   /
      ---X---A

   繰り返しになりますが、このコミットでAを更新すると早送り
(fast-forward)され、プッシュが受け入れられます。

   プッシュしようとしたときに非早送拒否(non-fast-forward rejection)が発
生する可能性がある別の一般的な状況があります。これは、他の誰もプッシュし
ていないリポジトリにプッシュしている場合でも発生する可能性があります。 自
分でコミットAをプッシュした後(このセクションの最初の図)、コミットBを生成
するために「git commit –amend」に置き換え、すでにAをプッシュしたことを忘
れたため、プッシュしようとします。 このような場合、その間に誰も以前のコ
ミットAをフェッチしなかった(そしてその上にビルドを開始した)ことが確実な
場合にのみ、「git push –force」を実行して上書きできます。 言い換えれば、
「git push –force」は、履歴を失うことを意味する場合のために予約されてい
るメソッドです。

EXAMPLES
********

‘git push’
     ‘git push <remote>’ のように機能します。ここで、<remote>は現在のブ
     ランチのリモート(または、現在のブランチにリモートが構成されていない
     場合は ‘origin’)です。

‘git push origin’
     追加の構成がない場合、現在のブランチが、構成されたアップストリーム
     の現在のブランチと同一の名前の場合は、現在のブランチを構成されたア
     ップストリーム(‘branch.<name>.merge’ 構成値)にプッシュし、それ以外
     の場合はプッシュせずにエラーになります。

     <refspec>が指定されていない場合のこのコマンドのデフォルトの動作は、
     リモートの ‘push’ オプション、または ‘push.default’ 構成変数を設定
     することで構成できます。

     たとえば、デフォルトで現在のブランチのみを ‘origin’ にプッシュする
     には、 ‘git config remote.origin.push HEAD’ を使用します。 有効な
     <refspec> (以下の例のような)を ‘git push origin’ のデフォルトとして
     設定できます。

‘git push origin :’
     「マッチする」ブランチを ‘origin’ にプッシュします。 「マッチする」
     ブランチの説明については、上記 OPTIONS (see [OPTIONS]) セクショ
     ンの <refspec> を参照してください。

‘git push origin master’
     ソースリポジトリで ‘master’ に一致するrefを探し(ほとんどの場合
     ‘refs/heads/master’ を探し)、 ‘origin’ リポジトリで同一ref(例:
     ‘refs/heads/master’)を更新します。 ‘master’ がリモートに存在しなか
     った場合は作成されます。

‘git push origin HEAD’
     現在のブランチをリモートの同一の名前にプッシュする便利な方法。

‘git push mothership master:satellite/master dev:satellite/dev’
     ‘master’ と一致するソースref(例: ‘refs/heads/master’)を使用して、
     ‘mothership’ リポジトリ内の ‘satellite/master’(おそらく
     ‘refs/remotes/satellite/master’)と一致するrefを更新します。 ‘dev’ と
     ‘satellite/dev’ についても同様にします。

     マッチングのセマンティクスの説明については、 上記「<refspec>…」につ
     いて説明しているセクションを参照してください。

     これは、 ‘mothership’ で実行される ‘git fetch’ を、 ‘satellite’ で
     の作業を統合するために逆方向に実行される ‘git push’ でエミュレート
     するもので、一方通行でしか接続できないときによく必要になります(つま
     り、 ‘satellite’ はsshで ‘mothership’ に入ることができますが、
     ‘satellite’ がファイアウォールの背後にあるか、sshdを実行していない
     ため、 ‘mothership’ は ‘satellite‘への接続を開始できません)。

     この ‘git push’ を ‘satellite’ のマシンで実行した後、 ‘mothership’
     に ssh して ‘git merge’ を実行すれば、‘satellite’ で行われた変更を
     ‘git pull’ でプルするエミュレーションが完成します。

‘git push origin HEAD:master’
     現在のブランチを、 ‘origin’ リポジトリ内の ‘master’ に一致するリモ
     ートrefにプッシュします。 この形式は、ローカル名を気にせずに現在の
     ブランチをプッシュするのに便利です。

‘git push origin master:refs/heads/experimental’
     現在の ‘master’ ブランチをコピーして、 ‘origin’ リポジトリにブラン
     チ ‘experimental’ を作成します。 これは、ローカル名とリモート名が異
     なる場合に、リモートリポジトリに新しいブランチまたはタグを作成する
     時のみ必要な形式です。 それ以外の場合は、ref名自体で機能します。

‘git push origin :experimental’
     ‘origin’ リポジトリで ‘experimental’ に一致するref(たとえば
     ‘refs/heads/experimental’)を見つけて削除します。

‘git push origin +dev:master’
     origin リポジトリのmasterブランチをdevブランチで更新し、早送り以外
     の更新(non-fast-forward updates)を可能にします。「これにより、参照
     されていないコミットがoriginリポジトリにぶら下がる可能性があります
     。」 早送りが(fast-forward)不可能な以下の状況を考慮してください:

                      o---o---o---A---B  origin/master
                               \
                                X---Y---Z  dev

     上記コマンドは、originリポジトリを以下のように変更します

                                A---B  (unnamed branch)
                               /
                      o---o---o---X---Y---Z  master

     コミットAとBは、もはやシンボリック名のブランチに属さなくなるため、
     到達不能になります。 そのため、これらのコミットは、originリポジトリ
     の ‘git gc’ コマンドによって削除されます。

SECURITY
********

フェッチおよびプッシュプロトコルは、共有することを意図していない一方の側
が他方のリポジトリからデータを盗むのを防ぐようには設計されていません。悪
意のある者から保護する必要のあるプライベートデータがある場合、最善のオプ
ションはそれを別のリポジトリに保存することです。これは、クライアントとサ
ーバーの両方に適用されます。特に、サーバー上の名前空間は、読み取りアクセ
ス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼
できるクライアントにのみ、名前空間への読み取りアクセスを許可する必要があ
ります。

   既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は、明示的に共有することを意図していないオブジェクトのIDをア
     ドバタイズする "have" 行を送信しますが、他にもIDを持っている者が居
     る場合は、転送を最適化するために使用できます。攻撃者はオブジェクト
     ID Xを選択して盗み、refをXに送信しますが、被害者はすでにXのコンテン
     ツを持っているため、Xのコンテンツを送信する必要はありません。 これ
     で、被害者は攻撃者がXを持っていると信じ、Xのコンテンツを後で攻撃者
     に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間
     にXへのrefを作成してフェッチすることにより、クライアントがサーバー
     上で実行するのが最も簡単です。サーバーがクライアント上で実行する最
     も可能性の高い方法は、Xをパブリックブランチにマージし、ユーザーがこ
     のブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュ
     バックすることを期待します。)

  2. #1 と同様に、攻撃者は盗むオブジェクトID Xを選択します。被害者は、攻
     撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持
     っていると誤って主張するため、被害者はYをXに対するデルタとして送信
     します。デルタは、攻撃者にYに類似したXの領域を明らかにします。

GIT
***

Part of the git(1) suite

Name
****

git-quiltimport — quilt(キルト)パッチセットを現在のブランチに適用します

Synopsis
********

     git quiltimport [–dry-run | -n] [–author <author>] [–patches <dir>]
                     [–series <file>] [–keep-non-patch]

DESCRIPTION
***********

quiltパッチセットを現在のGitブランチに適用し、quiltパッチセットに存在す
るパッチ境界、パッチ順序、およびパッチの説明を保持します。

   パッチごとに、コードはパッチの説明から作者を抽出しようとします。それ
が失敗した場合は、 ‘--author’ で指定された作者にフォールバックします。
‘--author’ フラグが指定されていない場合、パッチの説明が表示され、ユーザ
ーはパッチの作者をインタラクティブに入力するように求められます。

   パッチの説明に件名が見つからない場合、パッチ名はGitの説明の1行の件名
として保持されます。

OPTIONS
*******

‘-n’
‘--dry-run’
     一連(series)のパッチをウォークスルーし、パッチをコミットするために
     必要なすべての情報が見つからない場合は警告します。この記事の執筆時
     点では、欠落している作者情報のみを警告します。

‘--author Author Name <Author Email>’
     パッチの説明に作者情報が見つからない場合に使用する作者名と電子メー
     ルアドレス。

‘--patches <dir>’
     quiltパッチを見つけるためのディレクトリ。

     パッチディレクトリのデフォルトは、 patches または ‘$QUILT_PATCHES’
     環境変数の値です。

‘--series <file>’
     キルトシリーズファイル(quilt series file)。

     シリーズファイルのデフォルトは、 <patches>/series または
     ‘$QUILT_SERIES’ 環境変数の値です。

‘--keep-non-patch’
     ‘-b’ フラグを _git mailinfo_ に渡します(git-mailinfo(1) 参照)。

GIT
***

Part of the git(1) suite

Name
****

git-range-diff — 2つのコミット範囲(例: ブランチの2つのバージョン)を比較
します

Synopsis
********

     git range-diff [–color=[<when>]] [–no-color] [<diff-options>]
             [–no-dual-color] [–creation-factor=<factor>]
             [–left-only | –right-only]
             ( <range1> <range2> | <rev1>…<rev2> | <base> <rev1> <rev2> )

DESCRIPTION
***********

このコマンドは、パッチシリーズの2つのバージョン、またはより一般的には2つ
のコミット範囲(マージコミットは無視)の違いを表示します。

   そのために、最初に、互いに対応する両方のコミット範囲からコミットのペ
アを見つけます。 2つのコミットは、パッチ間の差分(つまり、作者情報、コミ
ットメッセージ、およびコミット差分)がパッチのサイズと比較して適度に小さ
い場合に一致していると言われます。 詳細については、下記「Algorithm」を参
照してください。

   最後に、一致するコミットのリストが2番目のコミット範囲の順序で表示され
、すべての祖先が表示された直後に一致しないコミットが挿入されます。

   コミット範囲を指定するには、以下の3つの方法があります:

   • ‘<range1> <range2>’ : どちらのコミット範囲も ‘<base>..<rev>’ または
     ‘<rev>^!’ または ‘<rev>^-<n>’ 形式にすることができます。 詳細につい
     ては、 gitrevisions(7)の「SPECIFYING RANGES」を参照してください。

   • ‘<rev1>...<rev2>’ : これは、 ‘<rev2>..<rev1> <rev1>..<rev2>’ と同じ
     です。

   • ‘<base> <rev1> <rev2>’ : これは ‘<base>..<rev1> <base>..<rev2>’ と
     同じです。

OPTIONS
*******

‘--no-dual-color’
     コミットdiffが異なる場合、 ‘git range-diff’ は元の差分の色付けを再
     現し、例えば、追加された正確な行に変更があったとき、背景が 赤/緑 で
     ある外側の -/+ 差分マーカーを追加して見やすくします。

     さらに、最初のコミット範囲にのみ存在するコミット差分行は「薄暗く」
     (dimmed)表示され(これは、 ‘color.diff.<slot>’ 構成設定を使用してオ
     ーバーライドできます。ここで、 ‘<slot>’ は ‘contextDimmed’ と
     ‘oldDimmed’ と ‘newDimmed’ のうちの1つです)、2番目のコミット範囲に
     のみ存在するコミット差分行は太字(bold)で示されています(これは、構成
     設定 ‘color.diff.<slot>’ を使用してオーバーライドできます。‘<slot>’
     は ‘contextBold’ または ‘oldBold’ または ‘newBold’ のいずれかです
     )。

     これは ‘range-diff’ のための「dual coloring」として知られています。
     ‘--no-dual-color’ を使用すると、外側のdiffマーカーに従ってすべての
     行の色を反転します(色に関しては内側のdiffを完全に無視します)。

‘--creation-factor=<percent>’
     作成/削除 コストのファッジ係数を ‘<percent>’ に設定します。 デフォ
     ルトは60です。 ‘git range-diff’ が誤って大きな変更を全体の書き換え
     (1つのコミットの削除と別のコミットの追加)と見なす場合は大きな値を試
     し、逆の場合は小さな値を試してください。 これが必要な理由の説明につ
     いては、下記「Algorithm」セクションを参照してください。

‘--left-only’
     最初に指定された範囲(または ‘<rev1>...<rev2>’ 形式を使用する場合は
     「左範囲」(left range)）から欠落しているコミットを隠し(suppress)ま
     す。

‘--right-only’
     2番目に指定された範囲(または ‘<rev1>...<rev2>’ 形式を使用する場合は
     「右範囲」(right range)）から欠落しているコミットを隠し(supprss)ま
     す。

‘--[no-]notes[=<ref>]’
     このフラグは、パッチを生成する ‘git log’ プログラム(git-log(1) 参照
     )に渡されます。

<range1> <range2>
     2つの範囲で指定されたコミットを比較します。ここで、 ‘<range1>’ は
     ‘<range2>’ の古いバージョンと見なされます。

<rev1>…<rev2>
     ‘<rev2>..<rev1>’ と ‘<rev1>..<rev2>’ を渡すのと同じです。

<base> <rev1> <rev2>
     ‘<base>..<rev1>’ と ‘<base>..<rev2>’ を渡すのと同じです。 ‘<base>’
     は分岐の正確な分岐点である必要はないことに注意してください。 例: ブ
     ランチ ‘my-topic’ をリベースした後、 ‘git range-diff my-topic@{u}
     my-topic@{1} my-topic’ は、リベースによって導入された違いを示します
     。

   ‘git range-diff’ は、通常のdiffオプション(git-diff(1) 参照)、特に
‘--color=[<when>]’ および ‘--no-color’ オプションも受け入れます。 これら
のオプションは、「パッチ間の差分」を生成するときに使用されます。つまり、
作者、コミットメッセージ、および対応する 古い/新しい コミットの差分を比
較します。 現在、これらのパッチを生成するときに ‘git log’ に渡される
diffオプションのほとんどは微調整する手段がありません。

OUTPUT STABILITY
****************

‘range-diff’ コマンドの出力は変更される可能性があります。 これは人間が読
める磁器コマンドの出力であり、Gitのバージョン間でテキスト的に安定した
‘range-diff’ を取得するために使用できるものではありません
(git-patch-id(1) の ‘--stable’ オプションのようなものとは対照的です)。
‘range-diff’ には git-apply(1) に相当するものもありません。出力は、プロ
グラムで読み取ること(machine-readable)は意図されていません。

   これは特に diff オプションを渡すときに当てはまります。現在、 ‘--stat’
のようないくつかのオプションは、 ‘range-diff’ のコンテキストでは全く役に
立たない出力を生成することがあります。将来のバージョンの ‘range-diff’ で
は、このようなオプションを ‘range-diff’ 固有の方法で解釈するようになるか
もしれません (例えば、 ‘--stat’ は diffstat がどのように変化したかをまと
めた、人間が読めるような出力を生成します)。

CONFIGURATION
*************

このコマンドは、 ‘diff.color.*’ および ‘pager.range-diff’ 設定を使用しま
す(後者はデフォルトでオンになっています)。 git-config(1) を参照してくだ
さい。

EXAMPLES
********

リベースでマージの競合を解決する必要がある場合は、以下のコマンドを使用し
て、リベースによって導入された変更をその直後に比較します:

     $ git range-diff @{u} @{1} @

   ‘git range-diff’ の典型的な出力は以下のようになります:

     -:  ------- > 1:  0ddba11 Prepare for the inevitable!
     1:  c0debee = 2:  cab005e Add a helpful message at the start
     2:  f00dbal ! 3:  decafe1 Describe a bug
         @@ -1,3 +1,3 @@
          Author: A U Thor <author@example.com>

         -TODO: Describe a bug
         +Describe a bug
         @@ -324,5 +324,6
           This is expected.

         -+What is unexpected is that it will also crash.
         ++Unexpectedly, it also crashes. This is a bug, and the jury is
         ++still out there how to fix it best. See ticket #314 for details.

           Contact
     3:  bedead < -:  ------- TO-UNDO

   この例では、3つの古いコミットと3つの新しいコミットがあり、開発者は3番
目を削除し、最初の2つの前に新しいコミットを追加し、2番目のコミットのコミ
ットメッセージとその差分を変更しました。

   出力が端末に送られるとき、通常の ‘git diff’ の出力と同じように、デフ
ォルトで色分けされています。 さらに、最初の行(コミットの追加)は緑、最後
の行(コミットの削除)は赤、2番目の行(完全一致)は ‘git show’ の出力のコミ
ットヘッダーのように黄色で、 3行目は、古いコミットを赤、新しいコミットを
緑、残りを ‘git show’ のコミットヘッダーのように色付けします。

   ただし、単純な色分けされた「diffのdiff」は、行全体を赤または緑に色付
けするため、実際には少し読みにくいです。 たとえば、古いコミットで「予期
しないもの」を追加した行は、古いコミットの目的が何かを追加することであっ
たとしても、完全に赤くなります。

   これを助けるために、 ‘range’ はデフォルトで ‘--dual-color’ モードを使
用します。 このモードでは、「diffのdiff」は元のdiffの色を保持し、行の前
に「背景」が赤または緑の -/+ マーカーを付けて、diff自体がどのように変化
したかをより明確にします。

Algorithm
*********

一般的な考え方は次のとおりです: 両方のコミット範囲のコミット間にコストマ
トリックスを生成してから、最小コストの割り当てを解決します。

   コストマトリックスはこのように入力されます: コミットのペアごとに、両
方のdiffが生成され、3つのコンテキスト行で「diffのdiff」が生成され、その
diffの行数がコストとして使用されます。

   誤検知(たとえば、パッチが削除され、同じパッチシリーズの2つの反復の間
に無関係のパッチが追加された場合)を回避するために、一括 削除/追加 の固定
費エントリを追加することにより、コストマトリックスが拡張されて誤検知の回
避が可能になります。

   例: コミット ‘1--2’ をパッチシリーズの最初の反復とし、 ‘A--C’ を2番目
の反復とします。 ‘A’ は ‘2’ のチェリーピックであり、 ‘C’ は ‘1’ のチェリ
ーピックですが、わずかな変更(たとえば、タイプミス修正)があると仮定します
。 コミットを二部グラフ(bipartite graph)として視覚化する:

         1            A

         2            B

                      C

   私たちは、新しい系列を古い系列の観点から「最適」に「説明」
(explanation)することを求めています。「説明」はグラフの辺として表現する
ことができます:

         1            A
                    /
         2 --------'  B

                      C

   この「説明」(explanation)は、変更がなかったため、「無料」で提供されま
す。 同様に、 ‘C’ は ‘1’ を使用して「説明」できますが、変更のために「
c>0」のコストがかかります:

         1 ----.      A
               |    /
         2 ----+---'  B
               |
               `----- C
               c>0

   数学的に言えば、私たちが探しているのは、ある種の最小コストの二部マッ
チング(bipartite matching)です。 ‘1’ は、いくらかのコストで ‘C’ と一致し
ます。基礎となるグラフは、実際には完全2部グラフです。 すべてのエッジに関
連するコストは、2つのコミットのパッチ間の差分のサイズです。 新しいコミッ
トについても説明するために、両側にダミーノードを導入します:

         1 ----.      A
               |    /
         2 ----+---'  B
               |
         o     `----- C
               c>0
         o            o

         o            o

   エッジ ‘o--C’ のコストは、 ‘C’ の差分のサイズであり、100％未満である
必要があるファッジ係数(fudge factor)によって変更されます。 エッジ ‘o--o’
のコストは無料です。 ファッジ係数が必要なのは、たとえ ‘1’ と ‘C’ に共通
点がなくても、空行などがいくつか共有され、 ‘1--C’ 、 ‘o--o’ の代入が
‘1--o’ 、 ‘o--C’ よりもわずかにコストが安くなる可能性があるためです。フ
ァッジ係数を使用すると、パッチを対応するものと見なすためには、はるかに大
きな共通部分が必要になります。

   このアルゴリズムの計算に必要な全体の時間は、パッチの、n+mコミットdiff
と n*m diff の計算に必要な時間に加えて、nとmのdiff間の最小コストの割り当
ての計算に必要な時間です。 Gitは、Jonker-Volgenantアルゴリズムの実装を使
用して、実行時の複雑さが3次である割り当ての問題を解決します。 この場合に
見つかった一致は以下のようになります:

         1 ----.      A
               |    /
         2 ----+---'  B
            .--+-----'
         o -'  `----- C
               c>0
         o ---------- o

         o ---------- o

SEE ALSO
********

git-log(1)

GIT
***

Part of the git(1) suite

Name
****

git-read-tree — ツリー情報をインデックスに読み込みます

Synopsis
********

     git read-tree [[-m [–trivial] [–aggressive] | –reset | –prefix=<prefix>]
                     [-u [–exclude-per-directory=<gitignore>] | -i]]
                     [–index-output=<file>] [–no-sparse-checkout]
                     (–empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]])

DESCRIPTION
***********

<tree-ish> によって指定されたツリー情報をインデックスに読み込みますが、
「キャッシュする」ファイルは実際には「更新」されません。
(git-checkout-index(1) 参照)

   オプションで、ツリーをインデックスにマージしたり、早送り
(fast-forward)(つまり、2方向)マージを実行したり、 ‘-m’ フラグを使用して
3方向マージを実行したりできます。 ‘-u’ フラグを ‘-m’ と一緒に使用すると
、マージの結果で作業ツリー内のファイルも更新されます。

   trivial(些細な)マージは、 ‘git read-tree’ 自体によって行われます。
‘git read-tree’ から戻ると、競合するパスのみがマージされていない状態にな
ります。

OPTIONS
*******

‘-m’
     読み取りだけでなく、マージを実行します。インデックスファイルにマー
     ジされていないエントリがある場合、コマンドは実行を拒否します。これ
     は、以前に開始したマージが完了していないことを示します。

‘--reset’
     ‘-m’ と同じですが、マージされていないエントリが失敗する代わりに破棄
     される点が異なります。 ‘-u’ と一緒に使用すると、作業ツリーの変更が
     失われる原因となる更新によって操作が中止されることはありません。

‘-u’
     マージが成功したら、マージの結果で作業ツリーのファイルを更新します
     。

‘-i’
     通常、マージでは、ローカルの変更が失われないように、インデックスフ
     ァイルと作業ツリー内のファイルが現在のヘッドコミットで最新である必
     要があります。 このフラグは、作業ツリーでのチェックを無効にし、現在
     の作業ツリーのステータスに直接関係しないツリーを一時的なインデック
     スファイルにマージするときに使用することを目的としています。

‘-n’
‘--dry-run’
     作業ツリー内のインデックスまたはファイルを実際に更新せずに、コマン
     ドがエラーになるかどうかを確認します。

‘-v’
     ファイルのチェックアウトの進行状況を表示します。

‘--trivial’
     trivial(些細な)ケースでマージ解決作業し、競合するファイルをインデッ
     クスに未解決のままにする代わりに、 ‘git read-tree’ による3方向マー
     ジを、ファイルレベルのマージが必要ない場合にのみ発生するように制限
     します。

‘--aggressive’
     通常、 ‘git read-tree’ による3方向のマージは、本当にtrivial(些細な
     )ケースのマージを解決し、他のケースはインデックスに未解決のままにし
     て、磁器コマンドがさまざまなマージポリシーを実装できるようにします
     。このフラグにより、コマンドはさらにいくつかのケースを内部的に解決
     します:

        • 一方の側がパスを削除し、もう一方の側がパスを変更しないままにす
          る場合。 解決策は、そのパスを削除することです。

        • 両側でパスを削除したとき。 解決策は、そのパスを削除することで
          す。

        • 両側で同じようにパスを追加する場合。 解決策は、そのパスを追加
          することです。

‘--prefix=<prefix>’
     現在のインデックスの内容を保持し、 ‘<prefix>’ のディレクトリの下に
     ある名前付きtree-ishの内容を読み取ります。このコマンドは、元のイン
     デックスファイルにすでに存在しているエントリの上書きを拒否します。

‘--exclude-per-directory=<gitignore>’
     ‘-u’ および ‘-m’ オプションを指定してコマンドを実行すると、現在のブ
     ランチで追跡されていないパスをマージ結果で上書きする必要がある場合
     があります。コマンドは通常、そのようなパスを失うことを避けるために
     マージを続行することを拒否します。ただし、この安全弁が邪魔になるこ
     とがあります。たとえば、他のブランチがブランチで生成されたファイル
     であったファイルを追加し、 ‘make’ を実行した後、 ‘make clean’ を実
     行して生成されたファイルを削除する前に、そのブランチに切り替えよう
     とすると安全弁がトリガーされることがよくあります。このオプションは
     、ディレクトリごとの除外ファイル(通常は ‘.gitignore’)を読み取るよう
     にコマンドに指示し、追跡されていないが明示的に無視されたファイルを
     上書きできるようにします。

‘--index-output=<file>’
     結果を ‘$GIT_INDEX_FILE’ に書き出す代わりに、結果のインデックスを名
     前付きファイルに書き込みます。コマンドの動作中は、元のインデックス
     ファイルが通常と同じメカニズムでロックされます。ファイルは、通常の
     インデックスファイルの隣に作成される一時ファイルから名前を変更でき
     るようにする必要があります(rename(2))。通常、これは、インデックスフ
     ァイル自体と同じファイルシステム上にある必要があり、インデックスフ
     ァイルとインデックス出力ファイルが配置されているディレクトリへの書
     き込み権限が必要であることを意味します。

‘--[no-]recurse-submodules’
     ‘--recurse-submodules’ を使用すると、スーパープロジェクトに記録され
     たコミットに従ってすべてのアクティブなサブモジュールのコンテンツが
     更新され、read-treeが再帰的に呼び出され、そのコミット時にサブモジュ
     ールのHEADが切り離される(detach)ように設定されます。

‘--no-sparse-checkout’
     ‘core.sparseCheckout‘がtrueの場合でも、スパースチェックアウト
     (sparse checkout)のサポートを無効にします。

‘--empty’
     ツリーオブジェクトをインデックスに読み込む代わりに、空にします。

‘-q’
‘--quiet’
     静かにし、フィードバックメッセージを抑制します。

<tree-ish#>
     読み取られる/マージされる ツリーオブジェクトのID。

MERGING
*******

‘-m’ が指定されている場合、 ‘git read-tree’ は3種類のマージを提供します
。1つのツリーのみが指定されている場合は単一のツリーマージ(single tree
merge)、2つのツリーとの早送り(fast-forward)マージ(two tree merge)、3つ以
上のツリーが指定されている3方向マージです(3-way merge)。

Single Tree Merge
=================

ツリーが 1 つだけ指定されている場合、 ‘git read-tree’ はユーザーが ‘-m’
を指定しなかったかのように動作しますが、 元のインデックスに特定のパス名
のエントリがあり、パスの内容が読み取られるツリーと一致する場合、インデッ
クスの統計情報が使用されます。(言い換えれば、インデックスの stat() はマ
ージされたツリーのものよりも優先されます)。

   つまり、 ‘git read-tree -m <newtree>’ の後に ‘git checkout-index -f
-u -a’ を実行すると、 ‘git checkout-index’ は本当に変更されたものだけを
チェックアウトします。

   これは、 ‘git read-tree’ の後に ‘git diff-files’ を実行したときに不要
な誤検出を避けるために使用します。

Two Tree Merge
==============

通常、これは ‘git read-tree -m $H $M’ として呼び出されます。ここで、$H は
現在のリポジトリのヘッドコミットであり、$M は $H の前にある外部ツリーの
ヘッドです(つまり、早送り(fast-forward)の状況にあります)。

   2つのツリーが指定されている場合、ユーザーは ‘git read-tree’ に以下の
ように指示している事になります:

  1. 現在のインデックスと作業ツリーは$Hから派生していますが、 ユーザーは
     $H以降にローカルで変更を加えている可能性があります。

  2. ユーザーは$Mに早送り(fast-forward)したいと考えています。

   この場合、 ‘git read-tree -m $H $M’ コマンドは、この「マージ」の結果
としてローカルの変更が失われないことを確認します。 「繰越」(carry
forward)ルールは次のとおりです。「I」はインデックスを示し、「clean」はイ
ンデックスと作業ツリーが一致することを意味し、「exists」/「nothing」 は
指定されたコミットにパスが存在することを示します:

             I                   H        M        Result
            -------------------------------------------------------
          0  nothing             nothing  nothing  (does not happen)
          1  nothing             nothing  exists   use M
          2  nothing             exists   nothing  remove path from index
          3  nothing             exists   exists,  use M if "initial checkout",
                                          H == M   keep index otherwise
                                          exists,  fail
                                          H != M

             clean I==H  I==M
            ------------------
          4  yes   N/A   N/A     nothing  nothing  keep index
          5  no    N/A   N/A     nothing  nothing  keep index

          6  yes   N/A   yes     nothing  exists   keep index
          7  no    N/A   yes     nothing  exists   keep index
          8  yes   N/A   no      nothing  exists   fail
          9  no    N/A   no      nothing  exists   fail

          10 yes   yes   N/A     exists   nothing  remove path from index
          11 no    yes   N/A     exists   nothing  fail
          12 yes   no    N/A     exists   nothing  fail
          13 no    no    N/A     exists   nothing  fail

             clean (H==M)
            ------
          14 yes                 exists   exists   keep index
          15 no                  exists   exists   keep index

             clean I==H  I==M (H!=M)
            ------------------
          16 yes   no    no      exists   exists   fail
          17 no    no    no      exists   exists   fail
          18 yes   no    yes     exists   exists   keep index
          19 no    no    yes     exists   exists   keep index
          20 yes   yes   no      exists   exists   use M
          21 no    yes   no      exists   exists   fail

   すべての「インデックスを保持する」場合、インデックスエントリは元のイ
ンデックスファイルと同じままです。 エントリが最新でない場合、 ‘git
read-tree’ は ‘-u’ フラグの下で動作しているときに作業ツリー内のコピーを
そのまま保持します。

   この形式の ‘git read-tree’ から正常に返ると、 ‘git diff-index
--cached $M’ を実行することで、行った「ローカル変更」のどれが繰り越され
たかを確認できます。 これは、このような2つのツリーがマージされる前に
‘git diff-index --cached $H’ が生成したものと必ずしも一致しないことに注
意してください。 これは、上記ケース18と19が原因です — すでに$Mに変更があ
った場合(たとえば、パッチ形式で電子メールで取得した場合)、 ‘git
diff-index --cached $H’ は、このマージの前に変更について通知しますが、
2ツリーのマージ後の ‘git diff-index --cached $M’ 出力には表示されません
。

   上記ケース3は少しトリッキーで、説明が必要です。 このルールの結果は、
論理的には、ユーザーがパスの削除をステージングしてから新しいブランチに切
り替えた場合に、パスを削除することです。 ただし、これにより最初のチェッ
クアウトが行われないため、インデックスの内容が空の場合にのみM(新しいツリ
ー)を使用するようにルールが変更されます。 それ以外の場合、パスの削除は、
$Hと$Mが同じである限り保持されます。

3-Way Merge
===========

各「インデックス」エントリには、2ビット相当の「ステージ」状態があります
。ステージ0は通常のステージであり、通常の使用で見られる唯一のステージで
す。

   しかしながら、あなたが3つのツリーで ‘git read-tree’ を実行すると、「
ステージ」は1から始まります。

   これはあなたが以下のようにできることを意味します

     $ git read-tree -m <tree1> <tree2> <tree3>

   そうすると、「stage1」にすべての<tree1>エントリ、「stage2」にすべての
<tree2>エントリ、「stage3」にすべての<tree3>エントリを持つインデックスが
作成されます。 別のブランチを現在のブランチにマージする場合、共通の祖先
ツリーを<tree1>として、現在のブランチヘッドを<tree2>として、他のブランチ
ヘッドを<tree3>として使用します。

   さらに、 ‘git read-tree’ には、以下のような特殊なケースのロジックがあ
ります。以下の状態ですべての点で一致するファイルを見つけると、「折りたた
み」(collapse)して ‘stage0’ に戻します:

   • ステージ2と3は同一です。 どちらか一方を取ります(違いはありません。
     ステージ2のブランチとステージ3のブランチで同じ作業が行われました)

   • ステージ1とステージ2は同じで、ステージ3は異なります。ステージ3を取
     得します（ステージ2のブランチは、ステージ3のブランチが作業している
     間、ステージ1の祖先以降何もしませんでした）

   • ステージ1とステージ3は同じで、ステージ2は異なります。ステージ2を使
     用します(私達は何もしなかったのに何かをしました)

   ‘git write-tree’ コマンドは、無意味なツリーの書き込みを拒否し、ステー
ジ0ではない単一のエントリを検出すると、マージされていないエントリについ
て文句を言います。

   ええ、これはすべてまったく無意味なルールのコレクションのように聞こえ
ますが、実際には、高速マージを実行するために必要なものです。 異なるステ
ージは、「結果ツリー」(result tree)(ステージ0、別名「merged」)、元のツリ
ー(original tree)(ステージ1、別名「orig」）、およびマージしようとしてい
る2つのツリー（それぞれステージ2と3）を表します。

   すでに入力されているインデックスファイルを使用して3方向マージを開始す
る場合、ステージ1、2、および3の順序(つまり、3つの<tree-ish>コマンドライ
ン引数の順序)は重要です。アルゴリズムの仕組みの概要は以下のとおりです:

   • ファイルが3つのツリーすべてに同じ形式で存在する場合、ファイルは
     ‘git read-tree’ によって自動的に「マージされた」状態(merged state)に
     折りたたまれ(collapse)ます。

   • 3つのツリーに違いがあるファイルは、インデックス内の別々のエントリと
     して残ります。0以外のステージを削除し、マージされたバージョンを挿入
     する方法を決定するのは、「磁器ポリシー」(porcelain policy)次第です
     。

   • インデックスファイルはこれらすべての情報を保存および復元するため、
     段階的にマージできますが、ステージ 1/2/3 のエントリ(つまり、「マー
     ジされていないエントリ」)がある限り、結果を書き込むことはできません
     。したがって、マージアルゴリズムは非常に単純になります:

        • あなたはインデックスを順番に歩きます。ステージ0のすべてのエン
          トリはすでに完了しているため、無視します。

        • 「stage1」が見つかったが、一致する「stage2」または「stage3」が
          ない場合は、両方のツリーから削除されたことがわかり(元のツリー
          にのみ存在した)、そのエントリを削除します。

        • 一致する「stage2」および「stage3」ツリーが見つかった場合は、そ
          れらの1つを削除し、もう1つを「stage0」エントリに変換します。 一
          致する「stage1」エントリも存在する場合は削除します。 .. すべて
          の通常のtrivial(些細な)ルール ..

   この最後のステップを実行するには、通常、提供された ‘git
merge-one-file’ とともに ‘git merge-index’ を使用します。 スクリプトは、
各パスをマージし、マージが正常に終了すると、作業ツリー内のファイルを更新
します。

   すでに入力されているインデックスファイルを使用して3方向マージを開始す
ると、それが作業ツリー内のファイルの状態を表していると見なされ、変更がイ
ンデックスファイルに記録されていないファイルを作成することもできます。 さ
らに、この状態はステージ2ツリーから「派生」していると想定されます。 元の
インデックスファイルでステージ2と一致しないエントリが見つかった場合、3方
向マージは実行を拒否します。

   これは、進行中の変更が失われたり、無関係なマージコミットでランダムな
変更が混在したりするのを防ぐために行われます。ここでは説明のために、あな
たのリポジトリに最後にコミットされたものから開始するとします:

     $ JC=`git rev-parse --verify "HEAD^0"`
     $ git checkout-index -f -u -a $JC

   あなたは ‘git update-index’ を実行せずに、ランダムに編集します。 そし
て、あなたは彼(him)からpullしてからあなたの「上流」のツリーの先端が進ん
だことに気づきます:

     $ git fetch git://.... linus
     $ LT=`git rev-parse FETCH_HEAD`

   作業ツリーはまだHEAD($JC)に基づいていますが、あなたはそれ以降、いくつ
か編集しています。3方向マージは、 $JC 以降にインデックスエントリを追加ま
たは変更していないことを確認し、追加していない場合は、正しいことを行いま
す。 したがって、以下のシーケンス:

     $ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
     $ git merge-index git-merge-one-file -a
     $ echo "Merge with Linus" | \
       git commit-tree `git write-tree` -p $JC -p $LT

   これは、コミットするのは、進行中の作業を変更せずに$JCと$LTを純粋にマ
ージすることであり、作業ツリーはマージの結果に更新されます。

   ただし、このマージによって上書きされる作業ツリーにローカルの変更があ
る場合、変更が失われるのを防ぐために、 ‘git read-tree’ は実行を拒否しま
す。

   つまり、作業ツリーにのみ存在するものについて心配する必要はありません
。 マージに関係しないプロジェクトの一部にローカルの変更がある場合、変更
はマージに干渉せず、そのまま保持されます。 それらが干渉する場合、マージ
は開始されません(‘git read-tree’ は大声で文句を言い、何も変更せずに失敗
します)。 このような場合は、実行中の作業を続行し、作業ツリーの準備ができ
たら(つまり、進行中の作業が終了したら)、マージを再試行します。

SPARSE CHECKOUT
***************

「スパースチェックアウト」(Sparse checkout)を使用すると、作業ディレクト
リにまばらに(sparsely)データを入力できます。 skip-worktreeビット
(git-update-index(1) 参照)を使用して、作業ディレクトリ内のファイルを確認
する価値があるかどうかをGitに通知します。

   ‘git read-tree’ およびその他のマージベースコマンド(‘git merge’ 、
‘git checkout’ …)は、skip-worktreeビットマップと作業ディレクトリの更新を
維持するのに役立ちます。‘$GIT_DIR/info/sparse-checkout’ は、
skip-worktree参照ビットマップを定義するために使用されます。 ‘git
read-tree’ が作業ディレクトリを更新する必要がある場合、このファイルに基
づいてインデックスのskip-worktreeビットをリセットします。これは、
‘.gitignore’ ファイルと同じ構文を使用します。 エントリがこのファイルのパ
ターンとマッチする場合、skip-worktreeはそのエントリに設定されません。 そ
れ以外の場合は、skip-worktreeが設定されます。

   次に、新しいskip-worktree値を前の値と比較します。 skip-worktreeが
setからunsetに変わると、対応するファイルが追加されます。 unsetからsetに
変わると、そのファイルは削除されます。

   通常、 ‘$GIT_DIR/info/sparse-checkout’ はどのファイルが含まれているか
を指定するために使用されますが、否定パターンを使用して、どのファイルが含
まれていないかを指定することもできます。 たとえば、ファイル ‘unwanted’ を
削除するには以下のようにします:

     /*
     !unwanted

   もう1つの注意が必要なのは、スパースチェックアウトが不要になったときに
作業ディレクトリを完全に再設定することです。 skip-worktreeビットはまだイ
ンデックスにあり、作業ディレクトリはまだまばらに(sparsely)配置されている
ため、「スパースチェックアウト」を無効にすることはできません。 以下のよ
うに、作業ディレクトリに ‘$GIT_DIR/info/sparse-checkout’ ファイルの内容
を再入力する必要があります:

     /*

   その後、スパースチェックアウトを無効にできます。 ‘git read-tree’ およ
び同様のコマンドでのスパースチェックアウトのサポートはデフォルトで無効に
なっています。 スパースチェックアウトをサポートするには、
‘core.sparseCheckout’ をオンにする必要があります。

SEE ALSO
********

git-write-tree(1); git-ls-files(1); gitignore(5);
git-sparse-checkout(1);

GIT
***

Part of the git(1) suite

Name
****

git-rebase — 別のベース先端の上にコミットを再適用します

Synopsis
********

     git rebase [-i | –interactive] [<options>] [–exec <cmd>]
             [–onto <newbase> | –keep-base] [<upstream> [<branch>]]
     git rebase [-i | –interactive] [<options>] [–exec <cmd>] [–onto <newbase>]
             –root [<branch>]
     git rebase (–continue | –skip | –abort | –quit | –edit-todo | –show-current-patch)

DESCRIPTION
***********

<branch> が指定されている場合、 ‘git rebase’ は他の処理を行う前に自動で
‘git switch <branch>’ を実行します。それ以外の場合は、引き続き現在のブラ
ンチに滞在しています。

   <upstream> が指定されていない場合、 ‘branch.<name>.remote’ と
‘branch.<name>.mergebranch’ オプションで構成されたアップストリーム(詳細
はgit-config(1) 参照) および ‘--fork-point’ オプションが想定されています
。あなたが現在ブランチを一切使用していない場合、または、現在のブランチに
アップストリームが構成されていない場合、リベースは中止(abort)されます。

   現在のブランチでコミットによって行われたが、<upstream>にないすべての
変更は、一時領域に保存されます。 これは ‘git log <upstream>..HEAD’ で表
示されるのと同じコミットのセットで、または ‘--fork-point’ がアクティブな
場合 ‘git log 'fork_point'..HEAD’ で表示されるのと同じコミットのセットで
、または ‘--root’ オプションが指定されている場合 ‘git log HEAD’ で表示さ
れるのと同じコミットのセットです。

   現在のブランチは<upstream>にリセットされ、または ‘--onto’ オプション
が指定されている場合は<newbase>にリセットされます。これは、 ‘git reset
--hard <upstream>’ (または<newbase>)とまったく同じ効果があります。
ORIG_HEADは、リセット前にブランチの先端を指すように設定されています。

   以前に一時領域に保存されたコミットは、現在のブランチに1つずつ順番に再
適用されます。注意: ‘HEAD..<upstream>’ でのコミットと同一のテキスト変更
を導入するHEADでのコミットは省略されることに注意してください(つまり、異
なるコミットメッセージまたはタイムスタンプで、アップストリームで既に受け
入れ済のパッチはスキップされます)。

   マージに失敗すると、このプロセスが完全には自動で行われなくなる事があ
ります。あなたは、このようなマージの失敗を解決し、そして ‘git rebase
--continue’ を実行する必要があります。 別のオプションとしては、 ‘git
rebase --skip’ でマージの失敗を引き起こしたコミットをバイパスすることで
す。そして、元の<branch>をチェックアウトし、‘.git/rebase-apply’ 作業ファ
イルを削除するには、代わりにコマンド ‘git rebase --abort’ を使用します。

   以下の履歴が存在し、現在のブランチが ‘topic’ であるとします:

               A---B---C topic
              /
         D---E---F---G master

   この時点で、以下のコマンドのいずれかを実行します:

     git rebase master
     git rebase master topic

   そうすると以下のようになります:

                       A'--B'--C' topic
                      /
         D---E---F---G master

   *注意* : 後者の形式は、 ‘git checkout topic’ の後に ‘git rebase
master’ が続く省略形です。 リベースが終了すると、チェックアウトされたブ
ランチ(‘topic’)のままになります。

   (たとえば、アップストリームに適用されたパッチをメールで送信したため
)アップストリームブランチにすでに行った変更が含まれている場合、そのコミ
ットはスキップされ、警告が発行されます(‘merge’ バックエンドが使用されて
いる場合)。たとえば、以下の履歴で ‘git rebase master’ を実行します(‘A'’
と ‘A’ は同じ変更セットを導入しますが、コミッター情報は異なります):

               A---B---C topic
              /
         D---E---A'---F master

   これの結果は以下のようになります:

                        B'---C' topic
                       /
         D---E---A'---F master

   これは、あるブランチに基づいてトピックブランチを別のブランチに移植し
、 ‘rebase --onto’ を使用して、トピックブランチを後者のブランチからフォ
ークしたふりをする方法です。

   まず、「topic」がブランチ「next」に基づいているとしましょう。 たとえ
ば「topic」で開発された機能は、「next」にあるいくつかの機能に依存してい
ます。

         o---o---o---o---o  master
              \
               o---o---o---o---o  next
                                \
                                 o---o---o  topic

   我々は _topic_ をブランチ _master_ からフォークさせたいのです。たとえ
ば「topic」が依存する機能が、より安定した「master」ブランチにマージされ
たためです。 ツリーを以下のようにしたいわけです:

         o---o---o---o---o  master
             |            \
             |             o'--o'--o'  topic
              \
               o---o---o---o---o  next

   これは、以下のコマンドを使用して取得できます:

     git rebase --onto master next topic

   ‘--onto’ オプションの別の例は、ブランチの一部をリベースすることです。
以下のような状況の場合:

                                 H---I---J topicB
                                /
                       E---F---G  topicA
                      /
         A---B---C---D  master

   そして、以下のコマンドを実行します

     git rebase --onto master topicA topicB

   そうすると結果は以下のようになります:

                      H'--I'--J'  topicB
                     /
                     | E---F---G  topicA
                     |/
         A---B---C---D  master

   これは、topicBがtopicAに依存していない場合に役立ちます。

   コミットの範囲は、リベースで削除することもできます。以下の状況の場合:

         E---F---G---H---I---J  topicA

   そして、以下のコマンドを実行します

     git rebase --onto topicA~5 topicA~3 topicA

   上記を実行すると、以下のようにコミットFとGが削除されます:

         E---H'---I'---J'  topicA

   これは、 F と G に何らかの欠陥がある場合、または、topicA の一部であっ
てはならない場合に役立ちます。注意: ‘--onto’ と <upstream> パラメーター
の引数は、任意の有効なコミットっぽい何か(commit-ish)にすることができるこ
とに注意してください。

   競合が発生した場合、 ‘git rebase’ は最初の問題のあるコミットで停止し
、ツリーに競合マーカーを残します。 あなたは ‘git diff’ を使用して、マー
カー(‘<<<<<<’)を見つけ、編集して競合を解決できます。編集するファイルごと
に、競合が解決されたことをGitに通知する必要があります。通常、これは以下
の方法で行います

     git add <filename>

   競合を手動で解決し、あなたが望んだ解決策でインデックスを更新した後、
以下のコマンドでリベースプロセスを続行できます

     git rebase --continue

   あるいは、以下のように ‘git rebase’ を元に戻す(undo)こともできます

     git rebase --abort

OPTIONS
*******

‘--onto <newbase>’
     新しいコミットを作成する開始点を指定します。 ‘--onto’ オプションが
     指定されていない場合、開始点は <upstream> です。これは、既存のブラ
     ンチ名だけでなく、任意の有効なコミットである可能性があります。

     特別な場合として、マージベースが1つしかない場合は、あなたはAとBのマ
     ージベースのショートカットとして "A...B" を使用できます。最大でAと
     Bのいずれかを省略できます。その場合、デフォルトでHEADになります。

‘--keep-base’
     <upstream> の <branch> のマージベースへの新しいコミットを作成する開
     始点を設定します。 ‘git rebase --keep-base <upstream> <branch>’ を
     実行することは ‘git rebase --onto <upstream>... <upstream>’ を実行
     することと同じです。

     このオプションは、アップストリームブランチの先頭で機能を開発してい
     る場合に役立ちます。この機能が働いている間に、アップストリームのブ
     ランチが進むことがあり、アップストリームの先頭にリベースを続けるの
     は得策ではなく、ベースのコミットをそのままにしておくことがあります
     。

     このオプションと ‘--fork-point’ はどちらも <upstream> と <branch> の
     間のマージベースを検索します。しかし、このオプションは新しいコミッ
     トが作成される「開始点」としてマージベースを使用します。一方
     ‘--fork-point’ はマージベースを使用して、リベースされる「コミットの
     セット」を決定します。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

<upstream>
     比較するアップストリームブランチ。既存のブランチ名だけでなく、任意
     の有効なコミットである可能性があります。デフォルトは、現在のブラン
     チ用に構成されたアップストリームです。

<branch>
     作業するブランチ。デフォルトはHEADです。

‘--continue’
     マージの競合を解決した後、リベースプロセスを再開します。

‘--abort’
     リベース操作を中止(abort)し、HEADを元のブランチにリセットします。リ
     ベース操作の開始時に<branch>が指定された場合、HEADは<branch>にリセ
     ットされます。それ以外の場合、HEADはリベース操作が開始されたときの
     位置にリセットされます。

‘--quit’
     リベース操作を中止(abort)しますが、HEADは元のブランチにリセットされ
     ません。その結果、インデックスと作業ツリーも変更されません。
     ‘--autostash’ を使用して一時的なstashエントリが作成された場合、それ
     はstashリストに保存されます。

‘--apply’
     適用戦略(applying strategies)を使用してリベースします(内部で
     ‘git-am’ を呼び出します)。このオプションは、マージバックエンドが
     applyのすべてを処理すると、将来的には動作しなくなる可能性があります
     。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--empty={drop,keep,ask}’
     任意のアップストリームコミットの、開始時は空ではなく、かつ、クリー
     ンでは無いチェリーピックであるが、(すでにアップストリームの変更のサ
     ブセットが含まれているため、)リベース後に空になるコミットを処理する
     方法。dropを使用すると、空になるコミットはドロップされます(これがデ
     フォルトです)。keepを使用すると、そのようなコミットは保持されます。
     ask を使用すると、空のコミットが適用されるとリベースが停止し、ドロ
     ップするか、ファイルをさらに編集するか、空の変更をコミットするかを
     選択できます(‘--interactive’ の指定を含んでいます)。‘--exec’ などの
     他のオプションでは、-i / -interactiveが明示的に指定されていない限り
     、デフォルトのdropが使用されます。

     注意: (‘--no-keep-empty’ が指定されていない場合、)空で開始するコミ
     ットは保持され、(‘--reapply-cherry-picks’ が渡されない限り)準備ステ
     ップとして、( ‘git log --cherry-mark ...’ によって決定される)クリー
     ンなチェリーピックであるコミットが検出・ドロップされます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--no-keep-empty’
‘--keep-empty’
     リベースの前に空で始まるコミット(つまり、親から何も変更していないコ
     ミット)を結果に残さないようにします。 なぜなら、そのようなコミット
     を作成するには ‘git commit’ に ‘--allow-empty’ というオーバーライド
     するフラグを渡す必要があり、これはユーザーが意図的にそのようなコミ
     ットを作成し、それを保持したいことを意味しているからです。

     対話的なリベースを起動し、不要なコミットに対応する行を削除するだけ
     で、空で始まるコミットを取り除くことができるため、このフラグの使用
     はおそらくまれです。 このフラグは、外部ツールが多くの空のコミットを
     生成し、それらをすべて削除したい場合などの為の便利なショートカット
     として存在します。

     開始時は空でないが、リベース後に空になるコミットについては、
     ‘--empty’ フラグを参照してください。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--reapply-cherry-picks’
‘--no-reapply-cherry-picks’
     我先にドロップしてしまうのではなく、アップストリームコミットのすべ
     てのクリーンなチェリーピックを再適用します。 （これらのコミットがリ
     ベース後に空になった場合、それらにはすでにアップストリームの変更の
     サブセットが含まれているため、それらに対する動作は ‘–empty‘フラグに
     よって制御されます。）

     デフォルト(または ‘--no-reapply-cherry-picks’ が指定されている場合
     )では、これらのコミットは自動的にドロップされます。 これにはすべて
     のアップストリームコミットを読み取る必要があるため、読み取る必要の
     あるアップストリームコミットが多数あるリポジトリではコストがかかる
     可能性があります。 ‘merge’ バックエンドを使用する場合、（‘--quiet’
     が指定されていない限り）ドロップされたコミットごとに警告が発行され
     ます。 ‘advice.skippedCherryPicks’ がfalseに設定されていない限り、
     アドバイスも表示されます (git-config(1) を参照)。

     ‘--reapply-cherry-picks’ を使用すると、リベースはすべてのアップスト
     リームコミットの読み取りを放棄できるため、パフォーマンスが向上する
     可能性があります。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--allow-empty-message’
     何も操作しません。空のメッセージでコミットをリベースすると失敗
     (fail)しますが、このオプションはその動作をオーバーライドし、空のメ
     ッセージを含むコミットをリベースできます。つまり、空のメッセージで
     コミットしても、リベースは停止(halt)しません。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--skip’
     現在のパッチをスキップして、リベースプロセスを再開します。

‘--edit-todo’
     対話リベース中にToDoリストを編集します。

‘--show-current-patch’
     対話的なリベース、または、競合のためにリベースが停止されたときに、
     現在のパッチを表示します。 これは ‘git show REBASE_HEAD’ と同等です
     。

‘-m’
‘--merge’
     マージ戦略(merging strategies)を使用してリベースします(デフォルト
     )。

     リベースマージは、<upstream>ブランチの上にある作業ブランチからの各
     コミットをリプレイすることによって機能することに注意してください。
     このため、マージの競合が発生した場合、 ‘ours’ として報告される側は
     、<upstream>で始まるこれまでのリベースされたシリーズであり、
     ‘theirs’ は作業ブランチです。 つまり、サイドが入れ替わっています。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘-s <strategy>’
‘--strategy=<strategy>’
     デフォルトの ‘ort’ の代わりに、指定のマージ戦略を使用します。 この
     オプションは ‘--merge’ の指定を含んでいます。

     ‘git rebase’ は、指定された戦略を使用して<upstream>ブランチの上にあ
     る作業ブランチからの各コミットをリプレイするため、 ‘ours’ 戦略を使
     用すると、<branch>からすべてのパッチが空になります。これはほとんど
     意味がありません。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘-X <strategy-option>’
‘--strategy-option=<strategy-option>’
     <strategy-option>をマージ戦略に渡します。 これは ‘--merge’ の指定を
     含んでいて、戦略が指定されていない場合は ‘-s ort’ を意味します。
     ‘-m’ オプションにて上記で述べたように、「ours」と「theirs」が逆にな
     っていることに注意してください。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--rerere-autoupdate’
‘--no-rerere-autoupdate’
     可能であれば、rerereメカニズムが自動競合解決の結果でインデックスを
     更新できるようにします。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     GPG署名コミットです。 ‘keyid’ 引数はオプションであり、デフォルトで
     コミッターIDになります。 指定する場合は、スペースなしでオプションに
     串刺しする必要があります。 ‘--no-gpg-sign’ は、‘commit.gpgSign’ 構
     成変数と、それより前で指定した ‘--gpg-sign’ オプションの、その両方
     を打ち消すのに役立ちます。

‘-q’
‘--quiet’
     静かにします。‘--no-stat’ の指定を含みます。

‘-v’
‘--verbose’
     おしゃべりにします。 ‘--stat’ の指定を含みます。

‘--stat’
     最後のリベース以降にアップストリームで変更されたもののdiffstatを表
     示します。 diffstatは、構成オプション rebase.stat によっても制御さ
     れます。

‘-n’
‘--no-stat’
     リベース処理の一部としてdiffstatを表示しないでください。

‘--no-verify’
     このオプションは、リベース前のフック(pre-rebase hook)をバイパスしま
     す。 githooks(5) も参照してください。

‘--verify’
     リベース前フック(pre-rebase hook)の実行を許可します。これがデフォル
     トです。このオプションは、 ‘--no-verify’ をオーバーライドするために
     使用できます。 githooks(5) も参照してください。

‘-C<n>’
     各変更の前後で、少なくとも <n> 行の周囲のコンテキストが一致すること
     を確認する。 周囲の文脈の行数が少ない場合は、すべて一致させなければ
     ならない。 デフォルトでは、コンテキストは無視されます。 ‘--apply’ の
     指定を含んでいます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--no-ff’
‘--force-rebase’
‘-f’
     変更されていないコミットを早送りす(fast-forward)るのではなく、リベ
     ースされたすべてのコミットを個別にリプレイします。これにより、リベ
     ースされたブランチの履歴全体が新しいコミットで構成されることが保証
     されます。

     トピックブランチのマージを取り消した後にこのオプションを使うと便利
     です。このオプションはトピックブランチを新しいコミットで再作成する
     ので、「戻しを戻す」(revert the reversion)必要はありません (詳細は
     revert-a-faulty-merge How-To (howto/revert-a-faulty-merge.html) を
     ご覧ください)。

‘--fork-point’
‘--no-fork-point’
     <branch>によって導入されたコミットを計算するときに、reflogを使用し
     て、<upstream>と<branch>の間の、より一般的な祖先を見つけます。

     ‘--fork-point’ がアクティブな場合、<upstream>の代わりに
     ‘fork_point’ を使用して、リベースするコミットのセットを計算します。
     ここで、 ‘fork_point’ は、 ‘git merge-base --fork-point <upstream>
     <branch>’ コマンドの結果です（git-merge-base(1) 参照）。
     ‘fork_point’ が空になると、<upstream>がフォールバックとして使用され
     ます。

     コマンドラインで<upstream>が指定されている場合、デフォルトは
     ‘--no-fork-point’ です。それ以外の場合、デフォルトは ‘--fork-point’
     です。

     あなたのブランチが<upstream>に基づいていたが、<upstream>が巻き戻さ
     れ、あなたのブランチにドロップされたコミットが含まれている場合、あ
     なたのブランチからそれらのコミットをドロップするために、このオプシ
     ョンを ‘--keep-base’ とともに使用できます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--ignore-whitespace’
     差分を調整しようとするときは、空白の違いを無視してください。現在、
     各バックエンドはこの振る舞いの近似を実装しています:

     applyバックエンド: パッチを適用するときは、コンテキスト行の空白
     (whitespace)の変更を無視してください。残念ながら、これは、パッチに
     よって置き換えられる「古い」行が既存のファイルと空白(whitespace)の
     みが異なる場合、パッチアプリケーションが成功する代わりに、マージの
     競合が発生することを意味します。

     mergeバックエンド: 空白(whitespace)のみが変更された行は、マージ時に
     変更されていないものとして扱います。残念ながら、これは、反対側に競
     合する変更がなかったとしても、空白(whitespace)を変更することを目的
     としたパッチハンクがドロップされることを意味します。

‘--whitespace=<option>’
     このフラグは、パッチを適用する ‘git apply’ プログラム(git-apply(1)
     参照)に渡されます。 ‘--apply’ の指定を含んでいます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--committer-date-is-author-date’
     現在の時刻をコミッターの日付として使用する代わりに、リベースされる
     コミットの作成者の日付をコミッターの日付として使用します。このオプ
     ションは、 ‘--force-rebase’ の指定を含んでいます。

‘--ignore-date’
‘--reset-author-date’
     元のコミットの作成者の日付を使用する代わりに、現在の時刻をリベース
     されたコミットの作成者の日付として使用します。 このオプションは、
     ‘--force-rebase’ の指定を含んでいます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--signoff’
     すべてのリベースされたコミットに ‘Signed-off-by’ トレーラーを追加し
     ます。注意: ‘--interactive’ が指定されている場合、pick または edit
     または reword のマークが付けられたコミットのみにトレーラーが追加さ
     れることに注意してください。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘-i’
‘--interactive’
     リベースされようとしているコミットのリストを作成します。リベースす
     る前に、ユーザーにそのリストを編集させます。このモードは、コミット
     の分割にも使用できます（以下の「SPLITTING COMMITS」を参照）。

     コミットリストの書式は、構成オプション rebase.instructionFormat を
     設定することで変更できます。カスタマイズされた命令書式では、書式の
     前に長いコミットハッシュが自動的に追加されます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘-r’
‘--rebase-merges[=(rebase-cousins|no-rebase-cousins)]’
     デフォルトでは、リベースはtodoリストからマージコミットを削除し、リ
     ベースされたコミットを単一の線形ブランチに配置します。
     ‘--rebase-merges’ を使用すると、リベースは代わりに、マージコミット
     を再作成することにより、リベースされるコミット内の分岐構造を保持し
     ようとします。これらのマージコミットで解決されたマージの競合または
     手動の修正(amend)は、手動で 解決/再適用 する必要があります。

     デフォルト、または ‘no-rebase-cousins’ が指定された場合、直接の祖先
     として ‘<upstream>’ を持たないコミットは元の分岐点を保持します。つ
     まり、 git-log(1) の ‘--ancestry-path’ オプションによって除外される
     コミットは、デフォルトで元の祖先を保持します。 ‘rebase-cousins’ モ
     ードがオンになっている場合、そのようなコミットは代わりに
     ‘<upstream>’ （または指定されている場合は ‘<onto>’ ）にリベースされ
     ます。

     ‘--rebase-merges’ モードは、非推奨の ‘--preserve-merges’ と考え方は
     似ていますが、こちらは、コミットを自由に並べ替え、挿入、削除できる
     対話的リベースで機能します。

     現在、 ‘ort’ マージ戦略を使用してのみマージコミットを再作成すること
     が可能です。異なるマージ戦略は、明示的な ‘exec git merge -s
     <strategy> [...]’ コマンドを介してのみ使用できます。

     下記の「REBASING MERGES」と「INCOMPATIBLE OPTIONS」も参照してくださ
     い。

‘-p’
‘--preserve-merges’
     [非推奨: 代わりに ‘--rebase-merges’ を使用してください]マージコミッ
     トによって導入されたコミットをリプレイして履歴をフラット化するので
     はなく、マージコミットを再作成します。マージの競合解決またはマージ
     コミットの手動修正は保持されません。

     これは内部で ‘--interactive’ 機構を使用しますが、これを ‘
     –interactive‘ オプションと明示的に組み合わせることは、あなた自身が
     何をしているのかを理解していない限り、一般的には良い考えではありま
     せん(下記 BUGS 参照)。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘-x <cmd>’
‘--exec <cmd>’
     最終履歴にコミットを作成する各行の後に ‘exec <cmd>’ を追加します。
     <cmd> は、1つ以上のシェルコマンドとして解釈されます。 失敗したコマ
     ンドは、終了コード1でリベースを中断(interrupt)します。

     ‘--exec’ の1つのインスタンスを複数のコマンドで使用することにより、
     複数のコマンドを実行できます:

          git rebase -i --exec "cmd1 && cmd2 && ..."

     または、複数の ‘--exec’ を指定します:

          git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

     ‘--autosquash’ が使用されている場合、 ‘exec’ 行は中間コミットに追加
     されず、各 squash/fixup シリーズの最後にのみ現れます。

     これは内部で ‘--interactive’ 機構を使用しますが、明示的な
     ‘--interactive’ の指定なしで実行できます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--root’
     <upstream>で制限するのではなく、<branch>から到達可能なすべてのコミ
     ットをリベースします。 これにより、ブランチのルートコミットをリベー
     スできます。 ‘--onto’ と一緒に使用すると、（<upstream>ではなく、）
     <newbase>にすでに含まれている変更をスキップしますが、 ‘--onto’ を使
     用しない場合は、すべての変更に対して機能します。 ‘--onto’ と
     ‘--preserve-merges’ の両方と一緒に使用すると、「すべての」ルートコ
     ミットは、代わりに<newbase>を親として持つように書き直されます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--autosquash’
‘--no-autosquash’
     コミットログメッセージが「squash!  …」または「fixup!  …」または「
     amend!  …」で始まり、同一の ‘...’ に一致するコミットがすでにtodoリ
     ストにある場合、 ‘rebase -i’ のtodoリストを自動的に変更して、
     squashするようにマークされたコミットが、変更するコミットの直後に来
     るようにし、移動したコミットのアクションをそれぞれ ‘pick’ から、
     ‘squash’ または ‘fixup’ または ‘fixup-C’ に変更します。 コミットの
     件名が一致する場合、または ‘...’ がコミットのハッシュを参照する場合
     、コミットは ‘...’ と一致します。フォールバックとして、コミットサブ
     ジェクトの部分一致も機能します。 fixup/amend/squash コミットを作成
     するための推奨される方法は、 git-commit(1) のそれぞれ ‘--fixup’ ま
     たは ‘--fixup=amend:’ または ‘--fixup=reword:’ と、‘--squash’ オプ
     ションを使用することです。

     構成変数 ‘rebase.autoSquash’ を使用して ‘--autosquash’ オプションが
     デフォルトで有効になっている場合、このオプションを使用して、この設
     定をオーバーライドおよび無効にすることができます。

     下記の「INCOMPATIBLE OPTIONS」(互換性のないオプション)も参照してく
     ださい。

‘--autostash’
‘--no-autostash’
     操作を開始する前に一時的なスタッシュエントリを自動的に作成し、操作
     の終了後に適用します。これは、汚れたワークツリー(dirty worktree)で
     リベースを実行できることを意味します。ただし、注意して使用してくだ
     さい。リベースが成功した後の最後のスタッシュアプリケーションは、重
     要な競合を引き起こす可能性があります。

‘--reschedule-failed-exec’
‘--no-reschedule-failed-exec’
     失敗した ‘exec’ コマンドを自動的に再スケジュールします。 これは、対
     話モード(または ‘--exec’ オプションが提供された場合)でのみ意味があ
     ります。

     このオプションは、リベースが開始されると適用されますが、これは、
     ‘rebase.rescheduleFailedExec’ 構成(git-config(1) または 下記「
     CONFIGURATION」参照)、またはこのオプションが提供されているかどうか
     に基づいて、最初にリベース全体に設定されます。でなければ、開始時の
     明示的な ‘--no-reschedule-failed-exec’ が、
     ‘rebase.rescheduleFailedExec=true’ 構成の存在によって上書きされます
     。

INCOMPATIBLE OPTIONS(互換性の無いオプション)
********************************************

これらのオプション:

   • ‘--apply’

   • ‘--whitespace’

   • ‘-C’

   は、以下のオプションと互換性がありません:

   • ‘--merge’

   • ‘--strategy’

   • ‘--strategy-option’

   • ‘--allow-empty-message’

   • ‘--[no-]autosquash’

   • ‘--rebase-merges’

   • ‘--preserve-merges’

   • ‘--interactive’

   • ‘--exec’

   • ‘--no-keep-empty’

   • ‘--empty=’

   • ‘--reapply-cherry-picks’

   • ‘--edit-todo’

   • ‘--root’ 。‘--onto’ と組み合わせて使用する場合。

   さらに、以下のオプションの組み合わせには互換性がありません:

   • ‘--preserve-merges’ と ‘--interactive’

   • ‘--preserve-merges’ と ‘--signoff’

   • ‘--preserve-merges’ と ‘--rebase-merges’

   • ‘--preserve-merges’ と ‘--empty=’

   • ‘--preserve-merges’ と ‘--ignore-whitespace’

   • ‘--preserve-merges’ と ‘--committer-date-is-author-date’

   • ‘--preserve-merges’ と ‘--ignore-date’

   • ‘--keep-base’ と ‘--onto’

   • ‘--keep-base’ と ‘--root’

   • ‘--fork-point’ と ‘--root’

BEHAVIORAL DIFFERENCES(振る舞いの違い)
**************************************

git rebaseには、applyとmergeの2つの主要なバックエンドがあります。 （
applyバックエンドは以前は amバックエンド と呼ばれていましたが、名前は名
詞ではなく動詞のように見えるため混乱を招きました。また、mergeバックエン
ドは以前は interactiveバックエンド と呼ばれていましたが、現在は 非対話型
の場合にも使用されます。どちらも、それぞれを支える低レベルの機能に基づい
て名前が変更されました。）これら2つのバックエンドの振る舞いには微妙な違
いがあります:

空のコミット
============

applyバックエンドは、残念ながら意図的に空のコミット、つまり空で開始され
たコミットを削除しますが、これらは実際にはまれです。また、空になるコミッ
トを削除したり、その振る舞いを制御するオプションがありません。

   mergeバックエンドは、デフォルトで意図的に空のコミットを保持します(た
だし、 ‘-i’ を使用すると、todoリストエディタでemptyとしてマークされます
。または、 ‘--no-keep-empty’ を使用して自動的に削除できます）。

   適用バックエンドと同様に、デフォルトでは、mergeバックエンドは、
‘-i/--interactive’ が指定されていない限り、空になるコミットをドロップし
ます(この場合、mergeバックエンドは停止(stop)し、ユーザーに何をすべきかを
尋ねます)。mergeバックエンドには、空になったコミットの処理動作を変更する
ための ‘--empty={drop,keep,ask}’ オプションもあります。

ディレクトリ名変更の検知
========================

正確なツリー情報が不足している(パッチで利用可能な限られた情報で偽の祖先
を構築するために生じる)ため、applyバックエンドでディレクトリ名変更の検出
が無効になっています。ディレクトリ名前変更の検出が無効になっているという
ことは、履歴の一方がディレクトリの名前を変更し、もう一方が古いディレクト
リに新しいファイルを追加した場合に、リベース時にこれらのファイルを新しい
ディレクトリに移動したいという警告なしに、新しいファイルが古いディレクト
リに残されます。

   ディレクトリ名変更の検出は、マージバックエンドと連携して、このような
場合に警告を出します。

Context
=======

適用バックエンドは、（内部で ‘format-patch’ を呼び出すことにより、）パッ
チのシーケンスを作成し、次にパッチを順番に適用することにより（内部で
‘am’ を呼び出すことにより）機能します。パッチは複数のハンクで構成されて
おり、それぞれに行番号、コンテキストリージョン、および実際の変更が含まれ
ています。反対側がファイルの前に行を挿入または削除した可能性があるため、
行番号はある程度曖昧にする必要があります。コンテキスト領域(context
region)は、正しい行に変更を適用するために行番号を調整する方法を見つける
のに役立つことを目的としています。ただし、コードの複数の領域に同じ周囲の
コンテキスト行がある場合、間違った領域が選択される可能性があります。これ
により、競合が報告されずにコミットが誤って再適用される実際のケースがあり
ます。diff.contextをより大きな値に設定すると、このようなタイプの問題を防
ぐことができますが、誤った競合の可能性が高くなります（適用するには、一致
するコンテキストの行がより多く必要になるため）。

   mergeバックエンドは、関連する各ファイルの完全なコピーを使って動作し、
これらの種類の問題からファイルを保護します。

Labelling of conflicts markers
==============================

コンテンツの競合がある場合、マージ機構は、コンテンツが由来するコミットで
それぞれの側の競合マーカーに注釈を付けようとします。applバックエンドは、
リベースされたコミットとその親に関する元の情報を削除するため(代わりに、
生成されたパッチの限られた情報に基づいて新しい偽のコミットを生成します
)、それらのコミットを識別できません。 代わりに、コミットの要約にフォール
バックする必要があります。また、 merge.conflictStyle が diff3 に設定され
ている場合、applyバックエンドは「構築されたマージベース」を使用してマー
ジベースのコンテンツにラベルを付けるため、マージベースのコミットに関する
情報は一切提供されません。

   マージバックエンドは、履歴の両側で完全なコミットで動作するため、その
ような制限はありません。

フック
======

applyバックエンドは従来、コミット後フック(post-commit hook)を呼び出して
いませんでしたが、mergeバックエンドは呼び出していました。mergeバックエン
ドはその出力を黙らせましたが、いまだ両方ともチェックアウト後フック
(post-checkout hook)を呼び出します。さらに、両方のバックエンドは、中間コ
ミットや最終コミットではなく、リベースの開始点コミットでのみチェックアウ
ト後フック(post-checkout hook)を呼び出します。いずれの場合も、これらのフ
ックの呼び出しは、そう設計したのではなく、実装の偶然によるものでした(両
方のバックエンドは元々シェルスクリプトとして実装されており、フックを呼び
出す ‘git checkout ` や `git commit’ などの他のコマンドをたまたま呼び出
していました)。どちらが正しいかは完全には明らかではありませんが、両方の
バックエンドの動作は同じであるべきです。将来的には、リベースがこれらのフ
ックのいずれかを呼び出すのを停止する可能性があります。

Interruptability(割り込み可能性)
================================

applyバックエンドには、タイミングの悪い割り込みによる安全上の問題があり
ます。ユーザーが間違ったタイミングで Ctrl-C を押してリベースを中止しよう
とすると、リベースは、後続の ‘git rebase --abort’ で中止できない状態にな
る可能性があります。mergeバックエンドには、同様の欠点は見られません。(詳
細については、
https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/
(https://lore.kernel.org/git/20200207132152.GC2868@szeder.dev/) を参照し
てください。)

Commit Rewording
================

リベース中に競合が発生すると、リベースが停止(stop)し、ユーザーに解決を求
めます。 ユーザーは競合の解決中に注目すべき変更を加える必要がある場合が
あるため、競合が解決され、ユーザーが ‘git rebase --continue’ を実行した
後、リベースはエディターを開き、ユーザーにコミットメッセージを更新するよ
うに依頼する必要があります。 mergeバックエンドはこれを行いますが、
applyバックエンドは元のコミットメッセージを盲目的に適用します。

Miscellaneous differences
=========================

ほとんどの人がおそらく取るに足らないと考えるであろうが、完全性のために言
及されているいくつかの振る舞いの違いがあります:

   • Reflog: 2つのバックエンドは、reflogで行われた変更を説明するときに異
     なる表現を使用しますが、どちらも「リベース」という単語を使用します
     。

   • 進行状況、情報、エラーメッセージ について: 2つのバックエンドは、わ
     ずかに異なる進行状況と情報メッセージを提供します。また、applyバック
     エンドはエラーメッセージ（「Your files would be overwritten…」など
     ）をstdoutに書き込み、mergeバックエンドはそれらをstderrに書き込みま
     す。

   • 状態ディレクトリ: 2つのバックエンドは、 ‘.git/’ の下の異なるディレ
     クトリに状態を保持します

MERGE STRATEGIES
****************

マージ機構(‘git merge’ と ‘git pull’ コマンド)では、バックエンドの「マー
ジ戦略」を ‘-s’ オプションで選択することができます。 いくつかの戦略では
、独自のオプションを指定することができます。これは、 ‘git merge’ や ‘git
pull’ に ‘-X<option>’ 引数として渡すことができます。

ort
     これは、1つのブランチをプルまたはマージするときのデフォルトのマージ
     戦略です。この戦略では、3方向マージアルゴリズムを使用して2つのヘッ
     ドのみを解決できます。3方向マージに使用できる共通の祖先が複数ある場
     合は、共通の祖先のマージされたツリーを作成し、それを3方向のマージの
     参照ツリーとして使用します。これにより、Linux 2.6カーネルの開発履歴
     から取得した実際のマージコミットで実行されたテストによって、誤った
     マージを引き起こすことなく、マージの競合が少なくなることが報告され
     ています。さらに、この戦略では、名前の変更を伴うマージを検出して処
     理できます。検出されたコピーは使用しません。このアルゴリズムの名前
     は "Ostensibly Recursive’s Twin" (表面上は再帰の双子)の頭文字を取っ
     たものであり、以前のデフォルトのアルゴリズムである「recursive」の代
     わりとして作成されたという事実に由来しています。

     ‘ort’ 戦略は、以下のオプションを取ることができます:

     ours
          このオプションは、「our」バージョンを優先することにより、競合
          するハンクをクリーンに自動解決するように強制します。 our側と競
          合しない他のツリーからの変更は、マージ結果に反映されます。 バ
          イナリファイルの場合、内容全体がour側から取得されます。

          これを「ours」マージ戦略と混同しないでください。この戦略では、
          他のツリーに何が含まれているのかさえまったく調べません。それは
          他のツリーが行ったすべてを破棄し、「our」履歴にはその中で起こ
          ったすべてが含まれていると宣言します。

     theirs
          これは「ours」の反対です。 「ours」とは異なり、このmergeオプシ
          ョンを混同する「theirs」マージ戦略はないことに注意してください
          。

     ignore-space-change
     ignore-all-space
     ignore-space-at-eol
     ignore-cr-at-eol
          指示されたタイプの空白(whitespace)の変更を含む行を、3方向マー
          ジのために変更されていないものとして扱います。行に対する、他の
          変更と空白(whitespace)の変更との混合は、無視されません。
          git-diff(1) の ‘-b’ と ‘-w’ と ‘--ignore-space-at-eol’ と
          ‘--ignore-cr-at-eol’ も参照してください。

             • 「their」バージョンが行に空白の変更のみを導入する場合、「
               our」バージョンが使用されます。

             • 「our」バージョンで空白の変更が導入されたが、「their」バ
               ージョンに大幅な変更が含まれている場合は、「their」バージ
               ョンが使用されます。

             • それ以外の場合、マージは通常の方法で進行します。

     renormalize
          これにより、3方向マージを解決するときに、ファイルの3つのステー
          ジすべての仮想チェックアウトとチェックインが実行されます。この
          オプションは、ブランチをさまざまなクリーンフィルターまたは行末
          正規化ルールとマージするときに使用することを目的としています。
          詳細については、 gitattributes(5) の「Merging branches with
          differing checkin/checkout attributes」(チェックイン/チェック
          アウト属性が異なるブランチのマージ)を参照してください。

     no-renormalize
          ‘renormalize’ オプションを無効にします。 これは、
          ‘merge.renormalize’ 構成変数をオーバーライドします。

     find-renames[=<n>]
          名前変更(rename)の検出をオンにし、オプションで類似性のしきい値
          (similarity threshold)を設定します。これがデフォルトです。 こ
          れは、 ‘merge.renames’ 構成変数をオーバーライドします。
          git-diff(1) の ‘--find-renames’ も参照してください。

     rename-threshold=<n>
          ‘find-renames=<n>’ の非推奨の同義語。

     subtree[=<path>]
          このオプションは「subtree」戦略をさらに発展させたもので、2つの
          木をマージする際に、どのようにずらせば互いにマッチするかを推測
          するものである。その代わり、指定されたパスは、2つの木の形が一
          致するように前置される(または、最初から取り除かれる)。

recursive
     これは、3方向マージアルゴリズムを使用して2つのヘッドのみを解決でき
     ます。3方向マージに使用できる共通の祖先が複数ある場合は、共通の祖先
     のマージされたツリーを作成し、それを3方向のマージの参照ツリーとして
     使用します。 これにより、Linux 2.6カーネルの開発履歴から取得した実
     際のマージコミットで実行されたテストによって、誤ったマージを引き起
     こすことなく、マージの競合が少なくなることが報告されています。 さら
     に、これにより、名前変更を含むマージを検出して処理できます。 検出さ
     れたコピーは使用しません。 これは、Git v0.99.9k 〜 v2.33.0 まで、
     2つのヘッドを解決するためのデフォルトの戦略でした。

     「recursive」(再帰的)戦略は「ort」と同じオプションを取る。 しかし、
     「ort」が無視する3つのオプション(上記には書かれていない)があり、 「
     recursive」戦略で有用となる可能性がある:

     patience
          ‘diff-algorithm=patience’ の非推奨の同義語。

     diff-algorithm=[patience|minimal|histogram|myers]
          マージ中に別の差分アルゴリズムを使用すると、重要でない一致行
          (異なる関数の中括弧など)が原因で発生するミスマージを回避できま
          す。 git-diff(1) ‘--diff-algorithm’ も参照してください。注意:
          特に、「ort」は ‘diff-algorithm=histogram’ を使用しますが、「
          recursive」はデフォルトで 「diff.algorithm」 設定を使う事に注
          意して下さい。

     no-renames
          名前変更(rename)の検出をオフにします。 これは、‘merge.renames’
          構成変数をオーバーライドします。 git-diff(1) の ‘--no-renames’
          も参照してください。

resolve
     これは、3方向マージアルゴリズムを使用して、2つのヘッド（つまり、現
     在のブランチとプルした別のブランチ）のみを解決できます。 交差マージ
     (criss-cross merge)のあいまいさを注意深く検出しようとします。 名前
     の変更は処理しません。

octopus
     これにより、3つ以上のヘッドを持つケースが解決されますが、手動解決が
     必要な複雑なマージの実行は拒否されます。これは主に、トピックの分岐
     ヘッドを纏めるために使用されることを意図しています。これは、複数の
     ブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

ours
     これにより、任意の数のヘッドが解決されますが、結果として得られるマ
     ージのツリーは常に現在のブランチヘッドのツリーであり、他のすべての
     ブランチからのすべての変更を事実上無視します。 これは、サイドブラン
     チの古い開発履歴に取って代わるために使用されることを意図しています
     。 これは、「recursive」マージ戦略の ‘-Xours’ オプションとは異なる
     ことに注意してください。

subtree
     これは改造された「ort」戦略です。 ツリーAとBをマージするとき、Bが
     Aのサブツリーに対応する場合、同じレベルのツリーを読み取るのではなく
     、Bは最初にAのツリー構造に一致するように調整されます。 この調整は、
     共通の祖先ツリーに対しても行われます。

   3方向マージ(デフォルトの「ort」を含む)を使用する戦略では、両方のブラ
ンチで変更が行われたが、後で一方のブランチで元に戻された場合、その変更は
マージされた結果に表示されます。一部の人々は、この振る舞いを混乱させると
感じています。これは、個々のコミットではなく、ヘッドとマージベースのみが
マージの実行時に考慮されるために発生します。したがって、マージアルゴリズ
ムは、元に戻された変更をまったく変更なしと見なし、代わりに変更されたバー
ジョンに置き換えます。

NOTES
*****

あなたは共有リポジトリで ‘git rebase’ を使用することの意味を理解する必要
があります。下記「RECOVERING FROM UPSTREAM REBASE」も参照してください。

   git-rebase コマンドを実行すると、最初にリベース前フック(pre-rebase
hook)が存在する場合はそれが実行されます。このフックを使用して、健全性チ
ェックを実行し、適切でない場合はリベースを拒否できます。例については、テ
ンプレートの pre-rebase hook スクリプトを参照してください。

   完了すると、<branch>が現在のブランチになります。

INTERACTIVE MODE
****************

対話的にリベースするということは、あなたがリベースされるコミットを編集す
る機会があることを意味します。コミットを並べ替えたり、削除したりできます
(不良パッチやその他の不要なパッチを削除します)。

   対話モードは、以下のタイプの作業フローを対象としています:

  1. 素晴らしいアイデアを思いついた

  2. コードをハックハック

  3. 提出用のシリーズを準備

  4. 送信

   ここで、 (2) は以下のいくつかの作業で構成されています

   a) 普段

  1. コミットに値する何かを終える

  2. コミットする

   b) 独立した修正

  1. 何かが機能しないことに気付く

  2. そいつを修正

  3. それをコミットする

   bの(2) で修正したコミットがパッチシリーズの中に深く埋もれているために
、完全ではないコミットに戻せない(amend)ことがあります。これこそが対話型
リベースの目的です。たくさんの "a" と "b" の後に、コミットを並べ替えたり
編集したり、複数のコミットをひとつにまとめたりするために使用します。

   そのまま保持したい最後のコミットから開始します:

     git rebase -i <after-this-commit>

   エディターは、あなたの現在のブランチのすべてのコミット(マージコミット
は無視)で起動されます。これは、指定のコミットの後に発生します。あなたは
、このリストのコミットを心ゆくまで並べ替えたり、削除したりできます。そし
て、リストは多かれ少なかれ以下のようになります:

     pick deadbee The oneline of this commit
     pick fa1afe1 The oneline of the next commit
     ...

   1行説明は、純粋にあなたの備忘のためです。 ‘git rebase’ はそれらを参照
せず、コミット名（この例では "deadbee" と "fa1afe1" ）を参照するため、名
前を削除または編集しないでください。

   コマンド「pick」をコマンド「edit」に置き換えることで、 ‘git rebase’ に
そのコミットを適用した後に停止(stop)するように指示できます。これにより、
あなたはファイルやコミットメッセージを編集し、コミットを修正(amend)して
、リベースを続行できます。

   リベースを中断するには(‘edit’ コマンドと同様、ただし最初にコミットを
選択せずに)、 ‘break’ コマンドを使用します。

   あなたがコミットのコミットメッセージを編集したいだけの場合は、コマン
ド ‘pick’ をコマンド ‘reword’ に置き換えます。

   コミットを削除するには、コマンド ‘pick’ を ‘drop’ に置き換えるか、あ
るいはマッチする行を削除します。

   2つ以上のコミットを1つにまとめる場合は、2番目以降のコミットのコマンド
pick を squash または fixup に置き換えます。コミットに異なる作者がいた場
合、折りたたまれたコミットは最初のコミットの作者に帰属します。折りたたま
れたコミットに対して推奨されるコミットメッセージは、最初のコミットのメッ
セージと squash コマンドで識別されるメッセージを連結したもので、 ‘fixup
-c’ が使用されていない限り、fixupコマンドで識別されるコミットのメッセー
ジは省略されます。‘fixup -c’ が使用された場合、提案されたコミットメッセ
ージは ‘fixup -c’ コミットのメッセージのみであり、エディタが開いてメッセ
ージを編集できます。 ‘fixup -c’ コミットの内容(パッチ)は、折りたたまれた
コミットに引き続き組み込まれます。 ‘fixup -c’ コミットが複数ある場合は、
最後のコミットからのメッセージが使用されます。あなたは ‘fixup -C’ を使用
して、エディターを開かないことを除いて ‘fixup -c’ と同じ動作をさせること
もできます。

   「git rebase」は、 pick が edit に置き換えられたとき、またはマージエ
ラーのためにコマンドが失敗したときに停止(stop)します。 競合の編集や解決
が完了したら、 あなたは ‘git rebase --continue’ で続行できます。

   たとえば、最後の5つのコミットを並べ替えて、 HEAD~4 であったものが新し
いHEADになるようにします。これを実現するには、以下のように「git rebase」
を呼び出します:

     $ git rebase -i HEAD~5

   そして、最初のパッチをリストの最後に移動します。

   たとえば、あなたが以下のような履歴を持っているなら、マージコミットを
再作成することをお勧めします:

                X
                 \
              A---M---B
             /
     ---o---O---P---Q

   あなたは A から Q までのブランチをリベースしたいとします。現在の
HEADが B であることを確認して、以下を実行します

     $ git rebase -i -r --onto Q O

   コミットの並べ替えと編集は通常、テストされていない中間ステップを作成
します。テストを実行するか、少なくとも「exec」コマンド(ショートカット「
x」)を使用して履歴の中間ポイントで再コンパイルすることにより、履歴の編集
で何も壊れていないことを確認することをお勧めします。これを行うには、以下
のようなToDoリストを作成します:

     pick deadbee Implement feature XXX
     fixup f1a5c00 Fix to feature XXX
     exec make
     pick c0ffeee The oneline of the next commit
     edit deadbab The oneline of the commit after
     exec cd subdir; make test
     ...

   コマンドが失敗すると（つまり、0以外のステータスで終了すると）、対話的
リベースが停止(stop)し、あなたには問題を修正する機会が与えられます。あな
たは ‘git rebase --continue’ で続行できます。

   「exec」コマンドは、シェル(‘$SHELL’ で指定されたもの、または ‘$SHELL’
が設定されていない場合はデフォルトのシェル)でコマンドを起動するため、シ
ェル機能("cd"、">"、";" など)を使用できます。コマンドは、作業ツリーのル
ートから実行されます。

     $ git rebase -i --exec "make test"

   このコマンドを使用すると、あなたは中間コミット(intermediate commits)が
コンパイル可能であることを確認できます。ToDoリストは以下のようになります
:

     pick 5928aea one
     exec make test
     pick 04d0fda two
     exec make test
     pick ba46169 three
     exec make test
     pick f4593f9 four
     exec make test

SPLITTING COMMITS
*****************

対話モードでは、アクション「edit」でコミットをマークできます。 ただし、
これは必ずしも「git rebase」がこの編集の結果が正確に1つのコミットである
ことを期待していることを意味するわけではありません。 実際、あなたはコミ
ットを元に戻す(undo)ことも、他のコミットを追加することもできます。そして
これは、コミットを2つに分割するために使用できます:

   • ‘git rebase -i <commit> ^’ を使用して対話的リベースを開始します。こ
     こで、<commit> はあなたが分割したいコミットです。 実際、そのコミッ
     トが含まれている限り、どんなコミット範囲でもかまいません。

   • あなたが分割したいコミットを、 アクション ‘edit’ でマークします。

   • そのコミットを編集する場合は、 ‘git reset HEAD^’ を実行します。 そ
     の効果は、HEADが1つ巻き戻され、インデックスがそれに追随することです
     。 ただし、作業ツリーは同じままです。

   • 次に、最初のコミットで必要な変更をインデックスに追加します。 これを
     行うには、 （おそらく対話的に）‘git add’ を使うかまたは _git gui_ を
     使うか（、またはこの両方を使うか)できます。

   • 最新の適切なコミットメッセージを使用して、最新の「現在のインデック
     ス」をコミットします。

   • 作業ツリーがクリーンになるまで、最後の2つの手順を繰り返します。

   • ‘git rebase --continue’ でリベースを続行します。

   あなたが中間リビジョンの一貫性(コンパイル、テストスイートの合格など
)が完全には分からない場合は、「git stash」を使用して、各コミット後にまだ
コミットされていない変更を隠し、修正が必要な場合はコミットをテストして修
正する必要があります。

RECOVERING FROM UPSTREAM REBASE
*******************************

他の人がベースにしているブランチをリベースする (あるいは他の形で書き換え
る) のは悪い考えです。そのブランチの下流の人は、自分の履歴を手動で修正す
ることを余儀なくされます。 このセクションでは、下流側の視点から見た修正
の方法を説明します。 しかし、本当の意味での修正は、そもそも上流のリベー
スを行わないことです。

   説明のために、誰かが「subsystem」ブランチを開発し、この「subsystem」
に依存する「topic」に取り組んでいる状況にあると仮定します。たぶん以下の
ような履歴です:

         o---o---o---o---o---o---o---o  master
              \
               o---o---o---o---o  subsystem
                                \
                                 *---*---*  topic

   ‘subsystem’ が ‘master’ に対してリベースされる場合、以下が発生します:

         o---o---o---o---o---o---o---o  master
              \                       \
               o---o---o---o---o       o'--o'--o'--o'--o'  subsystem
                                \
                                 *---*---*  topic

   これで、あなたは通常どおり開発を続行し、最終的に ‘topic’ を
‘subsystem’ にマージすると、 以下のように、 ‘subsystem’ からのコミットは
永久に複製されたままになります:

         o---o---o---o---o---o---o---o  master
              \                       \
               o---o---o---o---o       o'--o'--o'--o'--o'--M  subsystem
                                \                         /
                                 *---*---*-..........-*--*  topic

   このような重複は、履歴が乱雑になり、追跡が困難になるため、一般的に眉
をひそめられる行為です。これをクリーンアップするには、「topic」のコミッ
トを新しい「subsystem」の先端に移植する必要があります。つまり、「topic」
をリベースする必要があります。これは影響が波及します。「topic」の下流に
いる人もリベースを余儀なくされます！

   2種類の修正パターン(簡単な場合と難しい場合)があります。以下のサブセク
ションで議論します:

簡単な場合: 変更は文字通り同じ(same)
     これは、 ‘subsystem’ のリベースが単純なリベースであり、競合がなかっ
     た場合に発生します。

難しい場合: 変更は同じではありません
     これは、「subsystem」のリベースで競合が発生した場合、または
     ‘--interactive’ を使用してコミットを省略(omit)、edit、squash、
     fixupした場合に発生します。または、アップストリームで ‘commit
     --amend’ や、 ‘reset’ や、 ‘filter-repo’
     (https://github.com/newren/git-filter-repo) のような完全な履歴書き
     換えコマンドのいずれかを使用した場合に発生します。

簡単な場合
==========

‘subsystem’ の変更点(diffの内容に基づくパッチID)がリベース ‘subsystem’ の
前と後で文字通り同じである場合にのみ動作します。

   その場合、 ‘git rebase’ は新しいアップストリームにすでに存在する変更
をスキップすることを知っているため、修正は簡単です
(‘--reapply-cherry-picks’ が指定されていない場合)。 だから(あなたが「
topic」にいると仮定して、)あなたが以下のようにすれば、

         $ git rebase subsystem

   あなたは修正された履歴で終わります。

         o---o---o---o---o---o---o---o  master
                                      \
                                       o'--o'--o'--o'--o'  subsystem
                                                        \
                                                         *---*---*  topic

難しい場合
==========

‘subsystem’ の変更がリベース前の変更に正確に対応していない場合、事態はさ
らに複雑になります。

     *Note*

     「簡単な場合の回復」は、難しい場合でも成功するように見えることがあ
     りますが、 意図しない結果をもたらす可能性があります。 たとえば、
     ‘git rebase --interactive’ を介して削除されたコミットが「復活」しま
     す！

   考え方としては、「git rebase」に「古い「subsystem」が終了し、あなたの
「topic」が開始した場所」、つまり、それらの間の古いマージベースが何であ
ったかを手動で伝えることです。 古い「subsystem」の最後のコミットに名前を
付ける方法を見つける必要があります。以下に例を示します:

   • ‘subsystem’ reflogの場合: ‘git fetch’ 後、‘subsystem’ の古い先端は
     ‘subsystem@{1}’ にあります。それ以降にフェッチすると、その数は増え
     ます。 (git-reflog(1) を参照してください)。

   • ‘topic’ の先端に関連して: ‘topic’ に3つのコミットがあることを知って
     いるので、 ‘subsystem’ の古い先端は ‘topic~3’ でなければなりません
     。

   次に、あなたは以下のように言って、古い ‘subsystem..topic’ を新しい先
端に移植できます(reflogの場合、すでに ‘topic’ にいると仮定します):

         $ git rebase --onto subsystem subsystem@{1}

   「悪い場合」のリカバリの波及効果は特に悪いです。「topic」の下流にある
「全て」で「悪い場合」のリカバリを実行する必要があります。

REBASING MERGES
***************

対話的リベースコマンドは、元々、個々のパッチシリーズを処理するために設計
されました。そのため、開発者がブランチの作業中にその時点で最新の「
master」をマージした可能性があり、最終的にすべてのコミットを「master」に
リベースする(マージコミットをスキップする)ため、マージコミットをtodoリス
トから除外することは理にかなっています。

   ただし、開発者がマージコミットを再作成する正当な理由があります。それ
は複数の相互に関連するブランチで作業するときに、ブランチ構造(または「コ
ミットトポロジ」）を維持するためです。

   次の例では、開発者はボタンの定義方法をリファクタリングするトピックブ
ランチと、そのリファクタリングを使用して[バグの報告]ボタンを実装する別の
トピックブランチで作業します。 ‘git log --graph --format=%s -5’ の出力は
以下のようになります:

     *   Merge branch 'report-a-bug'
     |\
     | * Add the feedback button
     * | Merge branch 'refactor-button'
     |\ \
     | |/
     | * Use the Button class for all buttons
     | * Extract a generic Button class from the DownloadButton one

   開発者は、ブランチトポロジを維持しながら、これらのコミットを新しい
‘master’ にリベースしたい場合があります。たとえば、最初のトピックブラン
チが2番目のブランチよりもはるかに早く ‘master’ に統合されると予想される
場合、たとえば、マージの競合を解決して、 ‘master’ にしたDownloadButtonク
ラスへの変更を解決します。

   このリベースは、 ‘--rebase-merges’ オプションを使用して実行できます。
以下のようなToDoリストが生成されます:

     label onto

     # Branch: refactor-button
     reset onto
     pick 123456 Extract a generic Button class from the DownloadButton one
     pick 654321 Use the Button class for all buttons
     label refactor-button

     # Branch: report-a-bug
     reset refactor-button # Use the Button class for all buttons
     pick abcdef Add the feedback button
     label report-a-bug

     reset onto
     merge -C a1b2c3 refactor-button # Merge 'refactor-button'
     merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'

   通常の対話的リベースとは対照的に、 ‘pick’ コマンドに加えて ‘label’ と
‘reset’ と‘merge‘ コマンドがあります。

   ‘label’ コマンドは、そのコマンドが実行されるときに、ラベルを現在の
HEADに関連付けます。これらのラベルは、ワークツリーローカル参照
(‘refs/rewritten/<label>’)として作成され、リベースが終了すると削除されま
す。こうすれば、同じリポジトリにリンクされている複数のワークツリーでのリ
ベース操作が相互に干渉することはありません。 ‘label’ コマンドが失敗した
場合、すぐに再スケジュールされ、続行する方法について役立つメッセージが表
示されます。

   ‘reset’ コマンドは、HEADとインデックスとワークツリーを指定されたリビ
ジョンにリセットします。 これは ‘exec git reset --hard <label>’ に似てい
ますが、追跡していないファイルの上書きを拒否します。 ‘reset’ コマンドが
失敗すると、すぐに再スケジュールされ、todoリストを編集する方法がわかりや
すく表示されます(これは通常、 ‘reset’ コマンドがtodoリストに手動で挿入さ
れ、タイプミスが含まれている場合に発生します)。

   ‘merge’ コマンドは、指定されたリビジョンをその時点でHEADであるものに
マージします。 ‘-C <original-commit>`を使用すると、指定されたマージコミ
ットのコミットメッセージが使用されます。 `-C’ が小文字の ‘-c’ に変更され
ると、ユーザーがメッセージを編集できるように、マージが成功した後にメッセ
ージがエディターで開かれます。

   マージの競合以外の理由で ‘merge’ コマンドが失敗した場合(つまり、マー
ジ操作が開始されなかった場合)、コマンドは直ちに再スケジュールされます。

   デフォルトでは、「merge」コマンドは通常のマージには「ort」マージ戦略
を使用し、タコマージ(octopus merges)には「octopus」マージ戦略を使用しま
す。リベースを呼び出すときに ‘--strategy’ 引数を使用して、すべてのマージ
のデフォルト戦略を指定できます。または、 ‘exec’ コマンドを使用して明示的
に ‘--strategy’ 引数を伴った ‘git merge’ を呼び出すことにより、コマンド
の対話リスト内の特定のマージをオーバーライドできます。注意:このように明
示的に ‘git merge’ を呼び出す場合、マージするブランチを参照するために、
ラベルがワークツリーローカル参照であるという事実(たとえば、 ref
‘refs/rewritten/onto’ はラベル ‘onto’ に対応します)を利用できることに注
意してください。

   注意: 最初のコマンド(‘label onto’)は、コミットがリベースされるリビジ
ョンにラベルを付けます。 ‘onto`という名前は単なる慣例で、 `--onto’ オプ
ションにちなんでいます。

   ‘merge <merge-head>’ の形式のコマンドを追加することにより、完全に新し
いマージコミットを最初から導入することもできます。この形式は、暫定的なコ
ミットメッセージを生成し、常にエディターを開いてユーザーが編集できるよう
にします。これは便利です。例えば、トピックブランチが複数の懸念事項に対処
していることが判明し、2つ以上のトピックブランチに分割したい場合です。以
下のToDoリストを検討してみてください:

     pick 192837 Switch from GNU Makefiles to CMake
     pick 5a6c7e Document the switch to CMake
     pick 918273 Fix detection of OpenSSL in CMake
     pick afbecd http: add support for TLS v1.3
     pick fdbaec Fix detection of cURL in CMake on Windows

   CMakeに関連しないこのリストの1つのコミットは、CMakeに切り替えることに
よって発生したすべてのバグの修正に取り組むことによって動機付けられた可能
性がありますが、しかし、それは別の懸念に対処します。このブランチを2つの
トピックブランチに分割するには、ToDoリストを以下のように編集できます:

     label onto

     pick afbecd http: add support for TLS v1.3
     label tlsv1.3

     reset onto
     pick 192837 Switch from GNU Makefiles to CMake
     pick 918273 Fix detection of OpenSSL in CMake
     pick fdbaec Fix detection of cURL in CMake on Windows
     pick 5a6c7e Document the switch to CMake
     label cmake

     reset onto
     merge tlsv1.3
     merge cmake

CONFIGURATION
*************

rebase.backend
     リベースに使用するデフォルトのバックエンド。 可能な選択肢は、「
     apply」または「merge」です。 将来、mergeバックエンドがapplyバックエ
     ンドの残りのすべての機能を取得した場合、この設定は使用されなくなる
     可能性があります。

rebase.stat
     最後のリベース以降にアップストリームで変更されたもののdiffstatを表
     示するかどうか。デフォルトではFalseです。

rebase.autoSquash
     trueに設定されている場合、デフォルトで ‘--autosquash’ オプションを
     有効にします。

rebase.autoStash
     trueに設定すると、操作を開始する前に一時的なstashエントリを自動的に
     作成し、操作の終了後に適用します。これは、ダーティワークツリーでリ
     ベースを実行できることを意味します。ただし、注意して使用してくださ
     い。リベースが成功した後の最後のstashアプリケーションは、重要な競合
     を引き起こす可能性があります。このオプションは、 git-rebase(1) の
     ‘--no-autostash’ および ‘--autostash’ オプションでオーバーライドで
     きます。 デフォルトはfalseです。

rebase.missingCommitsCheck
     「warn」に設定すると、 ‘git rebase -i’ は、一部のコミットが削除され
     た場合(たとえば、行が削除された場合)に警告を出力しますが、リベース
     は続行されます。 「error」に設定すると、前記の警告が出力され、リベ
     ースが停止(stop)します。 ‘git rebase --edit-todo’ を使用して、エラ
     ーを修正できます。 「ignore」に設定すると、チェックは行われません。
     警告やエラーなしにコミットをドロップするには、todoリストの ‘drop’ コ
     マンドを使用します。 デフォルトは「ignore」です。

rebase.instructionFormat
     git-log(1) で指定されている、対話的リベース中にToDoリストに使用され
     る書式文字列。書式では、自動的に長いコミットハッシュが書式の前に付
     加されます。

rebase.abbreviateCommands
     trueに設定すると、 ‘git rebase’ はtodoリストで省略コマンド名を使用
     し、以下のようになります:

                  p deadbee The oneline of the commit
                  p fa1afe1 The oneline of the next commit
                  ...

     上記は以下の省略形です:

                  pick deadbee The oneline of the commit
                  pick fa1afe1 The oneline of the next commit
                  ...

     デフォルトではfalseです。

rebase.rescheduleFailedExec
     失敗した ‘exec’ コマンドを自動的に再スケジュールします。 これは、対
     話モード (または ‘--exec’ オプションが指定されている場合)でのみ意味
     があります。これは ‘--reschedule-failed-exec’ オプションを指定する
     のと同じです。

rebase.forkPoint
     falseに設定されている場合、デフォルトで ‘--no-fork-point’ オプショ
     ンを設定します。

sequence.editor
     リベース命令ファイル(rebase instruction file)を編集するために ‘git
     rebase -i’ によって使用されるテキストエディタ。この値は、使用時にシ
     ェルによって解釈されることを意図しています。 これは、
     ‘GIT_SEQUENCE_EDITOR’ 環境変数によってオーバーライドできます。構成
     されていない場合は、代わりにデフォルトのコミットメッセージエディタ
     が使用されます。

BUGS
****

非推奨の ‘--preserve-merges --interactive’ によって提示されるToDoリスト
は、リビジョングラフのトポロジを表していません(代わりに‘
–rebase-merges‘を使用してください)。コミットのeditとコミットメッセージの
rewordは正常に機能するはずですが、コミットを並べ替え(reorder)しようとす
ると、直感に反する結果になる傾向があります。 このようなシナリオでは、代
わりに ‘--rebase-merges’ を使用してください。

   たとえば、以下のように再配置の試みます

     1 --- 2 --- 3 --- 4 --- 5

   を

     1 --- 2 --- 4 --- 3 --- 5

   のように、 ‘pick 4’ の行を移動すると、以下の履歴になります:

             3
            /
     1 --- 2 --- 4 --- 5

GIT
***

Part of the git(1) suite

Name
****

git-receive-pack — リポジトリにプッシュされたものを受信します

Synopsis
********

     git-receive-pack <directory>

DESCRIPTION
***********

‘git send-pack’ によって呼び出され、リモート側からもたらされた情報でリポ
ジトリを更新します。

   このコマンドは通常、エンドユーザーによって直接呼び出されることはあり
ません。 プロトコルのUIは ‘git send-pack’ 側にあり、プログラムペアは更新
をリモートリポジトリにプッシュするために使用されることを目的としています
。 プル操作については、 git-fetch-pack(1) を参照してください。

   このコマンドを使用すると、リモート側で sha1 ref (ヘッド/タグ)を作成し
て早送りできます(厳密に言えば、ローカル側では ‘git-receive-pack’ が実行
されますが、send-pack側に居るユーザにとってはリモートの更新をしている事
になります。混乱しないでね？)

   Documentation/howtoディレクトリには、更新フック(update hook)と更新後
フック(post-update hook)を使用した実例が他にもあります。

   _git-receive-pack_ は、 receive.denyNonFastForwards 構成オプションを
尊重します。このオプションは、refの更新が早送りでない場合に拒否する必要
があるかどうかを通知します。

   他の多くの ‘receive.*’ 構成オプションを使用して、その動作を微調整でき
ます。 git-config(1) を参照してください。

OPTIONS
*******

<directory>
     同期するリポジトリ。

‘--http-backend-info-refs’
     git-http-backend(1) が、
     ‘$GIT_URL/info/refs?service=git-receive-pack’ リクエストを処理する
     ために使用します。 git-upload-pack(1) の ‘--http-backend-info-refs’
     を参照してください。

PRE-RECEIVE HOOK
****************

refが更新される前に、 $GIT_DIR/hooks/pre-receive ファイルが存在し、実行
可能である場合、パラメーターなしで1回呼び出されます。 フックの標準入力は
、更新される参照ごとに1行になります:

     sha1-old SP sha1-new SP refname LF

   refnameの値は$GIT_DIRを基準にしています。 例えば masterヘッドの場合、
これは ‘refs/heads/master’ です。 各refnameの前の2つのsha1値は、更新前後
のrefnameのオブジェクト名です。 作成されるrefのsha1-oldは 0{40} に等しく
、削除されるrefのsha1-newは 0{40} になります。それ以外の場合、sha1-oldと
sha1-newはリポジトリ内の有効なオブジェクトである必要があります。

   署名されたプッシュを受け入れる場合(git-push(1) 参照)、署名されたプッ
シュ証明書はブロブに格納され、環境変数 ‘GIT_PUSH_CERT’ でオブジェクト名
を調べることができます。 例については、 ‘post-receive’ フックの説明を参
照してください。 さらに、証明書はGPGを使用して検証され、結果は以下の環境
変数とともにエクスポートされます:

‘GIT_PUSH_CERT_SIGNER’
     プッシュ証明書に署名したキーの所有者の、名前(name)と電子メールアド
     レス(e-mail address)。

‘GIT_PUSH_CERT_KEY’
     プッシュ証明書に署名したキーのGPGキーID。

‘GIT_PUSH_CERT_STATUS’
     コマンドの ‘git log’ ファミリーの ‘%G?’ 形式で使用されるのと同一の
     ニーモニックを使用した、プッシュ証明書のGPG検証のステータス
     (git-log(1) を参照)。

‘GIT_PUSH_CERT_NONCE’
     プロセスが署名者にプッシュ証明書に含めるように要求したノンス
     (nonce;その場限りの)文字列。これがプッシュ証明書の「nonce」ヘッダー
     に記録されている値と一致しない場合は、証明書が別の ‘git push’ セッ
     ションから再実行されている有効な証明書であることを示している可能性
     があります。

‘GIT_PUSH_CERT_NONCE_STATUS’

     ‘UNSOLICITED’
          ‘git push --signed’ は、私達が送信を問い合わせなかったときにノ
          ンス(nonce)を送信しました。

     ‘MISSING’
          ‘git push --signed’ はノンスヘッダーを送信しませんでした。

     ‘BAD’
          ‘git push --signed’ は偽のノンスを送信しました。

     ‘OK’
          ‘git push --signed’ は、私達が送信を要求したノンスを送信しまし
          た。

     ‘SLOP’
          ‘git push --signed’ は、前回のセッションで送信するように要求し
          たものとは異なるノンスを送信しました。
          ‘GIT_PUSH_CERT_NONCE_SLOP’ 環境変数を参照してください。

‘GIT_PUSH_CERT_NONCE_SLOP’
     ‘git push --signed’ は、現在送信するように要求したものとは異なるノ
     ンスを送信しました。開始時刻が現在のセッションとは何秒も違う別のセ
     ッションで送信されました。 ‘GIT_PUSH_CERT_NONCE_STATUS’ が ‘SLOP’ と
     言った場合にのみ意味があります。 git-config(1) の
     ‘receive.certNonceSlop’ 変数についてもお読みください。

   このフックは、refnameが更新される前、および早送りチェックが実行される
前に呼び出されます。

   受信前(pre-receive)フックがゼロ以外の終了ステータスで終了した場合、更
新は実行されず、更新(update)フックや受信後フック(post-receive)や更新後
(post-update)フックも呼び出されません。 これは、更新がサポートされない場
合に迅速に救済するのに役立ちます。

   以下の検疫環境(quarantine environment)に関する注記を参照してください
。

UPDATE HOOK
***********

各refが更新される前に、 $GIT_DIR/hooks/update ファイルが存在し、実行可能
である場合、3つのパラメーターを使用してrefごとに1回呼び出されます:

     $GIT_DIR/hooks/update refname sha1-old sha1-new

   refnameパラメーターは$GIT_DIRに関連しています。 例えば masterヘッドの
場合、これは ‘refs/heads/master’ です。 2つのsha1引数は、更新前後の
refnameのオブジェクト名です。 refnameが更新される前にフックが呼び出され
るため、sha1-oldが 0{40} (そのようなrefがまだないことを意味します)である
か、refnameに記録されているものと一致する必要があることに注意してくださ
い。

   名前付きrefの更新を禁止する場合、フックはゼロ以外のステータスで終了す
る必要があります。 それ以外の場合は、ゼロで終了する必要があります。

   このフックの正常な実行(ゼロ終了ステータス)は、refが実際に更新されるこ
とを保証するものではなく、前提条件にすぎません。 そのため、このフックか
ら通知(電子メールなど)を送信することはお勧めできません。 代わりに、受信
後(post-receive)フックの使用を検討してください。

POST-RECEIVE HOOK
*****************

すべてのrefが更新された後(または更新が試みられた後)、refの更新が成功した
場合、および $GIT_DIR/hooks/post-receive ファイルが存在し、実行可能であ
る場合、パラメーターなしで1回呼び出されます。 フックの標準入力は、正常に
更新された参照ごとに1行になります。

     sha1-old SP sha1-new SP refname LF

   refnameの値は$GIT_DIRを基準にしています。 例えば masterヘッドの場合、
これは ‘refs/heads/master’ です。 各refnameの前の2つのsha1値は、更新前後
のrefnameのオブジェクト名です。 作成された参照はsha1-oldが 0{40} に等し
くなり、削除された参照はsha1-newが 0{40} に等しくなります。それ以外の場
合、sha1-oldとsha1-newはリポジトリ内の有効なオブジェクトである必要があり
ます。

   署名されたプッシュを受け入れた後、 ‘pre-receive’ フックの場合と同様に
、 ‘GIT_PUSH_CERT*’ 環境変数を検査できます。

   このフックを使用すると、リポジトリの更新を説明するメールを簡単に生成
できます。 このサンプルスクリプトは、リポジトリにプッシュされたコミット
を一覧表示するrefごとに1つのメールメッセージを送信し、適切な署名を持つ署
名付きプッシュのプッシュ証明書をログ取りサービス(logger service)に記録し
ます:

     #!/bin/sh
     # mail out commit update information.
     while read oval nval ref
     do
             if expr "$oval" : '0*$' >/dev/null
             then
                     echo "Created a new ref, with the following commits:"
                     git rev-list --pretty "$nval"
             else
                     echo "New commits:"
                     git rev-list --pretty "$nval" "^$oval"
             fi |
             mail -s "Changes to ref $ref" commit-list@mydomain
     done
     # log signed push certificate, if any
     if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
     then
             (
                     echo expected nonce is ${GIT_PUSH_NONCE}
                     git cat-file blob ${GIT_PUSH_CERT}
             ) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
     fi
     exit 0

   このフック呼び出しからの終了コードは無視されますが、ゼロ以外の終了コ
ードはエラーメッセージを生成します。

   このフックが実行されると、refnameにsha1-newがない可能性があることに注
意してください。 これは、 ‘git-receive-pack’ によって更新された後、フッ
クがそれを評価できるようになる前に、別のユーザーが参照を変更した場合に簡
単に発生する可能性があります。 フックは、refnameの現在の値ではなく、
sha1-newに依存することをお勧めします。

POST-UPDATE HOOK
****************

他のすべての処理の後、少なくとも1つのrefが更新され、
$GIT_DIR/hooks/post-update ファイルが存在し、実行可能である場合、更新さ
れたrefのリストを使用してpost-updateが呼び出されます。 これは、リポジト
リ全体のクリーンアップタスクを実装するために使用できます。

   このフック呼び出しからの終了コードは無視されます。 その時点で
‘git-receive-pack’ に残されているのは、とにかく自分自身を終了することだ
けです。

   このフックは、たとえば、リポジトリがパックされてバカ転送(dumb
transport)を介して提供される場合に ‘git update-server-info’ を実行するた
めに使用できます。

     #!/bin/sh
     exec git update-server-info

QUARANTINE ENVIRONMENT
**********************

‘receive-pack’ がオブジェクトを取り込むと、それらは ‘$GIT_DIR/objects’ デ
ィレクトリ内の一時的な「隔離」(quarantine)ディレクトリに配置され、
‘pre-receive’ フックが完了した後にのみメインオブジェクトストアに移行され
ます。 それ以前にプッシュが失敗した場合、一時ディレクトリは完全に削除さ
れます。

   これには、ユーザーからも見えるいくつかの影響と注意事項があります:

  1. 着信パックの問題、またはオブジェクトの欠落、または ‘pre-receive’ フ
     ックが原因で失敗したプッシュは、ディスク上のデータを残しません。 こ
     れは通常、繰り返し失敗したプッシュがディスクをいっぱいにするのを防
     ぐのに役立ちますが、デバッグがより困難になる可能性があります。

  2. ‘pre-receive’ フックによって作成されたオブジェクトはすべて、隔離
     (quarantine)ディレクトリに作成されます(成功した場合にのみ移行されま
     す)。

  3. ‘pre-receive’ フックは、隔離(quarantined)されたオブジェクトを指すよ
     うに参照を更新してはなりません。 リポジトリにアクセスする他のプログ
     ラムはオブジェクトを見ることができません(そして、受信前
     (pre-receive)フックが失敗した場合、それらのrefは破損します)。 安全
     のため、 ‘pre-receive’ 内からのrefの更新は自動的に拒否されます。

SEE ALSO
********

git-send-pack(1), gitnamespaces(7)

GIT
***

Part of the git(1) suite

Name
****

git-reflog — reflog情報を管理します

Synopsis
********

     git reflog <subcommand> <options>

DESCRIPTION
***********

このコマンドは、さまざまなサブコマンドと、サブコマンドに応じて異なるオプ
ションを取ります:

     git reflog [show] [log-options] [<ref>]
     git reflog expire [–expire=<time>] [–expire-unreachable=<time>]
             [–rewrite] [–updateref] [–stale-fix]
             [–dry-run | -n] [–verbose] [–all [–single-worktree] | <refs>…]
     git reflog delete [–rewrite] [–updateref]
             [–dry-run | -n] [–verbose] ref@{specifier}…
     git reflog exists <ref>

   参照ログ(reference logs)、または "reflogs" は、ブランチのヒントやその
他の参照がローカルリポジトリで更新された時期を記録します。reflogは、参照
の古い値を指定するために、さまざまなGitコマンドで役立ちます。 たとえば、
‘HEAD@{2}’ は「HEADが2移動前にあった位置」を意味し、
‘master@{one.week.ago}’ は「masterがこのローカルリポジトリで1週間前を指
していた位置」を意味する等々。詳細については gitrevisions(7) を参照して
ください。

   このコマンドは、reflogに記録された情報を管理します。

   「show」サブコマンド(サブコマンドの指定がない場合のデフォルトでもあり
ます)は、コマンドライン(またはデフォルトでは「HEAD」)で指定される参照の
ログを表示します。 reflogは最近のすべてのアクションをカバーし、さらに
‘HEAD’ reflogはブランチの切り替えを記録します。 ‘git reflog show’ は
‘git log -g --abbrev-commit --pretty=oneline’ のエイリアスです。詳細につ
いては git-log(1) を参照してください。

   「expire」サブコマンドは、古いreflogエントリを刈り取ります。「
expire」時間より古いエントリ、または「expire-unreachable」時間より古く、
現在の先端から到達できないエントリがreflogから削除されます。これは通常、
エンドユーザーが直接使用することはありません。代わりに、 git-gc(1) を参
照してください。

   「delete」サブコマンドは、reflogから単一のエントリを削除します。 その
引数は「正確な」エントリである必要があります(例: ‘git reflog delete
master@{2}’ )。 このサブコマンドは、通常、エンドユーザーが直接使用するこ
ともありません。

   「exists」サブコマンドは、refにreflogがあるかどうかをチェックします。
reflogが存在する場合はゼロのステータスで終了し、存在しない場合はゼロ以外
のステータスで終了します。

OPTIONS
*******

showサブコマンド用オプション
============================

‘git reflog show’ は、 ‘git log’ で受け入れられるすべてのオプションを受
け入れます。

expireサブコマンド用オプション
==============================

‘--all’
     すべての参照のreflogを処理します。

‘--single-worktree’
     デフォルトでは、 ‘--all’ が指定されている場合、すべての作業ツリーか
     らのreflogが処理されます。 このオプションは、処理を現在の作業ツリー
     からのreflogのみに制限します。

‘--expire=<time>’
     指定された時間より古いエントリを刈り取ります。このオプションが指定
     されていない場合、有効期限は構成設定 ‘gc.reflogExpire’ から取得され
     、デフォルトで90日になります。 ‘--expire=all’ は、年齢に関係なくエ
     ントリを削除します。 ‘--expire=never’ は、到達可能なエントリの刈り
     取りをオフにします(しかし、 ‘--expire-unreachable’ を参照してくださ
     い)。

‘--expire-unreachable=<time>’
     ブランチの現在の先端から到達できない ‘<time>’ より古いエントリを刈
     り取ります。このオプションが指定されていない場合、有効期限は構成設
     定 ‘gc.reflogExpireUnreachable’ から取得され、デフォルトで30日にな
     ります。 ‘--expire-unreachable=all’ は、年齢に関係なく、到達不能な
     エントリを刈り取ります。 ‘--expire-unreachable=never’ は、到達不能
     なエントリの早期刈り取りをオフにします(しかし、 ‘--expire’ を参照し
     てください)。

‘--updateref’
     以前の最上位エントリが刈り取りされた場合は、最上位のreflogエントリ
     の値(つまり、 <ref>@{0} )への参照を更新します。(このオプションは、
     シンボリック参照では無視されます。)

‘--rewrite’
     reflogエントリーの前任者が刈り込まれてしまった場合、その「古い」
     SHA-1を、現在の前任者にあるエントリーの「新しい」SHA-1フィールドと
     等しくなるように調整します。

‘--stale-fix’
     「壊れたコミット」(broken commits)を指すreflogエントリを削除します
     。壊れたコミットとは、どのリファレンスヒントからも到達できず、直接
     または間接的に、欠落しているコミットまたはツリーまたはブロブオブジ
     ェクトを参照するコミットです。

     これの計算では、到達可能なすべてのオブジェクトのトラバースが含まれ
     ます。つまり、 ‘git prune’ と同じコストがかかります。これは主に、
     reflogによって参照されるオブジェクトを保護しなかった古いバージョン
     のGitを使用したガベージコレクションによって引き起こされた破損を修正
     することを目的としています。

‘-n’
‘--dry-run’
     実際にエントリの刈り取りは行いません。何が刈り取られるかを表示する
     だけです。

‘--verbose’
     画面に追加情報を出力します。

deleteサブコマンド用オプション
==============================

‘git reflog delete’ は、オプション ‘--updateref’ と ‘-rewrite’ と ‘-n’ と
‘--dry-run’ と‘ –verbose‘ を受け入れます。これらは、 ‘expire’ で使用され
る場合と同じ意味です。

GIT
***

Part of the git(1) suite

Name
****

git-remote-ext — スマートトランスポートを外部コマンドにブリッジします。

Synopsis
********

     git remote add <nick> "ext::<command>[ <arguments>…]"

DESCRIPTION
***********

このリモートヘルパーは、指定の ‘<command>’ を使用してリモートGitサーバー
に接続します。

   指定の ‘<command>’ のstdinに書き込んだデータは、git:// サーバーまたは
git-upload-pack または git-receive-pack または (状況に応じて
)git-upload-archive に送信されるものと見なし、かつ、 <command> の
stdoutからの読み取りは、同一のサービスから受信されたものと見なされます。

   コマンドと引数は、エスケープされていない空白で区切られます。

   以下のシーケンスには特別な意味があります:

‘% ‘
     コマンドまたは引数のリテラル空白

‘%%’
     リテラルのパーセント文字

‘%s’
     Gitが呼び出したいサービスの名前(receive-pack または upload-pack ま
     たは upload-archive)に置き換えられます。

‘%S’
     Gitが呼び出したいサービスの長い名前(long name)(git-receive-pack ま
     たは git-upload-pack または git-upload-archive)に置き換えられます。

‘%G’ (引数の最初の文字列である必要があります)
     この引数は ‘<command>’ には渡されません。その代わりにヘルパーは、サ
     ービスフィールドが適切な値に設定され、かつ、リポジトリフィールドが
     引数の残りの部分に設定された状態でリモート側に git:// サービス要求
     (request)を送信することから開始します。デフォルトでは、そのような要
     求は送信されません。

     これはリモート側の git:// サーバーへトンネルを介してアクセスする場
     合に便利です。

‘%V’ (引数の最初の文字列である必要があります)
     この引数は ‘<command>’ には渡されません。その代わりに git:// サービ
     ス要求でvhostフィールドを(引数の残りの部分に)設定します。デフォルト
     では、(送信の場合)そのような要求でvhostを送信しません。

ENVIRONMENT VARIABLES
*********************

GIT_TRANSLOOP_DEBUG
     設定されている場合、さまざまな読み取り/書き込みに関するデバッグ情報
     を出力します。

ENVIRONMENT VARIABLES PASSED TO COMMAND
***************************************

GIT_EXT_SERVICE
     サービスヘルパーが呼び出す必要のある長い名前(git-upload-pack など
     )を設定します。

GIT_EXT_SERVICE_NOPREFIX
     サービスヘルパーが呼び出す必要のある名前(upload-pack など)を設定し
     ます。

EXAMPLES
********

このリモートヘルパーは、 ‘git fetch <URL>’ 、 ‘git clone <URL>’ 、 ‘git
push <URL>’ 、 ‘git remote add <nick> <URL>’ などのコマンドを使用すると
きに、Gitによって透過的に使用され、 <URL>は ‘ext::’ で始まります。 例:

"ext::ssh -i /home/foo/.ssh/somekey user@host.example %S _foo/repo_"
     host.example:foo/repo と同様ですが、キーペアとして
     /home/foo/.ssh/somekey を使用し、リモート側のユーザーとしてuserを使
     用します。 これにより、 .ssh/config を編集する必要がなくなります。

"ext::socat -t3600 - ABSTRACT-CONNECT:/git-server %G/somerepo"
     抽象名前空間アドレス(abstract namespace address) /git-server で
     gitプロトコルを介してアクセス可能なパス /somerepo を持つリポジトリ
     を表します。

"ext::git-server-alias foo %G/repo"
     ヘルパープログラム ‘git-server-alias foo’ を使用してアクセスされる
     パス /repo を持つリポジトリを表します。リポジトリへのパスとリクエス
     トのタイプは、コマンドラインではなく、通常の git:// プロトコルのよ
     うにプロトコルストリームの一部として渡されます。

"ext::git-server-alias foo %G/repo %Vfoo"
     ヘルパープログラム ‘git-server-alias foo’ を使用してアクセスされる
     パス /repo を持つリポジトリを表します。プロトコルストリームで渡され
     るリモートサーバーのホスト名は「foo」になります(これにより、複数の
     仮想Gitサーバーがリンクレベルのアドレスを共有できるようになります
     )。

"ext::git-server-alias foo %G/repo% with% spaces %Vfoo"
     ヘルパープログラム ‘git-server-alias foo’ を使用してアクセスされる
     パス ‘/repo with spaces’ のリポジトリを表します。プロトコルストリー
     ムで渡されるリモートサーバーのホスト名は「foo」になります(これによ
     り、複数の仮想Gitサーバーがリンクレベルのアドレスを共有できるように
     なります)。

"ext::git-ssl foo.example /bar"
     ヘルパープログラム ‘git-ssl foo.example /bar’ を使用してアクセスさ
     れるリポジトリを表します。リクエストのタイプは、ヘルパーが環境変数
     を使用して決定できます(上記参照)。

SEE ALSO
********

gitremote-helpers(7)

GIT
***

Part of the git(1) suite

Name
****

git-remote-fd — スマートトランスポートストリームを呼び出し元に反映します
(Reflect smart transport stream back to caller)

Synopsis
********

"fd::<infd>[,<outfd>][/<anything>]" (as URL)

DESCRIPTION
***********

このヘルパーは、指定のファイルデスクリプタを使用してリモートGitサーバー
に接続します。これはエンドユーザー向けではなく、git fetch、pushまたは
archiveを呼び出すプログラムとスクリプトを対象としています。

   <infd> のみが指定されている場合は、リモートGitサーバー
(git-upload-pack、git-receive-pack または git-upload-archive)に接続され
ている双方向ソケットであると見なされます。 <infd> と <outfd> の両方が指
定されている場合、それらはリモートGitサーバーに接続されているパイプであ
ると見なされます( <infd> は入力パイプ、 <outfd> は出力パイプです)。

   このヘルパーが開始される前に、ハンドシェイク手順(git:// のサービスリ
クエストの送信など)がすでに完了していることを前提としています。

   <anything> は任意の文字列にすることができます。それは無視されます。こ
れは、URLが何らかのコンテキストで表示される場合に、URLでユーザーに情報を
提供するためのものです。

ENVIRONMENT VARIABLES
*********************

GIT_TRANSLOOP_DEBUG
     設定されている場合、さまざまな 読み取り/書き込み に関するデバッグ情
     報を出力します。

EXAMPLES
********

‘git fetch fd::17 master’
     ファイルデスクリプタ #17 使用して master を Fetch し、
     git-upload-pack と通信します。

‘git fetch fd::17/foo master’
     同上。

‘git push fd::7,8 master (as URL)’
     master を push し、ファイルデスクリプタ #7 を使用して
     git-receive-pack からデータを読み取り、ファイルデスクリプタ #8 を使
     用して同じサービスにデータを書き込みます。

‘git push fd::7,8/bar master’
     同上。

SEE ALSO
********

gitremote-helpers(7)

GIT
***

Part of the git(1) suite

Name
****

git-remote — 追跡中のリポジトリの組を管理します

Synopsis
********

     git remote [-v | –verbose]
     git remote add [-t <branch>] [-m <master>] [-f] [–[no-]tags] [–mirror=(fetch|push)] <name> <url>
     git remote rename <old> <new>
     git remote remove <name>
     git remote set-head <name> (-a | –auto | -d | –delete | <branch>)
     git remote set-branches [–add] <name> <branch>…
     git remote get-url [–push] [–all] <name>
     git remote set-url [–push] <name> <newurl> [<oldurl>]
     git remote set-url –add [–push] <name> <newurl>
     git remote set-url –delete [–push] <name> <url>
     git remote [-v | –verbose] show [-n] <name>…
     git remote prune [-n | –dry-run] <name>…
     git remote [-v | –verbose] update [-p | –prune] [(<group> | <remote>)…]

DESCRIPTION
***********

ブランチを追跡するリポジトリの組(「remotes」)を管理します。

OPTIONS
*******

‘-v’
‘--verbose’
     もう少しおしゃべりにして、名前の後にリモートURLを表示します。 注意:
     これは、‘remote’ とサブコマンドの間に配置する必要があります。

COMMANDS
********

引数なしだと、既存のリモートのリストを表示します。 「リモート」に操作を
実行するために、いくつかのサブコマンドを使用できます。

_add_
     <url>のリポジトリに<name>という名前の「リモート」を追加します。 次
     に、コマンド ‘git fetch <name>’ を使用して、リモート追跡ブランチ
     <name>/<branch> を作成および更新できます。

     ‘-f’ オプションと使用すると、「リモート」情報が設定された直後に
     ‘git fetch <name>’ が実行されます。

     ‘--tags’ オプションと使用すると、 ‘git fetch <name>’ はリモートリポ
     ジトリからすべてのタグをインポートします。

     ‘--no-tags’ オプションと使用すると、 ‘git fetch <name> ‘ はリモート
     リポジトリからタグをインポートしません。

     デフォルトでは、フェッチされたブランチのタグのみがインポートされま
     す(git-fetch(1) 参照)。

     ‘-t <branch>’ オプションと使用すると、「リモート」のデフォルトのグ
     ロブrefspecが ‘refs/remotes/<name>/’ 名前空間の下のすべてのブランチ
     を追跡する代わりに、 ‘<branch>’ のみを追跡するrefspecが作成されます
     。 複数の ‘-t <branch>’ を指定して、すべてのブランチを取得せずに複
     数のブランチを追跡できます。

     ‘-m <master>’ オプションと使用すると、シンボリックref
     ‘refs/remotes/<name>/HEAD’ がリモートの ‘<master>’ ブランチを指すよ
     うに設定されます。 set-head コマンドも参照してください。

     フェッチミラーが ‘--mirror=fetch’ で作成される場合、refは
     ‘refs/remotes/’ 名前空間に保存されませんが、リモートの ‘refs/’ 内の
     すべてがローカルリポジトリ内の ‘refs/’ に直接ミラーリングされます。
     フェッチはローカルコミットを上書きするため、このオプションはベアリ
     ポジトリでのみ意味があります。

     プッシュミラーが ‘--mirror=push’ で作成されると、 ‘git push’ は常に
     ‘--mirror’ が渡されたかのように動作します。

_rename_
     <old>という名前の「リモート」の名前を<new>に変更します。 「リモート
     」のすべてのリモート追跡ブランチと構成設定が更新されます。

     <old>と<new>が同一で、<old>が ‘$GIT_DIR/remotes’ または
     ‘$GIT_DIR/branchs’ の下のファイルである場合、「リモート」は構成ファ
     イル形式に変換されます。

_remove_
_rm_
     <name>という名前の「リモート」を削除します。 「リモート」のすべての
     リモート追跡ブランチと構成設定が削除されます。

_set-head_
     名前付き「リモート」のデフォルトブランチ(つまり、シンボリックref
     ‘refs/remotes/<name>/HEAD’ のターゲット)を設定または削除します。 リ
     モートのデフォルトブランチを持つ必要はありませんが、特定のブランチ
     の代わりにリモートの名前を指定できます。 たとえば、‘origin’ のデフ
     ォルトブランチが ‘master’ に設定されている場合、通常は
     ‘origin/master’ を指定する場所であればどこでも ‘origin’ を指定でき
     ます。

     ‘-d’ または ‘--delete’ と使用すると、シンボリックref
     ‘refs/remotes/<name>/HEAD’ が削除されます。

     ‘-a’ または ‘--auto’ と使用すると、リモートはその ‘HEAD’ を決定する
     ために照会され、シンボリックref ‘refs/remotes/<name>/HEAD’ が同じブ
     ランチに設定されます。 たとえば、リモートの ‘HEAD’ が ‘next’ を指し
     ている場合、 ‘git remote set-head origin -a’ はシンボリックref
     ‘refs/remotes/origin/HEAD’ を ‘refs/remotes/origin/next’ に設定しま
     す。 これは、 ‘refs/remotes/origin/next’ がすでに存在する場合にのみ
     機能します。 そうでない場合は、最初にフェッチする必要があります。

     ‘<branch>’ を使用して、シンボリックref ‘refs/remotes/<name>/HEAD’ を
     明示的に設定します。 たとえば、 ‘git remote set-head origin master’
     はシンボリックref ‘refs/remotes/origin/HEAD’ を
     ‘refs/remotes/origin/master’ に設定します。 これは、
     ‘refs/remotes/origin/master’ がすでに存在する場合にのみ機能します。
     そうでない場合は、最初にフェッチする必要があります。

_set-branches_
     指定された「リモート」によって追跡されるブランチのリストを変更しま
     す。 これは、「リモート」の初期セットアップ後に、使用可能なリモート
     ブランチのサブセットを追跡するために使用できます。

     名前付きブランチは、 ‘git remote add’ コマンドラインで ‘-t’ オプシ
     ョンを指定した場合と同じように解釈されます。

     ‘--add’ と使用すると、現在追跡されているブランチのリストを置き換え
     る代わりに、そのリストに追加します。

_get-url_
     「リモート」のURLを取得します。 ‘insteadOf’ と ‘pushInsteadOf’ の設
     定はここで展開されます。デフォルトでは、最初のURLのみがリストされま
     す。

     ‘--push’ と使用すると、URLをフェッチするのではなく、プッシュURLが照
     会されます。

     ‘--all’ と使用すると、リモート(remote)のすべてのURLが一覧表示されま
     す。

_set-url_
     「リモート」のURLを変更します。 正規表現 <oldurl> (<oldurl> が指定
     されていない場合は最初のURL)に一致するリモート<name>の最初のURLを
     <newurl>に設定します。 <oldurl>がどのURLとも一致しない場合、エラー
     が発生し、何も変更されません。

     ‘--push’ と使用すると、フェッチURLの代わりにプッシュURLが操作されま
     す。

     ‘--add’ と使用すると、既存のURLを変更する代わりに、新しいURLが追加
     されます。

     ‘--delete’ と使用すると、既存のURLを変更する代わりに、リモート
     <name>の 正規表現<url> に一致するすべてのURLが削除されます。プッシ
     ュされていないURLをすべて削除しようとするとエラーになります。

     注意: プッシュURLとフェッチURLは、設定を変えても、同じ場所を参照す
     る必要があることに注意してください。 プッシュURLにプッシュしたもの
     は、フェッチURLからすぐにフェッチした場合に表示されるものになります
     。 ある場所(アップストリームなど)からフェッチして別の場所(パブリッ
     シングリポジトリなど)にプッシュしようとしている場合は、2つの別々の
     「リモート」を使用します。

_show_
     リモートの<name>に関する情報を提供します。

     ‘-n’ オプションと使用すると、リモートヘッドは最初に ‘git ls-remote
     <name>’ でクエリされません。 代わりに、キャッシュされた情報が使用さ
     れます。

_prune_
     <name>に関連付けられている古い参照を削除します。 デフォルトでは、
     <name>の下の古いリモート追跡ブランチは削除されますが、グローバル構
     成とリモートの構成によっては、そこにプッシュされていないローカルタ
     グを削除することもあります。 新しい参照がフェッチされないことを除い
     て、 ‘git fetch --prune <name>’ と同等です。

     さまざまな構成に応じて刈り込みする内容については、 git-fetch(1) の
     「PRUNING」セクションを参照してください。

     ‘--dry-run’ オプションと使用して、どのブランチが刈り込まれるかを報
     告しますが、実際にはそれらを刈り込みしません。

_update_
     ‘remotes.<group>’ で定義されているように、リポジトリ内のリモートま
     たはリモートグループの更新を取得します。 コマンドラインでgroupも
     remoteも指定されていない場合は、構成パラメーター remotes.default が
     使用されます。 remotes.defaultが定義されていない場合、構成パラメー
     ター ‘remote.<name>.skipDefaultUpdate’ がtrueに設定されていないすべ
     てのリモートが更新されます。 (git-config(1) 参照)。

     ‘--prune’ オプションと使用して、更新されたすべてのリモートに対して
     刈り込みを実行します。

DISCUSSION
**********

「リモート」構成は、 ‘remote.origin.url’ および ‘remote.origin.fetch’ 構
成変数を使用して実現されます。 (git-config(1) 参照)。

EXIT STATUS
***********

成功ならば、終了ステータスは ‘0’ です。

   add や rename や remove などのサブコマンドが問題のリモートを見つける
ことができない場合、終了ステータスは ‘2’ です。 リモートがすでに存在する
場合、終了ステータスは ‘3’ です。

   その他のエラーの場合、終了ステータスはその他ゼロ以外の値になるでしょ
う。

EXAMPLES
********

   • 新しいリモートを追加し、フェッチして、そこからブランチをチェックア
     ウトします

          $ git remote
          origin
          $ git branch -r
            origin/HEAD -> origin/master
            origin/master
          $ git remote add staging git://git.kernel.org/.../gregkh/staging.git
          $ git remote
          origin
          staging
          $ git fetch staging
          ...
          From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
           * [new branch]      master     -> staging/master
           * [new branch]      staging-linus -> staging/staging-linus
           * [new branch]      staging-next -> staging/staging-next
          $ git branch -r
            origin/HEAD -> origin/master
            origin/master
            staging/master
            staging/staging-linus
            staging/staging-next
          $ git switch -c staging staging/master
          ...

   • ‘git clone’ を模倣しますが、選択したブランチのみを追跡します

          $ mkdir project.git
          $ cd project.git
          $ git init
          $ git remote add -f -t master -m master origin git://example.com/git.git/
          $ git merge origin

SEE ALSO
********

git-fetch(1) git-branch(1) git-config(1)

GIT
***

Part of the git(1) suite

Name
****

git-repack — リポジトリ内のアンパックオブジェクトをパックする

Synopsis
********

     git repack [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [–window=<n>] [–depth=<n>] [–threads=<n>] [–keep-pack=<pack-name>]

DESCRIPTION
***********

このコマンドは、現在パック内に存在しないすべてのオブジェクトを1つのパッ
クに結合するために使用されます。また、既存のパックを単一のより効率的なパ
ックに再編成するために使用することもできます。

   パックは、個別に圧縮され、デルタ圧縮が適用され、関連付けられたインデ
ックスファイルとともに単一のファイルに格納されたオブジェクトのコレクショ
ンです。

   パックは、ミラーシステム、バックアップエンジン、ディスクストレージな
どの負荷を軽減するために使用されます。

OPTIONS
*******

‘-a’
     パックされていないオブジェクトを段階的にパックする代わりに、参照さ
     れるすべてのものを1つのパックにパックします。プライベート開発に使用
     されるリポジトリをパックする場合に特に便利です。 ‘-d’ と一緒に使用
     します。 これにより、 ‘git prune’ が残したオブジェクトがクリーンア
     ップされますが、 ‘git fsck --full --dangling’ ではぶら下がりを表示
     します。

     馬鹿プロトコル(dumb protocol)を介してフェッチするユーザーは、含まれ
     ているオブジェクトを取得するために、そのパック内にすでにローカルに
     ある他のオブジェクトの数に関係なく、まったく新しいパックをフェッチ
     する必要があることに注意してください。

     promisorパックファイルは個別に再パックされます。 ‘.promisor’ ファイ
     ルに関連付けられているパックファイルがある場合、これらのパックファ
     イルは別の個別パックに再パックされ、新しい個別パックに対応する、空
     の ‘.promisor’ ファイルが書き込まれます。

‘-A’
     ‘-d’ を使用しない限り ‘-a’ と同じです。 それから、前のパックの到達
     不能なオブジェクトは、古いパックに残されるのではなく、looseになって
     、パックされていないオブジェクトになります。再パックする場合でも、
     到達不能なオブジェクトが意図的にパックに追加されることはありません
     。このオプションは、到達不能なオブジェクトが古いパックに残されて、
     古いパックごと削除されることによって、すぐに削除されてしまうのを防
     ぎます。代わりに、loose到達不能オブジェクトは、以下の 「git gc」呼
     び出しで通常の有効期限ルールに従って剪定されます。 git-gc(1) を参照
     してください。

‘-d’
     パック後、新しく作成されたパックによって既存のパックの一部が冗長に
     なる場合は、冗長パックを削除してください。 また、「git
     prune-packed」を実行して、冗長なルーズオブジェクトファイルを削除し
     ます。

‘-l’
     ‘--local’ オプションを _git pack-objects_ に渡します。
     git-pack-objects(1) を参照してください。

‘-f’
     ‘--no-reuse-delta’ オプションを ‘git-pack-objects’ に渡します。
     git-pack-objects(1) を参照してください。

‘-F’
     ‘--no-reuse-object’ オプションを ‘git-pack-objects’ に渡します。
     git-pack-objects(1) を参照してください。

‘-q’
     ‘-q‘オプションを _git pack-objects_ に渡します。
     git-pack-objects(1) を参照してください。

‘-n’
     _git update-server-info_ でサーバー情報を更新しないでください。この
     オプションは、HTTPまたはFTPを介してこのリポジトリ(またはその直接の
     コピー)を公開するために必要なローカルカタログファイルの更新をスキッ
     プします。 git-update-server-info(1) を参照してください。

‘--window=<n>’
‘--depth=<n>’
     これらの2つのオプションは、パックに含まれるオブジェクトがデルタ圧縮
     を使用して格納される方法に影響します。オブジェクトは最初にタイプ、
     サイズ、およびオプションで名前で内部的にソートされ、 ‘--window’ 内
     の他のオブジェクトと比較されて、デルタ圧縮を使用することでスペース
     が節約されるかどうかが確認されます。 ‘--depth’ は最大デルタ深度を制
     限します。深くしすぎると、必要なオブジェクトに到達するためにデルタ
     データを何度も適用する必要があるため、アンパッカー側(unpacker
     side)のパフォーマンスに影響します。

     ‘--window’ のデフォルト値は10で、 ‘--depth’ は50です。最大深度
     (maximum depth)は4095です。

‘--threads=<n>’
     このオプションは ‘git pack-objects’ に渡されます。

‘--window-memory=<n>’
     このオプションは、 ‘--window’ に加えて追加の制限を提供します。ウィ
     ンドウサイズは、メモリ内で _<n>_ バイトを超えないように動的に縮小さ
     れます。これは、大きなウィンドウと小さなオブジェクトが混在するリポ
     ジトリで、大きなウィンドウでメモリが不足しないようにするのに役立ち
     ますが、小さなオブジェクトは大きなウィンドウを利用できます。 サイズ
     には、「k」または「m」または「g」の接尾辞を付けることができます。
     ‘--window-memory=0’ は、メモリ使用量を無制限にします。 デフォルトは
     、 ‘pack.windowMemory’ 構成変数から取得されます。 実際のメモリ使用
     量は、制限に git-pack-objects(1) で使用されるスレッド数を掛けたもの
     になることに注意してください。

‘--max-pack-size=<n>’
     各出力パックファイルの最大サイズ。 サイズには、「k」または「m」また
     は「g」の接尾辞を付けることができます。許可される最小サイズは1MiBに
     制限されています。 指定した場合、複数のパックファイルが作成される可
     能性があります。これにより、ビットマップインデックスの作成も妨げら
     れます。構成変数 ‘pack.packSizeLimit’ が設定されていない限り、デフ
     ォルトは無制限です。このオプションを使用すると、リポジトリが大きく
     なり、速度が低下する可能性があることに注意してください。
     ‘pack.packSizeLimit’ の説明を参照してください。

‘-b’
‘--write-bitmap-index’
     再パックの一部として到達可能性ビットマップインデックスを書き込みま
     す。ビットマップは到達可能なすべてのオブジェクトを参照できる必要が
     あるため、これは ‘-a’ または ‘-A’ とともに使用する場合にのみ意味が
     あります。このオプションは、 ‘repack.writeBitmaps’ の設定を上書きし
     ます。複数のパックファイルが作成されている場合、このオプションは効
     果がありません。

‘--pack-kept-objects’
     再パックするときは ‘.keep’ ファイルにオブジェクトを含めます。
     ‘pack-objects’ が終了した後も ‘.keep’ パックを削除しないことに注意
     してください。これは、オブジェクトを複製する可能性があることを意味
     しますが、これにより、プッシュまたはフェッチが同時に発生する場合に
     オプションを安全に使用できます。このオプションを指定すると、ビット
     マップ化されたパックファイルに必要なオブジェクトが確実に含まれるた
     め、通常、 ‘-b’ または ‘repack.writeBitmaps’ を使用してビットマップ
     を書き込む場合にのみ役立ちます。

‘--keep-pack=<pack-name>’
     指定されたパックを再パックから除外します。 これは、パックに ‘.keep’
     ファイルがあるのと同じです。 ‘<pack-name>’ は、先頭にディレクトリが
     ないパックファイル名です(例: ‘pack-123.pack’)。このオプションは、複
     数のパックを保持するために複数回指定できます。

‘--unpack-unreachable=<when>’
     到達不能なオブジェクトのパックをほどく(loose)ときは、 ‘<when>’ より
     古いオブジェクトをわざわざほどきません。これは、フォローアップで行
     う ‘git prune’ によってすぐに剪定されるオブジェクトの書き込みを最適
     化するために使用できます。

‘-k’
‘--keep-unreachable’
     ‘-ad’ と一緒に使用すると、既存のパックから到達できないオブジェクト
     は、削除されるのではなく、パックファイルの最後に追加されます。さら
     に、到達不能なlooseオブジェクトはパックされます(そしてそれらの
     looseオブジェクトは削除されます)。

‘-i’
‘--delta-islands’
     ‘--delta-islands’ オプションを ‘git-pack-objects’ に渡します。
     git-pack-objects(1) を参照してください。

‘-g=<factor>’
‘--geometric=<factor>’
     結果のパック構造を、連続する各パックに、次に大きいパックのオブジェ
     クト数の少なくとも ‘<factor>’ 倍が含まれるように配置します。

     ‘git repack’ が、等比数列を確実にするために1つに再パックする必要が
     あるパックファイルの「切り分け」を決断することによってこれを保証し
     ます。 大きいパックファイルの多く(そのパックに含まれるオブジェクト
     の数による)がそのまま残るように、パックファイルの最小セットを選択し
     ます。

     他の再パックモードとは異なり、梱包するオブジェクトのセットは、「ロ
     ールアップ」(rolled-up)されるパックのセットによって一意に決定されま
     す。言い換えれば、等比数列を復元するために組み合わせる必要があると
     判断されたパックです。

     ‘--unpacked’ が指定されている場合、ルーズオブジェクトは、到達可能性
     に関係なく、この「ロールアップ」に暗黙的に含まれます。 これは将来変
     更される可能性があります。このオプション(大幅に異なる再パックモード
     を意味する)は、 ‘git repack’ の他のすべてのオプションの組み合わせで
     機能することが保証されていません。

CONFIGURATION
*************

さまざまな構成変数がパッキングに影響します。 git-config(1) を参照してく
ださい(「pack」と「delta」を検索してください)。

   デフォルトでは、コマンドは ‘--delta-base-offset’ オプションを
_gitpack-objects_ に渡します。これにより、通常、パックはわずかに小さくな
りますが、生成されたパックは、バージョン1.4.4より古いバージョンのGitと互
換性がありません。直接またはダムhttpプロトコルを介して、このような古いバ
ージョンのGitとリポジトリを共有する必要がある場合は、構成変数
‘repack.UseDeltaBaseOffset’ を ‘false’ に設定して再パックする必要があり
ます。この場合、必要に応じて変換がオンザフライで実行されるため、ネイティ
ブプロトコルを介した古いGitバージョンからのアクセスではこのオプションの
影響を受けません。

   デルタ圧縮は、 ‘core.bigFileThreshold’ 構成変数より大きいオブジェクト
、および属性 ‘delta’ がfalseに設定されているファイルでは使用されません。

SEE ALSO
********

git-pack-objects(1) git-prune-packed(1)

GIT
***

Part of the git(1) suite

Name
****

git-replace — オブジェクトを置き換えるためのrefsの作成、一覧表示、削除

Synopsis
********

     git replace [-f] <object> <replacement>
     git replace [-f] –edit <object>
     git replace [-f] –graft <commit> [<parent>…]
     git replace [-f] –convert-graft-file
     git replace -d <object>…
     git replace [–format=<format>] [-l [<pattern>]]

DESCRIPTION
***********

‘refs/replace/’ 名前空間に ‘replace’ 参照を追加します。

   ‘replace’ 参照の名前は、置き換えられるオブジェクトのSHA-1です。
‘replace’ 参照の内容は、置き換えるオブジェクトのSHA-1です。

   置き換えられるオブジェクトと置き換えるオブジェクトは同じタイプである
必要があります。 この制限は、 ‘-f’ を使用して迂回(bypass)できます。

   ‘-f’ が指定されていない限り、 ‘replace’ 参照はまだ存在していてはなり
ません。

   置換されるオブジェクトと置換するオブジェクトに他の制限はありません。
マージコミットは非マージコミットに置き換えることができ、その逆も可能です
。

   置換する参照は、デフォルトでは、到達可能性トラバーサル(剪定(prune)と
パックと転送とfsck)実行するコマンドを除くすべてのGitコマンドで使用されま
す。

   ‘git’ の直後に ‘--no-replace-objects’ オプションを使用すると、任意の
コマンドでの置換参照の使用を無効にすることができます。

   たとえば、 コミット ‘foo’ がコミット ‘bar’ に置き換えられた場合:

     $ git --no-replace-objects cat-file commit foo

   上記は、コミット ‘foo’ に関する情報を表示します。

     $ git cat-file commit foo

   これはコミット ‘bar’ に関する情報を表示します。

   ‘GIT_NO_REPLACE_OBJECTS’ 環境変数は、 ‘--no-replace-objects’ オプショ
ンと同じ効果を達成するように設定できます。

OPTIONS
*******

‘-f’
‘--force’
     同じオブジェクトの既存の置換refが存在する場合、(失敗するのではなく
     )上書きされます。

‘-d’
‘--delete’
     指定されたオブジェクトの既存の置換refsを削除します。

‘--edit <object>’
     オブジェクトのコンテンツを対話的に編集します。 <object> の既存のコ
     ンテンツは一時ファイルにきれいに表示(pretty-printed)され、そのファ
     イルでエディタが起動され、エディタの編集結果がパースされて <object>
     と同じタイプの新しいオブジェクトが作成されます。続いて、置換refが作
     成され、 <object> が新しく作成されたオブジェクトに置き換えられます
     。エディタの選択方法の詳細については git-var(1) を参照してください
     。

‘--raw’
     編集するときにきれいに出力されたものではなく、生のオブジェクトの内
     容を提供します。現在、これはツリーにのみ影響し、バイナリ形式で表示
     されます。これは扱いが難しいですが、きれいに出力できないほど破損し
     ているツリーを修復するときに役立ちます。バイナリデータをきれいに読
     み書きできるようにエディタを設定する必要がある場合があることに注意
     してください。

‘--graft <commit> [<parent>...]’
     graftコミットを作成します。 <commit> と同じ内容で新しいコミットが作
     成されますが、その親は <commit> の親ではなく [<parent>…] になります
     。続けて、置換refが作成され、 <commit> が新しく作成されたコミットに
     置き換えられます。 ‘--convert-graft-file’ を使用して
     ‘$GIT_DIR/info/grafts’ ファイルを変換し、代わりに置換refsを使用しま
     す。

‘--convert-graft-file’
     ‘$GIT_DIR/info/grafts’ のすべてのエントリに対してgraftコミットを作
     成し、成功するとそのファイルを削除します。目的は、現在非推奨の
     graftファイルからの移行の為にユーザーを支援することです。

‘-l <pattern>’
‘--list <pattern>’
     指定されたパターンに一致する(またはパターンが指定されていない場合は
     すべての)オブジェクトの置換refをリストします。引数なしで「git
     replace」と入力すると、すべての置換refが一覧表示されます。

‘--format=<format>’
     リストするときに、指定の <format> を使用します。これには、「short」
     および「medium」および「long」のいずれかになります。 省略した場合、
     フォーマットはデフォルトで「short」になります。

FORMATS
*******

以下の形式を使用できます:

   • ‘short’: <置換された sha1>

   • ‘medium’: <置換された sha1> → <置換する sha1>

   • ‘long’: <置換された sha1> (<置換された sha1 のタイプ>) → <置換する
     sha1> (<置換する sha1 のタイプ>)

CREATING REPLACEMENT OBJECTS
****************************

git-hash-object(1) と git-rebase(1) と git-filter-repo
(https://github.com/newren/git-filter-repo) は、他のgitコマンドの中でも
特に 既存のオブジェクトから置換オブジェクトを作成するために使用されます
。 ‘--edit’ オプションを _git replace_ と一緒に使用して、既存のオブジェ
クトを編集することで置換オブジェクトを作成することもできます。

   コミットの文字列の一部である多くの、ブロブまたはツリーまたはコミット
を置き換える場合は、コミットの置換文字列を作成してから、コミットのターゲ
ット文字列の先端にあるコミットのみを、コミットの置換文字列の先端にあるコ
ミットに置き換えることができます。

BUGS
****

置き換えられたブロブまたはツリーをそれらを置き換えるものと比較すると、正
しく機能しません。 また、 ‘git reset --hard’ を使用して置換されたコミッ
トに戻ると、ブランチは置換されたコミットではなく置換されたコミットに移動
します。

   保留中のオブジェクトに関連する「git rev-list」を使用すると、他の問題
が発生する可能性があります。

SEE ALSO
********

git-hash-object(1) git-rebase(1) git-tag(1) git-branch(1) git-commit(1)
git-var(1) git(1) git-filter-repo
(https://github.com/newren/git-filter-repo)

GIT
***

Part of the git(1) suite

Name
****

git-request-pull — 保留中の変更の概要を生成します

Synopsis
********

     git request-pull [-p] <start> <url> [<end>]

DESCRIPTION
***********

アップストリームプロジェクトに変更をツリーにプルするように要求するリクエ
ストを生成します。標準出力に出力される要求は、ブランチの説明で始まり、変
更を要約し、どこからプルできるかを示します。

   アップストリームプロジェクトには ‘<start>’ という名前のコミットがある
と予想され、出力では、そのコミット以降に行った変更を ‘<url>`という名前の
リポジトリの、’<end>‘ という名前のコミットまで統合するように求められます
。

OPTIONS
*******

‘-p’
     出力にパッチテキストを含めます。

<start>
     開始コミット。これは、すでにアップストリーム履歴に存在するコミット
     を指定します。

<url>
     プル元のリポジトリURL。

<end>
     終了コミット(省略時デフォルトはHEAD)。プルを要求している履歴の先端
     にあるコミットを指定します。

     ‘<url>’ で指定されたリポジトリの、ローカルにあるrefとは異なるrefの
     先端にコミットがある場合、「ローカル名 コロン(:) リモート名」である
     、 ‘<local>:<remote>’ 構文を使用することができます。

EXAMPLES
********

‘v1.0’ リリースの上にある ‘master’ ブランチで作業を構築し、それをプロジ
ェクトに統合したいとします。 まず、他の人が見ることができるように、その
変更をパブリックリポジトリにプッシュします:

     git push https://git.ko.xz/project master

   それから、あなたは以下のコマンドを実行します:

     git request-pull v1.0 https://git.ko.xz/project master

   これにより、アップストリームへのリクエストが生成され、 ‘v1.0’ リリー
スと ‘master’ の間の変更が要約されて、パブリックリポジトリからプルされま
す。

   ローカルにあるブランチとは名前が異なるブランチに変更をプッシュする場
合、例えば、

     git push https://git.ko.xz/project master:for-linus

   それからあなたはそれをプルするように頼むことができます

     git request-pull v1.0 https://git.ko.xz/project master:for-linus

GIT
***

Part of the git(1) suite

Name
****

git-rerere — 競合するマージの記録された競合解決決定を再利用する

Synopsis
********

     git rerere [clear|forget <pathspec>|diff|remaining|status|gc]

DESCRIPTION
***********

比較的長期間存続するトピックブランチを使用するワークフローでは、開発者は
、トピックブランチが完了するまで(「リリース」ブランチにマージされるか、
アップストリームに送信されて受け入れられるまで)、同じ競合を何度も解決す
る必要がある場合があります。

   このコマンドは、最初の手動マージにて、自動マージ結果の競合とそれに対
応した手動解決結果を記録しておいて、以後の自動マージ結果の競合に、その記
録した手動競合解決決定を適用することにより、この処理において開発者を支援
します。

     *Note*

     あなたがこのコマンドを有効にするには、構成変数 ‘rerere.enabled’ を
     設定する必要があります。

COMMANDS
********

通常、「git rerere」は、引数やユーザーの介入なしで実行されます。 ただし
、動作状態との対話を可能にするいくつかのコマンドがあります。

_clear_
     マージ競合解決決定を中止する場合は、rerereが使用するメタデータをリ
     セットします。 ‘git am [--skip|--abort]’ または ‘git rebase
     [--skip|--abort]’ を呼び出すと、このコマンドが自動的に呼び出されま
     す。

_forget_ <pathspec>
     <pathspec> の現在の競合について rerere が記録した競合解決決定をリセ
     ットします。

_diff_
     競合解決決定の現在の状態の差分を表示します。これは、ユーザーが競合
     を解決している間に何が変更されたかを追跡するのに役立ちます。追加の
     引数は、PATHにインストールされているシステムの「diff」コマンドに直
     接渡されます。

_status_
     マージ競合解決決定がrerereで記録される競合のあるパスをプリントする
     。

_remaining_
     rerereによって自動解決されていない競合のあるパスをプリントする。こ
     れには、競合するサブモジュールなど、rerereで競合解決決定を追跡でき
     ないパスが含まれます。

_gc_
     ずっと前に発生した競合するマージのレコードを剪定(prune)します。デフ
     ォルトでは、15日より古い未解決の競合と、60日より古い解決済みの競合
     は剪定されます。これらのデフォルトは、それぞれ
     ‘gc.rerereUnresolved’ および ‘gc.rerereResolved’ 構成変数を介して制
     御されます。

DISCUSSION
**********

トピックブランチが分岐してからマスターブランチ(またはアップストリーム)が
触れた重複領域をトピックブランチが変更する場合、トピックブランチをアップ
ストリームにプッシュする準備ができる前であっても、最新のマスターでテスト
することをお勧めします:

                   o---*---o topic
                  /
         o---o---o---*---o---o master

   このようなテストでは、マスターとトピックを何らかの方法でマージする必
要があります。これを行う1つの方法は、マスターをトピックブランチにプルす
ることです:

             $ git switch topic
             $ git merge master

                   o---*---o---+ topic
                  /           /
         o---o---o---*---o---o master

   ‘*’ でマークされたコミットは、同じファイルの同じ領域にアクセスします
。 ‘+’ でマークされたコミットを作成するときに競合を解決する必要がありま
す。次に、結果をテストして、進行中の作業が最新のマスターにあるもので引き
続き機能することを確認できます。

   このテストマージの後、トピックの作業を続行するには2つの方法があります
。最も簡単なのは、テストマージコミット ‘+’ の上に構築することです。トピ
ックブランチでの作業の準備ができたら、トピックブランチをマスターにプルす
るか、アップストリームにプルするように依頼します。ただし、その時点で、テ
ストマージ ‘+’ 以降、マスターまたはアップストリームが進んでいる可能性が
あります。その場合、最終的なコミットグラフは以下のようになります:

             $ git switch topic
             $ git merge master
             $ ... work on both topic and master branches
             $ git switch master
             $ git merge topic

                   o---*---o---+---o---o topic
                  /           /         \
         o---o---o---*---o---o---o---o---+ master

   けれども、トピックブランチの存続期間が長い場合、トピックブランチには
そのような「マスターからのマージ」コミットが多数含まれることになり、開発
履歴が不必要に乱雑になります。Linuxカーネルメーリングリストの読者は、サ
ブシステムのメンテナが「役に立たないマージ」でいっぱいのブランチからプル
するように要求したときに、Linusがテストマージの頻度が高すぎると不平を言
ったことを覚えているかもしれません。

   別の方法として、トピックブランチでテストマージをクリーンに保つために
、テストマージを吹き飛ばし、テストマージの前に、先端の先に構築し続けるこ
とができます:

             $ git switch topic
             $ git merge master
             $ git reset --hard HEAD^ ;# rewind the test merge
             $ ... work on both topic and master branches
             $ git switch master
             $ git merge topic

                   o---*---o-------o---o topic
                  /                     \
         o---o---o---*---o---o---o---o---+ master

   これにより、トピックブランチの準備が整い、マスターブランチにマージさ
れたときに、マージコミットが1つだけ残ります。 このマージでは、 ‘*’ でマ
ークされたコミットによって導入された競合を解決する必要があります。ただし
、この競合は、多くの場合、吹き飛ばしたテストマージを作成したときに解決し
た競合と同じです。 _git rerere_ は、以前の手動解決からの情報を使用して、
この最後の競合するマージを解決するのに役立ちます。

   競合する自動マージの直後に「git rerere」コマンドを実行すると、それら
の中の、通常の競合マーカー ‘<<<<<<<’ と ‘=======’ と ‘>>>>>>>’ を使用し
て、競合する作業ツリーファイルが記録されます。後で、競合の解決が完了した
後、「git rerere」を再度実行すると、これらのファイルの解決された状態が記
録されます。 masterのトピックブランチへのテストマージを作成したときにこ
れを行ったとします。

   次回、同じ競合する自動マージを確認した後、「git rerere」を実行すると
、以前の競合する自動マージ、以前の手動解決、および現在の競合する自動マー
ジの間で3方向のマージが実行されます。この3方向マージが正常に解決される場
合、結果は作業ツリーファイルに書き出されるため、手動で解決する必要はあり
ません。注意: _git rerere_ はインデックスファイルをそのままにしておくの
で、結果に満足のいく場合は、 ‘git diff’ (または ‘git diff -c’)を使用して
最終的な健全性チェックを行い、そして、 _git add_ する必要があることに注
意してください。

   より便利な方法として、「git merge」は、失敗した自動マージで終了すると
自動的に「git rerere」を呼び出し、「git rerere」は、新しい競合の場合は手
動解決を記録し、そうでない場合は以前の手動解決を再利用します。「git
commit」は、マージ結果をコミットするときに「git rerere」も呼び出します。
これが意味することは、（rerere.enabled構成変数を有効にする以外に）自分で
特別なことをする必要がないということです。

   この例では、テストマージを実行すると、手動の競合解決決定が記録され、
記録された競合解決決定が引き続き適用可能である限り、後で更新されたマスタ
ーブランチとトピックブランチを使用して実際のマージを実行するときに再利用
されます。

   「git rerere」レコードの情報は、「git rebase」を実行するときにも使用
されます。 テストマージを吹き飛ばし、トピックブランチで開発を続けた後:

                   o---*---o-------o---o topic
                  /
         o---o---o---*---o---o---o---o   master

             $ git rebase master topic

                                       o---*---o-------o---o topic
                                      /
         o---o---o---*---o---o---o---o   master

   ‘git rebase master topic’ を実行して、トピックをアップストリームに送
信する準備ができる前に最新の状態にすることができます。これにより、3方向
マージにフォールバックし、前に解決したテストマージと同じように競合します
。 「git rerere」は「git rebase」によって実行され、この競合を解決するの
に役立ちます。

   [注] _git rerere_ は、ファイル内の競合マーカーに依存して競合を検出し
ます。ファイルに競合マーカーのある行と同じように見える行がすでに含まれて
いる場合、「git rerere」は競合解決の記録に失敗する可能性があります。これ
を回避するには、 gitattributes(5) の ‘conflict-marker-size’ 設定を使用で
きます。

GIT
***

Part of the git(1) suite

Name
****

git-reset — 現在のHEADを指定の状態にリセットします

Synopsis
********

     git reset [-q] [<tree-ish>] [–] <pathspec>…
     git reset [-q] [–pathspec-from-file=<file> [–pathspec-file-nul]] [<tree-ish>]
     git reset (–patch | -p) [<tree-ish>] [–] [<pathspec>…]
     git reset [–soft | –mixed [-N] | –hard | –merge | –keep] [-q] [<commit>]

DESCRIPTION
***********

最初の3つの形式は、エントリを‘<tree-ish>‘ からインデックスにコピーします
。 最後の形式では、現在のブランチヘッド(‘HEAD’) を ‘<commit>’ に設定し、
オプションでインデックスと作業ツリーを一致するように変更します。
‘<tree-ish>’/‘<commit>’ は、すべての形式でデフォルトで ‘HEAD’ になります
。

‘git reset' [-q] [<tree-ish>] [--] <pathspec>...’
‘git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]’
     これらの形式は、 ‘<pathspec>’ を ‘<tree-ish>’ の状態に一致させるす
     べてのパスのインデックスエントリをリセットします。 (作業ツリーや現
     在のブランチには影響しません。)

     これは、 ‘git reset <pathspec>’ が ‘git add <pathspec>’ の反対であ
     ることを意味します。 このコマンドは、 ‘git restore
     [--source=<tree-ish>] --staged <pathspec>...’ と同等です。

     ‘git reset <pathspec>’ を実行してインデックスエントリを更新した後、
     git-restore(1) を使用して、インデックスの内容を作業ツリーにチェック
     アウトできます。 または、 git-restore(1) を使用し、 ‘--source’ でコ
     ミットを指定すると、コミットからインデックスと作業ツリーへのパスの
     内容を一度にコピーできます。

‘git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...]’
     インデックスと ‘<tree-ish>’ (デフォルトは ‘HEAD’)の違いでハンクを対
     話的に選択します。 選択したハンクは、インデックスから適用を外します
     (apply in reverse)。

     これは、 ‘git reset -p’ が ‘git add -p’ の反対であることを意味しま
     す。つまり、これを使用してハンクを選択的にリセットできます。
     ‘--patch’ モードの操作方法については、 git-add(1) の「Interactive
     Mode」セクションを参照してください。

‘git reset [<mode>] [<commit>]’
     この形式は、現在のブランチヘッドを ‘<commit>’ にリセットし、場合に
     よっては、 ‘<mode>’ に応じて、インデックス(‘<commit>’ のツリーにリ
     セット)と作業ツリーを更新します。 ‘<mode>’ を省略すると、デフォルト
     で ‘--mixed’ になります。 ‘<mode>’ は以下のいずれかである必要があり
     ます:

     ‘--soft’
          インデックスファイルまたは作業ツリーにはまったく触りません(し
          かし、すべてのモードと同様に、ヘッドを ‘<commit>’ にリセットし
          ます)。 これにより、 ‘git status’ が示すように、変更されたすべ
          てのファイルが「コミットされる変更」(Changes to be committed)の
          ままになります。

     ‘--mixed’
          インデックスをリセットしますが、作業ツリーはリセットしません
          (つまり、変更されたファイルは保持されますが、コミットのマーク
          は付けられません)。更新されていないものを報告します。 これがデ
          フォルトのアクションです。

          ‘-N’ が指定されている場合、削除されたパスはadd対象
          (intent-to-add)としてマークされます(git-add(1) 参照)。

     ‘--hard’
          インデックスと作業ツリーをリセットします。 ‘<commit>’ 以降の作
          業ツリー内の追跡中のファイルへの変更はすべて破棄されます。

     ‘--merge’
          インデックスをリセットし、作業ツリー内の ‘<commit>’ と ‘HEAD’
          の間で異なるファイルを更新しますが、インデックスと作業ツリーの
          間で異なるファイル（つまり、まだ追加されていない変更があるもの
          ）は保持します。 もし ‘<commit>’ とインデックスの間で異なるフ
          ァイルに、ステージされていない変更がある場合、リセットは中断
          (abort)されます。

          つまり、 ‘--merge’ は ‘git read-tree -u -m <commit>’ のような
          ことをしますが、アンマージインデックスエントリは引き継ぎます。

     ‘--keep’
          インデックスエントリをリセットし、 ‘<commit>’ と ‘HEAD’ で異な
          る作業ツリー内のファイルを更新します。 ‘<commit>’ と ‘HEAD’ で
          異なるファイルにローカル変更がある場合、リセットは中止
          (abort)されます。

     ‘--[no-]recurse-submodules’
          作業ツリーが更新される時、 ‘--recurse-submodules’ を使用すると
          、スーパープロジェクトに記録されたコミットに従ってすべてのアク
          ティブなサブモジュールの作業ツリーが再帰的にリセットされ、その
          コミット時にサブモジュールのHEADが切り離されるよう(detach)に設
          定されます。

   3つのコマンドの違いについては、 git(1) の「Reset, restore and revert」
を参照してください。

OPTIONS
*******

‘-q’
‘--quiet’
‘--no-quiet’
     静かにして、エラーだけを報告します。 デフォルトの動作は、
     ‘reset.quiet’ 構成オプションによって設定されます。 ‘--quiet’ と
     ‘--no-quiet’ はデフォルトの動作を上書きします。

‘--pathspec-from-file=<file>’
     パススペックは、コマンドライン引数の代わりに ‘<file>’ で渡されます
     。 ‘<file>’ が正確に ‘-’ の場合、標準入力が使用されます。 Pathspec要
     素は、LFまたはCR/LFで区切られます。 パススペック要素は、構成変数
     ‘core.quotePath’ で説明されているようにクォートできます
     (git-config(1) 参照)。 ‘--pathspec-file-nul’ および グローバルの
     ‘--literal-pathspecs’ も参照してください。

‘--pathspec-file-nul’
     ‘--pathspec-from-file’ 指定時のみ意味があります。 パススペック要素
     はNUL文字で区切られ、他のすべての文字は文字通りに解釈されます(改行
     と引用符を含む)。

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

<pathspec>…
     操作の影響を受けるパスを制限します。

     詳細については、 gitglossary(7) の「pathspec」エントリを参照してく
     ださい。

EXAMPLES
********

Undo add
          $ edit                                     (1)
          $ git add frotz.c filfre.c
          $ mailx                                    (2)
          $ git reset                                (3)
          $ git pull git://info.example.com/ nitfol  (4)

     See (1).
          あなたは喜んで何かに取り組んでおり、これらのファイルの変更が適
          切に行われていることがわかります。 あなたが ‘git diff’ を実行
          するときにそれらを表示したくないのは、他のファイルで作業するこ
          とを計画していて、これらのファイルでの変更が気を散らすためです
          。

     See (2).
          誰かがあなたにプルを要求し、その変更がマージに値すると思われる
          場合。

     See (3).
          しかしながら、あなたはすでにインデックスをダーティにしています
          (つまり、インデックスが ‘HEAD’ コミットと一致していません)。 た
          だし、これから行うプルは ‘frotz.c’ または ‘filfre.c’ には影響
          しないため、これら2つのファイルのインデックスの変更を元に戻し
          ます。 作業ツリーのあなたの変更はそのまま残ります。

     See (4).
          それから、あなたは ‘frotz.c’ と ‘filfre.c’ の変更を作業ツリー
          に残したまま、プルしてマージできます。

Undo a commit and redo
          $ git commit ...
          $ git reset --soft HEAD^      (1)
          $ edit                        (2)
          $ git commit -a -c ORIG_HEAD  (3)

     See (1).
          これは、コミットした内容が不完全であることを思い出した場合、コ
          ミットメッセージのスペルを間違えた場合、またはその両方の場合に
          最もよく行われます。 「リセット」前の状態で作業ツリーを残しま
          す。

     See (2).
          作業ツリーファイルを修正します。

     See (3).
          「リセット」は古いヘッドを ‘.git/ORIG_HEAD’ にコピーします。 ロ
          グメッセージから始めて、コミットをやり直します。 メッセージを
          さらに編集する必要がない場合は、代わりに ‘-C’ オプションを指定
          できます。

          git-commit(1) の ‘--amend’ オプションも参照してください。

コミットを元に戻し(undo)、トピックブランチにします
          $ git branch topic/wip          (1)
          $ git reset --hard HEAD~3       (2)
          $ git switch topic/wip          (3)

     See (1).
          あなたはいくつかのコミットをしましたが、それらが ‘master’ ブラ
          ンチに入るのは時期尚早であることに気づきました。 あなたはトピ
          ックブランチでそれらを磨き続けたいので、現在の ‘HEAD’ から
          ‘topic/wip’ ブランチを作成します。

     See (2).
          masterブランチを巻き戻して、これら3つのコミットを取り除きます
          。

     See (3).
          ‘topic/wip’ ブランチに切り替えて、作業を続けます。

Undo commits permanently
          $ git commit ...
          $ git reset --hard HEAD~3   (1)

     See (1).
          最後の3コミット(‘HEAD’ と ‘HEAD^’ と ‘HEAD~2’)は悪かったので、
          二度と見たくありません。 あなたがこれらのコミットを他の誰かに
          すでに与えている場合は、これを行ってはいけません。 (そうするこ
          との意味については、 git-rebase(1) の「RECOVERING FROM
          UPSTREAM REBASE」セクションを参照してください。)

Undo a merge or pull
          $ git pull                         (1)
          Auto-merging nitfol
          CONFLICT (content): Merge conflict in nitfol
          Automatic merge failed; fix conflicts and then commit the result.
          $ git reset --hard                 (2)
          $ git pull . topic/branch          (3)
          Updating from 41223... to 13134...
          Fast-forward
          $ git reset --hard ORIG_HEAD       (4)

     See (1).
          アップストリームから更新しようとすると、多くの競合が発生しまし
          た。 あなたは現在、マージに多くの時間を費やす準備ができていな
          かったため、後でマージすることにしました。

     See (2).
          「プル」はマージコミットを行っていないため、 ‘git reset--hard
          HEAD’ の同義語である ‘git reset --hard’ は、インデックスファイ
          ルと作業ツリーから混乱を取り除きます。

     See (3).
          トピックブランチを現在のブランチにマージします。これにより、早
          送り(fast-forward)が行われました。

     See (4).
          しかし、あなたはそのトピックブランチがまだ一般公開の準備ができ
          ていないと判断しました。 「pull」または「merge」は常に現在のブ
          ランチの元の先端を ‘ORIG_HEAD’ に残すため、ハードにリセットす
          るとインデックスファイルと作業ツリーがその状態に戻り、ブランチ
          の先端がそのコミットにリセットされます。

Undo a merge or pull inside a dirty working tree
          $ git pull                         (1)
          Auto-merging nitfol
          Merge made by recursive.
           nitfol                |   20 +++++----
           ...
          $ git reset --merge ORIG_HEAD      (2)

     See (1).
          作業ツリーにローカルの変更がある場合でも、他のブランチの変更が
          それらと重複していないことがわかっている場合は、「git pull」と
          安全に言うことができます。

     See (2).
          マージの結果を調べた後、他のブランチでの変更が不十分であること
          がわかる場合があります。 ‘git reset --hard ORIG_HEAD’ を実行す
          ると、元の場所に戻ることができますが、不要なローカルの変更は破
          棄されます。 ‘git reset --merge’ は、ローカルの変更を保持しま
          す。

Interrupted workflow
     あなたが大規模な変更をしている最中に、緊急の修正リクエストによって
     中断されたとします。 作業ツリー内のファイルはまだコミットできる形で
     はありませんが、バグをすばやく修正するには、他のブランチにアクセス
     する必要があります。

          $ git switch feature  ;# you were working in "feature" branch and
          $ work work work      ;# got interrupted
          $ git commit -a -m "snapshot WIP"                 (1)
          $ git switch master
          $ fix fix fix
          $ git commit ;# commit with real log
          $ git switch feature
          $ git reset --soft HEAD^ ;# go back to WIP state  (2)
          $ git reset                                       (3)

     See (1).
          このコミットは吹き飛ばされちゃうので、投げやりなログメッセージ
          でOKです。

     See (2).
          これにより、コミット履歴から「WIP」コミットが削除され、作業ツ
          リーがスナップショットを作成する直前の状態に設定されます。

     See (3).
          この時点で、インデックスファイルには「スナップショットWIP」と
          してコミットしたすべてのWIP変更がまだ含まれています。 これによ
          り、インデックスが更新され、WIPファイルがコミットされていない
          ものとして表示されます。

          git-stash(1) も参照して下さい。

Reset a single file in the index
     インデックスにファイルを追加したが、後でそれをコミットに追加したく
     ないと判断したとします。 git resetを使用して変更を保持しながら、フ
     ァイルをインデックスから削除できます。

          $ git reset -- frotz.c                      (1)
          $ git commit -m "Commit files in index"     (2)
          $ git add frotz.c                           (3)

     See (1).
          これにより、ファイルは作業ディレクトリに保持されたまま、インデ
          ックスから削除されます。

     See (2).
          これにより、インデックス内の他のすべての変更がコミットされます
          。

     See (3).
          そのファイルをインデックスに再度追加します。

以前のコミットを破棄しつつ作業ツリーの変更を保持する
     何かに取り組んでいて、それをコミットしてから、もう少し作業を続けた
     として、作業ツリーにあるものは、以前にコミットしたものとは関係のな
     い別のブランチにあるはずだと思います。 作業ツリーに変更を加えたまま
     、新しいブランチを開始してリセットできます。

          $ git tag start
          $ git switch -c branch1
          $ edit
          $ git commit ...                            (1)
          $ edit
          $ git switch -c branch2                     (2)
          $ git reset --keep start                    (3)

     See (1).
          これにより、‘branch1’ にあなたの最初の編集がコミットされます。

     See (2).
          理想的な世界では、 あなたが ‘branch2’ (つまり、 ‘git switch -c
          branch2 start’)を作成して切り替えたときに、以前のコミットが新
          しいトピックに属していないことに気付くかもしれませんが、完璧な
          人は誰もいません。

     See (3).
          しかし、 あなたが ‘branch2’ に切り替えた後は、 ‘reset --keep’
          を使用して不要なコミットを削除できます。

Split a commit apart into a sequence of commits
     論理的に別々の変更をたくさん作成し、それらを一緒にコミットしたとし
     ます。 次に、後で、各論理チャンクを独自のコミットに関連付ける方がよ
     い場合があると判断したとします。 あなたが git reset を使用すると、
     ローカルファイルの内容を変更せずに履歴を巻き戻すことができます。そ
     の後、‘git add -p’ を使用して各コミットに含めるハンクを対話的に選択
     し、 ‘git commit -c’ でコミットメッセージをあらかじめ入力しておくこ
     とができます。

          $ git reset -N HEAD^                        (1)
          $ git add -p                                (2)
          $ git diff --cached                         (3)
          $ git commit -c HEAD@{1}                    (4)
          ...                                         (5)
          $ git add ...                               (6)
          $ git diff --cached                         (7)
          $ git commit ...                            (8)

     See (1).
          まず、履歴をあるコミットにリセットして、元のコミットを削除しま
          すが、すべての変更を作業ツリーに残します。 ‘-N’ を使用すると、
          ‘HEAD’ で追加された新しいファイルにマークが付けられ、 ‘git add
          -p’ がそれらを検出できるようになります。

     See (2).
          次に、 私達は ‘git add -p’ 機能を使用して、追加するdiffハンク
          を対話的に選択します。 これにより、各diffハンクについて順番に
          尋ねられ、「はい、これを含める」、「いいえ、これを含めない」、
          または非常に強力な「編集」機能などの簡単なコマンドを使用できま
          す。

     See (3).
          あなたが含めたいハンクに満足したら、 ‘git diff --cached’ を使
          用して、最初のコミットのために何が準備されているかを確認する必
          要があります。 これは、インデックスに移動され、コミットされよ
          うとしているすべての変更を示しています。

     See (4).
          次に、インデックスに保存されている変更をコミットします。 ‘-c’
          オプションは、最初のコミットで開始した元のメッセージからコミッ
          トメッセージを事前入力することを指定します。 これは、再入力を
          避けるのに役立ちます。 ‘HEAD@{1}’ は、元のリセットコミット(1変
          更前)の前に ‘HEAD’ が使用されていたコミットの特別な表記です。
          詳細については、 git-reflog(1) を参照してください。 他の有効な
          コミット参照を使用することもできます。

     See (5).
          あなたは手順2〜4を複数回繰り返して、元のコードを任意の数のコミ
          ットに分割できます。

     See (6).
          さて、あなたは多くの変更をそれぞれのコミットに分割したので、残
          りの未コミットの変更をすべて選択するために、もはや ‘git add’ の
          パッチモードは使用しないかもしれません。

     See (7).
          もう一度、必要なものが含まれていることを確認してください。 ま
          た、git diffにて後でコミットする残りの変更が表示されないことを
          確認することもできます。

     See (8).
          そして最後に最終コミットを作成します。

DISCUSSION
**********

以下の表は、実行時に何が起こるかを示しています:

     git reset --option target

   ファイルの状態に応じて異なるリセットオプションを使用して、 ‘HEAD’ を
別のコミット(‘target’)にリセットします。

   これらの表で、 ‘A’ 、‘B’ 、‘C’ 、‘D’ はファイルのいくつかの異なる状態
を表しています。例えば、最初のテーブルの1行目は、あるファイルが作業ツリ
ーの状態 ‘A’ 、インデックスの状態 ‘B’ 、HEADの状態 ‘C’、ターゲットの状態
‘D’ にある場合、 ‘git reset --soft target’ は作業ツリーの状態 ‘A’ とイン
デックスの状態 ‘B’ を残したままにすることを意味しています。 これは、
‘HEAD’ (つまり、現在のブランチの先端)を ‘target’ (状態 ‘D’ のファイルが
ある)にリセット(つまり移動)するものです。

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      A       B     C    D     --soft   A       B     D
                               --mixed  A       D     D
                               --hard   D       D     D
                               --merge (disallowed)
                               --keep  (disallowed)

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      A       B     C    C     --soft   A       B     C
                               --mixed  A       C     C
                               --hard   C       C     C
                               --merge (disallowed)
                               --keep   A       C     C

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      B       B     C    D     --soft   B       B     D
                               --mixed  B       D     D
                               --hard   D       D     D
                               --merge  D       D     D
                               --keep  (disallowed)

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      B       B     C    C     --soft   B       B     C
                               --mixed  B       C     C
                               --hard   C       C     C
                               --merge  C       C     C
                               --keep   B       C     C

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      B       C     C    D     --soft   B       C     D
                               --mixed  B       D     D
                               --hard   D       D     D
                               --merge (disallowed)
                               --keep  (disallowed)

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      B       C     C    C     --soft   B       C     C
                               --mixed  B       C     C
                               --hard   C       C     C
                               --merge  B       C     C
                               --keep   B       C     C

   ‘reset --merge’ は、競合するマージからリセットするときに使用すること
を目的としています。 マージ操作は、マージに関係する作業ツリーファイルが
、開始前にインデックスに対してローカルな変更がないこと、そしてその結果を
作業ツリーに書き出すことを保証しています。 したがって、インデックスとタ
ーゲットの間、およびインデックスと作業ツリーの間に何らかの違いが見られる
場合、それは、マージ中の操作が競合で失敗した後に残した状態からリセットさ
れていないことを意味します。 そのため、この場合は ‘--merge’ オプションを
使用を許可しません。

   ‘reset --keep’ は、作業ツリーの変更を維持しながら、現在のブランチの最
後のコミットの一部を削除するときに使用することを目的としています。 削除
するコミットの変更と保持する作業ツリーの変更の間に競合が発生する可能性が
ある場合、リセットは許可されません。 そのため、作業ツリーと ‘HEAD’ の間
、および ‘HEAD’ とターゲットの間の両方に変更がある場合、リセットは許可さ
れません。 安全のため、アンマージエントリがある場合もリセットは許可され
ません。

   以下の表は、アンマージエントリがある場合に何が起こるかを示しています:

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      X       U     A    B     --soft  (disallowed)
                               --mixed  X       B     B
                               --hard   B       B     B
                               --merge  B       B     B
                               --keep  (disallowed)

     working index HEAD target         working index HEAD
     ----------------------------------------------------
      X       U     A    A     --soft  (disallowed)
                               --mixed  X       A     A
                               --hard   A       A     A
                               --merge  A       A     A
                               --keep  (disallowed)

   ‘X’ は任意の状態を意味し、 ‘U’ はアンマージインデックスを意味します。

GIT
***

Part of the git(1) suite

Name
****

git-restore — 作業ツリーファイルを復元します

Synopsis
********

     git restore [<options>] [–source=<tree>] [–staged] [–worktree] [–] <pathspec>…
     git restore [<options>] [–source=<tree>] [–staged] [–worktree] –pathspec-from-file=<file> [–pathspec-file-nul]
     git restore (-p|–patch) [<options>] [–source=<tree>] [–staged] [–worktree] [–] [<pathspec>…]

DESCRIPTION
***********

復元ソースからのコンテンツを使用して、作業ツリー内の指定されたパスを復元
します。パスが追跡されているが、復元ソースに存在しない場合、復元ソースと
一致するように削除されます。

   このコマンドを使用して、 ‘--staged’ を使用してインデックスのコンテン
ツを復元したり、 ‘--staged--worktree’ を使用して作業ツリーとインデックス
の両方を復元したりすることもできます。

   デフォルトでは、 ‘--staged’ が指定されている場合、コンテンツは ‘HEAD’
から復元され、そうでない場合はインデックスから復元されます。別のコミット
から復元するには、 ‘--source’ を使用します。

   3つのコマンドの違いについては、 git(1) の "Reset, restore and revert"
を参照してください。

   !!このコマンドは実験的なものです。 動作が変わる可能性があります!!

OPTIONS
*******

‘-s <tree>’
‘--source=<tree>’
     指定のツリーのコンテンツを使用して、作業ツリーファイルを復元します
     。ソースツリーに関連付けられているコミット、ブランチ、またはタグに
     名前を付けてソースツリーを指定するのが一般的です。

     このオプションを指定しない場合で、 ‘--staged’ が指定されている場合
     は ‘HEAD’ から、それ以外の場合はインデックスから内容が復元されます
     。

     特別な場合として、マージベースが1つしかない場合は、 ‘A’ と ‘B’ のマ
     ージベースのショートカットとして ‘A...B’ を使用できます。 ‘A’ と
     ‘B’ の片方を省略できます。その場合、省略した方はデフォルトで ‘HEAD’
     になります。

‘-p’
‘--patch’
     復元ソースと復元場所の違いでハンクを対話的に選択します。 ‘--patch’
     モードの操作方法については、 git-add(1) の「Interactive Mode」セク
     ションを参照してください。

     注意: ‘--patch’ はpathspecを受け入れることができず、変更されたすべ
     てのパスを復元するように求められることに注意してください。

‘-W’
‘--worktree’
‘-S’
‘--staged’
     復元場所を指定します。どちらのオプションも指定されていない場合、デ
     フォルトで作業ツリーが復元されます。 ‘--staged’ を指定すると、イン
     デックスのみが復元されます。両方を指定すると、両方が復元されます。

‘-q’
‘--quiet’
     静かにします。フィードバックメッセージを抑制します。
     ‘--no-progress’ を含んでいます。

‘--progress’
‘--no-progress’
     ‘--quiet’ が指定されていない限り、進行状況は、端末に接続されている
     場合、デフォルトで標準エラーストリームに報告されます。このフラグは
     、 ‘--quiet’ に関係なく、端末に接続されていない場合でも進行状況のレ
     ポートを有効にします。

‘--ours’
‘--theirs’
     作業ツリー内のファイルをインデックスから復元する場合は、マージされ
     ていないパスにステージ#2(_ours_)または#3(_theirs_)を使用します。

     注意: ‘git rebase`と `git pull --rebase’ での作業中、「ours」と「
     theirs」が入れ替わっているように見える場合があることに注意してくだ
     さい。 詳細については、 git-checkout(1) の同じオプションの説明を参
     照してください。

‘-m’
‘--merge’
     作業ツリー上のファイルをインデックスから復元する場合は、マージされ
     ていないパスで競合するマージを再作成してください。

‘--conflict=<style>’
     上記の ‘--merge’ オプションと同じですが、競合するハンクの表示方法を
     変更し、 ‘merge.conflictStyle’ 構成変数をオーバーライドします。 可
     能な値は「merge」(デフォルト)と「diff3」(「merge」スタイルで表示さ
     れるものに加えて、元のコンテンツを表示します)です。

‘--ignore-unmerged’
     作業ツリー上のファイルをインデックスから復元するときに、マージされ
     ていないエントリがあり、 ‘--ours’ 、‘--theirs’ 、 ‘--merge’ または
     ‘--conflict’ のいずれも指定されていない場合は、操作を中止しないでく
     ださい。作業ツリー上のマージされていないパスはそのままになります。

‘--ignore-skip-worktree-bits’
     スパースチェックアウトモード(sparse checkout mode)では、デフォルト
     では、 ‘<pathspec>’ に一致するエントリと、
     $GIT_DIR/info/sparse-checkout のスパースパターンのみが更新されます
     。このオプションは、スパースパターンを無視し、 ‘<pathspec>’ 内のす
     べてのファイルを無条件に復元します。

‘--recurse-submodules’
‘--no-recurse-submodules’
     ‘<pathspec>’ がアクティブなサブモジュールを指定し、復元場所に作業ツ
     リーが含まれている場合、このオプションが指定されている場合にのみサ
     ブモジュールが更新されます。この場合、その作業ツリーはスーパープロ
     ジェクトに記録されたコミットに復元されます。ローカルの変更は上書き
     されます。何も使用されていない場合(または ‘--no-recurse-submodules’
     の場合)、サブモジュールの作業ツリーは更新されません。
     git-checkout(1) と同様に、これはサブモジュールの ‘HEAD’ を切り離し
     ます(detach)。

‘--overlay’
‘--no-overlay’
     オーバーレイモード(overlay mode)では、コマンドは復元時にファイルを
     削除しません。オーバーレイなしモード(no-overlay mode)では、
     ‘--source’ ツリーに表示されない追跡ファイルが削除され、 ‘<tree>’ と
     完全に一致するようになります。 デフォルトはオーバーレイなしモード
     (no-overlay mode)です。

‘--pathspec-from-file=<file>’
     pathspecは、コマンドライン引数の代わりに ‘<file>’ で渡されます。
     ‘<file>’ が正確に ‘-’ の場合、標準入力が使用されます。pathspec要素
     はLFまたはCR/LFで区切られます。pathspec要素は、構成変数
     ‘core.quotePath’ で説明されているように引用できます(git-config(1) 参
     照)。 ‘--pathspec-file-nul’ およびグローバルの
     ‘--literal-pathspecs’ も参照してください。

‘--pathspec-file-nul’
     ‘--pathspec-from-file’ でのみ意味があります。pathspec要素はNUL文字
     で区切られ、他のすべての文字は文字通りに解釈されます(改行と引用符を
     含む)。

‘--’
     これより後ろの引数をオプションとして解釈しないでください。

<pathspec>…
     操作の影響を受けるパスを制限します。

     詳細については、 gitglossary(7) の「pathspec」エントリを参照してく
     ださい。

EXAMPLES
********

以下のシーケンスは、 ‘master’ ブランチに切り替え、‘Makefile’ を2つ前のリ
ビジョンに戻し、誤って hello.c を削除して、インデックスから戻します。

     $ git switch master
     $ git restore --source master~2 Makefile  (1)
     $ rm -f hello.c
     $ git restore hello.c                     (2)

See (1).
     別のコミットからファイルを取り出します

See (2).
     インデックスから hello.c を復元します。

   あなたが、インデックス内のバージョンと一致するように「すべての」Cソー
スファイルを復元する場合は、以下のように書くことができます。

     $ git restore '*.c'

   注意: ‘*.c’ を囲む引用符に注意してください。 ファイル ‘hello.c’ は、
作業ツリーに存在しなくなった場合でも復元されます。これは、ファイルグロブ
がインデックス内のエントリを照合するために使用されるためです(シェルによ
る作業ツリー内ではありません)。

   現在のディレクトリ内のすべてのファイルを復元するには

     $ git restore .

   または、_top_ pathspec魔法を使用してすべての作業ツリーファイルを復元
します(gitglossary(7) 参照)。

     $ git restore :/

   ‘HEAD’ のバージョンと一致するようにインデックス内のファイルを復元する
には(これは git-reset(1) を使用するのと同じです)

     $ git restore --staged hello.c

   または、インデックスと作業ツリーの両方を復元できます(これは、
git-checkout(1) を使用する場合と同じです)。

     $ git restore --source=HEAD --staged --worktree hello.c

   または、より実用的で読みにくい短い形式:

     $ git restore -s@ -SW hello.c

SEE ALSO
********

git-checkout(1), git-reset(1)

GIT
***

Part of the git(1) suite

Name
****

git-rev-list — コミットオブジェクトを新しい順に一覧表示します

Synopsis
********

     git rev-list [<options>] <commit>… [[–] <path>…]

DESCRIPTION
***********

指定されたコミットから「親」リンクをたどることによって到達可能なコミット
をリストしますが、その前に ^ が付いているコミットから到達可能なコミット
は除外します。デフォルトでは、出力は時系列の逆順で表示されます。

   これは集合演算と考えることができます。 コマンドラインで指定されたコミ
ットのいずれかから到達可能なコミットのセットを形成し、 ^ が前に付いたコ
ミットのいずれかから到達可能なコミットがそのセットから差し引かれます。差
し引かれた残りのコミットは、コマンドの出力に出力されるものです。他のさま
ざまなオプションとパスパラメータ(pats parameters)を使用して、結果をさら
に制限できます。

   したがって、以下のコマンド:

     $ git rev-list foo bar ^baz

   は、「foo または bar から到達可能であるが、 baz からは到達できないす
べてのコミットをリストする」を意味します。

   特別な表記 ‘<commit1>..<commit2>’ は、 ‘^<commit1> <commit2>’ の省略
形として使用できます。たとえば、以下のどちらかを同じ意味で使用できます:

     $ git rev-list origin..HEAD
     $ git rev-list HEAD ^origin

   もう1つの特別な表記法は、マージに役立つ ‘<commit1>...<commit2>’ です
。結果として得られるコミットのセットは、2つのオペランド間の対称差
(symmetric difference)です。以下の2つのコマンドは同等です:

     $ git rev-list A B --not $(git merge-base --all A B)
     $ git rev-list A...B

   ’rev-list’は、コミットの祖先グラフ作成およびトラバースする機能を提供
するため、非常に重要なGitコマンドです。 このため、’git bisect’や’git
repack’などのさまざまなコマンドで使用できるようにするさまざまなオプショ
ンがあります。

OPTIONS
*******

Commit Limiting
===============

ここで説明されている特別な表記法を使用してリストする必要があるコミットの
範囲を指定することに加えて、追加のコミット制限が適用される場合があります
。

   より多くのオプションを使用すると、通常、出力がさらに制限されます(たと
えば、‘--since=<date1>`は’<date1>‘より新しいコミットに制限され、
’–grep=<pattern>‘と一緒に使用すると、ログメッセージに’<pattern>‘と一致す
る行があるコミットにさらに制限されます)。

   注意: これらは、‘–reverse‘などのコミット順序およびフォーマットオプシ
ョンの前に適用されることに注意してください。

‘-<number>’
‘-n <number>’
‘--max-count=<number>’
     出力するコミットの数を制限します。

‘--skip=<number>’
     コミット出力の表示を開始する前に、number 個のコミットをスキップしま
     す。

–since=<date>
‘--after=<date>’
     指定の日付よりも新しいコミットを表示します。

‘--until=<date>’
‘--before=<date>’
     指定の日付より古いコミットを表示します。

‘--max-age=<timestamp>’
‘--min-age=<timestamp>’
     コミット出力を指定された時間範囲に制限します。

‘--author=<pattern>’
‘--committer=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致する作者
     (author)/コミッター(committer)ヘッダー行を持つものに制限します。複
     数の ‘--author=<pattern>’ がある場合、作者が指定されたパターンのい
     ずれかに一致するコミットが選択されます(複数の
     ‘--committer=<pattern>’ の場合も同様)。

‘--grep-reflog=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致するreflogエント
     リを持つものに制限します。複数の‘–grep-reflog‘を使用すると、指定さ
     れたパターンのいずれかに一致するreflogメッセージを持つコミットが選
     択されます。‘–walk-reflogs‘が使用されていない限り、このオプションを
     使用するとエラーになります。

‘--grep=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致するログメッセー
     ジを持つものに制限します。複数の‘–grep=<pattern>‘を使用すると、指定
     されたパターンのいずれかにメッセージが一致するコミットが選択されま
     す(全てに一致するコミットだけを選択したい場合、’–all-match‘を参照し
     てください)。

‘--all-match’
     コミット出力を、少なくとも1つに一致するものではなく、指定されたすべ
     ての‘–grep‘に一致するものに制限します。

‘--invert-grep’
     コミット出力を、‘–grep=<pattern>‘で指定されたパターンと一致しないロ
     グメッセージを持つものに制限します。

‘-i’
‘--regexp-ignore-case’
     大文字小文字に関係なく、正規表現の制限パターンに一致します。

‘--basic-regexp’
     制限パターンを基本正規表現として扱います。これがデフォルトです。

‘-E’
‘--extended-regexp’
     制限パターンを、デフォルトの基本正規表現の代わりに拡張正規表現とし
     て扱います。

‘-F’
‘--fixed-strings’
     制限パターンを固定文字列として扱います(パターンを正規表現として解釈
     しないでください)。

‘-P’
‘--perl-regexp’
     制限パターンをPerl互換の正規表現として扱います。

     これらのタイプの正規表現のサポートは、コンパイル時オプションに依存
     します。Gitが当該のサポート付きでコンパイルされていない場合、このオ
     プションを提供すると、Gitが死にます(die)。

‘--remove-empty’
     指定されたパスがツリーから見えなくなったら停止(stop)します。

‘--merges’
     マージコミットのみを印刷します。これは‘–min-parents=2‘とまったく同
     じです。

‘--no-merges’
     複数の親を持つコミットを出力しない。これは‘–max-parents=1‘とまった
     く同じです。

‘--min-parents=<number>’
‘--max-parents=<number>’
‘--no-min-parents’
‘--no-max-parents’
     量の多少に関わらず、とにかく複数の親コミットがあるコミットのみを表
     示します。特に、‘--max-parents=1`は’–no-merges‘と同じであり、
     ‘--min-parents=2`は’–merges‘と同じです。‘--max-parents=0`はすべての
     ルートコミットを提供し、’–min-parents=3‘はすべてのタコ足マージ
     (octopus merges)を示します。

     ‘--no-min-parents`と’–no-max-parents‘は、これらの制限を(制限なしに
     )再度リセットします。同等の形式は、‘--min-parents=0’(すべてのコミッ
     トに0個以上の親があります)および‘–max-parents=-1‘(マイナスの数は上
     限がないことを示します)です。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを探索します。この
     オプションは、特定のトピックブランチの進化を表示するときに、より良
     い概要を提供できます。トピックブランチへのマージは、時々更新される
     アップストリームに調整することだけである傾向があり、このオプション
     を使用すると、そのようなマージによって履歴に取り込まれた個々のコミ
     ットを無視できます。

‘--not’
     次に現れる ‘--not’ までの間、後続のすべてのリビジョン指定子の ‘^’(カ
     レット)接頭辞(またはその欠如)の意味を逆にします。

‘--all’
     ‘refs/’ 内のすべてのrefが HEAD とともに、コマンドラインに <commit>
     としてリストされているかのように見せかけます。

‘--branches[=<pattern>]’
     ‘refs/heads’ 内のすべてのrefがコマンドラインに <commit> としてリス
     トされているかのように見せかけます。 <pattern> が指定されている場合
     、ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限
     します。パターンに "?" または "*" または "[" がない場合、最後に
     "/*" が含まれます。

‘--tags[=<pattern>]’
     ‘refs/tags’ 内のすべてのrefがコマンドラインに <commit> としてリスト
     されているかのように見せかけます。 <pattern> が指定されている場合は
     、指定されたシェルグロブ(shell glob)に一致するタグにタグを制限しま
     す。パターンに "?" または "*" または "[" がない場合、最後に "/*" が
     含まれます。

‘--remotes[=<pattern>]’
     ‘refs/remotes’ 内のすべてのrefがコマンドラインに <commit> としてリ
     ストされているかのように見せかけます。 <pattern> が指定されている場
     合、リモート追跡ブランチを指定されたシェルグロブ(shell glob)に一致
     するものに制限します。パターンに "?" または "*" または "[" がない場
     合、最後に "/*" が含まれます。

‘--glob=<glob-pattern>’
     シェルグロブ <glob-pattern> に一致するすべてのrefがコマンドラインに
     <commit> としてリストされているかのように見せかけます。先頭の
     ‘refs/’ は、欠落している場合は自動的に先頭に追加されます。パターン
     に "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

‘--exclude=<glob-pattern>’
     次の ‘--all’ または ‘--branches’ または ‘--tags’ または ‘--remotes’
     または ‘--glob’ が別の方法で考慮する <glob-pattern> に一致するrefを
     含めないでください。このオプションを繰り返すと、次の ‘--all’ または
     ‘--branches’ または ‘--tags’ または ‘--remotes’ または ‘--glob’ オ
     プションまで除外パターンが蓄積されます(他のオプションまたは引数は、
     蓄積されたパターンをクリアしません)。

     与えられたパターンは、それぞれ ‘--branches’ または ‘--tags’ または
     ‘--remotes’ に適用される場合、 ‘refs/heads’ または ‘refs/tags’ また
     は ‘refs/remotes’ で始まるべきではありません。 ‘--glob’ または
     ‘--all’ に適用する場合は、 ‘refs/’ で始める必要があります。末尾の
     "/*" を意図している場合は、明示的に指定する必要があります。

‘--reflog’
     reflogsで言及されているすべてのオブジェクトがコマンドラインに
     <commit> としてリストされているかのように見せかけます。

‘--alternate-refs’
     代替リポジトリのref先端として言及されているすべてのオブジェクトがコ
     マンドラインにリストされているかのように見せかけます。代替リポジト
     リは、オブジェクトディレクトリが‘objects/info/alternates‘で指定され
     ているリポジトリです。インクルードされたオブジェクトのセットは、
     ‘core.alternateRefsCommand‘などによって変更できます。
     git-config(1)を参照してください。

‘--single-worktree’
     デフォルトでは、作業ツリーが複数ある場合、‘--all`と’-reflog‘と
     ‘–indexed-objects‘では、すべての作業ツリーが検査されます
     (git-worktree(1)を参照)。このオプションは、現在の作業ツリーのみを調
     べるように強制します。

‘--ignore-missing’
     入力に無効なオブジェクト名が含まれている場合、そもそもその不正な入
     力が行われていないかのように見せかけます。

‘--stdin’
     コマンドラインにリストされている <commit> に加えて、標準入力からそ
     れらを読み取ります。 ‘--’ 区切り文字が表示された場合は、コミットの
     読み取りを停止し、パスの読み取りを開始して結果を制限します。

‘--quiet’
     標準出力には何も出力しないでください。この形式は主に、呼び出し元が
     終了ステータスをテストして、オブジェクトの範囲が完全に接続されてい
     るかどうかを確認できるようにすることを目的としています。出力をフォ
     ーマットする必要がないため、stdoutを‘/dev/null‘にリダイレクトするよ
     りも高速です。

‘--disk-usage’
     通常の出力を抑制します。代わりに、選択したコミットまたはオブジェク
     トによってディスク上のストレージに使用されたバイトの合計を出力しま
     す。これは、出力が(特に ‘--use-bitmap-index’ を伴った場合)はるかに
     高速に実行されることを除いて、出力を ‘git cat-file
     --batch-check='%(objectsize:disk)'’ にパイプすることと同じです。
     "on-disk storage" の意味する制限については、 git-cat-file(1) の「
     CAVEATS」を参照してください。

‘--cherry-mark’
     ‘--cherry-pick’（以下を参照）と同様ですが、同等のコミットを省略せず
     に ‘=’ と印し、同等でないコミットを ‘+’ と印します。

‘--cherry-pick’
     コミットの組を対称差(symmetric difference)に制限する場合、「反対側
     」の別のコミットと同じ変更を導入するコミットを省略します。

     たとえば、‘A’ と ‘B’ の2つのブランチがある場合、それらの片側だけで
     すべてのコミットを一覧表示する通常の方法は、 ‘--left-right’ を使用
     することです(‘--left-right’ オプションの説明の以下の例を参照してく
     ださい)。ただし、他のブランチからは(ブランチAと重複しない)厳選され
     たコミットが表示されます(たとえば、「3rd onb」はブランチAからチェリ
     ーピックされる可能性があります)。このオプションを使用すると、そのよ
     うなコミットのペアは出力から除外されます。

‘--left-only’
‘--right-only’
     リストは、対称差のそれぞれの側でのみコミットします。つまり、
     ‘--left-right`で `<’ と印されるのだけか、あるいは‘–left-right‘で
     ‘>‘と印されるものだけです。

     たとえば、‘--cherry-pick --right-only A...B`は、`A`にある、または
     `A`のコミットとパッチと同等のコミットを`B`から省略します。つまり、
     これは`git cherry A B`からの’+‘コミットをリストします。より正確に書
     くと、’–cherry-pick –right-only –no-merges‘により正確なリストを提供
     します。

‘--cherry’
     ‘–right-only –cherry-mark –no-merges‘の同義語です。出力を私たちの側
     のコミットに制限し、フォークされた履歴の反対の側に適用されたものを
     、‘git cherry upstream mybranch‘と同様に‘git log –cherry
     upstream…mybranch‘で印するのに役立ちます。

‘-g’
‘--walk-reflogs’
     コミットの祖先チェーンをたどる代わりに、reflogエントリを最新のもの
     から古いものに移動します。このオプションを使用する場合、除外するコ
     ミットを指定することはできません(つまり、 "^commit" や
     ‘commit1..commit2’ や ‘commit1...commit2’ 表記は使用できません)。

     (明らかな理由で、)‘oneline`と`reference`以外の’–pretty‘形式では、こ
     れにより、出力にreflogから取得された2行の追加情報が含まれます。出力
     のreflog指定子は、‘ref@{Nth}’ (‘Nth’ はreflogの逆時系列インデックス
     (reverse-chronological index))または ‘ref@{timestamp}’ (そのエント
     リのタイムスタンプ付き)として表示されます。表示は下記のいくつかのル
     ールに依存します:

       1. 開始点が ‘ref@{Nth}’ として指定されている場合は、インデックス
          形式を表示します。

       2. 開始点が ‘ref@{now}’ として指定されている場合は、タイムスタン
          プ形式を表示します。

       3. 上記のどちらも使用されていないが、コマンドラインで‘–date‘が指
          定されている場合は、‘–date‘で要求された形式でタイムスタンプを
          表示します。

       4. それ以外の場合は、インデックス形式を表示します。

     ‘--pretty = oneline`では、コミットメッセージの前にこの情報が同じ行
     に付けられます。このオプションを’–reverse‘と組み合わせることはでき
     ません。git-reflog(1)も参照してください。

     ‘–pretty=reference‘では、この情報はまったく表示されません。

‘--merge’
     マージが失敗した後、競合があり、マージするすべてのheadに存在しない
     ファイルに関連(touch)するrefを表示します。

‘--boundary’
     除外された境界コミットを出力します。 境界コミットの前には ‘-‘が付い
     ています。

‘--use-bitmap-index’
     (使用可能な場合は、)パックビットマップインデックスを使用して、トラ
     バーサルを高速化しようと試みます。‘–objects‘でトラバースする場合、
     ツリーとブロブには関連するパスが出力されないことに注意してください
     。

‘--progress=<header>’
     オブジェクトが対称になるときに、stderrに進捗レポートを表示します。
     ‘<header>‘テキストは、進行状況が更新されるたびに印刷されます。

History Simplification
======================

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があり
ます。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成
ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つは
コミットの選択であり、もう1つはそれを行う方法です。

   以下のオプションは、表示するコミットを選択します:

<paths>
     指定された<パス>を変更するコミットが選択されます。

‘--simplify-by-decoration’
     いくつかのブランチまたはタグによって参照されるコミットが選択されま
     す。

   注意: 意味のある重要な履歴のために、追加のコミットを表示できることに
注意してください。

   以下のオプションは、簡略化の実行方法に影響します。

Default mode
     履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最
     終結果が同じである場合(つまり、同じコンテンツのブランチをマージする
     場合)、いくつかの傍流ブランチ(side branches)を削除するため、最も単
     純です。

‘--show-pulls’
     デフォルトモードからのすべてのコミットを含めますが、最初の親への
     TREESAMEではなく、後の親へのTREESAMEであるマージコミットも含めます
     。このモードは、ブランチに変更を「最初に導入した」マージコミットを
     表示するのに役立ちます。(訳注:TREESAME=pathspecが全く同一であるツリ
     ー)

‘--full-history’
     デフォルトモードと同じですが、一部の履歴を削除しません。

‘--dense’
     選択したコミットのみが表示され、重大で意味のある履歴を持つコミット
     もいくつか表示されます。

‘--sparse’
     簡略化された履歴内のすべてのコミットが表示されます。

‘--simplify-merges’
     このマージに寄与する選択されたコミットがないため、結果の履歴からい
     くつかの不要なマージを削除するための‘–full-history‘への追加オプショ
     ン。

‘--ancestry-path’
     表示するコミットの範囲が指定されている場合(たとえば、
     ‘commit1..commit2’ または "commit2 ^commit1")、 commit1 と commit2
     の間の祖先チェーンに直接存在するコミットのみ、つまり、 commit1 の子
     孫であり、 commit2 の祖先であるコミットを表示します。

   より詳細な説明は以下のとおりです。

   <paths> として ‘foo’ を指定したとします。 ‘foo’ !TREESAME を変更する
コミットを呼び出し、残りをTREESAMEと呼びます。( ‘foo’ のためにフィルタリ
ングされた差分では、それぞれ異なって見えたりたり等しく見えたりします。）

   以下、簡略化設定の違いを説明するために、同じ履歴例を使います。このコ
ミットグラフでは、ファイル ‘foo’ をフィルタリングしていると想定していま
す:

               .-A---M---N---O---P---Q
              /     /   /   /   /   /
             I     B   C   D   E   Y
              \   /   /   /   /   /
               `-------------'   X

   履歴 A—Q の水平線は、各マージの最初の親と見なされます。その各コミット
は以下のとおりです:

   • ‘I’ は最初のコミットであり、ファイル foo が内容 “asdf” で存在し、フ
     ァイル quux は内容 “quux” で存在します。最初のコミットは空のツリー
     と比較されるため、‘I’ は !TREESAME です。

   • ‘A’ では、 foo には “foo” だけが含まれています。

   • ‘B’ には ‘A’ と同じ変更が含まれています。そのマージ ‘M’ は些細なこ
     とであり、したがってすべての親にとって TREESAME です。

   • ‘C’ は ‘foo’ を変更しませんが、そのマージ ‘N’ はそれを “foobar” に
     変更するので、どの親にとっても TREESAME ではありません。

   • ‘D’ は ‘foo’ を “baz” に設定します。そのマージ ‘O’ は、 ‘N’ と ‘D’
     から “foobarbaz” への文字列を結合します。つまり、どの親にとっても
     TREESAME ではありません。

   • ‘E’ は ‘quux’ を “xyzzy” に変更し、そのマージ ‘P’ は文字列を
     “quuxxyzzy” に結合します。 ‘P’ は ‘O’ に対して TREESAME ですが、
     ‘E’ に対してはそうではありません。

   • ‘X’ は、新ファイル ‘side’ を追加し、 ‘Y’ がそれを変更した独立したル
     ートコミットです。 ‘Y’ は ‘X’ へのTREESAMEです。そのマージ ‘Q’ は
     ‘P’ に ‘side’ を追加し、 ‘Q’ は ‘P’ にはTREESAMEですが、‘Y’ に対し
     てはそうではありません。

   ‘rev-list’ は、 ‘--full-history’ および/または、( ‘--parents’ または
‘--children’ を介して)親の書き換えが使用されているかどうかに基づいて、コ
ミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下
の設定が可能です。

Default mode
     コミットは、どの親に対してもTREESAMEでない場合に含まれます(これは変
     更できますが、以下の ‘--sparse’ を参照してください)。コミットがマー
     ジであり、一方の親に対するTREESAMEであった場合は、その親のみをフォ
     ローします。(TREESAMEの親が複数ある場合でも、そのうちの1つだけをフ
     ォローします)。それ以外の場合は、すべての親をフォローします。

     これにより、以下のようになります:

                    .-A---N---O
                   /     /   /
                  I---------D

     TREESAMEの親のみに従うルールが利用可能な場合は、 ‘B’ を検討対象から
     完全に削除したことに注意してください。 ‘C’ は ‘N’ を介して考慮され
     ましたが、しかしそれはTREESAMEです。ルートコミットは空のツリーと比
     較されるため、 ‘I’ は !TREESAME です。

     親子関係は ‘--parents’ でのみ表示されますが、デフォルトモードで選択
     されたコミットには影響しないため、親の行を示しました。

‘--full-history without parent rewriting’
     このモードは、デフォルトとはある一点で異なります。つまり、いずれか
     の親に対してTREESAMEであっても、常にマージのすべての親に従います。
     マージの複数の側にコミットが含まれている場合でも、これはマージ自体
     が含まれていることを意味するものではありません！ 例では以下のように
     なります。

                  I  A  B  N  D  O  P  Q

     ‘M’ は、両方の親にとってTREESAMEであるため、除外されました。 ‘E’ と
     ‘C’ と ‘B’ をすべて巡りましたが、 ‘B’ だけが !TREESAME だったので、
     他は表示されません。

     注意: 親の書き換え(rewrite)がないと、コミット間の親子関係について話
     す(talk)ことは実際には不可能であるため、それらが切断されている
     (disconnected)ことを示していることに注意してください。

‘--full-history with parent rewriting’
     通常のコミットは !TREESAME の場合にのみ含まれます(これは変更できま
     すが、以下の ‘--sparse’ を参照してください)。

     マージは常に含まれます。ただし、親リストは書き直されます。各親に沿
     って、自分自身に含まれていないコミットを削除します。 これにより以下
     のようになります。

                    .-A---M---N---O---P---Q
                   /     /   /   /   /
                  I     B   /   D   /
                   \   /   /   /   /
                    `-------------'

     上記を書き直さずに ‘--full-history’ と比較してください。 ‘E’ は
     TREESAMEであるため削除されましたが、Pの親リストは ‘E’ の親 ‘I’ を含
     むように書き直されていることに注意してください。 ‘C’ と ‘N’ および
     ‘X’ と ‘Y’ と ‘Q’ についても同じことが起こりました。

   上記の設定に加えて、あなたはTREESAMEが包含に影響を与えるかどうかを変
更できます:

‘--dense’
     巡ったコミットは、親にとってTREESAMEでない場合に含まれます。

‘--sparse’
     巡ったすべてのコミットが含まれます。

     ‘--full-history’ がなくても、これによりマージが単純化されることに注
     意してください。親の1つがTREESAMEの場合、その1つだけに従うため、マ
     ージの反対側を巡ることはありません。

‘--simplify-merges’
     最初に、親を書き換えた ‘--full-history’ と同じ方法で履歴グラフを作
     成します(上記を参照)。

     それから、以下のルールに従って、各コミット ‘C’ を最終履歴内の置換
     ‘C'’ に単純化します:

        • ‘C'’ を ‘C’ にセットします。

        • ‘C'’ の各親 ‘P’ をその簡略化された ‘P'’ に置き換えます。その過
          程で、他の親の祖先であるか、ルートである親を削除すると、
          TREESAMEが空のツリーにコミットされ、重複が削除されますが、
          TREESAMEであるすべての親を削除しないように注意してください。

        • この親の書き換え後、 ‘C'’ がルートまたはマージコミット(0または
          >1 の親を持つ)、境界コミット、または !TREESAMEである場合、それ
          は残ります。それ以外の場合は、唯一の親に置き換えられます。

     この効果は、親の書き換えを使用した ‘--full-history’ と比較すること
     で最もよく示されます。例は以下のようになります:

                    .-A---M---N---O
                   /     /       /
                  I     B       D
                   \   /       /
                    `---------'

     注意: ‘--full-history’ に対する ‘N’ と ‘P’ と ‘Q’ の主な違いに注意
     してください:

        • ‘N’ の親リストは、他の親 ‘M’ の祖先であるため、 ‘I’ が削除され
          ました。それでも、 !TREESAME なので ‘N’ が残りました。

        • ‘P’ の親リストも同様に ‘I’ が削除されました。 ‘P’ は、親が1つ
          で TREESAMEであるため、完全に削除されました。

        • ‘Q’ の親リストでは、 ‘Y’ が ‘X’ に簡略化されていました。その後
          、 ‘X’ はTREESAMEルートであったため、削除されました。 ‘Q’ は、
          親が1つで TREESAMEであるため、完全に削除されました。

   利用可能な別の簡略化モードがあります:

‘--ancestry-path’
     表示されるコミットを、指定されたコミット範囲内の “from” コミットと
     “to” コミットの間の祖先チェーンに直接あるコミットに制限します。つま
     り、 “to” コミットの祖先であるコミットと “from” コミットの子孫であ
     るコミットのみを表示します。

     ユースケースの例として、以下のコミット履歴について考えます:

                      D---E-------F
                     /     \       \
                    B---C---G---H---I---J
                   /                     \
                  A-------K---------------L--M

     通常の ‘D..M’ は、 ‘M’ の祖先であるコミットのセットを計算しますが、
     ‘D’ の祖先であるコミットは除外します。 これは、「 ‘M’ には ‘D’ には
     存在しなかったものがある」という意味で、 ‘D’ 以降の ‘M`に至るまでの
     歴史に何が起こったのかを知るのに役立ちます。この例の結果は、 `A’ と
     ‘B’ (そしてもちろん ‘D’ 自体)を除くすべてのコミットになります。

     ただし、 ‘M’ のコミットが ‘D’ で入ったバグで汚染されており、修正が
     必要な場合は、実際には ‘D’ の子孫である ‘D..M’ のサブセットのみを表
     示する必要があります。つまり、 ‘C’ と ‘K’ を除外します。これはまさ
     に ‘--ancestry-path’ オプションが行うことです。これを ‘D..M’ 範囲に
     適用すると、以下のようになります:

                          E-------F
                           \       \
                            G---H---I---J
                                         \
                                          L--M

   別のオプション ‘--show-pulls’ について説明する前に、新しいサンプル履
歴を作成する必要があります。

   簡略化された履歴を見るときにユーザーが直面する一般的な問題は、ファイ
ルを変更したことがわかっているコミットが、ファイルの簡略化された履歴に表
示されないことです。そこで、新しい例を示し、その場合に ‘--full-history’
や ‘--simplify-merges’ などのオプションがどのように機能するかを示しまし
ょう。

               .-A---M-----C--N---O---P
              /     / \  \  \/   /   /
             I     B   \  R-'`-Z'   /
              \   /     \/         /
               \ /      /\        /
                `---X--'  `---Y--'

   この例では、 ‘I’ が ‘file.txt’ を作成し、それが ‘A’ と‘B‘ と ‘X’ にて
さまざまな方法で変更されたとします。ひとり親のコミット ‘C’ と ‘Z’ と ‘Y’
は ‘file.txt’ を変更していません。マージコミット ‘M’ は、マージの競合を
解決して、 ‘A’ と ‘B’ の両方の変更を含めることによって作成されたため、ど
ちらにもTREESAMEではありません。ただし、マージコミット ‘R’ は、 ‘M’ の
‘file.txt`の内容を無視し、 `X’ の ‘file.txt’ の内容のみを取得することに
よって作成されました。 したがって、 ‘R’ は ‘X’ へのTREESAMEですが、 ‘M’
はそうではありません。最後に、 ‘N’ を作成するための自然なマージ解決は、
‘R’ で ‘file.txt’ の内容を取得することです。したがって、 ‘N’ は ‘C’ では
なく ‘R’ へのTREESAMEです。マージコミット ‘O’ と ‘P’ は、最初の親には
TREESAMEですが、2番目の親である ‘Z’ と ‘Y’ にはついてはそうではありませ
ん。

   デフォルトモードを使用する場合、 ‘N’ と ‘R’ は両方ともTREESAMEの親を
持っているため、これらのエッジはウォークされ、他のエッジは無視されます。
結果の履歴グラフは以下のとおりです:

             I---X

   ‘--full-history’ を使用する場合、Gitはすべてのエッジを巡ります。これ
により、コミット ‘A’ と ‘B’ と マージ ‘M’ が検出されますが、マージコミッ
ト ‘O’ と ‘P’ も明らかになります。 親を書き換えると、結果のグラフは以下
のようになります:

               .-A---M--------N---O---P
              /     / \  \  \/   /   /
             I     B   \  R-'`--'   /
              \   /     \/         /
               \ /      /\        /
                `---X--'  `------'

   ここで、マージコミット ‘O’ と ‘P’ は、実際には ‘file.txt’ への変更を
提供しなかったため、余分なノイズを提供します。古いバージョンの
‘file.txt’ に基づいたトピックのみをマージしました。これは、多くの寄稿者
が並行して作業し、トピックブランチを単一のトランクに沿ってマージするワー
クフローを使用するリポジトリの一般的な問題です。開発に関係のないマージが
‘--full-history’ の結果に表示されます。

   ‘--simplify-merges’ オプションを使用すると、コミット ‘O’ と ‘P’ が結
果から消えます。 これは、 ‘O’ と ‘P’ の書き直された2番目の親が、最初の親
から到達可能であるためです。これらのエッジが削除されると、コミットは、親
にとってTREESAMEである単一の親のコミットのように見えます。これはコミット
‘N’ にも発生し、以下のような履歴ビューが表示されます:

               .-A---M--.
              /     /    \
             I     B      R
              \   /      /
               \ /      /
                `---X--'

   このビューでは、 ‘A’ と ‘B’ と ‘X’ からの重要なひとり親の変更がすべて
表示されます。また、慎重に解決されたマージ ‘M’ とそれほど慎重に解決され
ていないマージ ‘R’ も表示されます。これは通常、コミット ‘A’ と ‘B’ がデ
フォルトのビューの履歴から「消えた」理由を判断するのに十分な情報です。た
だし、このアプローチにはいくつかの問題があります。

   最初の問題はパフォーマンスです。以前のオプションとは異なり、
‘--simplify-merges’ オプションでは、単一の結果を返す前にコミット履歴全体
をウォークする必要があります。これにより、非常に大規模なリポジトリでこの
オプションを使用するのが難しくなる可能性があります。

   2番目の問題は監査の1つです。多くの寄稿者が同じリポジトリで作業してい
る場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。
上記の問題のあるマージ ‘R’ は、重要なブランチにマージするために使用され
たマージコミットではない可能性があります。 代わりに、マージ ‘N’ を使用し
て ‘R’ と ‘X’ を重要なブランチにマージしました。このコミットには、変更
‘X’ がコミットメッセージの ‘A’ と ‘B’ からの変更を上書きするようになった
理由に関する情報が含まれている可能性があります。

‘--show-pulls’
     デフォルトの履歴に表示されるコミットに加えて、最初の親には
     TREESAMEではなく、後の親にはTREESAMEである各マージコミットを表示し
     ます。

     マージコミットが ‘--show-pulls’ に含まれている場合、マージは別のブ
     ランチから変更を「プル」したかのように扱われます。この例で
     ‘--show-pulls’ を使用すると(他のオプションは使用しない場合、)結果の
     グラフは行かのようになります:

                  I---X---R---N

     ここで、コミット ‘X’ と ‘R’ をそれぞれベースブランチにプルしたため
     、マージコミット ‘R’ と ‘N’ が含まれています。これらのマージは、コ
     ミット ‘A’ と ‘B’ がデフォルトの履歴に表示されない理由です。

     ‘--show-pulls’ が ‘--simplify-merges’ とペアになっている場合、グラ
     フには必要なすべての情報が含まれます:

                    .-A---M--.   N
                   /     /    \ /
                  I     B      R
                   \   /      /
                    \ /      /
                     `---X--'

     ‘M’ は ‘R’ から到達可能であるため、 ‘N’ から ‘M’ へのエッジが単純化
     されていることに注意してください。ただし、 ‘N’ は、変更 ‘R’ をメイ
     ンブランチに「プル」したため、重要なコミットとして履歴に表示されま
     す。

   ‘--simplify-by-decoration’ オプションを使用すると、タグで参照されてい
ないコミットを省略して、履歴のトポロジの全体像のみを表示できます。コミッ
トは、(1)タグによって参照されている場合、または (2)コマンドラインで指定
されたパスの内容を変更した場合に、!TREESAMEとしてマークされます(つまり、
上記の履歴簡略化ルールの後に保持されます)。他のすべてのコミットは
TREESAMEとしてマークされます(簡略化される可能性があります)。

Bisection Helpers
=================

‘--bisect’
     含まれるコミットと除外されるコミットのほぼ中間にある1つのコミットオ
     ブジェクトに出力を制限します。(存在する場合)bad bisection ref
     ‘refs/bisect/bad’ が含まれるコミットに追加され、（存在する場合)good
     bisection ref ‘refs/bisect/good-*’ が除外されるコミットに追加される
     ことに注意してください。したがって、 ‘refs/bisect/’ にrefsがないと
     仮定すると、

                  $ git rev-list --bisect foo ^bar ^baz

     は、2つのコマンドの出力である中間点(midpoint)を出力します

                  $ git rev-list foo ^midpoint
                  $ git rev-list midpoint ^bar ^baz

     上記は、ほぼ同じ長さになります。 したがって、回帰を導入する変更を見
     つけることは、バイナリ検索(binary search)に還元されます。コミットチ
     ェーンの長さが1になるまで、新しい中間点(midpoint)を繰り返し生成して
     テストします。

‘--bisect-vars’
     これは、 ‘refs/bisect/’ 内のrefが使用されないこと、およびシェルによ
     って評価される準備ができているテキストを出力することを除いて、
     ‘--bisect’ と同じように計算されます。これらの行は、中間点リビジョン
     の名前を変数 ‘bisect_rev’ に割り当て、 ‘bisect_rev’ が ‘bisect_nr’
     にテストされた後にテストされるコミットの予想数、 ‘bisect_rev’ が
     ‘bisect_good`に適していることが判明した場合にテストされるコミットの
     予想数、 `bisect_rev’ が ‘bisect_bad’ に不適切であることが判明した
     場合にテストされるコミットの予想数、および現在 ‘bisect_all’ に二等
     分しているコミットの数です。

‘--bisect-all’
     これにより、含まれるコミットと除外されるコミットの間のすべてのコミ
     ットオブジェクトが、含まれるコミットと除外されるコミットまでの距離
     順に出力されます。 ‘refs/bisect/’ のrefは使用されません。それらから
     最も遠いものが最初に表示されます。(これは ‘--bisect’ によって表示さ
     れる唯一のものです。)

     これは、何らかの理由(たとえば、コンパイルできない場合など)でそれら
     の一部をテストすることを避けたい場合に、テストするための適切なコミ
     ットを簡単に選択できるため便利です。

     このオプションは ‘--bisect-vars’ と一緒に使用できます。この場合、ソ
     ートされたすべてのコミットオブジェクトの後に、 ‘--bisect-vars’ が単
     独で使用された場合と同じテキストが表示されます。

Commit Ordering
===============

デフォルトでは、コミットは新しい順に表示されます。

‘--date-order’
     すべての子が表示されるまで親を表示しませんが、それ以外の場合はコミ
     ットタイムスタンプの順序でコミットを表示します。

‘--author-date-order’
     すべての子が表示されるまで親を表示しませんが、それ以外の場合は、作
     者(author)のタイムスタンプ順にコミットを表示します。

‘--topo-order’
     すべての子が表示されるまで親を表示せず、複数の履歴行が混在するコミ
     ットを表示しないようにします。

     たとえば、以下のようなコミット履歴があります:

              ---1----2----4----7
                  \              \
                   3----5----6----8---

     ここで、数字はコミットタイムスタンプの順序を示し、 ‘gitrev-list’ と
     ‘--date-order’ のある友達は、タイムスタンプの順序でコミットを示しま
     す。つまり、8 7 6 5 4 3 2 1

     ‘--topo-order’ を使用すると、8 6 5 3 7 4 2 1（または8 7 4 2 6 5 3
     1）が表示されます。2つの並列開発トラックからのコミットが混在して表
     示されないようにするために、いくつかの古いコミットが新しいコミット
     の前に表示されます。

‘--reverse’
     表示するように選択したコミットを逆の順序で出力します(上記の Commit
     Limiting 節を参照)。 ‘--walk-reflogs’ と組み合わせることはできませ
     ん。

Object Traversal
================

これらのオプションは、主にGitリポジトリのパッキングを対象としています。

‘--objects’
     リストされたコミットによって参照されるオブジェクトのオブジェクト
     IDを出力します。 したがって、 ‘--objects foo ^bar’ 「コミットオブジ
     ェクトが bar であるが foo でない場合にダウンロードする必要があるす
     べてのオブジェクトIDを送ってください」という意味です。

‘--in-commit-order’
     ツリーIDとブロブのIDをコミット順に出力します。 ツリーIDとブロブの
     IDは、コミットによって最初に参照された後に出力されます。

‘--objects-edge’
     ‘--objects’ に似ていますが、接頭辞 “-” 文字が付いた除外されたコミッ
     トのIDも出力します。これは git-pack-objects(1) によって使用され、ネ
     ットワークトラフィックを削減するために、これらの除外されたコミット
     に含まれるオブジェクトに基づいてオブジェクトを削除された形式で記録
     する「薄い」パック(thin pack)を構築します。

‘--objects-edge-aggressive’
     ‘--objects-edge’ に似ていますが、時間がかかるという犠牲を払って、除
     外されたコミットを見つけためにもっともっと頑張ります。これは、
     ‘--objects-edge’ の代わりに使用されて浅いリポジトリ(shallow
     repositories)用の「薄い」パック(thin pack)を構築します。

‘--indexed-objects’
     インデックスで使用されるすべてのツリーとブロブがコマンドラインにリ
     ストされているかのように見せかけます。 注意: たぶんあなたは一緒に
     ‘--objects’ も使用したいと思うでしょう。

‘--unpacked’
     ‘--objects’ と一緒の時のみ役立ちます。パックに含まれていないオブジ
     ェクトIDを出力します。

‘--object-names’
     ‘--objects’ と一緒の時のみ役立ちます。見つかったオブジェクトIDの名
     前を出力します。これがデフォルトの動作です。

‘--no-object-names’
     ‘--objects’ と一緒の時のみ役立ちます。見つかったオブジェクトIDの名
     前は出力されません。これにより、 ‘--object-names’ が反転します。 こ
     のフラグを使用すると、 git-cat-file(1) などのコマンドで出力をより簡
     単に解析できます。

‘--filter=<filter-spec>’
     ‘--objectsほげほげ’ のどれかと一緒の時のみ役立ちます。印刷されたオ
     ブジェクトのリストからオブジェクト(通常はブロブ)を省略します。
     <filter-spec> は、以下のいずれかになります:

     ‘--filter=blob:none’ の形式では、すべてのブロブが省略されます。

     ‘--filter=blob:limit=<n>[kmg]’ の形式では、nバイトまたは指定の単位
     より大きいブロブが省略されます。nはゼロの場合があります。 接尾辞kと
     mとgを使用して、KiBまたはMiBまたはGiBの単位にすることができます。 た
     とえば、 ‘blob:limit=1k’ は ‘blob:limit=1024’ と同じです。

     ‘--filter=object:type=(tag|commit|tree|blob)’ の形式では、要求され
     たタイプではないすべてのオブジェクトが省略されます。

     ‘--filter=sparse:oid=<blob-ish>’ の形式は、ブロブ(またはブロブ式)
     <blob-ish> に含まれるsparse-checkout仕様を使用して、 要求された
     refsでsparse checkoutに必要のないブロブを省略します。

     ‘--filter=tree:<depth>’ の形式は、ルートツリーからの深さが ‘>=
     <depth>’ (オブジェクトがトラバースされたコミットの複数の深さにある
     場合の最小深さ)であるすべてのブロブとツリーを省略します。 <depth>=0
     は、コマンドライン(または –stdin が使用されている場合は標準入力)に
     明示的に含まれていない限り、ツリーやブロブを含みません。 <depth>=1
     は、 <commit> から到達可能なコミットまたは明示的に指定されたオブジ
     ェクトによって直接参照されるツリーとブロブのみが含まれます。
     <depth>=2 は <depth>=1 に似ていますが、明示的に指定されたコミットま
     たはツリーから削除されたもう1つのレベルのツリーとブロブも含まれます
     。

     注意: ファイルシステム上の任意のパスから読み取れる形式である
     ‘--filter=sparse:path=<path>’ は、セキュリティ上の理由から削除され
     たことに注意してください。

     複数の ‘--filter=’ フラグを指定して、フィルターを組み合わせることが
     できます。指定の全てのフィルターで受け入れられるオブジェクトのみが
     含まれます。

     ‘--filter=combine:<filter1>+<filter2>+...<filterN>’ の形式を使用し
     て、複数のフィルターを組み合わせることができますが、これは
     ‘--filter’ フラグを繰り返すよりもずっとずっと難しく、通常は必要はあ
     りません。フィルタは ‘+’ で結合され、個々のフィルタは ‘%’ エンコー
     ドされます(つまり、URLエンコードされます)。 ‘+’ と ‘%’ 文字に加えて
     、次の文字は予約されており、エンコードする必要があります:
     ‘~!@#$^&*()[]{}\;",<>?’‘'`’ およびASCIコード ‘0x20’ 以下の全ての文
     字(空白(space)と改行(newline)を含む)。

     他の任意の文字もエンコードできます。 たとえば、
     ‘combine:tree:3+blob:none’ と ‘combine:tree%3A3+blob%3Anone’ は同等
     です。

‘--no-filter’
     以前の ‘--filter=’ 引数をすべてオフにします。

‘--filter-provided-objects’
     明示的に提供されたオブジェクトのリストをフィルタリングします。そう
     しないと、どのフィルターとも一致しなくても常に出力されます。
     ‘--filter=’ と一緒に使った時のみ役に立ちます。

‘--filter-print-omitted’
     ‘--filter=’ と一緒の時のみ役立ちます。フィルタによって省略されたオ
     ブジェクトのリストを出力します。オブジェクトIDの前には “~” 文字が付
     いています。

‘--missing=<missing-action>’
     将来の「部分クローン」(partial clone)開発に役立つデバッグオプション
     。このオプションは、欠落しているオブジェクトの処理方法を指定します
     。

     ‘--missing=error’ の形式は、欠落しているオブジェクトが検出された場
     合に、rev-list がエラーで停止することを要求します。これがデフォルト
     のアクションです。

     ‘--missing=allow-any’ の形式を使用すると、欠落しているオブジェクト
     が検出された場合でも、オブジェクトの走査を続行できます。欠落してい
     るオブジェクトは、結果から黙って省略されます。

     ‘--missing=allow-promisor’ の形式は allow-any に似ていますが、オブ
     ジェクトのトラバーサルは、 EXPECTED promisor が欠落しているオブジェ
     クトに対してのみ続行できます。予期しない欠落したオブジェクトはエラ
     ーを発生させます。

     ‘--missing=print’ の形式は allow-any に似ていますが、欠落しているオ
     ブジェクトのリストも出力します。オブジェクトIDの前には “?” 文字が付
     いています。

‘--exclude-promisor-objects’
     (内部使用のみ。) promisor境界でのオブジェクトトラバーサルをプレフィ
     ルターします。これは部分クローン(partial clone)で使用されます。これ
     は、欠落しているオブジェクトに関するエラーを単に黙らせるのではなく
     、トラバーサルを制限するため、 ‘--missing=allow-promisor’ よりも強
     力です。

‘--unsorted-input’
     コミット時間で時系列の逆順に並べ替えるのではなく、コマンドラインで
     指定された順序でコミットを表示します。‘--no-walk’ または
     ‘--no-walk=sorted’ と組み合わせることはできません。

‘--no-walk[=(sorted|unsorted)]’
     指定されたコミットのみを表示し、祖先をトラバースしない。範囲が指定
     されている場合、これは効果がありません。引数 ‘unsorted’ が指定され
     ている場合、コミットはコマンドラインで指定された順序で表示されます
     。それ以外の場合( ‘sorted’ または引数が指定されていない場合)、コミ
     ットはコミット時間の逆順に表示されます。 ‘--graph’ と組み合わせるこ
     とはできません。 ‘sorted’ または引数が指定されていない場合、
     ‘--unsorted-input’ と組み合わせることはできません。

‘--do-walk’
     以前の ‘--no-walk’ を上書きします。

Commit Formatting
=================

これらのオプションを使用すると、 git-rev-list(1) より専門的なコミットロ
グツールのファミリーである git-log(1) や git-show(1) や
git-whatchanged(1) と同様に機能します。

‘--pretty[=<format>]’
‘--format=<format>’
     コミットログの内容を指定された形式できれいに印刷(pretty-print)しま
     す。 <format> は oneline、short、medium、full、fuller、reference、
     email、raw、format:<string>、tformat:<string> のいずれかになります
     。 <format> が上記のいずれでもなく、「%プレースホルダー」が含まれて
     いる場合、 ‘--pretty=tformat:<format>’ が指定されたかのように動作し
     ます。

     各フォーマットの詳細については、「PRETTY FORMATS」セクションを参照
     してください。 ‘=<format>’ の部分を省略すると、デフォルトで medium
     になります。

     注意: リポジトリー構成でデフォルトのpretty formatを指定できます
     (git-config(1) 参照)。

‘--abbrev-commit’
     40バイトの16進コミットオブジェクト名全体を表示する代わりに、オブジ
     ェクトに一意の名前を付けるプレフィックスを表示します。
     "–abbrev=<n>" (表示されている場合はdiff出力も変更します)オプション
     を使用して、プレフィックスの最小長を指定できます。

     これにより、80桁幅の端末を使用している人にとって "–pretty=oneline"
     がずっと読みやすくなるはずです。

‘--no-abbrev-commit’
     完全な40バイトの16進コミットオブジェクト名を表示します。 これにより
     、明示的または "–oneline" などの他のオプションによって暗黙的に示さ
     れる ‘--abbrev-commit’ が無効になります。また、 ‘log.abbrevCommit’
     変数をオーバーライドします。

‘--oneline’
     これは、 "–pretty=oneline –abbrev-commit" を一緒に使用するための省
     略形です。

‘--encoding=<encoding>’
     コミットオブジェクトは、ログメッセージに使用される文字エンコードを
     エンコードヘッダーに記録します。このオプションを使用して、ユーザー
     が好むエンコーディングでコミットログメッセージを再コーディングする
     ようにコマンドに指示できます。配管以外のコマンドの場合、これはデフ
     ォルトでUTF-8になります。オブジェクトが ‘X’ でエンコードされている
     と主張し、 ‘X’ で出力している場合、オブジェクトをそのまま出力するこ
     とに注意してください。これは、元のコミットの無効なシーケンスが出力
     にコピーされる可能性があることを意味します。同様に、 iconv(3) コミ
     ットの変換に失敗した場合、警告とともに元のオブジェクトをそのまま出
     力します。

‘--expand-tabs=<n>’
‘--expand-tabs’
‘--no-expand-tabs’
     出力に表示する前に、ログメッセージでタブ展開を実行します(タブ幅を
     <n> とみなして <n> 境界に揃うように空白で調整する)。
     ‘--expand-tabs’ は ‘--expand-tabs=8’ の省略形であり、
     ‘--no-expand-tabs’ は ‘--expand-tabs=0’ の省略形です。タブの展開を
     無効にします。

     デフォルトでは、タブはログメッセージを4つのスペースでインデントする
     きれいな形式(pretty formats)で展開されます(つまり、medium (これがデ
     フォルト) と full と fuller)。

‘--show-signature’
     署名を ‘gpg --verify’ に渡して、署名されたコミットオブジェクトの有
     効性を確認し、出力を表示します。

‘--relative-date’
     ‘--date=relative’ と同じ。

‘--date=<format>’
     ‘--pretty’ を使用する場合など、人間が読める形式で表示される日付に対
     してのみ有効になります。 ‘log.date’ 構成変数(config variable)は、
     logコマンドの ‘--date’ オプションのデフォルト値を設定します。デフォ
     ルトでは、日付は元のタイムゾーン(コミッターの、または作者のいずれか
     )で表示されます。フォーマットに ‘-local’ が追加されている場合(例:
     ‘iso-local’ )、代わりにユーザーのローカルタイムゾーンが使用されます
     。

     ‘--date=relative’ は、現在の時刻を基準にした日付を示します。例: “2
     hours ago” 。 ‘-local’ オプションは ‘--date = relative’ には効果が
     ありません。

     ‘--date=local’ は ‘--date=default-local’ のエイリアスです。

     ‘--date=iso’ (または ‘--date=iso8601’ )は、タイムスタンプをISO
     8601のような形式で表示します。厳密なISO 8601形式との違いは以下のと
     おりです:

        • ‘T’ 日付/時刻区切り文字の代わりにスペース

        • 時間とタイムゾーンの間のスペース

        • タイムゾーンの時間と分の間にコロンがありません

     ‘--date=iso-strict’ (または ‘--date=iso8601-strict’ )は、タイムスタ
     ンプを厳密なISO 8601形式で表示します。

     ‘--date=rfc’ (または ‘--date=rfc2822’ )は、RFC 2822形式のタイムスタ
     ンプを示します。これは、電子メールメッセージでよく見られます。

     ‘--date=short’ は、日付のみを表示し、時刻は表示せず、 ‘YYYY-MM-DD’
     形式で表示します。

     ‘--date=raw’ は、エポック(1970-01-01 00:00:00 UTC)からの秒数、スペ
     ース、UTCからのオフセット(‘+’ または ‘-’ の付いた4桁数字で、最初の
     2つは時間、次の2つは分です)。つまり、タイムスタンプが ‘strftime("%s
     %z")’ でフォーマットされているかのようになります。 ‘-local’ オプシ
     ョンは、seconds-since-epoch値(常にUTCで測定されます)には影響しませ
     んが、付随するタイムゾーン値を切り替えることに注意してください。

     ‘--date=human’ は、タイムゾーンが現在のタイムゾーンと一致しない場合
     はタイムゾーンを表示し、一致する場合は日付全体を印刷しません(つまり
     、「今年」の日付の場合は年の印刷をスキップしますが、何があったか覚
     えてるような過去数日については日付自体もスキップします)。 古い日付
     の場合、時と分も省略されます。

     ‘--date=unix’ は、日付をUnixエポックタイムスタンプ(1970年からの秒数
     )として表示します。 ‘--raw’ と同様に、これは常にUTCであるため、 ‘
     -local‘ は効果がありません。

     ‘--date=format:...’ は、内部で処理される%zと%Zを除いて、フォーマッ
     ト ‘...’ をあなたのシステムの ‘strftime’ に送ります。
     ‘--date=format:%c’ を使用して、システムロケールの推奨形式で日付を表
     示します。フォーマットプレースホルダーの完全なリストについては、
     ‘strftime’ マニュアルを参照してください。 ‘-local’ を使用する場合、
     正しい構文は ‘--date=format-local:...’ です。

     ‘--date=default’ はデフォルトの形式であり、いくつかの例外を除いて
     ‘--date=rfc2822’ に似ています:

        • 曜日の後にコンマはありません

        • ローカルタイムゾーンを使用する場合、タイムゾーンは省略されます

‘--header’
     コミットの内容をraw形式で出力します。各レコードはNUL文字で区切られ
     ます。

‘--no-commit-header’
     "commit" を含むヘッダー行と、指定された形式の前に出力されたオブジェ
     クトIDを抑制します。これは組み込みフォーマットには影響しません。 カ
     スタムフォーマットのみが影響を受けます。

‘--commit-header’
     以前の ‘--no-commit-header’ を上書きします。

‘--parents’
     コミットの親も出力します( "commit parent…" の形式で)。親の書き換え
     も可能にします。上記「History Simplification」を参照してください。

‘--children’
     コミットの子も出力します( "commit child…" の形式で)。親の書き換えも
     可能にします。上記「History Simplification」を参照してください。

‘--timestamp’
     生のコミットタイムスタンプを出力します。

‘--left-right’
     対称差のどちら側からコミットに到達できるかをマークします。左側から
     のコミットには ‘<’ が付けられ、右側からのコミットには ‘>’ が付けら
     れます。 ‘--boundary’ と組み合わせると、それらのコミットの前に ‘-’
     が付きます。

     たとえば、以下のトポロジーの場合:

                       y---b---b  branch B
                      / \ /
                     /   .
                    /   / \
                   o---x---a---a  branch A

     以下のような出力が得られます:

                  $ git rev-list --left-right --boundary --pretty=oneline A...B

                  >bbbbbbb... 3rd on b
                  >bbbbbbb... 2nd on b
                  <aaaaaaa... 3rd on a
                  <aaaaaaa... 2nd on a
                  -yyyyyyy... 1st on b
                  -xxxxxxx... 1st on a

‘--graph’
     出力の左側に、コミット履歴のテキストベースのグラフィック表現を描画
     します。グラフ履歴を適切に描画するために、コミットの間に余分な行が
     出力される可能性があります。 ‘--no-walk’ と組み合わせることはできま
     せん。

     これにより、親の書き換えが可能になります。上記「History
     Simplification」を参照してください。

     これは、デフォルトで ‘--topo-order’ オプションを意味しますが、
     ‘--date-order’ オプションも指定できます。

‘--show-linear-break[=<barrier>]’
     –graph を使用しない場合、すべての履歴ブランチがフラット化されるため
     、2つの連続するコミットが線形ブランチに属していないことがわかりにく
     くなる可能性があります。このオプションは、その場合、それらの間に障
     壁を置きます。 ‘<barrier>’ が指定されている場合、デフォルトの障壁文
     字列の代わりに ‘<barrier>’ が表示されます。

‘--count’
     リストされたコミットの数を示す数値を出力し、他のすべての出力を抑制
     します。 ‘--left-right’ と一緒に使用する場合は、代わりに、タブで区
     切って、左右のコミットのカウントを出力します。 ‘--cherry-mark’ と一
     緒に使用する場合は、これらのカウントからパッチの同等のコミットを省
     略し、タブで区切られた同等のコミットのカウントを出力します。

PRETTY FORMATS
**************

コミットがマージであり、 pretty-format が ‘oneline’ または ‘email’ また
は ‘raw’ で無い場合、 ‘Author:’ 行の前に追加の行が挿入されます。この行は
"Merge: " で始まり、先祖のコミットのハッシュがスペースで区切られて出力さ
れます。履歴の表示を制限している場合、たとえば、特定のディレクトリまたは
ファイルに関連する変更のみに関心がある場合、リストされたコミットは必ずし
も *直接* の親コミットのリストではない可能性があることに注意してください
。

   いくつかの組み込みフォーマットがあります。そして以下で説明するように
、 pretty.<name> 構成オプション(config option)を別のフォーマット名または
‘format:’ 文字列に設定することで、追加のフォーマットを定義できます
(git-config(1) 参照)。組み込みフォーマットの詳細は以下のとおりです:

   • ‘oneline’

          <hash> <title line>

     これは、可能な限りコンパクトになるように設計されています。

   • ‘short’

          commit <hash>
          Author: <author>

          <title line>

   • ‘medium’

          commit <hash>
          Author: <author>
          Date:   <author date>

          <title line>

          <full commit message>

   • ‘full’

          commit <hash>
          Author: <author>
          Commit: <committer>

          <title line>

          <full commit message>

   • ‘fuller’

          commit <hash>
          Author:     <author>
          AuthorDate: <author date>
          Commit:     <committer>
          CommitDate: <committer date>

          <title line>

          <full commit message>

   • ‘reference’

          <abbrev hash> (<title line>, <short author date>)

     この形式は、コミットメッセージ内の別のコミットを参照するために使用
     され、 ‘--pretty='format:%C(auto)%h (%s, %ad)'’ と同じです。 デフォ
     ルトでは、別の ‘--date’ オプションが明示的に指定されていない限り、
     日付は ‘--date=short’ でフォーマットされます。formatプレースホルダ
     ーを使用する他の ‘format:’ と同様に、その出力は、 ‘--decorate’ や
     ‘--walk-reflogs’ などの他のオプションの影響を受けません。

   • ‘email’

          From <hash> <date>
          From: <author>
          Date: <author date>
          Subject: [PATCH] <title line>

          <full commit message>

   • ‘mboxrd’

     ‘email’ と同様ですが、コミットメッセージの "From " で始まる行(前に
     0個以上の ‘>’ が付いている)は ‘>’ でクォートされているため、新しい
     コミットの開始と混同されることはありません。

   • ‘raw’

     ‘raw’ 形式は、コミットオブジェクトに格納されているとおりにコミット
     全体を正確に表示します。とりわけ ‘--abbrev’ または ‘--no-abbrev’ の
     どちらが使用されているかに関係なく、ハッシュは完全に表示され、「親
     」(parents)情報は、移植や履歴の単純化を考慮せずに、真の親のコミット
     を示します。この形式は、コミットの表示方法に影響しますが、いわゆる
     ‘git log --raw’ の差分の表示方法ではありません。生のdiff形式で完全
     なオブジェクト名を取得するには、 ‘--no-abbrev’ を使用します。

   • ‘format:<string>’

     ‘format:<string>’ 形式を使用すると、表示する情報を指定できます。注
     意: これはprintf書式に少し似ていますが、 ‘\n’ の代わりに ‘%n’ を使
     用して改行を取得するという例外に注意してください。

     例: ‘format:"The author of %h was %an, %ar%nThe title was
     >>%s<<%n"’ は以下のように表示されます:

          The author of fe6e0ee was Junio C Hamano, 23 hours ago
          The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

     さて、以下がプレースホルダー達です:

        • 単一のリテラル文字に展開されるプレースホルダー:

          ‘%n’
               改行(newline)

          ‘%%’
               ‘%‘そのもの

          ‘%x00’
               16進数のバイト値を出力

        • うしろのプレースホルダーのフォーマッティングに影響するプレース
          ホルダー:

          ‘%Cred’
               赤色に切り替える

          ‘%Cgreen’
               緑色に切り替える

          ‘%Cblue’
               青色に切り替える。

          ‘%Creset’
               色をリセットする

          ‘%C(...)’
               git-config(1) の「CONFIGURATION FILE」の Values で説明さ
               れている色の指定。 デフォルトでは、色はログ出力が有効にな
               っている場合にのみ表示されます’(‘color.diff’ または
               ‘color.ui’ または ‘--color’ によって、ターミナルに出す場
               合は前者の ‘auto’ 設定を尊重します)。 ‘%C(auto,...)’ は、
               default の歴史的同義語として受け入れられます(例:
               ‘%C(auto,red)’)。 ‘%C(always,...)’ を指定すると、色が有効
               になっていない場合でも色が表示されます(この形式やgitが色
               付けする可能性のある他のすべてのものを含め、出力全体の色
               を有効にするために ‘--color=always’ の使用を検討してくだ
               さい)。 ‘auto’ のみ(つまり、 ‘%C(auto)’)は、色が再び切り
               替わるまで、これに続くプレースホルダーで自動色付けをオン
               にします。

          ‘%m’
               左(‘<’) または 右(‘>’) または 境界 (‘-’) の印

          ‘%w([<w>[,<i1>[,<i2>]]])’
               git-shortlog(1) の -w オプションのように、 行の折り返しを
               切り替えます。

          ‘%<(<N>[,trunc|ltrunc|mtrunc])’
               次のプレースホルダーに少なくともN列を使用させ、 必要に応
               じて右側にスペースを埋め込みます。オプションで、出力がN列
               より長い場合は、先頭(ltrunc)または中間(mtrunc)または末尾
               (trunc)で切り捨てます。注意: 切り捨ては、 N >= 2 でのみ正
               しく機能することに注意してください。

          ‘%<|(<N>)’
               次のプレースホルダーを少なくともN番目の列まで取得し、 必
               要に応じて右側にスペースを埋め込みます

          ‘%>(<N>)’, ‘%>|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 左側に
               スペースが埋め込まれています

          ‘%>>(<N>)’, ‘%>>|(<N>)’
               ‘%>(<N>)’ 、 ‘%>|(<N>)’ とそれぞれ似ていますが、 次のプレ
               ースホルダーが指定されたよりも多くのスペースを取り、その
               左側にスペースがある場合は、それらのスペースを使用します
               。

          ‘%><(<N>)’, ‘%><|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 両側に
               パディングがあります(つまり、テキストが中央に配置されます
               )

        • コミットから抽出された情報に展開するプレースホルダー:

          ‘%H’
               コミットハッシュ

          ‘%h’
               省略されたコミットハッシュ

          ‘%T’
               ツリーハッシュ

          ‘%t’
               省略されたツリーハッシュ

          ‘%P’
               親のハッシュ達

          ‘%p’
               省略された親のハッシュ達

          ‘%an’
               作者名

          ‘%aN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) を参照)

          ‘%ae’
               作者電子メールアドレス

          ‘%aE’
               作者電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) を参照)

          ‘%al’
               作者電子メールアドレスアカウント名(local-part)(‘@’ の前の
               部分)

          ‘%aL’
               作者電子メールアドレスアカウント名(local-part)(‘%al’ 参照
               ) .mailmap に関しては git-shortlog(1) または git-blame(1)
               参照)

          ‘%ad’
               作成日(フォーマットに関しては –date= オプション参照)

          ‘%aD’
               作成日 RFC2822形式

          ‘%ar’
               作成日 相対(relative)形式

          ‘%at’
               作成日 UNIXタイムスタンプ形式

          ‘%ai’
               作成日 ISO 8601風形式

          ‘%aI’
               作成日 厳密なISO 8601形式

          ‘%as’
               作成日 短い形式(‘YYYY-MM-DD’)

          ‘%ah’
               作成日 human形式( git-rev-list(1) の ‘--date=human’ オプ
               ションのようなかんじ)

          ‘%cn’
               コミッター名

          ‘%cN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ce’
               コミッター電子メールアドレス

          ‘%cE’
               コミッター電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%cl’
               コミッター電子メールアドレスアカウント名(local-part)( ‘@’
               の前の部分)

          ‘%cL’
               コミッター電子メールアドレスアカウント名(local-part)(
               ‘%cl’ 参照) .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%cd’
               コミッター日付(フォーマットに関しては ‘--date=’ オプショ
               ン参照)

          ‘%cD’
               コミッター日付 RFC2822形式

          ‘%cr’
               コミッター日付 相対(relative)形式

          ‘%ct’
               コミッター日付 UNIXタイムスタンプ形式

          ‘%ci’
               コミッター日付 ISO 8601風形式

          ‘%cI’
               コミッター日付 厳密なISO 8601形式

          ‘%cs’
               コミッター日付 短い形式(‘YYYY-MM-DD’)

          ‘%ch’
               コミッター日付 human形式(git-rev-list(1) の
               ‘--date=human’ オプションのようなかんじ)

          ‘%d’
               ref名 git-log(1) の –decorate オプションみたいなの

          ‘%D’
               " (", ")" で囲ってないref名

          ‘%(describe[:options])’
               git-describe(1) のような人間が読める名前。 説明できないコ
               ミットの場合は空の文字列。 ‘describe’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。タグが同時に追加または削除されると、説明に一貫性がな
               くなる可能性があります。

                  • ‘match=<pattern>’: ‘refs/tags/’ プレフィックスを除い
                    て、指定された ‘glob(7)’ パターンに一致するタグのみ
                    を考慮します。

                  • ‘exclude=<pattern>’: ‘refs/tags/’ プレフィックスを除
                    いて、指定された ‘glob(7)’ パターンに一致するタグを
                    対象にしません。

          ‘%S’
               コミットに到達したコマンドラインで指定されたref名 ( ‘git
               log --source’ など)は、 ‘git log’ でのみ機能します

          ‘%e’
               エンコーディング

          ‘%s’
               件名(subject)

          ‘%f’
               ファイル名に適した、サニタイズされた件名

          ‘%b’
               本文(body)

          ‘%B’
               生本文(raw body)(ラップされてない件名と本文)

          ‘%GG’
               署名されたコミットの為のGPSからの生の検証メッセージ

          ‘%G?’

               G
                    良い(good)な(有効な)署名の場合はこの文字に置換されま
                    す。

               B
                    悪い署名(bad signature)の場合はこの文字に置換されま
                    す。

               U
                    有効性が不明(unknown validity)な良い署名の場合はこの
                    文字に置換されます。

               X
                    期限切れ(eXpired)の良い署名の場合はこの文字に置換さ
                    れます。

               Y
                    期限切れのキーで作成された良い署名の場合はこの文字に
                    置換されます。

               R
                    取り消されたキーによって作成された良い署名の場合はこ
                    の文字に置換されます。

               E
                    署名を確認できない場合(キーの欠落など)の場合はこの文
                    字に置換されます。

               N
                    署名がない場合の場合はこの文字に置換されます。

          ‘%GS’
               署名されたコミットの署名者の名前を表示する

          ‘%GK’
               署名されたコミットに署名するために使用されるキーを表示す
               る

          ‘%GF’
               署名されたコミットに署名するために使用されるキーのフィン
               ガープリントを表示する

          ‘%GP’
               署名されたコミットに署名するためにサブキーが使用された 主
               キーのフィンガープリントを表示します

          ‘%GT’
               署名されたコミットに署名するために使用されるキーの信頼レ
               ベル(trust level)を表示します

          ‘%gD’
               reflogセレクター(例:‘refs/stash@{1}’ or ‘refs/stash@{2
               minutes ago}’) この形式は、 ‘-g’ オプションで説明されてい
               る規則に従います。 ‘@’ の前の部分は、コマンドラインで指定
               されたrefnameです(したがって、 ‘git log -g
               refs/heads/master’ は ‘refs/heads/master@{0}’ を生成しま
               す)。

          ‘%gd’
               短縮されたreflogセレクター。 ‘%gD’ と同じですが、 人間が
               読みやすいようにrefname部分が短縮されています(したがって
               、 ‘refs/heads/master’ は単に ‘master’ になります)。

          ‘%gn’
               reflog ID名

          ‘%gN’
               reflog ID名( .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ge’
               reflog ID 電子メールアドレス

          ‘%gE’
               reflog ID 電子メールアドレス( .mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%gs’
               reflog 件名

          ‘%(trailers[:options])’
               git-interpret-trailers(1) によって解釈されるようにボディ
               のトレーラーを表示します。 ‘trailers’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。いずれかのオプションが複数回提供された場合、それぞれ
               最後のものが優先されます。

               ブール値オプションは、オプションの値 ‘[=<BOOL>]’ を受け入
               れます。 値 ‘true’ 、‘false’ 、 ‘on’ 、‘off’ などはすべて
               受け入れられます。 git-config(1) の "EXAMPLES" の
               "boolean" サブセクションを参照してください。ブール値オプ
               ションが値なしで指定された場合、それは有効を指定した事に
               なります。

                  • ‘key=<K>’ は指定されたキーを持つトレーラーのみを表示
                    します。マッチングは大文字と小文字を区別せずに行われ
                    、末尾のコロンはオプションです。オプションが複数回指
                    定されている場合、いずれかのキーに一致するトレーラー
                    行が表示されます。このオプションは自動的に ‘only’ オ
                    プションを有効にして、トレーラーブロック内の非トレー
                    ラー行が非表示になるようにします。それが望ましくない
                    場合は、 ‘only=false’ で無効にすることができます。 た
                    とえば、 ‘%(trailers:key=Reviewed-by)’ は、キーが
                    ‘Reviewed-by‘のトレーラー行を表示します。

                  • ‘only[=<BOOL>]’ はトレーラーブロックに非トレーラー行
                    を含めるかどうかを選択します。

                  • ‘separator=<SEP>’ はトレーラー行の間に挿入される区切
                    り文字を指定します。このオプションが指定されていない
                    場合、各トレーラー行は改行文字で終了します。文字列
                    SEPには、上記のリテラルフォーマットコードが含まれる
                    場合があります。区切り文字としてコンマを使用するには
                    、次のオプションとして解析されないよう ‘%x2C’ を使用
                    する必要があります。 たとえば、
                    ‘%(trailers:key=Ticket,separator=%x2C )’ は、キーが
                    ‘Ticket’ であるすべてのトレーラー行をカンマとスペー
                    スで区切って表示します。

                  • ‘unfold[=<BOOL>]’ は interpret-trailer の ‘--unfold’
                    オプションが指定されたかのように動作させます。たとえ
                    ば、 ‘%(trailers:only,unfold=true)’ が展開され、すべ
                    てのトレーラー行が表示されます。

                  • ‘keyonly[=<BOOL>]’ トレーラーのキー部分のみを表示。

                  • ‘valueonly[=<BOOL>]’ トレーラーの値部分のみ表示。

                  • ‘key_value_separator=<SEP>’ トレーラー行の間に挿入さ
                    れる区切り文字を指定します。このオプションが指定され
                    ていない場合、各トレーラーのキーと値のペアは ": " で
                    区切られます。 それ以外の場合は、上記の
                    ‘separator=<SEP>’ と同じセマンティクスを共有します。

     *Note*

     一部のプレースホルダーは、リビジョントラバーサルエンジンに指定され
     た他のオプションに依存する場合があります。 たとえば、 ‘%g*’ reflogオ
     プションは、reflogエントリをトラバースしない限り(たとえば、 ‘git
     log -g’ によって)空の文字列を挿入します。コマンドラインで
     ‘--decorate’ がまだ指定されていない場合、 ‘%d’ と ‘%D’ プレースホル
     ダーは「短い」(short)装飾形式を使用します。

   プレースホルダーの ‘%’ の後に ‘+’ (プラス記号)を追加すると、プレース
ホルダーが空でない文字列に展開される場合に限り、展開の直前に改行が挿入さ
れます。

   プレースホルダーの ‘%’ の後に ‘-’ (マイナス記号)を追加すると、プレー
スホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべて
の改行が削除されます。

   プレースホルダーの ‘%’ の後に " " (スペース)を追加すると、プレースホ
ルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入
されます。

   • ‘tformat:’

     ‘tformat:’ 形式は、 "separator" セマンティクスの代わりに
     "terminator" セマンティクスを提供することを除いて、 ‘format:’ とま
     ったく同じように機能します。 つまり、各コミットには、エントリ間に区
     切り文字を配置するのではなく、メッセージターミネータ文字(通常は改行
     )が追加されます。 これは、「1行」形式と同様に、1行形式の最終エント
     リが新しい行で適切に終了することを意味します。 例えば:

          $ git log -2 --pretty=format:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973 -- NO NEWLINE

          $ git log -2 --pretty=tformat:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973

     加えて、 ‘%’ が含まれている認識されない文字列は、その前に
     ‘tformat:’ があるかのように解釈(interpret)されます。 たとえば、以下
     の2つは同等です:

          $ git log -2 --pretty=tformat:%h 4da45bef
          $ git log -2 --pretty=%h 4da45bef

EXAMPLES
********

   • 現在のブランチから到達可能なコミットのリストを出力します。

          git rev-list HEAD

   • このブランチのコミットのリストを出力しますが、アップストリームブラ
     ンチのは表示しません。

          git rev-list @{upstream}..HEAD

   • 作者(author)とコミットメッセージを使用してコミットをフォーマットし
     ます(磁器コマンドのgit-log(1)も参照)。

          git rev-list --format=medium HEAD

   • コミットとその差分をフォーマットします(これを単一のプロセスで実行で
     きる磁器コマンドのgit-log(1)も参照してください)。

          git rev-list HEAD |
          git diff-tree --stdin --format=medium -p

   • 現在のブランチで、‘Documentation‘ディレクトリ内のファイルに関連
     (touch)したコミットのリストを出力します。

          git rev-list HEAD -- Documentation/

   • 任意のブランチ・タグ・他のrefから過去1年間に作者you@example.comが作
     成したコミットのリストを出力します (mailto:他のrefから過去1年間に作
     者you@example.comが作成したコミットのリストを出力します)。

          git rev-list --author=you@example.com --since=1.year.ago --all

   • 現在のブランチから到達可能なオブジェクトのリストを出力します(つまり
     、すべてのコミットと、それらに含まれるブロブとツリー)。

          git rev-list --objects HEAD

   • 到達可能なすべてのオブジェクトのディスクサイズ、reflogから到達可能
     なオブジェクト、およびパックされた合計サイズを比較します。これによ
     り、‘git repack -ad‘を実行すると(到達不能なオブジェクトを削除するこ
     とで)リポジトリのサイズが減少するかどうか、およびreflogの有効期限が
     切れる(expire)ことによってリポジトリのサイズ減少に役立つかどうかが
     わかります。

          # reachable objects
          git rev-list --disk-usage --objects --all
          # plus reflogs
          git rev-list --disk-usage --objects --all --reflog
          # total disk size used
          du -c .git/objects/pack/*.pack .git/objects/??/*
          # alternative to du: add up "size" and "size-pack" fields
          git count-objects -v

   • 現在のブランチで使用されているオブジェクトを除いて、各ブランチのデ
     ィスクサイズを報告します。 これにより、リポジトリサイズの肥大化の原
     因となっているイレギュラー値を見つけることができます(たとえば、誰か
     が誤って大きなビルドアーティファクトをコミットしたためとか)。

          git for-each-ref --format='%(refname)' |
          while read branch
          do
                  size=$(git rev-list --disk-usage --objects HEAD..$branch)
                  echo "$size $branch"
          done |
          sort -n

   • (別のグループを除いた)refsの単一のグループのブランチのディスク上の
     サイズを比較します。1つのリポジトリに複数のリモートからのオブジェク
     トを混在させる場合、これにより、リポジトリ内で、どのリモートがどれ
     だけ占めているかを示すことができます(‘origin‘のサイズを基準値として
     使用)。

          git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin

GIT
***

Part of the git(1) suite

Name
****

git-rev-parse — パラメータを選択してもみもみします。

Synopsis
********

     git rev-parse [<options>] <args>…

DESCRIPTION
***********

多くのGit磁器コマンドは、内部で使用されベースとなる ‘git rev-list’ コマ
ンド用のフラグとパラメーターの組み合わせと、 ‘git rev-list’ の下流で使用
する他のコマンドのフラグとパラメーターの組み合わせを使用します。このコマ
ンドは、それらを識別するために使用されます。

OPTIONS
*******

Operation Modes
===============

これらの各オプションは、コマンドラインの最初にある必要があります。

‘--parseopt’
     オプション解析モードで ‘git rev-parse’ を使用します(以下の PARSEOPT
     セクションを参照)。

‘--sq-quote’
     シェルクォートモードで _git rev-parse_ を使用します(以下の SQ-QUOTE
     セクションを参照)。以下の ‘--sq’ オプションとは対照的に、このモード
     はクォートのみを実行します。コマンド入力に対して他に何も行われませ
     ん。

Options for –parseopt
=====================

‘--keep-dashdash’
     ‘--parseopt’ モードでのみ意味があります。 オプションパーサーに、最
     初に出会った ‘--’ をスキップするのではなく、エコー出力(echo out)す
     るように指示します。

‘--stop-at-non-option’
     ‘--parseopt’ モードでのみ意味があります。オプションパーサーを最初の
     非オプション引数で停止させます。これは、オプション自体を受け取るサ
     ブコマンドを解析するために使用できます。

‘--stuck-long’
     ‘--parseopt’ モードでのみ意味があります。可能な場合は長い形式でオプ
     ションを出力し、それらの引数を固定(stick)します。

Options for Filtering
=====================

‘--revs-only’
     ‘git rev-list’ コマンド用ではないフラグやパラメーターを出力しないで
     ください。

‘--no-revs’
     ‘git rev-list’ コマンド用のフラグとパラメーターを出力しないでくださ
     い。

‘--flags’
     非フラグパラメータを出力しないでください。

‘--no-flags’
     フラグパラメータを出力しないでください。

Options for Output
==================

‘--default <arg>’
     ユーザーが指定したパラメーターがない場合は、代わりに ‘<arg>’ を使用
     してください。

‘--prefix <arg>’
     ‘git rev-parse’ が作業ツリーの ‘<arg>’ サブディレクトリから呼び出さ
     れたかのように動作します。相対ファイル名は、接頭辞が ‘<arg>’ である
     かのように解決され、その形式で出力されます。

     これを使用して、引数をサブディレクトリで実行されるコマンドに変換し
     、リポジトリの最上位に移動した後も使用できるようにすることができま
     す。 例えば:

          prefix=$(git rev-parse --show-prefix)
          cd "$(git rev-parse --show-toplevel)"
          # rev-parse provides the -- needed for 'set'
          eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"

‘--verify’
     正確に1つのパラメーターが提供されていること、およびそれがオブジェク
     ト・データベースへのアクセスに使用できる生の20バイトのSHA-1に変換で
     きることを検証します。もしそうなら、それを標準出力に出力します。そ
     れ以外の場合は、エラー出力になります。

     出力が実際にオブジェクトデータベース内のオブジェクトに名前を付けて
     いること、および/または必要な特定のタイプのオブジェクトとして使用で
     きることを確認したい場合は、パラメータに ‘^{type}’ 皮むき演算子
     (peeling operator)を追加できます。 たとえば、 ‘git rev-parse
     "$VAR^{commit}"’ は、 ‘$VAR’ がコミットっぽい既存のオブジェクト(つ
     まりコミット、またはコミットを指す注釈付きタグ)に名前を付けることを
     確認します。 ‘$VAR’ が任意のタイプの既存のオブジェクトに名前を付け
     るようにするには、 ‘git rev-parse "$VAR^{object}"’ を使用できます。

     注意: 信頼できないソースからの名前を検証(verify)する場合は、name引
     数が別のオプションと間違えられないように、 ‘--end-of-options’ の使
     用が賢明です。

‘-q’
‘--quiet’
     ‘--verify’ モードでのみ意味があります。最初の引数が有効なオブジェク
     ト名でない場合は、エラーメッセージを出力しないでください。代わりに
     、ゼロ以外のステータスで黙って終了(exit)します。有効なオブジェクト
     名のSHA-1は、成功するとstdoutに出力されます。

‘--sq’
     通常、出力はフラグとパラメータごとに1行になります。このオプションは
     、シェルによって消費されるための適切に引用された1行の出力を作成しま
     す。パラメータに空白と改行が含まれていると予想される場合に便利です
     (たとえば、 pickaxe ‘-S’ with _git diff-*_ )。 ‘--sq-quote’ オプシ
     ョンとは対照的に、コマンド入力は通常どおり解釈されます。

‘--short[=length]’
     ‘--verify’ と同じですが、オブジェクト名を少なくとも ‘length’ 文字の
     一意のプレフィックスに短縮します。最小の長さは4で、デフォルトは
     ‘core.abbrev’ 構成変数の有効な値です(git-config(1)を参照)。

‘--not’
     オブジェクト名を表示するときは、それらに ‘{caret}’ というプレフィッ
     クスを付け、逆に既に、 ‘{caret}’ プレフィックスを持っているオブジェ
     クト名からは ‘{caret}’ プレフィックスを削除します。

‘--abbrev-ref[=(strict|loose)]’
     オブジェクト名のあいまいでない短い名前。オプション
     core.warnAmbiguousRefs は、厳密な省略形モードを選択するために使用さ
     れます。

‘--symbolic’
     通常、オブジェクト名はSHA-1形式で出力されます(可能な場合は
     ‘{caret}’ プレフィックス付き)。このオプションを使用すると、入力され
     たオリジナルにできるだけ近い形式で出力されます。

‘--symbolic-full-name’
     これは ‘--symbolic’ に似ていますが、ref(つまり、ブランチ名とタグ名
     。または、残念ながら ‘master’ と名付けられたタグがあるとき ‘master’
     ブランチに名前を付けたい場合はより明確な ‘heads/master’ 形式である
     )ではない入力を省略し、完全なrefname(例: "refs/heads/master")として
     表示します。

Options for Objects
===================

‘--all’
     ‘refs/’ で見つかったすべての参照を表示します。

‘--branches[=pattern]’
‘--tags[=pattern]’
‘--remotes[=pattern]’
     すべてのブランチまたはタグまたはリモートトラッキングブランチをそれ
     ぞれ表示します(つまり、それぞれ ‘refs/heads’ または ‘refs/tags’ ま
     たは ‘refs/remotes’ で見つかったref)。

     ‘pattern’ が指定されている場合、指定されたシェルグロブに一致する
     refのみが表示されます。パターンにグロビング文字(‘?’ または ‘*’ また
     は ‘[’)が含まれていない場合は、 ‘/*’ を追加することでプレフィックス
     一致に変換されます。

‘--glob=pattern’
     シェルグロブパターン ‘pattern’ に一致するすべてのrefを表示します。
     パターンが ‘refs/’ で始まらない場合、自動的に先頭に追加されます。パ
     ターンにグロビング文字(‘?’ または ‘*’ または ‘[’)が含まれていない場
     合は、 ‘/*’ を追加することでプレフィックス一致に変換されます。

‘--exclude=<glob-pattern>’
     このオプションに続く ‘--all’ または ‘--branches’ または ‘--tags’ ま
     たは ‘--remotes’ または ‘--glob’ がそれぞれ考慮する
     _<glob-pattern>_ に一致するrefを含めないでください。このオプション
     を繰り返すと、次の ‘--all’ または ‘--branches’ または ‘--tags’ また
     は ‘--remotes’ または ‘--glob’ オプションまで除外パターンが蓄積され
     ます(他のオプションや引数は蓄積されたパターンをクリアしませんされま
     せん)。

     与えられたパターンは、それぞれ ‘--branches’ または ‘--tags’ または
     ‘--remotes’ に適用される場合、それぞれ ‘refs/heads’ 、 ‘refs/tags’
     、‘refs/remotes’ で始まるべきではありません。 ‘--glob’ または
     ‘--all’ に適用する場合は、 ‘refs/’ で始める必要があります。末尾の
     _/*_ を意図している場合は、それを明示的に指定する必要があります。

‘--disambiguate=<prefix>’
     名前が、指定されたプレフィックスで始まるすべてのオブジェクトを表示
     します。 <prefix> は、リポジトリ内のすべてのオブジェクトを誤ってリ
     ストしないように、少なくとも4桁の16進数である必要があります。

Options for Files
=================

‘--local-env-vars’
     リポジトリローカルな GIT_* 環境変数を一覧表示します(例: GIT_DIRまた
     はGIT_WORK_TREE、ただしGIT_EDITORは除く)。 変数が設定されている場合
     でも、変数の名前のみがリストされ、値はリストされません。

‘--path-format=(absolute|relative)’
     他の特定のオプションの動作を制御します。absolute(絶対)を指定すると
     、これらのオプションによって出力されるパスは絶対パスかつ正規化され
     ます。relative(相対)を指定すると、可能であれば、パスは現在の作業デ
     ィレクトリからの相対パスになります。デフォルトは対象の、他の特定の
     オプションそれぞれ固有です。

     このオプションは複数回指定でき、コマンドラインの最後か、またはこの
     オプションの次のインスタンスかの、いずれかに続くコマンドラインの引
     数にのみ影響します。

   以下のオプションは ‘--path-format’ による変更対象です:

‘--git-dir’
     定義されている場合は ‘$GIT_DIR’ を表示します。それ以外の場合は、
     ‘.git’ ディレクトリへのパスを表示します。表示されているパスは、相対
     の場合、現在の作業ディレクトリからの相対パスです。

     ‘$GIT_DIR’ が定義されておらず、現在のディレクトリがGitリポジトリま
     たは作業ツリーにあることが検出されない場合は、標準エラー出力にメッ
     セージを出力し、ゼロ以外のステータスで終了(exit)します。

‘--git-common-dir’
     定義されている場合は ‘$GIT_COMMON_DIR’ を表示し、そうでない場合は
     ‘$GIT_DIR’ を表示します。

‘--resolve-git-dir <path>’
     <path> が有効なリポジトリまたは有効なリポジトリを指す gitfile であ
     るかどうかを確認し、リポジトリの場所を出力します。 <path> が
     gitfile の場合、実際のリポジトリへの解決されたパス(resoluved path)が
     出力されます。

‘--git-path <path>’
     ‘$GIT_DIR/<path>’ を解決し、 $GIT_OBJECT_DIRECTORY、
     $GIT_INDEX_FILE…などの他のパス再配置変数を考慮に入れます。 たとえば
     、 $GIT_OBJECT_DIRECTORY が ‘/foo/bar’ に設定されている場合、 ‘git
     rev-parse --git-path objects/abc’ は ‘/foo/bar/abc’ を返します。

‘--show-toplevel’
     作業ツリーの最上位ディレクトリの(デフォルトでは絶対)パスを表示しま
     す。作業ツリーがない場合は、エラーを報告します。

‘--show-superproject-working-tree’
     現在のリポジトリをサブモジュールとして使用するスーパープロジェクト
     の作業ツリー(存在する場合)のルート(root)の絶対パスを表示します。現
     在のリポジトリがどのプロジェクトでもサブモジュールとして使用されて
     いない場合は、何も出力しません。

‘--shared-index-path’
     共有インデックスファイル(shared index file)へのパスを分割インデック
     スモード(split index mode)で表示します。分割インデックスモードで無
     い場合は空です。

   以下のオプションは、 ‘--path-format’ の影響を受けません:

‘--absolute-git-dir’
     ‘--git-dir’ に似ていますが、その出力は常に正規化された絶対パスです
     。

‘--is-inside-git-dir’
     現在の作業ディレクトリがリポジトリディレクトリ(訳注: 通常 ‘.git’ デ
     ィレクトリ)の下にある場合は ‘true’ 、それ以外の場合は ‘false’ と出
     力します。

‘--is-inside-work-tree’
     現在の作業ディレクトリがリポジトリの作業ツリー内にある場合は ‘true’
     、それ以外の場合は ‘false’ と出力します。(訳注 ‘.git’ ディレクトリ
     内では ‘false’)

‘--is-bare-repository’
     ベアリポジトリの場合は ‘true’ 、それ以外の場合は ‘false’ を出力。

‘--is-shallow-repository’
     shallowリポジトリの場合は ‘true’ 、そうでない場合は ‘false’ を出力
     します。

‘--show-cdup’
     コマンドがサブディレクトリから呼び出された場合は、現在のディレクト
     リを基準にした最上位ディレクトリのパスを表示します(通常は ‘../’ の
     シーケンスまたは空の文字列)。(訳注:作業ディレクトリ内じゃない時はエ
     ラー)

‘--show-prefix’
     コマンドがサブディレクトリから呼び出された場合は、最上位ディレクト
     リを基準にした現在のディレクトリのパスを表示します。(訳注:作業ディ
     レクトリ内じゃない時はエラー)

‘--show-object-format[=(storage|input|output)]’
     ‘.git’ ディレクトリ内でリポジトリのために使われるストレージ
     (storage)、または入力(input)、または出力(output)に使われるオブジェ
     クト形式(ハッシュアルゴリズム)を表示します。入力(input)の場合、複数
     のアルゴリズムがスペースで区切られて出力される場合があります。形式
     を指定しない場合、デフォルトは ‘storage’ です。

Other Options
=============

‘--since=datestring’
‘--after=datestring’
     日付文字列をパースし、 ‘git rev-list’ に対応する ‘-max-age=’ パラメ
     ーターを出力します。

‘--until=datestring’
‘--before=datestring’
     日付文字列をパースし、 ‘git rev-list’ に対応する ‘--min-age=’ パラ
     メーターを出力します。

<args>…
     パースされるフラグとパラメーター。

SPECIFYING REVISIONS
********************

リビジョンパラメータ ‘<rev>’ は必ずしもそうとは限りませんが、通常はコミ
ットオブジェクトに名前を付けます。これは、いわゆる「拡張SHA-1」構文を使
用します。 オブジェクト名を綴るにはさまざまな方法があります。このリスト
の終わり近くにリストされているものは、コミットに含まれているツリーとブロ
ブに名前を付けています。

     *Note*

     この文書は、gitで見られる「生の」構文を示しています。シェルおよびそ
     の他のUIでは、特殊文字を保護し、単語の分割を回避するために、追加の
     引用符が必要になる場合があります。

‘<sha1>’ 例: ‘dae86e1950b1277e545cee180551750029cfe735’, ‘dae86e’
     完全なSHA-1オブジェクト名(40バイトの16進文字列)、またはリポジトリ内
     で一意の先頭のsubstring。例えば
     dae86e1950b1277e545cee180551750029cfe735 と dae86e はどちらも、リポ
     ジトリ内にオブジェクト名が dae86e で始まる他のオブジェクトがない場
     合、全く同じコミットオブジェクトに名前を付けます。

‘<describeOutput>’ 例: ‘v1.7.4.2-679-g3bee7fb’
     ‘git describe’ からの出力。つまり、現在のコミットから最も近いタグ。
     オプションで、ダッシュ(-)とそのタグ以降現在のコミットが何番目になる
     かの数が続き、その後にダッシュ(-)、「g」、および省略されたオブジェ
     クト名が続きます。

‘<refname>’ 例: ‘master’, ‘heads/master’, ‘refs/heads/master’
     シンボリックref名。例えば ‘master’ は通常、 ‘refs/heads/master’ に
     よって参照されるコミットオブジェクトを意味します。 ‘heads/master’ と
     ‘tags/master’ の両方がある場合は、あなたは ‘heads/master’ と明示的
     に指定して、どちらを意味するかをGitに伝えることができます。 あいま
     いな場合、 ‘<refname>’ は、以下のルールに従い最初の一致を採用ことで
     明確になります:

       1. もし ‘$GIT_DIR/<refname>’ が存在するならば、それはあなたが指定
          した通りのものです(これは通常、‘HEAD’ と ‘FETCH_HEAD’ と
          ‘ORIG_HEAD’ と ‘MERGE_HEAD’ と ‘CHERRY_PICK_HEAD’ のみで役に立
          ちます)

       2. でなければ ‘refs/<refname>’ が存在すればそれを採用します。

       3. でなければ ‘refs/tags/<refname>’ が存在すればそれを採用します
          。

       4. でなければ ‘refs/heads/<refname>’ が存在すればそれを採用します
          。

       5. でなければ ‘refs/remotes/<refname>’ が存在すればそれを採用しま
          す。

       6. でなければ ‘refs/remotes/<refname>/HEAD’ が存在すればそれを採
          用します。

          ‘HEAD’ は、作業ツリーの変更に基づいたコミットに名前を付けます
          。 ‘FETCH_HEAD’ は、最後の ‘git fetch’ 呼び出しでリモートリポ
          ジトリからフェッチしたブランチを記録します。 ‘ORIG_HEAD’ は、
          ‘HEAD’ を大幅に移動するコマンドによって作成され、操作前の
          ‘HEAD’ の位置を記録します。これにより、ブランチの先端を実行前
          の状態に簡単に戻すことができます。 ‘MERGE_HEAD’ は、 ‘git
          merge’ を実行するときにブランチにマージするコミットを記録しま
          す。 ‘CHERRY_PICK_HEAD’ は、 ‘git cherry-pick’ を実行したとき
          にチェリーピックしているコミットを記録します。

          注意: 上記の ‘refs/*’ の場合、 ‘$GIT_DIR/refs’ ディレクトリま
          たは ‘$GIT_DIR/packed-refs’ ファイルのいずれかから発生する可能
          性があることに注意してください。ref名のエンコードは指定されて
          いませんが、一部の出力処理ではUTF-8でref名を想定する場合がある
          ため、UTF-8が推奨されます。

‘@’
     ‘@’ 単独では ‘HEAD’ のショートカットを意味します。

‘[<refname>]@{<date>}’ 例: ‘master@{yesterday}’, ‘HEAD@{5 minutes ago}’
     refの後に接尾辞 ‘@’ が続き、日付指定が中括弧のペアで囲まれています
     (例: ‘{yesterday}’ 、 ‘{1 month 2 weeks 3 days 1 hour 1 second
     ago}’ 、‘{1979-02-26 18:30:00}’ )。これは以前の時点でのrefの値を指
     定します。この接尾辞は、ref名の直後にのみ使用でき、refには既存のロ
     グ( ‘$GIT_DIR/logs/<ref>’ )が必要です。これは、特定の時点での *ロー
     カル* refの状態を検索することに注意してください。たとえば、先週ロー
     カルの ‘master’ ブランチに何があったか、です。特定の時間に行われた
     コミットを確認する場合は、 ‘--since’ と ‘--until’ を参照してくださ
     い。

‘<refname>@{<n>}’ 例: ‘master@{1}’
     refの後に接尾辞 ‘@’ が続き、数の指定が中括弧のペアで囲まれている場
     合(たとえば ‘{1}’, ‘{15}’)、そのrefのn個前の値を指定します。たとえ
     ば ‘master@{1}’ は ‘master’ の直前の値であり、 ‘master@{5}’ は
     ‘master’ の5個前の値です。この接頭辞は、ref名の直後にのみ使用でき、
     refには既存のログ( ‘$GIT_DIR/logs/<refname>’ )が必要です。

‘@{<n>}’ 例: ‘@{1}’
     空のref部分で ‘@’ コンストラクトを使用して、現在のブランチの
     reflogエントリを取得できます。たとえば、あなたがブランチ ‘blabla’ を
     使用している場合、 ‘@{1}’ は ‘blabla@{1}’ と同じ意味になります。

‘@{-<n>}’ 例: ‘@{-1}’
     構成 ‘@{-<n>}’ は、現在のブランチ/コミットの前にチェックアウトされ
     た<n>番目のブランチ/コミットを意味します。

‘[<branchname>]@{upstream}’ 例: ‘master@{upstream}’, ‘@{u}’
     ブランチ名の接尾辞 ‘@{upstream}’ (短縮形 ‘<branchname>@{u}’)は、
     branchnameで指定されたブランチの上部に構築するように設定されている
     ブランチを指します(‘branch.<name>.remote’ と ‘branch.<name>.merge’
     によって設定されます)。ブランチ名が欠落している場合は、デフォルトで
     現在のブランチ名になります。これらの接尾辞は、大文字で綴る場合にも
     受け入れられ、大文字と小文字を問わず同じ意味になります。

‘[<branchname>]@{push}’ 例: ‘master@{push}’, ‘@{push}’
     接尾辞 ‘@\{push}’ は、 ‘branchname’ がチェックアウトされているとき
     に ‘git push’ が実行された場合(またはブランチ名が指定されていない場
     合は現在の ‘HEAD’ )、「プッシュ先」のブランチを報告します。もちろん
     、プッシュ先はリモートリポジトリにあるため、そのブランチに対応する
     ローカルトラッキングブランチ(つまり、 ‘refs/remotes/’ 内の何か)を報
     告します。

     ここで、よりはっきり分かる例を以下に示します:

          $ git config push.default current
          $ git config remote.pushdefault myfork
          $ git switch -c mybranch origin/master

          $ git rev-parse --symbolic-full-name @{upstream}
          refs/remotes/origin/master

          $ git rev-parse --symbolic-full-name @{push}
          refs/remotes/myfork/mybranch

     注意: この例では、ある場所からプルして別の場所にプッシュする三角形
     のワークフローを設定していることに注意してください。非三角形のワー
     クフローでは、 ‘@\{push}’ は ‘@\{upstream}’ と同じであり、このよう
     なことをする必要はありません。

     この接尾辞は大文字で綴る場合にも受け入れられ、大文字と小文字を問わ
     ず同じことを意味します。

‘<rev>^[<n>]’ 例: ‘HEAD^, v1.5.1^0’
     リビジョンパラメータの接尾辞 ‘^’ は、そのコミットオブジェクトの最初
     の親を意味します。 ‘^<n>’ は <n> 番目の親を意味します(つまり、
     ‘<rev>^’ は ‘<rev>^1’ と同じです)。特別ルールとして、 ‘<rev>^0’ は
     コミット自体を意味し、 ‘<rev>’ がコミットオブジェクトを参照するタグ
     オブジェクトのオブジェクト名である場合に使用されます。

‘<rev>~[<n>]’ 例: ‘HEAD~, master~3’
     リビジョンパラメータの接尾辞 ‘~’ は、そのコミットオブジェクトの最初
     の親を意味します。リビジョンパラメータの接尾辞 ‘~<n>’ は、最初の親
     のみに続く、指定されたコミットオブジェクトの <n> 世代の祖先であるコ
     ミットオブジェクトを意味します。つまり、 ‘<rev>~3’ は ‘<rev>^^^’ と
     同じで、するってぇと ‘<rev>^1^1^1’ と同じということです。この形式に
     ついては以下の図を参照してください。

‘<rev>^{<type>}’ 例: ‘v0.99.8^{commit}’
     接尾辞 ‘^’ の後に中括弧のペアで囲まれたオブジェクトタイプ名が続くと
     いうことは、タイプ ‘<type>’ のオブジェクトが見つかるか、オブジェク
     トを逆参照できなくなるまで、 ‘<rev>’ でオブジェクトを再帰的に逆参照
     する(この場合は、いろいろ一旦飲み込んでしまったのを吐きもどすような
     感じだぬ)ことを意味します。 たとえば、 ‘<rev>’ がコミットっぽい場合
     、 ‘<rev>^{commit}’ は対応するコミットオブジェクトを記述します。同
     様に、 ‘<rev>’ がツリーっぽい場合、 ‘<rev>^{tree}’ は対応するツリー
     オブジェクトを記述します。 ‘<rev>^0’ は ‘<rev>^{commit}’ の省略形で
     す。

     ‘<rev>^{object}’ を使用すると、 ‘<rev>’ がタグである必要がなく、
     ‘<rev>’ を逆参照することなく、 ‘<rev>’ が存在するオブジェクトに名前
     を付けることができます。なお、タグはすでにオブジェクトであるため、
     オブジェクトに到達するために一度も逆参照する必要はありません。

     ‘<rev>^{tag}’ を使用して、 ‘<rev>’ が既存のタグオブジェクトを確実に
     識別することができます。

‘<rev>^{}’ 例: ‘v0.99.8^{}’
     接尾辞 ‘^’ の後に空のブレースペアが続くということは、オブジェクトが
     タグである可能性があることを意味し、タグ以外のオブジェクトが見つか
     るまでタグを再帰的に逆参照します。

‘<rev>^{/<text>}’ 例: ‘HEAD^{/fix nasty bug}’
     リビジョンパラメータの接尾辞 ‘^’ と、それに続くスラッシュで始まるテ
     キストを含む中括弧のペアは、以下の ‘:/fix nasty bug’ 構文と同じです
     が、 ‘^’ の前の ‘<rev>’ から到達可能な一致する最も若いコミットを返
     す点が異なります。

‘:/<text>’ 例: ‘:/fix nasty bug’
     コロンに続いてスラッシュそしてそれに続くテキストは、コミットメッセ
     ージが指定された正規表現と一致するコミットを示します。この名前は、
     HEADを含む任意のrefから到達可能な最も若い一致するコミットを返します
     。正規表現は、コミットメッセージの任意の部分に一致できます。文字列
     で始まるメッセージを照合するには、たとえば、 ‘:/^foo’ とします。特
     別なシーケンス ‘:/!’ はマッチングの修飾子用に予約されています。ます
     。 ‘:/!-foo’ は一致の否定を実行し、 ‘:/!!foo’ はリテラル ‘!’ 後に
     ‘foo’ が続く文字列とマッチします。 ‘:/!’ で始まるその他のシーケンス
     は今のところ予約されています。指定されたテキストによっては、シェル
     により追加の引用符が必要になる場合があります。

‘<rev>:<path>’ 例: ‘HEAD:README’, ‘master:./README’
     接尾辞 ‘:’ の後にパス(path)を続けると、コロンの前の部分によって名前
     が付けられたツリー風のオブジェクト内の、指定されたパスにあるブロブ
     またはツリーに名前が付けられます。 ‘./’ または ‘../’ で始まるパスは
     、現在の作業ディレクトリからの相対パスです。指定のパスは、作業ツリ
     ーのルートディレクトリからの相対パスに変換されます。これは、作業ツ
     リーと同じツリー構造を持つコミットまたはツリーからブロブまたはツリ
     ーをアドレス指定するのに最も役立ちます。

‘:[<n>:]<path>’ 例: ‘:0:README’, ‘:README’
     コロンに、オプションでステージ番号(0〜3)とコロンが続き、それにパス
     が続くと、指定されたパスのインデックス内のブロブオブジェクトに名前
     を付けます。ステージ番号省略(およびそれに続くコロン)は、ステージ0エ
     ントリーを示します。マージ作業中、ステージ1は共通の祖先、ステージ
     2はターゲットブランチのバージョン(通常は現在のブランチ)、ステージ
     3はマージされるブランチのバージョンです。

   以下はJon Loeligerによる図解です。コミットノードBとCはどちらもコミッ
トノードAの親です。親コミットは左から右に順序付けられます。

     G   H   I   J
      \ /     \ /
       D   E   F
        \  |  / \
         \ | /   |
          \|/    |
           B     C
            \   /
             \ /
              A

     A =      = A^0
     B = A^   = A^1     = A~1
     C =      = A^2
     D = A^^  = A^1^1   = A~2
     E = B^2  = A^^2
     F = B^3  = A^^3
     G = A^^^ = A^1^1^1 = A~3
     H = D^2  = B^^2    = A^^^2  = A~2^2
     I = F^   = B^3^    = A^^3^
     J = F^2  = B^3^2   = A^^3^2

SPECIFYING RANGES
*****************

‘git log’ などの履歴トラバースコマンドは、単一のコミットだけでなく、一連
のコミットで動作します。

   これらのコマンドの場合、前のセクションで説明した表記法を使用して単一
のリビジョンを指定することは、指定のコミットから「到達可能」なコミットの
組を意味します。

   複数のリビジョンを指定するということは、指定のコミットのいずれかから
到達可能なコミットの組を意味します。

   コミットの到達可能な組は、コミット自体とその祖先チェーン内のコミット
です。

   以下に示すように、接続されたコミット(connected commits)の組(「リビジ
ョン範囲」(revision range)と呼ばれる)を指定するためのいくつかの表記法が
あります。

Commit Exclusions
=================

‘^<rev>’ (カレット)記法
     とある到達可能なコミットをコミット達から除外するには、接頭辞 ‘^’ 表
     記を使用します。 例えば ‘^r1 r2’ は ‘r2’ から到達可能なコミットだけ
     ども、 ‘r1’ から到達可能なコミット(つまり ‘r1’ とその祖先)は除外す
     る事を意味します。

Dotted Range Notations
======================

‘..’ (2ドット)範囲記法
     ‘^r1 r2’ 操作は頻繁に表示されるため、省略形があります。(上記の
     SPECIFYING REVISIONS で説明されている構文に従って名前が付けられてい
     る)2つのコミット ‘r1’ と ‘r2’ がある場合、あなたは ‘^r1 r2’ によっ
     てr1から到達可能なコミットを取り除き、r2から到達可能なコミットを要
     求できます。そしてこれは ‘r1..r2’ と書くことができます。

‘...’ (3ドット)対称差記法
     似た表記 ‘r1...r2’ は ‘r1’ と ‘r2’ の対称差と呼ばれ、 ‘r1 r2 --not
     $(git merge-base --all r1 r2)’ として定義されます。 これは、 ‘r1’
     (左側)または ‘r2’ (右側)のいずれかから到達可能であるが、両方からは
     到達できないコミットの組です。

   これらの2つの省略表記では、一方の端を省略して、デフォルトでHEADにする
ことができます。たとえば、 ‘origin..’ は ‘origin..HEAD’ の省略形であり、
「originブランチから分岐(fork)してから何をしましたか？」と尋ねます。 同
様に、 ‘..origin’ は ‘HEAD..origin’ の省略形であり、「私がそれらから分岐
してから、originは何をしましたか？」と尋ねます。 ‘..’ は ‘HEAD..HEAD’ を
意味することに注意してください。これは、HEADから到達可能および到達不能の
両方の空の範囲です。

   2つの異なる範囲を取るように特別に設計されたコマンド(たとえば、2つの範
囲を比較するための "git range-diff R1 R2" ) は存在しますが、それらは例外
です。特に明記されていない限り、一連のコミットを操作するすべての "git" コ
マンドは、単一のリビジョン範囲で機能します。言い換えると、2つの「2ドット
範囲表記」を隣り合わせに記述します。

     $ git log A..B C..D

   ほとんどのコマンドでは2つのリビジョン範囲を指定しません。代わりに、接
続された単一のコミットの組、つまりBまたはDのいずれかから到達可能であるが
、AまたはCのどちらからも到達可能でないコミットの組に名前を付けます。線形
履歴では、以下のようになります:

     ---A---B---o---o---C---D

   AとBはCから到達可能であるため、これら2つの2ドット範囲記法で指定された
リビジョン範囲は単一のコミットDです。

Other <rev>^ Parent Shorthand Notations
=======================================

コミットとその親コミットによって形成される組に名前を付けるために、マージ
コミットに特に役立つ他の3つの省略形が存在します。

   ‘r1^@’ 表記は、 ‘r1’ のすべての親を意味します。

   ‘r1^!’ 表記には コミット ‘r1’ が含まれますが、そのすべての親は除外さ
れます。この表記自体は、単一のコミット ‘r1’ を示します。

   ‘<rev>^-[<n>]’ 表記には ‘<rev>’ が含まれますが、 <n> 番目の親(つまり
、 ‘<rev>^<n>..<rev>’ の省略形)は除外されます。 <n> が指定されていない場
合は ‘<n>’ = 1 とみなします。これは通常、 ‘<commit>^-’ を渡すだけで、マ
ージコミット ‘<commit>’(‘<commit>’ 自体を含む)でマージされたブランチ内の
すべてのコミットを取得できるマージコミットに役立ちます。

   ‘<rev>^<n>’ は単一のコミット親を指定することに関するものでしたが、こ
れらの3つの表記はその親も考慮します。たとえば、 ‘HEAD^2^@’ と言うことは
できますが、 ‘HEAD^@^2’ と言うことはできません。

Revision Range Summary
**********************

‘<rev>’
     <rev> から到達可能なコミット(つまり <rev> とその祖先)を含めます。

‘^<rev>’
     <rev> から到達可能なコミット(つまり <rev> とその祖先)を除外します。

‘<rev1>..<rev2>’
     <rev2> から到達可能なコミットを含めますが、 <rev1> から到達可能なコ
     ミットは除外します。 <rev1> または <rev2> のいずれかを省略すると、
     それらはそれぞれデフォルトで ‘HEAD’ になります。

‘<rev1>...<rev2>’
     <rev1> または <rev2> のいずれかから到達可能なコミットを含めますが、
     両方から到達可能なコミットは除外します。 <rev1> または <rev2> のい
     ずれかを省略すると、それらはそれぞれデフォルトで ‘HEAD’ になります
     。

‘<rev>^@’ 例: ‘HEAD^@’
     接尾辞 ‘^’ の後にアットマーク(‘@’)を付けることは、 ‘<rev>’ のすべて
     の親をリストすることと同じです(つまり、親から到達可能なものはすべて
     含まれますが、コミット自体は含まれません)。

‘<rev>^!’ 例: ‘HEAD^!’
     接尾辞 ‘^’ の後に感嘆符(‘!’)を付けることは、コミット ‘<rev>’ を指定
     し、そのすべての親の前に ‘^’ を付けてそれら(およびその祖先)を除外す
     ることと同じです。

‘<rev>^-<n>’ 例: ‘HEAD^-, HEAD^-2’
     ‘<rev>^<n>..<rev>’ と同等であり、 ‘<n>’ が指定されていない場合は
     ‘<n>’ = 1 です。

   上記のLoeliger図解を使用したいくつかの例を以下に示します。表記の拡張
と選択は、それぞれ段階が分かるようステップを踏んで説明してあります:

        Args   Expanded arguments    Selected commits
        D                            G H D
        D F                          G H I J D F
        ^G D                         H D
        ^D B                         E I J F B
        ^D B C                       E I J F B C
        C                            I J F C
        B..C   = ^B C                C
        B...C  = B ^F C              G H D E B C
        B^-    = B^..B
               = ^B^1 B              E I J F B
        C^@    = C^1
               = F                   I J F
        B^@    = B^1 B^2 B^3
               = D E F               D G H E F I J
        C^!    = C ^C^@
               = C ^C^1
               = C ^F                C
        B^!    = B ^B^@
               = B ^B^1 ^B^2 ^B^3
               = B ^D ^E ^F          B
        F^! D  = F ^I ^J D           G H D F

PARSEOPT
********

‘--parseopt’ モードでは、 ‘git rev-parse’ は、オプションをもみもみして、
Cビルトインと同じ機能をシェルスクリプトにもたらすのに役立ちます。これは
、 ‘getopt(1)’ と少し似た、オプションの正規化機能です(たとえば、単一のス
イッチの集合を分割します)。

   パースおよび理解できるオプションの仕様を標準入力で受け取り、引数を正
規化されたものに置き換えるために、‘sh(1)’ ‘eval’ に適した文字列をエコー
します。エラーが発生した場合は、標準エラーストリームで使用状況を出力し、
コード129で終了します。

   注: 結果を ‘eval’ に渡すときは、必ず引用符で囲んでください。例につい
ては、以下を参照してください。

Input Format
============

‘git rev-parse --parseopt’ 入力形式は完全にテキストベースです。 ‘--’ の
みを含む行で区切られた2つの部分から構成されます。セパレーターの前の行
(1つ以上である必要があります)が使用例に使用されます。区切り文字の後の行
は、オプションを示しています。

   オプションの各行の形式はいかのとおりです:

     <opt-spec><flags>*<arg-hint>? SP+ help LF

‘<opt-spec>’
     この形式は、短いオプション1文字で、続いてコンマ(_,_)で区切り、そし
     て長いオプション名があります。少なくとも短長のうち1つは必要ですが、
     両方揃ってなくてもいいです。 ‘<flags>’ 文字を含めることはできません
     。 ‘h,help’ や ‘dry-run’ や ‘f’ は正しい ‘<opt-spec>’ の例です。

‘<flags>’
     ‘<flags>’ とは ‘*’ または ‘=’ または ‘?’ または ‘!’ です。

        • オプションが引数を取る場合は、 ‘=’ を使用します。

        • ‘?’ の使用は、オプションがオプションの引数を取ることを意味しま
          す。オプションの引数を明確に解析できるようにするには、おそらく
          ‘--stuck-long’ モードを使用する必要があります。

        • ‘*’ を使用すると、このオプションが ‘-h’ 引数に対して生成された
          使用法にリストされてはならないことを意味します。 gitcli(7) に
          記載されているように、 ‘--help-all’ には表示されます。

        • ‘！’ を使用すると、対応する否定されたlongオプションを使用可能
          にしません。

‘<arg-hint>’
     ‘<arg-hint>’ は、指定された場合、引数を取るオプションのヘルプ出力で
     引数の名前として使用されます。 ‘<arg-hint>’ は最初の空白で終了しま
     す。複数単語の引数ヒントで単語を区切りたい時は、ダッシュを使う通例
     です。

   スペースを取り除いた後の行の残りの部分は、オプションに関連付けられた
ヘルプとして使用されます。

   空白行は無視され、この仕様に一致しない行はオプショングループヘッダー
として使用されます(意図的にそのような行を作成するためにはスペースで行を
開始します)。

Example
=======

     OPTS_SPEC="\
     some-command [<options>] <args>...

     some-command does foo and bar!
     --
     h,help    show the help

     foo       some nifty option --foo
     bar=      some cool option --bar with an argument
     baz=arg   another cool option --baz with a named argument
     qux?path  qux may take a path argument but has meaning by itself

       An option group Header
     C?        option C with an optional argument"

     eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

Usage text
==========

上記の例で ‘"$@"’ が ‘-h’ または ‘--help’ の場合、以下の使用法テキストが
表示されます:

     usage: some-command [<options>] <args>...

         some-command does foo and bar!

         -h, --help            show the help
         --foo                 some nifty option --foo
         --bar ...             some cool option --bar with an argument
         --baz <arg>           another cool option --baz with a named argument
         --qux[=<path>]        qux may take a path argument but has meaning by itself

     An option group Header
         -C[...]               option C with an optional argument

SQ-QUOTE
********

‘--sq-quote’ モードでは、 ‘git rev-parse’ は、 ‘sh(1)’ ‘eval’ に適した
1行を標準出力にエコーします。この行は、 ‘--sq-quote’ に続く引数を正規化
することによって作成されます。引数をクォートする以外に何も行いません。

   出力がシェル引用符で囲まれる前に、コマンド入力を ‘git rev-parse’ によ
って通常どおりに解釈するには ‘--sq’ オプションを参照してください。

Example
=======

     $ cat >your-git-script.sh <<\EOF
     #!/bin/sh
     args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
     command="git frotz -n24 $args"          # and use it inside a handcrafted
                                             # command line
     eval "$command"
     EOF

     $ sh your-git-script.sh "a b'c"

EXAMPLES
********

   • 現在のコミットのオブジェクト名を出力します:

          $ git rev-parse --verify HEAD

   • $REV シェル変数のリビジョンからコミットオブジェクト名を出力します:

          $ git rev-parse --verify --end-of-options $REV^{commit}

     $REV が空であるか、有効なリビジョンでない場合エラーになります。

   • 上記と同様ですが…:

          $ git rev-parse --default master --verify --end-of-options $REV

     これは、 $REV が空の場合、masterからのコミットオブジェクト名が出力
     されます。

GIT
***

Part of the git(1) suite

Name
****

git-revert — いくつかの既存のコミットを元に戻します

Synopsis
********

     git revert [–[no-]edit] [-n] [-m parent-number] [-s] [-S[<keyid>]] <commit>…
     git revert (–continue | –skip | –abort | –quit)

DESCRIPTION
***********

1つ以上の既存のコミットが与えられた場合、関連するパッチによって導入され
た変更を元に戻し、それらを記録するいくつかの新しいコミットを記録します。
これには、作業ツリーがクリーンである必要があります(HEADコミットからの変
更はありません)。

   注意: ‘git revert’ は、いくつかの新しいコミットを記録して、以前のコミ
ットの効果を元に戻すために使用されます(多くの場合、障害のあるコミットの
み)。あなたが作業ディレクトリ内のコミットされていないすべての変更を破棄
したい場合は、 git-reset(1) 、特に ‘--hard’ オプションについて参照すべき
です。あなたが別のコミットから特定のファイルを抽出したい場合は、
git-restore(1) 、特に ‘--source’ オプションについて参照すべきです。これ
らは作業ディレクトリ内のコミットされていない変更を破棄するため、これらの
選択肢には注意してください。

   3つのコマンドの違いについては、 git(1) の「Reset, restore and revert」
を参照してください。

OPTIONS
*******

<commit>…
     元に戻すためのコミットを指定。コミット名を綴る方法のより完全なリス
     トについては、 gitrevisions(7) を参照してください。コミットのセット
     を指定することもできますが、デフォルトではトラバーサルは実行されま
     せん。 git-rev-list(1) と、その ‘--no-walk’ オプションを参照してく
     ださい。

‘-e’
‘--edit’
     このオプションを使用すると、 ‘git revert’ は「戻し」(the revert)を
     コミットする前にあなたにコミットメッセージを編集させます。これは、
     端末からコマンドを実行する場合のデフォルトです。

‘-m parent-number’
‘--mainline parent-number’
     通常、マージのどの筋を本線(mainline)と見なすかわからないため、マー
     ジを元に戻すことはできません。 このオプションは、本線とする親番号
     (1から始まる)を指定し、指定された親を基準にして変更を元に戻すことが
     できます。

     マージコミットを戻す(revert)と、そのマージによってもたらされたツリ
     ーの変更が不要になることが宣言されます。その結果、その後に行われる
     マージでは、先に戻されたマージの先祖ではないコミットによってもたら
     されたツリーの変更のみが適用されます。これはあなたの望むところかも
     しれませんし、そうでないかもしれません。

     詳細については、 revert-a-faulty-merge How-To
     (howto/revert-a-faulty-merge.html) (誤ったマージの取り消し方法)を参
     照してください。

‘--no-edit’
     このオプションを使うと、 _git revert_ はコミットメッセージエディタ
     を起動しません。

‘--cleanup=<mode>’
     このオプションは、コミットメッセージがコミット機構に渡される前にど
     のようにクリーンアップされるかを決定します。詳細については、
     git-commit(1) を参照してください。 特に、競合が発生した場合、
     <mode> に値 ‘scissors’ が指定されていると、渡される前に、MERGE_MSG
     に切り取り線が追加されます。

‘-n’
‘--no-commit’
     通常、コマンドは、どのコミットが元に戻されたかを示すコミットログメ
     ッセージを含むいくつかのコミットを自動的に作成します。このフラグは
     、名前付きコミットを作業ツリーとインデックスに戻すために必要な変更
     を適用(apply)しますが、コミットは行いません。さらに、このオプション
     を使用する場合、インデックスはHEADコミットと一致する必要はありませ
     ん。 revertは、あなたのインデックスの開始状態に対して行われます。

     これは、複数のコミットの効果を連続してインデックスにrevertする場合
     に役立ちます。

‘-S[<keyid>]’
‘--gpg-sign[=<keyid>]’
‘--no-gpg-sign’
     GPG署名コミット。 ‘keyid’ 引数はオプションであり、デフォルトはコミ
     ッターIDになります。指定する場合は、スペースなしでオプションに指定
     する必要があります。 ‘--no-gpg-sign’ は、 ‘commit.gpgSign’ 構成変数
     と、 それより前で指定された ‘--gpg-sign’ の両方を打ち消すのに役立ち
     ます。

‘-s’
‘--signoff’
     コミットメッセージの最後に ‘Signed-off-by’ トレーラーを追加します。
     詳細については、 git-commit(1) の signoff オプションを参照してくだ
     さい。

‘--strategy=<strategy>’
     指定されたマージ戦略を使用します。指定できるのは一度だけです。詳細
     については、 git-merge(1) の「MERGE STRATEGIES」セクションを参照し
     てください。

‘-X<option>’
‘--strategy-option=<option>’
     マージ戦略固有のオプションをマージ戦略に渡します。詳細については、
     git-merge(1) を参照してください。

‘--rerere-autoupdate’
‘--no-rerere-autoupdate’
     可能であれば、rerereメカニズムの自動競合解決の結果でインデックスを
     更新できるようにします。

SEQUENCER SUBCOMMANDS
*********************

‘--continue’
     ‘.git/sequencer’ の情報を使用して、進行中の操作の続行を行います。失
     敗したcherry-pickまたはrevertの競合を解決した後、続行するために使用
     できます。

‘--skip’
     現在のコミットをスキップして、残りのシーケンスを続行します。

‘--quit’
     進行中の今回の操作を忘れてください。チェリーピックまたはrevertに失
     敗した後、シーケンサーの状態をクリアするために使用できます。

‘--abort’
     操作をキャンセルして、シーケンス操作前の状態に戻ります。

EXAMPLES
********

‘git revert HEAD~3’
     HEADの最後から4番目のコミットで指定された変更を元に戻し、元に戻した
     変更を使用して新しいコミットを作成します。

‘git revert -n master~5..master~2’
     コミットによって行われた変更を、masterの最後から5番目のコミット(そ
     れ自身を含む)から、masterの最後から3番目のコミット(それ自身を含む
     )に戻しますが、元に戻した変更でコミットを作成しないでください。元に
     戻すと、作業ツリーとインデックスのみが変更されます。

SEE ALSO
********

git-cherry-pick(1)

GIT
***

Part of the git(1) suite

Name
****

git-rm — 作業ツリーとインデックスからファイルを削除します

Synopsis
********

     git rm [-f | –force] [-n] [-r] [–cached] [–ignore-unmatch]
               [–quiet] [–pathspec-from-file=<file> [–pathspec-file-nul]]
               [–] [<pathspec>…]

DESCRIPTION
***********

pathspecに一致するファイルをインデックスから、または作業ツリーとインデッ
クスから削除します。 ‘git rm’ は、作業ディレクトリだけからファイルを削除
することはありません。 (作業ツリーからのみファイルを削除し、それをインデ
ックスに保持するオプションはありません。必要に応じて、 ‘/bin/rm’ を使用
してください。) 削除されるファイルはブランチの先端と同一である必要があり
、その内容の更新をインデックスにステージングすることはできませんが、その
デフォルトの動作は ‘-f’ オプションでオーバーライドできます。 ‘--cached’
が指定されている場合、ステージングされたコンテンツはブランチの先端または
ディスク上のファイルのいずれかに一致する必要があり、ファイルをインデック
スからのみ削除できます。 スパースチェックアウトが使用されている場合
(git-sparse-checkout(1) を参照)、 ‘git rm’ はスパースチェックアウトパタ
ーン内のパスのみを削除します。

OPTIONS
*******

<pathspec>…
     削除するファイル。先頭のディレクトリ名(たとえば、削除する
     ‘dir/file1’ や ‘dir/file2’ の ‘dir’)を指定して、ディレクトリ内のす
     べてのファイル削除でき、そして、 ‘-r’ オプションを明示的に指定する
     必要がありますが、再帰的にすべてのサブディレクトリを削除できます。

     このコマンドは、Gitに認識されているパスのみを削除します。

     ファイルグロブはディレクトリの境界を越えて一致します。 したがって、
     2つのディレクトリ ‘d’ と ‘d2’ が与えられた場合、 ‘git rm 'd*'’ と
     ‘git rm 'd/*'’ は異なります。前者はディレクトリ ‘d2’ もすべて削除す
     るからです。

     詳細については、 gitglossary(7) の「pathspec」エントリを参照してく
     ださい。

‘-f’
‘--force’
     更新チェックをオーバーライドします。

‘-n’
‘--dry-run’
     実際にファイルを削除することはありません。代わりに、インデックスに
     存在するか、でなければコマンドによって削除されるかを示すだけです。

‘-r’
     先頭のディレクトリ名が指定されている場合は、再帰的な削除を許可しま
     す。

‘--’
     このオプションは、コマンドラインオプションをファイルのリストから分
     離するために使用できます(ファイル名がコマンドラインオプションと間違
     えられる可能性がある場合に便利です)。

‘--cached’
     このオプションを使用して、インデックス分のみパスをステージング解除
     して削除します。作業ツリーファイルは、変更されているかどうかに関係
     なく、そのまま残されます。

‘--ignore-unmatch’
     一致するファイルがない場合にも、ステータスがゼロで終了(exit)します
     。

‘-q’
‘--quiet’
     ‘git rm’ は通常、削除されたファイルごとに1行(‘rm’ コマンドの形式で
     )を出力します。 このオプションは、その出力を抑制します。

‘--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文字で区切られ、他のすべての文字は文字通りに解釈されます(改行と
     引用符を含む)。

ファイルシステムから消えたファイルの削除
****************************************

‘git rm’ には、ファイルシステムから消えたパスのみをインデックスから削除
するオプションはありません。 ただし、ユースケースに応じて、実行できる方
法がいくつかあります。

git commit -a の使用
====================

次回のコミットで、作業ツリー内の追跡対象ファイルのすべての変更を記録し、
作業ツリーから削除されたファイルのすべての削除を(‘git rm’ ではなく、)
‘rm’ で記録する場合は、すべての削除を自動的に通知して記録するため、 ‘git
commit -a’ を使用します。 ‘git add -u’ を使用してコミットせずに同様の効
果を得ることもできます。

git add -A の使用
=================

ベンダーブランチの新しいコードドロップを受け入れる場合は、パスの削除と新
しいパスの追加、および既存のパスの変更の両方を記録する必要があります。

   通常、最初に以下のコマンドを使用して、追跡中のすべてのファイルを作業
ツリーから削除します:

     git ls-files -z | xargs -0 rm -f

   次に、作業ツリーで新しいコードを解凍(untar)します。または、変更を作業
ツリーに「rsync」することもできます。

   その後、作業ツリーのすべての削除、追加、および変更を記録する最も簡単
な方法は以下のとおりです:

     git add -A

   git-add(1) 参照。

Other ways
==========

あなたが本当にやりたいのは作業ツリーに存在しなくなったファイルをインデッ
クスから削除することだけである場合(おそらく、作業ツリーが汚れているため
に ‘git commit -a’ を使用できない)、以下のコマンドを使用します:

     git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached

SUBMODULES
**********

リポジトリはスーパープロジェクトの ‘.git’ ディレクトリ内にあるため、
gitfileを使用するサブモジュール(つまり、Gitバージョン1.7.8以降で複製され
たもの)のみが作業ツリーから削除されます。 サブモジュール(またはその中に
ネストされているものの1つ)がまだ ‘.git’ ディレクトリを使用している場合、
‘git rm’ はサブモジュールの履歴を保護するためにサブモジュールのgitディレ
クトリをスーパープロジェクトのgitディレクトリに移動します。 存在する場合
は、 gitmodules(5) ファイルの submodule.<name> セクションも削除され、そ
のファイルがステージングされます(‘--cached’ または ‘-n’ が使用されている
場合を除く)。

   HEADがインデックスに記録されているものと同じであり、追跡中のファイル
が変更されておらず、無視されない追跡中でないファイルがサブモジュールの作
業ツリーに存在しない場合、サブモジュールは最新であると見なされます。 無
視されたファイルは消耗品と見なされ、サブモジュールの作業ツリーの削除を停
止しません。

   あなたが削除をコミットせずにサブモジュールのローカルチェックアウトの
みを作業ツリーから削除する場合は、代わりに git-submodule(1) の ‘deinit’
を使用してください。 サブモジュールの削除の詳細については、
gitsubmodules(7) も参照してください。

EXAMPLES
********

‘git rm Documentation/\*.txt’
     ‘Documentation’ ディレクトリとそのサブディレクトリの下にあるすべて
     の ‘*.txt’ ファイルをインデックスから削除します。

     注意: この例では、アスタリスク(‘*’)がシェルからクォートされているこ
     とに注意してください。これにより、シェルではなくGitが、
     ‘Documentation/’ ディレクトリの下にあるファイルとサブディレクトリの
     パス名を展開できるようになります。

‘git rm -f git-*.sh’
     この例では、シェルでアスタリスクを展開できるため(つまり、あなたはフ
     ァイルを明示的にリストしているため)、 ‘subdir/git-foo.sh’ は削除さ
     れません。

BUGS
****

スーパープロジェクトの更新により、入力されたサブモジュールが削除されるた
びに(たとえば、削除の前後でコミットを切り替える場合)、古いサブモジュール
のチェックアウトは古い場所に残ります。古いディレクトリの削除は、
gitfileを使用している場合にのみ安全です。そうしないと、サブモジュールの
履歴も削除されます。 この手順は、サブモジュールの再帰的な更新が実装され
ている場合は廃止されます。

SEE ALSO
********

git-add(1)

GIT
***

Part of the git(1) suite

Name
****

git-send-email — パッチの集まりを電子メールとして送信します

Synopsis
********

     git send-email [<options>] <file|directory|rev-list options>…
     git send-email –dump-aliases

DESCRIPTION
***********

コマンドラインで指定されたパッチを取得し、電子メールで送信します。 パッ
チは、ファイルまたは、ディレクトリ(ディレクトリ内のすべてのファイルを送
信します)または、リビジョンリストとして直接指定できます。 リビジョンリス
トの場合、git-format-patch(1) によって受け入れられた任意の形式を ‘git
send-email’ に渡すことができます。

   電子メールのヘッダーは、コマンドラインオプションを使用して構成できま
す。 コマンドラインで指定されていない場合、ReadLine対応のインターフェイ
スでユーザーが必要な情報を提供するためのプロンプトが表示されます。

   パッチファイルに使用できる形式は2つあります:

  1. mbox形式ファイル

     これは、 git-format-patch(1) が生成するものです。 ほとんどのヘッダ
     ーとMIMEフォーマットは無視されます。

  2. Greg Kroah-Hartman の ‘send_lots_of_email.pl’ スクリプトで使用され
     たオリジナル形式

     この形式では、ファイルの1行目に「Cc:」値が含まれ、2行目としてメッセ
     ージの「Subject:」が含まれている必要があります。

OPTIONS
*******

電子メール作成
==============

‘--annotate’
     送信しようとしている各パッチを確認して編集します。 デフォルトは
     ‘sendemail.annotate’ の値です。 ‘sendemail.multiEdit‘の「
     CONFIGURATION」セクションを参照してください。

‘--bcc=<address>,...’
     メールごとに「Bcc:」の値を指定します。 デフォルトは ‘sendemail.bcc’
     の値です。

     このオプションは複数回指定できます。

‘--cc=<address>,...’
     各電子メールの開始「Cc:」値(starting "Cc:" value)を指定します。 デ
     フォルトは ‘sendemail.cc’ の値です。

     このオプションは複数回指定できます。

‘--compose’
     テキストエディタ(git-var(1)の GIT_EDITOR 参照)を呼び出して、パッチ
     シリーズの紹介メッセージ(introductory message)を編集します。

     ‘--compose’ が使用されている場合、 ‘git send-email’ は、メッセージ
     で指定されているFromとSubjectとIn-Reply-Toヘッダーを使用します。 メ
     ッセージの本文(ヘッダーと空行の後に入力するもの)に空行(または Git:
     プレフィックス)のみが含まれている場合、要約は送信されませんが、
     FromとSubjectとIn-Reply-Toヘッダーは削除されない限り使用されます。

     From ヘッダー または In-Reply-To ヘッダーが無い時はプロンプトが表示
     されます。

     ‘sendemail.multiEdit’ の「CONFIGURATION」セクションを参照してくださ
     い。

‘--from=<address>’
     電子メールの送信者(sender)を指定します。 コマンドラインで指定されて
     いない場合は、‘sendemail.from’ 構成オプションの値が使用されます。 コ
     マンドラインオプションも ‘sendemail.from’ も設定されていない場合、
     ユーザーは値の入力を求められます。 そのプロンプトのデフォルトは、
     ‘git var -l’ によって返される、GIT_AUTHOR_IDENTの値、または、
     GIT_AUTHOR_IDENTが設定されていない場合はGIT_COMMITTER_IDENTの値にな
     ります。

‘--reply-to=<address>’
     受信者からの返信先(reply)のアドレスを指定します。 メッセージへの応
     答(reply)が ‘--from’ パラメーターで指定されたものとは別のアドレスに
     送信される必要がある場合は、これを使用します。

‘--in-reply-to=<identifier>’
     最初のメール(または ‘--no-thread’ 指定の全てのメール)を、指定の
     Message-Id への応答(reply)として表示します。これにより、スレッドが
     壊れて新しいパッチシリーズが提供されるのを防ぎます。 2回目以降のメ
     ールは、 ‘--[no-]chain-reply-to’ 設定に従って返信(reply)として送信
     されます。

     そのため、例えば ‘--thread’ と ‘--no-chain-reply-to’ を指定すると、
     以下のように ‘[PATCH v2 0/3]’ が ‘[PATCH 0/2]’ に対する返信になるよ
     うに、2番目以降のパッチは最初のパッチへの返信になります:

          [PATCH 0/2] Here is what I did...
            [PATCH 1/2] Clean up and tests
            [PATCH 2/2] Implementation
            [PATCH v2 0/3] Here is a reroll
              [PATCH v2 1/3] Clean up
              [PATCH v2 2/3] New tests
              [PATCH v2 3/3] Implementation

     ‘--compose’ も設定されている場合のみ必要です。 ‘--compose’ が設定さ
     れていない場合は、プロンプトが表示されます。

‘--subject=<string>’
     メールスレッドの最初の件名を指定します。 ‘--compose’ も設定されてい
     る場合にのみ必要です。 ‘--compose’ が設定されていない場合、これはプ
     ロンプトが表示されます。

‘--to=<address>,...’
     生成された電子メールの主な受信者(primary recipient)を指定します。 通
     常、これは関連するプロジェクトの上流のメンテナになります。 デフォル
     トは、 ‘sendemail.to’ 構成値の値です。 それが指定されておらず、
     ‘--to-cmd’ が指定されていない場合、プロンプトが表示されます。

     このオプションは複数回指定できます。

‘--8bit-encoding=<encoding>’
     エンコードを宣言していない非ASCIIメッセージまたは件名に遭遇した場合
     は、 ヘッダー/引用符 を追加して、<encoding>でエンコードされているこ
     とを示します。 デフォルトは ‘sendemail.assume8bitEncoding’ の値です
     。 それが指定されていない場合に非ASCIIファイルが検出された場合はプ
     ロンプトが表示されます。

     注意:エンコーディングを検証する試みは一切行われないことに注意してく
     ださい。

‘--compose-encoding=<encoding>’
     作成するッセージのエンコードを指定します。 デフォルトは
     ‘sendemail.composeencoding’ の値です。 それが指定されていない場合は
     、UTF-8 を想定されます。

‘--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)’
     SMTP経由でメッセージを送信するために使用する転送エンコーディングを
     指定します。 非ASCIIメッセージに遭遇すると、 ‘7bit’ は失敗します。
     ‘quoted-printable’ は、リポジトリにキャリッジリターンを含むファイル
     が含まれている場合に役立ちますが、生のパッチ電子メールファイル
     (MUAで保存されたもの)を手動で検査するのがとても難しくなります。
     ‘base64’ はさらに確実ですが、さらに不透明です。 ‘auto’ は、可能な場
     合は8ビットを使用し、それ以外の場合は ‘quoted-printable’ を使用しま
     す。

     デフォルトは、‘sendemail.transferEncoding’ 構成値です。 それが指定
     されていない場合、デフォルトは ‘auto’ です。

‘--xmailer’
‘--no-xmailer’
     ‘X-Mailer:’ ヘッダーを追加(または追加を防止)します。 デフォルトでは
     追加されますが、 ‘sendemail.xmailer’ 構成変数を ‘false’ に設定する
     ことでオフにできます。

電子メール送信
==============

‘--envelope-sender=<address>’
     メールの送信に使用するエンベロープ(envelope)の送信者を指定します。
     これは、デフォルトのメールアドレスがメーリングリストに申し込まれて
     いるメールアドレスではない場合に役立ちます。 ‘From’ アドレスを使用
     するには、値を ‘auto’ 」に設定します。 sendmailバイナリを使用する場
     合は、 ‘-f’ パラメータに適切な権限が必要です。 デフォルトは、
     ‘sendemail.envelopeSender’ 構成変数の値です。 それが指定されていな
     い場合、エンベロープ送信者の選択はMTAに任されています。

‘--sendmail-cmd=<command>’
     電子メールを送信するために実行するコマンドを指定します。 コマンドは
     sendmailのようなものでなければなりません。 具体的には、 ‘-i’ オプシ
     ョンをサポートする必要があります。 コマンドは、必要に応じてシェルで
     実行されます。 デフォルトは ‘sendemail.sendmailcmd’ 構成の値です。
     ‘sendemail.sendmailcmd’ 構成の値が指定されていない場合、かつ、
     ‘--smtp-server’ も指定されていない場合、 ‘git-send-email’ は
     ‘/usr/sbin’ と ‘/usr/lib’ と $PATH で ‘sendmail’ を検索します。

‘--smtp-encryption=<encryption>’
     使用する暗号化を ‘ssl’ または ‘tls’ のどちらかで指定します。その他
     の値は平文SMTPに戻します。 デフォルトは ‘sendemail.smtpEncryption’
     の値です。

‘--smtp-domain=<FQDN>’
     SMTPサーバーへの HELO/EHLO コマンドで使用される完全修飾ドメイン名
     (FQDN)を指定します。 一部のサーバーでは、FQDNがIPアドレスと一致する
     必要があります。 設定されていない場合、 ‘git send-email’ はFQDNを自
     動的に判別しようとします。 デフォルトは ‘sendemail.smtpDomain’ の値
     です。

‘--smtp-auth=<mechanisms>’
     許可されたSMTP-AUTHメカニズムの空白で区切られた
     (Whitespace-separated)リスト。 この設定は、リストされたメカニズムの
     みを使用するように強制します。 例:

          $ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...

     指定されたメカニズムの少なくとも1つがSMTPサーバによって宣伝
     (advertise)されたメカニズムと一致し、利用されるSASLライブラリによっ
     てサポートされている場合、そのメカニズムが認証に使用されます。
     ‘sendemail.smtpAuth’ と ‘--smtp-auth’ のどちらも指定されない場合、
     SASL ライブラリでサポートされているすべてのメカニズムが使用される可
     能性があります。 特別な値として ‘none’ を指定すると、 ‘--smtp-user’
     と独立して認証を完全に無効にすることができます。

‘--smtp-pass[=<password>]’
     SMTP-AUTHのパスワード。 引数はオプションです。引数が指定されていな
     い場合は、空の文字列がパスワードとして使用されます。 デフォルトは
     ‘sendemail.smtpPass’ の値ですが、 ‘--smtp-pass’ は常に
     ‘sendemail.smtpPass’ の値を上書きします。

     さらに、パスワードを構成ファイルまたはコマンドラインで指定する必要
     はありません。 ユーザー名が指定されている(‘--smtp-user’ または
     ‘sendemail.smtpUser’ を使用)が、パスワードが指定されていない
     (‘--smtp-pass’ または ‘sendemail.smtpPass’ を使用)場合、パスワード
     ‘git-credential’ を使用して取得されます。

‘--no-smtp-auth’
     SMTP認証を無効にします。 ‘--smtp-auth=none’ の省略形

‘--smtp-server=<host>’
     設定されている場合、使用する送信SMTPサーバを指定します(例:
     ‘smtp.example.com’ または生のIPアドレス)。 これが未指定の場合で、か
     つ、 ‘--sendmail-cmd’ も未指定の場合、デフォルトでは ‘/usr/sbin’ と
     ‘/usr/lib’ と $PATH にある ‘sendmail’ を探します。それが存在しなけ
     れば ‘localhost’ にフォールバックされます。

     下位互換性のために、このオプションでは、代わりにsendmailのようなプ
     ログラムの絶対パス名を指定することもできます。 プログラムは ‘-i’ オ
     プションをサポートする必要があります。 このメソッドは、引数の受け渡
     しや平文コマンド名の使用をサポートしていません。 これらの場合には、
     代わりに ‘--sendmail-cmd’ の使用を検討してください。

‘--smtp-server-port=<port>’
     デフォルトのポートとは異なるポートを指定します(SMTPサーバーは通常
     smtpポート25をリッスンしますが、送信ポート587または共通のSSL smtpポ
     ート465もリッスンする場合があります)。 シンボリックポート名(たとえ
     ば、587ではなく "submission")も受け入れられます。 ポートは、
     ‘sendemail.smtpServerPort’ 構成変数を使用して設定することもできます
     。

‘--smtp-server-option=<option>’
     設定されている場合、使用する送信SMTPサーバーオプションを指定します
     。 デフォルト値は、 ‘sendemail.smtpServerOption’ 構成オプションで指
     定できます。

     ‘--smtp-server-option’ オプションは、サーバーに渡すオプションごとに
     繰り返す必要があります。 同様に、構成ファイルではオプションごとに異
     なる行を使用する必要があります。

‘--smtp-ssl’
     _–smtp-encryptionssl_ の、大昔からのエイリアス。

‘--smtp-ssl-cert-path’
     SMTP SSL/TLS 証明書検証用の信頼できるCA証明書のストアへのパス
     (‘c_rehash’ によって処理されたディレクトリ、または1つ以上のPEM形式
     の証明書が連結された単一のファイル: これらの詳細については、
     verify(1) の ‘-CAfile’ と ‘-CApath’ を参照してください)。 証明書の
     検証を無効にするには、空の文字列に設定します。 デフォルトは、設定さ
     れている場合は ‘sendemail.smtpsslcertpath’ 構成変数の値、それ以外の
     場合はバッキングSSLライブラリのコンパイル済みデフォルト(ほとんどの
     プラットフォームで最良の選択)です。

‘--smtp-user=<user>’
     SMTP-AUTHのユーザー名。 デフォルトは ‘sendemail.smtpUser’ の値です
     。 (‘--smtp-user’ または ‘sendemail.smtpUser’ で)ユーザー名が指定さ
     れていない場合、認証は試行されません。

‘--smtp-debug=0|1’
     デバッグ出力を有効(1)または無効(0)にします。 有効にすると、SMTPコマ
     ンドとその応答が出力されます。 TLS接続と認証の問題をデバッグするの
     に役立ちます。

‘--batch-size=<num>’
     一部の電子メールサーバー(たとえば smtp.163.com)では、セッション(ま
     たは接続)ごとに送信される電子メールの数が制限されているため、多くの
     メッセージを送信すると失敗します。 このオプションを使用すると、
     ‘send-email’ は <num> メッセージの送信後に切断され、数秒待って
     (‘--relogin-delay’ 参照)、再接続して、このような制限を回避します。
     これが発生するたびにパスワードを再入力する必要がないように、何らか
     の形式のクレデンシャルヘルパーを使用することをお勧めします。 デフォ
     ルトは ‘sendemail.smtpBatchSize’ 構成変数です。

‘--relogin-delay=<int>’
     SMTPサーバーに再接続する前に <int> 秒待機します。 ‘--batch-size’ オ
     プションと一緒に使用します。 デフォルトは
     ‘sendemail.smtpReloginDelay’ 構成変数です。

自動化
======

‘--no-[to|cc|bcc]’
     configで以前に設定した "To:" と "Cc:" と "Bcc:" アドレスのリストを
     すべてクリアします。

‘--no-identity’
     configで設定された ‘sendemail.identity’ から読み取られた値があるな
     らば、その値をクリアします。

‘--to-cmd=<command>’
     パッチファイルごとに1回実行するコマンドを指定し、パッチファイル固有
     の ‘To:’ エントリーを生成するようにします。 このコマンドの出力は、
     1行に1つの電子メールアドレスでなければなりません。 デフォルトは、設
     定値 ‘sendemail.tocmd’ の値です。

‘--cc-cmd=<command>’
     パッチファイルごとに1回実行するコマンドを指定し、パッチファイル固有
     の ‘Cc:’ エントリを生成するようにします。 このコマンドの出力は、1行
     に1つの電子メールアドレスでなければなりません。 デフォルトは
     ‘sendemail.ccCmd’ 設定値の値です。

‘--[no-]chain-reply-to’
     これが設定されている場合、各メールは前に送信されたメールへの返信と
     して送信されます。 ‘--no-chain-reply-to’ で無効にすると、最初の電子
     メール以降のすべての電子メールが、最初に送信された電子メールへの返
     信として送信されます。 これを使用する場合、最初のファイルはパッチシ
     リーズ全体の概要であることが推奨されます。 デフォルトでは無効になっ
     ていますが、 ‘sendemail.chainReplyTo’ 構成変数を使用して有効にする
     ことができます。

‘--identity=<identity>’
     構成ID。 指定すると、 ‘sendemail.<identity>’ サブセクションの値が
     ‘sendemail’ セクションの値よりも優先されます。 デフォルトのIDは、
     ‘sendemail.identity‘の値です。

‘--[no-]signed-off-by-cc’
     これが設定されている場合は、 ‘Signed-off-by’ トレーラーまたは ‘Cc:’
     行にある電子メールアドレスをccリストに追加します。 デフォルトは
     ‘sendemail.signedoffbycc’ 構成変数の値です。
     ‘sendemail.signedoffbycc’ 構成変数が指定されていない場合、デフォル
     トは ‘--signed-off-by-cc’ です。

‘--[no-]cc-cover’
     これが設定されている場合、シリーズの最初のパッチ(通常はカバーレター
     )の ‘Cc:’ ヘッダー達で見つかった電子メールアドレスが、各電子メール
     アドレスのセットのccリストに追加されます。 デフォルトは、
     ‘sendemail.cccover’ 構成の値です。 ‘sendemail.cccover’ 構成が指定さ
     れていない場合、デフォルトは ‘--no-cc-cover’ です。

‘--[no-]to-cover’
     これが設定されている場合、シリーズの最初のパッチ(通常はカバーレター
     )の ‘To:’ ヘッダー達で見つかった電子メールアドレスが、各電子メール
     アドレスのセットのtoリストに追加されます。 デフォルトは、
     ‘sendemail.tocover’ 構成の値です。 ‘sendemail.tocover’ 構成の値が指
     定されていない場合、デフォルトで ‘--no-to-cover’ になります。

‘--suppress-cc=<category>’
     自動CC(auto-cc)を抑制するために、以下の追加受信者カテゴリを指定しま
     す:

        • ‘author’ は、パッチの作者を含めないようにします。

        • ‘self’ は送信者を含めないようにします。

        • ‘cc’ は、 ‘self’ を指定した場合を除き、Cc行で言及されている人
          をパッチヘッダーに含めないようにします(含めたいなら _self_ を
          使用します)。

        • ‘bodycc’ は、 ‘self’ を指定した場合を除き、 パッチ本体(コミッ
          トメッセージ)にCc行で言及されている人を含めないようにします(含
          めたい場合は _self_ を使います)。

        • ‘sob’ は、 ‘self’ を指定している場合を除き、 Signed-off-by に
          記載されている人を含めないようにします(含めたい場合は ‘self’ を
          使用します)。

        • ‘misc-by’ は、 ‘Signed-off-by’ (‘sob’ を使用)を除いて、パッチ
          本体に Acked-byや、Reviewed-byや、Tested-byや、その他の ‘-by’
          行で言及されているのを含めないようにします。

        • ‘cccmd’ は、 ‘--cc-cmd’ の実行を回避します。

        • ‘body’ は ‘sob’ + ‘bodycc’ + ‘misc-by’ と同じです。

        • ‘all’ は、すべての自動cc値を抑制します。

     デフォルトは ‘sendemail.suppresscc’ 構成の値です。
     ‘sendemail.suppresscc’ 構成が指定されていない場合に、
     ‘--suppress-from’ が指定されている場合はデフォルトで ‘self’ になり
     、 ‘--no-signed-off-cc’ が指定されている場合は ‘body’ になります。

‘--[no-]suppress-from’
     これが設定されている場合は、 ‘From:’ アドレス を ‘cc:’ リストに追加
     しないでください。 デフォルトは ‘sendemail.suppressFrom’ 構成の値で
     す。 ‘sendemail.suppressFrom’ 構成が指定されていない場合、デフォル
     トは ‘--no-suppress-from’ です。

‘--[no-]thread’
     これが設定されている場合、In-Reply-To と References ヘッダー達は送
     信される各メールアドレスに追加されます。 各メールが前のメールを参照
     するのか(‘git format-patch’ の文言に従った「深い」(deep)スレッディ
     ング)、最初のメールを参照するのか(「浅い」(shallow)スレッディング
     )については ‘--[no-]chain-reply-to’ で制御されます。

     ‘--no-thread’ で無効にすると、それらのヘッダーは追加されません
     (‘--in-reply-to’ で指定されていない限り)。 デフォルトは、
     ‘sendemail.thread’ 構成の値です。 ‘sendemail.thread’ 構成が指定され
     ていない場合、デフォルトは ‘--thread’ です。

     ‘git send-email’ が In-Reply-To ヘッダを追加するように要求したとき
     に、すでにそのヘッダが存在しないことを確認するのはユーザー側です
     ((特に ‘git format-patch’ がスレッド化するように設定されている場合
     は注意が必要です)。 これを怠ると、受信者の MUA で期待通りの結果が得
     られないことがあります。

管理
====

‘--confirm=<mode>’
     送信する直前に確認(confirm)します:

        • ‘always’ は送信前に常に確認します

        • ‘never’ は送信する前に確認すること決してありません

        • ‘cc’ は、send-emailがパッチからCcリストにアドレスを自動的に追
          加したときは、送信前に確認します

        • ‘compose’ は、 ‘--compose’ を使用した時に、最初のメッセージを
          送信する前に確認します。

        • ‘auto’ は ‘cc’+ ‘compose’ と同じです

     デフォルトは ‘sendemail.confirm’ 構成の値です。 ‘sendemail.confirm’
     構成が指定されていない場合、抑制オプション(suppress options)のいず
     れかが指定されていない限り、デフォルトは ‘auto’ になります。抑制オ
     プションのいずれかが指定されている場合は、デフォルトで ‘compose‘に
     なります。

‘--dry-run’
     実際にメールを送信する以外はすべて行います。

‘--[no-]format-patch’
     引数が参照またはファイル名として理解される場合は、それを
     format-patch引数(‘--format-patch’)またはファイル名
     (‘--no-format-patch’)として理解することを選択します。 デフォルトで
     は、このような競合が発生すると、 ‘git send-email’ は失敗します。

‘--quiet’
     git-send-emailのおしゃべりを減らします。 電子メール１通につき1行出
     力するだけにします。

‘--[no-]validate’
     パッチの健全性チェックを実行します。 現状、検証(validation)とは以下
     のことを意味します:

        • sendemail-validate フックが存在する場合はそれを呼び出します
          (githooks(5) 参照)。

        • 適切な転送エンコーディング(‘auto’ または ‘base64’ または
          ‘quoted-printable’)が使用されていない時は、998文字より長い行を
          含むパッチについて警告します。 これは、
          http://www.ietf.org/rfc/rfc5322.txt
          (http://www.ietf.org/rfc/rfc5322.txt) で説明されているSMTPの制
          限によるものです。

     デフォルトは ‘sendemail.validate’ の値です。 これが設定されていない
     場合、デフォルトは ‘--validate’ になります。

‘--force’
     安全チェックで防止できる場合でも、電子メールを送信してください。

情報
====

‘--dump-aliases’
     通常の操作の代わりに、構成されたエイリアスファイルからアルファベッ
     ト順に1行に1つずつ短縮エイリアス名をダンプします。 これにはエイリア
     ス名のみが含まれ、拡張された電子メールアドレスは含まれないことに注
     意してください。 エイリアスの詳細については、
     ‘sendemail.aliasesfile’ を参照してください。

CONFIGURATION
*************

sendemail.aliasesFile
     長いメールアドレスを入力しないようにするには、これが1つ以上のメール
     エイリアスファイルを指すようにします。 ‘sendemail.aliasFileType’ も
     指定する必要があります。

sendemail.aliasFileType
     sendemail.aliasesFile で指定するファイルの形式。 ‘mutt’, ‘mailrc’,
     ‘pine’, ‘elm’, ‘gnus’ のいずれか、または ‘sendmail’ である必要があ
     ります。

     各形式のエイリアスファイルがどのように見えるかは、同じ名前の電子メ
     ールプログラムのドキュメントに記載されています。 標準フォーマットと
     の違いと制限を以下で説明します:

     sendmail

             • クォートされたエイリアスとクォートされたアドレスはサポー
               トされていません。 ‘"’ 記号を含む行は無視されます。

             • ファイル(‘/path/name’)またはパイプ(‘|command’)へのリダイ
               レクトはサポートされていません。

             • ファイルのインクルード(‘:include: /path/name’)はサポート
               されていません。

             • 明示的にサポートされていない構文や、パーサーが認識できな
               いその他の行については、標準エラー出力に警告が表示されま
               す。

sendemail.multiEdit
     true(デフォルト)の場合、編集する必要のあるファイルを編集するために
     単一のエディターインスタンスが生成されます(‘--annotate’ が使用され
     ている場合はパッチ、 ‘--compose’ が使用されている場合はサマリー)。
     falseの場合、ファイルは次々に編集され、毎回新しいエディターインスタ
     ンスが生成されます。

sendemail.confirm
     送信前に確認するかどうかのデフォルトを設定します。 ‘always’ または
     ‘never’ または ‘cc’ または ‘compose’ または ‘auto’ のいずれかである
     必要があります。 これらの値の意味については、前セクションの
     ‘--confirm’ を参照してください。

EXAMPLES
********

Use gmail as the smtp server
============================

‘git send-email’ を使用してGMail SMTPサーバーを介してパッチを送信するに
は、 ‘~/.gitconfig’ を編集してあなたのアカウント設定を指定します:

     [sendemail]
             smtpEncryption = tls
             smtpServer = smtp.gmail.com
             smtpUser = yourname@gmail.com
             smtpServerPort = 587

   Gmailアカウントで多要素認証を設定している場合は、 ‘git send-email’ で
使用するアプリ固有のパスワード(アプリ パスワード)を生成する必要がありま
す。 https://security.google.com/settings/security/apppasswords
(https://security.google.com/settings/security/apppasswords) にアクセス
して作成します。

   Gmailアカウントで多要素認証を設定していない場合、「安全性の低いアプリ
のアクセス」を許可する必要があります。
https://myaccount.google.com/lesssecureapps
(https://myaccount.google.com/lesssecureapps) にアクセスして有効にします
。

   あなたのコミットをメーリングリストに送信する準備ができたら、以下のコ
マンドを実行します:

     $ git format-patch --cover-letter -M origin/master -o outgoing/
     $ edit outgoing/0000-*
     $ git send-email outgoing/*

   初めて実行すると、資格情報の入力を求められます。 必要に応じて、アプリ
固有のパスワードまたは通常のパスワードを入力します。 クレデンシャルヘル
パーを構成している場合(git-credential(1) 参照)、パスワードはクレデンシャ
ルストアに保存されるため、次回入力する必要はありません。

   注意: Perlのディストリビューションとともにインストールできる次のコア
Perlモジュールが必要です: ‘MIME::Base64’ と ‘MIME::QuotedPrint’ と
‘Net::Domain’ と ‘Net::SMTP’ 。 また、次の追加のPerlモジュールも必要です
: ‘Authen::SASL’ と ‘Mail::Address’ 。

SEE ALSO
********

git-format-patch(1), git-imap-send(1), mbox(5)

GIT
***

Part of the git(1) suite

Name
****

git-send-pack — Gitプロトコルを介してオブジェクトを別のリポジトリにプッ
シュする

Synopsis
********

     git send-pack [–all] [–dry-run] [–force] [–receive-pack=<git-receive-pack>]
                     [–verbose] [–thin] [–atomic]
                     [–[no-]signed|–signed=(true|false|if-asked)]
                     [<host>:]<directory> [<ref>…]

DESCRIPTION
***********

通常は、代わりに、このコマンドの上位レベルのラッパーである「git push」を
使用することをお勧めします。 git-push(1) を参照してください。

   おそらくリモートリポジトリで ‘git-receive-pack’ を呼び出し、現在のリ
ポジトリから更新して、名前付きrefsを送信します。

OPTIONS
*******

‘--receive-pack=<git-receive-pack>’
     リモート側の 「git-receive-pack」プログラムへのパス。 sshを介してリ
     モートリポジトリにプッシュするとき、デフォルトの $PATH のディレクト
     リにプログラムが無い場合に便利です。

‘--exec=<git-receive-pack>’
     ‘--receive-pack=<git-receive-pack>’ と同じ。

‘--all’
     更新するrefを明示的に指定する代わりに、ローカルに存在するすべてのヘ
     ッドを更新します。

‘--stdin’
     stdinからrefのリストを1行に1つずつ取得します。 このオプションに加え
     てコマンドラインでrefが指定されている場合、stdinからのrefはコマンド
     ラインでのrefの後に処理されます。

     ‘--stateless-rpc’ がこのオプションと一緒に指定されている場合、refの
     リストはパケット形式(pkt-line)である必要があります。各refは個別のパ
     ケットに含まれている必要があり、リストはフラッシュパケットで終了し
     ている必要があります。

‘--dry-run’
     実際に更新を送信する以外はすべて行います。

‘--force’
     通常、このコマンドは、上書きに使用されたローカル ref の祖先ではない
     リモート ref の更新を拒否します。 このフラグは、このチェックを無効
     にします。 これが意味することは、リモートリポジトリがコミットを失う
     可能性があるということです。注意して使用してください。

‘--verbose’
     おしゃべりに実行します。

‘--thin’
     ネットワークトラフィックを削減するために、パックに含まれていないオ
     ブジェクトに基づいてオブジェクトを削除された形式で記録する薄いパッ
     ク(thin pack)を送信します。

‘--atomic’
     参照を更新するためにアトミック取引(atomic transaction)を使用します
     。いずれかのrefが更新に失敗した場合、refを変更せずにプッシュ全体が
     失敗します。

‘--[no-]signed’
‘--signed=(true|false|if-asked)’
     プッシュリクエストをGPG署名して、受信側のrefを更新し、フックでチェ
     ックしたり、ログに記録したりできるようにします。 ‘false’ または
     ‘--no-signed’ の場合、署名は試行されません。 ‘true’ または
     ‘--signed’ の場合、サーバーが署名付きプッシュをサポートしていないと
     、プッシュは失敗します。 ‘if-asked’ に設定されている場合、サーバー
     が署名されたプッシュをサポートしている場合にのみ署名します。 ‘gpg
     --sign’ の実際の呼び出しが失敗した場合も、プッシュは失敗します。 受
     信側の詳細については、 git-receive-pack(1) を参照してください。

‘--push-option=<string>’
     サーバー側のフックで使用するためのプッシュオプションとして、指定さ
     れた文字列を渡します。 サーバーがプッシュオプションをサポートしてい
     ない場合は、エラーになります。 詳細については、 git-push(1) と
     githooks(5) を参照してください。

<host>
     リポジトリを収容するリモートホスト。 この部分を指定すると、sshを介
     して「git-receive-pack」が呼び出されます。

<directory>
     更新するリポジトリ。

<ref>…
     更新するリモートref。

SPECIFYING THE REFS
*******************

リモート側で更新するrefを指定するには、3つの方法があります。

   ‘--all’ フラグを使用すると、ローカルに存在するすべての参照がリモート
側に転送されます。 このフラグを使用する場合、 <ref> を指定することはでき
ません。

   ‘--all’ がなく、 _<ref>_ がない場合、ローカル側とリモート側の両方に存
在するヘッドが更新されます。

   (コマンドラインまたは ‘--stdin’ を介して、)1つ以上の _<ref>_ が明示的
に指定されている場合、単一のパターン、またはコロン(‘:’)で区切られたその
ようなパターンのペアのいずれかです(これはref名にコロンを含めることはでき
ないことを意味します)。単一のパターン ‘<name>’ は、‘<name>:<name>’ の省
略形です。

   各パターンペアは、ソース側(コロンの前)と、宛先側(コロンの後)で構成さ
れます。プッシュされるrefは、ソース側にマッチするモノを見つけることによ
って決定され、プッシュされる場所は、宛先側を使用して決定されます。refの
照合に使用されるルールは、シンボリックref名を解決するために「git
rev-parse」で使用されるルールと同じです。 git-rev-parse(1) を参照してく
ださい。

   • <src> がローカル参照の1つと正確に一致しない場合はエラーとなります。

   • <dst> が複数のリモート参照と一致する場合はエラーになります。

   • <dst> がどのリモート参照とも一致しない場合は以下のいずれかです。

        • 「refs/」で始まる必要があります。 この場合、文字通り <dst> が
          宛先として使用されます。

        • <src> == <dst> および、 <src> に一致するrefは、リモートrefのセ
          ットに存在してはなりません。 ローカルで一致する参照 <src> が、
          宛先の名前として使用されます。

   ‘--force’ がない場合、<src> refは、<dst>が存在しない場合、または
<dst>が<src>の適切なサブセット(つまり、祖先)である場合にのみリモートに保
存されます。 「早送りチェック」(fast-forward check)と呼ばれるこのチェッ
クは、リモートrefを誤って上書きして、そこから他の人のコミットを失うこと
を回避するために行われます。

   ‘--force’ を使用すると、すべてのrefに対して早送りチェック
(fast-forward check)が無効になります。

   オプションで、<ref>パラメーターの前にプラスの「+」記号を付けて、その
refでのみ早送りチェック(fast-forward check)を無効にすることができます。

GIT
***

Part of the git(1) suite

Name
****

git-sh-i18n–envsubst — i18nフォールバック用のGit独自のenvsubst(1)

Synopsis
********

     eval_gettext () {
             printf "%s" "$1" | (
                     export PATH $(git sh-i18n–envsubst –variables "$1");
                     git sh-i18n–envsubst "$1"
             )
     }

DESCRIPTION
***********

これは、全くもってエンドユーザーが実行するコマンドではありません。この文
書は、配管スクリプトを研究している、および/または新しいスクリプトを作成
している人々を対象としています。

   _git sh-i18n–envsubst_ は、GNU gettextパッケージに付属するGNU
‘envsubst(1)’ プログラムのGit用簡略版です。これは、 git-sh-i18n(1) によ
って内部的に使用され、 ‘eval_gettext’ 関数に渡された変数を差し込みます。

   インターフェイスについては何も約束されていません。また、このプログラ
ムが次のバージョンのGitで警告なしに消えることはありません。使用しないで
ください。(No promises are made about the interface, or that this
program won’t disappear without warning in the next version of Git.
Don’t use it.)

GIT
***

Part of the git(1) suite

Name
****

git-sh-i18n — シェルスクリプトのためのGit用i18nセットアップコード

Synopsis
********

     . "$(git –exec-path)/git-sh-i18n"

DESCRIPTION
***********

これは、全くもってエンドユーザーが実行するコマンドではありません。この文
書は、磁器風のスクリプトを研究している、および/または新しいスクリプトを
書いている人々を対象としています。

   ’git sh-i18n スクリプトレットは、シェルスクリプト内に実装されたGitの
磁器プログラムによって、(‘.`を使用してsourceコマンドで)実行されるように
設計されています。 これは、 `gettext.sh’ スクリプトを介してアクセス可能
なGNU ‘gettext’ および ‘eval_gettext’ 関数のラッパーを提供し、GNU
gettextのないシステムではこれらが自動的に使われます(pass-through
fallbacks)。

FUNCTIONS
*********

gettext
     現在、 ‘printf(1)’ のラッパーとして実装されているダミーのフォールス
     ルー関数。今後のバージョンでは、実際のgettext実装に置き換えられる事
     でしょう。

eval_gettext
     現在、 ‘printf(1)’ のラッパーとして実装されているダミーのフォールス
     ルー関数で、その変数達は git-sh-i18n–envsubst(1) ヘルパーによって展
     開されます。今後のバージョンでは、実際のgettext実装に置き換えられる
     事でしょう。

GIT
***

Part of the git(1) suite

Name
****

git-sh-setup — 一般的なGitシェルスクリプトのセットアップコード

Synopsis
********

     . "$(git –exec-path)/git-sh-setup"

DESCRIPTION
***********

これは、エンドユーザーが実行するコマンドではありません。この文書は、磁器
風のスクリプトを研究している、および/または 新しいスクリプトを書いている
人々を対象としています。

   _git sh-setup_ スクリプトレットは、他のシェルスクリプトから( ‘.’ を使
用して)実行(source)され、通常のGitディレクトリと、いくつかのヘルパーシェ
ル関数を指す、いくつかの環境変数を設定するように設計されています。

   実行(source)前に、スクリプトでいくつかの環境変数を設定する必要があり
ます。‘USAGE’ (および存在する場合は ‘LONG_USAGE’ )は、 ‘usage()’ シェル
関数によって与えられるメッセージを定義するために使用されます。スクリプト
が作業ツリーのサブディレクトリから実行できる場合は、 ‘SUBDIRECTORY_OK’ を
設定できます(一部のコマンドは実行できません)。

   スクリプトレットは ‘GIT_DIR’ と ‘GIT_OBJECT_DIRECTORY’ シェル変数を設
定しますが、それらを環境にエクスポートしません。

FUNCTIONS
*********

die
     提供されたエラーメッセージを標準エラーストリームに出力した後に終了
     します。

usage
     使用法メッセージで die します。

set_reflog_action
     すでに設定されていない限り、 ‘GIT_REFLOG_ACTION’ 環境変数を指定の文
     字列(通常はプログラムの名前)に設定します。スクリプトが、refを更新す
     る ‘git’ コマンドを実行するたびに、この文字列の値を使用してreflogエ
     ントリが作成され、どのコマンドがrefを更新したかの記録が残されます。

git_editor
     特定のファイルに対してユーザーが選択したエディター(GIT_EDITOR また
     は core.editor または VISUAL または EDITOR)を実行しますが、エディタ
     ーが指定されておらず、端末がダムの場合はエラーになります。

is_bare_repository
     ‘true’ または ‘false’ を標準出力ストリームに出力して、リポジトリが
     ベアリポジトリであるかどうか(つまり、関連する作業ツリーがないかどう
     か)を示します。

cd_to_toplevel
     作業ツリーのトップレベルまでchdirを実行します。

require_work_tree
     現在のディレクトリがリポジトリの作業ツリー内にあるかどうかを確認し
     、そうでない場合は停止(die)します。

require_work_tree_exists
     リポジトリに関連付けられている作業ツリーが存在するかどうかを確認し
     、存在しない場合は停止(die)します。多くの場合、cd_to_toplevelを呼び
     出す前に実行されますが、作業ツリーがない場合は実行できません。

require_clean_work_tree <action> [<hint>]
     リポジトリに関連付けられている作業ツリーとインデックスに、追跡され
     たファイルへのコミットされていない変更がないことを確認します。それ
     以外の場合は、 ‘Cannot <action>: <reason>. <hint>’ の形式のエラーメ
     ッセージを出力し、dieします。 例:

          require_clean_work_tree rebase "Please commit or stash them."

get_author_ident_from_commit
     特定のコミットの GIT_AUTHOR_NAME と GIT_AUTHOR_EMAIL と
     GIT_AUTHOR_DATE 変数を設定するためにevalで使用するコードを出力しま
     す。

create_virtual_base
     最初のファイルを変更して、2番目のファイルと共通の行だけが残るように
     します。共通の資料が不十分な場合、最初のファイルは空のままになりま
     す。 結果は、3方向マージの仮想ベース入力として適しています。

GIT
***

Part of the git(1) suite

Name
****

git-shell — GitのみのSSHアクセス用の制限付きログインシェル

Synopsis
********

     chsh -s $(command -v git-shell) <user>
     git clone <user>@localhost:/path/to/repo.git
     ssh <user>@localhost

DESCRIPTION
***********

これは、制限されたGitアクセスを提供するためのSSHアカウントのログインシェ
ルです。プル/プッシュ機能を実装するサーバー側のGitコマンドと、ユーザーの
ホームディレクトリの ‘git-shell-commands’ という名前のサブディレクトリに
あるカスタムコマンドの実行のみを許可します。

COMMANDS
********

_git shell_ は、 ‘-c’ オプションの後に以下のコマンドを受け入れます:

_git receive-pack <argument>_
_git upload-pack <argument>_
_git upload-archive <argument>_
     対応するサーバー側コマンドを呼び出して、クライアントの「git push」
     または「git fetch」または「git archive –remote」リクエストをサポー
     トします。

_cvs server_
     CVSサーバーを模倣します。 git-cvsserver(1) 参照。

   ‘~/git-shell-commands’ ディレクトリが存在する場合、 _git shell_ は、
ユーザーのホームディレクトリから "‘git-shell-commands/<command>
<arguments>’" を実行することにより他のカスタムコマンドも処理します。

INTERACTIVE USE
***************

デフォルトでは、上記のコマンドは ‘-c’ オプションでのみ実行できます。シェ
ルはインタラクティブではありません。

   ‘~/git-shell-commands’ ディレクトリが存在する場合、 _git shell_ をイ
ンタラクティブに実行することもできます(引数なしで)。 ‘help’ コマンドが
‘git-shell-commands’ ディレクトリにある場合、許可されたアクションの概要
をユーザーに提供するために実行されます。次に、 ‘git> ‘ プロンプトが表示
され、「git-shell-commands」ディレクトリから任意のコマンドを入力すること
ができます。「exit」を使用すれば接続を閉じることができます。

   通常、このモードは、ユーザーがアクセスできるリポジトリの一覧表示、リ
ポジトリの作成、削除、名前変更、またはリポジトリの説明と権限の変更を可能
にする管理インターフェイスとして使用されます。

   ‘no-interactive-login’ コマンドが存在する場合、それが実行され、対話型
シェルが中止(abort)されます。

EXAMPLES
********

インタラクティブログインを無効にするには、代わりにgreeting(挨拶)を表示し
ます:

     $ chsh -s /usr/bin/git-shell
     $ mkdir $HOME/git-shell-commands
     $ cat >$HOME/git-shell-commands/no-interactive-login <<\EOF
     #!/bin/sh
     printf '%s\n' "Hi $USER! You've successfully authenticated, but I do not"
     printf '%s\n' "provide interactive shell access."
     exit 128
     EOF
     $ chmod +x $HOME/git-shell-commands/no-interactive-login

   git-cvsserverアクセスを有効にするには(なお、git-shell-commandsディレ
クトリを作成するとインタラクティブログインが可能になるため、通常、上記の
「no-interactive-login」の例が前提条件として必要です):

     $ cat >$HOME/git-shell-commands/cvs <<\EOF
     if ! test $# = 1 && test "$1" = "server"
     then
             echo >&2 "git-cvsserver only handles \"server\""
             exit 1
     fi
     exec git cvsserver server
     EOF
     $ chmod +x $HOME/git-shell-commands/cvs

SEE ALSO
********

ssh(1), git-daemon(1), contrib/git-shell-commands/README

GIT
***

Part of the git(1) suite

Name
****

git-shortlog — ’git log’ の出力を要約します。

Synopsis
********

     git shortlog [<options>] [<revision range>] [[–] <path>…]
     git log –pretty=short | git shortlog [<options>]

DESCRIPTION
***********

’git log’の出力を、リリースアナウンスに含めるのに適した形式で要約します
。各コミットは、作者とタイトルごとにグループ化されます。

   加えて、「[PATCH]」はコミットの説明から削除されます。

   コマンドラインでリビジョンが渡されず、かつ、標準入力が端末ではないか
または現在のブランチがない場合、「git shortlog」は、現在のリポジトリを参
照せずに、標準入力から読み取られたログの概要を出力します。

OPTIONS
*******

‘-n’
‘--numbered’
     作者のアルファベット順ではなく、作者のコミット数に従って出力を並べ
     替えます。

‘-s’
‘--summary’
     コミットの説明を抑制し、コミット数の要約のみを提供します。

‘-e’
‘--email’
     各作者のメールアドレスを表示します。

‘--format[=<format>]’
     コミットの件名の代わりに、他の情報を使用して各コミットを説明します
     。 ‘<format>’ は、 ‘* [%h] %s’ など 、 ‘git log’ の ‘--format’ オプ
     ションで受け入れられる任意の文字列にすることができます。
     (git-log(1) の「PRETTY FORMATS」セクションを参照してください。)

          pretty-printされた各コミットは、表示される前に再ラップ(rewrapp)されます。

‘--group=<type>’
     グループは ‘<type>’ に基づいてコミットします。 ‘--group’ オプション
     が指定されていない場合、デフォルトは ‘author’ です。 ‘<type>’ は以
     下のいずれかです:

        • ‘author’ : コミットは作成者ごとにグループ化されます

        • ‘committer’ : コミットはコミッターによってグループ化されます(
          ‘-c’ と同じ)

        • ‘trailer:<field>’ : ‘<field>’ は大文字と小文字を区別しないコミ
          ットメッセージトレーラーとして解釈されます
          (git-interpret-trailers(1) 参照)。たとえば、プロジェクトで
          ‘Reviewed-by’ のトレーラーを使用している場合、 ‘git shortlog
          -ns --group=trailer:reviewed-by’ を使用して誰がレビューしてい
          るかを確認できます。

          注意: トレーラーを含まないコミットはカウントされないことに注意
          してください。同様に、複数のトレーラーを使用したコミット(複数
          のサインオフなど)は、複数回カウントされる場合があります(ただし
          、そのコミットの一意のトレーラー値ごとに1回のみです)。

          shortlog は、各トレーラー値を ‘name <email>’ ID としてパースし
          ようとします。成功すると、mailmapが適用され、 ‘--email’ オプシ
          ョンが指定されていない限りemailは省略されます。値をIDとして解
          析できない場合は、その文言通りに取得されます。

     ‘--group’ が複数回指定されている場合、コミットは各値でカウントされ
     ます(ただし、そのコミットの一意の値ごとに1回だけカウントされます)。
     たとえば、 ‘git shortlog --group=author
     --group=trailer:co-authored-by’ は、authorとco-authorの両方をカウン
     トします。

‘-c’
‘--committer’
     ‘--group=committer’ のエイリアスです。

‘-w[<width>[,<indent1>[,<indent2>]]]’
     各行を ‘width’ で折り返すことにより、出力を行折り返します。各エント
     リの最初の行は ‘indent1’ スペースでインデントされ、2行目以降は
     ‘indent2’ スペースでインデントされます。 ‘width’ と ‘indent1’ と
     ‘indent2’ のデフォルトは、それぞれ76と6と9です。

     widthが ‘0’ (ゼロ)の場合、出力の行を折り返すことなくインデントしま
     す。

<revision range>
     指定のリビジョン範囲のコミットのみを表示します。 <revision range> が
     指定されていない場合、デフォルトで ‘HEAD’ (つまり、現在のコミットに
     つながる履歴全体)になります。 ‘origin..HEAD’ は、現在のコミット(つ
     まり、 ‘HEAD’ )から到達可能なすべてのコミットを指定しますが、
     ‘origin’ からは指定しません。 <revision range> のスペルの完全なリス
     トについては、 gitrevisions(7) の「Specifying Ranges」セクションを
     参照してください。

[–] <path>…
     指定されたパスに一致するファイルがどのように作成されたかを説明する
     のに十分なコミットのみを検討してください。

     混乱が生じた場合、パスをオプションまたはリビジョン範囲から分離する
     ために、パスの前に ‘--’ を付ける必要がある場合があります。

Commit Limiting
===============

ここで説明されている特別な表記法を使用してリストする必要があるコミットの
範囲を指定することに加えて、追加のコミット制限が適用される場合があります
。

   より多くのオプションを使用すると、通常、出力がさらに制限されます(たと
えば、‘--since=<date1>`は’<date1>‘より新しいコミットに制限され、
’–grep=<pattern>‘と一緒に使用すると、ログメッセージに’<pattern>‘と一致す
る行があるコミットにさらに制限されます)。

   注意: これらは、‘–reverse‘などのコミット順序およびフォーマットオプシ
ョンの前に適用されることに注意してください。

‘-<number>’
‘-n <number>’
‘--max-count=<number>’
     出力するコミットの数を制限します。

‘--skip=<number>’
     コミット出力の表示を開始する前に、number 個のコミットをスキップしま
     す。

–since=<date>
‘--after=<date>’
     指定の日付よりも新しいコミットを表示します。

‘--until=<date>’
‘--before=<date>’
     指定の日付より古いコミットを表示します。

‘--author=<pattern>’
‘--committer=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致する作者
     (author)/コミッター(committer)ヘッダー行を持つものに制限します。複
     数の ‘--author=<pattern>’ がある場合、作者が指定されたパターンのい
     ずれかに一致するコミットが選択されます(複数の
     ‘--committer=<pattern>’ の場合も同様)。

‘--grep-reflog=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致するreflogエント
     リを持つものに制限します。複数の‘–grep-reflog‘を使用すると、指定さ
     れたパターンのいずれかに一致するreflogメッセージを持つコミットが選
     択されます。‘–walk-reflogs‘が使用されていない限り、このオプションを
     使用するとエラーになります。

‘--grep=<pattern>’
     コミット出力を、指定されたパターン(正規表現)に一致するログメッセー
     ジを持つものに制限します。複数の‘–grep=<pattern>‘を使用すると、指定
     されたパターンのいずれかにメッセージが一致するコミットが選択されま
     す(全てに一致するコミットだけを選択したい場合、’–all-match‘を参照し
     てください)。

     ‘–notes‘が有効な場合、ノートからのメッセージは、ログメッセージの一
     部であるかのようにマッチングされます。

‘--all-match’
     コミット出力を、少なくとも1つに一致するものではなく、指定されたすべ
     ての‘–grep‘に一致するものに制限します。

‘--invert-grep’
     コミット出力を、‘–grep=<pattern>‘で指定されたパターンと一致しないロ
     グメッセージを持つものに制限します。

‘-i’
‘--regexp-ignore-case’
     大文字小文字に関係なく、正規表現の制限パターンに一致します。

‘--basic-regexp’
     制限パターンを基本正規表現として扱います。これがデフォルトです。

‘-E’
‘--extended-regexp’
     制限パターンを、デフォルトの基本正規表現の代わりに拡張正規表現とし
     て扱います。

‘-F’
‘--fixed-strings’
     制限パターンを固定文字列として扱います(パターンを正規表現として解釈
     しないでください)。

‘-P’
‘--perl-regexp’
     制限パターンをPerl互換の正規表現として扱います。

     これらのタイプの正規表現のサポートは、コンパイル時オプションに依存
     します。Gitが当該のサポート付きでコンパイルされていない場合、このオ
     プションを提供すると、Gitが死にます(die)。

‘--remove-empty’
     指定されたパスがツリーから見えなくなったら停止(stop)します。

‘--merges’
     マージコミットのみを印刷します。これは‘–min-parents=2‘とまったく同
     じです。

‘--no-merges’
     複数の親を持つコミットを出力しない。これは‘–max-parents=1‘とまった
     く同じです。

‘--min-parents=<number>’
‘--max-parents=<number>’
‘--no-min-parents’
‘--no-max-parents’
     量の多少に関わらず、とにかく複数の親コミットがあるコミットのみを表
     示します。特に、‘--max-parents=1`は’–no-merges‘と同じであり、
     ‘--min-parents=2`は’–merges‘と同じです。‘--max-parents=0`はすべての
     ルートコミットを提供し、’–min-parents=3‘はすべてのタコ足マージ
     (octopus merges)を示します。

     ‘--no-min-parents`と’–no-max-parents‘は、これらの制限を(制限なしに
     )再度リセットします。同等の形式は、‘--min-parents=0’(すべてのコミッ
     トに0個以上の親があります)および‘–max-parents=-1‘(マイナスの数は上
     限がないことを示します)です。

‘--first-parent’
     マージコミットを確認したら、最初の親コミットのみを探索します。この
     オプションは、特定のトピックブランチの進化を表示するときに、より良
     い概要を提供できます。トピックブランチへのマージは、時々更新される
     アップストリームに調整することだけである傾向があり、このオプション
     を使用すると、そのようなマージによって履歴に取り込まれた個々のコミ
     ットを無視できます。

‘--not’
     次に現れる ‘--not’ までの間、後続のすべてのリビジョン指定子の ‘^’(カ
     レット)接頭辞(またはその欠如)の意味を逆にします。

‘--all’
     ‘refs/’ 内のすべてのrefが HEAD とともに、コマンドラインに <commit>
     としてリストされているかのように見せかけます。

‘--branches[=<pattern>]’
     ‘refs/heads’ 内のすべてのrefがコマンドラインに <commit> としてリス
     トされているかのように見せかけます。 <pattern> が指定されている場合
     、ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限
     します。パターンに "?" または "*" または "[" がない場合、最後に
     "/*" が含まれます。

‘--tags[=<pattern>]’
     ‘refs/tags’ 内のすべてのrefがコマンドラインに <commit> としてリスト
     されているかのように見せかけます。 <pattern> が指定されている場合は
     、指定されたシェルグロブ(shell glob)に一致するタグにタグを制限しま
     す。パターンに "?" または "*" または "[" がない場合、最後に "/*" が
     含まれます。

‘--remotes[=<pattern>]’
     ‘refs/remotes’ 内のすべてのrefがコマンドラインに <commit> としてリ
     ストされているかのように見せかけます。 <pattern> が指定されている場
     合、リモート追跡ブランチを指定されたシェルグロブ(shell glob)に一致
     するものに制限します。パターンに "?" または "*" または "[" がない場
     合、最後に "/*" が含まれます。

‘--glob=<glob-pattern>’
     シェルグロブ <glob-pattern> に一致するすべてのrefがコマンドラインに
     <commit> としてリストされているかのように見せかけます。先頭の
     ‘refs/’ は、欠落している場合は自動的に先頭に追加されます。パターン
     に "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

‘--exclude=<glob-pattern>’
     次の ‘--all’ または ‘--branches’ または ‘--tags’ または ‘--remotes’
     または ‘--glob’ が別の方法で考慮する <glob-pattern> に一致するrefを
     含めないでください。このオプションを繰り返すと、次の ‘--all’ または
     ‘--branches’ または ‘--tags’ または ‘--remotes’ または ‘--glob’ オ
     プションまで除外パターンが蓄積されます(他のオプションまたは引数は、
     蓄積されたパターンをクリアしません)。

     与えられたパターンは、それぞれ ‘--branches’ または ‘--tags’ または
     ‘--remotes’ に適用される場合、 ‘refs/heads’ または ‘refs/tags’ また
     は ‘refs/remotes’ で始まるべきではありません。 ‘--glob’ または
     ‘--all’ に適用する場合は、 ‘refs/’ で始める必要があります。末尾の
     "/*" を意図している場合は、明示的に指定する必要があります。

‘--reflog’
     reflogsで言及されているすべてのオブジェクトがコマンドラインに
     <commit> としてリストされているかのように見せかけます。

‘--alternate-refs’
     代替リポジトリのref先端として言及されているすべてのオブジェクトがコ
     マンドラインにリストされているかのように見せかけます。代替リポジト
     リは、オブジェクトディレクトリが‘objects/info/alternates‘で指定され
     ているリポジトリです。インクルードされたオブジェクトのセットは、
     ‘core.alternateRefsCommand‘などによって変更できます。
     git-config(1)を参照してください。

‘--single-worktree’
     デフォルトでは、作業ツリーが複数ある場合、‘--all`と’-reflog‘と
     ‘–indexed-objects‘では、すべての作業ツリーが検査されます
     (git-worktree(1)を参照)。このオプションは、現在の作業ツリーのみを調
     べるように強制します。

‘--ignore-missing’
     入力に無効なオブジェクト名が含まれている場合、そもそもその不正な入
     力が行われていないかのように見せかけます。

‘--bisect’
     コマンドラインで、bad bisection ref ‘refs/bisect/bad’ がリストされ
     、その後に ‘--not’ と good bisection ref ‘refs/bisect/good-*’ が続
     くかのように見せかけます。

‘--stdin’
     コマンドラインにリストされている <commit> に加えて、標準入力からそ
     れらを読み取ります。 ‘--’ 区切り文字が表示された場合は、コミットの
     読み取りを停止し、パスの読み取りを開始して結果を制限します。

‘--cherry-mark’
     ‘--cherry-pick’（以下を参照）と同様ですが、同等のコミットを省略せず
     に ‘=’ と印し、同等でないコミットを ‘+’ と印します。

‘--cherry-pick’
     コミットの組を対称差(symmetric difference)に制限する場合、「反対側
     」の別のコミットと同じ変更を導入するコミットを省略します。

     たとえば、‘A’ と ‘B’ の2つのブランチがある場合、それらの片側だけで
     すべてのコミットを一覧表示する通常の方法は、 ‘--left-right’ を使用
     することです(‘--left-right’ オプションの説明の以下の例を参照してく
     ださい)。ただし、他のブランチからは(ブランチAと重複しない)厳選され
     たコミットが表示されます(たとえば、「3rd onb」はブランチAからチェリ
     ーピックされる可能性があります)。このオプションを使用すると、そのよ
     うなコミットのペアは出力から除外されます。

‘--left-only’
‘--right-only’
     リストは、対称差のそれぞれの側でのみコミットします。つまり、
     ‘--left-right`で `<’ と印されるのだけか、あるいは‘–left-right‘で
     ‘>‘と印されるものだけです。

     たとえば、‘--cherry-pick --right-only A...B`は、`A`にある、または
     `A`のコミットとパッチと同等のコミットを`B`から省略します。つまり、
     これは`git cherry A B`からの’+‘コミットをリストします。より正確に書
     くと、’–cherry-pick –right-only –no-merges‘により正確なリストを提供
     します。

‘--cherry’
     ‘–right-only –cherry-mark –no-merges‘の同義語です。出力を私たちの側
     のコミットに制限し、フォークされた履歴の反対の側に適用されたものを
     、‘git cherry upstream mybranch‘と同様に‘git log –cherry
     upstream…mybranch‘で印するのに役立ちます。

‘-g’
‘--walk-reflogs’
     コミットの祖先チェーンをたどる代わりに、reflogエントリを最新のもの
     から古いものに移動します。このオプションを使用する場合、除外するコ
     ミットを指定することはできません(つまり、 "^commit" や
     ‘commit1..commit2’ や ‘commit1...commit2’ 表記は使用できません)。

     (明らかな理由で、)‘oneline`と`reference`以外の’–pretty‘形式では、こ
     れにより、出力にreflogから取得された2行の追加情報が含まれます。出力
     のreflog指定子は、‘ref@{Nth}’ (‘Nth’ はreflogの逆時系列インデックス
     (reverse-chronological index))または ‘ref@{timestamp}’ (そのエント
     リのタイムスタンプ付き)として表示されます。表示は下記のいくつかのル
     ールに依存します:

       1. 開始点が ‘ref@{Nth}’ として指定されている場合は、インデックス
          形式を表示します。

       2. 開始点が ‘ref@{now}’ として指定されている場合は、タイムスタン
          プ形式を表示します。

       3. 上記のどちらも使用されていないが、コマンドラインで‘–date‘が指
          定されている場合は、‘–date‘で要求された形式でタイムスタンプを
          表示します。

       4. それ以外の場合は、インデックス形式を表示します。

     ‘--pretty = oneline`では、コミットメッセージの前にこの情報が同じ行
     に付けられます。このオプションを’–reverse‘と組み合わせることはでき
     ません。git-reflog(1)も参照してください。

     ‘–pretty=reference‘では、この情報はまったく表示されません。

‘--merge’
     マージが失敗した後、競合があり、マージするすべてのheadに存在しない
     ファイルに関連(touch)するrefを表示します。

‘--boundary’
     除外された境界コミットを出力します。 境界コミットの前には ‘-‘が付い
     ています。

History Simplification
======================

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があり
ます。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成
ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つは
コミットの選択であり、もう1つはそれを行う方法です。

   以下のオプションは、表示するコミットを選択します:

<paths>
     指定された<パス>を変更するコミットが選択されます。

‘--simplify-by-decoration’
     いくつかのブランチまたはタグによって参照されるコミットが選択されま
     す。

   注意: 意味のある重要な履歴のために、追加のコミットを表示できることに
注意してください。

   以下のオプションは、簡略化の実行方法に影響します。

Default mode
     履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最
     終結果が同じである場合(つまり、同じコンテンツのブランチをマージする
     場合)、いくつかの傍流ブランチ(side branches)を削除するため、最も単
     純です。

‘--show-pulls’
     デフォルトモードからのすべてのコミットを含めますが、最初の親への
     TREESAMEではなく、後の親へのTREESAMEであるマージコミットも含めます
     。このモードは、ブランチに変更を「最初に導入した」マージコミットを
     表示するのに役立ちます。(訳注:TREESAME=pathspecが全く同一であるツリ
     ー)

‘--full-history’
     デフォルトモードと同じですが、一部の履歴を削除しません。

‘--dense’
     選択したコミットのみが表示され、重大で意味のある履歴を持つコミット
     もいくつか表示されます。

‘--sparse’
     簡略化された履歴内のすべてのコミットが表示されます。

‘--simplify-merges’
     このマージに寄与する選択されたコミットがないため、結果の履歴からい
     くつかの不要なマージを削除するための‘–full-history‘への追加オプショ
     ン。

‘--ancestry-path’
     表示するコミットの範囲が指定されている場合(たとえば、
     ‘commit1..commit2’ または "commit2 ^commit1")、 commit1 と commit2
     の間の祖先チェーンに直接存在するコミットのみ、つまり、 commit1 の子
     孫であり、 commit2 の祖先であるコミットを表示します。

   より詳細な説明は以下のとおりです。

   <paths> として ‘foo’ を指定したとします。 ‘foo’ !TREESAME を変更する
コミットを呼び出し、残りをTREESAMEと呼びます。( ‘foo’ のためにフィルタリ
ングされた差分では、それぞれ異なって見えたりたり等しく見えたりします。）

   以下、簡略化設定の違いを説明するために、同じ履歴例を使います。このコ
ミットグラフでは、ファイル ‘foo’ をフィルタリングしていると想定していま
す:

               .-A---M---N---O---P---Q
              /     /   /   /   /   /
             I     B   C   D   E   Y
              \   /   /   /   /   /
               `-------------'   X

   履歴 A—Q の水平線は、各マージの最初の親と見なされます。その各コミット
は以下のとおりです:

   • ‘I’ は最初のコミットであり、ファイル foo が内容 “asdf” で存在し、フ
     ァイル quux は内容 “quux” で存在します。最初のコミットは空のツリー
     と比較されるため、‘I’ は !TREESAME です。

   • ‘A’ では、 foo には “foo” だけが含まれています。

   • ‘B’ には ‘A’ と同じ変更が含まれています。そのマージ ‘M’ は些細なこ
     とであり、したがってすべての親にとって TREESAME です。

   • ‘C’ は ‘foo’ を変更しませんが、そのマージ ‘N’ はそれを “foobar” に
     変更するので、どの親にとっても TREESAME ではありません。

   • ‘D’ は ‘foo’ を “baz” に設定します。そのマージ ‘O’ は、 ‘N’ と ‘D’
     から “foobarbaz” への文字列を結合します。つまり、どの親にとっても
     TREESAME ではありません。

   • ‘E’ は ‘quux’ を “xyzzy” に変更し、そのマージ ‘P’ は文字列を
     “quuxxyzzy” に結合します。 ‘P’ は ‘O’ に対して TREESAME ですが、
     ‘E’ に対してはそうではありません。

   • ‘X’ は、新ファイル ‘side’ を追加し、 ‘Y’ がそれを変更した独立したル
     ートコミットです。 ‘Y’ は ‘X’ へのTREESAMEです。そのマージ ‘Q’ は
     ‘P’ に ‘side’ を追加し、 ‘Q’ は ‘P’ にはTREESAMEですが、‘Y’ に対し
     てはそうではありません。

   ‘rev-list’ は、 ‘--full-history’ および/または、( ‘--parents’ または
‘--children’ を介して)親の書き換えが使用されているかどうかに基づいて、コ
ミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下
の設定が可能です。

Default mode
     コミットは、どの親に対してもTREESAMEでない場合に含まれます(これは変
     更できますが、以下の ‘--sparse’ を参照してください)。コミットがマー
     ジであり、一方の親に対するTREESAMEであった場合は、その親のみをフォ
     ローします。(TREESAMEの親が複数ある場合でも、そのうちの1つだけをフ
     ォローします)。それ以外の場合は、すべての親をフォローします。

     これにより、以下のようになります:

                    .-A---N---O
                   /     /   /
                  I---------D

     TREESAMEの親のみに従うルールが利用可能な場合は、 ‘B’ を検討対象から
     完全に削除したことに注意してください。 ‘C’ は ‘N’ を介して考慮され
     ましたが、しかしそれはTREESAMEです。ルートコミットは空のツリーと比
     較されるため、 ‘I’ は !TREESAME です。

     親子関係は ‘--parents’ でのみ表示されますが、デフォルトモードで選択
     されたコミットには影響しないため、親の行を示しました。

‘--full-history without parent rewriting’
     このモードは、デフォルトとはある一点で異なります。つまり、いずれか
     の親に対してTREESAMEであっても、常にマージのすべての親に従います。
     マージの複数の側にコミットが含まれている場合でも、これはマージ自体
     が含まれていることを意味するものではありません！ 例では以下のように
     なります。

                  I  A  B  N  D  O  P  Q

     ‘M’ は、両方の親にとってTREESAMEであるため、除外されました。 ‘E’ と
     ‘C’ と ‘B’ をすべて巡りましたが、 ‘B’ だけが !TREESAME だったので、
     他は表示されません。

     注意: 親の書き換え(rewrite)がないと、コミット間の親子関係について話
     す(talk)ことは実際には不可能であるため、それらが切断されている
     (disconnected)ことを示していることに注意してください。

‘--full-history with parent rewriting’
     通常のコミットは !TREESAME の場合にのみ含まれます(これは変更できま
     すが、以下の ‘--sparse’ を参照してください)。

     マージは常に含まれます。ただし、親リストは書き直されます。各親に沿
     って、自分自身に含まれていないコミットを削除します。 これにより以下
     のようになります。

                    .-A---M---N---O---P---Q
                   /     /   /   /   /
                  I     B   /   D   /
                   \   /   /   /   /
                    `-------------'

     上記を書き直さずに ‘--full-history’ と比較してください。 ‘E’ は
     TREESAMEであるため削除されましたが、Pの親リストは ‘E’ の親 ‘I’ を含
     むように書き直されていることに注意してください。 ‘C’ と ‘N’ および
     ‘X’ と ‘Y’ と ‘Q’ についても同じことが起こりました。

   上記の設定に加えて、あなたはTREESAMEが包含に影響を与えるかどうかを変
更できます:

‘--dense’
     巡ったコミットは、親にとってTREESAMEでない場合に含まれます。

‘--sparse’
     巡ったすべてのコミットが含まれます。

     ‘--full-history’ がなくても、これによりマージが単純化されることに注
     意してください。親の1つがTREESAMEの場合、その1つだけに従うため、マ
     ージの反対側を巡ることはありません。

‘--simplify-merges’
     最初に、親を書き換えた ‘--full-history’ と同じ方法で履歴グラフを作
     成します(上記を参照)。

     それから、以下のルールに従って、各コミット ‘C’ を最終履歴内の置換
     ‘C'’ に単純化します:

        • ‘C'’ を ‘C’ にセットします。

        • ‘C'’ の各親 ‘P’ をその簡略化された ‘P'’ に置き換えます。その過
          程で、他の親の祖先であるか、ルートである親を削除すると、
          TREESAMEが空のツリーにコミットされ、重複が削除されますが、
          TREESAMEであるすべての親を削除しないように注意してください。

        • この親の書き換え後、 ‘C'’ がルートまたはマージコミット(0または
          >1 の親を持つ)、境界コミット、または !TREESAMEである場合、それ
          は残ります。それ以外の場合は、唯一の親に置き換えられます。

     この効果は、親の書き換えを使用した ‘--full-history’ と比較すること
     で最もよく示されます。例は以下のようになります:

                    .-A---M---N---O
                   /     /       /
                  I     B       D
                   \   /       /
                    `---------'

     注意: ‘--full-history’ に対する ‘N’ と ‘P’ と ‘Q’ の主な違いに注意
     してください:

        • ‘N’ の親リストは、他の親 ‘M’ の祖先であるため、 ‘I’ が削除され
          ました。それでも、 !TREESAME なので ‘N’ が残りました。

        • ‘P’ の親リストも同様に ‘I’ が削除されました。 ‘P’ は、親が1つ
          で TREESAMEであるため、完全に削除されました。

        • ‘Q’ の親リストでは、 ‘Y’ が ‘X’ に簡略化されていました。その後
          、 ‘X’ はTREESAMEルートであったため、削除されました。 ‘Q’ は、
          親が1つで TREESAMEであるため、完全に削除されました。

   利用可能な別の簡略化モードがあります:

‘--ancestry-path’
     表示されるコミットを、指定されたコミット範囲内の “from” コミットと
     “to” コミットの間の祖先チェーンに直接あるコミットに制限します。つま
     り、 “to” コミットの祖先であるコミットと “from” コミットの子孫であ
     るコミットのみを表示します。

     ユースケースの例として、以下のコミット履歴について考えます:

                      D---E-------F
                     /     \       \
                    B---C---G---H---I---J
                   /                     \
                  A-------K---------------L--M

     通常の ‘D..M’ は、 ‘M’ の祖先であるコミットのセットを計算しますが、
     ‘D’ の祖先であるコミットは除外します。 これは、「 ‘M’ には ‘D’ には
     存在しなかったものがある」という意味で、 ‘D’ 以降の ‘M`に至るまでの
     歴史に何が起こったのかを知るのに役立ちます。この例の結果は、 `A’ と
     ‘B’ (そしてもちろん ‘D’ 自体)を除くすべてのコミットになります。

     ただし、 ‘M’ のコミットが ‘D’ で入ったバグで汚染されており、修正が
     必要な場合は、実際には ‘D’ の子孫である ‘D..M’ のサブセットのみを表
     示する必要があります。つまり、 ‘C’ と ‘K’ を除外します。これはまさ
     に ‘--ancestry-path’ オプションが行うことです。これを ‘D..M’ 範囲に
     適用すると、以下のようになります:

                          E-------F
                           \       \
                            G---H---I---J
                                         \
                                          L--M

   別のオプション ‘--show-pulls’ について説明する前に、新しいサンプル履
歴を作成する必要があります。

   簡略化された履歴を見るときにユーザーが直面する一般的な問題は、ファイ
ルを変更したことがわかっているコミットが、ファイルの簡略化された履歴に表
示されないことです。そこで、新しい例を示し、その場合に ‘--full-history’
や ‘--simplify-merges’ などのオプションがどのように機能するかを示しまし
ょう。

               .-A---M-----C--N---O---P
              /     / \  \  \/   /   /
             I     B   \  R-'`-Z'   /
              \   /     \/         /
               \ /      /\        /
                `---X--'  `---Y--'

   この例では、 ‘I’ が ‘file.txt’ を作成し、それが ‘A’ と‘B‘ と ‘X’ にて
さまざまな方法で変更されたとします。ひとり親のコミット ‘C’ と ‘Z’ と ‘Y’
は ‘file.txt’ を変更していません。マージコミット ‘M’ は、マージの競合を
解決して、 ‘A’ と ‘B’ の両方の変更を含めることによって作成されたため、ど
ちらにもTREESAMEではありません。ただし、マージコミット ‘R’ は、 ‘M’ の
‘file.txt`の内容を無視し、 `X’ の ‘file.txt’ の内容のみを取得することに
よって作成されました。 したがって、 ‘R’ は ‘X’ へのTREESAMEですが、 ‘M’
はそうではありません。最後に、 ‘N’ を作成するための自然なマージ解決は、
‘R’ で ‘file.txt’ の内容を取得することです。したがって、 ‘N’ は ‘C’ では
なく ‘R’ へのTREESAMEです。マージコミット ‘O’ と ‘P’ は、最初の親には
TREESAMEですが、2番目の親である ‘Z’ と ‘Y’ にはついてはそうではありませ
ん。

   デフォルトモードを使用する場合、 ‘N’ と ‘R’ は両方ともTREESAMEの親を
持っているため、これらのエッジはウォークされ、他のエッジは無視されます。
結果の履歴グラフは以下のとおりです:

             I---X

   ‘--full-history’ を使用する場合、Gitはすべてのエッジを巡ります。これ
により、コミット ‘A’ と ‘B’ と マージ ‘M’ が検出されますが、マージコミッ
ト ‘O’ と ‘P’ も明らかになります。 親を書き換えると、結果のグラフは以下
のようになります:

               .-A---M--------N---O---P
              /     / \  \  \/   /   /
             I     B   \  R-'`--'   /
              \   /     \/         /
               \ /      /\        /
                `---X--'  `------'

   ここで、マージコミット ‘O’ と ‘P’ は、実際には ‘file.txt’ への変更を
提供しなかったため、余分なノイズを提供します。古いバージョンの
‘file.txt’ に基づいたトピックのみをマージしました。これは、多くの寄稿者
が並行して作業し、トピックブランチを単一のトランクに沿ってマージするワー
クフローを使用するリポジトリの一般的な問題です。開発に関係のないマージが
‘--full-history’ の結果に表示されます。

   ‘--simplify-merges’ オプションを使用すると、コミット ‘O’ と ‘P’ が結
果から消えます。 これは、 ‘O’ と ‘P’ の書き直された2番目の親が、最初の親
から到達可能であるためです。これらのエッジが削除されると、コミットは、親
にとってTREESAMEである単一の親のコミットのように見えます。これはコミット
‘N’ にも発生し、以下のような履歴ビューが表示されます:

               .-A---M--.
              /     /    \
             I     B      R
              \   /      /
               \ /      /
                `---X--'

   このビューでは、 ‘A’ と ‘B’ と ‘X’ からの重要なひとり親の変更がすべて
表示されます。また、慎重に解決されたマージ ‘M’ とそれほど慎重に解決され
ていないマージ ‘R’ も表示されます。これは通常、コミット ‘A’ と ‘B’ がデ
フォルトのビューの履歴から「消えた」理由を判断するのに十分な情報です。た
だし、このアプローチにはいくつかの問題があります。

   最初の問題はパフォーマンスです。以前のオプションとは異なり、
‘--simplify-merges’ オプションでは、単一の結果を返す前にコミット履歴全体
をウォークする必要があります。これにより、非常に大規模なリポジトリでこの
オプションを使用するのが難しくなる可能性があります。

   2番目の問題は監査の1つです。多くの寄稿者が同じリポジトリで作業してい
る場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。
上記の問題のあるマージ ‘R’ は、重要なブランチにマージするために使用され
たマージコミットではない可能性があります。 代わりに、マージ ‘N’ を使用し
て ‘R’ と ‘X’ を重要なブランチにマージしました。このコミットには、変更
‘X’ がコミットメッセージの ‘A’ と ‘B’ からの変更を上書きするようになった
理由に関する情報が含まれている可能性があります。

‘--show-pulls’
     デフォルトの履歴に表示されるコミットに加えて、最初の親には
     TREESAMEではなく、後の親にはTREESAMEである各マージコミットを表示し
     ます。

     マージコミットが ‘--show-pulls’ に含まれている場合、マージは別のブ
     ランチから変更を「プル」したかのように扱われます。この例で
     ‘--show-pulls’ を使用すると(他のオプションは使用しない場合、)結果の
     グラフは行かのようになります:

                  I---X---R---N

     ここで、コミット ‘X’ と ‘R’ をそれぞれベースブランチにプルしたため
     、マージコミット ‘R’ と ‘N’ が含まれています。これらのマージは、コ
     ミット ‘A’ と ‘B’ がデフォルトの履歴に表示されない理由です。

     ‘--show-pulls’ が ‘--simplify-merges’ とペアになっている場合、グラ
     フには必要なすべての情報が含まれます:

                    .-A---M--.   N
                   /     /    \ /
                  I     B      R
                   \   /      /
                    \ /      /
                     `---X--'

     ‘M’ は ‘R’ から到達可能であるため、 ‘N’ から ‘M’ へのエッジが単純化
     されていることに注意してください。ただし、 ‘N’ は、変更 ‘R’ をメイ
     ンブランチに「プル」したため、重要なコミットとして履歴に表示されま
     す。

   ‘--simplify-by-decoration’ オプションを使用すると、タグで参照されてい
ないコミットを省略して、履歴のトポロジの全体像のみを表示できます。コミッ
トは、(1)タグによって参照されている場合、または (2)コマンドラインで指定
されたパスの内容を変更した場合に、!TREESAMEとしてマークされます(つまり、
上記の履歴簡略化ルールの後に保持されます)。他のすべてのコミットは
TREESAMEとしてマークされます(簡略化される可能性があります)。

MAPPING AUTHORS
***************

See gitmailmap(5).

   注意: (標準入力でログの内容を処理するため) ‘git shortlog’ がリポジト
リの外部で実行される場合、現在のディレクトリで ‘.mailmap’ ファイルが検索
されることに注意してください。

GIT
***

Part of the git(1) suite

Name
****

git-show-branch — ブランチとそのコミットを表示します

Synopsis
********

     git show-branch [-a|–all] [-r|–remotes] [–topo-order | –date-order]
                     [–current] [–color[=<when>] | –no-color] [–sparse]
                     [–more=<n> | –list | –independent | –merge-base]
                     [–no-name | –sha1-name] [–topics]
                     [(<rev> | <glob>)…]
     git show-branch (-g|–reflog)[=<n>[,<base>]] [–list] [<ref>]

DESCRIPTION
***********

<rev> または <glob> (または、 refs/heads および/または refs/tags の下の
すべてのref)で名前が付けられたコミットから始まるコミットの祖先グラフを半
視覚的に表示します。

   一度に29を超えるブランチとコミットを表示することはできません。

   コマンドラインで <rev> または <glob> が指定されていない場合は、
‘showbranch.default’ の複数値(multi-valued)の構成アイテムを使用します。

OPTIONS
*******

<rev>
     通常はブランチヘッドまたはタグに名前を付ける任意の拡張SHA-1式
     (gitrevisions(7) 参照)。

<glob>
     refs/ の下のブランチ名またはタグ名に一致するグロブパターン。 たとえ
     ば、 refs/heads/topic の下に多くのトピックブランチがある場合、
     ‘topic/*’ を指定するとそれらすべてが表示されます。

‘-r’
‘--remotes’
     リモート追跡ブランチを表示します。

‘-a’
‘--all’
     リモート追跡ブランチとローカルブランチの両方を表示します。

‘--current’
     このオプションを使用すると、コマンドラインに指定されていない場合に
     表示されるrevのリストに現在のブランチが含まれます。

‘--topo-order’
     デフォルトでは、ブランチとそのコミットは新しい順に表示されます。こ
     のオプションを使用すると、トポロジカル順に表示されます(つまり、子孫
     のコミットは親の前に表示されます)。

‘--date-order’
     このオプションは、すべての子の前に親が来ないという意味で
     ‘--topo-order’ に似ていますが、それ以外の場合、コミットはコミット日
     に従って順序付けられます。

‘--sparse’
     デフォルトでは、出力には、表示されている1つの先端からのみ到達可能な
     マージが省略されています。このオプションにより、それらが表示されま
     す。

‘--more=<n>’
     通常、コマンドは、すべてのブランチの共通の祖先であるコミットを表示
     すると出力を停止します。このフラグは、それを超えて共通のコミットを
     <n> 回表示するようコマンドに指示します。 <n>が負の場合、コミットの
     祖先ツリーを表示せずに、指定された<reference>のみを表示します。

‘--list’
     ‘--more=-1’ と同義です。

‘--merge-base’
     コミットリストを表示する代わりに、指定されたコミットの可能なマージ
     ベースを決定します。すべてのマージベースは、指定されたすべてのコミ
     ットに含まれます。 これは、 git-merge-base(1) が3つ以上のコミットの
     場合を処理する方法とは異なります。

‘--independent’
     与えられた <reference> のうち、他の <reference> から到達できないも
     ののみを表示します。

‘--no-name’
     各コミットの名前付け文字列(naming strings)を表示しません。

‘--sha1-name’
     ヘッドからコミットに到達するためのパスを使用してコミットに名前を付
     ける代わりに(たとえば、「master」の祖父母を意味する「master~2」)、
     オブジェクト名の一意のプレフィックスを使用してコミットに名前を付け
     ます。

‘--topics’
     指定された最初のブランチにないコミットのみを表示します。これは、す
     でに開発のメインラインにあるコミットを非表示にすることで、トピック
     ブランチを追跡するのに役立ちます。 ‘git show-branch --topics master
     topic1 topic2’ を指定すると、 ‘git rev-list {caret}master topic1
     topic2’ で指定されたリビジョンが表示されます。

‘-g’
‘--reflog[=<n>[,<base>]] [<ref>]’
     指定された参照の最新の参照ログエントリを<n>個表示します。<base>が指
     定されている場合、<n>エントリはそのエントリから戻ります。 <base>は
     、カウントまたは日付として指定できます。 明示的な<ref>パラメータが
     指定されていない場合、デフォルトで現在のブランチ(またはデタッチされ
     ている場合は ‘HEAD’ )になります。

‘--color[=<when>]’
     所属するブランチに対応する各コミットのステータス記号(‘*’ ‘！’ ‘+’
     ‘-’ )に色を付けます。値は always (デフォルト) または never または
     auto である必要があります。

‘--no-color’
     構成ファイルでデフォルトのカラー出力が指定されている場合でも、カラ
     ー出力をオフにします。 ‘--color=never’ と同じです。

   ‘--more@ と `-list’ と ‘-independent’ と ‘--merge-base’ オプションは
相互に排他的であることに注意してください。

OUTPUT
******

N <references> が与えられた場合、最初のN行はコミットメッセージからの各
1行説明です。 $GIT_DIR/HEAD が指すブランチヘッドには、アスタリスクの ‘*’
文字が接頭辞として付けられ、他のヘッドには、 ‘!’ 文字が接頭辞として付け
られます。

   これらのN行に続いて、コミットごとに1行のログが表示され、N桁インデント
されます。 コミットがI番目のブランチにある場合、I番目のインデント文字は
‘+’ 記号を示します。それ以外の場合は、スペースが表示されます。 マージコ
ミットは ‘-’ 記号で示されます。各コミットは、そのコミットに名前を付ける
ための拡張SHA-1として使用できる短い名前が表示されます。

   以下の例は、「master」と「fixes」と「mhf」の3つのブランチを示していま
す:

     $ git show-branch master fixes mhf
     * [master] Add 'git show-branch'.
      ! [fixes] Introduce "reset type" flag to "git reset"
       ! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
     ---
       + [mhf] Allow "+remote:local" refspec to cause --force when fetching.
       + [mhf~1] Use git-octopus when pulling more than one heads.
      +  [fixes] Introduce "reset type" flag to "git reset"
       + [mhf~2] "git fetch --force".
       + [mhf~3] Use .git/remote/origin, not .git/branches/origin.
       + [mhf~4] Make "git pull" and "git fetch" default to origin
       + [mhf~5] Infamous 'octopus merge'
       + [mhf~6] Retire git-parse-remote.
       + [mhf~7] Multi-head fetch.
       + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
     *++ [master] Add 'git show-branch'.

   これらの3つのブランチはすべて、共通のコミット[master]から分岐し、その
コミットメッセージは「Add ’git show-branch’」です。「fixes」ブランチは、
「gitreset」に「Resettype」フラグを導入するコミットを1つ追加します。「
mhf」ブランチは、他の多くのコミットを追加します。 現在のブランチは「
master」です。

EXAMPLES
********

プライマリブランチを ‘refs/heads’ のすぐ下に置き、トピックブランチをその
サブディレクトリに保持する場合は、構成ファイルに以下の情報を含めると役立
つ場合があります:

     [showbranch]
             default = --topo-order
             default = heads/*

   これにより、追加のパラメータがない ‘git show-branch’ は、プライマリブ
ランチのみを表示します。さらに、トピックブランチにいる場合は、それも表示
されます。

     $ git show-branch --reflog="10,1 hour ago" --list master

   これは、1時間前の時点で先端から戻った10個のreflogエントリを示していま
す。 ‘--list’ がない場合、出力には、これらのヒントがトポロジ的に相互にど
のように関連しているかも示されます。

GIT
***

Part of the git(1) suite

Name
****

git-show-index — パックされたアーカイブインデックスを表示する

Synopsis
********

     git show-index [–object-format=<hash-algorithm>]

DESCRIPTION
***********

標準入力から、(git-pack-objects(1) または git-index-pack(1) で作成の
)Gitパックファイルの、 ‘.idx’ ファイルを読み取り、その内容をダンプします
。 出力は、行ごとに1つのオブジェクトで構成され、各行には2つまたは3つのス
ペースで区切られた複数列が含まれます:

   • 最初の列は、対応するパックファイル内のオブジェクトのバイト単位のオ
     フセットです。

   • 2番目の列はオブジェクトのオブジェクトIDです

   • インデックスバージョンが2以上の場合、3番目の列にはオブジェクトデー
     タのCRC32が含まれます

   オブジェクトは、インデックスファイルで見つかった順序で出力されます。
(正しく作成されたファイルであれば、)インデックスファイルはオブジェクト
IDソートされていなければなりません。

   注意: あなたは git-verify-pack(1) を呼び出すと、パックファイルに関す
る情報をよりたくさん取得できます。けれども、このコマンド(show-index)はイ
ンデックスファイル自体のみを考慮するため、より高速で柔軟性があります。

OPTIONS
*******

‘--object-format=<hash-algorithm>’
     インデックスファイルのためのオブジェクト形式(ハッシュアルゴリズム
     )を指定します。有効な値は _sha1_ および (有効な場合) _sha256_ です
     。 デフォルトは、現在のリポジトリのアルゴリズム
     (‘extensions.objectFormat’ で設定)、または値が設定されていないかリ
     ポジトリの外部にある場合は _sha1_ です。

     このオプションは実験的なものです！ SHA-256のサポートは実験的なもの
     であり、まだ初期段階です。 SHA-256リポジトリは、通常、「通常の」
     SHA-1リポジトリと作業を共有できません。 たとえば、SHA-256リポジトリ
     に関連するGit内部ファイル形式は、下位互換性のない方法で変更される可
     能性があると想定する必要があります。テスト目的でのみ
     ‘--object-format=sha256’ を使用してください。

GIT
***

Part of the git(1) suite

Name
****

git-show-ref — ローカルリポジトリ内の参照を一覧表示します

Synopsis
********

     git show-ref [-q|–quiet] [–verify] [–head] [-d|–dereference]
                  [-s|–hash[=<n>]] [–abbrev[=<n>]] [–tags]
                  [–heads] [–] [<pattern>…]
     git show-ref –exclude-existing[=<pattern>]

DESCRIPTION
***********

ローカルリポジトリで使用可能な参照を、関連するコミットIDとともに表示しま
す。結果はパターンを使用してフィルタリングでき、タグはオブジェクトIDに逆
参照できます。さらに、特定のrefが存在するかどうかをテストするために使用
できます。

   デフォルトでは、タグとヘッドとリモートrefを表示します。

   ‘--exclude-existing’ 形式は、逆を行うフィルターです。 stdinから1行に
1つのrefを読み取り、ローカルリポジトリに存在しないものを表示します。

   ‘.git’ ディレクトリの下のファイルに直接アクセスするために、このユーテ
ィリティの使用をお勧めします。

OPTIONS
*******

‘--head’
     通常は検索除外される場合でも、HEAD参照を表示します。

‘--heads’
‘--tags’
     それぞれ「refs/heads」と「refs/tags」に制限します。これらのオプショ
     ンは相互に排他的ではありません。 両方を指定すると、「refs/heads」と
     「refs/tags」に保存されている参照が表示されます。

‘-d’
‘--dereference’
     タグをオブジェクトIDにも逆参照します。 ‘{caret}{}’ が追加されて表示
     されます。

‘-s’
‘--hash[=<n>]’
     参照名ではなく、SHA-1ハッシュのみを表示します。 ‘--dereference’ と
     組み合わせると、逆参照されたタグがSHA-1の後に依然として表示されます
     。

‘--verify’
     正確な参照パスを要求することにより、より厳密な参照チェックを有効に
     します。エラーコード1を返す以外に、 ‘--quiet’ が指定されていない場
     合はエラーメッセージも出力します。

‘--abbrev[=<n>]’
     オブジェクト名を省略します。 ‘--hash’ を使用する場合は ‘--hash
     --abbrev’ と言う必要はなく、 ‘--hash=n’ で十分です。

‘-q’
‘--quiet’
     結果をstdoutに出力しないでください。 ‘--verify’ と組み合わせると、
     参照が存在するかどうかをサイレントにチェックするために使用できます
     。

‘--exclude-existing[=<pattern>]’
     "‘^(?:<anything>\s)?<refname>(?:\^{})?$’" 形式でstdinからrefを読み
     取り、そのそれぞれに対して以下のアクションを実行するフィルターとし
     て _git show-ref_ を使います: (1) 行末の ‘{caret}{}’ を削除します
     (2) パターンが指定されていて、refnameとヘッドが一致(head-match)しな
     い場合は無視 (3) refnameが整形式(well-formed)のrefnameでない場合は
     警告し、スキップします (4) refnameがローカルリポジトリに存在する
     refである場合は無視 (5) それ以外の場合は、行を出力します。

<pattern>…
     1つ以上のパターンに一致する参照を表示します。パターンはフルネームの
     末尾から一致し、完全な部品のみが一致します。 「master」は「
     refs/heads/master」や「refs/remotes/origin/master」や「
     refs/tags/jedi/master」と一致しますが、「refs/heads/mymaster」とか
     「refs/remotes/master/jedi」とは一致しません 。

OUTPUT
******

出力形式: <SHA-1 ID><空白><参照名>

     $ git show-ref --head --dereference
     832e76a9899f560a90ffd62ae2ce83bbeff58f54 HEAD
     832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/master
     832e76a9899f560a90ffd62ae2ce83bbeff58f54 refs/heads/origin
     3521017556c5de4159da4615a39fa4d5d2c279b5 refs/tags/v0.99.9c
     6ddc0964034342519a87fe013781abf31c6db6ad refs/tags/v0.99.9c^{}
     055e4ae3ae6eb344cbabf2a5256a49ea66040131 refs/tags/v1.0rc4
     423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
     ...

   ( ‘--dereference’ ではなく) ‘--hash’ を使用する場合の出力形式: <SHA-1
ID>

     $ git show-ref --heads --hash
     2e3ba0114a1f52b47df29743d6915d056be13278
     185008ae97960c8d551adcd9e23565194651b5d1
     03adf42c988195b50e1a1935ba5fcbc39b2b029b
     ...

EXAMPLES
********

タグやヘッドなど、「master」と呼ばれるすべての参照を表示するには、参照の
名前付け階層の深さに関係なく、以下を使用します:

             git show-ref master

   これには、「refs/heads/master」だけでなく、「
refs/remote/other-repo/master」も表示されます(そのような参照が存在する場
合)。

   ‘--verify’ フラグを使用する場合、コマンドには正確なパスが必要です:

             git show-ref --verify refs/heads/master

   これは「master」と呼ばれる正確なブランチにのみ一致します。

   一致するものがない場合、「git show-ref」はエラーコード1を返し、検証の
場合はエラーメッセージを表示します。

   スクリプトの場合は、 ‘--quiet’ フラグを使用して静かにするように要求で
きます。これにより、以下のようにできます

             git show-ref --quiet --verify -- "refs/heads/$headname" ||
                     echo "$headname is not a valid branch"

   これは、特定のブランチが存在するかどうかを確認します(実際には結果を表
示したくないので、あいまいな部分一致で問題が発生しないように、完全な
refnameを使用します)。

   タグのみ、または適切なブランチヘッドのみを表示するには、それぞれ「
–tags」かつ/または「–heads」を使用します(両方を使用すると、タグとヘッド
が表示されますが、 refs/ サブディレクトリの下にある他のランダムな参照は
表示されません)。

   タグオブジェクトの自動逆参照を行うには、「-d」または「–dereference」
フラグを使用して、以下のことができるようにします

             git show-ref --tags --dereference

   これは、すべてのタグのリストを、それらが逆参照するものと一緒に取得し
ます。

FILES
*****

‘.git/refs/*’, ‘.git/packed-refs’

SEE ALSO
********

git-for-each-ref(1), git-ls-remote(1), git-update-ref(1),
gitrepository-layout(5)

GIT
***

Part of the git(1) suite

Name
****

git-show — さまざまなタイプのオブジェクトを表示

Synopsis
********

     git show [<options>] [<object>…]

DESCRIPTION
***********

1つまたはそれ以上のオブジェクト(ブロブ・ツリー・タグ・コミット)を表示し
ます。

   コミットの場合、ログメッセージとテキストの差分が表示されます。 また、
_git diff-tree –cc_ によって生成された特別な形式でマージコミットを示しま
す。

   タグの場合、タグメッセージと参照オブジェクトが表示されます。

   ツリーの場合は、名前が表示されます(‘--name-only’ オプション付きの
_git ls-tree_ 相当)。

   プレーンブロブの場合は、プレーンコンテンツが表示されます。

   このコマンドは、「git diff-tree」コマンドに適用可能なオプションを使用
して、コミットによって導入された変更の表示方法を制御します。

   このマニュアルページでは、最も頻繁に使用されるオプションについてのみ
説明します。

OPTIONS
*******

<object>…
     表示するオブジェクトの名前(デフォルトは「HEAD」)。オブジェクト名を
     綴る方法のより完全なリストについては、 gitrevisions(7) の「
     SPECIFYING REVISIONS」セクションを参照してください。

‘--pretty[=<format>]’
‘--format=<format>’
     コミットログの内容を指定された形式できれいに印刷(pretty-print)しま
     す。 <format> は oneline、short、medium、full、fuller、reference、
     email、raw、format:<string>、tformat:<string> のいずれかになります
     。 <format> が上記のいずれでもなく、「%プレースホルダー」が含まれて
     いる場合、 ‘--pretty=tformat:<format>’ が指定されたかのように動作し
     ます。

     各フォーマットの詳細については、「PRETTY FORMATS」セクションを参照
     してください。 ‘=<format>’ の部分を省略すると、デフォルトで medium
     になります。

     注意: リポジトリー構成でデフォルトのpretty formatを指定できます
     (git-config(1) 参照)。

‘--abbrev-commit’
     40バイトの16進コミットオブジェクト名全体を表示する代わりに、オブジ
     ェクトに一意の名前を付けるプレフィックスを表示します。
     "–abbrev=<n>" (表示されている場合はdiff出力も変更します)オプション
     を使用して、プレフィックスの最小長を指定できます。

     これにより、80桁幅の端末を使用している人にとって "–pretty=oneline"
     がずっと読みやすくなるはずです。

‘--no-abbrev-commit’
     完全な40バイトの16進コミットオブジェクト名を表示します。 これにより
     、明示的または "–oneline" などの他のオプションによって暗黙的に示さ
     れる ‘--abbrev-commit’ が無効になります。また、 ‘log.abbrevCommit’
     変数をオーバーライドします。

‘--oneline’
     これは、 "–pretty=oneline –abbrev-commit" を一緒に使用するための省
     略形です。

‘--encoding=<encoding>’
     コミットオブジェクトは、ログメッセージに使用される文字エンコードを
     エンコードヘッダーに記録します。このオプションを使用して、ユーザー
     が好むエンコーディングでコミットログメッセージを再コーディングする
     ようにコマンドに指示できます。配管以外のコマンドの場合、これはデフ
     ォルトでUTF-8になります。オブジェクトが ‘X’ でエンコードされている
     と主張し、 ‘X’ で出力している場合、オブジェクトをそのまま出力するこ
     とに注意してください。これは、元のコミットの無効なシーケンスが出力
     にコピーされる可能性があることを意味します。同様に、 iconv(3) コミ
     ットの変換に失敗した場合、警告とともに元のオブジェクトをそのまま出
     力します。

‘--expand-tabs=<n>’
‘--expand-tabs’
‘--no-expand-tabs’
     出力に表示する前に、ログメッセージでタブ展開を実行します(タブ幅を
     <n> とみなして <n> 境界に揃うように空白で調整する)。
     ‘--expand-tabs’ は ‘--expand-tabs=8’ の省略形であり、
     ‘--no-expand-tabs’ は ‘--expand-tabs=0’ の省略形です。タブの展開を
     無効にします。

     デフォルトでは、タブはログメッセージを4つのスペースでインデントする
     きれいな形式(pretty formats)で展開されます(つまり、medium (これがデ
     フォルト) と full と fuller)。

‘--notes[=<ref>]’
     コミットログメッセージを表示するときに、コミットに注釈を付ける
     notes(git-notes(1) 参照)を表示します。これは、コマンドラインに
     ‘--pretty’ 、‘--format’ または ‘--oneline’ オプションが指定されてい
     ない場合の、 ‘git log’ と ‘git show’ と ‘ git whatchanged‘ コマンド
     のデフォルトです。

     デフォルトでは、表示されるnotesは、 ‘core.notesRef’ および
     ‘notes.displayRef’ 変数(または対応する環境変数オーバーライド)にリス
     トされているnote refからのものです。詳細については git-config(1) を
     参照してください。

     オプションの <ref> 引数を使用して、refを使用して表示するnotesを検索
     します。 refは、 ‘refs/notes/’ で始まる完全なrefnameを指定できます
     。 ‘notes/’ で始まるか、 ‘refs/’ で始まるか、それ以外で始まる場合、
     ‘refs/notes/’ が接頭辞として付けられ、refのフルネームを形成します。

     複数の –notes オプションを組み合わせて、表示するノートを制御できま
     す。 例: "–notes=foo" は "refs/notes/foo" からのnotesのみを表示しま
     す。 "–notes=foo –notes" は、 "refs/notes/foo" とデフォルトのnotes
     ref(s) の両方のnotesを表示します。

‘--no-notes’
     notesを表示しないでください。 これは、notesが表示されるnotes refの
     リストをリセットすることにより、上記の ‘--notes’ オプションを無効に
     します。 オプションは、コマンドラインで指定された順序で解析されます
     。 "–notes –notes=foo –no-notes –notes=bar" は、 "refs/notes/bar" か
     らのnotesのみを表示します。

‘--show-notes[=<ref>]’
‘--[no-]standard-notes’
     これらのオプションは非推奨です。 代わりに、上記の –notes/–no-notes
     オプションを使用してください。

‘--show-signature’
     署名を ‘gpg --verify’ に渡して、署名されたコミットオブジェクトの有
     効性を確認し、出力を表示します。

PRETTY FORMATS
**************

コミットがマージであり、 pretty-format が ‘oneline’ または ‘email’ また
は ‘raw’ で無い場合、 ‘Author:’ 行の前に追加の行が挿入されます。この行は
"Merge: " で始まり、先祖のコミットのハッシュがスペースで区切られて出力さ
れます。履歴の表示を制限している場合、たとえば、特定のディレクトリまたは
ファイルに関連する変更のみに関心がある場合、リストされたコミットは必ずし
も *直接* の親コミットのリストではない可能性があることに注意してください
。

   いくつかの組み込みフォーマットがあります。そして以下で説明するように
、 pretty.<name> 構成オプション(config option)を別のフォーマット名または
‘format:’ 文字列に設定することで、追加のフォーマットを定義できます
(git-config(1) 参照)。組み込みフォーマットの詳細は以下のとおりです:

   • ‘oneline’

          <hash> <title line>

     これは、可能な限りコンパクトになるように設計されています。

   • ‘short’

          commit <hash>
          Author: <author>

          <title line>

   • ‘medium’

          commit <hash>
          Author: <author>
          Date:   <author date>

          <title line>

          <full commit message>

   • ‘full’

          commit <hash>
          Author: <author>
          Commit: <committer>

          <title line>

          <full commit message>

   • ‘fuller’

          commit <hash>
          Author:     <author>
          AuthorDate: <author date>
          Commit:     <committer>
          CommitDate: <committer date>

          <title line>

          <full commit message>

   • ‘reference’

          <abbrev hash> (<title line>, <short author date>)

     この形式は、コミットメッセージ内の別のコミットを参照するために使用
     され、 ‘--pretty='format:%C(auto)%h (%s, %ad)'’ と同じです。 デフォ
     ルトでは、別の ‘--date’ オプションが明示的に指定されていない限り、
     日付は ‘--date=short’ でフォーマットされます。formatプレースホルダ
     ーを使用する他の ‘format:’ と同様に、その出力は、 ‘--decorate’ や
     ‘--walk-reflogs’ などの他のオプションの影響を受けません。

   • ‘email’

          From <hash> <date>
          From: <author>
          Date: <author date>
          Subject: [PATCH] <title line>

          <full commit message>

   • ‘mboxrd’

     ‘email’ と同様ですが、コミットメッセージの "From " で始まる行(前に
     0個以上の ‘>’ が付いている)は ‘>’ でクォートされているため、新しい
     コミットの開始と混同されることはありません。

   • ‘raw’

     ‘raw’ 形式は、コミットオブジェクトに格納されているとおりにコミット
     全体を正確に表示します。とりわけ ‘--abbrev’ または ‘--no-abbrev’ の
     どちらが使用されているかに関係なく、ハッシュは完全に表示され、「親
     」(parents)情報は、移植や履歴の単純化を考慮せずに、真の親のコミット
     を示します。この形式は、コミットの表示方法に影響しますが、いわゆる
     ‘git log --raw’ の差分の表示方法ではありません。生のdiff形式で完全
     なオブジェクト名を取得するには、 ‘--no-abbrev’ を使用します。

   • ‘format:<string>’

     ‘format:<string>’ 形式を使用すると、表示する情報を指定できます。注
     意: これはprintf書式に少し似ていますが、 ‘\n’ の代わりに ‘%n’ を使
     用して改行を取得するという例外に注意してください。

     例: ‘format:"The author of %h was %an, %ar%nThe title was
     >>%s<<%n"’ は以下のように表示されます:

          The author of fe6e0ee was Junio C Hamano, 23 hours ago
          The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

     さて、以下がプレースホルダー達です:

        • 単一のリテラル文字に展開されるプレースホルダー:

          ‘%n’
               改行(newline)

          ‘%%’
               ‘%‘そのもの

          ‘%x00’
               16進数のバイト値を出力

        • うしろのプレースホルダーのフォーマッティングに影響するプレース
          ホルダー:

          ‘%Cred’
               赤色に切り替える

          ‘%Cgreen’
               緑色に切り替える

          ‘%Cblue’
               青色に切り替える。

          ‘%Creset’
               色をリセットする

          ‘%C(...)’
               git-config(1) の「CONFIGURATION FILE」の Values で説明さ
               れている色の指定。 デフォルトでは、色はログ出力が有効にな
               っている場合にのみ表示されます’(‘color.diff’ または
               ‘color.ui’ または ‘--color’ によって、ターミナルに出す場
               合は前者の ‘auto’ 設定を尊重します)。 ‘%C(auto,...)’ は、
               default の歴史的同義語として受け入れられます(例:
               ‘%C(auto,red)’)。 ‘%C(always,...)’ を指定すると、色が有効
               になっていない場合でも色が表示されます(この形式やgitが色
               付けする可能性のある他のすべてのものを含め、出力全体の色
               を有効にするために ‘--color=always’ の使用を検討してくだ
               さい)。 ‘auto’ のみ(つまり、 ‘%C(auto)’)は、色が再び切り
               替わるまで、これに続くプレースホルダーで自動色付けをオン
               にします。

          ‘%m’
               左(‘<’) または 右(‘>’) または 境界 (‘-’) の印

          ‘%w([<w>[,<i1>[,<i2>]]])’
               git-shortlog(1) の -w オプションのように、 行の折り返しを
               切り替えます。

          ‘%<(<N>[,trunc|ltrunc|mtrunc])’
               次のプレースホルダーに少なくともN列を使用させ、 必要に応
               じて右側にスペースを埋め込みます。オプションで、出力がN列
               より長い場合は、先頭(ltrunc)または中間(mtrunc)または末尾
               (trunc)で切り捨てます。注意: 切り捨ては、 N >= 2 でのみ正
               しく機能することに注意してください。

          ‘%<|(<N>)’
               次のプレースホルダーを少なくともN番目の列まで取得し、 必
               要に応じて右側にスペースを埋め込みます

          ‘%>(<N>)’, ‘%>|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 左側に
               スペースが埋め込まれています

          ‘%>>(<N>)’, ‘%>>|(<N>)’
               ‘%>(<N>)’ 、 ‘%>|(<N>)’ とそれぞれ似ていますが、 次のプレ
               ースホルダーが指定されたよりも多くのスペースを取り、その
               左側にスペースがある場合は、それらのスペースを使用します
               。

          ‘%><(<N>)’, ‘%><|(<N>)’
               それぞれ ‘%<(<N>)’ 、 ‘%<|(<N>)’ に似ていますが、 両側に
               パディングがあります(つまり、テキストが中央に配置されます
               )

        • コミットから抽出された情報に展開するプレースホルダー:

          ‘%H’
               コミットハッシュ

          ‘%h’
               省略されたコミットハッシュ

          ‘%T’
               ツリーハッシュ

          ‘%t’
               省略されたツリーハッシュ

          ‘%P’
               親のハッシュ達

          ‘%p’
               省略された親のハッシュ達

          ‘%an’
               作者名

          ‘%aN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) を参照)

          ‘%ae’
               作者電子メールアドレス

          ‘%aE’
               作者電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) を参照)

          ‘%al’
               作者電子メールアドレスアカウント名(local-part)(‘@’ の前の
               部分)

          ‘%aL’
               作者電子メールアドレスアカウント名(local-part)(‘%al’ 参照
               ) .mailmap に関しては git-shortlog(1) または git-blame(1)
               参照)

          ‘%ad’
               作成日(フォーマットに関しては –date= オプション参照)

          ‘%aD’
               作成日 RFC2822形式

          ‘%ar’
               作成日 相対(relative)形式

          ‘%at’
               作成日 UNIXタイムスタンプ形式

          ‘%ai’
               作成日 ISO 8601風形式

          ‘%aI’
               作成日 厳密なISO 8601形式

          ‘%as’
               作成日 短い形式(‘YYYY-MM-DD’)

          ‘%ah’
               作成日 human形式( git-rev-list(1) の ‘--date=human’ オプ
               ションのようなかんじ)

          ‘%cn’
               コミッター名

          ‘%cN’
               作者名( .mailmap に関しては、git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ce’
               コミッター電子メールアドレス

          ‘%cE’
               コミッター電子メールアドレス(.mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%cl’
               コミッター電子メールアドレスアカウント名(local-part)( ‘@’
               の前の部分)

          ‘%cL’
               コミッター電子メールアドレスアカウント名(local-part)(
               ‘%cl’ 参照) .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%cd’
               コミッター日付(フォーマットに関しては ‘--date=’ オプショ
               ン参照)

          ‘%cD’
               コミッター日付 RFC2822形式

          ‘%cr’
               コミッター日付 相対(relative)形式

          ‘%ct’
               コミッター日付 UNIXタイムスタンプ形式

          ‘%ci’
               コミッター日付 ISO 8601風形式

          ‘%cI’
               コミッター日付 厳密なISO 8601形式

          ‘%cs’
               コミッター日付 短い形式(‘YYYY-MM-DD’)

          ‘%ch’
               コミッター日付 human形式(git-rev-list(1) の
               ‘--date=human’ オプションのようなかんじ)

          ‘%d’
               ref名 git-log(1) の –decorate オプションみたいなの

          ‘%D’
               " (", ")" で囲ってないref名

          ‘%(describe[:options])’
               git-describe(1) のような人間が読める名前。 説明できないコ
               ミットの場合は空の文字列。 ‘describe’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。タグが同時に追加または削除されると、説明に一貫性がな
               くなる可能性があります。

                  • ‘match=<pattern>’: ‘refs/tags/’ プレフィックスを除い
                    て、指定された ‘glob(7)’ パターンに一致するタグのみ
                    を考慮します。

                  • ‘exclude=<pattern>’: ‘refs/tags/’ プレフィックスを除
                    いて、指定された ‘glob(7)’ パターンに一致するタグを
                    対象にしません。

          ‘%S’
               コミットに到達したコマンドラインで指定されたref名 ( ‘git
               log --source’ など)は、 ‘git log’ でのみ機能します

          ‘%e’
               エンコーディング

          ‘%s’
               件名(subject)

          ‘%f’
               ファイル名に適した、サニタイズされた件名

          ‘%b’
               本文(body)

          ‘%B’
               生本文(raw body)(ラップされてない件名と本文)

          ‘%N’
               コミットノート(commit notes)

          ‘%GG’
               署名されたコミットの為のGPSからの生の検証メッセージ

          ‘%G?’

               G
                    良い(good)な(有効な)署名の場合はこの文字に置換されま
                    す。

               B
                    悪い署名(bad signature)の場合はこの文字に置換されま
                    す。

               U
                    有効性が不明(unknown validity)な良い署名の場合はこの
                    文字に置換されます。

               X
                    期限切れ(eXpired)の良い署名の場合はこの文字に置換さ
                    れます。

               Y
                    期限切れのキーで作成された良い署名の場合はこの文字に
                    置換されます。

               R
                    取り消されたキーによって作成された良い署名の場合はこ
                    の文字に置換されます。

               E
                    署名を確認できない場合(キーの欠落など)の場合はこの文
                    字に置換されます。

               N
                    署名がない場合の場合はこの文字に置換されます。

          ‘%GS’
               署名されたコミットの署名者の名前を表示する

          ‘%GK’
               署名されたコミットに署名するために使用されるキーを表示す
               る

          ‘%GF’
               署名されたコミットに署名するために使用されるキーのフィン
               ガープリントを表示する

          ‘%GP’
               署名されたコミットに署名するためにサブキーが使用された 主
               キーのフィンガープリントを表示します

          ‘%GT’
               署名されたコミットに署名するために使用されるキーの信頼レ
               ベル(trust level)を表示します

          ‘%gD’
               reflogセレクター(例:‘refs/stash@{1}’ or ‘refs/stash@{2
               minutes ago}’) この形式は、 ‘-g’ オプションで説明されてい
               る規則に従います。 ‘@’ の前の部分は、コマンドラインで指定
               されたrefnameです(したがって、 ‘git log -g
               refs/heads/master’ は ‘refs/heads/master@{0}’ を生成しま
               す)。

          ‘%gd’
               短縮されたreflogセレクター。 ‘%gD’ と同じですが、 人間が
               読みやすいようにrefname部分が短縮されています(したがって
               、 ‘refs/heads/master’ は単に ‘master’ になります)。

          ‘%gn’
               reflog ID名

          ‘%gN’
               reflog ID名( .mailmap に関しては git-shortlog(1) または
               git-blame(1) 参照)

          ‘%ge’
               reflog ID 電子メールアドレス

          ‘%gE’
               reflog ID 電子メールアドレス( .mailmap に関しては
               git-shortlog(1) または git-blame(1) 参照)

          ‘%gs’
               reflog 件名

          ‘%(trailers[:options])’
               git-interpret-trailers(1) によって解釈されるようにボディ
               のトレーラーを表示します。 ‘trailers’ 文字列の後には、コ
               ロンと0個以上のカンマ区切りオプションを続けることができま
               す。いずれかのオプションが複数回提供された場合、それぞれ
               最後のものが優先されます。

               ブール値オプションは、オプションの値 ‘[=<BOOL>]’ を受け入
               れます。 値 ‘true’ 、‘false’ 、 ‘on’ 、‘off’ などはすべて
               受け入れられます。 git-config(1) の "EXAMPLES" の
               "boolean" サブセクションを参照してください。ブール値オプ
               ションが値なしで指定された場合、それは有効を指定した事に
               なります。

                  • ‘key=<K>’ は指定されたキーを持つトレーラーのみを表示
                    します。マッチングは大文字と小文字を区別せずに行われ
                    、末尾のコロンはオプションです。オプションが複数回指
                    定されている場合、いずれかのキーに一致するトレーラー
                    行が表示されます。このオプションは自動的に ‘only’ オ
                    プションを有効にして、トレーラーブロック内の非トレー
                    ラー行が非表示になるようにします。それが望ましくない
                    場合は、 ‘only=false’ で無効にすることができます。 た
                    とえば、 ‘%(trailers:key=Reviewed-by)’ は、キーが
                    ‘Reviewed-by‘のトレーラー行を表示します。

                  • ‘only[=<BOOL>]’ はトレーラーブロックに非トレーラー行
                    を含めるかどうかを選択します。

                  • ‘separator=<SEP>’ はトレーラー行の間に挿入される区切
                    り文字を指定します。このオプションが指定されていない
                    場合、各トレーラー行は改行文字で終了します。文字列
                    SEPには、上記のリテラルフォーマットコードが含まれる
                    場合があります。区切り文字としてコンマを使用するには
                    、次のオプションとして解析されないよう ‘%x2C’ を使用
                    する必要があります。 たとえば、
                    ‘%(trailers:key=Ticket,separator=%x2C )’ は、キーが
                    ‘Ticket’ であるすべてのトレーラー行をカンマとスペー
                    スで区切って表示します。

                  • ‘unfold[=<BOOL>]’ は interpret-trailer の ‘--unfold’
                    オプションが指定されたかのように動作させます。たとえ
                    ば、 ‘%(trailers:only,unfold=true)’ が展開され、すべ
                    てのトレーラー行が表示されます。

                  • ‘keyonly[=<BOOL>]’ トレーラーのキー部分のみを表示。

                  • ‘valueonly[=<BOOL>]’ トレーラーの値部分のみ表示。

                  • ‘key_value_separator=<SEP>’ トレーラー行の間に挿入さ
                    れる区切り文字を指定します。このオプションが指定され
                    ていない場合、各トレーラーのキーと値のペアは ": " で
                    区切られます。 それ以外の場合は、上記の
                    ‘separator=<SEP>’ と同じセマンティクスを共有します。

     *Note*

     一部のプレースホルダーは、リビジョントラバーサルエンジンに指定され
     た他のオプションに依存する場合があります。 たとえば、 ‘%g*’ reflogオ
     プションは、reflogエントリをトラバースしない限り(たとえば、 ‘git
     log -g’ によって)空の文字列を挿入します。コマンドラインで
     ‘--decorate’ がまだ指定されていない場合、 ‘%d’ と ‘%D’ プレースホル
     ダーは「短い」(short)装飾形式を使用します。

   プレースホルダーの ‘%’ の後に ‘+’ (プラス記号)を追加すると、プレース
ホルダーが空でない文字列に展開される場合に限り、展開の直前に改行が挿入さ
れます。

   プレースホルダーの ‘%’ の後に ‘-’ (マイナス記号)を追加すると、プレー
スホルダーが空の文字列に展開された場合にのみ、展開の直前の連続するすべて
の改行が削除されます。

   プレースホルダーの ‘%’ の後に " " (スペース)を追加すると、プレースホ
ルダーが空でない文字列に展開される場合に限り、展開の直前にスペースが挿入
されます。

   • ‘tformat:’

     ‘tformat:’ 形式は、 "separator" セマンティクスの代わりに
     "terminator" セマンティクスを提供することを除いて、 ‘format:’ とま
     ったく同じように機能します。 つまり、各コミットには、エントリ間に区
     切り文字を配置するのではなく、メッセージターミネータ文字(通常は改行
     )が追加されます。 これは、「1行」形式と同様に、1行形式の最終エント
     リが新しい行で適切に終了することを意味します。 例えば:

          $ git log -2 --pretty=format:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973 -- NO NEWLINE

          $ git log -2 --pretty=tformat:%h 4da45bef \
            | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
          4da45be
          7134973

     加えて、 ‘%’ が含まれている認識されない文字列は、その前に
     ‘tformat:’ があるかのように解釈(interpret)されます。 たとえば、以下
     の2つは同等です:

          $ git log -2 --pretty=tformat:%h 4da45bef
          $ git log -2 --pretty=%h 4da45bef

DIFF FORMATTING
***************

以下のオプションを使用して、 ‘git show’ がdiff出力を生成する方法を変更で
きます。

‘-p’
‘-u’
‘--patch’
     パッチを生成します(generating patches に関するセクションを参照)。

‘-s’
‘--no-patch’
     diff出力を抑制します。デフォルトでパッチを表示する ‘git show’ のよ
     うなコマンド、または ‘--patch’ の効果をキャンセルする場合に便利です
     。

‘--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc)’
‘--no-diff-merges’
     マージコミットに使用するdiff形式を指定します。 ‘--first-parent’ が
     使用されている場合を除き、デフォルトは ‘dense-combined’ です。使用
     されている場合は、 ‘first-parent’ がデフォルトです。

     ‘--diff-merges=(off|none)’
     ‘--no-diff-merges’
          マージコミットのdiffの出力を無効にします。暗黙の値を上書きする
          のに便利です。

     ‘--diff-merges=on’
     ‘--diff-merges=m’
     ‘-m’
          このオプションにより、マージコミットのdiff出力がデフォルトの形
          式で表示されます。 ‘-m’ は、 ‘-p’ も指定されている場合にのみ出
          力を生成します。デフォルトの形式は、 ‘log.diffMerges’ 構成パラ
          メーター(configuration parameter)を使用して変更できます。デフ
          ォルト値は ‘separate’ です。

     ‘--diff-merges=first-parent’
     ‘--diff-merges=1’
          このオプションにより、マージコミットは最初の親に関してのみ完全
          なdiffを表示します。

     ‘--diff-merges=separate’
          これにより、マージコミットは各親に関して完全なdiffを表示します
          。親ごとに個別のログエントリとdiffが生成されます。

     ‘--diff-merges=combined’
     ‘--diff-merges=c’

‘-c:’
     このオプションを使用すると、マージコミットのdiff出力は、親と結果の
     ペアごとの差分を一度に1つずつ表示するのではなく、各親からの差分をマ
     ージ結果に同時に表示します。さらに、すべての親から変更されたファイ
     ルのみが一覧表示されます。 ‘-c’ は ‘-p’ の機能を含んでいます。

     ‘--diff-merges=dense-combined’
     ‘--diff-merges=cc’
     ‘--cc’
          このオプションを使用すると、 ‘--diff-merges=Combined’ によって
          生成される出力は、親のコンテンツに2つの派生(variants)しかない
          、興味のないハンクを省略してさらに圧縮され、マージ結果は変更な
          しでそのうちの1つを選択します。 ‘--cc’ は ‘-p’ の機能を含んで
          います。

‘--combined-all-paths’
     このフラグにより、結合された差分(マージコミットに使用)にすべての親
     からのファイルの名前が一覧表示されます。したがって、これは
     ‘--diff-merges=[dense-]combined’ が使用されている場合にのみ有効であ
     り、ファイル名の変更が検出された場合(つまり、名前の変更またはコピー
     の検出が要求された場合)にのみ役立つ可能性があります。

‘-U<n>’
‘--unified=<n>’
     通常の3行ではなく、<n> 行の内容でdiffを生成します。 ‘--patch’ の機
     能を含んでいます。

‘--output=<file>’
     stdout ではなく指定のファイルに出力します。

‘--output-indicator-new=<char>’
‘--output-indicator-old=<char>’
‘--output-indicator-context=<char>’
     生成されたパッチの新しい行、古い行、またはコンテキスト行を示すため
     に使用される文字を指定します。 通常、それらはそれぞれ "+"、 "-"、 "
     " です。

‘--raw’
     コミットごとに、生の差分形式を使用して変更の概要を表示します。
     git-diff(1) の "RAW OUTPUT FORMAT" セクションを参照してください。 こ
     れは、ログ自体をraw形式で表示することとは異なります。 これは
     ‘--format=raw’ で 実現できます。

‘--patch-with-raw’
     ‘-p --raw’ の同義語。

‘-t’
     diff出力にツリーオブジェクトを表示します。

‘--indent-heuristic’
     diffハンクの境界をずらす(shift)ヒューリスティックを有効にして、パッ
     チを読みやすくします。 これがデフォルトです。

‘--no-indent-heuristic’
     インデントヒューリスティック(indent heuristic)を無効にします。

‘--minimal’
     より多くの時間を費やして、可能な限り最小のdiffが生成されるようにし
     ます。

‘--patience’
     "patience diff" アルゴリズムを使用してdiffを生成します。

‘--histogram’
     "histogram diff" アルゴリズムを使用してdiffを生成します。

‘--anchored=<text>’
     "anchored diff" アルゴリズムを使用してdiffを生成します。

     このオプションは複数回指定できます。

     行がソースと宛先の両方に存在し、1回だけ存在し、このテキストで始まる
     場合、このアルゴリズムは、その行が出力に削除または追加として表示さ
     れないようにします。内部で "patience diff" アルゴリズムを使用します
     。

‘--diff-algorithm={patience|minimal|histogram|myers}’
     diffアルゴリズムを選択します。その派生(variants)は以下のとおりです:

     ‘default’, ‘myers’
          基本的な貪欲な差分アルゴリズム(greedy diff algorithm)。現在、
          これがデフォルトです。

     ‘minimal’
          より多くの時間を費やして、可能な限り最小のdiffが生成されるよう
          にします。

     ‘patience’
          パッチを生成する時に "patience diff" アルゴリズムを使います。

     ‘histogram’
          このアルゴリズムは、忍耐アルゴリズム(patience algorithm)を拡張
          して、「発生率の低い共通要素をサポート」(support
          low-occurrence common elements)します。

     たとえば、 あなたが ‘diff.algorithm’ 変数をデフォルト以外の値に設定
     した上で、それでもデフォルト値を使用する場合は、
     ‘--diff-algorithm=default’ オプションを使用する必要があります。

‘--stat[=<width>[,<name-width>[,<count>]]]’
     diffstatを生成します。 デフォルトでは、必要なだけのスペースがファイ
     ル名部分に使用され、残りはグラフ部分に使用されます。最大幅はデフォ
     ルトで端末幅、または端末に接続されていない場合は80桁であり、
     ‘<width>’ で上書きできます。ファイル名部分の幅は、コンマの後に別の
     幅 ‘<name-width>’ を指定することで制限できます。グラフ部分の幅は、
     ‘--stat-graph-width=<width>’ (統計グラフを生成するすべてのコマンド
     に影響します)を使用するか、 ‘diff.statGraphWidth=<width>’ ( ‘git
     format-patch’ に影響しません)を設定することによって制限できます。
     3番目のパラメータ ‘<count>’ を指定することにより、出力を最初の
     ‘<count>’ 行に制限し、それに ‘...’ が続く形にできます。

     これらのパラメータは、 ‘--stat-width=<width>’ と
     ‘--stat-name-width=<name-width>’ と ‘--stat-count=<count>’ を使用し
     て個別に設定することもできます。

‘--compact-summary’
     ファイルの作成や削除( "new" または "gone" 。オプションでシンボリッ
     クリンクの場合は "+l" )、diffstatのモード変更(実行可能ビットを追加
     または削除する場合は、それぞれ "+x" または "-x" )など、拡張ヘッダー
     情報の要約を出力します。情報はファイル名部分とグラフ部分の間に置か
     れます。本機能は ‘--stat’ の機能を含んでいます。

‘--numstat’
     ‘--stat`に似ていますが、プログラムで処理しやすい(machine friendly)よ
     うに、追加および削除された行数を10進表記とパス名で省略形なしで表示
     します。バイナリファイルの場合、 `0 0’ の代わりに2つの ‘-’ を出力し
     ます。

‘--shortstat’
     変更されたファイルの総数と、追加および削除された行の数を含む
     ‘--stat’ 形式の最後の行のみを出力します。

‘-X[<param1,param2,...>]’
‘--dirstat[=<param1,param2,...>]’
     各サブディレクトリの相対的な変更量の分布を出力します。 ‘--dirstat’
     の動作は、パラメータのコンマ区切りリストを渡すことでカスタマイズで
     きます。デフォルトは、 ‘diff.dirstat’ 構成変数によって制御されます
     (git-config(1) 参照)。以下のパラメータを使用できます:

     ‘changes’
          ソースから削除された、または宛先に追加された行をカウントして、
          dirstat数を計算します。これは、ファイル内の純粋なコード移動の
          量を無視します。つまり、ファイル内の行の再配置は、他の変更ほど
          カウントされません。これは、パラメーターが指定されていない場合
          のデフォルトの動作です。

     ‘lines’
          通常の行ベースのdiff分析を実行し、削除/追加された行数を合計し
          て、dirstat数を計算します。 (バイナリファイルの場合、バイナリ
          ファイルには行の概念がないため、代わりに64バイトのチャンクをカ
          ウントします)。 これは ‘changes’ 動作よりも高価な ‘--dirstat’
          動作ですが、他の変更と同じようにファイル内の再配置された行をカ
          ウントします。結果の出力は、他の ‘--*stat’ オプションから得ら
          れるものと一致しています。

     ‘files’
          変更されたファイルの数を数えて、dirstat数を計算します。変更さ
          れた各ファイルは、dirstat分析で等しくカウントされます。これは
          、ファイルの内容をまったく調べる必要がないため、計算コストが最
          もかからない ‘--dirstat’ の動作です。

     ‘cumulative’
          親ディレクトリの子ディレクトリの変更も同様にカウントします。
          ‘cumulative’(累積的) を使用する場合、報告されるパーセンテージ
          の合計が100%を超える場合があることに注意してください。デフォル
          トの(非累積的な)動作は、‘noncumulative’ パラメーターで指定でき
          ます。

     <limit>
          整数パラメーターは、カットオフパーセント(デフォルトでは3%)を指
          定します。指定の割合より少ないディレクトリは、出力に表示されま
          せん。

     例: 変更されたファイルの総数の10%未満のディレクトリを無視し、親ディ
     レクトリに子ディレクトリの数を累積しながら、変更されたファイルをカ
     ウント: ‘--dirstat=files,10,cumulative’

‘--cumulative’
     ‘--dirstat=cumulative’ と同義語

‘--dirstat-by-file[=<param1,param2>...]’
     ‘--dirstat=files,param1,param2...’ と同義語

‘--summary’
     作成、名前変更、モード変更などの拡張ヘッダー情報の短い要約
     (condensed summary)を出力します。

‘--patch-with-stat’
     ‘-p --stat’ と同義語。

‘-z’
     改行(newline)ではなく、NULでコミットを区切ります。

     また、 ‘--raw’ または ‘--numstat’ を指定した場合は、パス名を難読化
     (munge)したり、出力フィールドターミネータとしてNULを使用したりしな
     いでください。

     このオプションがないと、構成変数 ‘core.quotePath’ で説明されている
     ように、 通常の文字以外(unusual characters)を含むパス名が引用符で囲
     まれます(git-config(1) 参照)。

‘--name-only’
     変更されたファイルの名前のみを表示します。 多くの場合、ファイル名は
     UTF-8でエンコードされます。 詳細については、 git-log(1) のマニュア
     ルページにあるエンコーディングに関する議論(the discussion about
     encoding)を参照してください。

‘--name-status’
     変更されたファイルの名前とステータスのみを表示します。ステータス文
     字の意味については、 ‘--diff-filter’ オプションの説明を参照してくだ
     さい。 ‘--name-only’ と同じように、ファイル名はしばしばUTF-8でエン
     コードされます。

‘--submodule[=<format>]’
     サブモジュールの違いをどのように表示するかを指定します。
     ‘--submodule=short’ を指定する場合、 short形式が使用されます。この
     形式は、範囲の最初と最後にコミットの名前を表示するだけです。
     ‘--submodule’ または ‘--submodule=log’ が指定されている場合、 log形
     式が使用されます。この形式では、 git-submodule(1) ‘summary’ のよう
     に範囲内のコミットが一覧表示されます。 ‘--submodule=diff’ が指定さ
     れている場合、 diff形式が使用されます。この形式は、コミット範囲間の
     サブモジュールの内容の変更のインラインdiffを示します。configオプシ
     ョンが設定されていない場合、デフォルトは ‘diff.submodule’ または
     ‘short’ 形式です。

‘--color[=<when>]’
     色付きのdiffを表示します。 ‘--color’ (つまり、 ‘=<when>’ 無し) は
     ‘--color=always’ と同じです。 <when> は、 always または never また
     は auto のいずれかになります。

‘--no-color’
     カラーdiffをオフにします。 ‘--color=never’ と同じです。

‘--color-moved[=<mode>]’
     ソースコードの移動した行を別の色にします。 <mode>は、オプションが指
     定されていない場合はデフォルトで no になり、 モードが指定されていな
     いオプションが指定されている場合は zebra になります。 モードは以下
     のいずれかでなければなりません:

     no
          移動行をハイライトしません。

     default
          zebra の同義語です。これは、将来、より賢明なモードに変更される
          可能性があります。

     plain
          ある場所で追加され、別の場所で削除された行は、
          ‘color.diff.newMoved’ で色付けされます。 同様に、
          ‘color.diff.oldMoved’ は、差分の別の場所に追加された削除された
          行に使用されます。このモードは移動された行をピックアップします
          が、コードのブロックが順列なしで移動されたかどうかを判断するこ
          とはレビューではあまり役に立ちません。

     blocks
          少なくとも20文字の英数字の移動テキストのブロックが貪欲に検出さ
          れます。検出されたブロックは、 ‘color.diff.{old,new}Moved’ 色
          のいずれかを使用して色付けされます。隣接するブロックを区別する
          ことはできません。

     zebra
          移動されたテキストのブロックは、 _blocks_ モードの場合と同様に
          検出されます。 ブロックは、 _color.diff.{old,new}Moved_ 色また
          は _color.diff.{old,new}MovedAlternative_ 色のいずれかを使用し
          て色付けされます。2つの色の間の変化は、新しいブロックが検出さ
          れたことを示します。

     dimmed-zebra
          _zebra_ に似ていますが、移動されたコードの重要でない部分の追加
          の調光(dimmed)が実行されます。隣接する2つのブロックの境界線は
          興味深いと見なされ、残りは興味深いものではありません。
          ‘dimmed_zebra’ は非推奨の同義語です。

‘--no-color-moved’
     移動検出をオフにします。 これは、構成設定を上書きするために使用でき
     ます。 ‘--color-moved=no’ と同じです。

‘--color-moved-ws=<modes>’
     これは、 ‘--color-moved’ の移動検出を実行するときに空白を無視する方
     法を設定します。 これらのモードは、コンマ区切りのリストとして指定で
     きます:

     no
          移動行検出を実行するときに、空白(whitespace)を無視しない。

     ignore-space-at-eol
          行末(EOL)での空白(whitespace)の変更を無視します。

     ignore-space-change
          空白(whitespace)の数の変更は無視してください。これは、行末の空
          白(whitespace)を無視し、1つ以上の空白文字(whitespace
          characters)の他のすべてのシーケンスを同等と見なします。

     ignore-all-space
          行を比較するときは空白(whitespace)を無視します。これにより、一
          方の行に空白があり、もう一方の行に空白がない場合でも、違いは無
          視されます。

     allow-indentation-change
          最初に移動検出で空白(whitespace)を無視し、空白(whitespace)の変
          更が行ごとに同じである場合にのみ、移動されたコードブロックをブ
          ロックにグループ化します。 これは他のモードと互換性がありませ
          ん。

‘--no-color-moved-ws’
     移動検出を実行するときは、空白(whitespace)を無視しないでください。
     これは、構成設定を上書きするために使用できます。
     ‘--color-moved-ws=no’ と同じです。

‘--word-diff[=<mode>]’
     <mode> を使用して変更された単語を区切ることにより、単語のdiffを表示
     します。デフォルトでは、単語は空白で区切られます。 以下の
     ‘--word-diff-regex’ を参照してください。 <mode> のデフォルトは
     ’plain’です。 <mode> は以下のいずれかである必要があります:

     color
          変更された単語(word)を色のみを使用して強調表示します。
          ‘--color’ を意味します。

     plain
          単語を ‘[-removed-]’ および ‘{+added+}’ として表示します。 区
          切り文字が入力に表示されている場合、区切り文字をエスケープしよ
          うとしないため、出力があいまいになる可能性があります。

     porcelain
          スクリプトの使用を目的とした特別な行ベースの形式を使用します。
          追加/削除/無変更については、通常の統一されたdiff形式で印刷され
          、行の先頭の ‘+’/‘-’/‘ ‘ 文字で始まり、行の終わりまで続きます
          。入力の改行は、それ自体の行のチルダ ‘~’ で表されます。

     none
          単語(word)のdiffを再度無効にします。

     注意: 最初のモードの名前にもかかわらず、有効になっている場合、すべ
     てのモードで変更された部分を強調するために色が使用されることに注意
     してください。

‘--word-diff-regex=<regex>’
     空白以外を単語と見なす代わりに、 <regex> を使用して単語が何であるか
     を決定します。また、すでに有効になっていない限り、この機能は
     ‘--word-diff’ の機能を含んでいます。

     <regex> の重複しないマッチはすべて、単語と見なされます。これらのマ
     ッチの間のすべては空白と見なされ、違いを見つけるためとしては無視さ
     れます！ 正規表現に ‘|[^[:space:]]’ を追加して、空白以外のすべての
     文字とマッチすることを確認することをお勧めします。改行を含むマッチ
     は、改行で黙って切り捨てられます！

     たとえば、 ‘--word-diff-regex=.’ は各文字を単語として扱い、それに応
     じて文字ごとの違いを表示します。

     正規表現は、diffドライバーまたは構成オプション(configuration
     option)を介して設定することもできます。 gitattributes(5) または
     git-config(1) を参照してください。これを指定すると、diffドライバー
     または構成設定(configuration settings)が明示的にオーバーライドされ
     ます。diffドライバーは構成設定を上書きします。

‘--color-words[=<regex>]’
     ‘--word-diff=color’ に ‘--word-diff-regex=<regex>’ を加えたものに相
     当します(正規表現が指定されている場合)。

‘--no-renames’
     構成ファイルにデフォルトで指定されている場合でも、名前変更の検出を
     オフにします。

‘--[no-]rename-empty’
     名前変更ソースとして空のブロブを使用するかどうか。

‘--check’
     変更によって競合マーカーまたは空白エラーが発生した場合に警告します
     。空白エラーと見なされるものは、 ‘core.whitespace’ 構成によって制御
     されます。 デフォルトでは、末尾の空白(空白のみで構成される行を含む
     )と、行の最初のインデント内で直後にタブ文字が続くスペース文字は、空
     白エラーと見なされます。問題が見つかった場合は、ゼロ以外のステータ
     スで終了します。なお、 –exit-code とは互換性がありません。

‘--ws-error-highlight=<kind>’
     diffの ‘context’ または ‘old’ または ‘new’ 行の空白エラーを強調表示
     します。複数の値はコンマで区切られ、 ‘none’ は前の値をリセットし、
     ‘default’ はリストを ‘new’ にリセットし、 ‘all’ は old、new、
     context の省略形です。このオプションが指定されておらず、構成変数
     ‘diff.wsErrorHighlight’ が設定されていない場合、 ‘new’ 行の空白エラ
     ーのみが強調表示されます。空白エラーは ‘color.diff.whitespace’ で色
     分けされています。

‘--full-index’
     パッチ形式の出力を生成するときは、最初の一握りの文字(first handful
     of characters)の代わりに、「インデックス」行にイメージ前およびイメ
     ージ後の完全ブロブオブジェクト名を表示します。

‘--binary’
     ‘--full-index’ に加えて、 ‘git-apply’ で適用できるバイナリ差分を出
     力します。 ‘--patch’ の機能を含んでいます。

‘--abbrev[=<n>]’
     完全な40バイトの16進オブジェクト名をdiff-raw形式の出力とdiff-treeヘ
     ッダー行に表示する代わりに、オブジェクトを一意に参照する、少なくと
     も <n> 桁の16進数の長さの最短のプレフィックスを表示します。diffパッ
     チ出力形式では、 ‘--full-index’ が優先されます。つまり、
     ‘--full-index’ が指定されている場合、 ‘--abbrev’ に関係なく、完全な
     ブロブ名が表示されます。デフォルト以外の桁数は、 ‘--abbrev=<n>’ で
     指定できます。

‘-B[<n>][/<m>]’
‘--break-rewrites[=[<n>][/<m>]]’
     完全な書き換えの変更を削除と作成のペアに分割します。これには以下の
     2つの目的があります:

     これは、ファイルの完全な書き換えに相当する変更が、コンテキストとし
     てテキストで一致する非常に少数の行と混合された一連の削除と挿入とし
     てではなく、古いものすべての単一の削除とそれに続く すべての新しいも
     のを1回挿入し、数値 ‘m’ が -B オプションのこの側面を制御します(デフ
     ォルトは60%)。 ‘-B/70%’ は、Gitがそれを完全な書き換えと見なすために
     、元の30%未満が結果に残る必要があることを指定します(つまり、結果の
     パッチは、コンテキスト行と混合された一連の削除と挿入になります)。

     -M と一緒に使用すると、完全に書き換えられたファイルも名前変更のソー
     スと見なされ(通常、 -M は、消えたファイルのみを名前変更のソースと見
     なします)、数 ‘n’ が -Bオプションのこの側面を制御します(デフォルト
     は50%)。 ‘-B20%’ は、ファイルのサイズの20%以上と比較して、追加およ
     び削除を伴う変更が、別のファイルへの名前変更の可能なソースとして取
     得される資格があることを指定します。

‘-M[<n>]’
‘--find-renames[=<n>]’
     diffを生成する場合は、コミットごとに名前の変更を検出して報告します
     。 履歴をトラバースしながら名前を変更してファイルをフォローする方法
     については、 ‘--follow’ を参照してください。 ‘n’ が指定されている場
     合、それは類似性インデックスのしきい値です (つまり、ファイルのサイ
     ズと比較した追加/削除の量)。 たとえば、 ‘-M90%’ は、ファイルの90%以
     上が変更されていない場合、 Gitが削除/追加のペアを名前変更と見なす必
     要があることを意味します。 ‘%’ 記号がない場合、数値は小数として読み
     取られ、その前に小数点が付きます。 つまり、 ‘-M5’ は0.5になるため、
     ‘-M50%’ と同じになります。 同様に、 ‘-M05’ は ‘-M5%’ と同じです。 検
     出を正確な名前変更に制限するには、 ‘-M100%’ を使用します。 デフォル
     トの類似性インデックスは50%です。

‘-C[<n>]’
‘--find-copies[=<n>]’
     名前と同様コピーを検出します。 ‘--find-copies-harder’ ‘も参照してく
     ださい。 `n’ を指定すると、 ‘-M<n>’ と同じ意味になります。

‘--find-copies-harder’
     パフォーマンス上の理由から、デフォルトでは、 ‘-C’ オプションは、コ
     ピーの元のファイルが同じ変更組(changeset)で変更された場合にのみコピ
     ーを検索します。このフラグにより、コマンドは変更されていないファイ
     ルをコピー元の候補として検査します。これは大規模なプロジェクトでは
     非常にコストのかかる操作であるため、注意して使用してください。 複数
     の ‘-C’ オプションを指定しても同じ効果があります。

‘-D’
‘--irreversible-delete’
     削除するプレイメージ(preimage)を省略します。つまり、ヘッダーのみを
     出力し、プレイメージと ‘/dev/null’ の差分は出力しません。結果のパッ
     チは、 ‘patch’ または ‘git apply’ で適用されることを意図していませ
     ん。これは、変更後にテキストを確認することに集中したい人のためだけ
     のものです。さらに、出力には明らかに、そのようなパッチを手動でも逆
     に適用するのに十分な情報が不足しているため、オプションの名前が付け
     られています。

     ‘-B’ と併用する場合は、削除/作成ペアの削除部分のプリイメージ
     (preimage)も省略してください。

‘-l<num>’
     ‘-M’ および ‘-C’ オプションには、名前変更/コピーのサブセットを安価
     に検出できるいくつかの準備手順が含まれ、その後に、残りのすべてのペ
     アになっていない宛先をすべての関連ソースと比較する徹底的なフォール
     バック部分が続きます。(名前の変更の場合、残りのペアになっていないソ
     ースのみが関係します。コピーの場合、すべての元のソースが関係します
     )。Nのソースと宛先の場合、この徹底的なチェックのコストは O(N^2) で
     す。このオプションは、関係するソース/宛先ファイルの数が指定された数
     を超えた場合に、名前変更/コピー検出の完全な部分が実行されないように
     します。デフォルトは diff.renameLimit です。 値0は無制限として扱わ
     れることに注意してください。

‘--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]’
     追加(Add)・コピー(Copy)・削除(Delete)・変更(Modify)・名前変更
     (Rename)されたファイル、タイプが変更されたファイル(T)、マージされて
     いないファイル(U)、不明なファイル(X)、またはペアリングが壊れている
     ファイル(B)のみを選択します。フィルタ文字(無しも含む)の任意の組み合
     わせを使用できます。 組み合わせに ‘*’ (全てまたは無し)が追加される
     と、比較で他の基準に一致するファイルがある場合、すべてのパスが選択
     されます。 他の基準に一致するファイルがない場合、何も選択されません
     。

     また、逆に、除外したい時はこれらの各大文字指定を小文字にして指定し
     ます。例えば ‘--diff-filter=ad’ は、追加および削除されたパスを除外
     します。

     注意:すべてのdiffがすべてのタイプを特徴とするわけではないことに注意
     してください。 たとえば、インデックスから作業ツリーへのdiffにエント
     リを追加することはできません(diffに含まれるパスのセットは、インデッ
     クスの内容によって制限されるため)。 同様に、これらのタイプの検出が
     無効になっている場合、コピーおよび名前変更されたエントリは表示され
     ません。

‘-S<string>’
     ファイル内の指定の文字列(つまり、 addition 、deletion)の出現回数の
     差分を調べます。スクリプターが使用することを目的としています。

     (構造体など)コードの正確なブロックを探していて、そのブロックが最初
     に作成されてからの履歴を知りたい場合に便利です。この機能を繰り返し
     使用して、プリイメージ(preimage)内の興味深いブロックを ‘-S’ にフィ
     ードバックし、そしてあなたはそれをブロックの最初のバージョンを取得
     するまで続けます。

     バイナリファイルも検索されます。

‘-G<regex>’
     パッチテキストに <regex> にマッチする 追加/削除 された行が含まれて
     いる差分を探します。

     ‘-S<regex> --pickaxe-regex’ と ‘-G<regex>’ の違いを説明するために、
     同じファイル内で以下のdiffを使用してコミットすることを検討してくだ
     さい:

          +    return frotz(nitfol, two->ptr, 1, 0);
          ...
          -    hit = frotz(nitfol, mf2.ptr, 1, 0);

     ‘git log -G"frotz\(nitfol"’ はこのコミットを表示しますが、 ‘git log
     -S"frotz\(nitfol" --pickaxe-regex’ は表示しません(その文字列の出現
     回数が変更されなかったため)。

     ‘--text’ が提供されていない限り、 textconv フィルターのないバイナリ
     ファイルのパッチは無視されます。

     詳細については gitdiffcore(7) の「pickaxe」エントリを参照してくださ
     い。

‘--find-object=<object-id>’
     指定されたオブジェクトの出現回数を変更する違いを探します。 ‘-S’ と
     同様に、引数だけが異なり、特定の文字列ではなく特定のオブジェクト
     IDを検索します。

     オブジェクトは、ブロブまたはサブモジュールのコミットにすることがで
     きます。 これは、 ‘git-log’ の ‘-t’ オプションがツリーも探すことを
     意味します。

‘--pickaxe-all’
     ‘-S’ または ‘-G’ が変更を見つけたら、 <string> の変更を含むファイル
     だけでなく、その変更セット(changeset)のすべての変更を表示します。

‘--pickaxe-regex’
     ‘-S’ に指定した <string> を拡張POSIX正規表現として扱います。

‘-O<orderfile>’
     ファイルが出力に表示される順序を制御します。これは ‘diff.orderFile’
     構成変数をオーバーライドします(git-config(1) 参照)。
     ‘diff.orderFile’ をキャンセルするには、 ‘-O/dev/null’ を使用します
     。

     出力順序は、 <orderfile> 内のglobパターンの順序によって決定されます
     。最初のパターンに一致するパス名を持つすべてのファイルが最初に出力
     され、2番目のパターンに一致する(ただし最初のパターンには一致しない
     )パス名を持つすべてのファイルが次に出力されます。パス名がどのパター
     ンとも一致しないすべてのファイルは、ファイルの最後に暗黙のすべて一
     致パターンがあるかのように、最後に出力されます。複数のパス名のラン
     クが同じである場合(同じパターンに一致するが、以前のパターンには一致
     しない)、相互の出力順序は通常の順序です。

     <orderfile> は以下のとおりパースされます:

        • 空白行は無視されるため、読みやすくするための区切りとして使用で
          きます。

        • ハッシュ ("‘#’") で始まる行は無視されるため、コメントに使用で
          きます。 パターンがハッシュで始まる場合は、パターンの先頭にバ
          ックスラッシュ(訳注:日本では環境により円記号)("‘\’") を追加し
          ます。

        • 他の各行には、単一のパターンが含まれています。

     パターンは、 FNM_PATHNAME フラグなしで fnmatch(3) に使用されるパタ
     ーンと同じ構文とセマンティクスを持ちますが、最終的なパス名コンポー
     ネントをいくつも削除するとパターンと一致する場合、パス名もパターン
     と一致する点が異なります。 たとえば、パターン "‘foo*bar’" は、
     "‘fooasdfbar’" および "‘foo/bar/baz/asdf’" と一致しますが、
     "‘foobarx’" とは一致しません。

‘--skip-to=<file>’
‘--rotate-to=<file>’
     名前付き <file> の前のファイルを出力から破棄するか(スキップして)、
     出力の最後に移動させます(ローテーションさせます)。 これらは主に
     ‘git difftool’ コマンドを使用するために考案されたものであり、それ以
     外の場合はあまり役に立たない可能性があります。

‘-R’
     2つの入力を交換します。 つまり、インデックスまたはディスク上のファ
     イルとツリーの内容の違いを表示します。

‘--relative[=<path>]’
‘--no-relative’
     プロジェクトのサブディレクトリから実行する場合、このオプションを使
     用して、ディレクトリ外の変更を除外し、それに関連するパス名を表示す
     るように指示できます。サブディレクトリ(ベアリポジトリなど)にいない
     場合は、引数として <path> を指定することで、出力を作成するサブディ
     レクトリに名前を付けることができます。 ‘--no-relative`は、
     `diff.relative’ 設定オプションと以前の ‘--relative’ の両方を打ち消
     すために使用できます。

‘-a’
‘--text’
     すべてのファイルをテキストとして扱います。

‘--ignore-cr-at-eol’
     比較を行うときは、行末のキャリッジリターン(carriage-return)を無視し
     ます。

‘--ignore-space-at-eol’
     行末(EOL)での空白(whitespace)の変更を無視します。

‘-b’
‘--ignore-space-change’
     空白(whitespace)の数の変更は無視してください。これは、行末の空白
     (whitespace)を無視し、1つ以上の空白文字(whitespace characters)の他
     のすべてのシーケンスを同等と見なします。

‘-w’
‘--ignore-all-space’
     行を比較するときは空白を無視します。 これにより、一方の行に空白があ
     り、もう一方の行に空白がない場合でも、違いは無視されます。

‘--ignore-blank-lines’
     全て空白の行の変更は無視します。

‘-I<regex>’
‘--ignore-matching-lines=<regex>’
     すべての行が <regex> にマッチする変更を無視します。このオプションは
     複数回指定できます。

‘--inter-hunk-context=<lines>’
     指定された行数までの差分ハンク間のコンテキストを表示し、それによっ
     て互いに近いハンクを融合します。デフォルトは
     ‘diff.interHunkContext’ で、設定オプションが設定されていない場合は
     0です。

‘-W’
‘--function-context’
     関数全体を各変更のコンテキスト行として表示します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

‘--ext-diff’
     外部diffヘルパーの実行を許可します。 gitattributes(5) を使用して外
     部diffドライバーを設定する場合は、 git-log(1) およびその仲間と一緒
     にこのオプションを使用する必要があります。

‘--no-ext-diff’
     外部diffドライバーを禁止します。

‘--textconv’
‘--no-textconv’
     バイナリファイルを比較するときに、外部テキスト変換フィルターの実行
     を許可(または禁止)します。 詳細については、 gitattributes(5) を参照
     してください。textconvフィルターは通常、一方向の変換であるため、結
     果のdiffは人間の消費に適していますが、適用(apply)することはできませ
     ん。このため、textconvフィルターは、 git-diff(1) および git-log(1)
     に対してのみデフォルトで有効になりますが、 git-format-patch(1) また
     はdiff配管コマンドに対しては有効になりません。

‘--ignore-submodules[=<when>]’
     diff生成のサブモジュールへの変更を無視します。 <when> は、 none・
     untracked・dirty・allのいずれかになります。これがデフォルトです。
     noneを使用すると、追跡されていないファイルまたは変更されたファイル
     が含まれている場合、またはそのHEADがスーパープロジェクトに記録され
     ているコミットと異なる場合にサブモジュールが変更されたと見なされ、
     git-config(1) または gitmodules(5) の ignoreオプションの設定をオー
     バーライドするために使用できます。untrackedが使用されている場合、サ
     ブモジュールには追跡されていないコンテンツのみが含まれている場合、
     サブモジュールはダーティとは見なされません(ただし、変更されたコンテ
     ンツはスキャンされます)。「dirty」を使用すると、サブモジュールの作
     業ツリーへのすべての変更が無視され、スーパープロジェクトに格納され
     ているコミットへの変更のみが表示されます(これは1.7.0までの動作でし
     た)。「all」を使用すると、サブモジュールへのすべての変更が非表示に
     なります。

‘--src-prefix=<prefix>’
     "a/" の代わりに、与えられたソースプレフィックス(source prefix)を表
     示します。

‘--dst-prefix=<prefix>’
     "b/" の代わりに、指定された宛先プレフィックス(destination prefix)を
     表示します。

‘--no-prefix’
     送信元(source)または宛先(destination)のプレフィックスを表示しません
     。

‘--line-prefix=<prefix>’
     出力のすべての行に追加のプレフィックスを付加します。

‘--ita-invisible-in-index’
     デフォルトでは、 "git add -N" によって追加されたエントリは、 "git
     diff" に既存の空のファイルとして表示され、 "git diff –cached" に新
     しいファイルとして表示されます。このオプションを使用すると、エント
     リは "git diff" では新しいファイルとして表示され、 "git diff
     –cached" では存在しません。このオプションは、
     ‘--ita-visible-in-index’ で元に戻すことができます。どちらのオプショ
     ンも実験的なものであり、将来削除される可能性があります。

   これらの一般的なオプションの詳細については、 gitdiffcore(7) も参照し
てください。

Generating patch text with -p
*****************************

git-diff(1) 、 git-log(1) 、 git-show(1) 、 git-diff-index(1) 、
git-diff-tree(1) 、 git-diff-files(1) に ‘-p’ オプションを付けて実行する
とパッチテキストを生成します。パッチテキストの作成は、
‘GIT_EXTERNAL_DIFF’ と ‘GIT_DIFF_OPTS’ 環境変数( git(1) 参照)、および
‘diff’ 属性( gitattributes(5) 参照)を介してカスタマイズできます。

   -pオプションが生成するものは、従来のdiff形式とは少々異なります:

  1. 先行して、以下のような "git diff" ヘッダーがあります:

          diff --git a/file1 b/file2

     名前の変更/コピーが含まれない限り、 ‘a/’ と ‘b/’ のファイル名は同じ
     です。 特に、作成または削除の場合でも、 ‘a/’ または ‘b/’ ファイル名
     の代わりに ‘/dev/ null’ が使用されることはありません。

     名前変更/コピーが含まれる場合、 ‘file1’ と‘file2‘ は、それぞれ名前
     変更/コピーのソースファイルの名前と、名前変更/コピーが生成するファ
     イルの名前を示します。

  2. その後に、1つ以上の拡張ヘッダー行達が続きます:

          old mode <mode>
          new mode <mode>
          deleted file mode <mode>
          new file mode <mode>
          copy from <path>
          copy to <path>
          rename from <path>
          rename to <path>
          similarity index <number>
          dissimilarity index <number>
          index <hash>..<hash> <mode>

     ファイルモードは、ファイルタイプとファイル許可ビットを含む6桁の8進
     数として出力されます。

     拡張ヘッダーのパス名には、 ‘a/’ および ‘b/’ プレフィックスは含まれ
     ません。

     類似インデックス(similarity index)は変更されていない行のパーセンテ
     ージであり、非類似インデックス(dissimilarity index)は変更された行の
     パーセンテージです。これは切り捨てられた整数であり、その後にパーセ
     ント記号が続きます。したがって、100％の類似インデックス値は2つの等
     しいファイルを表し、100％の非類似性は古いファイルから新しいファイル
     に移行された行がないことを意味します。

     インデックス行には、変更前後のブロブオブジェクト名が含まれます。
     <mode> は、ファイルモードが変更されない場合に含まれます。それ以外の
     場合、別々の行は古いモードと新しいモードを示します。

  3. 通常の文字でないキャラクタ(\"unusual\" characters)を含むパス名は、
     構成変数 ‘core.quotePath’ で説明されているように引用符で囲まれてい
     ます( git-config(1)参照)。

  4. 出力内のすべての ‘file1’ ファイルはコミット前のファイルを参照し、す
     べての ‘file2’ ファイルはコミット後のファイルを参照します。各変更を
     各ファイルに順番に適用するのは誤りです。たとえば、以下のパッチはaと
     bを交換します:

          diff --git a/a b/b
          rename from a
          rename to b
          diff --git a/b b/a
          rename from b
          rename to a

  5. ハンクのヘッダーには、ハンクが適用される関数の名前が記載されていま
     す。特定の言語に合わせてこれを調整する方法の詳細については、
     gitattributes(5) の "Defining a custom hunk-header" を参照してくだ
     さい。

Combined diff format
********************

diffを生成するコマンドは、マージを表示するときに ‘-c’ または ‘--cc’ オプ
ションを使用して「合成diff」(combined diff)を生成できます。これは
git-diff(1) または git-show(1) でのマージを表示するときのデフォルトの形
式です。 注意: これらのコマンドのいずれかに適切な ‘--diff-merges’ オプシ
ョンを指定して、特定の形式で差分を強制的に生成できることにも注意してくだ
さい。

   合成diff形式は以下のようになります:

     diff --combined describe.c
     index fabadb8,cc95eb0..4866510
     --- a/describe.c
     +++ b/describe.c
     @@@ -98,20 -98,12 +98,20 @@@
             return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
       }

     - static void describe(char *arg)
      -static void describe(struct commit *cmit, int last_one)
     ++static void describe(char *arg, int last_one)
       {
      +      unsigned char sha1[20];
      +      struct commit *cmit;
             struct commit_list *list;
             static int initialized = 0;
             struct commit_name *n;

      +      if (get_sha1(arg, sha1) < 0)
      +              usage(describe_usage);
      +      cmit = lookup_commit_reference(sha1);
      +      if (!cmit)
      +              usage(describe_usage);
      +
             if (!initialized) {
                     initialized = 1;
                     for_each_ref(get_name);

  1. まず "git diff" ヘッダーがあり、以下のようになります( ‘-c’ オプショ
     ンが使用されている場合):

          diff --combined file

     または、以下のようになります( ‘--cc’ オプションが使用されている場合
     ):

          diff --cc file

  2. その後に1つ以上の拡張ヘッダー行が続きます(以下の例は、2つの親とのマ
     ージを示しています):

          index <hash>,<hash>..<hash>
          mode <mode>,<mode>..<mode>
          new file mode <mode>
          deleted file mode <mode>,<mode>

     ‘mode <mode>,<mode>..<mode>’ 行は、<mode> の少なくとも1つが他の
     <mode> と異なる場合にのみ表示されます。検出されたコンテンツの移動
     (名前の変更とコピーの検出)に関する情報を含む拡張ヘッダーは、2つの
     <tree-ish> のdiffで機能するように設計されており、合成diff形式では使
     用されません。

  3. その後に2行の from-file/to-file ヘッダーが続きます

          --- a/file
          +++ b/file

     従来の統一diff形式の2行ヘッダーと同様に、 ‘/dev/null’ は、作成また
     は削除されたファイルを通知するために使用されます。

     ただし、 –combined-all-paths オプションが指定されている場合、2行の
     from-file/to-file の代わりに、 N+1 行の from-file/to-file ヘッダー
     が取得されます。ここで、 N はマージコミットの親の数です。

          --- a/file
          --- a/file
          --- a/file
          +++ b/file

     この拡張形式は、名前変更またはコピー検出がアクティブな場合に役立ち
     、別の親のファイルの元の名前を確認できます。

  4. チャンクヘッダーの形式が変更され、誤って ‘patch-p1’ にフィードされ
     るのを防ぎます。合成差分形式は、マージコミットの変更を確認するため
     に作成されたものであり、適用されることを意図したものではありません
     。この変更は、拡張された「インデックス」ヘッダーの変更に似ています:

          @@@ <from-file-range> <from-file-range> <to-file-range> @@@

     合成diff形式のチャンクヘッダーには親の数+1の ‘@’ 文字があります。

   従来の統一diff形式とは異なり、2つのファイルAとBが、 ‘-’ (マイナスは
Aに表示されますが、Bでは削除されます) または ‘+’ (プラスはAにはありませ
んが、Bには追加されます)、または ‘" "’（スペースは変更なし) プレフィック
スを持つ単一の列で表示される場合、この形式は2つ以上のファイル file1,
file2,… を1つのファイルXと比較し、Xが各 fileN とどのように異なるかを示し
ます。ファイルNごとに1つの列が出力行の前に追加され、Xの行が出力行とどの
ように異なるかを示します。

   列Nの ‘-’ 文字は、その行が fileN に表示されているが、結果には表示され
ていないことを意味します。 列Nの ‘+’ 文字は、結果に行が表示され、 fileN
にその行がないことを意味します(つまり、その親の観点から見て行が追加され
たことを示す)。

   上記の出力例では、関数のシグネチャが両方のファイルから見て変更されて
います(したがって、 file1 と file2 の両方から2つの ‘-’ が削除され、さら
に ‘++’ が追加されたため、 file1 と file2 のどちらにも表示されません)。
また、他の8行は file1 と同じですが、 file2 には表示されません(したがって
、接頭辞として ‘+’ が付けられます)。

   ‘git diff-tree -c’ で表示される場合、マージコミットの親をマージ結果と
比較します(つまり、 file1..fileN が親です)。 ‘git diff-files -c’ で表示
される場合、2つの未解決のマージ親を作業ツリーファイルと比較します(つまり
、 file1 はステージ2、別名「私たちのバージョン」、 file2 はステージ3、別
名「彼らのバージョン」です)。

EXAMPLES
********

‘git show v1.0.0’
     タグ ‘v1.0.0’ と、タグが指すオブジェクトを表示します。

‘git show v1.0.0^{tree}’
     タグ ‘v1.0.0’ が指すツリーを表示します。

‘git show -s --format=%s v1.0.0^{commit}’
     タグ ‘v1.0.0’ が指すコミットの件名を表示します。

‘git show next~10:Documentation/README’
     ブランチ ‘next’ の最後から10番目のコミットで最新であったファイル
     ‘Documentation/README’ の内容を表示します。

‘git show master:Makefile master:t/Makefile’
     ブランチ ‘master’ の先頭にあるMakefileの内容を連結して表示します。

DISCUSSION
**********

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

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

   • パス名はUTF-8正規化形式C(UTF-8 normalization form C)でエンコードさ
     れます。これは、ツリーオブジェクト、インデックスファイル、ref名、お
     よびコマンドライン引数、環境変数、構成ファイル( ‘.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. ‘git commit’ と ‘git commit-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
***

Part of the git(1) suite

Name
****

git-sparse-checkout — チェックアウトをパターンのリストで指定されたパスの
セットに減らします

Synopsis
********

     git sparse-checkout <subcommand> [options]

DESCRIPTION
***********

スパース(まばらな)チェックアウト構成を初期化および変更します。これにより
、チェックアウトがパターンのリストで指定されたパスのセットに削減されます
。

   警告: このコマンドは実験的なものです。 その動作、およびスパースチェッ
クアウトの存在下での他のコマンドの動作は、将来変更される可能性があります
。

COMMANDS
********

list
     sparse-checkoutファイルにパターンを記述します。

init
     ‘core.sparseCheckout’ 設定を有効にします。スパースチェックアウトフ
     ァイル(sparse-checkout file)が存在しない場合は、ルートディレクトリ
     内のすべてのファイルに一致し、他のディレクトリには一致しないパター
     ンをスパースチェックアウトファイルに入力すると、Gitによって追跡され
     るすべてのディレクトリが削除されます。 スパースチェックアウトファイ
     ルにパターンを追加して、作業ディレクトリに再設定します。

     他のワークツリーへの干渉を避けるために、最初に
     ‘extensions.worktreeConfig’ 設定を有効にし、ワークツリー固有の構成
     ファイルで必ず ‘core.sparseCheckout’ 設定を設定します。

     ‘--cone’ を指定すると、 ‘core.sparseCheckoutCone’ 設定も設定され、
     限定パターンのセットでパフォーマンスが向上します(下記の「CONE
     PATTERN SET」参照)。

     ‘--[no-]sparse-index’ オプションを使用して、スパースインデックス形
     式の使用を切り替えます。 これにより、インデックスのサイズが縮小され
     、スパースチェックアウト定義とより緊密に連携します。 これにより、
     ‘gits tatus’ や ‘git add’ などのコマンドのパフォーマンスが大幅に向
     上する可能性があります。 注意: この機能はまだ実験段階です。 一部の
     コマンドは、機能と適切に統合されるまで、インデックスがまばら
     (sparse)であると遅くなる可能性があります。

          *Warning*

          スパースインデックスを使用するには、外部ツールでは完全には理解
          できない方法でインデックスを変更する必要があります。 この互換
          性に問題がある場合は、 ‘git sparse-checkout init
          --no-sparse-index’ を実行して、インデックスがまばらにならない
          ように書き換えます。 古いバージョンのGitは、スパースディレクト
          リエントリのインデックス拡張機能を理解せず、それが無効になるま
          でリポジトリとのやり取りに失敗する可能性があります。

set
     setサブコマンドに続く引数のリストとして与えられた一連のパターンをス
     パースチェックアウトファイルに書き込みます。 新しいパターンに一致す
     るように作業ディレクトリを更新します。 core.sparseCheckout 構成設定
     がまだ有効になっていない場合は、有効にします。

     ‘--stdin’ オプションを指定すると、パターンは引数からではなく、改行
     で区切られたリストとして標準入力から読み込まれます。

     ‘core.sparseCheckoutCone’ が有効になっている場合、入力リストはスパ
     ースチェックアウトパターンではなくディレクトリのリストと見なされま
     す。 このコマンドは、スパースチェックアウトファイルにパターンを書き
     込み、それらのディレクトリに含まれるすべてのファイル(と、以下のディ
     レクトリを再帰的にたどります)と、祖先ディレクトリの兄弟であるファイ
     ルを含めます。 入力形式は、 ‘git ls-tree --name-only’ の出力と一致
     します。 これには、二重引用符(‘"’)で始まるパス名をCスタイルの引用符
     で囲まれた文字列として解釈することが含まれます。

add
     スパースチェックアウトファイルを更新して、追加のパターンを含めます
     。 デフォルトでは、これらのパターンはコマンドライン引数から読み取ら
     れますが、 ‘--stdin’ オプションを使用して標準入力から読み取ることが
     できます。 ‘core.sparseCheckoutCone’ が有効になっている場合、指定さ
     れたパターンはsetサブコマンドのようにディレクトリ名として解釈されま
     す。

reapply
     作業ツリーのパスにスパースパターンルールを再適用します。 マージやリ
     ベースなどのコマンドは、作業を行うためのパスを具体化でき(たとえば、
     競合を表示するため)ますが、他のスパースチェックアウトコマンドは、個
     々のファイルをスパース化できない場合があります(たとえば、ステージン
     グされていない変更や競合があるため)。 このような場合、影響を受ける
     パスをクリーンアップした後、(たとえば、競合の解決、変更の取り消しま
     たはコミットなどの)後で ‘git sparse-checkout reapply’ を実行するの
     が理にかなっています。

disable
     ‘core.sparseCheckout’ 構成設定を無効にし、すべてのファイルを含める
     ように作業ディレクトリを復元(restore)します。 その後 _git
     sparse-checkout init_ コマンドで作業ディレクトリが同じ状態に戻る可
     能性があるため、スパースチェックアウトファイルはそのまま残します。

SPARSE CHECKOUT
***************

「sparse checkout」(まばらなチェックアウト)を使用すると、作業ディレクト
リにまばらにデータを入力できます。 skip-worktreeビット
(git-update-index(1) 参照)を使用して、作業ディレクトリ内のファイルを確認
する価値があるかどうかをGitに通知します。 skip-worktreeビットが設定され
ている場合、作業ディレクトリのファイルは無視されます。 Git はこれらのフ
ァイルの内容を入力しないので、多くのファイルがあるリポジトリで作業してい
るが、現在のユーザーにとって重要なものはごくわずかである場合に、まばらな
チェックアウトが役に立ちます。

   ‘$GIT_DIR/info/sparse-checkout’ ファイルは、スキップワークツリー参照
ビットマップを定義するために使用されます。 Gitが作業ディレクトリを更新す
ると、このファイルに基づいてインデックスのスキップワークツリービットが更
新されます。 ファイル内のパターンに一致するファイルは作業ディレクトリに
表示され、残りは表示されません。

   スパースチェックアウト機能を有効にするには、 ‘git sparse-checkout
init’ を実行してシンプルなスパースチェックアウトファイルを初期化し、
‘core.sparseCheckout’ 構成設定を有効にします。 次に、 ‘git
sparse-checkout set’ を実行して、スパースチェックアウトファイルのパター
ンを変更します。

   作業ディレクトリにすべてのファイルを再入力するには、 ‘git
sparse-checkou tdisable’ コマンドを使用します。

FULL PATTERN SET
****************

デフォルトでは、sparse-checkoutファイルは ‘.gitignore’ ファイルと同じ構
文を使用します。

   通常、 ‘$GIT_DIR/info/sparse-checkout’ は、含まれるファイルを指定する
ために使用されますが、ネガティブパターンを使用して、「含まれない」ファイ
ルを指定することもできます。 たとえば、ファイル unwanted を削除するには
以下のようにします:

     /*
     !unwanted

CONE PATTERN SET
****************

フルパターンセットにより、任意のパターンの一致と複雑な包含/除外ルールが
可能になります。 これらにより、インデックスを更新するときに O(オー
;N*M)パターンが一致する可能性があります。ここで、Nはパターンの数、Mはイ
ンデックス内のパスの数です。 このパフォーマンスの問題に対処するために、
‘core.sparseCheckoutCone’ が有効になっている場合は、より制限されたパター
ンセットが許可されます。

   円錐(cone)パターンセットで受け入れられるパターンは以下のとおりです:

  1. *再帰*: (recursive)ディレクトリ内のすべてのパスが含まれます

  2. *親*: (parent)ディレクトリ直下のすべてのファイルが含まれます。

   上記の2つのパターンに加えて、ルートディレクトリ内のすべてのファイルが
含まれていることも期待されます。再帰(recursive)パターンが追加されると、
すべての先行ディレクトリが親(parent)パターンとして追加されます。

   デフォルトでは、 ‘git sparse-checkout init’ を実行すると、ルートディ
レクトリが親パターンとして追加されます。 この時点で、スパースチェックア
ウトファイルには以下のパターンが含まれています:

     /*
     !/*/

   これは、「ルートは全てインクルードするが、ルートの2レベル下は何も含め
ない」という意味です。

   円錐(cone)モードの場合、 ‘git sparse-checkout set’ サブコマンドは、ス
パースチェックアウトパターンのリストではなく、ディレクトリのリストを取得
します。 このモードでは、コマンド ‘git sparse-checkout set A/B/C’ は、デ
ィレクトリ ‘A/B/C’ を再帰パターンとして設定し、ディレクトリ ‘A’ と ‘A/B’
は親パターンとして追加されます。 結果のスパースチェックアウトファイルは
以下のようになります

     /*
     !/*/
     /A/
     !/A/*/
     /A/B/
     !/A/B/*/
     /A/B/C/

   ここでは順番が重要なので、ネガティブなパターンはファイルの下位に表示
されるポジティブなパターンに上書きされます。

   ‘core.sparseCheckoutCone=true’ の場合、Gitはこれらのタイプのパターン
を期待してスパースチェックアウトファイルをパースします。 パターンが一致
しない場合、Gitは警告を発します。 パターンが期待される形式と一致する場合
、Gitはより高速なハッシュベースのアルゴリズムを使用して、スパースチェッ
クアウトに含めるモノを計算します。

   円錐(cone)モードの場合、 ‘git sparse-checkout list’ サブコマンドは、
再帰(recursive)パターンを定義するディレクトリを一覧表示します。 上記のス
パースチェックアウトファイルの例の場合、出力は以下のようになります:

     $ git sparse-checkout list
     A/B/C

   ‘core.ignoreCase=true’ の場合、パターンマッチングアルゴリズムは大文字
と小文字を区別しないチェックを使用します。 これにより、 ‘git
sparse-checkout set’ コマンドのファイル名が一致しない状況が修正され、作
業ディレクトリに期待される円錐(cone)が反映されます。

   円錐(cone)モードでスパースチェックアウトパターンを変更すると、Gitはス
パースチェックアウト円錐(cone)内にない追跡中の各ディレクトリを検査して、
追跡されていないファイルが含まれているかどうかを確認します。
‘.gitignore’ パターンが原因でこれらのファイルがすべて無視された場合、デ
ィレクトリは削除されます。 そのディレクトリ内の追跡されていないファイル
のいずれかが無視されない場合、そのディレクトリ内で削除は発生せず、警告メ
ッセージが表示されます。 これらのファイルが重要な場合は、スパースチェッ
クアウト定義をリセットして含まれるようにし、 ‘git add’ と ‘git commit’ を
使用してファイルを保存し、残りのファイルを手動で削除して、Gitが最適に動
作できるようにします。

SUBMODULES
**********

あなたのリポジトリに1つ以上のサブモジュールが含まれている場合、サブモジ
ュールは ‘git submodule’ コマンドとの相互作用に基づいて入力されます。 具
体的には、 ‘git submodule init -- <path>’ は ‘<path>’ のサブモジュールが
存在することを確認し、 ‘git submodule deinit [-f] -- <path>’ は ‘<path>’
のサブモジュールのファイルを削除します(追跡されていないファイル、コミッ
トされていない変更、プッシュされていない履歴を含む)。sparse-checkoutが作
業ツリーからファイルを削除するが、インデックスにエントリを残す方法と同様
に、初期化されていないサブモジュールは作業ディレクトリから削除されますが
、インデックスにはエントリがあります。

   サブモジュールにはプッシュされていない変更または追跡されていないファ
イルがある可能性があるため、それらを削除するとデータが失われる可能性があ
ります。 したがって、スパース 包含/除外 ルールを変更しても、すでにチェッ
クアウトされているサブモジュールが作業コピーから削除されることはありませ
ん。 別の言い方をすれば、サブモジュールを削除または追加するブランチを切
り替えても、 ‘checkout’ によってサブモジュールが自動的に削除または初期化
されないのと同様に、 ‘sparse-checkout’ を使用して「興味深い」ファイルの
範囲を縮小または拡大してもサブモジュールの自動的な非初期化または初期化は
発生しません。

   さらに、上記の事実は、「追跡された」ファイルが作業コピーに存在しない
可能性に複数の理由があることを意味します。スパースチェックアウトからのス
パースパターンアプリケーション、およびサブモジュールの初期化状態です。 し
たがって、作業コピー内の追跡されたファイルで機能する ‘git grep’ のような
コマンドは、これらの制限のいずれかまたは両方によって制限される結果を返す
可能性があります。

SEE ALSO
********

git-read-tree(1) gitignore(5)

GIT
***

Part of the git(1) suite

Name
****

git-stage — ファイルの内容をステージング領域に追加

Synopsis
********

     git stage args…

DESCRIPTION
***********

これは git-add(1) の同義語です。 git-add(1) の文書を参照してください。

GIT
***

Part of the git(1) suite

Name
****

git-stash — 汚い作業ディレクトリの変更を隠します

Synopsis
********

     git stash list [<log-options>]
     git stash show [-u|–include-untracked|–only-untracked] [<diff-options>] [<stash>]
     git stash drop [-q|–quiet] [<stash>]
     git stash ( pop | apply ) [–index] [-q|–quiet] [<stash>]
     git stash branch <branchname> [<stash>]
     git stash [push [-p|–patch] [-k|–[no-]keep-index] [-q|–quiet]
                  [-u|–include-untracked] [-a|–all] [-m|–message <message>]
                  [–pathspec-from-file=<file> [–pathspec-file-nul]]
                  [–] [<pathspec>…]]
     git stash clear
     git stash create [<message>]
     git stash store [-m|–message <message>] [-q|–quiet] <commit>

DESCRIPTION
***********

作業ディレクトリとインデックスの現在の状態を記録したいが、クリーンな作業
ディレクトリに戻りたい場合は、‘git stash’ を使用します。 このコマンドは
、ローカルの変更を保存し、作業ディレクトリを元に戻して(revert)、‘HEAD’ コ
ミットに一致させます。

   このコマンドによってスタッシュされた変更は、 ‘git stash list’ で一覧
表示され、 ‘git stash show’ で調査され、 ‘git stash apply’ で復元されま
す(それは別のコミットの上にある可能性があります)。 引数なしで ‘git
stash’ を呼び出すことは、 ‘git stash push’ と同等です。 スタッシュはデフ
ォルトで ‘WIP on 'branchname' ...’ としてリストされますが、作成するとき
にコマンドラインでより説明的なメッセージを与える事ができます。

   作成した 最新のスタッシュ は ‘refs/stash’ に保存されます。 古いスタッ
シュはこのリファレンスのreflogにあり、通常のreflog構文を使用して名前を付
けることができます(たとえば、 ‘stash@{0}’ は最後に作成されたスタッシュで
、 ‘stash@{1}’ はその前のスタッシュです。 ‘stash@{2.hours.ago}’ も可能で
す)。 スタッシュは、スタッシュインデックスのみを指定することによって参照
することもできます(たとえば、整数 ‘n’ は ‘stash@{n}’ と同等です)。

COMMANDS
********

‘push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--pathspec-from-file=<file> [--pathspec-file-nul]] [--] [<pathspec>...]’
     あなたのローカルの変更を新しい「スタッシュエントリ」に保存し、それ
     らをHEADに巻き戻します(作業ツリー内とインデックス内で)。 <message>
     の部分はオプションであり、スタッシュ状態と共に説明を提供します。

     スナップショットをすばやく作成するために、「push」を省略できます。
     このモードでは、サブコマンドのスペルミスで不要なスタッシュエントリ
     を作成するのを防ぐための非オプション引数は許可されていません。 これ
     に対する2つの例外は、 ‘stash push -p’ のエイリアスとして機能する
     ‘stash -p’ と、曖昧さ解消のために二重ハイフン ‘--’ の後ろで許可され
     るpathspec要素です。

‘save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]’
     このオプションは廃止され、 ‘git stash push’ が採用されました。
     pathspecをとることができないという点で「stash push」とは異なります
     。 代わりに、オプション以外のすべての引数が連結されて、スタッシュメ
     ッセージが形成されます。

list [<log-options>]
     現在持っているスタッシュエントリを一覧表示します。 各「スタッシュエ
     ントリ」は、その名前(たとえば、 ‘stash@{0}’ は最新のエントリ、
     ‘stash@{1}’ はその前のエントリ、など)と、 エントリが作成されたとき
     の現在のブランチの名前と、エントリが基づいていたコミットの簡単な説
     明と、ともに一覧表示されます。

          stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
          stash@{1}: On master: 9cc0589... Add git-stash

     このコマンドは、 ‘git log’ コマンドに適用可能なオプションを使用して
     、表示内容と方法を制御します。 git-log(1) を参照してください。

‘show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]’
     スタッシュエントリに記録された変更を、スタッシュされたコンテンツと
     スタッシュエントリが最初に作成されたときのコミットとの差分として表
     示します。 デフォルトでは、コマンドはdiffstatを表示しますが、 ‘git
     diff’ として認識される任意の形式を受け入れます(たとえば、パッチ形式
     で2番目に新しいエントリを表示するには ‘git stash show -p
     stash@{1}’)。 ‘<diff-option>’ が指定されていない場合、デフォルトの
     動作は ‘stash.showStat’ および ‘stash.showPatch’ 構成変数によって与
     えられます。 ‘stash.showIncludeUntracked’ を使用して、
     ‘--include-untracked’ がデフォルトで有効になっているかどうかを設定
     することもできます。

‘pop [--index] [-q|--quiet] [<stash>]’
     スタッシュリストから単一のスタッシュ状態を削除し、現在の作業ツリー
     状態の上に適用します。つまり、 ‘git stash push’ の逆の操作を実行し
     ます。 作業ディレクトリはインデックスと一致している必要があります。

     状態の適用は、競合で失敗する可能性があります。 この場合、スタッシュ
     リストからは削除されません。 競合を手動で解決し、後で手動で ‘git
     stash drop’ を呼び出す必要があります。

‘apply [--index] [-q|--quiet] [<stash>]’
     ‘pop’ と同様ですが、スタッシュリストから状態を削除しないでください
     。 ‘pop’ とは異なり 、‘<stash>’ は、‘stash push’ または ‘stash
     create’ によって作成されたコミットのように見える任意のコミットです
     。

branch <branchname> [<stash>]
     ‘<stash>’ が元々作成された時のコミットから ‘<branchname>’ という名
     前の新しいブランチを作成してチェックアウトし、 ‘<stash>’ に記録され
     た変更を新しい作業ツリーとインデックスに適用します。 それが成功し、
     ‘<stash>’ が ‘stash@{<revision>}’ 形式の参照である場合、 ‘<stash>’
     を削除します。

     これは、あなたが ‘git stash push’ を実行したブランチがとても変更さ
     れていて、‘git stash apply’ が競合のために失敗した場合に便利です。
     スタッシュエントリは、 ‘git stash’ が実行されたときにHEADであったコ
     ミットの上に適用(apply)されるため、競合することなく元のスタッシュさ
     れた状態を復元します。

clear
     すべてのスタッシュエントリを削除します。 これらのエントリは刈り込み
     の対象となり、回復できない可能性があることに注意してください(可能な
     戦略については、下記「Examples」を参照してください)。

‘drop [-q|--quiet] [<stash>]’
     スタッシュエントリリストからスタッシュエントリを1つ削除します。

create
     ref名前空間のどこにも保存せずに、スタッシュエントリ(通常のコミット
     オブジェクト)を作成し、そのオブジェクト名を返します。 これは、スク
     リプトで役立つことを目的としています。 おそらくあなたがこのコマンド
     を使用することはありません。 上記「push」を参照してください。

store
     ‘git stash create’ を介して作成された特定のスタッシュ(これは宙ぶら
     りんマージコミット(dangling merge commit)です)をスタッシュrefに格納
     し、スタッシュreflogを更新します。 これは、スクリプトで役立つことを
     目的としています。 おそらく、あなたはこのコマンドを使用することはあ
     りません。 上記「push」を参照してください。

OPTIONS
*******

‘-a’
‘--all’
     このオプションは、 ‘push’ および ‘save’ コマンドでのみ有効です。

     無視され追跡されていないすべてのファイルもスタッシュしてから、 ‘git
     clean’ でクリーンアップします。

‘-u’
‘--include-untracked’
‘--no-include-untracked’
     ‘push’ および ‘save’ コマンドと一緒に使用すると、追跡されていないす
     べてのファイルもスタッシュし、 ‘git clean’ でクリーンアップします。

     ‘show’ コマンドと一緒に使用すると、diffの一部としてスタッシュエント
     リの追跡されていないファイルを表示します。

‘--only-untracked’
     このオプションは、 ‘show’ コマンドでのみ有効です。

     diffの一部として、スタッシュエントリ内の、追跡されていないファイル
     (untracked files)のみを表示します。

‘--index’
     このオプションは、 ‘pop’ および ‘apply’ コマンドにのみ有効です。

     作業ツリーの変更だけでなく、インデックスの変更も復元しようと試みま
     す。 ただし、競合がある場合(競合がインデックスに保存されているため
     、元の変更を適用できなくなる)、これは失敗する可能性があります。

‘-k’
‘--keep-index’
‘--no-keep-index’
     このオプションは、 ‘push’ および ‘save’ コマンドでのみ有効です。

     インデックスにすでに追加されているすべての変更はそのまま残ります。

‘-p’
‘--patch’
     このオプションは、 ‘push’ および ‘save’ コマンドでのみ有効です。

     HEADと作業ツリー間のdiffから、スタッシュするハンクを対話的に選択し
     ます。 スタッシュエントリは、リポジトリのインデックス状態と同じにな
     るように構築され、そのワークツリーには、対話的に選択した変更点のみ
     が含まれます。 そして、選択した変更はワークツリーから巻き戻されます
     。 ‘--patch’ モードの操作方法については、 git-add(1) の「
     Interactive Mode」セクションを参照してください。

     ‘--patch’ オプションは ‘--keep-index’ の指定を含んでいます。あなた
     は ‘--no-keep-index’ を使用してこれを上書きできます。

‘--pathspec-from-file=<file>’
     このオプションは、 ‘push’ コマンドにのみ有効です。

     pathspecは、コマンドライン引数の代わりに ‘<file>’ で渡されます。
     ‘<file>’ が正確に ‘-’ の場合、標準入力が使用されます。 pathspec要素
     はLFまたはCR/LFで区切られます。 pathspec要素は、構成変数
     ‘core.quotePath’ にて説明されているようにクォートできます
     (git-config(1) 参照)。 ‘--pathspec-file-nul’ および グローバルの
     ‘--literal-pathspecs’ も参照してください。

‘--pathspec-file-nul’
     このオプションは、 ‘push’ コマンドにのみ有効です。

     このオプションは ‘--pathspec-from-file’ でのみ意味があります。
     pathspec要素はNUL文字で区切られ、他のすべての文字は文字通りに解釈さ
     れます(改行と引用符を含む)。

‘-q’
‘--quiet’
     このオプションは、 ‘apply’, ‘drop’, ‘pop’, ‘push’, ‘save’, ‘store’
     コマンドにのみ有効です。

     静かにして、フィードバックメッセージを抑制します。

‘--’
     このオプションは、 ‘push’ コマンドにのみ有効です。

     曖昧さ解消の目的のために pathspec をオプションから分離します。

<pathspec>…
     このオプションは、 ‘push’ コマンドにのみ有効です。

     新しいスタッシュエントリは、pathspecに一致するファイルについてのみ
     変更された状態を記録します。 次に、インデックスエントリと作業ツリー
     ファイルは、これらのファイルについてのみHEADの状態に巻き戻されされ
     、pathspecに一致しないファイルはそのまま残ります。

     詳細については、 gitglossary(7) の「pathspec」エントリを参照してく
     ださい。

<stash>
     このオプションは、 ‘apply’, ‘branch’, ‘drop’, ‘pop’, ‘show’ コマン
     ドにのみ有効です。

     ‘stash@{<revision>}’ 形式の参照。 ‘<stash>’ が指定されていない場合
     、最新のスタッシュ(‘stash@{0}’)を想定します。

DISCUSSION
**********

スタッシュエントリーは、作業ディレクトリの状態を記録するツリーを持つコミ
ットとして表現され、その最初の親はエントリーが作成された ‘HEAD’ でのコミ
ットとなります。 2番目の親のツリーは、エントリーが作成されたときのインデ
ックスの状態を記録しており、‘HEAD’ コミットの子として作られます。 祖先の
グラフは以下のようになります:

            .----W
           /    /
     -----H----I

   ここで、 ‘H’ は ‘HEAD’ コミット、 ‘I’ はインデックスの状態を記録する
コミット、 ‘W’ は作業ツリーの状態を記録するコミットです。

EXAMPLES
********

Pulling into a dirty tree
     あなたが何かしている最中、あなたがしていることにおそらく関連してい
     るかもしれないアップストリームの変更があったことを知りました。 あな
     たのローカルの変更がアップストリームの変更と競合しない場合は、単純
     に ‘git pull ‘で先に進むことができます。

     しかしながら、あなたのローカルの変更がアップストリームの変更と競合
     し、 ‘git pull’ が変更の上書きを拒否する場合があります。 このような
     場合、以下のように、変更をスタッシュし、プルしてから、スタッシュ解
     除できます:

          $ git pull
           ...
          file foobar not up to date, cannot merge.
          $ git stash
          $ git pull
          $ git stash pop

Interrupted workflow
     あなたが何かやってる真っ最中に、上司がやって来て、あなたにすぐに何
     かを直すように要求します。 従来は、一時的なブランチにコミットして変
     更を保存し、元のブランチに戻って以下のように緊急修正を行っていまし
     た:

          # ... hack hack hack ...
          $ git switch -c my_wip
          $ git commit -a -m "WIP"
          $ git switch master
          $ edit emergency fix
          $ git commit -a -m "Fix in a hurry"
          $ git switch my_wip
          $ git reset --soft HEAD^
          # ... continue hacking ...

     ‘git stash’ を使用することで上記を以下のように簡略化できます:

          # ... hack hack hack ...
          $ git stash
          $ edit emergency fix
          $ git commit -a -m "Fix in a hurry"
          $ git stash pop
          # ... continue hacking ...

Testing partial commits
     ワークツリーの変更から2つ以上のコミットを行い、コミットする前に各変
     更をテストする場合は、 ‘git stash push --keep-index’ を使用できます
     :

          # ... hack hack hack ...
          $ git add --patch foo            # add just first part to the index
          $ git stash push --keep-index    # save all other changes to the stash
          $ edit/build/test first part
          $ git commit -m 'First part'     # commit fully tested change
          $ git stash pop                  # prepare to work on all other changes
          # ... repeat above five steps until one commit remains ...
          $ edit/build/test remaining parts
          $ git commit foo -m 'Remaining parts'

誤ってクリアまたはドロップされたスタッシュエントリの回復
     誤ってスタッシュエントリをドロップまたはクリアした場合、通常の安全
     メカニズムでは回復できません。 ただし、以下の呪文を試して、リポジト
     リに残っているが到達できなくなったスタッシュエントリのリストを取得
     できます:

          git fsck --unreachable |
          grep commit | cut -d\  -f3 |
          xargs git log --merges --no-walk --grep=WIP

SEE ALSO
********

git-checkout(1), git-commit(1), git-reflog(1), git-reset(1),
git-switch(1)

GIT
***

Part of the git(1) suite

Name
****

git-status — 作業ツリーの状態を表示します

Synopsis
********

     git status [<options>…] [–] [<pathspec>…]

DESCRIPTION
***********

インデックスファイルと現在のHEADコミットの間に違いがあるパスや、作業ツリ
ーとインデックスファイルの間に違いがあるパスや、Gitによって追跡されない
(かつ gitignore(5) によって無視されない)作業ツリー内のパスを表示します。
1つ目は、 ‘git commit’ を実行してコミットすることになるものです。 2番目
と3番目は、 ‘git commit’ を実行する前に ‘git add’ を実行することでコミッ
ト可能になるものです。

OPTIONS
*******

‘-s’
‘--short’
     短い形式で出力を提供します。

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

‘--show-stash’
     現在スタッシュされているエントリの数を表示します。

‘--porcelain[=<version>]’
     スクリプトの出力を解析しやすい形式(easy-to-parse)で提供します。 こ
     れは短い出力に似ていますが、Gitのバージョン間で、ユーザー構成に関係
     なく安定しています。 詳細下記。

     versionパラメーターは、フォーマットバージョンを指定するために使用さ
     れます。 これはオプションであり、デフォルトでオリジナルバージョンの
     「v1」形式になります。

‘--long’
     長い形式で出力します。 これがデフォルトです。

‘-v’
‘--verbose’
     変更されたファイルの名前に加えて、コミットされるようにステージング
     されたテキストの変更も表示します(つまり、 ‘git diff --cached’ の出
     力風です)。 ‘-v’ が2回指定されている場合は、まだステージングされて
     いない作業ツリーの変更も表示します(つまり、 ‘git diff’ の出力風です
     )。

‘-u[<mode>]’
‘--untracked-files[=<mode>]’
     追跡されていないファイル(untracked files)を表示します。

     modeパラメーターは、追跡されていないファイルの処理を指定するために
     使用されます。 これはオプションです。デフォルトは ‘all’ であり、指
     定する場合は、オプションに串刺しする必要があります(たとえば、 ‘-u
     no’ ではなく ‘-uno’)。

     可能なオプションは以下のとおりです

          ‘no’
               追跡されていないファイル(untracked files)を表示します。

          ‘normal’
               追跡されていないファイルとディレクトリを表示します。

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

     ‘-u’ オプションを使用しない場合、追跡されていないファイルとディレク
     トリが表示され(つまり、 ‘normal’ を指定するのと同じ)、新しく作成さ
     れたファイルを追加するのを忘れないようにします。 ファイルシステムで
     、追跡されていないファイルを見つけるには余分な作業が必要なため、こ
     のモードは大きな作業ツリーでは時間がかかる場合があります。 サポート
     されている場合は、追跡されていないキャッシュと分割インデックスを有
     効にすることを検討してください(‘git update-index --untracked-cache’
     と ‘git update-index --split-index’ を参照)。そうでない場合は、
     ‘no’ を使用して、追跡されていないファイルを表示せずに ‘git status’
     からより迅速に返ることができます。

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

‘--ignore-submodules[=<when>]’
     変更を探すときは、サブモジュールへの変更を無視します。 <when> は、
     「none」、「untracked」、「dirty」、「all」のいずれかになります。「
     all」がデフォルトです。 「none」を使用すると、追跡されていないファ
     イルまたは変更されたファイルが含まれている場合、またはそのHEADがス
     ーパープロジェクトに記録されているコミットと異なる場合にサブモジュ
     ールが変更されたと見なされ、 git-config(1) または gitmodules(5) の
     「ignore」オプションの設定をオーバーライドするために使用できます。
     「untracked」が使用されている場合、サブモジュールには追跡されていな
     いコンテンツのみが含まれている場合、サブモジュールはダーティとは見
     なされません(ただし、変更されたコンテンツはスキャンされます)。 「
     dirty」を使用すると、サブモジュールの作業ツリーへのすべての変更が無
     視され、スーパープロジェクトに格納されているコミットへの変更のみが
     表示されます(これは1.7.0より前の振る舞いでした)。 「all」を使用する
     と、サブモジュールへのすべての変更が非表示になります(また、構成オプ
     ション ‘status.submoduleSummary’ が設定されている場合、サブモジュー
     ルの要約の出力が抑制されます)。

‘--ignored[=<mode>]’
     無視されたファイル(ignored files)も表示します。

     modeパラメーターは、無視されたファイル(ignored files)の処理を指定す
     るために使用されます。 これはオプションです。デフォルトは
     ‘traditional’ です。

     可能なオプションは以下のとおりです

          ‘traditional’
               ‘--untracked-files=all’ が指定されていない限り、無視され
               たファイルとディレクトリを表示します。指定されている場合
               、無視されたディレクトリ内の個々のファイルが表示されます
               。

          ‘no’
               無視されたファイル(ignored files)を表示しません。

          ‘matching’
               無視パターンにマッチする、無視されたファイルとディレクト
               リを表示します。

     _matching_ モードが指定されている場合、無視されたパターンに明示的に
     マッチするパスが表示されます。 ディレクトリが無視パターンにマッチす
     る場合、それは表示されますが、無視されたディレクトリに含まれるパス
     は表示されません。 ディレクトリが無視パターンにマッチしないが、すべ
     てのコンテンツが無視される場合、ディレクトリは表示されませんが、す
     べてのコンテンツが表示されます。

‘-z’
     LFではなくNULでエントリを終了します。 これは、他の形式が指定されて
     いない場合、 ‘--porcelain=v1’ 出力形式の指定を含んでいます。

‘--column[=<options>]’
‘--no-column’
     追跡されていないファイルを列(columns)に表示します。 オプションの構
     文については、構成変数 ‘column.status’ を参照してください。 オプシ
     ョンのない ‘--column’ と ‘--no-column’ は、それぞれ ‘always’ と
     ‘never’ と同等です。

‘--ahead-behind’
‘--no-ahead-behind’
     アップストリームブランチに関連するブランチの詳細な 先行(ahead)/遅延
     (behind) カウントを、表示するか、または、表示しない。 デフォルトは
     trueです。

‘--renames’
‘--no-renames’
     ユーザー構成に関係なく、名前変更検出の オン/オフ を切り替えます。
     git-diff(1) の ‘--no-renames’ も参照してください。

‘--find-renames[=<n>]’
     名前変更の検出をオンにし、オプションで類似性のしきい値を設定します
     。 git-diff(1) の ‘--find-renames’ も参照してください。

<pathspec>…
     gitglossary(7) の「pathspec」エントリを参照してください。

OUTPUT
******

このコマンドの出力は、コミットテンプレートのコメントとして使用するように
設計されています。 デフォルトの長い形式は、人間が読める形式で、冗長で説
明的なものになるように設計されています。 その内容と形式は予告なく変更さ
れる事があります。

   他の多くのGitコマンドとは異なり、出力に記載されているパスは、サブディ
レクトリで作業している場合、現在のディレクトリを基準にして作成されます
(これは、カット＆ペーストを支援するための意図的なものです)。 下記
status.relativePaths 構成オプションを参照してください。

Short Format
============

短い形式では、各パスのステータスがこれらの形式の1つとして表示されます

     XY PATH
     XY ORIG_PATH -> PATH

   ここで、 ‘ORIG_PATH’ は、名前が 変更/コピー されたコンテンツの出所で
す。 ‘ORIG_PATH’ は、エントリの名前が変更またはコピーされた場合にのみ表
示されます。 ‘XY’ は2文字のステータスコードです。

   フィールド(‘->’ を含む)は、単一のスペースで互いに区切られています。 フ
ァイル名に空白またはその他の印刷不可能な文字が含まれている場合、そのフィ
ールドはC文字列リテラルの方法でクォートされます。ASCII二重引用符(34)キャ
ラクタ(‘"’)で囲まれ、内部の特殊文字はバックスラッシュ(‘\’)でエスケープさ
れます。

   この形式を使用して表示される状態には3つの異なるタイプがあり、それぞれ
が「XY」構文を異なる方法で使用します:

   • マージが発生していてマージが成功した場合、またはマージ状況以外の場
     合、 ‘X’ はインデックスのステータスを示し、‘Y’ は作業ツリーのステー
     タスを示します。

   • マージの競合が発生し、まだ解決されていない場合、 ‘X’ と ‘Y’ は、共
     通の祖先と比較して、マージの各ヘッドによって導入された状態を示しま
     す。 これらのパスは「unmerged」と言われます。

   • パスが追跡されていない場合、 ‘X’ と ‘Y’ はインデックスで不明
     (unknown)であるため、常に同一です。 ‘??’ は追跡されていないパスに使
     用されます。 ‘--ignored’ が使用されない限り、無視されたファイルはリ
     ストされません。 ‘--ignored’ が使用された場合、無視されたファイルは
     ‘!!’ で示されます。

   ここでのマージという用語には、デフォルトの ‘–merge‘戦略を使用したリベ
ースや、チェリーピックや、マージ機構を使用したその他のものも含まれること
に注意してください。

   以下の表では、これら3つのクラスが別々のセクションに示されています。こ
れらの文字は、追跡されたパスを示す最初の2つのセクションの ‘X’ フィールド
と ‘Y’ フィールドに使用されます。

   • " " = 変更されていない

   • ‘M’ = 変更された

   • ‘A’ = 追加された

   • ‘D’ = 削除された

   • ‘R’ = 名前変更された

   • ‘C’ = コピーされた

   • ‘U’ = 更新されたがマージされていない

     X          Y     Meaning
     -------------------------------------------------
              [AMD]   not updated
     M        [ MD]   updated in index
     A        [ MD]   added to index
     D                deleted from index
     R        [ MD]   renamed in index
     C        [ MD]   copied in index
     [MARC]           index and work tree matches
     [ MARC]     M    work tree changed since index
     [ MARC]     D    deleted in work tree
     [ D]        R    renamed in work tree
     [ D]        C    copied in work tree
     -------------------------------------------------
     D           D    unmerged, both deleted
     A           U    unmerged, added by us
     U           D    unmerged, deleted by them
     U           A    unmerged, added by them
     D           U    unmerged, deleted by us
     A           A    unmerged, both added
     U           U    unmerged, both modified
     -------------------------------------------------
     ?           ?    untracked
     !           !    ignored
     -------------------------------------------------

サブモジュールにはより多くの状態があり、代わりのレポートがあります

     M
          サブモジュールには、インデックスに記録されているものとは異なる
          HEADがあります

     m
          サブモジュールに変更されたコンテンツがあります

     ?
          サブモジュールに追跡されていないファイル(untracked files)があ
          ります

   これは、サブモジュール内の、変更されたコンテンツ、または、追跡されて
いないファイルは、コミットを準備するためにスーパープロジェクトの ‘git
add’ を介して追加できないためです。

   ‘m’ と ‘?’ は再帰的に適用されます。 たとえば、サブモジュール内のネス
トされたサブモジュールに、追跡されていないファイルが含まれている場合、こ
れは同様に ‘?’ として報告されます。

   ‘-b’ が使用されている場合、短い形式のステータスの前に行が表示されます

     ## branchname tracking info

Porcelain Format Version 1
==========================

バージョン 1 の磁器形式(porcelain format)は短い形式に似ていますが、Gitバ
ージョン間またはユーザー構成に基づいて後方互換性のない方法で変更されない
ことが保証されています。 これにより、スクリプトによる解析に最適です。 上
記の短い形式の説明では、いくつかの例外を除いて、磁器形式についても説明し
ています:

  1. ユーザーの color.status 構成は尊重されません。 色は常にオフになりま
     す。

  2. ユーザーの status.relativePaths 構成は尊重されません。 表示されるパ
     スは、常にリポジトリルートを基準にしています。

   機械的パースで推奨される 代替 ‘-z’ 形式もあります。 この形式では、ス
テータスフィールドは同じですが、他のいくつかの点が異なります。 まず、名
前変更エントリから ‘->’ が省略され、フィールドの順序が逆になります(たと
えば、‘from -> to’ は ‘to from’ になります)。 次に、 NUL(ASCII 0)が各フ
ァイル名の後に続き、スペースをフィールド区切り文字として置き換え、改行で
終了します(ただし、スペースはステータスフィールドを最初のファイル名から
分離します)。 第三に、特殊文字を含むファイル名は特別にフォーマットされま
せん。 クォートや、バックスラッシュのエスケープは実行されません。

   サブモジュールの変更は、 ‘m’ または 単一の ‘?’ ではなく、変更された
‘M’ として報告されます。

Porcelain Format Version 2
==========================

バージョン2形式では、ワークツリーの状態と変更されたアイテムに関するより
詳細な情報が追加されます。 バージョン2では、パースが容易なオプションのヘ
ッダーの拡張可能なセットも定義されています。

   ヘッダー行は ‘#’ で始まり、特定のコマンドライン引数に応じて追加されま
す。 パーサーは、認識できないヘッダーを無視する必要があります。

Branch Headers
--------------

‘--branch’ を指定すると、一連のヘッダー行に現在のブランチに関する情報が
出力されます。

     Line                                     Notes
     ------------------------------------------------------------
     # branch.oid <commit> | (initial)        Current commit.
     # branch.head <branch> | (detached)      Current branch.
     # branch.upstream <upstream_branch>      If upstream is set.
     # branch.ab +<ahead> -<behind>           If upstream is set and
                                              the commit is present.
     ------------------------------------------------------------

Changed Tracked Entries
-----------------------

ヘッダーに続いて、追跡されたエントリの一連の行が印刷されます。 変更の種
類に応じて、3つの異なる行形式のいずれかを使用してエントリを記述すること
ができます。 追跡されたエントリは、未定義の順序で印刷されます。 パーサー
は、3つの行タイプを任意の順序で混合できるようにする必要があります。

   通常の、変更されたエントリの形式は以下のとおりです:

     1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>

   名前変更またはコピーされたエントリの形式は以下のとおりです:

     2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>

     Field       Meaning
     --------------------------------------------------------
     <XY>        short formatで記述されたステージされたXY値と
                 ステージされていないXY値を含む2文字のフィー
                 ルドで、変更されていない場合は空白
                 ではなく "." で示されます。
     <sub>       サブモジュールの状態説明の4文字フィールド。
                 "N..." when the entry is not a submodule.
                 "S<c><m><u>" when the entry is a submodule.
                 <c> is "C" if the commit changed; それ以外 ".".
                 <m> is "M" if it has tracked changes; それ以外 ".".
                 <u> is "U" if there are untracked changes; それ以外 ".".
     <mH>        The octal file mode in HEAD.
     <mI>        The octal file mode in the index.
     <mW>        The octal file mode in the worktree.
     <hH>        The object name in HEAD.
     <hI>        The object name in the index.
     <X><score>  The rename or copy score (移動またはコピーのソースと
                 ターゲット間の類似性のパーセンテージを示します)
                 例 "R100" or "C75".
     <path>      The pathname.  In a renamed/copied entry, this
                 is the target path.
     <sep>       When the `-z` option is used, the 2 pathnames are separated
                 with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
                 byte separates them.
     <origPath>  HEADでのコミットまたはインデックス内のパス名。
                 これは、名前が 変更された/コピーされた エントリに
                 のみ存在し、名前が変更された/コピーされた
                 コンテンツがどこから来たかを示します。
     --------------------------------------------------------

   アンマージエントリの形式は以下のとおりです。 最初の文字は、通常の変更
されたエントリと区別するための「u」です。

     u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>

     Field       Meaning
     --------------------------------------------------------
     <XY>        A 2 character field describing the conflict type
                 as described in the short format.
     <sub>       A 4 character field describing the submodule state
                 as described above.
     <m1>        The octal file mode in stage 1.
     <m2>        The octal file mode in stage 2.
     <m3>        The octal file mode in stage 3.
     <mW>        The octal file mode in the worktree.
     <h1>        The object name in stage 1.
     <h2>        The object name in stage 2.
     <h3>        The object name in stage 3.
     <path>      The pathname.
     --------------------------------------------------------

Other Items
-----------

追跡されたエントリに続いて(そして要求された場合)、ワークツリーで見つかっ
た追跡されてない項目と無視される項目に対して、一連の行を出力します。

   追跡されていないアイテムの形式は以下のとおりです:

     ? <path>

   無視されるアイテムの形式は以下のとおりです:

     ! <path>

パス名の形式に関する注意と -z
-----------------------------

‘-z’ オプションを指定すると、パス名はクォートされずにそのまま出力され、
行はNUL(ASCII 0x00)バイトで終了します。

   ‘-z’ オプションを指定しない場合、構成変数 ‘core.quotePath’ で説明され
ているように、「異常な」文字を含むパス名がクォートされます(git-config(1)
を参照)。

CONFIGURATION
*************

このコマンドは、 ‘color.status’ (または ‘status.color’ — 同じことを意味
し、‘status.color’ は下位互換性のために保持されます)と
‘color.status.<slot>’ 構成変数を尊重して出力を色付けします。

   構成変数 ‘status.relativePaths’ がfalseに設定されている場合、表示され
るすべてのパスは、現在のディレクトリではなく、リポジトリルートを基準にし
ています。

   ‘status.submoduleSummary’ がゼロ以外の数値またはtrue(それぞれ -1 また
は 無制限の数値 と同じ)に設定されている場合、サブモジュールの概要が長い
形式で有効になり、変更されたサブモジュールのコミットの概要が表示されます
(git-submodule(1) の ‘--summary-limit’ 参照)。 ‘diff.ignoreSubmodules’ が
‘all’ に設定されている場合、または ‘submodule.<name>.ignore=all’ である
サブモジュールに対してのみ、statusコマンドからの要約出力が抑制されること
に注意してください。 無視されたサブモジュールの概要も表示するには、
‘--ignore-submodules=dirty’ マンドラインオプションまたは ‘git submodule
summary’ コマンドを使用できます。これは同様の出力を表示しますが、これら
の設定を尊重しません。

BACKGROUND REFRESH
******************

デフォルトでは、 ‘git status’ は自動的にインデックスを更新し、作業ツリー
からキャッシュされた統計情報を更新し、結果を書き出します。 更新されたイ
ンデックスを書き出すことは、厳密には必要ではない最適化です(‘status’ はそ
れ自体の値を計算しますが、それらを書き出すことは、後続のプログラムが計算
を繰り返さないようにするためだけです)。 ‘status’ がバックグラウンドで実
行されると、書き込み中に保持されたロックが他の同時プロセスと競合し、それ
らが失敗する可能性があります。 バックグラウンドで ‘status’ を実行してい
るスクリプトは、 ‘git --no-optional-locks status’ の使用を検討する必要が
あります(詳細については、 git(1) を参照してください)。

SEE ALSO
********

gitignore(5)

GIT
***

Part of the git(1) suite

Name
****

git-stripspace — 不要な空白(whitespace)を削除します

Synopsis
********

     git stripspace [-s | –strip-comments]
     git stripspace [-c | –comment-lines]

DESCRIPTION
***********

コミットメッセージ・メモ・タグ・ブランチの説明などのテキストを標準の入力
から読み取り、Gitで使用されている作法でクリーンアップします。

   引数なしの場合、この作法は以下のようになります:

   • 全ての行の末尾の空白(whitespace)を取り除く

   • 複数の連続する空行を1つの空行に折りたたむ

   • 入力の最初と最後から空行を削除

   • 必要に応じて、欠落している _\n_ を最後の行に追加します。

   入力がすべて空白文字(whitespace characters)で構成されている場合、出力
は生成されません。

   *注意* これはメタデータのクリーニングを目的としています。リポジトリ内
のパッチまたは ファイルの空白を修正するには、 git-apply(1) の
‘--whitespace=fix’ モードをお勧めします。

OPTIONS
*******

‘-s’
‘--strip-comments’
     コメント文字で始まるすべての行をスキップして削除します(デフォルトは
     _#_ )。

‘-c’
‘--comment-lines’
     各行の前にコメント文字と空白を付けます。行は自動的に改行で終了しま
     す。 空行では、コメント文字のみが先頭に追加されます。

EXAMPLES
********

以下のようなノイズの多い入力があるとします。 _$_ は行の終わりを示してい
ます:

     |A brief introduction   $
     |   $
     |$
     |A new paragraph$
     |# with a commented-out line    $
     |explaining lots of stuff.$
     |$
     |# An old paragraph, also commented-out. $
     |      $
     |The end.$
     |  $

   _git stripspace_ を引数無しで実行すると以下のようになります:

     |A brief introduction$
     |$
     |A new paragraph$
     |# with a commented-out line$
     |explaining lots of stuff.$
     |$
     |# An old paragraph, also commented-out.$
     |$
     |The end.$

   _git stripspace –strip-comments_ を使うと以下のようになります:

     |A brief introduction$
     |$
     |A new paragraph$
     |explaining lots of stuff.$
     |$
     |The end.$

GIT
***

Part of the git(1) suite

Name
****

git-submodule — サブモジュールを初期化、更新、または検査します

Synopsis
********

     git submodule [–quiet] [–cached]
     git submodule [–quiet] add [<options>] [–] <repository> [<path>]
     git submodule [–quiet] status [–cached] [–recursive] [–] [<path>…]
     git submodule [–quiet] init [–] [<path>…]
     git submodule [–quiet] deinit [-f|–force] (–all|[–] <path>…)
     git submodule [–quiet] update [<options>] [–] [<path>…]
     git submodule [–quiet] set-branch [<options>] [–] <path>
     git submodule [–quiet] set-url [–] <path> <newurl>
     git submodule [–quiet] summary [<options>] [–] [<path>…]
     git submodule [–quiet] foreach [–recursive] <command>
     git submodule [–quiet] sync [–recursive] [–] [<path>…]
     git submodule [–quiet] absorbgitdirs [–] [<path>…]

DESCRIPTION
***********

サブモジュールを検査、更新、管理します。

   サブモジュールの詳細については、 gitsubmodules(7) を参照してください
。

COMMANDS
********

引数なしで、既存のサブモジュールのステータスを示します。 サブモジュール
で操作を実行するために、いくつかのサブコマンドを使用できます。

add [-b <branch>] [-f|–force] [–name <name>] [–reference <repository>] [–depth <depth>] [–] <repository> [<path>]
     現在のプロジェクトの次にコミットされるチェンジセットへの指定のパス
     で、指定のポジトリをサブモジュールとして追加します。現在のプロジェ
     クトは「スーパープロジェクト」と呼ばれます。

     <repository> は、新しいサブモジュールの元リポジトリのURLです。これ
     は、絶対URLまたは、( ‘./’ または ‘../’ で始まる場合、)スーパープロ
     ジェクトのデフォルトのリモートリポジトリに相対的な場所のいずれかで
     す(スーパープロジェクト ‘bar.git’ のすぐ隣にあるリポジトリ
     ‘foo.git’ を指定するには、 ‘./foo.git’ の代わりに ‘../foo.git’ を使
     用する必要があることに注意してください — 相対 URL の規則に従ってい
     れば、期待通りになるでしょう — Git における相対 URL の評価は相対デ
     ィレクトリの場合と同じだからです)。

     デフォルトのリモートは、現在のブランチのリモート追跡ブランチのリモ
     ートです。そのようなリモート追跡ブランチが存在しないか、または、
     HEADが切り離されている場合、「origin」がデフォルトのリモートである
     と見なされます。 スーパープロジェクトにデフォルトのリモートが構成さ
     れていない場合、スーパープロジェクトはそれ自身に権限のあるアップス
     トリームであり、代わりに現在の作業ディレクトリが使用されます。

     オプションの引数 <path> は、複製されたサブモジュールがスーパープロ
     ジェクト内で存在するための相対的な場所です。 <path> が指定されてい
     ない場合、ソースリポジトリの正規部分(canonical part)が使用されます
     (‘/path/to/repo.git’ の場合は「repo」、 ‘host.xz:foo/.git’ の場合は
     「foo」)。 <path> が存在し、すでに有効なGitリポジトリである場合、ク
     ローンを作成せずにコミット用にステージングされます。 <path> は、
     ‘--name’ を使用して論理名を指定しない限り、構成エントリでサブモジュ
     ールの論理名としても使用されます。

     指定のURLは、スーパープロジェクトのクローンを作成する後続のユーザー
     が使用できるように ‘.gitmodules’ に記録されます。 URLがスーパープロ
     ジェクトのリポジトリに関連して指定されている場合、スーパープロジェ
     クトとサブモジュールのリポジトリは同じ相対位置にまとめられ、スーパ
     ープロジェクトのURLのみを指定する必要があると想定します。
     git-submoduleは、 ‘.gitmodules’ の相対URLを使用してサブモジュールを
     正しく検索します。

status [–cached] [–recursive] [–] [<path>…]
     サブモジュールの状態を表示します。これにより、各サブモジュールの現
     在チェックアウトされているコミットの SHA-1 が、サブモジュールのパス
     と SHA-1 の _git describe_ の出力と共に出力されます。各 SHA-1 には
     、サブモジュールが初期化されていない場合は _-_ 、現在チェックアウト
     されているサブモジュールコミットが、含まれているリポジトリのインデ
     ックスにある SHA-1 と一致しない場合は _+_ 、サブモジュールにマージ
     競合がある場合は _U_ 、 という接頭辞が付く可能性があります。

     ‘--cached’ が指定されている場合、このコマンドは代わりに、各サブモジ
     ュールのスーパープロジェクトに記録されたSHA-1を出力します。

     ‘--recursive’ が指定されている場合、このコマンドはネストされたサブ
     モジュールに再帰し、それらのステータスも表示します。

     あなたがインデックスまたはHEADに記録されたコミットに関して、現在初
     期化されているサブモジュールの変更のみに関心がある場合は、
     git-status(1) および git-diff(1) もその情報を提供します(サブモジュ
     ールの作業ツリーへの変更も報告します)。

init [–] [<path>…]
     インデックスに記録されたサブモジュール(他の場所で追加およびコミット
     されたサブモジュール)を初期化するには、 ‘.git/config’ に
     ‘submodule.$name.url’ を設定します。テンプレートとして
     ‘.gitmodules’ と同じ設定を使用します。URLが相対的な場合は、デフォル
     トのリモートを使用して解決されます。デフォルトのリモートがない場合
     、現在のリポジトリはアップストリームであると見なされます。

     オプションの <path> 引数は、初期化されるサブモジュールを制限します
     。パスが指定されておらず、 submodule.active が構成されている場合、
     アクティブになるように構成されたサブモジュールが初期化されます。そ
     うでない場合、すべてのサブモジュールが初期化されます。

     存在する場合は、 ‘submodule.$name.update’ の値もコピーします。この
     コマンドは、 ‘.git/config’ の既存の情報を変更しません。あなたは次に
     、ローカル設定用に ‘.git/config’ のサブモジュールクローンURLをカス
     タマイズして、 ‘git submodule update’ に進むことができます。サブモ
     ジュールの場所をカスタマイズする予定がない場合は、明示的な「init」
     ステップなしで ‘git submodule update --init’ を使用することもできま
     す。

     デフォルトのリモートの定義については、add サブコマンドを参照してく
     ださい。

deinit [-f|–force] (–all|[–] <path>…)
     指定のサブモジュールの登録を解除します。つまり、‘.git/config’ から
     _submodule.$name_ セクション全体をその作業ツリーとともに削除します
     。さらに ‘git submodule update’ と ‘git submodule foreach’ と ‘git
     submodule sync’ を呼び出すと、 未登録のサブモジュールが再び初期化さ
     れるまでスキップされるので、作業ツリーにあるサブモジュールのローカ
     ルチェックアウトをもうこれ以上やりたくない場合は、このコマンドを使
     用してください。

     コマンドをpathspecなしで実行すると、間違いを防ぐために、すべてを無
     効にするのではなく、エラーが発生します。

     ‘--force’ が指定されている場合、サブモジュールの作業ツリーは、ロー
     カルの変更が含まれていても削除されます。

     あなたが本当にリポジトリからサブモジュールを削除してコミットしたい
     場合は、代わりに git-rm(1) を使用してください。削除オプションについ
     ては、 gitsubmodules(7) を参照してください。

update [–init] [–remote] [-N|–no-fetch] [–[no-]recommend-shallow] [-f|–force] [–checkout|–rebase|–merge] [–reference <repository>] [–depth <depth>] [–recursive] [–jobs <n>] [–[no-]single-branch] [–] [<path>…]
     登録されたサブモジュールを更新して、欠落しているサブモジュールのク
     ローンを作成し、サブモジュールで欠落しているコミットをフェッチし、
     サブモジュールの作業ツリーを更新して、スーパープロジェクトが期待す
     るものと一致させます。「更新」は、コマンドラインオプションと
     ‘submodule.<name>.update’ 構成変数の値に応じていくつかの方法で実行
     できます。 コマンドラインオプションは、構成変数よりも優先されます。
     どちらも指定されていない場合、「checkout」が実行されます。 コマンド
     ラインと ‘submodule.<name>.update’ 構成の両方でサポートされる「
     update」手順は以下のとおりです:

     checkout
          スーパープロジェクトに記録されたコミットは、 切り離された
          HEAD(detached HEAD)のサブモジュール(submodule)でチェックアウト
          されます。

     + ‘--force’ が指定された場合、サブモジュールは(‘git checkout
     --force’ を使って)チェックアウトされます。たとえ含んでいるリポジト
     リのインデックスで指定されたコミットが、すでにサブモジュールでチェ
     ックアウトしたコミットに一致していてもです。

     rebase
          サブモジュールの現在のブランチは、 スーパープロジェクトに記録
          されたコミットに基づいてリベースされます。

     merge
          スーパープロジェクトに記録されたコミットは、 サブモジュールの
          現在のブランチにマージされます。

     以下の「update」手順は、 ‘submodule.<name>.update’ 構成変数を介して
     のみ使用できます:

     custom command
          単一の引数 (スーパープロジェクトに記録されたコミットのsha1)を
          とる 任意のシェルコマンドが実行されます。
          ‘submodule.<name>.update’ が ‘!command’ に設定されている場合、
          感嘆符(‘!’)の後の残りはカスタムコマンドです。

     none
          サブモジュールは更新されません。

     サブモジュールがまだ初期化されておらず、 ‘.gitmodules’ に格納されて
     いる設定を使用するだけの場合、 あなたは ‘--init’ オプションを使用し
     てサブモジュールを自動的に初期化できます。

     ‘--recursive’ が指定されている場合、このコマンドは登録されたサブモ
     ジュールに再帰し、その中でネストされたサブモジュールを更新します。

set-branch (-b|–branch) <branch> [–] <path>
set-branch (-d|–default) [–] <path>
     サブモジュールのデフォルトのリモート追跡ブランチを設定します。
     ‘--branch’ オプションを使用すると、リモートブランチを指定できます。
     ‘--default’ オプションを使用すると、 submodule.<name>.branch 構成キ
     ーを削除し、これにより、追跡ブランチはデフォルトでリモートの「
     HEAD」になります。

set-url [–] <path> <newurl>
     指定されたサブモジュールのURLを <newurl> に設定します。そしてその次
     に、サブモジュールの新しいリモートURL構成を自動的に同期します。

summary [–cached|–files] [(-n|–summary-limit) <n>] [commit] [–] [<path>…]
     指定のコミット(デフォルトはHEAD)と 作業ツリー/インデックス の間のコ
     ミットの概要を表示します。問い合わせがサブモジュールの場合、指定の
     スーパープロジェクトコミットと、インデックスまたは作業ツリー
     (‘--cached’ によって切り替えられる)の間のサブモジュール内の一連のコ
     ミットが表示されます。オプション ‘--files’ が指定されている場合は、
     スーパープロジェクトのインデックスとサブモジュールの作業ツリーの間
     の、サブモジュールでの一連のコミットを表示します(このオプションでは
     、 ‘--cached’ オプションを使用したり、明示的なコミットを提供したり
     することはできません)。

     git-diff(1) で ‘--submodule=log’ オプションを使用すると、その情報も
     提供されます。

foreach [–recursive] <command>
     チェックアウトされた各サブモジュールで任意のシェルコマンドを評価し
     ます。このコマンドは、変数 $name と $sm_path と $displaypath と
     $sha1 と$toplevel にアクセスできます。$name は、 ‘.gitmodules’ の関
     連するサブモジュールセクションの名前で、 $sm_path は、直接のスーパ
     ープロジェクト(immediate superproject)に記録されているサブモジュー
     ルのパスで、 $displaypath には、現在の作業ディレクトリからサブモジ
     ュールのルートディレクトリへの相対パスが含まれ、 $sha1 は、直接のス
     ーパープロジェクト(immediate superproject)に記録されているコミット
     で、 $toplevel は、直接のスーパープロジェクト(immediate
     superproject)のトップレベルへの絶対パスです。Windowsでの ‘$PATH’ と
     の競合を避けるために、 ‘$path’ 変数は ‘$sm_path’ 変数の非推奨の同義
     語になっていることに注意してください。スーパープロジェクトで定義さ
     れているがチェックアウトされていないサブモジュールは、このコマンド
     では無視されます。‘--quiet’ が指定されていない限り、foreachはコマン
     ドを評価する前に各サブモジュールの名前を出力します。 ‘--recursive’
     が指定されている場合、サブモジュールは再帰的にトラバースされます(つ
     まり、指定のシェルコマンドはネストされたサブモジュールでも評価され
     ます)。 サブモジュールのコマンドからゼロ以外の値が返されると、処理
     が終了(terminate)します。これは、コマンドの最後に ‘|| :’ を追加する
     ことでオーバーライドできます。

     例として、以下のコマンドは、各サブモジュールのパスと現在チェックア
     ウトされているコミットを表示します:

          git submodule foreach 'echo $sm_path `git rev-parse HEAD`'

sync [–recursive] [–] [<path>…]
     サブモジュールのリモートURL構成設定を ‘.gitmodules’ で指定された値
     に同期します。 これは、‘.git/config’ にすでにURLエントリがあるサブ
     モジュールにのみ影響します(これは、初期化されたとき、または新しく追
     加されたときの場合です)。これは、サブモジュールのURLがアップストリ
     ームで変更され、それに応じてローカルリポジトリを更新する必要がある
     場合に役立ちます。

     ‘git submodule sync’ はすべてのサブモジュールを同期しますが、 ‘git
     submodule sync -- A’ はサブモジュール "A" のみを同期します。

     ‘--recursive’ が指定されている場合、このコマンドは登録されたサブモ
     ジュールに再帰し、その中でネストされたサブモジュールを同期します。

absorbgitdirs
     サブモジュールのgitディレクトリがサブモジュール内にある場合、サブモ
     ジュールのgitディレクトリをそのスーパープロジェクトの
     ‘$GIT_DIR/modules’ パスに移動し、次に、 ‘core.worktree’ を設定して
     、gitディレクトリとその作業ディレクトリを接続し、そして、スーパープ
     ロジェクトのgitディレクトリに埋め込んだサブモジュールのgitディレク
     トリを指す .git ファイルを追加します。

     独立して複製され、後でサブモジュールまたは古いセットアップとして追
     加されたリポジトリでは、スーパープロジェクトのgitディレクトリに埋め
     込まれるのではなく、サブモジュール内にサブモジュールのgitディレクト
     リがあります。

     このコマンドはデフォルトで再帰的に実行されます。

OPTIONS
*******

‘-q’
‘--quiet’
     エラーメッセージのみを出力します。

‘--progress’
     このオプションは、addおよびupdateコマンドにのみ有効です。 ‘-q’ が指
     定されていない限り、進行状況は、端末に接続されている場合、デフォル
     トで標準エラーストリームに報告されます。このフラグは、標準エラース
     トリームが端末に送信されていない場合でも、進行状況を強制します。

‘--all’
     このオプションは、deinitコマンドに対してのみ有効です。 作業ツリーの
     すべてのサブモジュールの登録を解除します。

‘-b <branch>’
‘--branch <branch>’
     サブモジュールとして追加するリポジトリのブランチ。ブランチの名前は
     、‘update --remote’ の ‘.gitmodules’ に ‘submodule.<name>.branch’ と
     して記録されます。 特別な値 ‘.’ は、サブモジュール内のブランチの名
     前が現在のリポジトリ内の現在のブランチと同じ名前でなければならない
     ことを示すために使用されます。オプションが指定されていない場合、デ
     フォルトでリモートの「HEAD」になります。

‘-f’
‘--force’
     このオプションは、addとdeinitとupdateコマンドにのみ有効です。addを
     実行するときは、無視されるサブモジュールパスの追加を許可します。
     deinitを実行するときは、ローカルの変更が含まれている場合でも、サブ
     モジュールの作業ツリーが削除されます。 updateを実行するときは
     (checkout手順でのみ有効)、別のコミットに切り替えるときにサブモジュ
     ールのローカル変更を破棄し、そして、含まれているリポジトリのインデ
     ックスにリストされているコミットがサブモジュールでチェックアウトさ
     れたコミットと一致する場合でも、常にサブモジュールでチェックアウト
     操作を実行します。

‘--cached’
     このオプションは、statusコマンドとsummaryコマンドにのみ有効です。こ
     れらのコマンドは通常、サブモジュールHEADにあるコミットを使用します
     が、このオプションを使用すると、代わりにインデックスに格納されてい
     るコミットが使用されます。

‘--files’
     このオプションは、summaryコマンドにのみ有効です。 このコマンドを使
     用すると、インデックス内のコミットと、サブモジュールHEAD内のコミッ
     トが比較されます。

‘-n’
‘--summary-limit’
     このオプションは、summaryコマンドにのみ有効です。 サマリーサイズ(合
     計で表示されるコミットの数)を制限します。 0を指定すると、要約が無効
     になります。 負の数は無制限(デフォルト)を意味します。この制限は、変
     更されたサブモジュールにのみ適用されます。 追加/削除/タイプ変更され
     た サブモジュールのサイズは常に1に制限されます。

‘--remote’
     このオプションは、updateコマンドに対してのみ有効です。 スーパープロ
     ジェクトの記録されたSHA-1を使用してサブモジュールを更新する代わりに
     、サブモジュールのリモート追跡ブランチのステータスを使用します。 使
     用されるリモートはブランチのリモート(‘branch.<name>.remote’)で、デ
     フォルトは ‘origin’ です。 使用されるリモートブランチのデフォルトは
     リモートの ‘HEAD’ ですが、ブランチ名は、 ‘.git / config’ または
     ‘.gitmodules’ のいずれかで ‘submodule.<name>.branch’ オプションを設
     定することでオーバーライドできます(‘.git / config’ が優先されます
     )。

     これは、サポートされている更新手順(‘--checkout’ 、‘--rebase’ など
     )のいずれでも機能します。唯一の変更は、ターゲットSHA-1のソースです
     。 たとえば、 ‘submodule update --remote --merge’ はアップストリー
     ムのサブモジュールの変更をサブモジュールにマージし、 ‘submodule
     update --merge’ はスーパープロジェクトのgitlinkの変更をサブモジュー
     ルにマージします。

     現在の追跡ブランチの状態を確認するために、 ‘update --remote’ は
     SHA-1を計算する前にサブモジュールのリモートリポジトリをフェッチしま
     す。フェッチしたくない場合は、 ‘submodule update --remote
     --no-fetch’ を使用する必要があります。

     このオプションを使用して、アップストリームサブプロジェクトからの変
     更をサブモジュールの現在のHEADと統合します。または、サブモジュール
     から ‘git pull’ を実行することもできます。これは、リモートブランチ
     名を除いて同等です。‘update --remote’ はデフォルトのアップストリー
     ムリポジトリと ‘submodule.<name>.branch’ を使用し、 ‘git pull’ はサ
     ブモジュールの ‘branch.<name>.merge’ を使用します。スーパープロジェ
     クトでデフォルトのアップストリームブランチを配布する場合は
     ‘submodule.<name>.branch’ を、サブモジュール自体で作業しているとき
     によりネイティブな感じが必要な場合は ‘branch.<name>.merge’ を使用し
     てください。

‘-N’
‘--no-fetch’
     このオプションは、updateコマンドに対してのみ有効です。リモートサイ
     トから新しいオブジェクトをフェッチしません。

‘--checkout’
     このオプションは、updateコマンドに対してのみ有効です。サブモジュー
     ルの切り離されたHEAD(detached HEAD)のスーパープロジェクトに記録され
     たコミットをチェックアウトします。これはデフォルトの動作です。この
     オプションの主な用途は、 ‘checkout’ 以外の値に設定されたときに
     ‘submodule.$name.update’ をオーバーライドすることです。 キー
     ‘submodule.$name.update’ が明示的に設定されていないか、 ‘checkout’
     に設定されている場合、このオプションが暗黙に指定されています。

‘--merge’
     このオプションは、updateコマンドに対してのみ有効です。 スーパープロ
     ジェクトに記録されたコミットをサブモジュールの現在のブランチにマー
     ジします。 このオプションを指定すると、サブモジュールのHEADは切り離
     されません。 マージの失敗によりこの処理が妨げられる場合は、通常の競
     合解決ツールを使用して、サブモジュール内で発生する競合を解決する必
     要があります。 キー ‘submodule.$name.update’ が ‘merge’ に設定され
     ている場合、このオプションが暗黙に指定されます。

‘--rebase’
     このオプションは、updateコマンドに対してのみ有効です。 現在のブラン
     チをスーパープロジェクトに記録されたコミットにリベースします。 この
     オプションを指定すると、サブモジュールのHEADは切り離されません。 マ
     ージの失敗によりこのプロセスが妨げられる場合は、 git-rebase(1) を使
     用してこれらの失敗を解決する必要があります。 キー
     ‘submodule.$name.update’ が ‘rebase’ に設定されている場合、このオプ
     ションが暗黙に指定されます。

‘--init’
     このオプションは、updateコマンドに対してのみ有効です。更新する前に
     、これまで ‘git submodule init’ が呼び出されていないすべてのサブモ
     ジュールを初期化します。

‘--name’
     このオプションは、addコマンドに対してのみ有効です。 サブモジュール
     の名前を、デフォルトのパスではなく、指定の文字列に設定します。 名前
     はディレクトリ名として有効である必要があり、 ‘/’ で終わらせることは
     できません。

‘--reference <repository>’
     このオプションは、addとupdateコマンドにのみ有効です。これらのコマン
     ドでは、リモートリポジトリのクローンを作成する必要がある場合があり
     ます。その場合、このオプションを git-clone(1) コマンドに渡します。

     *注意*: git-clone(1) の ‘--reference’ と ‘--shared’ と
     ‘--dissociate’ オプションに関するNOTEを注意深く読んでいない限り、 こ
     のオプションを使用しないでください。

‘--dissociate’
     このオプションは、addとupdateコマンドにのみ有効です。これらのコマン
     ドでは、リモートリポジトリのクローンを作成する必要がある場合があり
     ます。その場合、このオプションを git-clone(1) コマンドに渡します。

     *注意*: ‘--reference’ オプションについては NOTE を参照してください
     。

‘--recursive’
     このオプションは、foreachとupdateとstatusとsyncコマンドにのみ有効で
     す。サブモジュールを再帰的にトラバースします。この操作は、現在のリ
     ポジトリのサブモジュールだけでなく、それらのサブモジュール内のネス
     トされたサブモジュール(など)でも実行されます。

‘--depth’
     このオプションは、addとupdateコマンドに有効です。 指定のリビジョン
     数に切り捨てられた履歴を持つ「浅い」クローン(shallow clone)を作成し
     ます。 git-clone(1) を参照してください。

‘--[no-]recommend-shallow’
     このオプションは、updateコマンドに対してのみ有効です。サブモジュー
     ルの初期クローンは、デフォルトで ‘.gitmodules’ ファイルによって提供
     される推奨される ‘submodule.<name>.shallow’ を使用します。 提案を無
     視するには、‘--no-recommend-shallow’ を使用します。

‘-j <n>’
‘--jobs <n>’
     このオプションは、updateコマンドに対してのみ有効です。多くのジョブ
     と並行して新しいサブモジュールのクローンを作成します。デフォルトは
     ‘submodule.fetchJobs’ オプションです。

‘--[no-]single-branch’
     このオプションは、updateコマンドに対してのみ有効です。 HEAD または
     、 ‘--branch’ で指定されたブランチは、更新中に1つのブランチのみを複
     製します

<path>…
     サブモジュールへのパス。これを指定すると、指定したパスで見つかった
     サブモジュールでのみ動作するようにコマンドが制限されます。(この引数
     はaddでは必須です)。

FILES
*****

サブモジュールを初期化するとき、含まれているリポジトリの最上位ディレクト
リにある ‘.gitmodules’ ファイルを使用して、各サブモジュールのURLを検索し
ます。 このファイルは、 ‘$GIT_DIR/config’ と同じ方法でフォーマットする必
要があります。各サブモジュールURLのキーは、「submodule.$name.url」です。
詳細については、 gitmodules(5) を参照してください。

SEE ALSO
********

gitsubmodules(7), gitmodules(5).

GIT
***

Part of the git(1) suite

Name
****

git-svn — SubversionリポジトリとGit間の双方向操作

Synopsis
********

     git svn <command> [<options>] [<arguments>]

DESCRIPTION
***********

‘git svn’ は、SubversionとGitの間のチェンジセットのための単純な水道管で
す。 SubversionとGitリポジトリ間の双方向の変更フローを提供します。

   ‘git svn’ は、 ‘--stdlayout’ オプションを使用して、一般的な「
trunk/branches/tags」レイアウトに従って、標準のSubversionリポジトリを追
跡できます。 また、 ‘-T’/‘-t’/‘-b’ オプションを使用して、任意のレイアウ
トのブランチとタグを追跡することもできます(以下の「initコマンド」のオプ
ションおよび「cloneコマンド」も参照してください)。

   (上記の方法のいずれかを使用して)Subversionリポジトリを追跡すると、
Gitリポジトリは「fetch」コマンドによってSubversionから更新され、
Subversionは「dcommit」コマンドによってGitから更新されます。

COMMANDS
********

‘init’
     ‘git svn’ の追加のメタデータディレクトリを使用して空のGitリポジトリ
     を初期化します。 Subversion URLは、コマンドライン引数として、または
     ‘-T’/‘-t’/‘-b’ への完全なURL引数として指定できます。 オプションで、
     操作するターゲットディレクトリを2番目の引数として指定できます。 通
     常、このコマンドは現在のディレクトリを初期化します。

     ‘-T<trunk_subdir>’
     ‘--trunk=<trunk_subdir>’
     ‘-t<tags_subdir>’
     ‘--tags=<tags_subdir>’
     ‘-b<branches_subdir>’
     ‘--branches=<branches_subdir>’
     ‘-s’
     ‘--stdlayout’
          これらは、initのコマンドラインオプションです。 これらの各フラ
          グは、相対リポジトリパス(‘-tags=project/tags’)または完全な
          URL(‘--tags=https://foo.org/project/tags’)を指すことができます
          。 Subversionリポジトリがタグまたはブランチを複数のパスの下に
          配置する場合は、複数の ‘--tags’ および/または ‘--branches’ オ
          プションを指定できます。 オプション ‘--stdlayout’ は、トランク
          、タグ、ブランチを相対パスとして設定する簡単な方法です。これは
          、Subversionのデフォルトです。 他のオプションのいずれかが同様
          に指定されている場合、それらが優先されます。

     ‘--no-metadata’
          [svn-remote] 設定で ‘noMetadata’ オプションを設定します。 この
          オプションはお勧めしません。このオプションを使用する前に、この
          マンページの「svn.noMetadata」セクションをお読みください。

     ‘--use-svm-props’
          [svn-remote]設定で ‘useSvmProps’ オプションを設定します。

     ‘--use-svnsync-props’
          [svn-remote] 設定で ‘useSvnsyncProps’ オプションを設定します。

     ‘--rewrite-root=<URL>’
          [svn-remote]設定で ‘rewriteRoot’ オプションを設定します。

     ‘--rewrite-uuid=<UUID>’
          [svn-remote]設定で ‘rewriteUUID’ オプションを設定します。

     ‘--username=<user>’
          SVNが認証を処理する転送(http や https やプレーンsvn)の場合に、
          ユーザー名を指定します。 他の転送(例: ‘svn+ssh://’)の場合、
          URLにユーザー名を含める必要があります。例：
          ‘svn+ssh://foo@svn.bar.com/project’

     ‘--prefix=<prefix>’
          これにより、トランク/ブランチ/タグ が指定されている場合に、リ
          モートの名前の前に付加される接頭辞を指定できます。 接頭辞
          (prefix)には自動的に末尾のスラッシュが含まれ無いため、必要に応
          じて引数に必ず末尾のスラッシュを含めてください。
          ‘--branches’/‘-b’ を指定する場合、接頭辞には末尾のスラッシュを
          含める必要があります。 SVN追跡refは ‘refs/remotes/$prefix/*’ に
          配置されるため、(末尾にスラッシュを付けた)接頭辞を設定すること
          を強くお勧めします。これは、Git独自のリモート追跡refレイアウト
          と互換性があります(‘refs/remotes/$remote/*’)。 接頭辞の設定は
          、共通のリポジトリを共有する複数のプロジェクトを追跡する場合に
          も役立ちます。 デフォルトでは、接頭辞は ‘origin/’ に設定されて
          います。

               *Note*

               Git v2.0 より前は、デフォルトの接頭辞は "" (接頭辞無し)で
               した。 これは、SVN追跡refが ‘refs/remotes/*’ に配置された
               ことを意味します。これは、Git自体のリモート追跡refの編成
               方法と互換性がありません。 それでも古いデフォルトが必要な
               場合は、コマンドラインで ‘--prefix ""’ を渡すことで取得で
               きます(Perlの Getopt::Long is < v2.37 の場合、
               ‘--prefix=""’ は機能しない可能性があります)。

     ‘--ignore-refs=<regex>’
          ‘init’ または ‘clone’ に渡されると、この正規表現は構成キー
          (config key)として保持されます。 ‘--ignore-refs’ の説明につい
          ては、「fetch」コマンドを参照してください。

     ‘--ignore-paths=<regex>’
          ‘init’ または‘ clone‘ に渡されると、この正規表現は構成キー
          (config key)として保持されます。 ‘--ignore-paths’ の説明につい
          ては、「fetch」コマンドを参照してください。

     ‘--include-paths=<regex>’
          ‘init’ または ‘clone’ に渡されると、この正規表現は構成キー
          (config key)として保持されます。 ‘--include-paths’ の説明につ
          いては、「fetch」コマンドを参照してください。

     ‘--no-minimize-url’
          (‘--stdlayout’ または ‘--branches’ または ‘--tags’ オプション
          を使用して、)複数のディレクトリを追跡する場合、git svnは
          Subversionリポジトリのルート(または許可されている最高レベル)へ
          の接続を試みます。 このデフォルトでは、プロジェクト全体がリポ
          ジトリ内で移動された場合に履歴をより適切に追跡できますが、読み
          取りアクセス制限が設定されているリポジトリで問題が発生する可能
          性があります。 ‘--no-minimize-url’ を渡すと、git svnは、上位レ
          ベルのディレクトリに接続しようとせずに、URLをそのまま受け入れ
          ることができます。 このオプションは、1つの URL/ブランチ のみが
          追跡される場合はデフォルトでオフになっています(ほとんど効果あ
          りません)。

‘fetch’
     私達が追跡しているSubversionリモートからフェッチされていないリビジ
     ョンを取得します。 $GIT_DIR/config ファイルの [svn-remote "…"] セク
     ションの名前は、オプションのコマンドライン引数として指定できます。

     これにより、必要に応じてrev_mapが自動的に更新されます(詳細について
     は、以下の「FILES」セクションの ‘$GIT_DIR/svn/\**/.rev_map.*’ を参
     照してください)。

     ‘--localtime’
          Gitのコミット時間をUTCではなくローカルタイムゾーンで保存します
          。 これにより、「git log」は(‘–date=local‘がなくても)、「svn
          log」がローカルタイムゾーンで表示されるのと同じ時間を表示しま
          す。

          これは、クローンを作成したSubversionリポジトリとの相互運用を妨
          げることはありませんが、ローカルGitリポジトリを他の誰かのロー
          カルGitリポジトリと相互運用できるようにする場合は、このオプシ
          ョンを使用しないか、両方で同一のローカルタイムゾーンを使用する
          必要があります。

     ‘--parent’
          現在のHEADのSVNの親からのみフェッチします。

     ‘--ignore-refs=<regex>’
          Perlの正規表現にマッチするブランチまたはタグのrefを無視します
          。 ‘^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$’
          のような「negative look-ahead assertion」(負の先読みアサーショ
          ン)は、特定のrefのみを許可するために使用できます。

               config key: svn-remote.<name>.ignore-refs

          ignore-refs 構成キーが設定されていて、コマンドラインオプション
          も指定されている場合は、両方の正規表現が使用されます。

     ‘--ignore-paths=<regex>’
          これにより、SVNからのチェックアウトから一致するすべてのパスを
          スキップするPerl正規表現を指定できます。 ‘--ignore-paths’ オプ
          ションは、特定のリポジトリのすべての ‘fetch’ (‘clone’,
          ‘dcommit’, ‘rebase’ などによる自動フェッチを含む)にマッチする
          必要があります。

               config key: svn-remote.<name>.ignore-paths

          ignore-paths 構成キーが設定されていて、コマンドラインオプショ
          ンも指定されている場合は、両方の正規表現が使用されます。

          例:

          フェッチするたびに ‘doc*’ ディレクトリをスキップします
                    --ignore-paths="^doc"

          第1レベルのディレクトリの「branches」と「tags」をスキップします
                    --ignore-paths="^[^/]+/(?:branches|tags)"

     ‘--include-paths=<regex>’
          これにより、SVNのチェックアウトからのマッチするパスのみを含め
          るPerl正規表現を指定できます。 ‘--include-paths’ オプションは
          、特定のリポジトリのすべての ‘fetch’(‘clone’, ‘dcommit’,
          ‘rebase’ などによる自動フェッチを含む)に一致する必要があります
          。 ‘--ignore-paths’ は ‘--include-paths’ よりも優先されます。

               config key: svn-remote.<name>.include-paths

     ‘--log-window-size=<n>’
          Subversionの履歴をスキャンするときに、リクエストごとに<n>個の
          ログエントリを取得します。 デフォルトは100です。非常に大きな
          Subversionリポジトリの場合、「クローン」/「フェッチ」 が妥当な
          時間で完了するには、より大きな値が必要になる場合があります。 た
          だし、値が大きすぎると、メモリ使用量が増え、リクエストののタイ
          ムアウトが発生する可能性があります。

‘clone’
     ‘init’ と ‘fetch’ を実行します。 渡されたURLのベース名に基づいてデ
     ィレクトリを自動的に作成します。 または2番目の引数が渡された場合は
     ディレクトリを作成し、その中で動作します。 ‘--fetch-all’ と
     ‘--parent’ を除いて、 ‘init’ と ‘fetch’ コマンドが受け入れるすべて
     の引数を受け入れます。 リポジトリのクローンが作成されると、「
     fetch」コマンドは作業ツリーに影響を与えることなくリビジョンを更新で
     きるようになります。 「rebase」コマンドは、作業ツリーを最新の変更で
     更新できるようになります。

     ‘--preserve-empty-dirs’
          Subversionからフェッチされた空のディレクトリごとに、ローカル
          Gitリポジトリにプレースホルダーファイルを作成します。 これには
          、Subversionリポジトリ内のすべてのエントリを削除することによっ
          て空になるディレクトリが含まれます(ディレクトリ自体は削除され
          ません)。 プレースホルダーファイルも追跡され、不要になったとき
          に削除されます。

     ‘--placeholder-filename=<filename>’
          ‘--preserve-empty-dirs’ によって作成されたプレースホルダーファ
          イルの名前を設定します。 デフォルトは ‘.gitignore’ です。

‘rebase’
     これにより、現在のHEADのSVN親からリビジョンがフェッチされ、現在の
     (SVNにコミットされていない)作業がリベースされます。

     これは ‘svn update’ または ‘git pull’ と同様に機能しますが、 ‘git
     svn’ でのコミットを容易にするために ‘git merge’ ではなく ‘git
     rebase’ で線形履歴を保持する点が異なります。

     これは、 ‘git svn fetch’ や ‘git rebase’ が受け入れるすべてのオプシ
     ョンを受け入れます。 ただし、 ‘--fetch-all’ は現在の[svn-remote]か
     らのみフェッチし、すべての[svn-remote]定義からフェッチするわけでは
     ありません。

     ‘git rebase’ と同様です。これには、作業ツリーがクリーンであり、コミ
     ットされていない変更がないことが必要です。

     これにより、必要に応じてrev_mapが自動的に更新されます(詳細について
     は、以下の「FILES」セクションの ‘$GIT_DIR/svn/\**/.rev_map.*’ を参
     照してください)。

     ‘-l’
     ‘--local’
          リモートでフェッチしないでください。 アップストリームSVNから最
          後にフェッチされたコミットに対してのみ ‘git rebase’ を実行しま
          す。

‘dcommit’
     現在のブランチからの各diffを直接SVNリポジトリにコミットしてから、リ
     ベースまたはリセットします(SVNとヘッドの間にdiffがあるかどうかによ
     って異なります)。 これにより、GitのコミットごとにSVNにリビジョンが
     作成されます。

     オプションのGitブランチ名(またはGitコミットオブジェクト名)が引数と
     して指定されている場合、サブコマンドは現在のブランチではなく、指定
     されたブランチで機能します。

     ‘set-tree’ (下記)よりも ‘dcommit’ の使用が推奨されます。

     ‘--no-rebase’
          コミット後にリベースまたはリセットしないでください。

     ‘--commit-url <URL>’
          このSVN URL(フルパス)にコミットします。 これは、ユーザーが後で
          コミット用の代替転送方法(例えば ‘svn+ssh://’ や ‘https://’)へ
          のアクセスを許可された場合に、ある転送方法(例えば、匿名読み取
          りの場合は ‘svn://’ または ‘http://’)で作成された既存の ‘git
          svn’ リポジトリを再利用できるようにすることを目的としています
          。

               config key: svn-remote.<name>.commiturl
               config key: svn.commiturl (overwrites all svn-remote.<name>.commiturl options)

          注意: commiturl構成キーのSVN URLにはSVNブランチが含まれている
          ことに注意してください。 SVNリポジトリ全体のコミットURLを設定
          する場合は、代わりに ‘svn-remote.<name>.pushurl’ を使用してく
          ださい。

          このオプションを他の目的(それがナニカは聞かないで下さい)で使用
          することは、全く全然欠片もお勧めできません。

     ‘--mergeinfo=<mergeinfo>’
          dcommit中に指定されたマージ情報を追加します(たとえば
          ‘--mergeinfo="/branches/foo:1-10"’)。 すべてのsvnサーバーバー
          ジョンはこの情報を(プロパティとして)保存でき、バージョン1.5以
          降のsvnクライアントはそれを利用できます。 複数のブランチからの
          マージ情報を指定するには、ブランチの間に単一の空白文字を使用し
          ます(‘--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8"’)

               config key: svn.pushmergeinfo

          このオプションにより、git-svnは、可能な場合、SVNリポジトリの
          svn:mergeinfo プロパティに自動的にデータを入力しようとします。
          現在、これは、最初の親を除くすべての親がすでにSVNにプッシュさ
          れている非早送りマージをコミットする場合にのみ実行できます。

     ‘--interactive’
          パッチセットが実際にSVNに送信される必要があることを確認するよ
          うにユーザーに問い合わせます。 パッチごとに、「yes」(このパッ
          チを受け入れる)、または「no」(このパッチを破棄する)、または「
          all」(すべてのパッチを受け入れる)、または「quit」と答えること
          ができます。

          ‘git svn dcommit’ は、回答が「no」または「quit」の場合、SVNに
          何もコミットせずに、すぐに終了します。

‘branch’
     SVNリポジトリにブランチを作成します。

     ‘-m’
     ‘--message’
          コミットメッセージを指定できます。

     ‘-t’
     ‘--tag’
          ‘git svn init’ で指定された branchs_subdir の代わりに、
          tags_subdir を使用してタグを作成します。

     ‘-d<path>’
     ‘--destination=<path>’
          ‘init’ または ‘clone’ コマンドに複数の ‘--branches’(または
          ‘--tags’)オプションが指定されている場合は、SVNリポジトリに作成
          するブランチ(またはタグ)の場所を指定する必要があります。
          <path> はブランチやタグを作成するために使用するパスを指定し、
          設定されたブランチやタグのrefspecsのどれかの左側のパターンに一
          致する必要があります。

               git config –get-all svn-remote.<name>.branches
               git config –get-all svn-remote.<name>.tags

          ここで、 <name> は、‘init’ の ‘-R’ オプションで指定されたSVNリ
          ポジトリーの名前です(またはデフォルトでは ‘svn’)。

     ‘--username’
          コミットを実行するSVNユーザー名を指定します。 このオプションは
          、 ‘username’ 構成プロパティをオーバーライドします。

     ‘--commit-url’
          指定のURLを使用して、宛先のSubversionリポジトリに接続します。
          これは、ソースSVNリポジトリが読み取り専用である場合に役立ちま
          す。 このオプションは、構成プロパティ _commiturl_ をオーバーラ
          イドします。

               git config --get-all svn-remote.<name>.commiturl

     ‘--parents’
          親フォルダを作成します。 このパラメーターは、 ‘svn cp’ コマン
          ドの ‘--parents’ パラメーターと同等であり、非標準のリポジトリ
          ーレイアウトで役立ちます。

‘tag’
     SVNリポジトリにタグを作成します。 これは ‘branch -t’ の省略形です。

‘log’
     これにより、svnユーザーが ‘-r’/‘-revision’ 番号を参照するときに、
     svnログメッセージを簡単に検索できるようになります。

     ‘svn log’ では以下の機能がサポートされています:

     ‘-r <n>[:<n>]’
     ‘--revision=<n>[:<n>]’
          数値以外の、 HEAD, NEXT, BASE, PREV, 等 はサポートされていませ
          ん。

     ‘-v’
     ‘--verbose’
          ‘svn log’ の ‘--verbose’ 出力と完全互換性ではありませんが、か
          なり近いです。

     ‘--limit=<n>’
          このオプションは ‘--max-count’ と同一ではなく、 マージされた
          /除外された コミットをカウントしません

     ‘--incremental’
          supported(訳注: 原文ママ)

     新機能:

     ‘--show-commit’
          Gitコミットのsha1も表示します

     ‘--oneline’
          私たちのバージョンの ‘--pretty=oneline’

          *Note*

          SVN自体はUTCでのみ時間を保存し、他には何も保存しません。 通常
          のsvnクライアントは、UTC時刻を現地時間(local time)に(または
          TZ= 環境変数に基づいて)変換します。 このコマンドの振る舞いは同
          一です。

     その他の引数はすべて ‘git log’ に直接渡されます

‘blame’
     ファイルの各行を最後に変更したリビジョンと作成者を表示します。 この
     モードの出力は、デフォルトで ‘svn blame’ の出力と書式の互換がありま
     す。 SVN blameコマンドと同様に、作業ツリー内のローカルのコミットさ
     れていない変更は無視されます。 HEADリビジョンのファイルのバージョン
     に注釈を付けます。 不明な引数は「git blame」に直接渡されます。

     ‘--git-format’
          ‘git blame’ と同じ形式で出力を生成しますが、Gitコミットハッシ
          ュの代わりにSVNリビジョン番号を使用します。 このモードでは、
          SVNにコミットされていない変更(ローカルの作業コピー編集を含む
          )は リビジョン0 として表示されます。

‘find-rev’
     ‘rN’ の形式のSVNリビジョン番号を指定すると、対応するGitコミットハッ
     シュを返します(オプションで、検索するブランチを指定するためにツリー
     っぽい何かの後に続けることができます)。 ツリーっぽい何かの場合は、
     対応するSVNリビジョン番号を返します。

     ‘-B’
     ‘--before’
          SVNリビジョンが与えられた場合、完全一致は要求しません。代わり
          に、指定されたリビジョンでの(現在のブランチ上の)SVNリポジトリ
          の状態に対応するコミットを探します。

     ‘-A’
     ‘--after’
          SVNリビジョンが与えられた場合、完全一致を要求しません。 完全一
          致がない場合は、履歴内で前方に検索する最も近い一致を返します。

‘set-tree’
     あなたは、このコマンドの代わりに「dcommit」の使用を検討する必要があ
     ります。 これは指定の コミットまたはツリーオブジェクト をSVNにコミ
     ットします。 これは、インポートされたフェッチデータが最新であること
     に依存しています。 よって、SVNにコミットするときにパッチを適用する
     試みはまったく行われず、ツリーまたはコミットで指定されたファイルで
     ファイルが上書きされるだけです。 すべてのマージは、「git svn」機能
     とは独立して行われたと見なされます。

‘create-ignore’
     ディレクトリの svn:ignore プロパティを再帰的に検索し、一致する
     .gitignore ファイルを作成します。 結果のファイルはコミットされるよ
     う、ステージングされますが、コミットは行われません。
     ‘-r’/‘-revision’ を使用して、特定のリビジョンを参照します。

‘show-ignore’
     ディレクトリの ‘svn:ignore’ プロパティを再帰的に検索して一覧表示し
     ます。 この出力は、 ‘$GIT_DIR/info/exclude’ ファイルに追加するのに
     適しています。

‘mkdirs’
     ‘$GIT_DIR/svn/<refname>/unhandled.log’ ファイルの情報に基づいてコア
     Gitが追跡できない空のディレクトリを再作成しようとします。 「git svn
     clone」や「git svn rebase」を使用すると、空のディレクトリが自動的に
     再作成されるため、「mkdirs」は「git checkout」や「git reset」などの
     コマンドの後に使用することを目的としています。 (詳細については、
     ‘svn-remote.<name>.automkdirs’ 構成ファイルオプションを参照してくだ
     さい。)

‘commit-diff’
     コマンドラインで指定された2つのツリーっぽい引数のdiffをコミットしま
     す。 このコマンドは、 ‘git svn init’ されたリポジトリ内にあることに
     依存していません。 このコマンドは、 (a)差分する元のツリー、(b)新し
     いツリーの結果、(c)ターゲットのSubversionリポジトリのURL、の3つの引
     数を取ります。 ‘git svn’ 対応リポジトリ(‘git svn’ で ‘init’ されて
     いるリポジトリ)から作業している場合は、最後の引数(URL)を省略できま
     す。 これには、 ‘-r<revision>’ オプションが必要です。

     コミットメッセージは、 ‘-m’ または ‘-F’ オプションを使用して直接提
     供されるか、2番目のツリーっぽい何かがそのようなオブジェクトを示す場
     合はタグまたはコミットから間接的に提供されるか、エディターを呼び出
     すことによって要求されます(下記 ‘--edit’ オプション参照)。

     ‘-m <msg>’
     ‘--message=<msg>’
          指定された ‘msg’ をコミットメッセージとして使用します。 このオ
          プションは、‘--edit’ オプションを無効にします。

     ‘-F <filename>’
     ‘--file=<filename>’
          指定されたファイルからコミットメッセージを取得します。 このオ
          プションは ‘--edit’ オプションを無効にします。

‘info’
     ‘svn info’ が提供するものと同様のファイルまたはディレクトリに関する
     情報を表示します。 現在のところ ‘-r’/‘-revision’ 引数はサポートして
     いません。 ‘--url’ オプションを使用すると、「URL:」フィールドの値の
     みを出力します。

‘proplist’
     特定のファイルまたはディレクトリについてSubversionリポジトリに保存
     されているプロパティを一覧表示します。 ‘-r’/‘-revision’ を使用して
     、特定のSubversionリビジョンを参照します。

‘propget’
     ファイルの最初の引数として指定されたSubversionプロパティを取得しま
     す。 特定のリビジョンは ‘-r’/‘-revision’ で指定できます。

‘propset’
     最初の引数として与えられた Subversion のプロパティを、3番目の引数と
     して与えられたファイルに対して2番目の引数として与えられた値に設定し
     ます。

     例:

          git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile

     これにより、ファイル ‘devel/py-tipper/Makefile’ のプロパティ
     ‘svn:keywords’ が ‘FreeBSD=%H’ に設定されます。

‘show-externals’
     Subversionのexternalsを表示します。 ‘-r’/‘-revision’ を使用して、特
     定のリビジョンを指定します。

‘gc’
     ‘$GIT_DIR/svn/<refname>/unhandled.log’ ファイルを圧縮し、
     ‘$GIT_DIR/svn/<refname>/index’ ファイル達を削除します。

‘reset’
     ‘fetch’ の効果を元に戻し、指定されたリビジョンに戻します。 これによ
     り、SVNリビジョンを「再フェッチ」できます。 通常、SVNリビジョンの内
     容は決して変更されるべきではなく、「リセット」は必要ありません。 た
     だし、SVN権限が変更された場合、または ‘--ignore-paths’ オプションを
     変更した場合、「フェッチ」が「not found in commit」(コミットで見つ
     かりません)(ファイルが以前に表示されなかった)または「checksum
     mismatch」(チェックサムの不一致)(変更を見逃した)で失敗する場合があ
     ります。 問題のあるファイルを永久に無視できない場合
     (‘--ignore-pathsを使用’）、リポジトリを修復する唯一の方法は「
     reset」を使用することです。

     rev_map と ‘refs/remotes/git-svn’ のみが変更されます(詳細については
     、下記「ファイル」セクションの「$GIT_DIR/svn/**/.rev_map.*」を参照
     してください)。 ‘reset’ の後に ‘fetch’ を続け、次に ‘git reset’ ま
     たは ‘git rebase’ を実行して、ローカルブランチを新しいツリーに移動
     します。

     ‘-r <n>’
     ‘--revision=<n>’
          保持する最新のリビジョンを指定します。 それ以降のリビジョンは
          すべて破棄されます。

     ‘-p’
     ‘--parent’
          指定のリビジョンも破棄し、代わりに最も近い親を保持します。

     例:
          「master」にローカルの変更があると仮定しますが、あなたは「r2」
          を再フェッチする必要があります。

                   r1---r2---r3 remotes/git-svn
                               \
                                A---B master

          そもそも「r2」が不完全になる原因となったignore-pathsまたは
          SVNパーミッションの問題を修正します。 それから:

               git svn reset -r2 -p
               git svn fetch

                   r1---r2'--r3' remotes/git-svn
                     \
                      r2---r3---A---B master

          次に、「master」を「git rebase」で修正します。 「git merge」を
          使用してはいけません。「git merge」を使用すると、履歴が将来の
          「dcommit」と互換性がなくなります。

               git rebase –onto remotes/git-svn A^ master

                   r1---r2'--r3' remotes/git-svn
                               \
                                A'--B' master

OPTIONS
*******

‘--shared[=(false|true|umask|group|all|world|everybody)]’
‘--template=<template_directory>’
     ‘init’ コマンドでのみ使用されます。 これらは ‘git init’ に直接渡さ
     れます。

‘-r <arg>’
‘--revision <arg>’
     ‘fetch’ コマンドで使用されます。

     これにより、部分的な(partial)/一部が取り除かれた(cauterized) 履歴の
     リビジョン範囲をサポートできます。 $NUMBER, $NUMBER1:$NUMBER2 (数値
     範囲) と $NUMBER:HEAD と $NUMBER：HEAD と BASE:$NUMBER はすべてサポ
     ートされています。

     これにより、フェッチの実行時に部分ミラーを作成できます。 ただし、履
     歴がスキップされて失われるため、通常はお勧めしません。

‘-’
‘--stdin’
     ‘set-tree’ コマンドでのみ使用されます。

     stdinからコミットのリストを読み取り、逆の順序でコミットします。 各
     行からは先頭のsha1のみが読み取られるため、 ‘git rev-list
     --pretty=oneline’ 出力を使用できます。

‘--rmdir’
     ‘dcommit’ と ‘set-tree’ と ‘commit-diff’ コマンドでのみ使用されます
     。

     ファイルが残っていない場合は、SVNツリーからディレクトリを削除します
     。 SVNは空のディレクトリをバージョン管理でき、ファイルが残っていな
     い場合、デフォルトでは削除されません。 Gitは空のディレクトリをバー
     ジョン管理できません。 このフラグを有効にすると、SVNへのコミットが
     Gitのように機能します。

          config key: svn.rmdir

‘-e’
‘--edit’
     ‘dcommit’ と ‘set-tree’ と ‘commit-diff’ コマンドでのみ使用されます
     。

     SVNにコミットする前に、コミットメッセージを編集します。 これは、コ
     ミットされているオブジェクトではデフォルトでオフになっており、ツリ
     ーオブジェクトをコミットするときには強制的にオンになります。

          config key: svn.edit

‘-l<num>’
‘--find-copies-harder’
     ‘dcommit’ と ‘set-tree’ と ‘commit-diff’ コマンドでのみ使用されます
     。

     これらは両方とも「git diff-tree」に直接渡されます。 詳細については
     、 git-diff-tree(1) を参照してください。

          config key: svn.l
          config key: svn.findcopiesharder

‘-A<filename>’
‘--authors-file=<filename>’
     構文は「git cvs import」で使用されるファイルと互換性がありますが、
     空の電子メールアドレスを ‘<>’ で指定できます:

                  loginname = Joe User <user@example.com>

     このオプションが指定されていて、「git svn」が authors-file に存在し
     ないSVNコミッター名を検出した場合、「git svn」は操作を中止(abort)し
     ます。 この後、ユーザーは適切なエントリを追加する必要があります。
     authors-file を変更後、 先程の「git svn」コマンドを再実行すると、操
     作が続行されます。

          config key: svn.authorsfile

‘--authors-prog=<filename>’
     このオプションを指定すると、authorsファイルに存在しないSVNコミッタ
     ー名ごとに、指定のファイルを最初の引数としてコミッター名を使用して
     プログラムを実行します。プログラムは、「Name<email>」または「
     Name<>」の形式の1行を返すことが期待されており、これは、authorsファ
     イルに含まれているかのように扱われます。

     歴史的な理由により、相対的な ‘filename’ は、最初に「init」および「
     clone」の現在のディレクトリに対して、そして、「fetch」の作業ツリー
     のルートに対して、相対的に検索されます。 ‘filename’ が見つからない
     場合は、 ‘$PATH’ の他のコマンドと同様に検索されます。

          config key: svn.authorsProg

‘-q’
‘--quiet’
     ‘git svn’ のおしゃべりを減らします。 もう一度指定すると、おしゃべり
     がさらに少なくなります。

‘-m’
‘--merge’
‘-s<strategy>’
‘--strategy=<strategy>’
‘-p’
‘--rebase-merges’
‘--preserve-merges (DEPRECATED)’
     これらは、 ‘dcommit’ と ‘rebase’ コマンドでのみ使用されます。

     「git reset」を使用できない場合、「dcommit」を使用するときに「git
     rebase」に直接渡されます(「dcommit」コマンド参照)。

‘-n’
‘--dry-run’
     これは、 ‘dcommit’ と ‘rebase’ と ‘branch’ と ‘tag’ コマンドで使用
     できます。

     ‘dcommit’ の場合、どのdiffがSVNにコミットされるかを示す一連のGit引
     数を出力します。

     ‘rebase’ の場合、現在のブランチに関連付けられているアップストリーム
     svnリポジトリに関連付けられているローカルブランチと、フェッチ元の
     svnリポジトリのURLを表示します。

     ‘branch’ や ‘tag’ の場合、ブランチまたはタグを作成するときにコピー
     に使用されるURLを表示します。

‘--use-log-author’
     (「fetch」または「rebase」または「dcommit」操作の一部として、)svnの
     コミットをGitに取得する場合、ログメッセージで最初の ‘From:’ 行また
     は ‘Signed-off-by’ トレーラーを探し、それを著者文字列として使用しま
     す。

          config key: svn.useLogAuthor

‘--add-author-from’
     (「set-tree」または「dcommit」操作の一部として)Gitからsvnにコミット
     するとき、既存のログメッセージに ‘From:’ または ‘Signed-off-by’ ト
     レーラーがまだ存在しない場合は、Gitコミットの作者文字列に基づく
     ‘From:’ 行を追加します。 これを使用すると ‘--use-log-author’ はすべ
     てのコミットに対して有効な作者文字列を取得します。

          config key: svn.addAuthorFrom

ADVANCED OPTIONS
****************

‘-i<GIT_SVN_ID>’
‘--id <GIT_SVN_ID>’
     これにより、(環境変数を使用する代わりに) GIT_SVN_ID が設定されます
     。 これにより、ユーザーは単一のURLを追跡するときにフェッチするデフ
     ォルトのrefnameをオーバーライドできます。 ‘log’ コマンドと
     ‘dcommit’ コマンドは、もはや引数としてこのスイッチを必要としなくな
     りました。

‘-R<remote name>’
‘--svn-remote <remote name>’
     使用する [svn-remote "<remote name>"] セクションを指定します。これ
     により、SVNの複数のリポジトリを追跡できます。 デフォルトは ‘svn’ で
     す。

‘--follow-parent’
     このオプションは、ブランチを追跡している場合にのみ関連します(リポジ
     トリレイアウトオプション ‘--trunk’, ‘--tags’, ‘--branches’,
     ‘--stdlayout’ のどれかを使用)。 追跡されたブランチごとに、そのリビ
     ジョンがどこからコピーされたかを調べ、ブランチの最初のGitコミットで
     適切な親を設定しようと試みます。 これは、リポジトリ内で移動されたデ
     ィレクトリを追跡する場合に特に役立ちます。 この機能が無効になってい
     る場合、「git svn」によって作成されたブランチはすべて線形であり、履
     歴を共有しません。つまり、ブランチが分岐またはマージされた場所に関
     する情報はありません。 ただし、長い/複雑 な履歴の追跡には長い時間が
     かかる可能性があるため、この機能を無効にすると、クローン作成プロセ
     スが高速化される可能性があります。 この機能はデフォルトで有効になっ
     ています。無効にするには ‘--no-follow-parent’ を使用します。

          config key: svn.followparent

CONFIG FILE-ONLY OPTIONS
************************

svn.noMetadata
svn-remote.<name>.noMetadata
     これにより、すべてのコミットの最後にある ‘git-svn-id:’ 行が削除され
     ます。

     ‘git svn’ はメタデータなしでは再度フェッチできないため、このオプシ
     ョンはワンショットインポートにのみ使用できます。 さらに、もし、あな
     たが ‘$GIT_DIR/svn/\**/.rev_map.*’ ファイル達を失ってしまっても、
     ‘git svn’ はそれらを再構築できません。

     ‘git svn log’ コマンドは、これを使用するリポジトリ上でも機能しませ
     ん。 これを使用すると、 (うまくいけば)明らかな理由で ‘useSvmProps’
     オプションと競合します。

     このオプションは、既存のドキュメントやバグレポートやアーカイブで
     SVNリビジョン番号への古い参照を追跡するのが困難になるため「お勧めし
     ません」。 最終的にSVNからGitに移行することを計画していて、SVN履歴
     を削除することに確信がある場合は、代わりに git-filter-repo
     (https://github.com/newren/git-filter-repo) を検討してください。
     filter-repoを使用すると、メタデータを再フォーマットして、「
     svn.authorsFile」以外のユーザーの作成者情報を読みやすく書き直しやす
     くすることもできます。

svn.useSvmProps
svn-remote.<name>.useSvmProps
     これにより、「git svn」は、メタデータ用に ‘SVN::Mirror’ (または
     svk)を使用して作成されたミラーからリポジトリのURLとUUIDを再マップで
     きます。

     SVNリビジョンにプロパティ「svm:headrev」がある場合、リビジョンは
     (SVKでも使用される、) SVN::Mirror によって作成された可能性がありま
     す。 プロパティには、リポジトリUUIDとリビジョンが含まれています。 元
     のURLをミラーリングしているように見せるために、元のID URLとUUIDを返
     すヘルパー関数を導入し、コミットメッセージでメタデータを生成すると
     きに使用します。

svn.useSvnsyncProps
svn-remote.<name>.useSvnsyncprops
     useSvmPropsオプションと同様です。 これは、SVN 1.4.x以降で配布されて
     いる svnsync(1) コマンドのユーザー向けです。

svn-remote.<name>.rewriteRoot
     これにより、ユーザーは代替URL(alternate URLs)からリポジトリを作成で
     きます。 たとえば、管理者はサーバー上で ‘git svn’ をローカルで実行
     できますが(file:// 経由でアクセス)、メタデータに パブリック http://
     または svn:// URL を含むリポジトリを配布して、ユーザーにパブリック
     URLが表示されるようにします。

svn-remote.<name>.rewriteUUID
     useSvmPropsオプションと同様です。 これは、UUIDを手動で再マップする
     必要があるユーザー向けです。 これは、 useSvmProps または
     useSvnsyncProps のいずれかを介して元のUUIDを使用できない状況で役立
     つ場合があります。

svn-remote.<name>.pushurl
     Gitの ‘remote.<name>.pushurl’ と同様に、このキーは、 ‘url’ が読み取
     り専用転送(transport)を介してSVNリポジトリを指している場合に使用さ
     れ、代替の 読み取り/書き込み 転送を提供するように設計されています。
     両方のキーが同じリポジトリを指していると想定されています。
     ‘commiturl’ とは異なり、 ‘pushurl’ はベースパスです。 ‘commiturl’ ま
     たは ‘pushurl’ のいずれかを使用できる場合は、 ‘commiturl’ が優先さ
     れます。

svn.brokenSymlinkWorkaround
     これにより、壊れたクライアントによってSVNにチェックインされた壊れた
     シンボリックリンクを回避するための潜在的に高価なチェックが無効にな
     ります。 シンボリックリンクではない空のブロブが多数あるSVNリポジト
     リを追跡する場合は、このオプションを「false」に設定します。 このオ
     プションは、「git svn」の実行中に変更され、フェッチされた次のリビジ
     ョンで有効になる場合があります。 設定されていない場合、「git svn」
     はこのオプションが「true」であると見なします。

svn.pathnameencoding
     これは、パス名を特定のエンコーディングに再コード化するようにgit
     svnに指示します。 Windowsユーザーおよび 非utf-8 のロケールで作業す
     るユーザーが使用して、ASCII以外の文字でファイル名が破損しないように
     することができます。 有効なエンコーディングは、PerlのEncodeモジュー
     ルでサポートされているものです。

svn-remote.<name>.automkdirs
     通常、「git svn clone」および「git svn rebase」コマンドは、
     Subversionリポジトリにある空のディレクトリを再作成しようとします。
     このオプションが「false」に設定されている場合、「git svn mkdirs」コ
     マンドが明示的に実行された場合にのみ、空のディレクトリが作成されま
     す。 設定されていない場合、「git svn」はこのオプションが「true」で
     あると見なします。

   noMetadata と rewriteRoot と rewriteUUID と useSvnsyncProps と
useSvmProps オプションはすべて、「git svn」によって生成および使用される
メタデータに影響を与えるためです。 これらは、履歴をインポートする前に構
成ファイルで設定する必要があります。これらの設定は、一旦設定したら決して
変更してはいけません。

   さらに、これらのオプションは、一緒に使用できる rewriteRoot と
rewriteUUID を除いて、 ‘git-svn-id:’ メタデータ行に影響を与えるため、
svn-remoteセクションごとに使用できるのは1つだけです。

BASIC EXAMPLES
**************

Subversion管理プロジェクトのtrunkの追跡と貢献(タグとブランチを無視):

     # リポジトリのクローン(`git clone` と同様):
             git svn clone http://svn.example.com/project/trunk
     # 新しく複製されたディレクトリに入る:
             cd trunk
     # あなたはmasterブランチにいる必要があります。 `git branch ` で再確認
             git branch
     # いくつかの作業を行い、ローカルでGitにコミットします:
             git commit ...
     # 何かをSVNにコミットし、
     # SVNの最新の変更に対してあなたのローカルの変更をリベースします:
             git svn rebase
     # 次に、変更(先程はGitを使用してコミットしたもの)を
     # SVNにコミットし、作業中のHEADを自動的に更新します:
             git svn dcommit
     # svn:ignore 設定をデフォルトのGit除外ファイルに追加します:
             git svn show-ignore >> .git/info/exclude

   Subversion管理プロジェクト全体の追跡と貢献(trunkとタグとブランチを完
備):

     # 標準のSVNディレクトリレイアウトを使用してリポジトリのクローンを作成します(`git clone`と同様):
             git svn clone http://svn.example.com/project --stdlayout --prefix svn/
     # または、標準でないディレクトリレイアウトを使うリポジトリの場合は:
             git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
     # クローンしたすべてのブランチとタグを表示:
             git branch -r
     # SVNに新しいブランチを作成
             git svn branch waldo
     # masterをtrunk(または他のブランチ。`trunk` は
     # 適切な名前に置き換えて下さい)にリセットします:
             git reset --hard svn/trunk
     # 一度に1つの ブランチ/タグ/trunk にのみコミットできます。
     # dcommit/rebase/show-ignore の使用法は、上記と同じである必要があります。

   最初の「git svn clone」は非常に時間がかかる可能性があります(特に大規
模なSubversionリポジトリの場合)。 複数の人(または複数のマシンを持つ1人
)が同じSubversionリポジトリと対話するために「git svn」を使用したい場合は
、あなたがサーバー上のリポジトリに対して最初の「git svn clone」を実行し
、 ‘git clone’ で各人にそのリポジトリのクローンを作成させることができま
す:

     # サーバーで初期インポートを実行します
             ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
     # ローカルでクローンします - refs/remotes/ 空間 がサーバーと一致することを確認してください
             mkdir project
             cd project
             git init
             git remote add origin server:/pub/project
             git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
             git fetch
     # 今後、リモートGitサーバーからの フェッチ/プル を防止します
     # 今後の更新には git svn のみを使用します
             git config --remove-section remote.origin
     # フェッチしたブランチの1つからローカルブランチを作成します
             git checkout -b master FETCH_HEAD
     # `git svn` をローカルで初期化します(サーバーで使用されたものと同じURLと
     # `--stdlayout`/`-T`/`-b`/`-t`/`-prefix` オプションを使用してください)
             git svn init http://svn.example.com/project [options...]
     # Subversionから最新の変更をプルする
             git svn rebase

REBASE VS. PULL/MERGE
*********************

統合されていないコミットを「git svn」ブランチと同期するには、「git pull」
または「git merge」ではなく、「git svn rebase」または「git rebase」を使
用することをお勧めします。 そうすることで、統合されていないコミットの履
歴がアップストリームSVNリポジトリに対して線形に保たれ、優先される「git
svn dcommit」サブコマンドを使用して統合されていないコミットをSVNにプッシ
ュバックできるようになります。

   当初、「git svn」は、開発者が「git svn」ブランチからプルまたはマージ
することを推奨していました。 これは、作成者が複数のコミットをコミットす
るための ‘git svn set-tree A..B’ 表記ではなく、単一のヘッドをコミットす
るために ‘git svn set-tree B’ を好んだためです。 「git pull」または「git
merge」を、 ‘git svn set-tree A..B’ と一緒に使用すると、SVNにコミットす
るときに非線形履歴がフラット化され、これにより、マージコミットがSVNの以
前のコミットを予期せず逆転させる可能性があります。

MERGE TRACKING
**************

‘git svn’ は、標準レイアウト(standard layout)を採用しているリポジトリの
コピー履歴(ブランチとタグを含む)を追跡できますが、git内でSVNユーザーに戻
って発生したマージ履歴を表すことはできません。 したがって、SVNとの互換性
を容易にするために、ユーザーはGit内で履歴を可能な限り線形に保つことをお
勧めします(下記「CAVEATS」セクション参照)。

HANDLING OF SVN BRANCHES
************************

‘git svn’ がブランチをフェッチするように構成されている場合(そして
‘--follow-branches’ が有効な場合）、1つのSVNブランチに対して複数のGitブ
ランチが作成されることがあり、追加のブランチの名前は
‘branchname@nnn’(nnn はSVNリビジョン番号)形式になります。 これらの追加の
ブランチは、 ‘git svn’ がSVNブランチの最初のコミットの親コミットを見つけ
られない場合に作成され、ブランチを他のブランチの履歴に接続します。

   通常、SVNブランチの最初のコミットはコピー操作で構成されます。 「git
svn」はこのコミットを読み取り、ブランチが作成されたSVNリビジョンを取得し
ます。次に、このSVNリビジョンに対応するGitコミットを見つけようとし、それ
をブランチの親として使用します。ただし、親として機能する適切なGitコミッ
トがない可能性があります。 これは、他の理由の中でも特に、SVNブランチが「
git svn」によってフェッチされなかったリビジョンのコピーである場合(たとえ
ば、 ‘–revision‘でスキップされた古いリビジョンであるため)、またはSVNで「
git svn」によって追跡されないディレクトリがコピーされた場合(まったく追跡
されていないブランチ、または追跡されたブランチのサブディレクトリなど)に
発生します。 このような場合、「git svn」は引き続きGitブランチを作成しま
すが、ブランチの親として既存のGitコミットを使用する代わりに、ブランチの
コピー元のディレクトリのSVN履歴を読み取り、適切なGitコミットを作成します
。これは、 "Initializing parent: <branchname>" というメッセージで示され
ます。

   さらに、 ‘<branchname>@<SVN-Revision>’ という名前の特別なブランチを作
成します。ここで、<SVN-Revision> は、ブランチのコピー元のSVNリビジョン番
号です。 このブランチは、ブランチの新しく作成された親コミットを指します
。 SVNでブランチが削除され、後で別のバージョンから再作成された場合、 ‘@’
が付いたこのようなブランチが複数存在します。

   これは、単一のSVNリビジョンに対して複数のGitコミットが作成されること
を意味する場合があることに注意してください。

   例: 標準の トランク/タグ/ブランチ レイアウトのSVNリポジトリでは、ディ
レクトリ ‘trunk/sub’ が ‘r.100’ に作成されます。 ‘r.200’ では、
‘trunk/sub’ は ‘branchs/’ にコピーすることで分岐します。 ‘git svn clone
-s`は、ブランチ `sub’ を作成します。 また、 ‘r.100’ から ‘r.199’ までの
新しいGitコミットを作成し、これらをブランチ ‘sub’ の履歴として使用します
。 したがって、 ‘r.100’ から ‘r.199’ までのリビジョンごとに2つのGitコミ
ットがあります(1つは ‘trunk/’ を含み、もう1つは ‘trunk/sub/’ を含みます
)。 最後に、ブランチ ‘sub’ の新しい親コミットを指すブランチ ‘sub@200’ を
作成します(つまり、 ‘r.200’ および ‘trunk/sub/’ のコミット)。

CAVEATS
*******

単純化とSubversionとの相互運用のために、すべての「git svn」ユーザーが
SVNサーバーから直接クローンを作成し、フェッチしてdcommitし、Gitリポジト
リとブランチ間で、すべての 「git clone」/「pull」/「merge」/「push」 操
作を回避することをお勧めします。Gitブランチとユーザーの間でコードを交換
するための推奨される方法は、「git format-patch」と「git am」、または単に
「SVNリポジトリへのdcommit」です。

   「dcommit」を計画しているブランチで「git merge」または「git pull」を
実行することはお勧めしません。Subversionユーザーはあなたが行ったマージを
見ることができないからです。 さらに、SVNブランチのミラーであるGitブラン
チからマージまたはプルすると、「dcommit」が間違ったブランチにコミットす
る可能性があります。

   マージする場合は、以下のルールに注意してください: ‘git svn dcommit’ は
、以下で指定されたSVNコミット上でコミットを試みます

     git log --grep=^git-svn-id: --first-parent -1

   したがって、dcommitするブランチの最新のコミットがマージの「最初の」親
であることを確認する「必要」があります。 特に最初の親が同じSVNブランチの
古いコミットである場合は、混沌(chaos)になります。

   ‘git clone’ は ‘refs/remotes/’ 階層下のブランチや ‘git svn’ のメタデ
ータや設定をクローンしません。 そのため、‘git svn’ を使って作成・管理さ
れたリポジトリのクローンを作成する場合は ‘rsync’ を使用する必要がありま
す。

   ‘commit’ は内部でリベースを使用しているので、 ‘dcommit’ の前に ‘git
push’ した Git ブランチは、リモートリポジトリの既存の ref を強制的に上書
きする必要があります。 詳細は git-push(1) ドキュメントを参照ください。

   すでにコミットした変更に、 git-commit(1) の ‘--amend’ オプションを使
用しないでください。 他のユーザーのためのリモートリポジトリにすでにプッ
シュしたコミットを修正することは悪い習慣と考えられており、SVNを使用した
dcommitはそれに類似しています。

   SVNリポジトリのクローンを作成するときに、リポジトリレイアウトを記述す
るためのオプション(‘--trunk’, ‘--tags’, ‘--branches’, ‘--stdlayout’)が使
用されてい無い場合、 ‘git svn clone’ は完全に線形の履歴を持つGitリポジト
リを作成します 、ブランチとタグは作業コピーで別々のディレクトリとして表
示されます。 これは完全なリポジトリのコピーを取得する最も簡単な方法です
が、多くのブランチを持つプロジェクトの場合、トランクだけの何倍ものサイズ
の作業コピーになります。 したがって、標準のディレクトリ構造
(trunk/branchs/tags)を使用するプロジェクトの場合、オプション
‘--stdlayout’ を使用してクローンを作成することをお勧めします。 プロジェ
クトが非標準の構造を使用している場合、および/または ブランチとタグが不要
な場合は、リポジトリのレイアウトオプションを指定せずに、1つのディレクト
リ(通常はトランク)のみを複製するのが最も簡単です。 ブランチとタグを含む
完全な履歴が必要な場合は、オプション ‘--trunk’/‘--branches’/‘--tags’ を
使用する必要があります。

   複数の ‘--branches’ または ‘--tags’ を使用する場合、「git svn」は名前
の衝突を自動的に処理しません(たとえば、異なるパスからの2つのブランチが同
じ名前である場合、またはブランチとタグが同じ名前である場合)。 このような
場合は、「init」を使用してGitリポジトリを設定し、最初の「フェッチ」の前
に、ブランチとタグが異なる名前空間に関連付けられるように $GIT_DIR/config
ファイルを編集します。 例えば:

     branches = stable/*:refs/remotes/svn/stable/*
     branches = debug/*:refs/remotes/svn/debug/*

CONFIGURATION
*************

「git svn」は、 [svn-remote] 構成情報をリポジトリ $GIT_DIR/config ファイ
ルに保存します。 ‘fetch’ キーがglob引数を受け入れないことを除いて、コア
Gitの [remote] セクションに似ています。 ただし、代わりに ‘'branches’ キ
ーと ‘tags’ キーによって処理されます。 一部のSVNリポジトリは、複数のプロ
ジェクトで奇妙に構成されているため、以下にリストされているようなグロブ拡
張が許可されます:

     [svn-remote "project-a"]
             url = http://server.org/svn
             fetch = trunk/project-a:refs/remotes/project-a/trunk
             branches = branches/*/project-a:refs/remotes/project-a/branches/*
             branches = branches/release_*:refs/remotes/project-a/branches/release_*
             branches = branches/re*se:refs/remotes/project-a/branches/*
             tags = tags/*/project-a:refs/remotes/project-a/tags/*

   (‘:’ の右側の)ローカル参照の ‘*’(アスタリスク)ワイルドカードは、 最も
右のパスコンポーネントである必要があることに注意してください。 ただし、
リモートのワイルドカードは、独立したパスコンポーネント (‘/’ または EOLで
囲まれている)である限り、どこにあってもかまいません。 このタイプの構成は
、 ‘init’ によって自動的に作成されるわけではないため、 テキストエディタ
ーまたは ‘git config’ を使用して手動で入力する必要があります。

   また、単語ごとに1つのアスタリスク(‘*’)のみが許可されていることに注意
してください。 例えば:

     branches = branches/re*se:refs/remotes/project-a/branches/*

   ただし、これは、ブランチ ‘release’ 、‘rese’ 、‘re123se’ とマッチしま
す

     branches = branches/re*s*e:refs/remotes/project-a/branches/*

   これはエラーを発生させます。

   中括弧(‘{’ , ‘}’)内の名前のコンマ(‘,’)区切りリストを使用して、ブラン
チまたはタグのサブセットをフェッチすることもできます。 例えば:

     [svn-remote "huge-project"]
             url = http://server.org/svn
             fetch = trunk/src:refs/remotes/trunk
             branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
             tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*

   複数フェッチとブランチとタグキーがサポートされています:

     [svn-remote "messy-repo"]
             url = http://server.org/svn
             fetch = trunk/project-a:refs/remotes/project-a/trunk
             fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
             branches = branches/server/*:refs/remotes/project-a/branches/*
             branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
             tags = tags/server/*:refs/remotes/project-a/tags/*

   このような構成でブランチを作成するには、 ‘-d’ または ‘--destination’
フラグを使用して使用する場所を明確にする必要があります:

     $ git svn branch -d branches/server release-2-3-0

   git-svnは、ブランチまたはタグが出現した最高のリビジョン(highest
revision)を追跡することに注意してください。 フェッチ後にブランチまたはタ
グのサブセットが変更された場合は、 ‘$GIT_DIR/svn/.metadata’ を手動で編集
して、必要に応じて branches-maxRev および/または tags-maxRev を削除(また
はリセット)する必要があります。

FILES
*****

$GIT_DIR/svn/**/.rev_map.*
     Subversionリビジョン番号とGitコミット名の間のマッピング。
     noMetadataオプションが設定されていないリポジトリでは、これはすべて
     のコミットの最後にある ‘git-svn-id:’ 行から再構築できます(詳細につ
     いては、上記「svn.noMetadata」セクションを参照してください)。

     ‘git svn fetch’ および ‘git svn rebase’ は、rev_mapが欠落しているか
     最新でない場合、自動的に更新します。 ‘git svn reset’ は自動的にそれ
     を巻き戻します。

BUGS
****

svn:executable を除くすべてのSVNプロパティを無視します。 未処理のプロパ
ティはすべて ‘$GIT_DIR/svn/<refname>/unhandled.log’ に記録されます

   名前変更とコピーされたディレクトリはGitによって検出されないため、
SVNにコミットするときに追跡されません。 考えられるすべてのレアケース
(corner cases)に対応する作業を行うのは非常に困難で時間がかかるため、これ
に対するサポートを追加する予定はありません(Gitもサポートしていません)。
名前変更とコピーされたファイルのコミットは、Gitがそれらを検出するのに十
分類似している場合、完全にサポートされます。

   SVNでは、(推奨されていませんが)タグへの変更をコミットすることが可能で
す(タグは単なるディレクトリコピーであり、技術的にはブランチと同じである
ため)。 SVNリポジトリのクローンを作成する場合、「git svn」は、タグへのそ
のようなコミットが将来発生するかどうかを知ることができません。 したがっ
て、保守的な動作を行い、すべてのSVNタグをブランチとしてインポートし、タ
グ名の前に ‘tags/’ 接頭辞を付けます。

SEE ALSO
********

git-rebase(1)

GIT
***

Part of the git(1) suite

Name
****

git-switch — ブランチを切り替える

Synopsis
********

     git switch [<options>] [–no-guess] <branch>
     git switch [<options>] –detach [<start-point>]
     git switch [<options>] (-c|-C) <new-branch> [<start-point>]
     git switch [<options>] –orphan <new-branch>

DESCRIPTION
***********

指定のブランチに切り替えます。作業ツリーとインデックスは、ブランチに一致
するように更新されます。新規コミットは、全てこのブランチの先端に追加され
ることになります。

   オプションで、同じ名前のリモートブランチから自動的に ‘-c’ や ‘-C’ を
使用して新しいブランチを作成するか(‘--guess’ 参照)、あるいは切り替え時に
‘--detach’ を使用して任意のブランチから作業ツリーをデタッチできます。

   ブランチを切り替えるには、クリーンなインデックスと作業ツリーは必要あ
りません(つまり、「HEAD」との違いはありません)。ただし、操作によってロー
カル変更が失われる場合、 ‘--discard-changes’ または ‘--merge’ で特に指示
されない限り、操作は中止されます。

   !!このコマンドは実験的なものです。 動作が変わる可能性があります!!

OPTIONS
*******

<branch>
     切り替え先のブランチ

<new-branch>
     新ブランチの名前

<start-point>
     新ブランチの開始点。 ‘<start-point>’ を指定すると、HEADが現在指し示
     している場所以外の履歴内の場所に基づいてブランチを作成できます。(ま
     たは、 ‘--detach’ の場合、他の場所から検査してデタッチすることがで
     きます。)

     ‘@{-N}’ 構文を使用して、「git switch」または「git checkout」操作を
     使用して切り替えられた最後からN番目のブランチ/コミットを参照できま
     す。 ‘@{-1}’ と同義の ‘-’ を指定することもできます。これは、2つのブ
     ランチをすばやく切り替えたり、誤って切り替えたブランチを元に戻した
     りするためによく使用されます。

     特別な場合として、マージベースが1つしかない場合は、 ‘A’ と ‘B’ のマ
     ージベースのショートカットとして ‘A...B’ を使用できます。 ‘A’ と
     ‘B’ のうち片方を省略できます。その場合、省略した方はデフォルトで
     ‘HEAD’ になります。

‘-c <new-branch>’
‘--create <new-branch>’
     ブランチに切り替える前に、 ‘<start-point>’ で始まる ‘<new-branch>’
     という名前の新しいブランチを作成します。これは以下に代わる便利なシ
     ョートカットです:

          $ git branch <new-branch>
          $ git switch <new-branch>

‘-C <new-branch>’
‘--force-create <new-branch>’
     ‘--create`と似ていますが、 `<new-branch>’ がすでに存在する場合、
     ‘<start-point>’ にリセットされる点が異なります。これは以下に代わる
     便利なショートカットです:

          $ git branch -f <new-branch>
          $ git switch <new-branch>

‘-d’
‘--detach’
     検査と破棄可能な実験のためのコミットに切り替えます。詳細については
     、 git-checkout(1) の「DETACHED HEAD」セクションを参照してください
     。

‘--guess’
‘--no-guess’
     ‘<branch>’ が見つからないが、名前が一致するリモートが正確に1つだけ
     あり(‘<remote>’ と呼びます)、それに追跡ブランチが存在する場合は、以
     下と同等のものとして扱います。

          $ git switch -c <branch> --track <remote>/<branch>

     ブランチが複数のリモートに存在し、そのうちの1つが
     ‘checkout.defaultRemote’ 構成変数によって名前が付けられている場合、
     ‘<branch>’ がすべてのリモートで一意でなくても、曖昧さ回避の目的でそ
     のブランチを使用します。例えば、 ‘<branch>’ があいまいであるが、
     _origin_ リモートに存在する場合、そこからリモートブランチを常にチェ
     ックアウトするには、これを ‘checkout.defaultRemote=origin’ と設定し
     ます。 git-config(1) の ‘checkout.defaultRemote’ も参照してください
     。

     ‘--guess’ がデフォルトの動作です。無効にするには、 ‘--no-guess’ を
     使用します。

     デフォルトの動作は、 ‘checkout.guess’ 構成変数で設定できます。

‘-f’
‘--force’
     ‘--discard-changes’ のエイリアス。

‘--discard-changes’
     インデックスまたは作業ツリーが ‘HEAD’ と異なっていても続行します。
     インデックスと作業ツリーの両方が、切り替え先(switching target)に一
     致するように復元されます。 ‘--recurse-submodules’ が指定されている
     場合、サブモジュールの内容も切り替え先に一致するように復元されます
     。これは、ローカルの変更を破棄するために使用されます。

‘-m’
‘--merge’
     現在のブランチと切り替え先のブランチの間で異なる1つ以上のファイルに
     ローカルの変更がある場合、コマンドは、変更をコンテキストに保持する
     ためにブランチの切り替えを拒否します。 ただし、このオプションを使用
     すると、現在のブランチ、作業ツリーの内容、および新しいブランチの間
     の3方向のマージが実行され、新しいブランチに移動します。

     マージの競合が発生すると、競合するパスのインデックスエントリはマー
     ジされないままになり、競合を解決し、解決されたパスを ‘git add’ (ま
     たはマージによってパスが削除される場合は ‘git rm’)でマークする必要
     があります。

‘--conflict=<style>’
     上記の ‘--merge’ オプションと同じですが、競合するハンクの表示方法を
     変更し、 ‘merge.conflictStyle’ 構成変数をオーバーライドします。指定
     可能な値は「merge」(デフォルト)と「diff3」(「merge」スタイルで表示
     されるものに加えて、元のコンテンツを表示)です。

‘-q’
‘--quiet’
     静かにします。フィードバックメッセージを抑制します。

‘--progress’
‘--no-progress’
     ‘--quiet’ が指定されていない限り、進行状況は、端末に接続されている
     場合、デフォルトで標準エラーストリームに報告されます。このフラグは
     、 ‘--quiet’ に関係なく、端末に接続されていない場合でも進行状況のレ
     ポートを有効にします。

‘-t’
‘--track’
     新しいブランチを作成するときは、 "upstream" 構成をセットアップしま
     す。 ‘-c’ が暗黙に指定されたものと見なします。詳細については、
     git-branch(1) の ‘--track’ を参照してください。

     ‘-c’ オプションが指定されていない場合、新しいブランチの名前は、対応
     するリモート用に構成されたrefspecのローカル部分を調べ、次に、最初の
     部分を「*」まで削除することにより、リモート追跡ブランチから取得され
     ます。これは、 ‘origin/hack’ (または ‘remotes/origin/hack’ あるいは
     ‘refs/remotes/origin/hack’)から分岐するときに、ローカルブランチとし
     て ‘hack’ を使用するように指示します。指定された名前にスラッシュ
     (/)がない場合、または上記の推測の結果が空の名前になる場合、推測は中
     止されます。このような場合は、 ‘-c’ を使用して明示的に名前を付ける
     ことができます。

‘--no-track’
     ‘branch.autoSetupMerge’ 構成変数がtrueであっても、 "upstream" 構成
     をセットアップしない。

‘--orphan <new-branch>’
     ‘<new-branch>’ という名前の新しい 「孤立した」(orphan)ブランチを作
     成します。追跡中のファイルはすべて削除されます。

‘--ignore-other-worktrees’
     ‘git switch’ は、必要なrefが別のワークツリーによってすでにチェック
     アウトされている場合に拒否します。このオプションを使用すると、とに
     かくrefをチェックアウトできます。つまり、refは複数のワークツリーで
     保持できます。

‘--recurse-submodules’
‘--no-recurse-submodules’
     ‘--recurse-submodules’ を使用すると、スーパープロジェクト(親プロジ
     ェクト)に記録されたコミットに従って、すべてのアクティブなサブモジュ
     ールのコンテンツが更新されます。何も使用されていない(または
     ‘--no-recurse-submodules’)場合、サブモジュールの作業ツリーは更新さ
     れません。 git-submodule(1) と同様に、これはサブモジュールの ‘HEAD’
     を切り離します(detach)。

EXAMPLES
********

以下のコマンドは "master" ブランチに切り替えます:

     $ git switch master

   間違ったブランチで作業した後、正しいブランチへの切り替えは以下を使用
して行われます:

     $ git switch mytopic

   ただし、「間違った」ブランチと正しい「mytopic」ブランチは、ローカルで
変更したファイルが異なる場合があります。その場合、上記のswitchは以下のよ
うに失敗します:

     $ git switch mytopic
     error: You have local changes to 'frotz'; not switching branches.

   コマンドに ‘-m’ フラグを指定すると、3方向のマージを試行します:

     $ git switch -m mytopic
     Auto-merging frotz

   この3者間マージの後、ローカルの変更はインデックスファイルに登録されな
いため、 ‘git diff’ は、新しいブランチの先端以降に行った変更を示します。

   mytopicに切り替える前に前のブランチ(つまり、 "master" ブランチ)に戻す
には:

     $ git switch -

   どのコミットからでも新しいブランチを成長させることができます。たとえ
ば、 "HEAD~3" に切り替えて、ブランチ "fixup" を作成します:

     $ git switch -c fixup HEAD~3
     Switched to a new branch 'fixup'

   同じ名前のリモートブランチから新しいブランチを開始する場合:

     $ git switch new-topic
     Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin'
     Switched to a new branch 'new-topic'

   新しいブランチを作成せずに、一時的な検査または実験のためにコミット
‘HEAD~3’ をチェックアウトするには:

     $ git switch --detach HEAD~3
     HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

   一時的な検査または実験のために行ったことに維持する価値があることが判
明した場合は、(切り替えることなく)、いつでも新しい名前を作成できます:

     $ git switch -c good-surprises

SEE ALSO
********

git-checkout(1), git-branch(1)

GIT
***

Part of the git(1) suite

Name
****

git-symbolic-ref — シンボリックrefの読み取り、変更、および削除

Synopsis
********

     git symbolic-ref [-m <reason>] <name> <ref>
     git symbolic-ref [-q] [–short] <name>
     git symbolic-ref –delete [-q] <name>

DESCRIPTION
***********

引数が1つ与えられると、指定されたシンボリックrefが参照するブランチヘッド
を読み取り、 ‘.git/’ ディレクトリを基準にしてそのパスを出力します。 通常
、作業ツリーがどのブランチにあるかを確認するには、 <name> 引数として
‘HEAD’ を指定します。

   2つの引数を与えると、指定されたブランチ <ref> を指すようにシンボリッ
クref <name> を作成または更新します。

   ‘--delete’ と追加の引数を指定すると、指定されたシンボリックrefが削除
されます。

   シンボリックrefは、 ‘ref: refs/’ で始まる文字列を格納する通常のファイ
ルです。 たとえば、 ‘.git/HEAD’ は、内容が ‘ref: refs/heads/master’ であ
る通常のファイルです。

OPTIONS
*******

‘-d’
‘--delete’
     シンボリックref <name> を削除します。

‘-q’
‘--quiet’
     <name> がシンボリックrefではなく、切り離されたHEAD(detached HEAD)で
     ある場合は、エラーメッセージを発行しないでください。 代わりに、ゼロ
     以外のステータスで何も言わずに終了します。

‘--short’
     <name> の値をシンボリックrefとして表示する場合は、値を短くする事を
     試みます。例えば ‘refs/heads/master’ から ‘master’ へ。

‘-m’
     <name> のreflogを <reason> で更新します。これは、シンボリックrefを
     作成または更新する場合にのみ有効です。

NOTES
*****

以前は、 ‘.git/HEAD’ は ‘refs/heads/master’ を指すシンボリックリンクでし
た。別のブランチに切り替えたい場合は、 ‘ln -sf refs/heads/newbranch
.git/HEAD’ を実行し、現在のブランチを確認したい場合は、 ‘readlink
.git/HEAD’ を実行しました。 ただし、シンボリックリンクは完全に移植可能で
はないため、非推奨になり、(上記のとおり)シンボリックrefがデフォルトで使
用されます。

   _git symbolic-ref_ は、シンボリックrefの内容が正しく出力された場合は
ステータス0で終了し、要求された名前がシンボリックrefでない場合はステータ
ス1で終了し、別のエラーが発生した場合は128で終了します。

GIT
***

Part of the git(1) suite

Name
****

git-tag — GPG署名されたタグオブジェクトを作成、一覧表示、削除、検証しま
す

Synopsis
********

     git tag [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e]
             <tagname> [<commit> | <object>]
     git tag -d <tagname>…
     git tag [-n[<num>]] -l [–contains <commit>] [–no-contains <commit>]
             [–points-at <object>] [–column[=<options>] | –no-column]
             [–create-reflog] [–sort=<key>] [–format=<format>]
             [–merged <commit>] [–no-merged <commit>] [<pattern>…]
     git tag -v [–format=<format>] <tagname>…

DESCRIPTION
***********

タグを削除、一覧表示、検証するために ‘-d/-l/-v’ が指定されていない限り、
‘refs/tags/’ にタグ参照を追加します。

   ‘-f’ が指定されていない限り、名前付きタグはまだ存在してはいけません。

   ‘-a’, ‘-s’, ‘-u <keyid>’ のいずれかが渡されると、コマンドは「タグ」オ
ブジェクトを作成し、タグメッセージを必要とします。 ‘-m<msg>’ または
‘-F<file>’ が指定されていない限り、ユーザーがタグメッセージを入力するた
めのエディターが起動します。

   ‘-m<msg>’ または ‘-F<file>’ が指定され、 ‘-a’ と ‘-s’ と ‘-u <keyid>’
がない場合、 ‘-a’ が暗黙に指定されます。

   それ以外の場合は、指定されたオブジェクトを直接指すタグ参照(つまり、軽
量タグ)が作成されます。

   ‘-s’ または ‘-u<keyid>’ を使用すると、GnuPG署名付きタグオブジェクトが
作成されます。 ‘-u <keyid>’ が使用されていない場合、現在のユーザーのコミ
ッターIDを使用して、署名用のGnuPGキーが検索されます。 構成変数
‘gpg.program’ は、カスタムGnuPGバイナリを指定するために使用されます。

   (‘-a’ または ‘-s’ または ‘-u’ で作成した)タグオブジェクトは「注釈付き
」タグ(annotated tags)と呼ばれます。 これらには、作成日や、タグ付け者
(tagger)の名前と電子メールアドレスや、タグ付けメッセージや、オプションの
GnuPG署名が含まれています。 一方、「軽量」タグ(lightweight tag)は単にオ
ブジェクト(通常はコミットオブジェクト)の名前が含まれています。

   注釈付きタグはリリース用であり、軽量タグはプライベートまたは一時オブ
ジェクトラベル用です。 このため、オブジェクトに名前を付けるための一部の
gitコマンド( ‘git describe’ など)は、デフォルトでは軽量タグを無視します
。

OPTIONS
*******

‘-a’
‘--annotate’
     署名されていない注釈付きのタグオブジェクトを作成します

‘-s’
‘--sign’
     デフォルトの電子メールアドレスのキーを使用して、GPG署名付きタグを作
     成します。 タグGPG署名のデフォルトの動作は、存在する場合は
     ‘tag.gpgSign’ 構成変数によって制御され、存在しない場合は無効になり
     ます。 git-config(1) を参照してください。

‘--no-sign’
     すべてのタグに強制的に署名するように設定されている ‘tag.gpgSign’ 構
     成変数をオーバーライドします。

‘-u <keyid>’
‘--local-user=<keyid>’
     指定されたキーを使用して、GPG署名付きタグを作成します。

‘-f’
‘--force’
     既存のタグを、(失敗して終了するのではなく、)指定された名前に置き換
     えます

‘-d’
‘--delete’
     指定された名前の既存のタグを削除します。

‘-v’
‘--verify’
     指定されたタグ名のGPG署名を検証(verify)します。

‘-n<num>’
     <num> は、‘-l’ を使用したときに、注釈を何行出力するか指定します。
     ‘--list’ の指定を含んでいます。

     デフォルトでは、注釈行は印刷されません。 ‘-n’ に番号が指定されてい
     ない場合、最初の行のみが出力されます。 タグに注釈が付けられていない
     場合は、代わりにコミットメッセージが表示されます。

‘-l’
‘--list’
     タグを一覧表示します。オプションで ‘<pattern>...’ を指定すると、例
     えば ‘git tag --list 'v-*'’ のように、パターンにマッチするタグのみ
     をリストアップします。

     引数なしで ‘git tag’ を実行した時も、すべてのタグが一覧表示されます
     。 パターンはシェルワイルドカードです(つまり、fnmatch(3) を使用して
     マッチします)。 複数のパターンを指定できます。 それらのいずれかがマ
     ッチする場合、タグが表示されます。

     このオプションは、 ‘--contains’ などの他のリストっぽいオプション
     (list-like option)が提供されている場合に暗黙的に提供されます。 詳細
     については、これらの各オプションのドキュメントを参照してください。

‘--sort=<key>’
     指定されたキーに基づいて並べ替えます。 接頭辞 ‘-’ を使用して、値の
     降順で並べ替えます。 ‘-sort=<key>’ オプションは複数回使用できます。
     その場合、最後のキーが主キーになります。 "version:refname" または
     "v:refname" もサポートします(タグ名はバージョンとして扱われます)。
     "version:refname" のソート順は、 ‘versionsort.suffix’ 構成変数の影
     響も受ける可能性があります。 サポートされているキーは、‘git
     for-each-ref’ のキーと同じです。 並べ替え順序は、デフォルトで、
     ‘tag.sort’ 変数が存在する場合は設定された値になり、存在しない場合は
     辞書式順序(lexicographic order)になります。 git-config(1) を参照し
     てください。

‘--color[=<when>]’
     ‘--format’ オプションで指定された色を尊重します。 ‘<when>’ フィール
     ドは ‘always’, ‘never’, ‘auto’ のいずれかでなければなりません
     (‘<when>’ がない場合は、 ‘always’ が指定されたかのように振る舞いま
     す)。

‘-i’
‘--ignore-case’
     タグの並べ替えとフィルタリングでは英大文字小文字は区別されません
     (case insensitive)。

‘--column[=<options>]’
‘--no-column’
     タグリストを列(columns)に表示します。 オプションの構文については、
     構成変数 ‘column.tag’ を参照してください。 オプションのない
     ‘--column’ と ‘--no-column’ は、それぞれ ‘always’ と ‘never’ と同等
     です。

     このオプションは、注釈行(annotation lines)のないタグをリストする場
     合にのみ適用できます。

‘--contains [<commit>]’
     指定されたコミットを含むタグのみをリストします(指定されていない場合
     はHEAD)。 ‘--list’ の指定を含んでいます。

‘--no-contains [<commit>]’
     指定されたコミットを含まないタグのみをリストします(指定されていない
     場合はHEAD)。 ‘--list’ の指定を含んでいます。

‘--merged [<commit>]’
     指定されたコミットから、コミットに到達できるタグのみをリストします
     (指定されていない場合は ‘HEAD’)。

‘--no-merged [<commit>]’
     指定されたコミットから、コミットに到達できないタグのみをリストしま
     す(指定されていない場合は ‘HEAD’)。

‘--points-at <object>’
     指定されたオブジェクトのタグのみを一覧表示します(指定されていない場
     合はHEAD)。 ‘--list’ の指定を含んでいます。

‘-m <msg>’
‘--message=<msg>’
     (プロンプトを表示する代わりに)指定されたタグメッセージを使用します
     。 複数の ‘-m’ オプションが指定されている場合、それらの値は個別の段
     落として連結されます。 ‘-a’ と ‘-s’ と ‘-u <keyid>’ のいずれも指定
     されていない場合は、 ‘-a’ を意味します。

‘-F <file>’
‘--file=<file>’
     指定されたファイルからタグメッセージを取得します。 ‘-’ を使用して、
     標準入力からメッセージを読み取ります。 ‘-a’ と ‘-s’ と ‘-u <keyid>’
     のいずれも指定されていない場合は、 ‘-a’ を意味します。

‘-e’
‘--edit’
     ‘-F’ を使用してファイルから取得したメッセージと、 ‘-m’ を使用してコ
     マンドラインを使用したメッセージは、通常は編集しないタグメッセージ
     として使用されます。 このオプションを使用すると、これらのソースから
     取得したメッセージをさらに編集できます。

‘--cleanup=<mode>’
     このオプションは、タグメッセージのクリーンアップ方法を設定します。
     ‘<mode>’ は、 ‘verbatim’, ‘whitespace’, ‘strip’ のいずれかになりま
     す。 ‘strip’ モードがデフォルトです。 ‘verbatim’ モードはメッセージ
     をまったく変更せず、‘whitespace’ は 先頭/末尾 の空白行のみを削除し
     、‘strip’ は空白(whitespace)とコメント(commentary)の両方を削除しま
     す。

‘--create-reflog’
     タグのreflogを作成します。 タグのreflogをグローバルに有効にするには
     、 git-config(1) の ‘core.logAllRefUpdates’ を参照してください。 否
     定形式 ‘--no-create-reflog’ は、(コマンドラインで)それ以前に指定さ
     れた ‘--create-reflog’ をオーバーライドするだけですが、現在のところ
     、‘core.logAllRefUpdates’ の設定を否定しません。

‘--format=<format>’
     表示されているタグrefとそれが指すオブジェクトを ‘%(fieldname)’ によ
     って差し込みする文字列。 形式はgit-for-each-ref(1) の形式と同じです
     。 指定しない場合、デフォルトは ‘%(refname:strip=2)’ です。

<tagname>
     作成または削除または説明するタグの名前。 新しいタグ名は、
     git-check-ref-format(1) で定義されているすべてのチェックに合格する
     必要があります。 これらのチェックの一部は、タグ名で許可される文字を
     制限する場合があります。

<commit>
<object>
     新しいタグが参照するオブジェクト、通常はコミット。 デフォルトは
     HEADです。

CONFIGURATION
*************

デフォルトでは、 sign-with-default モード(‘-s’)の ‘git tag’ は、コミッタ
ーID(‘Your Name <your@email.address>’ 形式)を使用してキーを検索します。
別のデフォルトキーを使用する場合は、リポジトリ構成(repository
configuration)で以下のように指定できます:

     [user]
         signingKey = <gpg-keyid>

   ‘pager.tag’ は、タグを一覧表示する場合、つまり ‘-l’ が使用または暗示
されている場合にのみ尊重されます。 デフォルトではpagerを使用します。
git-config(1) を参照してください。

DISCUSSION
**********

On Re-tagging
=============

間違ったコミットにタグを付けてしまいました。再度タグを付けたい場合はどう
すればよいですか？

   あなたがまだ何もプッシュしたことがない場合は、タグを付け直してくださ
い。 古いものを置き換えるには ‘-f’ を使用します。 これで完了です。

   しかし、あなたが何かプッシュした場合(または他の人があなたのリポジトリ
を直接読み取ることができた場合)、他の人はすでに古いタグを見ているでしょ
う。 その場合、あなたは以下の2つのいずれかを実行できます:

  1. 常識的には、失敗したことを認めて、別の名前を使用してください。 他の
     人は既にとあるタグ名を見たことがあり、同一の名前を保持している場合
     、2人が両方とも「バージョンX」を持っているように見える状況にあるか
     もしれませんが、実際には「異なる」「X」を持っています。 だから、そ
     れを「X.1」と呼んで、それで終わりです。

  2. 非常識なやり方は、他の人がすでに古いバージョンを見たとしても、あな
     たは本当に新しいバージョンを「X」と呼びたいのです。 したがって、古
     いものをまだ公開していないかのように、もう一度 ‘git tag -f’ を使用
     します。

   しかしながら、Gitは、ユーザーの背後でタグを変更することはありません
(また、変更すべきではありません)。 ですから、誰かが既に古いタグを取得し
ている場合、あなたのツリーで ‘git pull’ を実行しても、古いタグを上書きす
ることにはならないはずです。

   誰かがあなたからリリースタグを取得した場合、あなた自身のタグを更新す
ることで、その人のタグを変更することはできません。これは、人々が自分のタ
グ名を信頼できなければならないという点で、大きなセキュリティ上の問題です
。 もしあなたが本当に非常識なことをしたいのであれば、素直に白状して、自
分が失敗したことを人々に伝える必要があります。そうするには、以下のように
公言すればよいでしょう:

     私はやらかしちまって、間違いのあるバージョンをXとタグ付けしてプッシュしてしまいました。
     それから私は、その何かを修正し、「修正された」ツリーを再度Xとしてタグ付けしました。

     あなたが既に間違ったタグを取得してしまっていて、新しいタグが必要な場合は、
     古いタグを削除し、以下の手順を実行して新しいタグをフェッチしてください。お願いします:

             git tag -d X
             git fetch origin tag X

     これで更新されたタグを取得します。

     あなたは以下のようにしてあなたの持っているタグをテストできます

             git rev-parse X

     これは、あなたが新しいバージョンを持っているなら、 0123456789abcdef.. と返されるはずです。

     ご不便おかけしてすみませんでした。

   これは少し複雑に見えますか？ 然り。 自動的に「修正」するだけで正しく
なる方法はありません。 人々にタグが変更された可能性があることを知らせる
必要があります。

On Automatic following
======================

他の誰かのツリーを追っている場合は、リモート追跡ブランチ(例:
‘refs/remotes/origin/master’)を使用している可能性があります。 通常、相手
側からのタグが必要です。

   一方、他の誰かからの一回限りの(one-shot)マージが必要なためにフェッチ
している場合は、通常、そこからタグを取得する必要はありません。 これは、
トップレベルに近い人によく起こりますが、それに限定されません。 神ならぬ
人々は、お互いからプルするとき、必ずしも相手からプライベートアンカーポイ
ントタグを自動的に取得したいとは思いません。

   多くの場合、メーリングリストの「プルしてください」というメッセージは
、リポジトリのURLとブランチ名の2つの情報を提供するだけです。 これは、
‘git fetch’ コマンドラインの最後で簡単にカットアンドペーストできるように
設計されています:

     リーナス、更新を取得するために、

             git://git..../proj.git master

     上記から取得してください。

   とあれば、以下のようになります:

     $ git pull git://git..../proj.git master

   このような場合、あなたは相手のタグを自動的に追跡したくはないでしょう
。

   Gitの重要な側面の1つは分散型であり、これは主にシステムに固有の「上流
」(upstream)または「下流」(downstream)がないことを意味します。 一見する
と、上記の例は、タグの名前空間が上層部の人々によって所有されており、タグ
が下向きにのみ流れることを示しているように見えるかもしれませんが、そうで
はありません。 使用パターンによって、誰が誰のタグに関心があるかが決まる
ことだけが示されています。

   一回限りのプル(on-shot pull)は、あるコミット履歴が、独自のタグ(例:「
これは、2.6.21リリースで一般消費向けに提案されるネットワーキンググループ
からの3番目のリリース候補です」)を持つあるサークル(例:「カーネルのネット
ワーキング部分に主に関心がある人々」)と、別のサークル(例:「さまざまなサ
ブシステムの改善を統合する人々」)の間の境界を越えていることを示すサイン
です。 後者は通常、前者のグループで内部的に使用される詳細なタグには関心
がありません(これが「内部」の意味です)。そのため、この場合、タグを自動的
に追跡しないことが望ましいです。

   ネットワーキングの人々の間では、グループ内でタグを交換したいと思うか
もしれませんが、その作業フローでは、リモート追跡ブランチを使用して互いの
進行状況を追跡している可能性があります。 繰り返しますが、そのようなタグ
を自動的に追跡するヒューリスティックは良いことです。

On Backdating Tags
==================

別のVCSからいくつかの変更をインポートし、作業のメジャーリリースのタグを
追加したい場合は、タグオブジェクト内に埋め込む日付を指定できると便利です
。 タグオブジェクト内のこのようなデータは、たとえば、gitwebインターフェ
イスでのタグの順序に影響します。

   将来のタグオブジェクトで使用される日付を設定するには、環境変数
GIT_COMMITTER_DATE を設定します(可能な値については後の説明を参照してくだ
さい。最も一般的な形式は "YYYY-MM-DD HH:MM" です)。

   For example:

     $ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

DATE FORMATS
************

‘GIT_AUTHOR_DATE’ と ‘GIT_COMMITTER_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’ として扱われます。

          *Note*

          日付部分は、上記に加えて、 ‘YYYY.MM.DD’ または ‘MM/DD/YYYY’ ま
          たは ‘DD.MM.YYYY’ 形式が受け入れられます。

NOTES
*****

複数の ‘--contains’ フィルターと ‘--no-contains’ フィルターを組み合わせ
る場合、少なくとも1つの ‘--contains’ コミットを含み、 ‘--no-contains’ コ
ミットを含まない参照のみが表示されます。

   複数の ‘--merged’ フィルターと ‘--no-merged’ フィルターを組み合わせる
と、少なくとも1つの ‘--merged’ コミットから到達可能で、 ‘--no-merged’ コ
ミットのいずれからも到達できない参照のみが表示されます。

SEE ALSO
********

git-check-ref-format(1).  git-config(1).

GIT
***

Part of the git(1) suite

Name
****

git-unpack-file — ブロブの内容を含む一時(temporary)ファイルを作成します

Synopsis
********

     git unpack-file <blob>

DESCRIPTION
***********

sha1で指定されたブロブの内容を保持するファイルを作成します。 一時
(temporary)ファイルの名前を次の形式で返します: .merge_file_XXXXX

OPTIONS
*******

<blob>
     ブロブIDである必要があります

GIT
***

Part of the git(1) suite

Name
****

git-unpack-objects — パックされたアーカイブからオブジェクトを取り出しま
す

Synopsis
********

     git unpack-objects [-n] [-q] [-r] [–strict]

DESCRIPTION
***********

標準入力からパックされたアーカイブ(.pack)を読み取り、そこに含まれるオブ
ジェクトを展開して、"loose" 形式(ファイルごとに1つのオブジェクト)でリポ
ジトリに書き込みます。

   リポジトリにすでに存在するオブジェクトは、パックファイルから取り出さ
れません。したがって、ターゲットリポジトリ内に存在するパックファイルでこ
のコマンドを使用しても、何も取り出されません。

   新しいパックを生成して既存のパックを置き換えるオプションについては、
git-repack(1) を参照してください。

OPTIONS
*******

‘-n’
     ドライランします。 実際にオブジェクトを取り出さずにパックファイルを
     確認するのみです。

‘-q’
     このコマンドは通常、進捗率を表示しますが、このフラグはそれを抑制し
     ます。

‘-r’
     破損したパックファイルから取り出そうとすると、コマンドは最初の破損
     で終了します。このフラグは破損があっても続行し、できるだけ多くのオ
     ブジェクトを回復するために最善を尽くすことを指示します。

‘--strict’
     壊れたコンテンツやリンクを含むオブジェクトをリポジトリに書き込まな
     い

‘--max-input-size=<size>’
     入力サイズが <size> より大きい場合は何もせず終了します。

GIT
***

Part of the git(1) suite

Name
****

git-update-index — 作業ツリーのファイルの内容をインデックスに登録します

Synopsis
********

     git update-index
                  [–add] [–remove | –force-remove] [–replace]
                  [–refresh] [-q] [–unmerged] [–ignore-missing]
                  [(–cacheinfo <mode>,<object>,<file>)…]
                  [–chmod=(+|-)x]
                  [–[no-]assume-unchanged]
                  [–[no-]skip-worktree]
                  [–[no-]ignore-skip-worktree-entries]
                  [–[no-]fsmonitor-valid]
                  [–ignore-submodules]
                  [–[no-]split-index]
                  [–[no-|test-|force-]untracked-cache]
                  [–[no-]fsmonitor]
                  [–really-refresh] [–unresolve] [–again | -g]
                  [–info-only] [–index-info]
                  [-z] [–stdin] [–index-version <n>]
                  [–verbose]
                  [–] [<file>…]

DESCRIPTION
***********

インデックスを変更します。 言及された各ファイルはインデックスに更新され
、「unmerged」(マージされていない)または「needs updating」(更新が必要)状
態がクリアされます。

   インデックスで最も一般的な操作のいくつかを実行するためのよりユーザー
フレンドリーな方法については、 git-add(1) も参照してください。

   ‘git update-index’ が通知されたファイルを処理する方法は、さまざまなオ
プションを使用して変更できます:

OPTIONS
*******

‘--add’
     指定のファイルがまだインデックスにない場合は、追加されます。 デフォ
     ルトの動作では、新規ファイルは無視されます。

‘--remove’
     指定のファイルがインデックスに含まれているが欠落している場合、その
     ファイルは削除されます。 デフォルトの動作では、削除済のファイルは無
     視されます。

‘--refresh’
     現在のインデックスを調べ、 stat() 情報をチェックして、マージまたは
     更新が必要かどうかを確認します。

‘-q’
     静かにします。 もし ‘--refresh’ がインデックスの更新を必要としてい
     ると判断した場合、デフォルトの動作はエラーになります。 このオプショ
     ンは、 _git update-index_ をとにかく継続させます。

‘--ignore-submodules’
     サブモジュールを更新しようと試みない。このオプションは、‘--refresh’
     より前に渡された場合にのみ尊重されます。

‘--unmerged’
     ‘--refresh’ がインデックス内のマージされていない変更を検出した場合
     、デフォルトの動作はエラー終了です。 このオプションにより、「git
     update-index」はとにかく続行されます。

‘--ignore-missing’
     ‘--refresh’ の処理中に欠落しているファイルを無視します

‘--cacheinfo <mode>,<object>,<path>’
‘--cacheinfo <mode> <object> <path>’
     指定の情報を直接インデックスに挿入します。 下位互換性のために、これ
     らの3つの引数を3つの別個のパラメーターとして指定することもできます
     が、新しいユーザーは単一パラメーター形式を使用することをお勧めしま
     す。

‘--index-info’
     stdinからインデックス情報を読み取ります。

‘--chmod=(+|-)x’
     更新されたファイルに実行権限を設定します。

‘--[no-]assume-unchanged’
     このフラグを指定すると、パスに記録されているオブジェクト名は更新さ
     れません。 代わりに、このオプションは、パスの「assume unchanged」
     (無変更仮定)ビットを 設定(1)/設定解除(0) します。 「assume
     unchanged」ビットがオンの場合、ユーザーはファイルを変更しないことを
     約束し、作業ツリーファイルがインデックスに記録されているものと一致
     するとGitに想定させます。 作業ツリーファイルを変更する場合は、Gitに
     通知するビットを設定解除する必要があります。 これは、 lstat(2) シス
     テムコールが非常に遅いファイルシステム(cifsなど)で大きなプロジェク
     トを操作する場合に役立つことがあります。

     インデックス内のこのファイルを変更する必要がある場合、例えばコミッ
     トにマージするとき、Gitは(正常に)失敗します。 したがって、追跡され
     ていないと仮定されるファイルがアップストリームで変更された場合、あ
     なたは状況を手動で処理する必要があります。

‘--really-refresh’
     ‘--refresh’ と同様ですが、「assume unchanged」設定に関係なく、統計
     情報を無条件にチェックします。

‘--[no-]skip-worktree’
     これらのフラグのいずれかが指定されている場合、パスに記録されている
     オブジェクト名は更新されません。 代わりに、これらのオプションは、パ
     スの「skip-worktree」ビットを設定および設定解除します。 詳細につい
     ては、下記「Skip-worktree bit」のセクションを参照してください。

‘--[no-]ignore-skip-worktree-entries’
     ‘--remove’ オプションが指定されている場合でも、 skip-worktree (別名
     「インデックスのみ」) エントリを削除しないでください。

‘--[no-]fsmonitor-valid’
     これらのフラグのいずれかが指定されている場合、パスに記録されている
     オブジェクト名は更新されません。 代わりに、これらのオプションは、パ
     スの「fsmonitor valid」ビットを設定および設定解除します。 詳細につ
     いては、下記「File System Monitor」のセクションを参照してください。

‘-g’
‘--again’
     インデックスエントリが ‘HEAD’ コミットとは異なるパスで ‘git
     update-index’ 自体を実行します。

‘--unresolve’
     誤ってクリアされた場合、マージ処理中のファイルの「unmerged」(マージ
     されていない)または「needs updating」(更新が必要)状態を復元します。

‘--info-only’
     このフラグに続くすべての <file> 引数に対して、オブジェクトデータベ
     ースにオブジェクトを作成しません。 オブジェクトIDをインデックスに挿
     入するだけです。

‘--force-remove’
     作業ディレクトリにそのようなファイルがまだある場合でも、インデック
     スからファイルを削除します。 (‘--remove’ の指定を含んでいます。)

‘--replace’
     デフォルトでは、ファイル ‘path’ がインデックスに存在する場合、 ‘git
     update-index’ は ‘path/file’ を追加する試みを拒否します。 同様に、
     ファイル ‘path/file’ が存在する場合、ファイル ‘path’ を追加すること
     はできません。 ‘--replace’ フラグを使用すると、競合する既存のエント
     リが警告メッセージとともに自動的に削除されて、エントリが追加されま
     す。

‘--stdin’
     コマンドラインからパスのリストを取得する代わりに、標準入力からパス
     のリストを読み取ります。 デフォルトでは、パスはLFで区切られます(つ
     まり、1行に1つのパス)。

‘--verbose’
     インデックスに 追加・削除 されているものを報告します。

‘--index-version <n>’
     結果のインデックスを、指定のディスク上のフォーマットバージョン
     (on-disk format version)で書き出します。 サポートされているバージョ
     ンは 2 と 3 と 4 です。現在のデフォルトバージョンは、 ‘git add -N’
     などの追加機能が使用されているかどうかに応じて、 2 または 3 です。

     バージョン4は、単純なパス名圧縮を実行し、大規模なリポジトリでインデ
     ックスサイズを30%〜50%削減します。これにより、読み込み時間が短縮さ
     れます。 バージョン4は比較的若いです(2012年10月の1.8.0で最初にリリ
     ースされました)。 JGitやlibgit2などの他のGit実装は、まだサポートし
     ていない可能性があります。

‘-z’
     これは ‘--stdin’ または ‘--index-info’ でのみ意味があります。 パス
     は、LFではなくNUL文字で区切られます。

‘--split-index’
‘--no-split-index’
     分割インデックスモードを有効または無効にします。 分割インデックスモ
     ードがすでに有効になっていて、 ‘--split-index’ が再度指定された場合
     、 $GIT_DIR/index のすべての変更が共有インデックスファイルに押し返
     されます。

     これらのオプションは、構成変数 ‘core.splitIndex’ の値が何であれ有効
     になります(git-config(1) 参照)。 しかし、構成変数 ‘core.splitIndex’
     の設定値に反する変更を行うと警告が表示されます。なぜなら、次回イン
     デックスを読み込むときには構成変数 ‘core.splitIndex’ の設定値が有効
     になり、オプションの意図した効果がなくなってしまうからです。

‘--untracked-cache’
‘--no-untracked-cache’
     追跡されていないモノのキャッシュ機能を有効または無効にします。 有効
     にする前には ‘--test-untracked-cache’ の使用をお願いします。

     これらのオプションは、 ‘core.untrackedCache’ 構成変数の値に関係なく
     有効になります(git-config(1) 参照)。 ただし、 ‘core.untrackedCache’
     構成変数設定値に反する変更を行うと警告が表示されます。これは、イン
     デックスを次に読み込むときには ‘core.untrackedCache’ 構成変数設定値
     が有効になり、このオプションが意図したとおりの効果を得られなくなっ
     てしまうからです。

‘--test-untracked-cache’
     追跡されていないモノのキャッシュ(untracked cache)を使用できることを
     確認するために、作業ディレクトリでのみテストを実行します。 本当に使
     用したい場合は、後で ‘--untracked-cache’ または
     ‘--force-untracked-cache’ または ‘core.untrackedCache’ 構成変数を使
     用して、追跡されていないモノのキャッシュ(untracked cache)を手動で有
     効にする必要があります。 テストが失敗した場合、exitコードは1であり
     、必要に応じて機能しないことを説明するメッセージが表示されます。そ
     れ以外の場合、exitコードは0であり、OKと出力されます。

‘--force-untracked-cache’
     ‘--untracked-cache’ と同一です。 ‘--untracked-cache’ が
     ‘--test-untracked-cache’ を意味するために使用されていた古いバージョ
     ンのGitとの下位互換性のために提供されていますが、このオプションは無
     条件に拡張を有効にします。

‘--fsmonitor’
‘--no-fsmonitor’
     ファイルシステムモニター機能を有効または無効にします。 これらのオプ
     ションは、設定変数 ‘core.fsmonitor’ の値が何であっても有効になりま
     す((git-config(1) 参照)。 しかし、設定変数 ‘core.fsmonitor’ の設定
     値と異なる変更を行うと警告が表示されます。インデックスを次に読み込
     む際には設定変数 ‘core.fsmonitor’ の設定値が有効となり、オプション
     の意図した効果がなくなってしまうからです。

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

<file>
     作用するファイル。 注意: ‘.’ で始まるファイルは破棄されます。 これ
     には、 ‘./file’ と ‘dir/./file’ が含まれます。 これがあなたの求める
     ものでない場合は、よりクリーンな名前を使用してください。 ‘/’ で終わ
     るディレクトリと ‘//’ で終わるパスにも同じことが当てはまります。

USING –refresh
**************

‘--refresh’ は、新しいsha1ファイルを計算したり、また、モード/コンテンツ
の変更についてインデックスを最新の状態にしたりしません。 ただし、ファイ
ルの統計情報をインデックスと「再照合」(re-match)することで、変更されてい
ないが統計エントリが古くなっているファイルのインデックスを更新できます。

   たとえば、あなたが「git read-tree」を実行した後にこれを実行して、統計
インデックスの詳細を適切なファイルにリンクすることができます。

USING –cacheinfo OR –info-only
******************************

‘--cacheinfo’ は、現在の作業ディレクトリにないファイルを登録するために使
用されます。 これは、最小チェックアウト(minimum-checkout)のマージに役立
ちます。

   path に mode と sha1 を持つファイルがあるように見せかけるには、以下の
ようにします:

     $ git update-index --add --cacheinfo <mode>,<sha1>,<path>

   ‘--info-only’ は、ファイルをオブジェクトデータベースに配置せずに登録
するために使用されます。 これは、ステータスのみ(status-only)のリポジトリ
に役立ちます。

   ‘--cacheinfo’ と ‘--info-only’ はどちらも同じように振る舞います。イン
デックスは更新されますが、オブジェクトデータベースは更新されません。
‘--cacheinfo’ は、オブジェクトがデータベースにあるが、ファイルがローカル
で利用できない場合に役立ちます。 ‘--info-only’ は、ファイルが利用可能で
あるが、オブジェクトデータベースを更新したくない場合に役立ちます。

USING –index-info
*****************

‘--index-info’ は、標準入力から複数のエントリ定義を供給できるより強力な
メカニズムであり、スクリプト用に特別に設計されています。 以下の3つの形式
の入力を受け取ることができます:

  1. mode SP type SP sha1 TAB path

     この形式は、 ‘git ls-tree’ 出力をインデックスに詰め込むためのもので
     す。

  2. mode SP sha1 SP stage TAB path

     この形式は、より高次のステージをインデックスファイルに配置するため
     のものであり、 ‘git ls-files --stage’ の出力と一致します。

  3. mode SP sha1 TAB path

     この形式はGitコマンドでは生成されなくなりましたが、 ‘update-index
     --index-info’ では引き続きサポートされます。

   インデックスに上位ステージのエントリを配置するには、最初にパスに
mode=0 エントリを入力してパスを削除し、次に必要な入力行を3番目の形式で入
力する必要があります。

   たとえば、以下のインデックスから始めます:

     $ git ls-files -s
     100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz

   あなたは以下の入力を ‘--index-info’ にフィードできます:

     $ git update-index --index-info
     0 0000000000000000000000000000000000000000      frotz
     100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1       frotz
     100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2       frotz

   入力の最初の行は、パスを削除するモードとして0を供給します。 SHA-1は、
適切にフォーマットされている限り問題ありません。 次に、2行目と3行目は、
そのパスのステージ1とステージ2のエントリに供給します。 上記の後は、以下
のようになるでしょう:

     $ git ls-files -s
     100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1       frotz
     100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2       frotz

「assume unchanged」(無変更と仮定する)ビットの使用
**************************************************

Gitの多くの操作は、効率的な ‘lstat(2)’ 実装をファイルシステムに依存して
いるため、作業ツリーファイルの ‘st_mtime’ 情報を低コストでチェックして、
ファイルの内容がインデックスファイルに記録されているバージョンから変更さ
れているかどうかを確認できます。 残念ながら、一部のファイルシステムには
非効率的な ‘lstat(2)’ があります。 ファイルシステムがそれらの1つである場
合は、変更していないパスに「assume unchanged」(不変更仮定)ビットを設定し
て、Gitがこのチェックを行わないようにすることができます。 パスにこのビッ
トを設定しても、Gitがファイルの内容をチェックしてファイルが変更されてい
るかどうかを確認するわけではありません。Gitはチェックを省略し、変更され
ていないと見なします。 作業ツリーファイルに変更を加えるときは、変更する
前または後に、「assume unchanged」ビットを削除して、Gitに明示的に通知す
る必要があります。

   「assume unchanged」(不変更仮定)ビットを設定するには、
‘--assume-unchanged’ オプションを使用します。 設定を解除するには、
‘--no-assume-unchanged’ を使用します。 「assume unchanged」ビットが設定
されているファイルを確認するには、 ‘git ls-files -v’ を使用します
(git-ls-files(1) 参照)。

   このコマンドは ‘core.ignorestat’ 構成変数を調べます。
core.ignorestat‘ 構成変数が true の場合、 ‘git update-index paths...’ で
更新されたパスと、インデックスと作業ツリーの両方を更新する他のGitコマン
ド(例: ‘git apply --index’ や ‘git checkout-index -u’ や ‘git read-tree
-u’)で更新されたパスは、自動的に「変更されていないと見なす」とマークされ
ます。 注意: ‘git update-index --refresh’ が、作業ツリーファイルとインデ
ックスが一致することを検出した場合、「assume unchanged」ビットは設定され
ないことに注意してください(あなたがそれらに「assume unchanged」マークを
付けたい場合は、 ‘git update-index --really-refresh’ を使用してください
)。

EXAMPLES
********

すでにチェックアウトされているファイルのみをupdateおよびrefreshするには:

     $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh

‘core.ignorestat’ が設定された非効率的なファイルシステム上で…
          $ git update-index --really-refresh              (1)
          $ git update-index --no-assume-unchanged foo.c   (2)
          $ git diff --name-only                           (3)
          $ edit foo.c
          $ git diff --name-only                           (4)
          M foo.c
          $ git update-index foo.c                         (5)
          $ git diff --name-only                           (6)
          $ edit foo.c
          $ git diff --name-only                           (7)
          $ git update-index --no-assume-unchanged foo.c   (8)
          $ git diff --name-only                           (9)
          M foo.c

     See (1).
          lstat(2) に、インデックスに一致するパスに「assume unchanged」
          (無変更仮定)ビットをセットするように強制します。

     See (2).
          編集するパスをマークします。

     See (3).
          これは lstat(2) を実行し、インデックスがパスに一致することを検
          出します。

     See (4).
          これは lstat(2) を実行し、インデックスがパスと「一致しない」こ
          とを検出します。

     See (5).
          新しいバージョンをインデックスに登録すると、「assume
          unchanged」(無変更仮定)ビットがセットされます。

     See (6).
          そしてそれは無変更と仮定されています(assumed unchanged)。

     See (7).
          それを編集した後でもです。

     See (8).
          あなたは事後に、変更について伝える事ができます。

     See (9).
          いまや、 lstat(2) をチェックして、変更されていることがわかりま
          す。

SKIP-WORKTREE BIT
*****************

skip-worktreeビットは1つの(長い)文で定義できます。これはエントリを読み取
るときに、skip-worktreeとしてマークされている場合、Gitは作業ディレクトリ
のバージョンが最新であるかのように見せかけ、代わりにインデックスバージョ
ンを読み取ります。

   詳しく説明すると、「reading」(読み取り)とは、ファイルの存在を確認する
こと、ファイルの属性またはファイルの内容を読み取ることを意味します。 作
業ディレクトリのバージョンが存在する場合と存在しない場合があります。 存
在する場合、そのコンテンツはインデックスバージョンと一致するかどうかがわ
かります。 書き込みはこのビットの影響を受けません。コンテンツの安全性は
依然として最優先事項です。 安全な場合(つまり、作業ディレクトリのバージョ
ンがインデックスのバージョンと一致する場合)、Gitはskip-worktreeとマーク
された作業ディレクトリファイルを更新できることに注意してください。

   このビットは、assume-unchanged ビットに似ていますが、その目的は、
assume-unchanged ビットとは異なります。 skip-worktree は、両方が設定され
ている場合、 assume-unchanged ビットよりも優先されます。

SPLIT INDEX
***********

このモードは、非常に大きなインデックスを持つリポジトリ用に設計されており
、これらのインデックスを繰り返し書き込むのにかかる時間を短縮することを目
的としています。

   このモードでは、インデックスは $GIT_DIR/index と
$GIT_DIR/sharedindex.<SHA-1> の2つのファイルに分割されます。 変更は分割
インデックスである $GIT_DIR/index に蓄積されますが、共有インデックス
(shared index)ファイルにはすべてのインデックスエントリが含まれ、変更され
ません。

   分割インデックスのエントリ数が splitIndex.maxPercentChange 構成変数で
指定されたレベルに達すると、分割インデックスのすべての変更が共有インデッ
クスファイルに押し戻されます(git-config(1) 参照)。

   新しい共有インデックスファイルが作成されるたびに、古い共有インデック
スファイルは、変更時間が splitIndex.sharedIndexExpire 構成変数で指定され
た時間よりも古い場合に削除されます(git-config(1) 参照)。

   まだ使用されている共有インデックスファイルの削除を回避するために、共
有インデックスファイルに基づく新しい分割インデックスが、作成または読み取
られるたびに、その変更時刻が現在の時刻に更新されます。

UNTRACKED CACHE
***************

このキャッシュは、 ‘git status’ などの追跡されていないファイルの判別を伴
うコマンドを高速化することを目的としています。

   この機能は、作業ツリーディレクトリのmtimeを記録し、mtimeが変更されて
いないディレクトリ内のファイルに対するディレクトリの読み取りとstat呼び出
しを省略することで機能します。 これを機能させるには、ディレクトリ内のフ
ァイルが追加、変更、または削除された場合に、基盤となるオペレーティングシ
ステムとファイルシステムがディレクトリの ‘st_mtime’ フィールドを変更する
必要があります。

   ‘--test-untracked-cache’ オプションを使用して、ファイルシステムがそれ
をサポートしているかどうかをテストできます。 ‘--untracked-cache’ オプシ
ョンは、古いバージョンのGitでこのテストを暗黙的に実行するために使用され
ていましたが、現在はそうではありません。

   この機能を有効(または無効)にする場合は、 各リポジトリで
‘--untracked-cache’ オプションを ‘git update-index’ に使用するよりも、
‘core.untrackedCache’ 構成変数(git-config(1) 参照)を使用する方が簡単です
。 特に、使用しているすべてのリポジトリに対してそうしたい場合は、あなた
の ‘$HOME/.gitconfig’ で ‘core.untrackedCache’ 構成変数を ‘true’(または
‘false’)と一度セットするだけですべてのリポジトリでその機能を使えるため、
簡単です。

   ‘core.untrackedCache’ 構成変数が変更されると、次にコマンドがインデッ
クスを読み取るときに、追跡されていないキャッシュがインデックスに追加され
るか、インデックスから削除されます。 一方、
‘--[no-|force-]untracked-cache’ が使用されている場合、追跡されていないキ
ャッシュはすぐにインデックスに追加されるか、インデックスから削除されます
。

   2.17より前は、追跡されていないモノのキャッシュ(untracked cache)にバグ
があり、ディレクトリを別のディレクトリへのシンボリックリンクに置き換える
と、gitによって追跡されたファイルが追跡されていないものとして誤って表示
される可能性がありました。 git.git の「status: add a failing test
showing a core.untrackedCache bug」コミットを参照してください。 その回避
策は以下のとおりです(これは将来、他の未発見のバグでも機能する可能性があ
ります):

     $ git -c core.untrackedCache=false status

   このバグは、追跡されていないモノのキャッシュ(untracked cache)の内部構
造に関して、ディレクトリをファイルに置き換えるシンボリックリンク以外のケ
ースにも影響を与えることが示されていますが、これにより誤った「git
status」出力が発生したケースは報告されていません。

   2.17より前のバージョンのgitによって書き込まれた既存のインデックスが、
もう存在しないディレクトリを参照し、「could not open directory」(ディレ
クトリを開けませんでした)という警告が「git status」に出力される可能性が
あります。 これらは、以前は黙って破棄されていた既存の問題に対する新しい
警告です。

   上記のバグと同様に、解決策は、 ‘core.untrackedCache=false’ で「git
status」を1回実行して、残っている不良データをフラッシュすることです。

FILE SYSTEM MONITOR
*******************

この機能は、巨大な作業ディレクトリを持つリポジトリのgit操作を高速化する
ことを目的としています。

   これにより、gitはファイルシステムモニター(githooks(5)の「
fsmonitor-watchman」セクションを参照)と連携して、どのファイルが変更され
たかを通知できます。 これにより、gitは、変更されたファイルを見つけるため
にすべてのファイルを lstat() する必要がなくなります。

   追跡されていないモノのキャッシュ(untracked cache)と組み合わせて使用す
ると、作業ディレクトリ全体をスキャンして新しいファイルを探すコストを回避
できるため、パフォーマンスをさらに向上させることができます。

   この機能を有効(または無効)にする場合は、 各リポジトリの ‘git
update-index’ に ‘--fsmonitor’ オプションを付けるよりも、
‘core.fsmonitor’ 構成変数(git-config(1) 参照)を使用する方が簡単です。 特
に、すべてのリポジトリで同じことをしたい場合は、あなたの
‘$HOME/.gitconfig’ で ‘core.fsmonitor’ 構成変数を一度設定するだけですべ
てのリポジトリでそれが適用されるので、使い勝手はよいでしょう。

   ‘core.fsmonitor’ 構成変数が変更されると、次にコマンドがインデックスを
読み取るときに、ファイルシステムモニターがインデックスに追加またはインデ
ックスから削除されます。 ‘--[no-]fsmonitor’ を使用すると、ファイルシステ
ムモニターはすぐにインデックスに追加またはインデックスから削除されます。

CONFIGURATION
*************

このコマンドは、‘core.filemode’ 構成変数を尊重します。 リポジトリが実行
可能ビットの信頼性が低いファイルシステム上にある場合は、 これを「false」
に設定する必要があります(git-config(1) 参照)。 これにより、コマンドは、
インデックスに記録されたファイルモードと、 実行可能ビットのみが異なる場
合はファイルシステムのファイルモードの違いを無視します。 このような不幸
なファイルシステムでは、 「git update-index –chmod=」を使用する必要があ
るかもしれません。

   まったく同様に、 ‘core.symlinks’ 構成変数が _false_ に設定されている
場合(git-config(1) 参照)、シンボリックリンクはプレーンファイルとしてチェ
ックアウトされ、そしてこのコマンドは記録されたファイルモードをシンボリッ
クから通常のファイルへのリンクへ変更しません。

   このコマンドは、 ‘core.ignorestat’ 構成変数を調べます。 上記「Using
"assume unchanged" bit」セクションを参照してください。

   このコマンドは、 ‘core.trustctime’ 構成変数も調べます。 iノードの変更
時刻がGitの外部で定期的に変更される場合に便利です(ファイルシステムクロー
ラーとバックアップシステムは、処理されたファイルのマーキングにctimeを使
用します)(git-config(1) 参照)。

   追跡されていないモノのキャッシュ(untracked cache)拡張は、
‘core.untrackedCache’ 構成変数によって有効にできます(git-config(1) 参照
)。

NOTES
*****

ユーザーは、追跡されるファイルへの変更を無視するようにGitに指示するため
に、assume-unchangedビット と skip-worktreeビット を使用しようと試みるこ
とがよくありますが、 Gitは特定の操作を実行するときに、インデックスに対し
て作業ツリーファイルをチェックする可能性があるため、これは期待どおりに機
能しません。 一般に、Gitは追跡されたファイルへの変更を無視する方法を提供
しないため、別の解決策をお勧めします。

   たとえば、変更するファイルがある種の構成ファイルである場合、リポジト
リにサンプルの構成ファイルを含めることができます。このファイルは、無視さ
れた名前にコピーして変更できます。 リポジトリには、サンプルファイルをテ
ンプレートとして扱い、自動的に変更およびコピーするスクリプトを含めること
もできます。

SEE ALSO
********

git-config(1), git-add(1), git-ls-files(1)

GIT
***

Part of the git(1) suite

Name
****

git-update-ref — refに保存されているオブジェクト名を安全に更新します

Synopsis
********

     git update-ref [-m <reason>] [–no-deref] (-d <ref> [<oldvalue>] | [–create-reflog] <ref> <newvalue> [<oldvalue>] | –stdin [-z])

DESCRIPTION
***********

2つの引数が与えられた場合、<newvalue>を<ref>に格納し、シンボリックrefを
逆参照する可能性があります。例えば、 ‘git update-ref HEAD <newvalue>’ は
、現在のブランチヘッドを新しいオブジェクトに更新します。

   3つの引数が与えられた場合、<ref>の現在の値が<oldvalue>と一致すること
を確認した後、<newvalue>を<ref>に格納し、シンボリックrefを逆参照する可能
性があります。 例えば、 ‘git update-ref refs/heads/master <newvalue>
<oldvalue>’ は、現在の値が<oldvalue>の場合にのみ、masterブランチヘッドを
<newvalue>に更新します。 あなたは、作成する参照がまだ存在しないこと示す
ために、40個の"0" または 空の文字列を <oldvalue> として指定する事ができ
ます。

   また、 "ref:" という4バイトのヘッダーシーケンスで開始することにより、
「ref」ファイルを別のrefファイルへのシンボリックポインタにすることもでき
ます。

   さらに重要なことは、refファイルの更新は、シンボリックリンクであろうと
、これらの「通常のファイルのシンボリック参照」であろうと、これらのシンボ
リックポインタに従います。 ‘refs/’ で始まる場合にのみ「実際」のシンボリ
ックリンクをたどります。それ以外の場合は、それらを読み取って通常のファイ
ルとして更新しようとします(つまり、ファイルシステムはそれらを追跡できま
すが、他の場所へのそのようなシンボリックリンクは通常のファイル名で上書き
されます)。

   ‘--no-deref’ を指定すると、シンボリックポインターをたどった結果ではな
く、<ref>自体が上書きされます。

   一般的には以下ように使います

     git update-ref HEAD "$head"

   これは、以下のようにするよりもはるかに安全なはずです

     echo "$head" > "$GIT_DIR/HEAD"

   シンボリックリンク追跡とエラーチェックの両方の観点から、シンボリック
リンクの "refs/" ルールは、ツリーの「外側」を指すシンボリックリンクが安
全であることを意味します。つまり、読み取りでは追跡されますが、書き込みで
は追跡されません(したがって、シンボリックリンクツリーを作成してアーカイ
ブ全体をコピーした場合は、refシンボリックリンクを介して他のツリーに書き
込むことはありません)。

   ‘-d’ フラグを使用すると、<ref>がまだ<oldvalue>を含んでいることを確認
(verify)した後、名前付きの<ref>を削除します。

   ‘--stdin’ を使用すると、update-refは標準入力から命令を読み取り、すべ
ての変更を一緒に実行します。 以下の形式のコマンドを指定します:

     update SP <ref> SP <newvalue> [SP <oldvalue>] LF
     create SP <ref> SP <newvalue> LF
     delete SP <ref> [SP <oldvalue>] LF
     verify SP <ref> [SP <oldvalue>] LF
     option SP <opt> LF
     start LF
     prepare LF
     commit LF
     abort LF

   ‘--create-reflog’ を使用すると、update-refは、通常は作成されない場合
でも、各refのreflogを作成します。

   Cソースコードの文字列であるかのように空白を含むフィールドをクォートし
ます。 つまり、二重引用符で囲まれ、バックスラッシュ(‘\’)でエスケープされ
ます。 ゼロ値(zero value)を指定するには、40個の "0" 文字または空の文字列
を使用します。 欠落している値(missing value)を指定するには、値とその前の
SPを完全に省略します。

   あるいは、 ‘-z’ を使用して、クォートせずにNUL終了形式で指定します:

     update SP <ref> NUL <newvalue> NUL [<oldvalue>] NUL
     create SP <ref> NUL <newvalue> NUL
     delete SP <ref> NUL [<oldvalue>] NUL
     verify SP <ref> NUL [<oldvalue>] NUL
     option SP <opt> NUL
     start NUL
     prepare NUL
     commit NUL
     abort NUL

   この形式では、40個の "0" を使用してゼロ値(zero value)を指定し、空の文
字列を使用して欠落している値(missing value)を指定します。

   どちらの形式でも、Gitがオブジェクト名として認識する任意の形式で値を指
定できます。他の形式のコマンドまたは繰り返される<ref>は、エラーを生成し
ます。 コマンドの意味は以下のとおりです:

update
     指定されている場合は、<oldvalue>を確認した後、<ref>を<newvalue>に設
     定します。 ゼロ<newvalue>を指定して、更新後にrefが存在しないことを
     確認(verify)するか、ゼロ<oldvalue>を指定して、更新前にrefが存在しな
     いことを確認(verify)します。

create
     存在しないことを確認した後、<newvalue>を使用して<ref>を作成します。
     指定された<newvalue>はゼロではない可能性があります。

delete
     <oldvalue>が指定されている場合は、それが存在することを確認した後、
     <ref>を削除します。 指定した場合、<oldvalue>はゼロではない可能性が
     あります。

verify
     <ref>を<oldvalue>に対して確認(verify)しますが、変更しないでください
     。 <oldvalue>がゼロ(zero)または欠落(missing)している場合、refは存在
     してはなりません。

option
     <ref>に名前を付ける次のコマンドの振る舞いを変更します。 唯一の有効
     なオプションは ‘no-deref’ で、シンボリックrefの逆参照を回避します。

start
     トランザクションを開始します。 非トランザクションセッションとは対照
     的に、セッションが明示的なコミットなしで終了すると、トランザクショ
     ンは自動的に中止(abort)されます。 このコマンドは、現在のトランザク
     ションがすでにコミットまたは中止(abort)されている場合に、新しい空の
     トランザクションを作成する場合があります。

prepare
     トランザクションをコミットする準備をします。 これにより、キューに入
     れられたすべての参照更新のロックファイルが作成されます。 ロックでき
     ない参照がある場合、トランザクションは中止(abort)されます。

commit
     トランザクションのためにキューに入れられたすべての参照更新をコミッ
     トし、トランザクションを終了(ending)します。

abort
     トランザクションを中止(abort)し、トランザクションが準備済み状態
     (prepared state)の場合はすべてのロックを解除します。

   すべての<ref>を一致する<oldvalue>で同時にロックできる場合、すべての変
更が実行されます。 それ以外の場合、変更は実行されません。 注意: 個々の
<ref>はアトミックに更新または削除されますが、並行読み取り(concurrent
reader)では変更のサブセットが表示される場合があることに注意してください
。

LOGGING UPDATES
***************

構成パラメーター ‘core.logAllRefUpdates `がtrueで、参照が `refs/heads/’
の下にある場合、 ‘refs/remotes/’ または ‘refs/notes/’ または HEADや
ORIG_HEADのような疑似参照 または ファイル ‘$GIT_DIR/logs/<ref>’ が存在す
る場合に、 ‘git update-ref’ はログファイル ‘$GIT_DIR/logs/<ref>’ にref値
の変更を説明する行を追加します(ログ名を作成する前に、すべてのシンボリッ
クrefを間接参照します)。 ログ行は以下のようにフォーマットされます:

     oldsha1 SP newsha1 SP committer LF

   「oldsha1」は以前に<ref>に保存された40文字の16進値であり、「newsha1」
は<newvalue>の40文字の16進値であり、「committer」は標準のGitコミッター
ID形式のコミッターの名前、メールアドレス、日付です。

   オプションで ‘-m’ と一緒に使用すると:

     oldsha1 SP newsha1 SP committer TAB message LF

   これは、すべてのフィールドが上記のとおりであり、「message」が ‘-m’ オ
プションに指定された値です。

   現在のユーザーが新しいログファイルを作成できない場合、既存のログファ
イルに追加できない場合、またはコミッター情報が利用できない場合、更新は（
<ref>を変更せずに）失敗します。

GIT
***

Part of the git(1) suite

Name
****

git-update-server-info — ダムサーバー(dumb servers)を支援するために補助
情報ファイル(auxiliary info file)を更新する

Synopsis
********

     git update-server-info

DESCRIPTION
***********

オンザフライパック生成(on-the-fly pack generations)を行わないダムサーバ
ー(dumb server)は、クライアントがサーバーの参照とパックを検出できるよう
に、 $GIT_DIR/info と $GIT_OBJECT_DIRECTORY/info ディレクトリにいくつか
の補助情報ファイル(auxiliary information files)を持っている必要がありま
す。このコマンドは、そのような補助ファイルを生成します。

OUTPUT
******

現在、このコマンドは以下のファイルを更新します。それらの目的の説明につい
ては、 gitrepository-layout(5) を参照してください:

   • objects/info/packs

   • info/refs

GIT
***

Part of the git(1) suite

Name
****

git-upload-archive — アーカイブを git-archive に送り返す

Synopsis
********

     git upload-archive <directory>

DESCRIPTION
***********

_git archive –remote_ によって呼び出され、生成されたアーカイブをGitプロ
トコルを介して送信します。

   このコマンドは通常、エンドユーザーによって直接呼び出されることはあり
ません。 プロトコルのUIは _git archive_ 側にあり、プログラムのペアはリモ
ートリポジトリからアーカイブを取得するために使用することを目的としていま
す。

SECURITY
********

履歴から削除されたが、まだ剪定(prune)されてない可能性のあるオブジェクト
のプライバシーを保護するために、 ‘git-upload-archive’ は、リポジトリの
refから到達できないコミットおよびツリーのアーカイブの提供を回避します。
ただし、オブジェクトの到達可能性の計算には計算コストがかかるため、
‘git-upload-archive’ は、より厳密でありながらチェックしやすい一連のルー
ルを実装します。

  1. クライアントは、refが直接指すコミットまたはツリーを要求できます。 例
     : ‘git archive --remote=origin v1.0’

  2. クライアントは、 ‘ref：path’ 構文を使用して、コミットまたはツリー内
     のサブツリーを要求できます。例: ‘git archive --remote=origin
     v1.0:Documentation’

  3. 最終結果に到達できる場合でも、クライアントは他のsha1式を使用できま
     せん。 たとえば、refから結果に到達できる場合でも、 ‘master^’ のよう
     な相対コミットや ‘abcd1234’ のようなリテラルsha1は許可されません。

   注意: 3番目の規則3は、プライバシーに影響を与えない多くの場合を許可し
ないことに注意してください。これらのルールはgitの将来のバージョンで変更
される可能性があり、 ‘git archive --remote’ によってアクセスされるサーバ
ーは、これらの正確なルールに従う場合と従わない場合があります。

   構成オプション ‘uploadArchive.allowUnreachable’ がtrueの場合、これら
の規則は無視され、クライアントは任意のsha1式を使用できます。これは、到達
不能なオブジェクトのプライバシーを気にしない場合、またはオブジェクトデー
タベースが非スマートhttp経由でアクセスできるようにすでに公開されている場
合に役立ちます。

OPTIONS
*******

<directory>
     tarアーカイブを取得するリポジトリ。

GIT
***

Part of the git(1) suite

Name
****

git-upload-pack — パックされたオブジェクトをgit-fetch-packに送り返す

Synopsis
********

     git-upload-pack [–[no-]strict] [–timeout=<n>] [–stateless-rpc]
                       [–advertise-refs] <directory>

DESCRIPTION
***********

_git fetch-pack_ によって呼び出され、通信の反対側で欠落しているオブジェ
クトを調べ、パッキング後にそれらを送信します。

   このコマンドは通常、エンドユーザーによって直接呼び出されることはあり
ません。プロトコルのUIは「git fetch-pack」側にあり、プログラムのペアはリ
モートリポジトリから更新をプルするために使用されることを目的としています
。プッシュ操作については、「git send-pack」を参照してください。

OPTIONS
*******

‘--[no-]strict’
     <directory> Gitディレクトリでない場合、 <directory>/.git/ を試さな
     い

‘--timeout=<n>’
     非アクティブになった <n> 秒後に転送を中断します。

‘--stateless-rpc’
     stdinとstdoutを使用して 読み取り/書き込み サイクルを1回だけ実行しま
     す。これは、プログラムが要求を読み取り、応答を書き込み、終了する必
     要があるHTTP POST要求処理モデルに適合します。

‘--http-backend-info-refs’
     git-http-backend(1) が、
     ‘$GIT_URL/info/refs?service=git-upload-pack’ リクエストを処理するた
     めに使用します。 the HTTP transfer protocols
     (technical/http-protocol.html) 文書の「Smart Clients」および the
     Git Wire Protocol, Version 2 (technical/protocol-v2.html) 文書の「
     HTTP Transport」を参照してください。なお、 git-receive-pack(1) でも
     同様です。

<directory>
     同期元のリポジトリ。

ENVIRONMENT
***********

‘GIT_PROTOCOL’
     ワイヤープロトコルをハンドシェイクするために使用される内部変数。サ
     ーバー管理者は、この変数を渡すことができるようにいくつかのトランス
     ポートを構成する必要がある場合があります。 git(1) のdiscussionを参
     照してください。

SEE ALSO
********

gitnamespaces(7)

GIT
***

Part of the git(1) suite

Name
****

git-var — Git論理変数を表示します

Synopsis
********

     git var ( -l | <variable> )

DESCRIPTION
***********

Git論理変数を出力します。

OPTIONS
*******

‘-l’
     論理変数をリストします。さらに、Git構成ファイル .git/config のすべ
     ての変数も一覧表示されます。 (ただし、構成変数を一覧表示する機能は
     非推奨になり、 ‘git config -l’ が採用されました。)

EXAMPLES
********

     $ git var GIT_AUTHOR_IDENT
     Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600

VARIABLES
*********

GIT_AUTHOR_IDENT
     コードの作者。

GIT_COMMITTER_IDENT
     コードの一部をGitに入れた人。

GIT_EDITOR
     Gitコマンドで使用するためのテキストエディタ。この値は、使用時にシェ
     ルによって解釈されることを意図しています。例: ‘~/bin/vi’ 、
     ‘$SOME_ENVIRONMENT_VARIABLE’ 、 ‘"C:\Program Files\Vim\gvim.exe"
     --nofork’ 。 優先順位は、 ‘$GIT_EDITOR’ 環境変数 、‘core.editor’ 構
     成、 ‘$VISUAL’ 、‘$EDITOR’ 、そしてコンパイル時に選択されるデフォル
     ト(通常は _vi_)です。

GIT_PAGER
     Gitコマンドで使用するためのテキストビューア(例: less)。値はシェルに
     よって解釈されることを意図しています。 優先順位は、 ‘$GIT_PAGER’ 環
     境変数、 ‘core.pager’ 構成、 ‘$PAGER’ 、そしてコンパイル時に選択さ
     れるデフォルト(通常は _less_)です。

SEE ALSO
********

git-commit-tree(1) git-tag(1) git-config(1)

GIT
***

Part of the git(1) suite

Name
****

git-verify-commit — コミットのGPG署名を確認します。

Synopsis
********

     git verify-commit <commit>…

DESCRIPTION
***********

_git commit -S_ によって作成されたGPG署名を検証します。

OPTIONS
*******

‘--raw’
     通常の人間が読める形式の出力ではなく、生のgpgステータス出力を、標準
     エラーに出力します。

‘-v’
‘--verbose’
     検証する前に、コミットオブジェクトの内容を出力します。

<commit>…
     GitコミットオブジェクトのSHA-1 ID。

GIT
***

Part of the git(1) suite

Name
****

git-verify-pack — パックされたGitアーカイブファイルを検証する

Synopsis
********

     git verify-pack [-v|–verbose] [-s|–stat-only] [–] <pack>.idx …

DESCRIPTION
***********

_git pack-objects_ コマンドで作成されたパックされたGitアーカイブの指定の
idxファイルを読み取り、idxファイルと、対応するパックファイルが正しいこと
を確認します。

OPTIONS
*******

<pack>.idx …
     確認するidxファイル(複数ファイル指定可)

‘-v’
‘--verbose’
     パックを確認した後、パックに含まれるオブジェクトのリストとデルタチ
     ェーン長のヒストグラムを表示します。

‘-s’
‘--stat-only’
     パックの内容を確認せず、デルタチェーン長のヒストグラムのみを表示し
     ます。 ‘--verbose’ を使用すると、オブジェクトのリストも表示されます
     。

–
     これ以降の引数をオプションとして解釈しないでください。

OUTPUT FORMAT
*************

オプション -v を指定する場合、使用される形式は以下のとおりです:

     SHA-1 type size size-in-packfile offset-in-packfile

   は、パックで削除されていないオブジェクトの場合です。そして、

     SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1

   は、削除されたオブジェクトの場合です。

GIT
***

Part of the git(1) suite

Name
****

git-verify-tag — タグのGPG署名を確認する

Synopsis
********

     git verify-tag [–format=<format>] <tag>…

DESCRIPTION
***********

_git tag_ によって作成されたgpg署名を検証します。

OPTIONS
*******

‘--raw’
     通常の人間が読める形式の出力の代わりに、生のgpgステータス出力を標準
     エラーに出力します。

‘-v’
‘--verbose’
     検証する前に、タグオブジェクトの内容を出力します。

<tag>…
     GitタグオブジェクトのSHA-1 ID。

GIT
***

Part of the git(1) suite

Name
****

git-version — Gitに関するバージョン情報を表示する

Synopsis
********

     git version [–build-options]

DESCRIPTION
***********

オプションが指定されていない場合、 _git_ のバージョンが標準出力に出力さ
れます。

   ‘git --version’ は ‘git version’ と同じであることに注意してください。
これは、前者が内部で後者に変換されるためです。

OPTIONS
*******

‘--build-options’
     診断目的でgitがどのように構築されたかに関する追加情報を含めます。

GIT
***

Part of the git(1) suite

Name
****

git-web–browse — Webブラウザを起動するためのGitヘルパースクリプト

Synopsis
********

     git web–browse [<options>] <url|file>…

DESCRIPTION
***********

このスクリプトは、引数として渡されたURLとファイルを、可能な限り、既に開
いているWebブラウザーの新しいタブにHTMLページとして表示しようとします。

   現在、以下のブラウザ(またはコマンド)がサポートされています:

   • firefox (これは、KDEを使用しない場合のX Windowのデフォルトです)

   • iceweasel

   • seamonkey

   • iceape

   • chromium (chromium-browser としてもサポートされています)

   • google-chrome (chromeとしてもサポートされています)

   • konqueror (これはKDEのデフォルトです。以下の「Note about konqueror」
     を参照してください)

   • opera

   • w3m (これはグラフィカル環境以外のデフォルトです)

   • elinks

   • links

   • lynx

   • dillo

   • open (これはMac OS X GUIのデフォルトです)

   • start (これはMinGWのデフォルトです)

   • cygstart (これはCygwinのデフォルトです)

   • xdg-open

   カスタムコマンドを指定することもできます。

OPTIONS
*******

‘-b <browser>’
‘--browser=<browser>’
     指定のブラウザを使用します。サポートされているブラウザのリストに含
     まれている必要があります。

‘-t <browser>’
‘--tool=<browser>’
     同上。

‘-c <conf.var>’
‘--config=<conf.var>’
     CONF.VAR はGit構成ファイルで検索されます。設定されている場合、その
     値は使用するブラウザを指定します。

CONFIGURATION VARIABLES
***********************

CONF.VAR( -c 由来) と web.browser
=================================

Webブラウザーは、 ‘-c’ (または ‘--config’)コマンドラインオプションで渡さ
れる構成変数、または前者が使用されていない場合は ‘web.browser’ 構成変数
を使用して指定できます。

browser.<tool>.path
===================

あなたは構成変数 ‘browser.<tool>.path’ を設定することにより、希望するブ
ラウザーへのフルパスを明示的に指定できます。たとえば、
‘browser.firefox.path’ を設定することで、Firefoxへの絶対パスを設定できま
す。それ以外の場合、 ‘git web{litdd}browse’ はツールがPATH上にあると想定
します。

browser.<tool>.cmd
==================

オプションまたは構成変数で指定されたブラウザーがサポートされているブラウ
ザーに含まれていない場合、対応する ‘browser.<tool>.cmd’ 構成変数が検索さ
れます。 この変数が存在する場合、 ‘git web{litdd}browse’ は指定されたツ
ールをカスタムコマンドとして扱い、シェルのevalを使用してURLを引数として
渡してコマンドを実行します。

NOTE ABOUT KONQUEROR
********************

_konqueror_ がコマンドラインオプションまたは構成変数で指定されている場合
、可能であれば、 _kfmclient_ を起動して、既に開いているkonquerorのHTMLマ
ニュアルページを新しいタブで開こうとします。

   一貫性を保つために、 ‘browser.konqueror.path’ が
‘A_PATH_TO/konqueror’ のように設定されている場合にも、このようなトリック
を試します。 つまり、代わりに ‘A_PATH_TO/kfmclient’ を起動しようと試みま
す。

   あなたが本当に ‘konqueror’ の使用を望むのなら、あなたは以下のようなも
のを使用できます:

             [web]
                     browser = konq

             [browser "konq"]
                     cmd = A_PATH_TO/konqueror

注意: git-config –global について
=================================

注意: これらの構成変数は、おそらく以下のように ‘--global’ フラグを使用し
て設定する必要があることに注意してください:

     $ git config --global web.browser firefox

   なぜなら、おそらくリポジトリ固有よりもユーザー固有であるためです。詳
細については、 git-config(1) を参照してください。

GIT
***

Part of the git(1) suite

Name
****

git-whatchanged — 各コミットでの差分のログを表示

Synopsis
********

     git whatchanged <option>…

DESCRIPTION
***********

各コミットのコミットログとdiff出力を表示します。

   新規ユーザーは、これの代わりに git-log(1) を使用することをお勧めしま
す。 ‘whatchanged’ コマンドは基本的に git-log(1) と同じですが、デフォル
トでは生の形式の差分出力を表示し、マージをスキップします。

   このコマンドは主に歴史的な理由で保持されています。‘git log’ が発明さ
れるずっと前に Linux kernel mailing list を読んで Gitを学んだ多くの人々
の指は、このコマンドをタイプするよう訓練されています。

Examples
********

‘git whatchanged -p v2.6.12.. include/scsi drivers/scsi’
     include/scsi または drivers/scsi サブディレクトリ内のファイルを変更
     したバージョン _v2.6.12_ 以降のコミットをパッチとして表示する

‘git whatchanged --since="2 weeks ago" -- gitk’
     過去2週間の変更をファイル _gitk_ に表示します。 "–" は、「ブランチ
     名 _gitk_ 」との混同を避けるために必要です。

GIT
***

Part of the git(1) suite

Name
****

git-worktree — 複数の作業ツリーを管理します

Synopsis
********

     git worktree add [-f] [–detach] [–checkout] [–lock [–reason <string>]] [-b <new-branch>] <path> [<commit-ish>]
     git worktree list [–porcelain]
     git worktree lock [–reason <string>] <worktree>
     git worktree move <worktree> <new-path>
     git worktree prune [-n] [-v] [–expire <expire>]
     git worktree remove [-f] <worktree>
     git worktree repair [<path>…]
     git worktree unlock <worktree>

DESCRIPTION
***********

同一のリポジトリに接続されている複数の作業ツリーを管理します。

   gitリポジトリは複数の作業ツリーをサポートできるため、一度に複数のブラ
ンチをチェックアウトできます。‘git worktree add’ を使用すると、新しい作
業ツリーがリポジトリに関連付けられます。この新しい作業ツリーは、
git-init(1) または git-clone(1) によって作成された「メイン作業ツリー」
(main working tree)とは対照的に、「リンクされた作業ツリー」(linked
working tree)と呼ばれます。リポジトリには、1つのメイン作業ツリー(ベアリ
ポジトリでない場合)と、0個以上のリンクされた作業ツリーがあります。あなた
がリンクされた作業ツリーを使い終わったら、 ‘git worktree remove’ で削除
します。

   最も単純な形式では、 ‘git worktree add <path>’ は、名前が ‘<path>’ の
最後のコンポーネントである新しいブランチを自動的に作成します。これは、あ
なたが新しいトピックで作業する場合に便利です。たとえば、 ‘git worktree
add ../hotfix’ は、新しいブランチ ‘hotfix’ を作成し、パス ‘../hotfix’ で
チェックアウトします。代わりに、既存のブランチの新しい作業ツリーで作業す
るには、 ‘git worktree add <path> <branch>’ を使用します。一方、既存の開
発を妨げることなく実験的な変更やテストを行う場合は、ブランチに関連付けら
れていない「使い捨て」の作業ツリーを作成すると便利なことがよくあります。
たとえば、 ‘git worktree add -d <path>’ は、現在のブランチと同じコミット
で、切り離された‘HEAD‘(detached HEAD)を持つ新しい作業ツリーを作成します
。

   ‘git worktree remove’ を使用せずに作業ツリーを削除すると、リポジトリ
にある関連する管理ファイル(後述の「DETAILS」参照)が最終的には自動的に削
除されます(git-config(1) の ‘gc.worktreePruneExpire’ 参照)。または、メイ
ンまたはリンクされた作業ツリーで、古い管理ファイルをクリーンアップするた
めに ‘git worktree prune’ を実行できます。

   リンクされた作業ツリーが、常にマウントされているとは限らないポータブ
ルデバイスまたはネットワーク共有に保存されている場合、‘git worktree
lock’ コマンドを、オプションで ‘–reason‘を指定して、作業ツリーがロックさ
れている理由を説明して発行することで、管理ファイルが刈り込み(prune)され
ないようにすることができます。

COMMANDS
********

add <path> [<commit-ish>]
     ‘<path>’ を作成し、それに ‘<commit-ish>’ をチェックアウトします。 新
     しい作業ディレクトリは現在のリポジトリにリンクされ、 ‘HEAD’ や
     ‘index’ などの作業ディレクトリ固有のファイルを除くすべてを共有しま
     す。便宜上、 ‘<commit-ish>’ は裸の ‘-’ である場合があり、これは
     ‘@{-1}’ と同義です。

     上記 ‘<commit-ish>’ がブランチ名(以下 ‘<branch>’ とします)で見つか
     らず、 ‘-b’ や ‘-B’ や ‘--detach’ のいずれも使用されていないが、名
     前が一致する1つのリモート(以下 ‘<remote>’ とします)には追跡ブランチ
     が存在する場合、上記は以下と同等です:

          $ git worktree add --track -b <branch> <path> <remote>/<branch>

     ブランチが複数のリモートに存在し、そのうちの1つが
     ‘checkout.defaultRemote’ 設定変数によって名付けられた場合、
     ‘<branch>’ がすべてのリモートでユニークでなくても、曖昧さをなくすた
     めにその1つを使用します。例えば、 ‘checkout.defaultRemote=origin’ と
     設定すると、 ‘<branch>’ があいまいで、かつ ‘origin’ リモートに存在
     する場合、常にそこからリモートブランチをチェックアウトすることがで
     きます。git-config(1) にある ‘checkout.defaultRemote’ も参照してく
     ださい。

     ‘<commit-ish>’ が省略され、 ‘-b’ も ‘-B’ も ‘--detach’ も使用されて
     いない場合、便宜上、新しい作業ツリーは ‘$(basename <path>)’ にちな
     んで名付けらたブランチ(‘<branch>’ とします)に関連付けられます。
     ‘<branch>’ が存在しない場合、 ‘-b <branch>’ が指定されたかのように
     、 ‘HEAD’ に基づく新しいブランチが自動的に作成されます。
     ‘<branch>`が存在する場合で、他の場所でチェックアウトされていない場
     合は、新しい作業ツリーでチェックアウトされます。存在しない場合、コ
     マンドは作業ツリーの作成を拒否します(’–force‘ が使用されている場合
     を除く)。

list
     各作業ツリーの詳細を一覧表示します。 メインの作業ツリーが最初にリス
     トされ、次にリンクされた各作業ツリーがリストされます。 出力の詳細に
     含まれるのは、作業ツリーがベア(bare)であるかどうか、現在チェックア
     ウトされているリビジョン、現在チェックアウトされているブランチ(また
     は、存在しない場合は「切り離されたHEAD」(detached HEAD))、ワークツ
     リーがロックされている場合は「locked」、 ‘prune’ コマンドによってワ
     ークツリーを刈り込みできる場合は「prunable」です。

lock
     作業ツリーが常にマウントされているとは限らないポータブルデバイスま
     たはネットワーク共有上にある場合は、管理ファイルが自動的に刈り込み
     (prune)されないように、ツリーをロックします。 これにより、移動や削
     除も防止されます。 オプションで、‘--reason’ を使用してロックの理由
     を指定します。

move
     作業ツリーを新しい場所に移動します。このコマンドでは、メインの作業
     ツリーまたはサブモジュールを含むリンクされた作業ツリーを移動できな
     いことに注意してください。(ただし、 ‘git worktree repair’ コマンド
     を使用すると、メインの作業ツリーを手動で移動した場合に、リンクされ
     た作業ツリーとの接続を再確立できます。)

prune
     ‘$GIT_DIR/worktrees’ の作業ツリー情報を刈り込みます(prune)。

remove
     作業ツリーを削除します。削除できるのは、クリーンな作業ツリー(追跡し
     てないファイルが無く、かつ、追跡ファイルの変更が無い場合)のみです。
     汚れた作業ツリーまたはサブモジュールのあるツリーは、 ‘--force’ を使
     用して削除できます。メインの作業ツリーは削除できません。

repair [<path>…]
     可能であれば、外部要因によって破損または古くなった作業ツリー管理フ
     ァイルを修復します。

     たとえば、メインの作業ツリー(またはベアリポジトリ(bare
     repository))を移動すると、リンクされた作業ツリーはそれを見つけるこ
     とができなくなります。メインの作業ツリーで ‘repair’ を実行すると、
     リンクされた作業ツリーからメインの作業ツリーへの接続が再確立されま
     す。

     同様に、リンクされた作業ツリーが ‘git worktree move’ を使用せずに移
     動された場合、メインの作業ツリー(またはベアリポジトリ(bare
     repository))はそれを見つけることができません。直近に移動した作業ツ
     リー内で ‘repair’ を実行すると、接続が再確立されます。リンクされた
     作業ツリーが複数移動された場合、各作業ツリーの新しい ‘<path>’ を引
     数として任意の作業ツリーから ‘repair’ を実行すると、指定されたすべ
     てのパスへの接続が再確立されます。

     メイン作業ツリーとリンクされた作業ツリーの両方が手動で移動された場
     合、メイン作業ツリーで ‘repair’ を実行し、リンクされた各作業ツリー
     の新しい ‘<path>’ を指定すると、両方向のすべての接続が再確立されま
     す。

unlock
     作業ツリーのロックを解除(unlock)して、刈り込(prune)みまたは移動
     (move)または削除(delete)できるようにします。

OPTIONS
*******

‘-f’
‘--force’
     デフォルトでは、‘<commit-ish>’ がブランチ名であり、別の作業ツリーに
     よってすでにチェックアウトされている場合、または ‘<path>’ がすでに
     作業ツリーに割り当てられているが欠落している場合(たとえば、
     ‘<path>`が手動で削除された場合)、`add’ は新しい作業ツリーの作成を拒
     否します。このオプションは、これらの安全装置(safeguards)をオーバー
     ライドします。欠落しているがロックされている作業ツリーパスを追加す
     るには、‘--force’ を2回指定します。

     ‘--force’ が2回指定されていない限り、 ‘move’ はロックされた作業ツリ
     ーの移動を拒否します。移動先がすでに他の作業ツリーに割り当てられて
     いるが欠落している場合(たとえば、 ‘<new-path>’ が手動で削除された場
     合)は、 ‘--force’ は移動を続行できます。移動先がロックされている場
     合は、 ‘--force’ を2回使用します。

     ‘--force’ が使用されていない限り、 ‘remove’ は汚れた作業ツリー
     (unclean working tree)の削除を拒否します。ロックされた作業ツリーを
     削除するには、‘--force’ を2回指定します。

‘-b <new-branch>’
‘-B <new-branch>’
     ‘add’ を使用して、 ‘<commit-ish>’ から開始する ‘<new-branch>’ とい
     う名前の新しいブランチを作成し、 ‘<new-branch>’ を新しい作業ツリー
     にチェックアウトします。 ‘<commit-ish>’ を省略すると、デフォルトで
     ‘HEAD’ になります。 デフォルトでは、 ‘-b’ は、新しいブランチがすで
     に存在する場合、それを作成することを拒否します。 ‘-B’ はこの安全装
     置をオーバーライドし、 ‘<new-branch>’ を ‘<commit-ish>’ にリセット
     します。

‘-d’
‘--detach’
     ‘add’ を使用して、新しい作業ツリーで ‘HEAD’ を切り離します
     (detach)。 git-checkout(1) の「DETACHED HEAD」を参照してください。

‘--[no-]checkout’
     デフォルトでは、 ‘add’ は ‘<commit-ish>’ をチェックアウトしますが、
     ‘--no-checkout’ を使用して、スパースチェックアウト(suppress
     checkout)の構成などのカスタマイズを行うためにチェックアウトを抑制す
     ることができます。 git-read-tree(1) の「Sparse checkout」を参照して
     ください。

‘--[no-]guess-remote’
     ‘<commit-ish>’ を伴わずに ‘worktree add <path>’ を使用し、 ‘HEAD’ か
     ら新しいブランチを作成する代わりに、 ‘<path>’ のベース名に一致する
     追跡ブランチが１つリモートにだけ存在する場合、新しいブランチをその
     リモート追跡ブランチに基づいて作成し、そのリモート追跡ブランチを新
     しいブランチの「アップストリーム」としてマークします。

     これは、 ‘worktree.guessRemote’ 構成オプションを使用してデフォルト
     の動作として設定することもできます。

‘--[no-]track’
     新しいブランチを作成するときに、 ‘<commit-ish>’ がブランチである場
     合は、新しいブランチの「アップストリーム」としてマークします。
     ‘<commit-ish>’ がリモート追跡ブランチの場合、これの振る舞いがデフォ
     ルトです。詳細については、 git-branch(1)の ‘--track’ を参照してくだ
     さい。

‘--lock’
     作成後は、作業ツリーをロックしたままにします。 これは、 ‘git
     worktree add’ の後に ‘git worktree lock’ するのと同等ですが、競合状
     態(race condition)はありません。

‘-n’
‘--dry-run’
     ‘prune’ では、何も削除しないでください。何が削除されるかを報告する
     だけです。

‘--porcelain’
     ‘list’ を使用すると、スクリプトの解析が容易な形式で出力されます。こ
     の形式は、Gitのバージョン間で、ユーザー構成に関係なく安定しています
     。詳細については、後述します。

‘-q’
‘--quiet’
     ‘add’ を使用して、フィードバックメッセージを抑制します。

‘-v’
‘--verbose’
     ‘prune’ を使用して、すべての削除を報告します。

     ‘list’ を使用して、ワークツリーに関する追加情報を出力します(後述)。

‘--expire <time>’
     ‘prune’ と共に使うと、 ‘<time>’ より古い未使用の作業ツリーのみを期
     限切れにします。

     ‘list’ と共に使うと、 ‘<time>’ より古い場合は、欠落している作業ツリ
     ーに刈り込み可能(prunable)という注釈(annotate)を付けます。

‘--reason <string>’
     ‘lock’ または ‘add --lock’ と共に使用して、作業ツリーがロックされて
     いる理由の説明とします。

<worktree>
     作業ツリーは、相対パスまたは絶対パスのいずれかで識別できます。

     作業ツリーのパスの最後のパスコンポーネントが作業ツリー間で一意であ
     る場合、それを使用して作業ツリーを識別できます。 たとえば、
     ‘/abc/def/ghi’ と ‘/abc/def/ggg’ の2つの作業ツリーしかない場合、前
     の作業ツリーを指すには、 ‘ghi’ または ‘def/ghi’ で十分です。

REFS
****

複数の作業ツリーでは、一部のrefはすべての作業ツリー間で共有される場合が
あり、一部のrefはローカルです。 一例として、作業ツリーごとに異なる
‘HEAD’ があります。このセクションでは、共有ルールと、ある作業ツリーの
refに別の作業ツリーからアクセスする方法について説明します。

   一般に、すべての疑似ref(pseudo refs)は作業ツリーごとにあり、そして、
‘refs/’ で始まるすべての参照は共有されます。 疑似refは、 ‘$GIT_DIR/refs’
内ではなく、 ‘$GIT_DIR’ の直下にある ‘HEAD’ のようなものです。 ただし、
例外があります。 ‘refs/bisect’ 内のrefと ‘refs/worktree’ は共有されませ
ん。

   作業ツリーごとのrefには、別の作業ツリーから、 ‘main-worktree’ と
‘worktrees’ の2つの特別なパスを介してアクセスできます。 ‘main-worktree’
はメインの作業ツリーから作業ごとのツリーrefへのアクセスを提供し、
‘worktrees’ すべてのリンクされた作業ツリーへのアクセスを提供します。

   たとえば、 ‘main-worktree/HEAD’ または
‘main-worktree/refs/bisect/good’ は、それぞれメインの作業ツリーの ‘HEAD’
および ‘refs/bisect/good ` と同じ値に解決されます。 同様に、
`worktrees/foo/HEAD’ または ‘worktrees/bar/refs/bisect/bad’ は
‘$GIT_COMMON_DIR/worktrees/foo/HEAD’ および
‘$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad’ と同じです。

   refにアクセスするのに ‘$GIT_DIR’ の内部を直接調べないことをお勧めしま
す。代わりに、refを正しく処理する git-rev-parse(1) や git-update-ref(1)
などのコマンドを使用してください。

CONFIGURATION FILE
******************

デフォルトでは、リポジトリの ‘config’ ファイルはすべての作業ツリー間で共
有されます。構成変数 ‘core.bare’ または ‘core.worktree’ が構成ファイルに
すでに存在する場合、それらはメインの作業ツリーにのみ適用されます。

   作業ツリーに固有の構成を作成するには、 ‘worktreeConfig’ 拡張機能をオ
ンにします。例:

     $ git config extensions.worktreeConfig true

   このモードでは、指定の構成は ‘git rev-parse --git-path
config.worktree’ が指すパスに残ります。 ‘git config --worktree’ を使用し
て、このファイルの構成を追加または更新できます。古いバージョンのGitは、
この拡張機能を備えたリポジトリへのアクセスを拒否します。

   注意: このファイルでは、 ‘core.bare’ と ‘core.worktree’ が例外扱いさ
れないことに注意してください。 それらが ‘$GIT_DIR/config’ に存在する場合
は、メインの作業ツリーの ‘config.worktree’ に移動する必要があります。こ
の機会に、共有したくない他の構成を確認して、すべての作業ツリーに移動する
こともできます。

   • ‘core.worktree’ と ‘core.bare’ は決して共有しないでください

   • すべての作業ツリーに常にスパースチェックアウト(sparse checkout)を使
     用することが確実でない限りは、作業ツリーごとに
     ‘core.sparseCheckout’ をお勧めします。

DETAILS
*******

リンクされた各作業ツリーには、リポジトリの ‘$ GIT_DIR/worktrees`ディレク
トリにプライベートサブディレクトリがあります。 プライベートサブディレク
トリの名前は通常、リンクされた作業ツリーのパスのベース名であり、一意にす
るために番号が追加される場合があります。たとえば、
`$GIT_DIR=/path/main/.git’ の場合、コマンド ‘git worktree add
/path/other/test-next next’ はリンクされた作業ツリーを
‘/path/other/test-next`に作成し、そしてまた
`$GIT_DIR/worktrees/test-next’ ディレクトリ(または、 ‘test-next’ がすで
に実行されている場合は、 ‘$GIT_DIR/worktrees/test-next1’ ディレクトリ)を
作成します。

   リンクされた作業ツリー内で、 ‘$GIT_DIR’ は、このプライベートディレク
トリを指すように設定され(例では ‘/path/main/.git/worktrees/test-next’ )、
‘$GIT_COMMON_DIR’ はメインの作業ツリーの ‘$GIT_DIR’ (例では
‘/path/main/.git’ )を指すように設定されます。これらの設定は、リンクされ
た作業ツリーの最上位ディレクトリにある ‘.git’ ファイルで行われます。

   ‘git rev-parse --git-path’ によるパス解決では、パスに応じて
‘$GIT_DIR’ または ‘$GIT_COMMON_DIR’ のいずれかが使用されます。たとえば、
リンクされた作業ツリーでは、 ‘git rev-parse --git-path HEAD’ は
‘/path/main/.git/worktrees/test-next/HEAD’ を返します
(‘/path/other/test-next/.git/HEAD’ や ‘/path/main/.git/HEAD’ ではありま
せん)。一方、 ‘git rev-parse --git-path refs/heads/master’ は
‘$GIT_COMMON_DIR’ を使用し、 ‘/path/main/.git/refs/heads/ master’ を返し
ます。refは、 ‘refs/bisect’ と ‘refs/worktree’ を除くすべての作業ツリー
で共有されるためです。

   詳細については、 gitrepository-layout(5) を参照してください。 経験則
では、 ‘$GIT_DIR’ 内の何かに直接アクセスする必要がある場合、パスが
‘$GIT_DIR’ または ‘$GIT_COMMON_DIR’ のどちらに属するかについては何も想定
していません。 ‘git rev-parse --git-path’ を使用して、最終的なパスを取得
してください。

   リンクされた作業ツリーを手動で移動する場合は、エントリのディレクトリ
にある ‘gitdir’ ファイルを更新する必要があります。 たとえば、リンクされ
た作業ツリーが ‘/newpath/test-next’ に移動され、その ‘.git’ ファイルが
‘/path/main/.git/worktrees/test-next’ を指しているならば、代わりに
‘/path/main/.git/worktrees/test-next/gitdir’ を更新し
‘/newpath/test-next’ を参照するようにします。もっといいのは、 ‘git
worktree repair’ を実行して、接続を自動的に再確立することです。

   ‘$GIT_DIR/worktrees’ エントリが刈り込み(prune)されないようにする(これ
は、エントリの作業ツリーがポータブルデバイスに保存されている場合など、状
況によっては便利です)には、 ‘git worktree lock’ コマンドを使用します。こ
のコマンドは ‘locked’ という名前のファイルをエントリのディレクトリに追加
します。ファイルには、理由(reason)がプレーンテキストで含まれています。た
とえば、リンクされた作業ツリーの ‘.git’ ファイルが
‘/path/main/.git/worktrees/test-next’ を指しているならば、
‘/path/main/.git/worktrees/test-next/locked’ という名前のファイルは
‘test-next’ エントリが刈り込み(pruned)されるのを防ぎます。詳細については
、 gitrepository-layout(5) を参照してください。

   ‘extensions.worktreeConfig’ が有効になっている場合、設定ファイル
‘.git/worktrees/<id>/config.worktree’ は ‘.git/config’ の後に読み込まれ
ます。

LIST OUTPUT FORMAT
******************

‘worktreelist’ コマンドには2つの出力形式があります。デフォルトの形式では
、詳細が1行に複数列で表示されます。例えば:

     $ git worktree list
     /path/to/bare-source            (bare)
     /path/to/linked-worktree        abcd1234 [master]
     /path/to/other-linked-worktree  1234abc  (detached HEAD)

   このコマンドは、状態に応じて、各作業ツリーの注釈(annotations)も表示し
ます。これらの注釈は以下のとおりです:

   • ‘locked’ : 作業ツリーがロックされている場合。

   • ‘prunable’ : 作業ツリーが ‘git worktree prune’ を介して刈り込みでき
     る場合。

     $ git worktree list
     /path/to/linked-worktree    abcd1234 [master]
     /path/to/locked-worktree    acbd5678 (brancha) locked
     /path/to/prunable-worktree  5678abc  (detached HEAD) prunable

   これらの注釈(annotations)については、理由(reason)も利用できる可能性が
あり、これは冗長モード(verbose mode)を使用して確認できます。そして、注釈
はインデントされた次の行に移動され、その後に追加情報が続きます。

     $ git worktree list --verbose
     /path/to/linked-worktree              abcd1234 [master]
     /path/to/locked-worktree-no-reason    abcd5678 (detached HEAD) locked
     /path/to/locked-worktree-with-reason  1234abcd (brancha)
             locked: working tree path is mounted on a portable device
     /path/to/prunable-worktree            5678abc1 (detached HEAD)
             prunable: gitdir file points to non-existent location

   注意: 追加情報が利用可能な場合、注釈は次の行に移動されることに注意し
てください。そうでない場合、注釈は作業ツリー自体と同じ行にとどまります。

Porcelain Format
================

磁器コマンドのフォーマットは、属性ごとに1行あります。 属性は、単一のスペ
ースで区切られたラベルと値でリストされます。ブール属性(‘bare’ や
‘detached’ など)はラベルとしてのみリストされ、値がtrueの場合にのみ存在し
ます。 一部の属性(‘locked’ など)は、ラベルとしてのみリストすることも、理
由が利用可能かどうかに応じて値とともにリストすることもできます。作業ツリ
ーの最初の属性は常に ‘worktree’ であり、空の行はレコードの終わりを示しま
す。例えば:

     $ git worktree list --porcelain
     worktree /path/to/bare-source
     bare

     worktree /path/to/linked-worktree
     HEAD abcd1234abcd1234abcd1234abcd1234abcd1234
     branch refs/heads/master

     worktree /path/to/other-linked-worktree
     HEAD 1234abc1234abc1234abc1234abc1234abc1234a
     detached

     worktree /path/to/linked-worktree-locked-no-reason
     HEAD 5678abc5678abc5678abc5678abc5678abc5678c
     branch refs/heads/locked-no-reason
     locked

     worktree /path/to/linked-worktree-locked-with-reason
     HEAD 3456def3456def3456def3456def3456def3456b
     branch refs/heads/locked-with-reason
     locked reason why is locked

     worktree /path/to/linked-worktree-prunable
     HEAD 1233def1234def1234def1234def1234def1234b
     detached
     prunable gitdir file points to non-existent location

   ロック理由に改行などの「異常な」文字が含まれている場合、それらはエス
ケープされ、構成変数 ‘core.quotePath’ で説明されているように理由全体がク
ォートされます(git-config(1) 参照)。例えば:

     $ git worktree list --porcelain
     ...
     locked "reason\nwhy is locked"
     ...

EXAMPLES
********

リファクタリングセッションの真っ最中に、上司がやって来て、あなたに、すぐ
に何かを修正するように要求します。 通常、 git-stash(1) を使用して変更を
一時的に保存しますが、作業ツリーは、(新しいファイル、移動されたファイル
、削除されたファイル、その他の断片が散らばっていて)混乱状態にあります。
あなたはそれのいずれかを邪魔する危険を冒したくありません。あなたは代わり
に、一時的にリンクされた作業ツリーを作成して緊急修正を行い、完了したらそ
れを削除してから、以前のリファクタリングセッションを再開することにします
。

     $ git worktree add -b emergency-fix ../temp master
     $ pushd ../temp
     # ... hack hack hack ...
     $ git commit -a -m 'emergency fix for boss'
     $ popd
     $ git worktree remove ../temp

BUGS
****

一般的な複数チェックアウト(multiple checkout)はまだ実験段階であり、サブ
モジュールのサポートは不完全です。スーパープロジェクトを複数チェックアウ
トすることはお勧めしません。

GIT
***

Part of the git(1) suite

Name
****

git-write-tree — 現在のインデックスからツリーオブジェクトを作成します

Synopsis
********

     git write-tree [–missing-ok] [–prefix=<prefix>/]

DESCRIPTION
***********

現在のインデックスを使用してツリーオブジェクトを作成します。新しいツリー
オブジェクトの名前が標準出力に出力されます。

   インデックスは完全にマージされた状態である必要があります。

   概念的には、 _git write-tree_ は、現在のインデックスの内容をツリーフ
ァイルのセットに sync() します。現在ディレクトリに実際にあるものと一致さ
せるには、 _git write-tree_ を実行する前に _git update-index_ フェイズを
実行する必要があります。

OPTIONS
*******

‘--missing-ok’
     通常、 _git write-tree_ は、ディレクトリによって参照されるオブジェ
     クトがオブジェクトデータベースに存在することを保証します。このオプ
     ションは、このチェックを無効にします。

‘--prefix=<prefix>/’
     サブディレクトリ ‘<prefix>’ を表すツリーオブジェクトを書き込みます
     。これは、指定されたサブディレクトリにあるサブプロジェクトのツリー
     オブジェクトを書き込むために使用できます。

GIT
***

Part of the git(1) suite

Name
****

git — くだらないコンテンツトラッカー

Synopsis
********

     git [–version] [–help] [-C <path>] [-c <name>=<value>]
         [–exec-path[=<path>]] [–html-path] [–man-path] [–info-path]
         [-p|–paginate|-P|–no-pager] [–no-replace-objects] [–bare]
         [–git-dir=<path>] [–work-tree=<path>] [–namespace=<name>]
         [–super-prefix=<path>] [–config-env=<name>=<envvar>]
         <command> [<args>]

DESCRIPTION
***********

Gitは、高速でスケーラブルな分散型リビジョン管理システムであり、高レベル
の操作と内部へのフルアクセスの両方を提供する非常に豊富なコマンドセットを
備えています。

   始めは gittutorial(7) を参照してください。次に、便利な最小限のコマン
ドセットについては giteveryday(7) を参照してください。 Git User’s Manual
(user-manual.html) には、より詳細な紹介があります。

   あなたが基本的な概念をマスターしたら、このページに戻ってGitが提供する
コマンドを学ぶことができます。「git help command」を使用して、個々の
Gitコマンドについて詳しく知ることができます。 gitcli(7) のマニュアルペー
ジには、コマンドラインコマンド構文の概要が記載されています。

   最新のGitドキュメントの、フォーマットされ、ハイパーリンクされたコピー
は、 https://git.github.io/htmldocs/git.html
(https://git.github.io/htmldocs/git.html) または
https://git-scm.com/docs (https://git-scm.com/docs) で表示できます。

OPTIONS
*******

‘--version’
     _git_ プログラムの元となったGitスイートのバージョンを出力します。

     このオプションは内部で ‘git version ...’ に変換されるので、
     git-version(1) コマンドと同じオプションを受け入れます。 ‘--help’ も
     指定されている場合は ‘--version’ よりも優先されます。

‘--help’
     概要と、最も一般的に使用されるコマンドのリストを出力します。 オプシ
     ョン ‘--all’ または ‘-a’ を指定すると、使用可能なすべてのコマンドが
     出力されます。Gitコマンドが明示された場合、このオプションはそのコマ
     ンドのマニュアルページを表示します。

     マニュアルページの表示方法を制御するために、他のオプションを使用で
     きます。‘git --help ...’ は内部で ‘git help ...’ に変換されるため、
     詳細については git-help(1) を参照してください。

‘-C <path>’
     現在の作業ディレクトリではなく、「<path>」でgitが開始されたかのよう
     に実行します。 複数の ‘-C’ オプションが指定されている場合、後続の「
     非絶対 ‘-C <path> ` 」は、それぞれ先行する `-C <path>’ に関連して解
     釈されます。 ’<path>’は存在するが空の場合(例: ‘-C" "’)の場合、現在
     の作業ディレクトリは変更されません。

     このオプションは、パス名の解釈が ‘-C’ オプションによって引き起こさ
     れる作業ディレクトリに対して行われるという点で、 ‘--git-dir’ や
     ‘--work-tree’ のようなパス名を期待するオプションに影響します。たと
     えば、以下の2つの呼び出しは同等です:

          git --git-dir=a.git --work-tree=b -C c status
          git --git-dir=c/a.git --work-tree=c/b status

‘-c <name>=<value>’
     構成パラメーターをコマンドに渡します。指定された値は、構成ファイル
     の値を上書きします。 <name>は、「git config」(ドットで区切られたサ
     ブキー)でリストされているものと同じ形式である必要があります。

     ‘git -c foo.bar ...’ で ‘=’ を省略することは許可されており、その場
     合 ‘foo.bar’ を(設定ファイルの ‘[foo]bar’ と同様に)ブール値のtrueに
     設定することに注意してください。等号と空の値(‘git -c foo.bar= ...’
     など)を含むと、 ‘foo.bar’ が空の文字列に設定されます。 ‘git config
     --type=bool’ ではこれを ‘false’ に変換します。

‘--config-env=<name>=<envvar>’
     ‘-c <name>=<value>’ と同様に、構成変数 _<name>_ に値を指定します。
     ここで、 <envvar> は、値を取得する環境変数の名前です。 ‘-c’ とは異
     なり、値を空の文字列に直接設定するためのショートカットはありません
     。代わりに、環境変数自体を空の文字列に設定する必要があります。
     ‘<envvar>’ が環境に存在しない場合はエラーになります。 ‘<envvar>’ に
     は等号を含めることはできません。これは、 ‘<name>’ に等号が含まれて
     いる場合のあいまいさを避けるためです。

     これは、あなたが一時的な構成オプションをgitに渡したいが、他のプロセ
     スで、あなたのコマンドライン(たとえば ‘/proc/self/cmdline’)は読み取
     れるが、あなたの環境(たとえば ‘/proc/self/environ’)は読み取れない可
     能性があるOS上で作業している場合に役立ちます。この動作はLinuxのデフ
     ォルトですが、あなたのシステムでは設定されてない場合があります。

     注意:これにより、機密情報が値の一部である ‘http.extraHeader’ などの
     変数のセキュリティが追加される可能性がありますが、機密情報をキーの
     一部にすることができるモノ、例えば ‘url.<base>.insteadOf’ は使用で
     きません。

‘--exec-path[=<path>]’
     あなたのコアGitプログラムがインストールされている場所へのパス。これ
     は、 GIT_EXEC_PATH 環境変数を設定することによっても制御できます。パ
     スが指定されていない場合、「git」は現在の設定を出力して終了します。

‘--html-path’
     GitのHTMLドキュメントがインストールされているパスを末尾のスラッシュ
     なしで印刷し、終了します。

‘--man-path’
     このバージョンのGitのマニュアルページのmanpath(‘man(1)’ 参照)を印刷
     して終了します。

‘--info-path’
     このバージョンのGitを文書化したInfoファイルがインストールされている
     パスを印刷して終了します。

‘-p’
‘--paginate’
     標準出力が端末の場合は、すべての出力を _less_ (または設定されている
     場合は $PAGER )にパイプします。これにより、 ‘pager.<cmd>’ 構成オプ
     ションが上書きされます(以下の「Configuration Mechanism」セクション
     を参照)。

‘-P’
‘--no-pager’
     Git出力をページャーにパイプしないでください。

‘--git-dir=<path>’
     リポジトリ(".git" ディレクトリ)へのパスを設定します。これは、
     ‘GIT_DIR’ 環境変数を設定することによっても制御できます。現在の作業
     ディレクトリへの絶対パスまたは相対パスにすることができます。

     このオプションを使用して ‘.git’ ディレクトリの場所を指定すると、 (リ
     ポジトリとトップレベルの作業ツリーを検出できる、) ‘.git’ サブディレ
     クトリを持つディレクトリを検索しようとするリポジトリ検出機能がオフ
     になり、あなたが作業ツリーの最上位にいるとGitに通知します。あなたが
     作業ツリーの最上位ディレクトリにいない場合は、 ‘--work-tree=<path>’
     オプション(または ‘GIT_WORK_TREE’ 環境変数)を使用して、作業ツリーの
     最上位がどこにあるかをGitに通知する必要があります。

     ‘<path>’ で開始されたかのようにgitを実行したい場合は、 ‘git -C
     <path>’ を使用します。

‘--work-tree=<path>’
     作業ツリーへのパスを設定します。絶対パスまたは現在の作業ディレクト
     リからの相対パスにすることができます。これは、 GIT_WORK_TREE環境変
     数とcore.worktree構成変数を設定することによっても制御できます(詳細
     については、 git-config(1) の core.worktree を参照してください)。

‘--namespace=<path>’
     Git名前空間を設定します。詳細については linkgit: gitnamespaces[7] を
     参照してください。 ‘GIT_NAMESPACE’ 環境変数を設定するのと同じです。

‘--super-prefix=<path>’
     現在、内部使用のみです。リポジトリの上位からそのリポジトリのルート
     までのパスを与えるプレフィックスを設定します。1つの使用法は、サブモ
     ジュールに、それを呼び出したスーパープロジェクトに関するコンテキス
     トを与えることです。

‘--bare’
     リポジトリをベアリポジトリとして扱います。GIT_DIR環境が設定されてい
     ない場合は、現在の作業ディレクトリに設定されます。

‘--no-replace-objects’
     Gitオブジェクトを置き換えるための置換refを使用しません。 詳細につい
     ては git-replace(1) を参照してください。

‘--literal-pathspecs’
     パススペックを文字通り扱います(つまり globbing 無し、 pathspec
     magic 無しです)。 これは、 ‘GIT_LITERAL_PATHSPECS’ 環境変数を ‘1’ に
     設定するのと同じです。

‘--glob-pathspecs’
     すべてのパススペックにグロブマジック(glob magic)を追加します。 これ
     は、 ‘GIT_GLOB_PATHSPECS’ 環境変数を ‘1’ に設定するのと同じです。 個
     々のパススペックで globbing を無効にするには、パススペックマジック
     ‘:(literal)’ を使用します。

‘--noglob-pathspecs’
     すべてのパススペックにリテラルマジック(literal magic)を追加します。
     これは、 ‘GIT_NOGLOB_PATHSPECS’ 環境変数を ‘1’ に設定するのと同じで
     す。個々のパススペックでグロブを有効にするには、パススペックマジッ
     ク ‘:(glob)’ を使用します。

‘--icase-pathspecs’
     すべてのパススペックに icase magic を追加します。 これは、
     ‘GIT_ICASE_PATHSPECS’ 環境変数を ‘1’ に設定するのと同じです。

‘--no-optional-locks’
     ロック(lock)を必要とするオプションの操作は実行しないでください。こ
     れは、 ‘GIT_OPTIONAL_LOCKS’ を ‘0’ に設定するのと同じです。

‘--list-cmds=group[,group...]’
     コマンドをグループ別に一覧表示します。これは 内部/実験的 なオプショ
     ンであり、将来変更または削除される可能性があります。サポートされて
     いるグループは、builtins、parseopt(parse-optionsを使用するbuiltinコ
     マンド)、main(libexecディレクトリ内のすべてのコマンド)、その他
     (git-プレフィックスを持つ ‘$PATH’ 内の他のすべてのコマンド)、
     list-<category> (command-list.txt 内の categories を参照)、
     nohelpers(ヘルパーコマンドを除く)、alias、config(構成変数
     completion.commands から取得したコマンドリスト)、です。

GIT COMMANDS
************

私達はGitを、高レベル(porcelain;磁器)コマンドと低レベル(plumbing;配管)コ
マンドに分けています。

High-level commands (porcelain)
*******************************

磁器コマンドは、メインコマンド群といくつかの補助ユーティリティに分けられ
ます。

Main porcelain commands
=======================

git-add(1)
     ファイルの内容をインデックスに追加します.

git-am(1)
     メールボックスから一連のパッチを適用します.

git-archive(1)
     名前付きツリーからファイルのアーカイブを作成します.

git-bisect(1)
     二分木検索を使用して、バグを引き起こしたコミットを見つけます.

git-branch(1)
     ブランチを、一覧表示または作成または削除します.

git-bundle(1)
     アーカイブごとにオブジェクトとrefを移動します.

git-checkout(1)
     ブランチの切り替え、または作業ツリーファイルの復元を行います。.

git-cherry-pick(1)
     いくつかの既存のコミットによって導入された変更を適用します.

git-citool(1)
     git-commitのグラフィカルな代替手段.

git-clean(1)
     作業ツリーから追跡されていないファイルを削除する.

git-clone(1)
     リポジトリを新しいディレクトリにクローン(複製)します.

git-commit(1)
     変更をリポジトリへ記録します.

git-describe(1)
     有効なrefに基づいて、オブジェクトに人間が読める形式の名前を付けます
     .

git-diff(1)
     コミット、コミット、作業ツリーなどの間の変更を表示する.

git-fetch(1)
     別のリポジトリからオブジェクトとrefsをダウンロードします.

git-format-patch(1)
     電子メール送信用のパッチを準備します.

git-gc(1)
     不要なファイルをクリーンアップし、ローカルリポジトリを最適化する.

git-grep(1)
     パターンにマッチする行を出力します.

git-gui(1)
     Gitのための移植性の高いGUI.

git-init(1)
     空のGitリポジトリを作成するか、既存のリポジトリを再初期化します.

git-log(1)
     コミットのログを表示.

git-maintenance(1)
     Gitリポジトリのデータを最適化するためのタスクの実行.

git-merge(1)
     2つまたはそれ以上の開発履歴を結合します.

git-mv(1)
     ファイルまたはディレクトリまたはシンボリックリンクを移動(move)また
     は名前変更(rename)します.

git-notes(1)
     オブジェクトノートを追加または検査します.

git-pull(1)
     別のリポジトリまたはローカルブランチから取得して統合する.

git-push(1)
     関連するオブジェクトとともにリモートrefを更新します.

git-range-diff(1)
     2つのコミット範囲(例: ブランチの2つのバージョン)を比較します.

git-rebase(1)
     別のベース先端の上にコミットを再適用します.

git-reset(1)
     現在のHEADを指定の状態にリセットします.

git-restore(1)
     作業ツリーファイルを復元します.

git-revert(1)
     いくつかの既存のコミットを元に戻します.

git-rm(1)
     作業ツリーとインデックスからファイルを削除します.

git-shortlog(1)
     _git log_ の出力を要約します。.

git-show(1)
     さまざまなタイプのオブジェクトを表示.

git-sparse-checkout(1)
     チェックアウトをパターンのリストで指定されたパスのセットに減らしま
     す.

git-stash(1)
     汚い作業ディレクトリの変更を隠します.

git-status(1)
     作業ツリーの状態を表示します.

git-submodule(1)
     サブモジュールを初期化、更新、または検査します.

git-switch(1)
     ブランチを切り替える.

git-tag(1)
     GPG署名されたタグオブジェクトを作成、一覧表示、削除、検証します.

git-worktree(1)
     複数の作業ツリーを管理します.

gitk(1)
     Gitリポジトリブラウザ.

Ancillary Commands(補助コマンド)
================================

操作コマンド:

git-config(1)
     リポジトリオプションまたはグローバルオプションを、取得および設定す
     る.

git-fast-export(1)
     Gitデータエクスポーター.

git-fast-import(1)
     高速Gitデータインポーターのバックエンド.

git-filter-branch(1)
     ブランチを書き換えます.

git-mergetool(1)
     マージ競合解決ツールを実行して、マージ競合を解決します.

git-pack-refs(1)
     効率的なリポジトリアクセスのためにヘッド(heads)とタグ(tags)をパック
     します.

git-prune(1)
     オブジェクトデータベースで、到達不能なすべてのオブジェクトを剪定
     (prune)します.

git-reflog(1)
     reflog情報を管理します.

git-remote(1)
     追跡中のリポジトリの組を管理します.

git-repack(1)
     リポジトリ内のアンパックオブジェクトをパックする.

git-replace(1)
     オブジェクトを置き換えるためのrefsの作成、一覧表示、削除.

   問合せコマンド:

git-annotate(1)
     指定ファイルの各行のコミット情報を表示.

git-blame(1)
     ファイルの各行を最後に変更したリビジョンと作者を表示する.

git-bugreport(1)
     ユーザーがバグ報告を提出するための情報を収集する.

git-count-objects(1)
     パックされていない(unpack)オブジェクトの数とそのディスク消費量を計
     量します.

git-difftool(1)
     一般的なdiffツールを使用して変更を表示します.

git-fsck(1)
     データベース内のオブジェクトの接続性(connectivity)と有効性
     (validity)を検証します.

git-help(1)
     Gitに関するヘルプ情報を表示します.

git-instaweb(1)
     gitwebで作業リポジトリをインスタントにブラウズします.

git-merge-tree(1)
     インデックスに触れずに(without touching)3者間マージを表示する.

git-rerere(1)
     競合するマージの記録された競合解決決定を再利用する.

git-show-branch(1)
     ブランチとそのコミットを表示します.

git-verify-commit(1)
     コミットのGPG署名を確認します。.

git-verify-tag(1)
     タグのGPG署名を確認する.

git-whatchanged(1)
     各コミットでの差分のログを表示.

gitweb(1)
     Git Webインターフェイス(GitリポジトリのためのWebフロントエンド).

Interacting with Others(他者との交流)
=====================================

これらのコマンドは、電子メールを利用したパッチを介して、他のSCMや人々と
対話するためのものです。

git-archimport(1)
     GNU Arch リポジトリをGitにインポートします.

git-cvsexportcommit(1)
     単一のコミットをCVSチェックアウトにエクスポートします.

git-cvsimport(1)
     別の嫌われ者のSCMからあなたのデータを救難救助する.

git-cvsserver(1)
     Git用のCVSサーバーエミュレーター.

git-imap-send(1)
     標準入力からIMAPフォルダへパッチのコレクションを送信します.

git-p4(1)
     Perforceリポジトリからのインポートと、Perforceリポジトリへのsubmit.

git-quiltimport(1)
     quilt(キルト)パッチセットを現在のブランチに適用します.

git-request-pull(1)
     保留中の変更の概要を生成します.

git-send-email(1)
     パッチの集まりを電子メールとして送信します.

git-svn(1)
     SubversionリポジトリとGit間の双方向操作.

Reset, restore and revert
=========================

同様の名前の3つのコマンドがあります。それは ‘git reset’ と ‘git restore’
と ‘git revert’ です。

   • git-revert(1) は、他のコミットによって行われた変更を元に戻す新しい
     コミットを作成することです。

   • git-restore(1) は、インデックスまたは別のコミットから作業ツリー内の
     ファイルを復元することです。このコマンドはブランチを更新しません。
     このコマンドを使用して、別のコミットからインデックス内のファイルを
     復元することもできます。

   • git-reset(1) は、ブランチを更新し、ブランチにコミットを追加または削
     除するために先端ポインタが指し示す先端(tip)を移動させることです。こ
     の操作により、コミット履歴が変更されます。

     ‘git restore’ と重複しますが、 ‘git reset’ はインデックスを復元する
     ためにも使用できます。

Low-level commands (plumbing)
*****************************

Gitには独自の磁器コマンドレイヤーが含まれていますが、代替磁器コマンドの
開発をサポートするには、その低レベルのコマンドで十分です。このような磁器
コマンドの開発者は git-update-index(1) と git-read-tree(1) を読むことか
ら始めるといいでしょう。

   これらの低レベルコマンドへのインターフェイス(入力、出力、オプションの
セット、セマンティクス)は、これらのコマンドが主にスクリプトで使用される
ため、磁器レベルのコマンドよりもはるかに安定していることを意味します。 一
方、磁器コマンドへのインターフェースは、エンドユーザーエクスペリエンスを
向上させるために変更される可能性があります。

   以下の説明では、低レベルのコマンドを、オブジェクト(リポジトリ、インデ
ックス、作業ツリー内)を操作するコマンドと、オブジェクトに問い合わせて比
較するコマンドと、リポジトリ間でオブジェクトと参照を移動するコマンドに、
分けています。

Manipulation commands(操作コマンド)
===================================

git-apply(1)
     パッチをファイルやインデックスに適用します.

git-checkout-index(1)
     インデックスから作業ツリーにファイルをコピー.

git-commit-graph(1)
     Gitコミットグラフファイル(commit-graph file)の書き出しと検証
     (verify).

git-commit-tree(1)
     新しいコミットオブジェクトを作成します.

git-hash-object(1)
     オブジェクトIDを計算し、オプションでファイルからブロブを作成する.

git-index-pack(1)
     既存のパックされたアーカイブのパックインデックスファイル構築.

git-merge-file(1)
     3方向ファイルマージを実行する.

git-merge-index(1)
     マージが必要なファイルのマージを実行します.

git-mktag(1)
     追加の検証(extra validation)でタグオブジェクトを作成します.

git-mktree(1)
     ls-tree形式のテキストからツリーオブジェクトを構築する.

git-multi-pack-index(1)
     multi-pack-indexを書き出し・検証します.

git-pack-objects(1)
     オブジェクトのパックされたアーカイブを作成する.

git-prune-packed(1)
     すでにパックファイルにある余分なオブジェクトを削除します.

git-read-tree(1)
     ツリー情報をインデックスに読み込みます.

git-symbolic-ref(1)
     シンボリックrefの読み取り、変更、および削除.

git-unpack-objects(1)
     パックされたアーカイブからオブジェクトを取り出します.

git-update-index(1)
     作業ツリーのファイルの内容をインデックスに登録します.

git-update-ref(1)
     refに保存されているオブジェクト名を安全に更新します.

git-write-tree(1)
     現在のインデックスからツリーオブジェクトを作成します.

Interrogation commands(問合せコマンド)
======================================

git-cat-file(1)
     リポジトリオブジェクトのコンテンツまたはタイプとサイズの情報を提供
     します.

git-cherry(1)
     アップストリームにまだ適用されていないコミットを検索する.

git-diff-files(1)
     作業ツリーとインデックス内のファイルを比較します.

git-diff-index(1)
     ツリーを作業ツリーまたはインデックスと比較します.

git-diff-tree(1)
     2つのツリーオブジェクト間で、ブロブの内容とモードを比較します.

git-for-each-ref(1)
     各refに関する情報を出力します.

git-for-each-repo(1)
     リポジトリのリストでGitコマンドを実行します.

git-get-tar-commit-id(1)
     git-archiveを使用して作成されたアーカイブからコミットIDを抽出します
     .

git-ls-files(1)
     インデックスと作業ツリーのファイルに関する情報を表示する.

git-ls-remote(1)
     リモートリポジトリの参照を一覧表示する.

git-ls-tree(1)
     ツリーオブジェクトの内容を一覧表示します.

git-merge-base(1)
     マージのために可能な限り良い共通の祖先を見つけます.

git-name-rev(1)
     指定のrevのシンボリック名を検索します.

git-pack-redundant(1)
     無駄なパックファイルを探す.

git-rev-list(1)
     コミットオブジェクトを新しい順に一覧表示します.

git-rev-parse(1)
     パラメータを選択してもみもみします。.

git-show-index(1)
     パックされたアーカイブインデックスを表示する.

git-show-ref(1)
     ローカルリポジトリ内の参照を一覧表示します.

git-unpack-file(1)
     ブロブの内容を含む一時(temporary)ファイルを作成します.

git-var(1)
     Git論理変数を表示します.

git-verify-pack(1)
     パックされたGitアーカイブファイルを検証する.

   一般に、問い合わせコマンドは作業ツリー内のファイルには影響しません。

Syncing repositories(リポジトリの同期)
======================================

git-daemon(1)
     Gitリポジトリ用のほんまにシンプルなサーバー.

git-fetch-pack(1)
     別のリポジトリから不足しているオブジェクトを受け取ります.

git-http-backend(1)
     Git over HTTP のサーバー側実装.

git-send-pack(1)
     Gitプロトコルを介してオブジェクトを別のリポジトリにプッシュする.

git-update-server-info(1)
     ダムサーバー(dumb servers)を支援するために補助情報ファイル
     (auxiliary info.

   以下は、上記で使用されるヘルパーコマンドです。エンドユーザーは通常、
これらを直接使用することはありません。

git-http-fetch(1)
     HTTPでリモートGitリポジトリからダウンロード.

git-http-push(1)
     HTTP/DAV を介してオブジェクトを別のリポジトリにプッシュする.

git-receive-pack(1)
     リポジトリにプッシュされたものを受信します.

git-shell(1)
     GitのみのSSHアクセス用の制限付きログインシェル.

git-upload-archive(1)
     アーカイブを git-archive に送り返す.

git-upload-pack(1)
     パックされたオブジェクトをgit-fetch-packに送り返す.

Internal helper commands(内部ヘルパーコマンド)
==============================================

これらは、他のコマンドで使用される内部ヘルパーコマンドです。エンドユーザ
ーは通常、これらを直接使用することはありません。

git-check-attr(1)
     gitattributes情報を表示.

git-check-ignore(1)
     gitignoreや除外ファイルのデバッグ.

git-check-mailmap(1)
     連絡先(contacts)の、正式な名前と電子メールアドレスを表示.

git-check-ref-format(1)
     参照名が整形式であることを確認します.

git-column(1)
     データを複数列表示する.

git-credential(1)
     ユーザー資格情報の取得と保存.

git-credential-cache(1)
     パスワードを一時的にメモリに保存するヘルパー.

git-credential-store(1)
     資格情報をディスクに保存するヘルパー.

git-fmt-merge-msg(1)
     git-fmt-merge-msg-マージコミットメッセージを生成します.

git-interpret-trailers(1)
     コミットメッセージの構造化情報を追加またはパースします.

git-mailinfo(1)
     単一の電子メールメッセージからパッチと作成者を抽出します.

git-mailsplit(1)
     簡易 UNIX mbox 分割プログラム.

git-merge-one-file(1)
     git-merge-indexで使用する標準のヘルパープログラム.

git-patch-id(1)
     パッチの一意のIDを計算します.

git-sh-i18n(1)
     シェルスクリプトのためのGit用i18nセットアップコード.

git-sh-setup(1)
     一般的なGitシェルスクリプトのセットアップコード.

git-stripspace(1)
     不要な空白(whitespace)を削除します.

Guides(ガイド)
**************

以下のドキュメントページ群は、Gitの概念に関するガイドです。

gitattributes(5)
     パスごとの属性の定義.

gitcli(7)
     Gitコマンドラインのインターフェイスと規則.

gitcore-tutorial(7)
     開発者のためのGit coreチュートリアル.

gitcredentials(7)
     Gitにユーザー名とパスワードを提供する.

gitcvs-migration(7)
     CVSユーザー向けGit.

gitdiffcore(7)
     diff出力の微調整.

giteveryday(7)
     Git日常利用に役立つ最小限のコマンドセット.

gitfaq(7)
     Gitの使用に関するよくある質問(FAQ).

gitglossary(7)
     Git用語集.

githooks(5)
     Gitで使われるフック.

gitignore(5)
     無視する、意図的に追跡しないファイルを指定します.

gitmailmap(5)
     作者(author)/コミッター(committer) および/または 電子メールアドレス
     (E-Mail.

gitmodules(5)
     サブモジュールプロパティの定義.

gitnamespaces(7)
     Git名前空間.

gitremote-helpers(7)
     リモートリポジトリと対話するためのヘルパープログラム群.

gitrepository-layout(5)
     Gitリポジトリの間取り.

gitrevisions(7)
     Gitのリビジョンと範囲を指定する.

gitsubmodules(7)
     あるリポジトリを別のリポジトリ内にマウントする.

gittutorial(7)
     Git入門.

gittutorial-2(7)
     Git入門パート2.

gitworkflows(7)
     Gitで推奨の作業手順の概要.

Configuration Mechanism(構成メカニズム)
***************************************

Gitは、単純なテキスト形式を使用して、リポジトリごとおよびユーザーごとの
カスタマイズを保存します。 このような構成ファイルは以下のようになります:

     #
     # A '#' or ';' character indicates a comment.
     #

     ; core variables
     [core]
             ; Don't trust file modes
             filemode = false

     ; user identity
     [user]
             name = "Junio C Hamano"
             email = "gitster@pobox.com"

   さまざまなコマンドが構成ファイルから読み取られ、それに応じて操作が調
整されます。構成メカニズムのリストと詳細については、 git-config(1) を参
照してください。

Identifier Terminology(識別子の用語)
************************************

<object>
     任意のタイプのオブジェクトのオブジェクト名を現します。

<blob>
     BLOBオブジェクト名を現します。

<tree>
     ツリーオブジェクト名を示します。

<commit>
     コミットオブジェクト名を示します。

<tree-ish>
     ツリーまたはコミットまたはタグオブジェクト名を示します。 <tree-ish>
     引数を取るコマンドは、最終的には <tree> オブジェクトを操作したいの
     で、 <tree> を指す <commit> オブジェクトと <tag> オブジェクトは自動
     的に逆参照(dereference)されます。(訳注: tree-ish;ツリーっぽいナニか
     の意)

<commit-ish>
     コミットまたはタグオブジェクト名を示します。 <commit-ish> 引数を取
     るコマンドは、最終的には <commit> オブジェクトを操作したいので、
     <commit> を指す <tag>オブジェクトを自動的に逆参照します。

<type>
     オブジェクトタイプが必要であることを示します。 現在、 ‘blob’ または
     ‘tree’ または ‘commit’ または ‘tag’ のいずれかです。

<file>
     ファイル名を示します。ほとんどの場合、 ‘GIT_INDEX_FILE’ が記述する
     ツリー構造のルートを基準にしています。

Symbolic Identifiers
********************

<object> を受け入れるGitコマンドでは、以下の記号表記も使用できます:

HEAD
     現在のブランチのヘッドを現します。

<tag>
     有効なタグ名(つまり ‘refs/tags/<tag>’ ref)。

<head>
     有効なhead名(つまり ‘refs/heads/<head>’ ref)。

   オブジェクト名のスペルのより完全なリストについては、 gitrevisions(7)
の「SPECIFYING REVISIONS」セクションを参照してください。

File/Directory Structure
************************

gitrepository-layout(5) 文書を参照してください。

   各フックの詳細については githooks(5) をご覧下さい。

   高レベルのSCMは、 ‘$GIT_DIR’ で追加情報を提供および管理する場合があり
ます。

Terminology(用語)
*****************

gitglossary(7) を参照してください。

Environment Variables(環境変数)
*******************************

さまざまなGitコマンドは、以下の環境変数を使用します:

The Git Repository
==================

これらの環境変数は、「すべての」コアGitコマンドに適用されます。 Nb: Gitの
上位にあるSCMSによって 使用/オーバーライド される可能性があることに注意
してください。したがって、外部のフロントエンドを使用する場合は注意が必要
です。

‘GIT_INDEX_FILE’
     この環境変数は、代替インデックスファイルを指定できます。指定しない
     場合、デフォルトの ‘$GIT_DIR/index’ が使用されます。

‘GIT_INDEX_VERSION’
     この環境変数を使用すると、新しいリポジトリのインデックスバージョン
     を指定できます。「既存のインデックスファイルには影響しません」。デ
     フォルトでは、バージョン2または3のインデックスファイルが使用されま
     す。詳細については、 git-update-index(1) を参照してください。

‘GIT_OBJECT_DIRECTORY’
     オブジェクトストレージディレクトリがこの環境変数を介して指定されて
     いる場合、 sha1 ディレクトリがその下に作成されます。それ以外の場合
     は、デフォルトの ‘$GIT_DIR/objects’ ディレクトリが使用されます。

‘GIT_ALTERNATE_OBJECT_DIRECTORIES’
     Gitオブジェクトは不変であるため、古いオブジェクトを共有の読み取り専
     用ディレクトリにアーカイブできます。この変数は、Gitオブジェクトの検
     索に使用できるGitオブジェクトディレクトリの ‘:’ で区切られた
     (Windowsでは ‘;’ で区切られた)リストを指定します。新しいオブジェク
     トはこれらのディレクトリに書き込まれません。

     ‘"’ (二重引用符;\x22)で始まるエントリは、Cスタイルの引用符で囲まれ
     たパスとして解釈され、先頭と末尾の二重引用符が削除され、バックスラ
     ッシュ(‘\' \x5c);のエスケープが尊重されます。たとえば、値
     `"path-with-\"-and-:-in-it":vanilla-path’ には
     ‘path-with-"-and-:-in-it’ と ‘vanilla-path’ の2つのパスがあります。

‘GIT_DIR’
     ‘GIT_DIR’ 環境変数が設定されている場合、リポジトリのベースにデフォ
     ルトの ‘.git’ の代わりに使用するパスを指定します。 ‘--git-dir’ コマ
     ンドラインオプションもこの値を設定します。

‘GIT_WORK_TREE’
     作業ツリーのルートへのパスを設定します。 これは、 ‘--work-tree’ コ
     マンドラインオプションと core.worktree 構成変数でも制御できます。

‘GIT_NAMESPACE’
     Git名前空間(Git namespace)を設定します。詳細については、
     gitnamespaces(7) を参照してください。 ‘--namespace’ コマンドライン
     オプションもこの値を設定します。

‘GIT_CEILING_DIRECTORIES’
     これは、コロン(‘:’)で区切られた絶対パスのリストである必要があります
     。設定されている場合、これは、リポジトリディレクトリを探すときに
     Gitがchdirを実行してはいけないディレクトリのリストです(読み込みの遅
     いネットワークディレクトリを除外する場合に便利です)。コマンドライン
     または環境で設定されている現在の作業ディレクトリまたはGIT_DIRは除外
     されません。通常、Gitはこのリストのエントリを読み取り、現在のディレ
     クトリと比較するために存在する可能性のあるシンボリックリンクを解決
     する必要があります。ただし、このアクセスが遅い場合でも、リストに空
     のエントリを追加して、後続のエントリがシンボリックリンクではなく、
     解決する必要がないことをGitに通知できます。 例:
     ‘GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink’

‘GIT_DISCOVERY_ACROSS_FILESYSTEM’
     ‘.git’ リポジトリディレクトリがないディレクトリで実行すると、Gitは
     それより親のディレクトリでそのようなディレクトリを見つけて作業ツリ
     ーの最上位を見つけようとしますが、デフォルトではファイルシステムの
     境界を越えません。この環境変数をtrueに設定して、ファイルシステムの
     境界で停止しないようにGitに指示できます。 ‘GIT_CEILING_DIRECTORIES’
     と同様に、これは ‘GIT_DIR’ またはコマンドラインで設定された明示的な
     リポジトリディレクトリには影響しません。

‘GIT_COMMON_DIR’
     この変数にパスが設定されている場合、通常は $GIT_DIR にある非ワーク
     ツリーファイルが、代わりにこのパスから取得されます。HEADやインデッ
     クスなどのワークツリー固有のファイルは $GIT_DIR から取得されます。
     詳細については、 gitrepository-layout(5) と git-worktree(1) を参照
     してください。この変数は GIT_INDEX_FILE や GIT_OBJECT_DIRECTORY な
     どの他のパス変数よりも優先順位が低くなります。

‘GIT_DEFAULT_HASH’
     この変数が設定されている場合、新しいリポジトリのデフォルトのハッシ
     ュアルゴリズムはこの値に設定されます。 現在、この値はクローン作成時
     は無視され、代わりに、リモートリポジトリの設定が使用されます。デフ
     ォルトは「sha1」です。この変数は実験的です！(「THIS VARIABLE IS
     EXPERIMENTAL!」) git-init(1) の ‘--object-format’ を参照してくださ
     い。

Git Commits
===========

‘GIT_AUTHOR_NAME’
     コミットまたはタグオブジェクトを作成するとき、またはreflogを書き込
     むときに、作者IDで使用される、人間が読める名前。 ‘user.name’ と
     ‘author.name’ の構成設定を上書きします。

‘GIT_AUTHOR_EMAIL’
     コミットまたはタグオブジェクトを作成するとき、またはreflogを書き込
     むときに作者IDで使用される電子メールアドレス。 ‘user.email’ と
     ‘author.email’ の設定を上書きします。

‘GIT_AUTHOR_DATE’
     commitまたはtagオブジェクトを作成するとき、またはreflogを書き込むと
     きに作者IDに使用される日付。有効な形式については、 git-commit(1) を
     参照してください。

‘GIT_COMMITTER_NAME’
     コミットオブジェクトまたはタグオブジェクトを作成するとき、または
     reflogを書き込むときに、コミッターIDで使用される、人間が読める形式
     の名前。 ‘user.name’ と ‘committer.name’ の設定を上書きします。

‘GIT_COMMITTER_EMAIL’
     コミットまたはタグオブジェクトを作成するとき、またはreflogを書き込
     むときに作者IDで使用される電子メールアドレス。 ‘user.email’ と
     ‘committer.email’ の設定を上書きします。

‘GIT_COMMITTER_DATE’
     コミットオブジェクトまたはタグオブジェクトを作成するとき、または
     reflogを書き込むときにコミッターIDに使用される日付。有効な形式につ
     いては、 git-commit(1) を参照してください。

‘EMAIL’
     他の関連する環境変数または構成設定が設定されていない場合に、作者と
     コミッターのIDで使用される電子メールアドレス。

Git Diffs
=========

‘GIT_DIFF_OPTS’
     有効な設定は、統一された差分(unified diff)が作成されたときに表示さ
     れるコンテキスト行の数を設定するための ‘--unified=??’ または ‘-u??’
     だけです。これは、Git diff コマンドラインで渡される ‘-U’ または
     ‘--unified’ のオプション値よりも優先されます。

‘GIT_EXTERNAL_DIFF’
     環境変数 ‘GIT_EXTERNAL_DIFF’ が設定されている場合、それによって指定
     されたプログラムが呼び出されてdiffが生成され、Gitは組み込みのdiff機
     構を使用しません。 追加または削除または変更されたパスの場合、
     ‘GIT_EXTERNAL_DIFF’ は以下の7つのパラメーターで呼び出されます:

          path old-file old-hex old-mode new-file new-hex new-mode

     これは:

<old|new>-file
     GIT_EXTERNAL_DIFF が <old|new> の内容を読み取るために 使用できるフ
     ァイルです。

<old|new>-hex
     16進40桁のSHA-1ハッシュです。

<old|new>-mode
     8進数で表現されたファイルモードです。

     ファイルパラメータは、ユーザーの作業ファイル(たとえば
     "git-diff-files" の ‘new-file’ )、または ‘/dev/null’ (たとえば、新
     しいファイルが追加されたときの ‘old-file’ )、または一時ファイル(た
     とえば インデックスの ‘old-file’) を指し示す事ができます。
     ‘GIT_EXTERNAL_DIFF’ は、一時ファイルの削除(unlink)を心配する必要は
     ありません。一時ファイルは ‘GIT_EXTERNAL_DIFF’ の指定したプログラム
     の呼び出しが終了すると削除されます。

     パスがマージされていない場合、 ‘GIT_EXTERNAL_DIFF’ は1つのパラメー
     ター <path> で呼び出されます。

     パス ‘GIT_EXTERNAL_DIFF’ が呼び出されるたびに、
     ‘GIT_DIFF_PATH_COUNTER’ と ‘GIT_DIFF_PATH_TOTAL’ の2つの環境変数が
     設定されます。

‘GIT_DIFF_PATH_COUNTER’
     パスごとに1ずつインクリメントされる1で始まるカウンター。

‘GIT_DIFF_PATH_TOTAL’
     パスの総数。

other
=====

‘GIT_MERGE_VERBOSITY’
     再帰的マージ戦略(recursive merge strategy)によって表示される出力の
     量を制御する数値。 merge.verbosity をオーバーライドします。
     git-merge(1) を参照してください

‘GIT_PAGER’
     この環境変数は ‘$PAGER’ をオーバーライドします。 空の文字列または値
     "cat"に設定されている場合、Gitはページャーを起動しません。
     git-config(1) の ‘core.pager’ オプションも参照してください。

‘GIT_PROGRESS_DELAY’
     オプションの進行状況インジケーターを表示する前に遅延する秒数を制御
     する数値。デフォルトは2です。

‘GIT_EDITOR’
     この環境変数は、 ‘$EDITOR’ と ‘$VISUAL’ をオーバーライドします。イ
     ンタラクティブモードでエディタを起動するときに、いくつかのGitコマン
     ドで使用されます。 git-var(1) と git-config(1) の ‘core.editor’ オ
     プションも参照してください。

‘GIT_SEQUENCE_EDITOR’
     この環境変数は、インタラクティブリベース(interactive rebase)の
     todoリストを編集するときに、構成されたGitエディタをオーバーライドし
     ます。 git-rebase(1) と git-config(1) の ‘sequence.editor’ オプショ
     ンも参照してください。

‘GIT_SSH’
‘GIT_SSH_COMMAND’
     これらの環境変数のいずれかが設定されている場合、 _git fetch_ と
     _git push_ は、リモートシステムに接続する必要があるときに、 _ssh_ の
     代わりに指定されたコマンドを使用します。設定されたコマンドに渡され
     るコマンドラインパラメータは、 ssh.variant によって決定されます。詳
     細については、 git-config(1) の ‘ssh.variant’ オプションを参照して
     ください。

     ‘$GIT_SSH_COMMAND’ は ‘$GIT_SSH’ よりも優先され、シェルによって解釈
     されます。これにより、追加の引数を含めることができます。 一方、
     ‘$GIT_SSH’ は、プログラムへのパスである必要があります(追加の引数が
     必要な場合は、ラッパーシェルスクリプトにすることができます)。

     通常、個人の ‘.ssh/config’ ファイルを使用して必要なオプションを設定
     する方が簡単です。詳細については、あなたのお手元のsshのドキュメント
     を参照してください。

‘GIT_SSH_VARIANT’
     この環境変数が設定されている場合、 ‘GIT_SSH’ ・ ‘ GIT_SSH_COMMAND‘
     ・ ‘core.sshCommand’ が OpenSSH・plink・tortoiseplinkのいずれを参照
     しているかにかかわらず、Gitの自動検出をオーバーライドします。この変
     数は、同じ目的を果たす構成設定 ‘ssh.variant’ をオーバーライドします
     。

‘GIT_ASKPASS’
     この環境変数が設定されている場合、パスワードまたはパスフレーズを取
     得する必要があるGitコマンド(HTTPまたはIMAP認証など)は、コマンドライ
     ン引数として適切なプロンプトを使用してこのプログラムを呼び出し、そ
     のプログラムの標準出力からパスワードを読み取ります。 git-config(1)の
     ‘core.askPass’ オプションも参照してください。

‘GIT_TERMINAL_PROMPT’
     この環境変数が ‘0’ に設定されている場合、gitは端末でプロンプトを表
     示しません(たとえば、HTTP認証を要求する場合)。

‘GIT_CONFIG_GLOBAL’
‘GIT_CONFIG_SYSTEM’
     グローバルまたはシステムレベルの構成ファイルからではなく、指定され
     たファイルから構成を取得します。 ‘GIT_CONFIG_SYSTEM’ が設定されてい
     る場合、ビルド時に定義されたシステム構成ファイル(通常は
     ‘/etc/gitconfig’)は読み取られません。同様に、 ‘GIT_CONFIG_GLOBAL’ が
     設定されている場合、 ‘$HOME/.gitconfig’ も
     ‘$XDG_CONFIG_HOME/git/config’ も読み取られません。 ‘/dev/null’ に設
     定すると、それぞれのレベルの構成ファイルの読み取りをスキップできま
     す。

‘GIT_CONFIG_NOSYSTEM’
     システム全体の ‘$(prefix)/etc/gitconfig’ ファイルからの設定の読み取
     りをスキップするかどうか。 この環境変数を ‘$HOME’ や
     ‘$XDG_CONFIG_HOME’ と一緒に使用して、厄介なスクリプトの予測可能な環
     境を作成するか、または、バグのある ‘/etc/gitconfig’ ファイルを使用
     しないように一時的に設定して、十分な権限を持つ誰かが修正するのを待
     つこともできます。

‘GIT_FLUSH’
     この環境変数が ‘1’ に設定されている場合、 _git blame_ (インクリメン
     タルモード)、 _git rev-list_ 、 _git log_ 、 _git check-attr_ 、
     _git check-ignore_ などのコマンドは、 各レコードがフラッシュされた
     後に出力ストリームを強制的にフラッシュします。 この変数が ‘0’ に設
     定されている場合、 これらのコマンドの出力は、完全にバッファリングさ
     れた入出力を使用して実行されます。 この環境変数が設定されていない場
     合、 Gitは、標準出力がファイルにリダイレクトされているように見える
     かどうかに基づいて、 バッファリングするか、またはレコード指向のフラ
     ッシュを選択します。

‘GIT_TRACE’
     一般的なトレースメッセージを有効にします。例えば、エイリアス拡張や
     、組み込みコマンド実行や、外部コマンド実行 においてです。

     この変数が ‘1’ または ‘2’ または ‘true’ に設定されている場合(比較で
     は英大文字小文字は区別されません)、トレースメッセージがstderrに出力
     されます。

     変数が2より大きく10より小さい整数値(訳注:つまり 2 < 変数 < 10)に設
     定されている場合、(厳密には、)Gitはこの値を、開いているファイルデス
     クリプターとして解釈し、トレースメッセージをこのファイルデスクリプ
     ターに書き込もうとします。

     または、変数が絶対パス(’/’文字で始まる)に設定されている場合、Gitは
     これをファイルパスとして解釈し、トレースメッセージをそのファイルに
     追加しようとします。

     変数の設定を解除(unset)するか、空(empty) または ‘0’ または ‘false’
     (英大文字小文字を区別しない)に設定すると、トレースメッセージが無効
     になります。

‘GIT_TRACE_FSMONITOR’
     ファイルシステムモニター拡張機能(filesystem monitor extension)のト
     レースメッセージを有効にします。使用可能なトレース出力オプションに
     ついては、 ‘GIT_TRACE’ を参照してください。

‘GIT_TRACE_PACK_ACCESS’
     任意のパックへのすべてのアクセスに対してトレースメッセージを有効に
     します。アクセスごとに、パックファイル名とパック内のオフセットが記
     録されます。これは、パック関連のパフォーマンスの問題のトラブルシュ
     ーティングに役立つ場合があります。使用可能なトレース出力オプション
     については、 ‘GIT_TRACE’ を参照してください。

‘GIT_TRACE_PACKET’
     特定のプログラムに出入りするすべてのパケットのトレースメッセージを
     有効にします。これは、オブジェクトネゴシエーションまたはその他のプ
     ロトコルの問題のデバッグに役立ちます。 "PACK" で始まるパケットでは
     トレースがオフになります(ただし、以下の ‘GIT_TRACE_PACKFILE’ を参照
     してください)。使用可能なトレース出力オプションについては、
     ‘GIT_TRACE’ を参照してください。

‘GIT_TRACE_PACKFILE’
     特定のプログラムによって送受信されたパックファイルのトレースを有効
     にします。他のトレース出力とは異なり、このトレースは垂れ流しです。
     ヘッダーやバイナリデータの引用はありません。あなたはこれを、ファイ
     ルを端末に表示したり、他のトレース出力と混合したりするのではなく、
     ほぼ確実に、ファイル(たとえば、 ‘GIT_TRACE_PACKFILE=/tmp/my.pack’
     )に転送する必要があります。

     注意: これは現在、クローンとフェッチのクライアント側にのみ実装され
     ていることに注意してください。

‘GIT_TRACE_PERFORMANCE’
     パフォーマンス関連のトレースメッセージを有効にします。例えば、各
     Gitコマンドの合計実行時間です。使用可能なトレース出力オプションにつ
     いては、 ‘GIT_TRACE’ を参照してください。

‘GIT_TRACE_REFS’
     refデータベースでの操作のトレースメッセージを有効にします。使用可能
     なトレース出力オプションについては、 ‘GIT_TRACE’ を参照してください
     。

‘GIT_TRACE_SETUP’
     Gitがセットアップフェーズを完了した後、‘.git’ と作業ツリーと現在の
     作業ディレクトリを出力するトレースメッセージを有効にします。使用可
     能なトレース出力オプションについては、 ‘GIT_TRACE’ を参照してくださ
     い。

‘GIT_TRACE_SHALLOW’
     浅い(shallow)リポジトリの フェッチ/クローン のデバッグに役立つトレ
     ースメッセージを有効にします。使用可能なトレース出力オプションにつ
     いては、 ‘GIT_TRACE’ を参照してください。

‘GIT_TRACE_CURL’
     gitトランスポートプロトコルのすべての着信および発信データ
     (descriptive information;説明情報を含む)のcurlフルトレースダンプを
     有効にします。これは、コマンドラインで curl ‘--trace-ascii’ を実行
     するのと似ています。使用可能なトレース出力オプションについては、
     ‘GIT_TRACE’ を参照してください。

‘GIT_TRACE_CURL_NO_DATA’
     curlトレースが有効になっている場合(上記の ‘GIT_TRACE_CURL’ を参照
     )、データをダンプしないでください(つまり、情報行とヘッダー(info
     lines and headers)のみをダンプします)。

‘GIT_TRACE2’
     「trace2」ライブラリからのより詳細なトレースメッセージを有効にしま
     す。 ‘GIT_TRACE2’ からの出力は、人間が読みやすいように単純なテキス
     トベースの形式です。

     この変数が ‘1’ または ‘2’ または ‘true’ に設定されている場合(比較で
     は英大文字小文字は区別されません)、トレースメッセージがstderrに出力
     されます。

     変数が2より大きく10より小さい整数値(訳注:つまり 2 < 変数 < 10)に設
     定されている場合、(厳密には、)Gitはこの値を、開いているファイルデス
     クリプターとして解釈し、トレースメッセージをこのファイルデスクリプ
     ターに書き込もうとします。

     あるいは、変数が絶対パス(‘/‘文字で始まる)に設定されている場合、
     Gitはこれをファイルパスとして解釈し、トレースメッセージをそのファイ
     ルに追加しようとします。パスがすでに存在し、ディレクトリである場合
     、トレースメッセージは、SIDの最後のコンポーネントと(ファイル名の衝
     突を回避するための)オプションのカウンタに従って名前が付けられた、そ
     のディレクトリ内のファイル(プロセスごとに1つ)に書き込まれます。

     加えて、変数が ‘af_unix:[<socket_type>:]<absolute-pathname>’ に設定
     されている場合、GitはパスをUnixドメインソケットとして開こうとします
     。ソケットタイプは、 ‘stream’ または ‘dgram’ のいずれかです。

     変数の設定を解除(unset)するか、空(empty) または ‘0’ または ‘false’
     (英大文字小文字を区別しない)に設定すると、トレースメッセージが無効
     になります。

     完全な詳細については Trace2 documentation
     (technical/api-trace2.html) を参照してください。

‘GIT_TRACE2_EVENT’
     この設定は、ソフトウェア処理(machine interpretation)に適したJSONベ
     ースの形式で書き込みます。利用可能なトレース出力オプションについて
     は ‘GIT_TRACE2’ を、詳細については Trace2 documentation
     (technical/api-trace2.html) を参照してください。

‘GIT_TRACE2_PERF’
     ‘GIT_TRACE2’ で利用可能なテキストベースのメッセージに加えて、この設
     定はネスト領域(nesting regions)を理解するための列ベース
     (column-based)のフォーマットを書き込みます。利用可能なトレース出力
     オプションについては ‘GIT_TRACE2’ を、完全な詳細については Trace2
     documentation (technical/api-trace2.html) を参照してください。

‘GIT_TRACE_REDACT’
     デフォルトでは、トレースがアクティブ化されると、Gitはクッキーと「
     Authorization:」ヘッダーと「Proxy-Authorization:」ヘッダーの値を編
     集します。この編集を防ぐには、この変数を ‘0’ に設定します。

‘GIT_LITERAL_PATHSPECS’
     この変数を ‘1’ に設定すると、Gitはすべてのパススペックをグロブパタ
     ーンとしてではなく文字通りに処理します。たとえば、
     ‘GIT_LITERAL_PATHSPECS=1 git log -- '*.c'’ を実行すると、グロブ
     ‘*.c’ が一致するパスではなく、パス ‘*.c’ に接触するコミットが検索さ
     れます。リテラルパスをGitにフィードする場合(たとえば、以前に ‘git
     ls-tree’ や ‘--raw’ diff output などによって与えられたパス)にこれが
     必要になる場合があります。

‘GIT_GLOB_PATHSPECS’
     この変数を ‘1’ に設定すると、Gitはすべてのパススペックをグロブパタ
     ーン(別名 グロブマジック(glob magic))として扱います。

‘GIT_NOGLOB_PATHSPECS’
     この変数を ‘1’ に設定すると、Gitはすべてのパススペックをリテラル(別
     名 リテラルマジック(literal magic))として扱います。

‘GIT_ICASE_PATHSPECS’
     この変数を ‘1’ に設定すると、Gitはすべてのパススペックの英大文字小
     文字を区別しないものとして扱います。

‘GIT_REFLOG_ACTION’
     refが更新されると、reflogエントリが作成され、refの新旧の値に加えて
     、refが更新された理由(通常はrefを更新した高レベルコマンドの名前)を
     追跡します。スクリプト化された磁器コマンドは、 ‘git-sh-setup’ の
     set_reflog_actionヘルパー関数を使用して、エンドユーザーがトップレベ
     ルコマンドとして呼び出したときにその名前をこの変数に設定して、
     reflogの本文(body)に記録できます。

‘GIT_REF_PARANOIA’
     ‘1’ に設定されている場合、refのリストを反復処理するときに、壊れた、
     または名前の悪いrefを含めます。通常の破損していないリポジトリでは、
     これは何もしません。ただし、これを有効にすると、refが壊れている場合
     にgitが一部の操作を検出して中止するのに役立つ場合があります。 Gitは
     、 git-prune(1) のような破壊的な操作を実行するときに、この変数を自
     動的に設定します。あなたが、操作がすべてのrefに影響を与えていること
     を確認したい場合(たとえば、バックアップを作成するためにリポジトリの
     クローンを作成しているため)を除いて、あなた自身で設定する必要はあり
     ません。

‘GIT_ALLOW_PROTOCOL’
     コロン(‘:’)で区切られたプロトコルのリストが設定されている場合、
     ‘protocol.allow’ が ‘never’ に設定され、リストされた各プロトコルで
     は、 ‘protocol.<name>.allow’ が ‘always’ に設定されているかのように
     振る舞います(既存の構成をオーバーライドします)。言い換えると、言及
     されていないプロトコルは許可されません(つまり、これはホワイトリスト
     であり、ブラックリストではありません)。詳細については、
     git-config(1) の ‘protocol.allow’ の説明を参照してください。

‘GIT_PROTOCOL_FROM_USER’
     ‘user’ 状態に構成されている fetch/push/clone によって使用されるプロ
     トコルを妨げるには、 ‘0’ に設定します。これは、信頼できないリポジト
     リからの再帰的なサブモジュールの初期化を制限したり、信頼できない可
     能性のあるURLをgitコマンドにフィードするプログラムに役立ちます。詳
     細については、 git-config(1) を参照してください。

‘GIT_PROTOCOL’
     内部使用のみ。ワイヤープロトコルのハンドシェイクで使用されます。オ
     プションで値 _key[=value]_ を持つ、 コロン(_:_)で区切られたリストを
     含んでいます。不明なキーと値は無視する必要があります。

     注意:この変数が一部のトランスポートを通過できるようにサーバーを構成
     する必要がある場合があることに注意してください。ローカルリポジトリ
     (つまり、 ‘file://’ またはファイルシステムパス)にアクセスするとき、
     および ‘git://’ プロトコルを介して自動的に伝播されます。
     git-over-http の場合、ほとんどの構成で自動的に機能するはずですが、
     git-http-backend(1) の説明を参照してください。 git-over-ssh の場合
     、クライアントがこの変数を渡すことができるようにsshサーバーを構成す
     る必要がある場合があります(たとえば、OpenSSHで ‘AcceptEnv
     GIT_PROTOCOL’ を使用することにより)。

     この構成はオプションです。変数が伝播されない場合、クライアントは元
     の "v0" プロトコルにフォールバックします(ただし、パフォーマンスの向
     上や機能の一部を見逃す可能性があります)。この変数は現在、cloneと
     fetchにのみ影響します。pushにはまだ使用されていません(ただし、将来
     的に使用される可能性があります)。

‘GIT_OPTIONAL_LOCKS’
     ‘0’ に設定すると、Gitは、ロックを取得する必要のあるオプションのサブ
     操作を実行せずに、要求された操作を完了します。たとえば、これにより
     、‘git status’ が副作用としてインデックスを更新するのを防ぐことがで
     きます。これは、リポジトリ上の他の操作とのロック競合を引き起こした
     くない、バックグラウンドで実行されているプロセスに役立ちます。デフ
     ォルトは ‘1’ です。

‘GIT_REDIRECT_STDIN’
‘GIT_REDIRECT_STDOUT’
‘GIT_REDIRECT_STDERR’
     Windowsのみ: 標準の入力/出力/エラーハンドルを環境変数で指定されたパ
     スにリダイレクトできるようにします。これは、 ‘CreateProcess()’ を介
     して標準ハンドルを渡す標準的な方法がオプションではないマルチスレッ
     ドアプリケーションで特に役立ちます。これは、ハンドルを継承可能とし
     てマークする必要があるためです(したがって、生成された「すべて」のプ
     ロセスがそれらを継承し、通常のGit操作をブロックする可能性があります
     )。主な使用目的は、通信に名前付きパイプを使用することです(例:
     ‘\\.\pipe\my-git-stdin-123’)。

     2つの特別な値がサポートされています。‘off’ は対応する標準ハンドルを
     閉じるだけです。そして、 ‘GIT_REDIRECT_STDERR’ が ‘2>&1’ の場合、標
     準エラーは標準出力と同じハンドルにリダイレクトされます。

‘GIT_PRINT_SHA1_ELLIPSIS’ (deprecated)
     (非推奨): ‘yes’ に設定されている場合、(省略形の)SHA-1値の後に省略記
     号を出力します。これは、切り離されたHEAD(detached HEAD)の表示
     (git-checkout(1))と生のdiff出力(git-diff(1))に影響します。上記の場
     合に省略記号を印刷することはもはや適切であるとは見なされておらず、
     そのサポートは(この変数と一緒に)近い将来削除される可能性があります
     。

Discussion
**********

以下の詳細については、 Git concepts chapter of the user-manual
(user-manual.html#git-concepts) および gitcore-tutorial(7) から入手でき
ます。

   Gitプロジェクトは通常、最上位に ‘.git’ サブディレクトリがある作業ディ
レクトリで構成されます。 ‘.git’ ディレクトリには、プロジェクトの完全な履
歴を表す圧縮オブジェクトデータベース、その履歴を作業ツリーの現在のコンテ
ンツにリンクする「インデックス」ファイル、タグやブランチヘッドなど、その
履歴への名前付きポインタが含まれています。

   オブジェクトデータベースには、主に3つのタイプのオブジェクトが含まれて
います。ファイルデータを保持するブロブ(blob)。ディレクトリ階層を構築する
ためのブロブやその他のツリーを指すツリー(tree)。そしてコミット(commit)は
、それぞれが単一のツリーといくつかの親コミットを参照します。

   コミットは、他のシステムが「チェンジセット」または「バージョン」と呼
ぶものと同等であり、プロジェクトの履歴のステップを表し、各親は直前のステ
ップを表します。複数の親とのコミットは、それぞれ独立していた開発ラインの
統合(マージ;merge)を表します。

   すべてのオブジェクトは、その内容のSHA-1ハッシュによって名前が付けられ
、通常は40桁の16進数の文字列として記述されます。このような名前はグローバ
ルに一意です。コミットに至るまでの履歴全体は、そのコミットだけに署名する
ことで保証できます。この目的のために、4番目のオブジェクトタイプであるタ
グ(tag)が提供されます。

   最初に作成されたとき、オブジェクトは個々のファイルに保存されますが、
効率を上げるために、後で「パックファイル」にまとめて圧縮される場合があり
ます。

   ref(refs)と呼ばれる名前付きポインターは、履歴の中で興味深い点を指し示
しています。refには、オブジェクトのSHA-1名または別のrefの名前を含めるこ
とができます。名前が ‘ref/head/’ で始まるrefには、開発中のブランチの最新
のコミット(または「head」)のSHA-1名が含まれます。対象のタグのSHA-1名は、
‘ref/tags/’ の下に保存されます。 ‘HEAD’ という名前の特別な参照には、現在
チェックアウトされているブランチの名前が含まれています。

   インデックスファイルは、すべてのパスのリストと、パスごとのブロブオブ
ジェクトと属性のセットで初期化されます。ブロブオブジェクトは、現在のブラ
ンチの先端にあるファイルの内容を表します。属性(最終変更時刻、サイズなど
)は、作業ツリー内の対応するファイルから取得されます。作業ツリーへのその
後の変更は、これらの属性を比較することで見つけることができます。インデッ
クスは新しいコンテンツで更新される可能性があり、新しいコミットはインデッ
クスに保存されているコンテンツから作成される可能性があります。

   インデックスは、特定のパス名の複数のエントリ(「ステージ」と呼ばれる
)を格納することもできます。これらのステージは、マージの進行中に、マージ
されていないさまざまなバージョンのファイルを保持するために使用されます。

FURTHER DOCUMENTATION
*********************

Gitの使用を開始するには、「description」セクションのリファレンスを参照し
てください。 以下は、初めてのユーザーにとっては、おそらく必要以上に詳細
です。

   Git concepts chapter of the user-manual
(user-manual.html#git-concepts) と gitcore-tutorial(7) はどちらも、基盤
となるGitアーキテクチャの概要を示しています。

   おすすめの作業手順の概要については gitworkflows(7) を参照してください
。

   いくつかの便利な実例について howto (howto-index.html) 文書もご覧下さ
い。

   Git内部については Git API documentation (technical/api-index.html) に
記載されています。

   CVSから移行するユーザーには gitcvs-migration(7) も読んで欲しいです。

Authors
*******

GitはLinus Torvalds(リーナス トーバルズ)によって開始され、現在はJunio C
Hamano(濱野 純)によって保守されています。Gitメーリングリスト
<git@vger.kernel.org (mailto:git@vger.kernel.org)> から多くの貢献があり
ました。 http://www.openhub.net/p/git/contributors/summary
(http://www.openhub.net/p/git/contributors/summary) は、貢献者のより完全
なリストを提供します。

   あなたが git.git 自体のクローンを持っている場合、 git-shortlog(1) と
git-blame(1) の出力は、プロジェクトの特定の部分の作者を表示することがで
きます。

Reporting Bugs
**************

開発とメンテナンスが主に行われるGitメーリングリスト <git@vger.kernel.org
(mailto:git@vger.kernel.org)> にバグを報告してください。そこにメッセージ
を送信するためにリストに登録する必要はありません。以前のバグレポートやそ
の他の議論については、 https://lore.kernel.org/git
(https://lore.kernel.org/git) メーリングリストアーカイブを参照してくださ
い。

   セキュリティに関連する問題は、Gitセキュリティメーリングリスト
<git-security@googlegroups.com (mailto:git-security@googlegroups.com)> に
非公開で投稿する必要があります。

SEE ALSO
********

gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7),
gitglossary(7), gitcore-tutorial(7), gitcli(7), The Git User’s Manual
(user-manual.html), gitworkflows(7)

GIT
***

Part of the git(1) suite

Name
****

gitattributes — パスごとの属性の定義

Synopsis
********

$GIT_DIR/info/attributes, .gitattributes

DESCRIPTION
***********

‘gitattributes’ ファイルは、パス名に属性(attributes)を与える単純なテキス
トファイルです。

   ‘gitattributes’ ファイルの各行は以下の形式です:

     pattern attr1 attr2 ...

   つまり、パターンの後に空白(whitespaces)で区切られた属性リストが続きま
す。先頭と末尾の空白は無視されます。 _#_ で始まる行は無視されます。 二重
引用符(‘"’)で始まるパターンは、Cスタイルでクォートされます。パターンが問
題のパスと一致すると、その行にリストされている属性がそのパスに与えられま
す。

   各属性は、特定のパスに対して以下のいずれかの状態になる可能性がありま
す:

set(設定)
     パスには、特別な値 ‘true’ を持つ属性があります。これは、属性リスト
     にその属性の名前のみをリストすることによって指定されます。

unset(設定解除)
     パスには、特別な値 ‘false’ を持つ属性があります。 これは、属性リス
     トにダッシュ ‘-’ で始まる属性の名前をリストすることによって指定され
     ます。

Set to a value(値を設定)
     パスには、指定の文字列値を持つ属性があります。これは、属性の名前の
     後に等号 ‘=’ とその値を、属性リストにリストすることによって指定され
     ます。

unspecified(未指定)
     パスに一致するパターンはなく、パスに属性があるかどうかはわかりませ
     ん。パスの属性は未指定(unspecified)であると言われます。

   複数のパターンがパスに一致する場合、後の行が前の行をオーバーライドし
ます。このオーバーライドは属性ごとに行われます。

   パターンがパスと一致するルールは、以下のいくつかの例外を除いて、
‘.gitignore’ ファイル(gitignore(5) 参照)と同じです:

   • 否定パターンは使えません

   • ディレクトリに一致するパターンは、そのディレクトリ内のパスに再帰的
     に一致しません(したがって、属性ファイルで末尾のスラッシュの ‘path/’
     構文を使用しても意味がありません。代わりに ‘path/**’ を使用してくだ
     さい)

   パスに割り当てる属性を決定するとき、Gitは、(優先順位が最も高い)
‘$GIT_DIR/info/attributes’ ファイルと、問題のパスと同じディレクトリにあ
る ‘.gitattributes’ ファイルと、作業ツリーの最上位までその親ディレクトリ
を参照します(‘.gitattributes’ を含むディレクトリが問題のパスから離れるほ
ど、優先順位は低くなります)。最後に、(優先順位が最も低い)グローバルファ
イルとシステム全体のファイルが考慮されます。

   ‘.gitattributes’ ファイルが作業ツリーにない場合、インデックス内のパス
がフォールバックとして使用されます。チェックアウト処理では、インデックス
の ‘.gitattributes’ が使用され、作業ツリーのファイルがフォールバックとし
て使用されます。

   単一のリポジトリのみに影響を与えたい(つまり、そのリポジトリの1人のユ
ーザーのワークフローに固有のファイルに属性を割り当てる)場合は、属性を
‘$GIT_DIR/info/attributes’ ファイルに配置する必要があります。バージョン
管理して他のリポジトリに配布する必要がある属性(つまり、すべてのユーザー
が関心を持つ属性)は、 ‘.gitattributes’ ファイルに入れる必要があります
(git-config(1) を参照)。 あるユーザーのすべてのリポジトリに影響を与える
属性は、 ‘core.attributesFile’ 構成オプションで指定されたファイルに配置
する必要があり、そのデフォルト値は $XDG_CONFIG_HOME/git/attributes です
。 $XDG_CONFIG_HOME が設定されていないか空の場合、代わりに
$HOME/.config/git/attributes が使用されます。システム上のすべてのユーザ
ーの属性は、 ‘$(prefix)/etc/gitattributes’ ファイルに配置する必要があり
ます。

   しばしばあなたは、 Unspecified(未指定)状態へのパスの属性の設定をオー
バーライドする必要があります。これは、感嘆符 ‘!’ が前に付いた属性の名前
をリストすることで行えます。

EFFECTS
*******

Gitによる特定の操作は、特定の属性をパスに割り当てることによって影響を受
ける可能性があります。 現在、以下の操作は属性対応(attributes-aware)です
。

Checking-out and checking-in
============================

これらの属性は、 ‘git switch’ や ‘git checkout’ や ‘git merge’ などのコ
マンドが実行されたときに、リポジトリに保存されているコンテンツが作業ツリ
ーファイルにコピーされる方法に影響します。 また、Gitが ‘git add’ や ‘git
commit’ する時に準備したコンテンツをリポジトリの作業ツリーに保存する方法
にも影響します。

text
----

この属性は、行末の正規化を有効にして制御します。テキストファイルが正規化
されると、その行末はリポジトリ内でLFに変換されます。作業ディレクトリ内で
使用される行末スタイルを制御するには、単一のファイルには ‘eol’ 属性を使
用し、すべてのテキストファイルには ‘core.eol’ 構成変数を使用します。
‘core.autocrlf’ を ‘true’ または ‘input’ に設定すると、 ‘core.eol’ がオ
ーバーライドされることに注意してください(git-config(1) のこれらのオプシ
ョンの定義を参照してください)。

set(設定)
     パスに ‘text’ 属性を設定すると、行末の正規化が有効になり、パスがテ
     キストファイルとしてマークされます。行末変換は、コンテンツタイプを
     推測せずに行われます。

unset(設定解除)
     パスの ‘text’ 属性を設定解除(unset)すると、チェックインまたはチェッ
     クアウト時に行末変換を試行しないようにGitに指示します。

Set to string value "auto"
     ‘text’ の値が "auto" に設定されている場合、パスは自動行末変換用にマ
     ークされます。Gitがコンテンツがテキストであると判断した場合、その行
     末はチェックイン時にLFに変換されます。ファイルがCRLFでコミットされ
     ている場合、変換は行われません。

unspecified(未指定)
     ‘text’ 属性が指定されていない場合、Gitは ‘core.autocrlf’ 構成変数を
     使用してファイルを変換する必要があるかどうかを判断します。

   その他の値の場合、Gitは ‘text’ が未指定(unspecified)であるかのように
動作します。

eol
---

この属性は、作業ディレクトリ内で使用される特定の行末スタイルを設定します
。コンテンツチェックなしで行末変換を可能にし、‘text’ 属性を効果的に設定
します。インデックスにあるCRLF行末のパスにこの属性を設定すると、パスがダ
ーティと見なされる可能性があることに注意してください。インデックスにパス
を再度追加すると、インデックスの行末が正規化されます。

文字列値 "crlf" を設定
     この設定により、Gitはチェックイン時にこのファイルの行末を正規化し、
     ファイルがチェックアウトされるときにCRLFに変換します。

文字列値 "lf" を設定
     この設定により、Gitはチェックイン時に行末をLFに正規化し、ファイルが
     チェックアウトされたときにCRLFに変換されないようにします。

crlf 属性との下位互換性
-----------------------

下位互換性のために、 ‘crlf’ 属性は以下のように解釈されます:

     crlf            text
     -crlf           -text
     crlf=input      eol=lf

行末変換
--------

Gitは通常、ファイルの内容をそのままにしますが、リポジトリ内で行末をLFに
正規化し、オプションで、ファイルがチェックアウトされたときにCRLFに変換す
るように構成できます。

   あなたが作業しているリポジトリに関係なく、あなたの作業ディレクトリ内
でCRLF行末を設定したいだけの場合は、属性を使用せずに構成変数
‘core.autocrlf’ を設定できます。

     [core]
             autocrlf = true

   これにより、テキストファイルの正規化は強制されませんが、リポジトリに
導入するテキストファイルの行末は、追加時にLFに正規化され、リポジトリです
でに正規化されているファイルは正規化されたままになります。

   貢献者(contributor)がリポジトリに導入するテキストファイルの行末が正規
化されていることを確認する場合は、「全て」のファイルに対して ‘text’ 属性
を "auto" に設定できます。

     *       text=auto

   属性を使用すると、行末の変換方法をきめ細かく制御できます。以下は、
Gitが ‘.txt’ と、‘.vcproj’ と ‘.sh’ ファイルを正規化し、 ‘.vcproj’ ファ
イルがCRLFを持ち、 ‘.sh’ ファイルが作業ディレクトリでLFを持っていること
を確認し、‘.jpg’ ファイルがその内容に関係なく正規化されないようにする例
です。

     *               text=auto
     *.txt           text
     *.vcproj        text eol=crlf
     *.sh            text eol=lf
     *.jpg           -text

     *Note*

     中央リポジトリへのプッシュとプルを使用してクロスプラットフォームプ
     ロジェクトで ‘text = auto’ 変換が有効になっている場合、CRLFを含むテ
     キストファイルを正規化する必要があります。

   クリーンな作業ディレクトリから始めます:

     $ echo "* text=auto" >.gitattributes
     $ git add --renormalize .
     $ git status        # 正規化されるファイルを表示
     $ git commit -m "Introduce end-of-line normalization"

   正規化してはならないファイルが ‘git status’ に表示される場合は、 ‘git
add -u’ を実行する前に、以下のように ‘text’ 属性の設定を解除してください
。

     manual.pdf      -text

   逆に、Gitが検出しないテキストファイルは、以下のように正規化を手動で有
効にすることができます。

     weirdchars.txt  text

   ‘core.safecrlf’ が "true" または "warn" に設定されている場合、Gitは変
換が ‘core.autocrlf’ の現在の設定に対して可逆的であるかどうかを確認しま
す。 "true" の場合、Gitは不可逆的な変換を拒否します。 "warn" の場合、
Gitは警告を出力するだけで、元に戻せない変換を受け入れます。作業ツリー内
のファイルに対してこのような変換が行われるのを防ぐための安全トリガーがあ
りますが、いくつかの例外がありますが、しかし…

   • _git add_ 自体は作業ツリー内のファイルに影響を与えません。その次に
     行うチェックアウトは影響を与えるため、セーフティーがトリガーされま
     す:

   • パッチでテキストファイルを更新するための ‘git apply’ は作業ツリー内
     のファイルに影響を与えますが、操作はテキストファイルに関するもので
     あり、CRLF変換は行末の不整合の修正に関するものであるため、セーフテ
     ィーはトリガーされません。

   • ‘git diff’ 自体は作業ツリー内のファイルに影響を与えません。多くの場
     合、次に ‘git add’ する予定の変更を検査するために実行されます。潜在
     的な問題を早期に発見するために、セーフティーがトリガーされます。

working-tree-encoding
---------------------

Gitは、ASCIIまたはそのスーパーセットの1つ(UTF-8、ISO-8859-1など)でエンコ
ードされたファイルをテキストファイルとして認識します。他の特定のエンコー
ディング(UTF-16など)でエンコードされたファイルはバイナリとして解釈される
ため、組み込みのGitテキスト処理ツール(‘git diff’ など)や、ほとんどの
GitWebフロントエンドはデフォルトでこれらのファイルのコンテンツを視覚化し
ません 。

   このような場合、 ‘working-tree-encoding’ 属性を使用して作業ディレクト
リ内のファイルのエンコーディングをGitに指示できます。この属性を持つファ
イルがGitに追加されると、Gitは指定されたエンコーディングからUTF-8にコン
テンツを再エンコードします。最後に、GitはUTF-8でエンコードされたコンテン
ツを内部データ構造(「インデックス」と呼ばれます)に格納します。チェックア
ウト時に、コンテンツは指定されたエンコーディングに再エンコードされます。

   注意: ‘working-tree-encoding’ 属性を使用すると、いくつかの落とし穴が
あることに注意してください:

   • (2018年3月現在、)代替のGit実装(JGitやlibgit2など)やGit古いバージョ
     ンは、 ‘working-tree-encoding’ 属性をサポートしていません。リポジト
     リで ‘working-tree-encoding’ 属性を使用する場合は、リポジトリを使用
     するすべてのクライアントがそれをサポートしていることを確認すること
     を強くお勧めします。

     たとえば、Microsoft Visual Studio リソースファイル(‘*.rc’)または
     PowerShellスクリプトファイル(‘*.ps1’)は、UTF-16でエンコードされる場
     合があります。 ‘*.ps1’ をUTF-16のファイルとして宣言し、
     ‘working-tree-encoding’ が有効なGitクライアントで ‘foo.ps1’ を追加
     すると、 ‘foo.ps1’ はUTF-8として内部に保存されます。
     ‘working-tree-encoding’ をサポートしていないクライアントは、
     ‘foo.ps1’ をUTF-8でエンコードされたファイルとしてチェックアウトしま
     す。これは通常、このファイルのユーザーに問題を引き起こします。

     ‘working-tree-encoding’ 属性をサポートしないGitクライアントが新しい
     ファイル ‘bar.ps1’ を追加した場合、 ‘bar.ps1`は内部に「現状のまま」
     (この例ではおそらくUTF-16として)保存されます。そしてそれに対して、
     `working-tree-encoding’ をサポートするクライアントは、内部コンテン
     ツをUTF-8として解釈し、チェックアウト時にUTF-16に変換しようとします
     。その操作は失敗し、エラーが発生します。

   • コンテンツを非UTFエンコーディングに再エンコードすると、変換が
     UTF-8ラウンドトリップセーフではない可能性があるため、エラーが発生す
     る可能性があります。 エンコーディングがラウンドトリップセーフではな
     いと思われる場合は、それを ‘core.checkRoundtripEncoding’ に追加して
     、Gitにラウンドトリップエンコーディングをチェックさせます
     (git-config(1) を参照)。 SHIFT-JIS(日本語文字セット)はUTF-8でラウン
     ドトリップ問題があることが知られており、デフォルトでチェックされて
     います。

   • コンテンツを再エンコードするには、計算機資源が必要なため、特定の
     Git操作(‘git checkout’ や ‘git add’ など)の速度を低下させる可能性が
     あります。

   ‘working-tree-encoding’ 属性は、ファイルをUTF-8エンコーディングで保存
できない場合や、Gitでコンテンツをテキストとして処理できるようにする場合
にのみ使用してください。

   例として、 あなたの _*.ps1_ ファイルがバイトオーダーマーク(BOM)付きで
UTF-16エンコードされており、Gitであなたのプラットフォームに基づいて自動
行末変換を実行する場合、以下の属性を使用します。

     *.ps1           text working-tree-encoding=UTF-16

   あなたの _* .ps1_ ファイルがBOMなしでUTF-16リトルエンディアンでエンコ
ードされており、Gitで作業ディレクトリのWindows行末を使用する場合は、以下
の属性を使用します(BOMを使用したUTF-16リトルエンディアンが必要な場合、
‘UTF-16LE’ の代わりに ‘UTF-16LE-BOM’ を使用します)。あいまいさを避けるた
めに ‘working-tree-encoding’ 属性を使用する場合は、行末を ‘eol’ で明示的
に定義することを強くお勧めします。

     *.ps1           text working-tree-encoding=UTF-16LE eol=CRLF

   あなたは以下のコマンドを使用して、あなたのプラットフォームで使用可能
なすべてのエンコーディングのリストを取得できます:

     iconv --list

   ファイルのエンコーディングがわからない場合、あなたは ‘file’ コマンド
を使用してエンコーディングを推測できます:

     file foo.ps1

ident
-----

パスに属性 ‘ident’ が設定されている場合、Gitはチェックアウト時にブロブオ
ブジェクト内の ‘$Id$’ を ‘$Id:’ に置き換え、その後に40文字の16進ブロブオ
ブジェクト名が続き、その後にドル記号 ‘$’ が続きます。ワークツリーファイ
ルで ‘$Id:’ で始まり、 ‘$’ で終わるバイトシーケンスは、チェックイン時に
‘$Id$’ に置き換えられます。

filter
------

filter‘ 属性には、構成で指定されたフィルタドライバの名前を文字列で指定す
ることができます。

   フィルタドライバは、 ‘clean’ コマンドと ‘smudge’ コマンドで構成されて
おり、どちらも指定しないでおくことができます。チェックアウト時に、
‘smudge’ コマンドが指定されると、コマンドはその標準入力からブロブオブジ
ェクトを供給され、その標準出力はワークツリーファイルを更新するために使用
されます。同様に、 ‘clean’ コマンドはチェックイン時にワークツリーファイ
ルの内容を変換するために使用されます。デフォルトでは、これらのコマンドは
単一のブロブのみを処理して終了します。長時間実行される ‘process’ フィル
ターが ‘clean’ および/または ‘smudge’ フィルターの代わりに使用される場合
、Gitは単一のGitコマンドの存続期間中、単一のフィルターコマンド呼び出しで
すべてのブロブを処理できます。例えば ‘git --all’ を追加します。長時間実
行される ‘process’ フィルターが構成されている場合、構成された単一のブロ
ブフィルターよりも常に優先されます。 ‘process’ フィルターとの通信に使用
されるプロトコルの説明については、以下のセクションを参照してください。

   コンテンツフィルタリングの用途の1つは、プラットフォームやファイルシス
テムやユーザーが使用しやすい形にコンテンツをもみもみ(massage)することで
す。この操作モードでは、ここでのキーワードは「より便利」であり、「使用で
きないものを使用可能にする」ではありません。 つまり、誰かがフィルタード
ライバーの定義を設定解除した場合、または適切なフィルタープログラムを持っ
ていない場合でも、プロジェクトは引き続き使用可能である必要があります。

   コンテンツフィルタリングのもう1つの用途は、リポジトリに直接使用できな
いコンテンツ(Gitの外部に保存されている実際のコンテンツを参照するUUIDや暗
号化されたコンテンツなど)を保存し、チェックアウト時に使用可能な形式に変
換することです(例: 外部コンテンツをダウンロードする、または暗号化された
コンテンツを復号化する)。

   これらの2つのフィルターの振る舞い異なり、デフォルトでは、フィルターは
前者と見なされ、コンテンツをより便利な形にもみもみ(massage)します。構成
にフィルタードライバー定義がないか、ゼロ以外のステータスで終了するフィル
タードライバーはエラーではありませんが、フィルターを無操作パススルーにし
ます。

   filter.<driver>.required 構成変数を ‘true’ に設定することにより、フィ
ルター自体が使用できないコンテンツを使用可能なコンテンツに変換することを
宣言できます。

   注意: clean フィルターを変更するたびに、リポジトリを再正規化する必要
があります: $ git add –renormalize

   たとえば、 ‘.gitattributes’ で、あなたはパスに ‘filter’ 属性を割り当
てるとします。

     *.c     filter=indent

   次に、あなたは以下のように ‘.git/config’ で ‘filter.indent.clean’ と
‘filter.indent.smudge’ 構成を定義して、ソースファイルがチェックインされ
たとき(‘clean’ が実行されます)と、チェックアウトされたとき(コマンドが
‘cat’ であるため、変更は行われません)、にCプログラムの内容を変更するコマ
ンドのペアを指定します。

     [filter "indent"]
             clean = indent
             smudge = cat

   最良の結果を得るには、 ‘clean’ を2回実行しても出力を変更しないでくだ
さい("clean→clean" は "clean" と同等である必要があります)。また、複数の
‘smudge’ コマンドで ‘clean’ の出力を変更しないでください
("smudge→smudge→clean" は "clean” と同等である必要があります)。 以下の
mergingセクションを参照してください。

   "indent" フィルターは、この点で適切に動作します。すでに正しくインデン
トされている入力は変更されません。この場合、smudgeフィルターがないという
ことは、cleanフィルターが自身の出力を変更せずに受け入れる必要があること
を意味します。

   保存されたコンテンツを使用可能にするためにフィルターが成功する必要が
ある場合は、構成でフィルターが ‘required’ (必須)であることを宣言できます
:

     [filter "crypt"]
             clean = openssl enc ...
             smudge = openssl enc -d ...
             required

   フィルタコマンドラインのシーケンス ‘%f’ は、フィルタが機能しているフ
ァイルの名前に置き換えられます。フィルタはこれをキーワード置換で使用する
場合があります。例えば:

     [filter "p4"]
             clean = git-p4-filter --clean %f
             smudge = git-p4-filter --smudge %f

   注意: ‘%f’ は、作業中のパスの名前であることに注意してください。フィル
タリングされているバージョンによっては、ディスク上の対応するファイルが存
在しないか、内容が異なる場合があります。したがって、smudgeおよびcleanコ
マンドは、ディスク上のファイルにアクセスしようとするのではなく、標準入力
で提供されるコンテンツのフィルターとしてのみ機能する必要があります。

Long Running Filter Process
---------------------------

フィルタコマンド(文字列値)が ‘filter.<driver>.process’ を介して定義され
ている場合、Gitは単一のGitコマンドの存続期間中、単一のフィルタ呼び出しで
すべてのブロブを処理できます。 これは、長時間実行プロセスプロトコル(
technical/long-running-process-protocol.txt にて説明)を使用して実現され
ます。

   Gitは、クリーニング(cleaned)またはスマッジング(smudged)が必要な最初の
ファイルを検出すると、フィルターを開始してハンドシェイクを実行します。ハ
ンドシェイクでは、Gitによって送信されるウェルカムメッセージは
"git-filter-client" であり、プロトコルバージョン2("version=2")のみがサポ
ートされ、サポートされる機能は "clean" と "smudge" と ”delay" です。

   その後、Gitはフラッシュパケットで終了する "key=value" ペアのリストを
送信します。リストには、少なくとも(サポートされている機能に基づく)フィル
ターコマンドと、リポジトリルートを基準にしてフィルタリングするファイルの
パス名が含まれます。フラッシュパケットの直後に、Gitはコンテンツを0個以上
のpkt-lineパケットに分割して送信し、フラッシュパケットを送信してコンテン
ツを終了します。フィルタは、コンテンツと最終的なフラッシュパケットを受信
する前に、応答を送信してはならないことに注意してください。 また、
"key=value" ペアの「value」には「=」文字を含めることができますが、キーに
は含めることはできません。

     packet:          git> command=smudge
     packet:          git> pathname=path/testfile.dat
     packet:          git> 0000
     packet:          git> CONTENT
     packet:          git> 0000

   フィルタは、フラッシュパケットで終了する "key=value" ペアのリストで応
答することが期待されます。フィルタで問題が発生しない場合は、リストに
"success" ステータスが含まれている必要があります。これらのパケットの直後
に、フィルターはコンテンツを0個以上のpkt-lineパケットで送信し、最後にフ
ラッシュパケットを送信することが期待されます。最後に、フラッシュパケット
で終了する "key=value" ペアの2番目のリストが必要です。フィルタは、2番目
のリストのステータスを変更したり、空のリストでステータスをそのまま維持し
たりできます。空のリストは、フラッシュパケットで終了する必要があることに
注意してください。

     packet:          git< status=success
     packet:          git< 0000
     packet:          git< SMUDGED_CONTENT
     packet:          git< 0000
     packet:          git< 0000  # empty list, keep "status=success" unchanged!

   結果のコンテンツが空の場合、フィルターは "success" ステータスとフラッ
シュパケットで応答して、空のコンテンツを通知することが期待されます。

     packet:          git< status=success
     packet:          git< 0000
     packet:          git< 0000  # empty content!
     packet:          git< 0000  # empty list, keep "status=success" unchanged!

   フィルタがコンテンツを処理できない、または処理したくない場合は、
"error" ステータスで応答することが期待されます。

     packet:          git< status=error
     packet:          git< 0000

   フィルタの処理中にエラーが発生した場合、コンテンツが(部分的または完全
に)送信された後、ステータス "error" を送信できます。

     packet:          git< status=success
     packet:          git< 0000
     packet:          git< HALF_WRITTEN_ERRONEOUS_CONTENT
     packet:          git< 0000
     packet:          git< status=error
     packet:          git< 0000

   フィルタがGitプロセスの存続期間中、コンテンツと将来のコンテンツを処理
できない、または処理したくない場合は、プロトコルの任意の時点で "abort" ス
テータスで応答することが期待されます。

     packet:          git< status=abort
     packet:          git< 0000

   "error"/"abort" ステータスが設定されている場合、Gitはフィルタープロセ
スを停止も再開もしません。 ただし、Gitは ‘filter.<driver>.required`フラ
グに従って終了コードを設定し、 `filter.<driver>.clean’ /
‘filter.<driver>.smudge’ メカニズムの振る舞いを真似っこします。

   通信中にフィルターが停止した場合、またはプロトコルに準拠していない場
合、Gitはフィルタープロセスを停止し、処理が必要な次のファイルでフィルタ
ーを再開します。 ‘filter.<driver>.required’ フラグの設定によっては、
Gitはそれをエラーとして解釈します。

Delay
-----

フィルタが "delay" 機能をサポートしている場合、Gitはフィルタコマンドとパ
ス名の後にフラグ "can-delay" を送信できます。このフラグは、コンテンツな
しでステータス "delayed" とフラッシュパケットで応答することにより、フィ
ルターが現在のブロブのフィルタリングを遅らせることができることを示します
(たとえば、ネットワーク遅延を補正するため)。

     packet:          git> command=smudge
     packet:          git> pathname=path/testfile.dat
     packet:          git> can-delay=1
     packet:          git> 0000
     packet:          git> CONTENT
     packet:          git> 0000
     packet:          git< status=delayed
     packet:          git< 0000

   フィルタが "delay" 機能をサポートしている場合は、
"list_available_blobs" コマンドをサポートしている必要があります。Gitがこ
のコマンドを送信すると、フィルターは、以前に遅延されて現在使用可能なブロ
ブを表すパス名のリストを返すことが期待されます。リストはフラッシュパケッ
トで終了する必要があり、その後に "success" ステータスが続き、これもフラ
ッシュパケットで終了します。 遅延パスのブロブがまだ利用できない場合、フ
ィルターは少なくとも1つのブロブが利用可能になるまで応答をブロックするこ
とが期待されます。フィルタは、空のリストを送信することで、遅延ブロブがな
くなったことをGitに伝えることができます。フィルタが空のリストで応答する
とすぐに、Gitは質問を停止します。この時点でGitが受信していないすべてのブ
ロブは欠落していると見なされ、エラーが発生します。

     packet:          git> command=list_available_blobs
     packet:          git> 0000
     packet:          git< pathname=path/testfile.dat
     packet:          git< pathname=path/otherfile.dat
     packet:          git< 0000
     packet:          git< status=success
     packet:          git< 0000

   Gitはパス名を受け取った後、対応するブロブを再度要求します。これらのリ
クエストには、パス名と空のコンテンツセクションが含まれています。フィルタ
ーは、上記で説明した通常の方法で汚れたコンテンツ(smudged content)に応答
することが期待されます。

     packet:          git> command=smudge
     packet:          git> pathname=path/testfile.dat
     packet:          git> 0000
     packet:          git> 0000  # empty content!
     packet:          git< status=success
     packet:          git< 0000
     packet:          git< SMUDGED_CONTENT
     packet:          git< 0000
     packet:          git< 0000  # empty list, keep "status=success" unchanged!

Example
-------

長時間実行されるフィルターのデモの実装は、Gitコアリポジトリにある
‘contrib/long-running-filter/example.pl’ にあります。 独自の長時間実行フ
ィルタープロセスを開発する場合は、 ‘GIT_TRACE_PACKET’ 環境変数がデバッグ
に非常に役立ちます(git(1) を参照)。

   既存の ‘filter.<driver>.clean’ や ‘filter.<driver>.smudge’ コマンドを
‘filter.<driver>.process’ で使用できないことに注意してください。前者は後
者とは異なるプロセス間通信プロトコルを使用するからです。

チェックイン/チェックアウト属性間の相互作用
-------------------------------------------

チェックインのコードの流れでは、ワークツリーファイルは最初に(指定され、
対応するドライバーが定義されている場合、) ‘filter’ ドライバーで変換され
、次に結果が(指定されている場合) ‘ident‘で処理され、最後に(指定されて適
用可能な場合) ‘text‘で処理されます。

   チェックアウトのコードの流れでは、ブロブコンテンツは最初に ‘text’ で
変換され、次に ‘ident’ で変換され、 ‘filter’ に送られます。

チェックイン/チェックアウト属性が異なるブランチをマージする
-----------------------------------------------------------

clean/smudge フィルターや text/eol/ident 属性の追加など、そのファイルの
正規リポジトリ形式を変更する属性をファイルに追加した場合、属性が配置され
ていない場所で何かをマージすると、通常、マージの競合が発生します。

   これらの不必要なマージの競合を防ぐために、Gitは、 ‘merge.renormalize’
構成変数を設定することにより、3方向マージを解決するときに、ファイルの3つ
のステージすべての仮想チェックアウトとチェックインを実行するように指示で
きます。これにより、チェックイン変換によって引き起こされた変更によって、
変換されたファイルが変換されていないファイルとマージされるときに、誤った
マージの競合が発生するのを防ぐことができます。

   「smudge→clean」の結果がすでに汚されている(smudged)ファイルでも「
clean」と同じ出力になる限り、この戦略はすべてのフィルター関連の競合を自
動的に解決します。このように機能しないフィルターは、手動で解決する必要が
ある追加のマージ競合を引き起こす可能性があります。

Generating diff text
====================

diff
----

属性 ‘diff’ は、Gitが特定のファイルのdiffを生成する方法に影響を与えます
。パスのテキストパッチを生成するか、パスをバイナリファイルとして扱うかを
Gitに指示できます。 また、ハンクヘッダーの ‘@@ -k,l +n,m @@’ 行に表示さ
れる行に影響を与えたり、外部コマンドを使用して差分を生成するようにGitに
指示したり、差分を生成する前にバイナリファイルをテキスト形式に変換するよ
うにGitに依頼したりすることもできます。

set(設定)
     ‘diff’ 属性が設定されているパスは、NULなどのテキストファイルには通
     常表示されないバイト値が含まれている場合でも、テキストとして扱われ
     ます。

unset(設定解除)
     ‘diff’ 属性が設定されていないパスは、 ‘Binary files differ’ (バイナ
     リファイル差分) (または、バイナリパッチが有効になっている場合、バイ
     ナリパッチ) を生成します。

unspecified(未指定)
     ‘diff’ 属性が指定されていないパスは、最初にその内容が検査され、テキ
     ストのように見え、 core.bigFileThreshold よりも小さい場合は、テキス
     トとして扱われます。さもなければ ‘Binary files differ’ (バイナリフ
     ァイル差分) が生成されます。

String(文字列値)
     指定されたdiffドライバーを使用してdiffが表示されます。以下のセクシ
     ョンで説明するように、各ドライバーは1つ以上のオプションを指定できま
     す。diffドライバー「foo」のオプションは、Git構成ファイルの「
     diff.foo」セクションの構成変数によって定義されます。

外部diffドライバーの定義
------------------------

diffドライバの定義は ‘gitattributes’ ファイルではなく ‘gitconfig’ で行わ
れるため、厳密に言えば、このマニュアルページはそれについて話すのには間違
った場所はありますが…

   外部diffドライバー ‘jcdiff’ を定義するには、以下のように
‘$GIT_DIR/config’ ファイル(または ‘$HOME/.gitconfig’ ファイル)にセクショ
ンを追加します:

     [diff "jcdiff"]
             command = j-c-diff

   Git は ‘diff’ 属性が ‘jcdiff’ に設定されているパスの diff を表示する
必要がある場合、上記の設定で指定したコマンド、つまり ‘j-c-diff’ を 7 つ
のパラメータで、 ‘GIT_EXTERNAL_DIFF’ プログラムが呼ばれるのと同じように
呼び出します。 詳しくは git(1) を参照してください。

Defining a custom hunk-header
-----------------------------

テキストdiff出力の変更の各グループ(ハンク(hunk)と呼ばれます)には、以下の
形式の行が接頭辞として付けられます:

     @@ -k,l +n,m @@ TEXT

   これはハンクヘッダー(hunk header)と呼ばれます。 "TEXT" の部分は、デフ
ォルトでは、アルファベットまたは、アンダースコア(‘_’)または、ドル記号
(‘$’)で始まる行です。 これは、GNU _diff -p_ 出力が使用するものとマッチし
ます。ただし、このデフォルトの選択は一部のコンテンツには適していないため
、カスタマイズされたパターンを使用して選択を行うことができます。

   最初に、 .gitattributesで、パスに ‘diff’ 属性を割り当てます。

     *.tex   diff=tex

   次に、 ‘diff.tex.xfuncname’ 構成を定義して、ハンクヘッダー "TEXT" と
して表示する行にマッチする正規表現を指定します。以下のように、
‘$GIT_DIR/config’ ファイル(または ‘$HOME/.gitconfig’ ファイル)にセクショ
ンを追加します:

     [diff "tex"]
             xfuncname = "^(\\\\(sub)*section\\{.*)$"

   注意: 単一レベルのバックスラッシュは構成ファイルパーサーによって使用
されるため、バックスラッシュを2重にする必要があります。 上記のパターンは
、バックスラッシュで始まり、行の終わりまで、 ‘sub’ 、 ‘section’ 、 ‘{’ の
順に0回以上出現する行を選択します。

   これを簡単にするための組み込みパターンがいくつかあり、 ‘tex’ はその
1つであるため、構成ファイルに上記を書き込む必要はありません(これは、
‘.gitattributes’ を介して属性メカニズムで有効にする必要があります)。以下
の組み込みパターンを使用できます:

   • ‘ada’ はAda言語のソースコードに適しています。

   • ‘bash’ はBourne-Againシェル言語(bash)のソースコードに適しています。
     POSIXシェル関数定義のスーパーセットをカバーしています。

   • ‘bibtex’ はBibTeXでコード化されたリファレンスを持つファイルに適して
     います。

   • ‘cpp’ はC言語とC++言語のソースコードに適しています。

   • ‘csharp’ はC#言語のソースコードに適しています。

   • ‘css’ はCSS(cascading style sheets)に適しています。

   • ‘dts’ は devicetree (DTS) ファイルに適しています。

   • ‘elixir’ はElixir言語のソースコードに適しています。

   • ‘fortran’ はFORTRAN言語のソースコードに適しています。

   • ‘fountain’ はFountain文書に適しています。

   • ‘golang’ はGo言語のソースコードに適しています。

   • ‘html’ は HTML/XHTML 文書に適しています。

   • ‘java’ はJava言語のソースコードに適しています。

   • ‘markdown’ はMarkdown文書に適しています。

   • ‘matlab’ はMATLABとOctave言語のソースコードに適しています。

   • ‘objc’ はObjective-C言語のソースコードに適しています。

   • ‘pascal’ は Pascal/Delphi 言語のソースコードに適しています。

   • ‘perl’ はPerl言語のソースコードに適しています。

   • ‘php’ はPHP言語のソースコードに適しています。

   • ‘python’ はPython言語のソースコードに適しています。

   • ‘ruby’ はRuby言語のソースコードに適しています。

   • ‘rust’ はRust言語のソースコードに適しています。

   • ‘scheme’ はScheme言語のソースコードに適しています。

   • ‘tex’ はLaTeX文書のソースコードに適しています。

Customizing word diff
---------------------

‘diff.*.wordRegex’ 構成変数で適切な正規表現を指定することにより、 ‘git
diff --word-diff’ が単語を1行に分割するために使用するルールをカスタマイ
ズできます。たとえば、TeXでは、バックスラッシュとそれに続く一連の文字が
コマンドを形成しますが、そのようなコマンドのいくつかは、空白を介さずに一
緒に実行できます。それらを分離するには、以下のように ‘$GIT_DIR/config’ フ
ァイル(または ‘$HOME/.gitconfig’ ファイル)で正規表現を使用します:

     [diff "tex"]
             wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"

   前のセクションにリストされているすべての言語には組み込みのパターンが
用意されています。

バイナリファイルのテキスト差分の取得
------------------------------------

一部のバイナリファイルのテキスト変換バージョンの差分を確認することが望ま
しい場合があります。たとえば、ワードプロセッサ文書をASCIIテキスト表現に
変換し、テキストの差分を表示することができます。この変換によって一部の情
報が失われますが、結果のdiffは人間が見るのに役立ちます(ただし、直接適用
(apply)することはできません)。

   ‘textconv’ configオプションは、そのような変換を実行するためのプログラ
ムを定義するために使用されます。プログラムは、変換するファイルの名前であ
る単一の引数を取り、結果のテキストをstdoutに生成する必要があります。

   たとえば、バイナリ情報の代わりにファイルのexif情報の差分を表示するに
は(exifツールがインストールされていると仮定して)、以下のセクションを
‘$GIT_DIR/config’ ファイル(または ‘$HOME/.gitconfig ファイル)に追加しま
す:

     [diff "jpg"]
             textconv = exif

     *Note*

     テキスト変換は通常、一方向の変換です。この例では、実際の画像コンテ
     ンツを失い、テキストデータのみに焦点を当てています。これは、
     textconvによって生成されたdiffが適用(apply)に適していないことを意味
     します。このため、テキスト変換を実行するのは、 ‘git diff’ と ‘git
     log’ ファミリーのコマンド(つまり、log、whatchanged、show)のみです。
     ‘git format-patch’ はこの出力を生成しません。バイナリファイルのテキ
     スト変換された差分を誰かに送信したい場合(たとえば、行った変更をすば
     やく伝達するため)、それを別個に生成し、送信する通常のバイナリ差分に
     加えてコメントとして送信する必要があります。

   特に ‘git log -p’ を使用して大量のテキスト変換を行う場合、テキスト変
換が遅くなる可能性があるため、Gitは出力をキャッシュし、将来の差分で使用
するメカニズムを提供します。 キャッシュを有効にするには、diffドライバー
の構成で「cachetextconv」変数を設定します。 例えば:

     [diff "jpg"]
             textconv = exif
             cachetextconv = true

   これにより、各ブロブで「exif」を実行した結果が無期限にキャッシュされ
ます。diffドライバーのtextconv構成変数を変更すると、Gitはキャッシュエン
トリを自動的に無効にし、textconvフィルターを再実行します。キャッシュを手
動で無効にしたい場合(たとえば、「exif」のバージョンが更新され、より良い
出力が生成されようになった等)、 ‘git update-ref -d
refs/notes/textconv/jpg’ を使用してキャッシュを手動で削除できます( ここ
で、「jpg」は上記の例のように、diffドライバーの名前です)。

textconvと外部diffの選択
------------------------

あなたがリポジトリ内のバイナリまたは特別にフォーマットされたブロブの違い
を表示したい場合は、外部のdiffコマンドを使用するか、textconvを使用してそ
れらを差分可能(diff-able)なテキストフォーマットに変換するかを選択できま
す。どちらの方法を選択するかは、状況に完全に依存します。

   外部diffコマンドを使用する利点は、柔軟性です。行指向の変更を見つける
必要はありません。また、出力が統一されたdiff(unified diff)に似ている必要
もありません。あなたはあなたのデータ形式に最も適した方法で変更を自由に見
つけて報告できます。

   それと比較すると、textconvははるかに制限的です。データを行指向のテキ
スト形式に変換すると、Gitは通常のdiffツールを使用して出力を生成します。
この方法を選択することにはいくつかの利点があります:

  1. 容易に使えます。多くの場合、独自の差分を実行するよりも、バイナリか
     らテキストへの変換を作成する方がはるかに簡単です。多くの場合、既存
     のプログラム(つまり exif や odt2txt)をtextconvフィルターとして使用
     できます。

  2. Gitのdiff機能。変換ステップのみを自分で実行することで、カラー化、単
     語diff、マージ用の複合diffなど、Gitのdiff機能の多くを引き続き利用で
     きます。

  3. キャッシュ機能。 textconvキャッシングは、 ‘git log -p’ を実行してト
     リガーするような、繰り返されるdiffを高速化できます。

ファイルをバイナリとしてマークする
----------------------------------

Gitは通常、コンテンツの先頭を調べることで、ブロブにテキストデータとバイ
ナリデータのどちらが含まれているかを正しく推測します。ただし、ブロブにフ
ァイルの後半にバイナリデータが含まれている、またはコンテンツが技術的には
テキスト文字で構成されているものの、人間の読者には不明瞭であるために、あ
なたは、その推測を上書きしたい場合があります。たとえば、多くのポストスク
リプトファイルにはASCII文字しか含まれていません(つまりテキストデータです
)が、ノイズが多く意味のないdiffが生成されます。

   ファイルをバイナリとしてマークする最も簡単な方法は、 ‘.gitattributes’
ファイルでdiff属性を設定解除(unset)することです。

     *.ps -diff

   これにより、Gitは通常の差分ではなく ‘Binary files differ’ (バイナリフ
ァイルの差分)(またはバイナリパッチが有効になっている場合はバイナリパッチ
)を生成します。

   しかしながら、他のdiffドライバー属性を指定することもできます。 たとえ
ば、 ‘textconv’ を使用してポストスクリプトファイルをASCII表現に変換し、
人間が表示できるようにしたい場合があるけども、それ以外の場合はバイナリフ
ァイルとして扱いたいとします。 ‘-diff’ 属性 と ‘diff=ps’ 属性の両方を指
定することはできません。 解決策は、 ‘diff.*.binary’ 構成オプションを使用
することです:

     [diff "ps"]
       textconv = ps2ascii
       binary = true

Performing a three-way merge
============================

merge
-----

属性 ‘merge’ は、 ‘git merge’ 中にファイルレベルのマージが必要な場合にフ
ァイルの3つのバージョンをマージする方法や、 ‘gitr evert’ や ‘git
cherry-pick’ などの他のコマンドに、影響します。

set(設定)
     組み込みの３方向マージドライバーは、 ‘RCS’ スイートの _merge_ コマ
     ンドと同様の方法でコンテンツをマージするために使用されます。これは
     通常のテキストファイルに適しています。

unset(設定解除)
     現在のブランチのバージョンを暫定的なマージ結果として取得し、マージ
     に競合があることを宣言します。これは、明確に定義されたマージセマン
     ティクスを持たないバイナリファイルに適しています。

unspecified(未指定)
     デフォルトでは、これは ‘merge’ 属性が設定されている場合と同じ組み込
     みの３方向マージドライバーを使用します。 ただし、 ‘merge.default’ 構
     成変数は、 ‘merge’ 属性未指定(unspecified)のパスで使用される別のマ
     ージドライバーに名前を付けることができます。

String(文字列値)
     3方向マージは、指定のカスタムマージドライバーを使用して実行されます
     。組み込みの3方向マージドライバーは、「text」ドライバーを要求するこ
     とで明示的に指定できます。 現在のブランチを取得する組み込みドライバ
     ーは、「binary」を要求することで指定できます。

Built-in merge drivers
----------------------

‘merge’ 属性を介して要求できる、いくつかの組み込みの低レベルのマージドラ
イバーが定義されています。

text
     テキストファイルの通常の3方向ファイルレベルのマージ。 競合する領域
     は、競合マーカー ‘<<<<<<<’ と ‘=======’ と ‘>>>>>>>’ でマークされま
     す。ブランチのバージョンは ‘=======’ マーカーの前に表示され、マージ
     されたブランチのバージョンは ‘=======’ マーカーの後に表示されます。

binary
     ブランチのバージョンを作業ツリーに保持しますが、ユーザーが整理でき
     るようにパスを競合状態のままにします。

union
     テキストファイルに対して3方向のファイルレベルのマージを実行しますが
     、競合マーカーを残すのではなく、両方のバージョンから行を取得します
     。これにより、結果のファイルに追加された行がランダムな順序で残る傾
     向があり、ユーザーは結果を確認すべきです。影響を理解していない場合
     は、これを使用してはいけません。

Defining a custom merge driver
------------------------------

マージドライバの定義は、 ‘gitattributes’ ファイルではなく ‘.git/config’
ファイルで行われるため、厳密に言えば、このマニュアルページはそれについて
話すのに間違った場所ではありますが…

   カスタムマージドライバー ‘filfre’ を定義するには、以下のように
‘$GIT_DIR/config’ ファイル(または ‘$HOME/.gitconfig’ ファイル)にセクショ
ンを追加します:

     [merge "filfre"]
             name = feel-free merge driver
             driver = filfre %O %A %B %L %P
             recursive = binary

   ‘merge.*.name’ 変数は、ドライバーに人間が読める名前を付けます。

   ‘merge.*.driver’ 変数の値は、祖先のバージョン(‘%O’)と、現在のバージョ
ン(‘%A’)と、他のブランチのバージョン(‘%B’)をマージするために実行するコマ
ンドを作成するために使用されます。これらの3つのトークンは、コマンドライ
ンの構築時にこれらのバージョンの内容を保持する一時ファイルの名前に置き換
えられます。さらに、 ‘%L’ は競合マーカーのサイズに置き換えられます(以下
を参照)。

   マージドライバーは、マージの結果を ‘%A’ という名前のファイルに上書き
して残し、それらを正常にマージできた場合はゼロステータスで終了し、競合が
あった場合は非ゼロで終了することが期待されます。

   ‘merge.*.recursive’ 変数は、複数の祖先が存在する場合に、共通の祖先間
の内部マージのためにマージドライバーが呼び出されるときに使用する他のマー
ジドライバーを指定します。指定しない場合、ドライバー自体が内部マージと最
終マージの両方に使用されます。

   マージドライバーは、プレースホルダー ‘%P’ を介して、マージされた結果
が格納されるパス名を知ります。

conflict-marker-size
--------------------

この属性は、競合するマージ中に作業ツリーファイルに残る競合マーカーの長さ
を制御します。値を正の整数に設定するだけで、意味のある効果があります。

   たとえば、 ファイル ‘Documentation/git-merge.txt’ の結果をマージする
と競合するときに、‘.gitattributes’ で(通常の7文字の長さではなく)はるかに
長い競合マーカーを残すようにマージ機構に指示できます。

     Documentation/git-merge.txt     conflict-marker-size=32

Checking whitespace errors
==========================

whitespace
----------

      `core.whitespace` 設定変数を使用すると、プロジェクト内のすべてのパスに対して 'diff' と 'apply'
     が空白エラー(whitespace errors)をどうみなすかを定義します(linkgit:git-config[1]
     を参照)。この属性では、あなたはパスごとに細かく制御できます。

set(設定)
     Gitでチェックできる全てのタイプの潜在的な空白エラーを通知します。タ
     ブ幅は ‘core.whitespace’ 構成変数の値から取得されます。

unset(設定解除)
     何もエラーとして通知しません。

unspecified(未指定)
     ‘core.whitespace’ 構成変数の値を使用して、エラーとして通知する内容
     を決定します。

String(文字列値)
     ‘core.whitespace’ 構成変数と同じ形式で、通知すべき一般的な空白の問
     題のコンマ区切りリストを指定します。

Creating an archive
===================

export-ignore
-------------

属性 ‘export-ignore’ を持つファイルとディレクトリはアーカイブファイルに
追加されません。

export-subst
------------

属性 ‘export-subst’ がファイルに設定されている場合、Gitはこのファイルを
アーカイブに追加するときにいくつかのプレースホルダーを展開します。展開は
、コミットIDの可用性に依存します。たとえば git-archive(1) にコミットやタ
グの代わりにツリーが与えられている場合、置換は行われません。プレースホル
ダーは、 git-log(1) のオプション ‘--pretty=format:’ のプレースホルダーと
同じですが、ファイル内で ‘$Format:PLACEHOLDERS$’ のようにラップする必要
がある点が異なります。 例えば、 文字列 ‘$Format:%H$’ は、コミットハッシ
ュに置き換えられます。ただし、DoS攻撃(denial-of-service attacks)を回避す
るために、アーカイブごとに1つの ‘%(describe)’ プレースホルダーのみが展開
されます。

Packing objects
===============

delta
-----

属性 ‘delta’ がfalseに設定されているパスのブロブに対して、デルタ圧縮は試
行されません。

Viewing files in GUI tools
==========================

encoding
--------

この属性の値は、関連するファイルの内容を表示するためにGUIツール(gitk(1)
や git-gui(1) など)で使用される文字エンコードを指定します。注意: パフォ
ーマンス上の考慮事項により、 gitk(1) は、オプションでファイルごとのエン
コーディングを手動で有効にしない限り、この属性を使用しないことに注意して
ください。

   この属性が設定されていないか、値が無効な場合は、代わりに
‘gui.encoding’ 構成変数の値が使用されます(git-config(1) を参照)。

USING MACRO ATTRIBUTES
**********************

追跡中のバイナリファイルに、行末変換を適用したり、テキストの差分を作成し
たりする必要はありません。あなたは、たとえば以下のように指定する必要があ
ります。

     *.jpg -text -diff

   しかし、多くの属性がある場合、これはめんどくさいです。マクロ属性を使
用すると、あなたは設定時に他の多くの属性を同時に設定または設定解除する属
性を定義できます。システムは、組み込みのマクロ属性 ‘binary’ を認識します
:

     *.jpg binary

   「binary」属性を設定すると、上記のように「text」属性と「diff」属性の
設定も解除されます。マクロ属性は「set」のみであることに注意してください
。ただし、1つを設定すると、他の属性をsetまたはunsetしたり、他の属性を「
Unspecified」状態に戻したりする事があります。

DEFINING MACRO ATTRIBUTES
*************************

カスタムマクロ属性は、最上位のgitattributesファイル
(‘$GIT_DIR/info/attributes’ または、作業ツリーの最上位にある ‘
.gitattributes‘ ファイルまたは、グローバルgitattributesファイルまたは、
システム全体のgitattributesファイル)でのみ定義でき、作業ツリーサブディレ
クトリの ‘.gitattributes’ ファイルでは定義できません。 組み込みのマクロ
属性「binary」は、以下のものと同等です:

     [attr]binary -diff -merge -text

NOTES
*****

作業ツリーの ‘.gitattributes’ ファイルにアクセスするとき、Gitはシンボリ
ックリンクをたどりません。 これにより、ファイルシステムからではなく、イ
ンデックスまたはツリーからファイルにアクセスする場合の動作の一貫性が保た
れます。

EXAMPLES
********

これらの以下の3つの ‘gitattributes’ ファイルがある場合:

     (in $GIT_DIR/info/attributes)

     a*      foo !bar -baz

     (in .gitattributes)
     abc     foo bar baz

     (in t/.gitattributes)
     ab*     merge=filfre
     abc     -foo -bar
     *.c     frotz

   パス ‘t/abc’ に与えられる属性は、以下のように計算されます:

  1. (問題のパスと同じディレクトリにある) ‘t/.gitattributes’ を調べるこ
     とにより、Gitは最初の行が一致することを検出します。 ‘merge’ 属性が
     設定されます。 また、2行目が一致し、属性 ‘foo’ と ‘bar‘が設定解除
     (unseet)されていることもわかります。

  2. 次に (親ディレクトリにある) ‘.gitattributes’ を調べ、最初の行がマッ
     チすることを確認します。しかし、 ‘t/.gitattributes’ ファイルでは、
     このパスに対して ‘merge’ や ‘foo’ や ‘bar’ 属性をどのように与えるべ
     きかを既に決めているので、‘foo’ と ‘bar’ は設定解除(unset)のままに
     しています。属性 ‘baz’ がsetされます。

  3. 最後に、 ‘$GIT_DIR/info/attributes’ を調べます。このファイルは、ツ
     リー内の設定を上書きするために使用されます。最初の行がマッチして
     ‘foo’ がsetされ、 ‘bar’ が指定解除(unset)の状態に戻され、 ‘baz’ が
     設定解除(unset)されます。

   その結果、 ‘t/abc’ への属性の割り当ては以下のようになります:

     foo     set to true
     bar     unspecified
     baz     set to false
     merge   set to string value "filfre"
     frotz   unspecified

SEE ALSO
********

git-check-attr(1).

GIT
***

Part of the git(1) suite

Name
****

gitcli — Gitコマンドラインのインターフェイスと規則

Synopsis
********

gitcli

DESCRIPTION
***********

このマニュアルでは Git CLI 全体で使用される規則について説明します。

   多くのコマンドは、引数としてリビジョン(revisions)(それはほとんどの場
合「コミット」(commits)ですが、文脈とコマンドによっては「ツリーっぽい」
(tree-ish)場合もあります)と、パス(paths)を取ります。ルールは以下のとおり
です:

   • リビジョン達が最初に来て、その次にパス達が来ます。 例えば、 ‘git
     diff v1.0 v2.0 arch/x86 include/asm-x86’ では ‘v1.0’ と ‘v2.0’ はリ
     ビジョン達であり、 ‘arch/x86’ と ‘include/asm-x86’ はパス達です。

   • 引数がリビジョンまたはパスのいずれかと誤解される可能性がある場合は
     、それらの間に ‘--’ を配置することで曖昧さを解消できます。例えば、
     ‘git diff -- HEAD’ は、「作業ツリーにHEADというファイルがあります。
     インデックスにステージングしたバージョンと、そのファイルの作業ツリ
     ーにあるバージョンとの変更を表示してください」であり、「HEADコミッ
     トとワークツリー全体の違いを表示する」ではありません。後者を求める
     には ‘git diff HEAD --’ とします。

   • ‘--’ を明示しなくても、Gitは合理的な推測を行いますが、あいまいな場
     合はエラーが発生し、あなたに明確にするように求めます。例えば、作業
     ツリーにHEADというファイルがある場合、 ‘git diff HEAD’ はあいまいで
     あり、曖昧さを解消するには、 ‘git diff HEAD --’ または ‘git diff --
     HEAD’ のいずれかを指定する必要があります。

   • 一部のコマンドでは、 ‘--’ はリビジョンとパスを明確に区別するために
     使われるため、これら一部のコマンドでオプションとリビジョンを分離す
     るために使用することはできません。これら一部のコマンドではオプショ
     ンとリビジョンを分離するために ‘--end-of-options’ を使用できます(こ
     れら以外のパスのリビジョンを区別しないコマンドでも機能します。その
     場合、 ‘--end-of-options’ は単に ‘--’ のエイリアスです)。

     ランダムなユーザー入力を処理することが期待されるスクリプトを作成す
     るときは、適切な場所に曖昧さ回避の ‘--’ を配置することにより、どの
     引数がどれであるかを明示することをお勧めします。

   • 多くのコマンドではパスにワイルドカードを使用できますが、シェルによ
     ってワイルドカードが取得されないように保護する必要があります。以下
     の2つの意味は異なります:

          $ git restore *.c
          $ git restore \*.c

     前者を使用すると、シェルでfileglobを展開でき、作業ツリー内の C言語
     ソースファイル(dot-C)をインデックス内のバージョンで上書きするように
     要求されます。後者は ‘*.c’ をGitに渡し、作業ツリーにチェックアウト
     するパターンに一致するインデックス内のパスを要求しています。‘git
     add hello.c; rm hello.c’ を実行後、前者では作業ツリーに ‘hello.c’ は
     表示されませんが、後者では表示されます。

   • ファイルシステムの ‘.’ (ピリオド)が現在のディレクトリを参照するのと
     同じように、Gitでリポジトリ名として ‘.’ を使用すること(a
     dot-repository)は相対パスであり、あなたの現在のリポジトリを意味しま
     す。

   Gitのスクリプトを作成するときに従う必要のある「フラグ」(flag)に関する
ルールは以下のとおりです:

   • ダッシュで繋がない形式(non-dashed form)のGitコマンドを使用すること
     をお勧めします。つまり、 ‘git-foo’ よりは ‘git foo’ を使用すべきで
     す。

   • 短いオプションは分割して単語に区切ります( ‘git foo -ab’ よりも ‘git
     foo -a -b’ を優先します。前者は機能しない事があります)。

   • コマンドラインオプションが引数を取る場合は、串刺し形式(stuck’ form)
     を使用します。つまり、短いオプションの場合は ‘git foo -o Arg’ の代
     わりに ‘git foo -oArg’ を記述し、長いオプションの場合は ‘git foo
     --long-opt Arg’ の代わりに ‘git foo --long-opt=Arg’ を記述します。
     オプションのオプション引数をとるオプションは、串刺し形式で記述する
     必要があります。

   • コマンドにリビジョンパラメータを指定するときは、そのパラメータが作
     業ツリー内のファイルの名前と混同されないことを確認してください。例
     えば、 ‘git log -1 HEAD’ とは記述せず、‘git log -1 HEAD --’ と記述
     します。作業ツリーに ‘HEAD’ というファイルがある場合、前者は機能し
     ません。

   • 多くのコマンドでは、長いオプション ‘--option’ を一意であるかぎり短
     いプレフィックスのみに省略できます(たとえば、名前が ‘opt’ で始まる
     オプションが他にない場合は、 ‘--opt’ と入力して ‘--option’ フラグを
     呼び出すことができます)。ただし、スクリプトを作成するときは、省略し
     てはいけません。なぜならGitのより新しいバージョンで、名前が同じプレ
     フィックスを共有する新しいオプションが導入される可能性があるからで
     す。例えば ‘--optimize’ が導入されると、以前は一意であった短いプレ
     フィックス(‘--option’ , ‘--opt’)を一意では無くしてしまいます。

ENHANCED OPTION PARSER
**********************

Git 1.5.4シリーズ以降、多くのGitコマンド(この文書の執筆時点ではすべてで
はありませんが)は、拡張オプションパーサーを備えています。

   以下は、この拡張オプションパーサーによって提供される機能のリストです
。

Magic Options
=============

拡張オプションパーサーがアクティブになっているコマンドはすべて、いくつか
の魔法のコマンドラインオプション(magic command-line options)を理解します
:

‘-h’
     コマンドの、かなり整った使用法を提供します。

          $ git describe -h
          usage: git describe [<options>] <commit-ish>*
             or: git describe [<options>] --dirty

              --contains            find the tag that comes after the commit
              --debug               debug search strategy on stderr
              --all                 use any ref
              --tags                use any tag, even unannotated
              --long                always use long format
              --abbrev[=<n>]        use <n> digits to display SHA-1s

     注意: 一部のサブコマンド(例: ‘git grep’ )は、コマンドラインに ‘-h’
     以外のものがある場合、動作が異なる場合がありますが、コマンドライン
     に何も含まれていない ‘git subcmd -h’ は、一貫して使用法を提供するこ
     とを目的としています。

‘--help-all’
     一部のGitコマンドは、配管コマンドにのみ使用されるオプションまたは非
     推奨のオプションを取り、そのようなオプションはデフォルトの使用法か
     ら隠されています。 このオプションはオプションの完全なリストを提供し
     ます。

否定オプション
==============

長いオプションは、接頭辞 ‘--no-’ を付けることで無効にできます。 たとえば
、 ‘git branch’ にはオプション ‘--track’ があります。これはデフォルトで
_on_ です。 ‘--no-track’ を使用して、その動作をオーバーライドできます。
‘--color’ と ‘--no-color’ についても同じことが言えます。

短いオプションのおまとめ
========================

拡張オプションパーサーをサポートするコマンドを使用すると、短いオプション
をおまとめできます。これは、たとえば、 ‘git rm -rf’ や ‘git clean -fdx’
を使用できることを意味します。

長いオプションの省略
====================

拡張オプションパーサーをサポートするコマンドは、クソ詳しく長いオプション
の一意なプレフィックスを受け入れますが、これは注意して使用してください。
たとえば、 ‘git commit --amen’ は ‘git commit --amend’ と入力したかのよ
うに動作しますが、これは、後のバージョンのGitが同じプレフィックスを共有
する別のオプションを導入するまでのみ当てはまります。例えば ‘git commit
--amenity’ オプションが導入されたら一意で無くなります。

Separating argument from the option
===================================

コマンドラインで、オプションの必須パラメータを単に区切られた単語として記
述することができます。これは、以下のすべての使い方が機能することを意味し
ます:

     $ git foo --long-opt=Arg
     $ git foo --long-opt Arg
     $ git foo -oArg
     $ git foo -o Arg

   ただし、これは必須ではないオプションの値を持つスイッチでは許可されて
いません。その場合は串刺し形式を使用する必要があります:

     $ git describe --abbrev HEAD     # correct
     $ git describe --abbrev=10 HEAD  # correct
     $ git describe --abbrev 10 HEAD  # NOT WHAT YOU MEANT

注意：よく混同されるオプションに関する注記
******************************************

作業ツリーおよび/またはインデックス内のファイルを処理できる多くのコマン
ドは、 ‘--cached’ および/または ‘--index’ オプションを使用できます。イン
デックスは元々キャッシュと呼ばれていたため、これら2つは同義語であると誤
解されることがあります。ちゃいます。これらの2つのオプションは非常に異な
ることを意味します。

   • ‘--cached’ オプションは、通常は作業ツリー内のファイルで機能するコマ
     ンドに、「インデックスのみで」機能するように要求するために使用され
     ます。 たとえば、 ‘git grep’ をコミットせずに使用して、どのコミット
     から文字列を検索するかを指定すると、通常は作業ツリー内のファイルで
     機能しますが、 ‘--cached’ オプションを使用するとインデックス内の文
     字列を検索します。

   • ‘--index’ オプションは、通常は作業ツリー内のファイルで機能するコマ
     ンドに、「インデックスにも」影響を与えるように要求するために使用さ
     れます。たとえば、 ‘git stash apply’ は通常、stashエントリに記録さ
     れた変更を作業ツリーにマージしますが、 ‘--index’ オプションを使用す
     ると、インデックスへの変更もマージします。

   ‘git apply`コマンドは、 `--cached’ または ‘--index’ のいずれかを伴っ
て使用できます(同時に使用することはできません。通常、このコマンドは作業
ツリー内のファイルにのみ影響しますが、 ‘--index’ を使用すると、ファイル
とそのインデックスエントリの両方にパッチが適用され、 ‘--cached’ を使用す
ると、インデックスエントリのみが変更されます。

   詳細については
https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/
(https://lore.kernel.org/git/7v64clg5u9.fsf@assigned-by-dhcp.cox.net/) と
https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/
(https://lore.kernel.org/git/7vy7ej9g38.fsf@gitster.siamese.dyndns.org/)
も参照してください。

   作業ツリー および/または インデックス内のファイルに対しても機能する他
のいくつかのコマンドは、 ‘--staged’ および/または ‘--worktree’ を取るこ
とができます。

   • ‘--staged’ は ‘--cached’ とまったく同じです。これは、作業ツリーでは
     なく、インデックスでのみ機能するようにコマンドに要求するために使用
     されます。

   • ‘--worktree’ は反対に、インデックスではなく、作業ツリーのみで作業す
     るようにコマンドに要求します。

   • 2つのオプションを一緒に指定して、インデックスと作業ツリーの両方で作
     業するようにコマンドに要求することができます。

GIT
***

Part of the git(1) suite

Name
****

gitcore-tutorial — 開発者のためのGit coreチュートリアル

Synopsis
********

git *

DESCRIPTION
***********

このチュートリアルでは、「コア」(core)Gitコマンドを使用してGitリポジトリ
を設定および操作する方法について説明します。

   あなたがGitをリビジョン管理システムとして使用する必要がある場合は、「
A Tutorial Introduction to Git」( linkgit: gittutorial[7] )または the
Git User Manual (user-manual.html) から始めることをお勧めします。

   しかしながら、Gitの内部を理解したい場合は、これら低レベルのツールを理
解しておくと役に立ちます。

   コアGit(core Git)は「配管」(plumbing)と呼ばれることが多く、その上に「
磁器」(porcelain)と呼ばれるより美しいユーザーインターフェイスがあります
。配管コマンドを直接使用することはあまりありませんが、磁器コマンドが使え
ない時に配管コマンドでどうするかを知っておくのは良い事です。

   このドキュメントが最初に作成されたとき、多くの磁器コマンドはシェルス
クリプトでした。説明を簡単にするために、配管がどのように組み合わされて磁
器コマンドを形成するかを示す例としていまだそれらを使用しています。ソース
ツリーには、参照用に contrib/examples/ にこれらのスクリプトの一部が含ま
れています。これらは最早シェルスクリプトとして実装されなくなりましたが、
それでも、配管レイヤーコマンドの機能の説明は引き続き有効です。

     *Note*

     より深い技術的な詳細は、多くの場合 Note 欄になっています。最初の読
     書ではスキップしてかまいません。

Creating a Git repository
*************************

新しいGitリポジトリの作成はこれ以上ないほど簡単です。すべてのGitリポジト
リは空から始まります。必要なのは、作業ツリーとして使用するサブディレクト
リを見つけることだけです。まったく新しいプロジェクトの場合は、それは空の
ものか、あるいは、Gitにインポートする既存の作業ツリーのいずれかです。

   私達の最初の例において、既存のファイルを使用せずに、まったく新しいリ
ポジトリを最初から開始します。これを「git-tutorial」と呼ぶことにします。
起動するには、そのサブディレクトリを作成し、そのサブディレクトリに入って
、 ‘git init’ を使用してGitインフラストラクチャを初期化します:

     $ mkdir git-tutorial
     $ cd git-tutorial
     $ git init

   そうすると、Gitは以下のように答えます

     Initialized empty Git repository in .git/

   これは、奇妙なことを何もしていないこと、そして新しいプロジェクト用に
ローカルの ‘.git’ ディレクトリセットアップを作成したことを示すGit流のや
り方です。これで ‘.git’ ディレクトリができ、_ls_ でそれを調べることがで
きます。新しい空のプロジェクトの場合、特に、以下の3つのエントリが表示さ
れます:

   • ‘ref: refs/heads/master’ という内容の ‘HEAD’ というファイル。これは
     シンボリックリンクに似ており、 ‘HEAD’ ファイルは
     ‘refs/heads/master’ を指します。

     ‘HEAD’ リンクが指すファイルがまだ存在しないという事実について心配す
     る必要はありません。まだあなたは ‘HEAD’ 開発ブランチを開始するコミ
     ットを作成していないからです。

   • プロジェクトのすべてのオブジェクトを含む ‘objects’ というサブディレ
     クトリ。オブジェクトを直接見る理由は何も無いはずですが、これらのオ
     ブジェクトがリポジトリ内のすべての実際の「データ」を含むものである
     ことを知りたい場合があります。

   • オブジェクトへの参照を含む ‘refs’ と呼ばれるサブディレクトリ。

   特に、 ‘refs’ サブディレクトリには、それぞれ ‘heads’ と ‘tags’ という
名前の2つのサブディレクトリが含まれます。それらは、名前が示すとおりに機
能します。つまり、開発のさまざまな「ヘッド」(先頭)(別名「ブランチ」)への
参照と、リポジトリ内の特定のバージョンに名前を付けるために作成した「タグ
」への参照が含まれます。

   注: 特別な ‘master’ ヘッドがデフォルトのブランチであるため、作成され
た ‘.git/HEAD’ ファイルは、まだ存在していなくてもそれを指します。基本的
に、 ‘HEAD’ リンクは常に現在作業しているブランチを指しているはずであり、
いつも ‘master’ ブランチでの作業から始まることを期待します。

   けれども、これは単なる慣例であり、ブランチには任意の名前を付けること
ができ、あなたは「master」ブランチを持つ必要はありません。ただし、多くの
Gitツールは ‘.git/HEAD’ が最初から有効であると想定します。

     *Note*

     「オブジェクト」は、その160ビットのSHA-1ハッシュ、別名「オブジェク
     ト名」によって識別され、オブジェクトへの参照は、常にそのSHA-1名の
     16進表現の40バイトです。 ‘refs’ サブディレクトリ内のファイルには、
     これらの16進参照(通常、末尾に ‘\n’ があります)が含まれていると予想
     されるため、実際にあなたのツリーにデータを入力し始めると、これらの
     ‘refs’ サブディレクトリにはこれらの参照を含む41バイトのファイルが多
     数表示されるはずです。

     *Note*

     上級ユーザーは、このチュートリアルを終了した後、
     gitrepository-layout(5) を確認することをお勧めします。

   これで、あなたの最初のGitリポジトリが作成されました。もちろん、空なの
であまり役に立ちません。なので、データの入力を始めましょう。

Populating a Git repository
***************************

我々はシンプルかつ愚直に行きたいと思います、まずは簡単なファイルをいくつ
か入力して、その感触をつかむことから始めます。

   あなたのGitリポジトリに保持したいランダムファイルを作成することから始
めます。これがどのように機能するかを理解するために、いくつかの悪い例から
始めます:

     $ echo "Hello World" >hello
     $ echo "Silly example" >example

   これで、あなたの作業ツリー(working tree)(別名「作業ディレクトリ」
(working directory))に2つのファイルが作成されましたが、実際にあなたの作
業をチェックインするには、以下の2つの手順を実行する必要があります:

   • _index_ ファイル(別名 _cache_ ）に作業ツリーの状態に関する情報を入
     力します。

   • そのインデックスファイルをオブジェクトとしてコミットします。

   最初のステップは至極簡単です。作業ツリーへの変更についてGitに通知する
場合は、 ‘git update-index’ プログラムを使用します。このプログラムは通常
、更新するファイル名のリストを取得しますが、些細な間違いを避けるために、
‘--add’ フラグを使用して新しいエントリを追加すること(または ‘–remove‘で
エントリを削除すること)を明示的に指定しない限り、インデックスへの新しい
エントリの追加(または既存のものを削除)することを拒否します。

   したがって、作成した2つのファイルをインデックスに追加するには、以下の
ようにします

     $ git update-index --add hello example

   これで、あなたはGitにこれら2つのファイルを追跡するように指示しました
。

   実際、上記を行った後にオブジェクトディレクトリを調べると、Gitがオブジ
ェクトデータベースに2つの新しいオブジェクトを追加していることがわかりま
す。上記の手順を正確に実行した場合は、あなたは以下のように実行できます

     $ ls .git/objects/??/*

   そうすると以下の２つのファイルが見えます:

     .git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
     .git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962

   これは、それぞれ「557db…」および「f24c7…」という名前のオブジェクトに
対応します。

   必要に応じて、 ‘git cat-file’ を使用してこれらのオブジェクトを確認で
きますが、オブジェクトのファイル名ではなく、オブジェクト名を使用する必要
があります:

     $ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238

   ここで、 ‘-t’ は _git cat-file_ に、オブジェクトの「タイプ」が何であ
るかを通知させます。 Gitは、「blob」(ブロブ)オブジェクト(つまり、通常の
ファイル)があることを通知し、あなたは以下のコマンドで内容を表示できます
。

     $ git cat-file blob 557db03

   "Hello World" が出力されます。オブジェクト ‘557db03’ は、ファイル
‘hello’ の内容そのものです。

     *Note*

     そのオブジェクトをファイル ‘hello’ 自体と混同しないでください。オブ
     ジェクトは文字通りファイルの特定の「内容」(contents)であり、後でフ
     ァイル ‘hello’ の内容を変更しても、先ほど見たオブジェクトは変更され
     ません。オブジェクトは不変(immutable)です。

     *Note*

     2番目の例は、ほとんどの場所でオブジェクト名を最初の数桁の16進数にの
     みに省略できることを示しています。

   とにかく、前述したように、通常、オブジェクト自体を実際に確認すること
はありません。40文字の長い16進名を入力することは、通常は行いたくないこと
です。上記の余談は、「git update-index」が魔法のようなことをし、実際にフ
ァイルの内容をGitオブジェクトデータベースに保存したことを現しています。

   インデックスを更新すると、他のことも行います。それは、 ‘.git/index’ フ
ァイルの作成です。これは、現在の作業ツリーを説明するインデックスであり、
とても注意を払う必要があります。 繰り返しになりますが、通常はインデック
スファイル自体について心配することはありませんが、ここまでファイルを実際
にはGitに「チェックイン」しておらず、Gitに「伝えただけ」であることに注意
する必要があります。

   しなしながら、Gitはそれらについて知っているため、最も基本的なGitコマ
ンドのいくつかを使用して、ファイルを操作したり、ファイルのステータスを確
認したりできます。

   特に、この時点ではこの2つのファイルをGitにチェックインしないでくださ
い。私達は、最初に、‘hello’ に別の行を追加することから始めます:

     $ echo "It's a new day for git" >>hello

   これで、Gitに以前の ‘hello’ の状態について伝えたので、 _git
diff-files_ コマンドを使用して、古いインデックスと比較してツリーで何が変
更されたかをGitに尋ねることができます:

     $ git diff-files

   おっと、これはあまり読みやすくないですね。これは _diff_ の独自の内部
バージョンを吐き出すだけですが、その内部バージョンは、「hello」が変更さ
れたこと、および古いオブジェクトの内容が別のものに置き換えられたことに気
付いたことを示しています。

   読みやすくするために、 ‘-p’ フラグを使用して、 _git diff-files_ にパ
ッチとして差分を出力するように指示できます:

     $ git diff-files -p
     diff --git a/hello b/hello
     index 557db03..263414f 100644
     --- a/hello
     +++ b/hello
     @@ -1 +1,2 @@
      Hello World
     +It's a new day for git

   つまり、これは ‘hello’ に別の行を追加することによって引き起された変更
の diff です。

   言い換えると、 _git diff-files_ は、常に、インデックスに記録されてい
るものと、現在作業ツリーにあるものとの違いを示しています。これはとても便
利です。

   ‘git diff-files -p’ の一般的な省略形は、 ‘git diff’ と書くことで、左
記と同一の事を行います。

     $ git diff
     diff --git a/hello b/hello
     index 557db03..263414f 100644
     --- a/hello
     +++ b/hello
     @@ -1 +1,2 @@
      Hello World
     +It's a new day for git

Committing Git state
********************

次に、私達はGitの次の段階に進みます。これは、Gitが知っているファイルをイ
ンデックスより取得し、それらを実際のツリーとしてコミットすることです。こ
れは次の2つのフェーズで行います。「ツリー」オブジェクトの作成し、そして
、ツリーが何であるかについての説明と、私たちがどのようにしてその状態に到
達したかについての情報とともに、その「ツリー」オブジェクトを「コミット」
オブジェクトとしてコミットします。

   ツリーオブジェクトの作成は至極簡単で、 ‘git write-tree’ を使用します
。オプションやその他の入力はありません。 ‘git write-tree’ は現在のインデ
ックスの状態を取得し、そのインデックス全体を記述するオブジェクトを書き込
みます。つまり、現在、すべての異なるファイル名をそれらのコンテンツ(およ
びそれらのアクセス許可)と結び付けており、Gitの「ディレクトリ」オブジェク
トに相当するものを作成します:

     $ git write-tree

   これにより、結果のツリーの名前が出力されます。この場合(私が説明したと
おり正確に実行した場合)、以下のようになっているべきです

     8988da15d077d4829fc51d8544c097def6644dbb

   これは、別のワケワカメなオブジェクト名です。繰り返しになりますが、あ
なたは必要に応じて、 ‘git cat-file -t 8988d...’ を使用して、今回のオブジ
ェクトが「ブロブ」オブジェクトではなく「ツリー」オブジェクトであることを
確認できます( ‘git cat-file’ を使用して、生のオブジェクトの内容を実際に
出力することもできますが、主にごちゃごちゃしたバイナリが見れるだけであま
り面白くありません)。

   しかしながら、通常は ‘git commit-tree’ コマンドを使用してツリーをコミ
ットオブジェクトにコミットするため、通常は ‘git write-tree’ を単独で使用
することはありません。 実際のところ ‘git write-tree’ を単独で使用するの
ではなく、その結果を ‘git commit-tree’ へ引数として渡す方が簡単です。

   _git commit-tree_ は通常、いくつかの引数を取ります。 ‘git
commit-tree’ はコミットの「親」が何であるかを知りたいのですが、これはこ
の新しいリポジトリでの最初のコミットであり、親がないため、ツリーのオブジ
ェクト名を渡すだけで済みます。ただし、 ‘git commit-tree’ は、標準入力か
らコミットメッセージを取得することも必要です。そしてコミットの結果のオブ
ジェクト名を標準出力に書き出します。

   ここで、 ‘HEAD’ が指す ‘.git/refs/heads/master’ ファイルを作成します
。このファイルには、masterブランチのツリーのてっぺん(top-of-tree)への参
照が含まれているはずです。これはまさに「git commit-tree」が吐き出すもの
なので、一連の単純なシェルコマンドでこれをすべて行うことができます:

     $ tree=$(git write-tree)
     $ commit=$(echo 'Initial commit' | git commit-tree $tree)
     $ git update-ref HEAD $commit

   この場合に限り、他の何にも関係のないまったく新しいコミットが作成され
ます。 通常、これはプロジェクトに対して「1回だけ」行います。このコミット
はこの後のすべてのコミットの親になります。

   繰り返しますが、通常、これを実際に手作業で行うことはありません。 これ
らすべてを実行する ‘git commit’ という便利なスクリプトがあります。 した
がって、あなたは代わりに ‘git commit’ と記述すれば、上記の魔法のスクリプ
トが実行されます。

Making a change
***************

以前、ファイル ‘hello’ で ‘git update-index’ を実行し、その後 ‘hello’ を
変更して、 ‘hello’ の新しい状態を、インデックスファイルに保存した状態と
比較したことを覚えていますか？

   さらに、 私が ‘git write-tree’ は「インデックス」ファイルの内容をツリ
ーに書き込むと言ったことを思い出してください。したがって、コミットしたの
は、実際にはファイル ‘hello’ の「元の内容」であり、新しい内容ではありま
せん。これは、インデックスの状態と作業ツリーの状態の違い、および私達が何
かをコミットした場合でもそれらが一致する必要がない事を示すために意図的に
行いました。

   以前と同様に、git-tutorialプロジェクトで ‘git diff-files -p’ を実行し
た場合でも、前回と同一の差異が見られます。つまり、何かをコミットすること
によってインデックスファイルが変更されていないということです。ただし、私
達は何かをコミットしたので、新しいコマンド ‘git diff-index’ の使用方法を
学ぶこともできます:

   インデックスファイルと作業ツリーの違いを示した ‘git diff-files’ とは
異なり、 ‘gitdiff-index’ はコミットされたツリーと、インデックスファイル
または作業ツリーとの違いを示します。言い換えると、 ‘git diff-index’ はツ
リーとの差分することを望んでおり、コミットする前は、そもそも差分するモノ
がなかったため、差分を行うことができませんでした。

   しかし、今や私達は以下のようにできます

     $ git diff-index -p HEAD

   (ここで、‘-p’ は ‘git diff-files’ のと同じ意味です。) 同一の差異が表
示されますが、理由はまったく異なります。これは、作業ツリーを、インデック
スファイルではなく、作成したツリーと比較しています。たまたまこれら2つが
明らかに同じであるため、私達は同じ結果を得たのです。

   繰り返しになりますが、これは一般的な操作であるため、以下のように短縮
することもできます

     $ git diff HEAD

   これで、結局は上記のようなことをやってくれます。

   つまり、 ‘git diff-index｀ は通常、ツリーを作業ツリーと比較しますが、
`--cached’ フラグを指定すると、代わりにインデックスキャッシュの内容と比
較し、現在の作業ツリーの状態を完全に無視するように指示します。我々はイン
デックスファイルをHEADに書き込んだばかりなので、 ‘git diff-index
--cached -p HEAD’ を実行すると、空の差分セットを返すはずで、これは正に指
示したとおりの結果です。

     *Note*

     ‘git diff-index’ は実際には「常に」その比較にインデックスを使用する
     ため、ツリーを作業ツリーと比較すると言ったことは厳密には正確ではあ
     りません。特に、比較するファイルのリスト(「メタデータ」
     (meta-data))は、 ‘--cached’ フラグが使用されているかどうかに関係な
     く、常にインデックスファイルから取得されます。 ‘--cached’ フラグは
     、実際には、比較されるファイルの「内容」が作業ツリーからのものであ
     るか否かを決定するだけです。

     これを理解するのは難しいことでは無く、すぐにあなたは、Gitが明示的に
     通知されていないファイルを知らない(または気にしない)ことに気付きま
     す。Gitは比較するファイルを「探す」ことは決してありません。ファイル
     が何であるかを教えて貰えることを期待しており、それがインデックスの
     目的なのです。

   ただし、私達の次のステップは、私達の行った変更をコミットすることです
。繰り返しますが、何が起こっているのかを理解するために、「作業ツリーの内
容」と「インデックスファイル」と「コミットされたツリー」の違いに注意して
ください。私達がコミットしたい作業ツリーに変更があり、私達は常にインデッ
クスファイルを処理する必要があるため、したがって、私達が最初に行う必要が
あるのは、インデックスキャッシュを更新することです:

     $ git update-index hello

   (注意: Gitはファイルについてすでに知っていたので、私達は今回は
‘--add’ フラグを必要としなかったことに注意してください)。

   注意: ここで、個別の ‘git diff-{asterisk}’ バージョンには何が起こるで
しょうか。我々がインデックス内の ‘hello’ を更新した後、 ‘git diff-files
-p’ は、違いを示さなくなりましたが、 ‘git diff-index -p HEAD’ は、現在の
状態がコミットした状態とは異なることを示しています。 実際、 ‘git
diff-index’ は、 ‘--cached’ フラグを使用するかどうかに関係なく同一の違い
を示します。これは、インデックスは作業ツリーと一貫性があるためです。

   これで、我々はインデックス内の ‘hello’ を更新したので、我々は新しいバ
ージョンをコミットできます。我々はもう一度手動でツリーを作成し、ツリーを
コミットすることでそれを行うことができます(今回は、 ‘-p HEAD’ フラグを使
用して、HEADが新しいコミットの「親」であり、これが最初のコミットではなく
なったことをコミットに通知する必要があります)。しかし、あなたはすでに一
度この手作業を経験済みですので、今回は役立つスクリプトを使用してみましょ
う:

     $ git commit

   これにより、あなたがコミットメッセージを書き込むためのエディタが起動
し、あなたがさっきやった事についてちょっぴり教えてくれます。

   あなたが必要なメッセージを書き込むと、 ‘#’ で始まるすべての行が削除さ
れ、残りはこの変更のコミットメッセージとして使用されます。あなたがこの時
点で結局何もコミットしたくないと判断した場合(あなたは引き続き編集してイ
ンデックスを更新できます)、あなたは空のメッセージを残すことができます。
それ以外の場合、 ‘git commit’ は変更をコミットします。

   これで、最初の実際のGitコミットが完了しました。 ‘git commit’ が実際に
何をするのかを知りたい場合は、お気軽に調査してください。役立つ(？)コミッ
トメッセージヘッダーを生成するための非常に単純なシェルスクリプトがいくつ
かあり、そして実際にコミット自体を行ういくつかのワンライナーがあります
(‘git commit’)。

Inspecting Changes
******************

変更を作成することは便利ですが、後で何が変更されたかを知ることができれば
さらに便利です。このための最も便利なコマンドは、diffファミリーのもう1つ
、つまり ‘git diff-tree’ です。

   ‘git diff-tree’ には任意の2つのツリーを指定でき、それらの間の違いがわ
かります。けれども、おそらくもっと一般的には、あなたはコミットオブジェク
トを1つだけ与えることができ、そうすると、そのコミット自体の親を把握し、
違いを直接表示します。したがって、すでに数回見たのと同一のdiffを取得する
ために、以下のようにすることができます

     $ git diff-tree -p HEAD

   (繰り返しになりますが、 ‘-p’ は人間が読めるパッチとして違いを表示する
ことを意味します)、(‘HEAD’ が指す)最後のコミットが実際に何を変更したかを
表示します。

     *Note*

     以下は、さまざまな ‘diff-{asterisk}’ コマンドが物事を比較する方法を
     表す、Jon Loeliger によるアスキーアートです。

                      diff-tree
                       +----+
                       |    |
                       |    |
                       V    V
                    +-----------+
                    | Object DB |
                    |  Backing  |
                    |   Store   |
                    +-----------+
                      ^    ^
                      |    |
                      |    |  diff-index --cached
                      |    |
          diff-index  |    V
                      |  +-----------+
                      |  |   Index   |
                      |  |  "cache"  |
                      |  +-----------+
                      |    ^
                      |    |
                      |    |  diff-files
                      |    |
                      V    V
                    +-----------+
                    |  Working  |
                    | Directory |
                    +-----------+

   さらに興味深いことに、 ‘git diff-tree’ に ‘--pretty’ フラグを指定する
こともできます。これにより、コミットメッセージと作者とコミットの日付も表
示され、一連のdiff全体を表示するように指示します。または、「黙って」
(silent)と指示して、差分をまったく表示せずに実際のコミットメッセージを表
示することもできます。

   実際には、 (リビジョンのリストを生成する) ‘git rev-list’ プログラムと
一緒に使うことで、 ‘git diff-tree’ は、正に変更の源泉と化します。 ‘git
rev-list’ の出力を ‘git diff-tree --stdin’ にパイプする簡単なスクリプト
を使用して、 ‘git log’ や ‘git log -p’ などをエミュレートできます。これ
は正に初期バージョンの ‘git log’ が実装された方法でした。

Tagging a version
*****************

Gitには、「軽い」(light)タグと「注釈付きタグ」(annotated tag)の2種類のタ
グがあります。

   「軽い」タグは、 ヘッドと呼ぶ代わりに ‘.git/refs/tags/’ サブディレク
トリに配置することを除いて、技術的にはブランチ以上のものではありません。
したがって、最も単純な形式のタグは以下のようになります

     $ git tag my-first-tag

   これは、現在の HEAD を ‘.git/refs/tags/my-first-tag’ ファイルに書き込
むだけです。その後は、その特定の状態にこのシンボル名を使用できます。たと
えば、以下のことができます

     $ git diff my-first-tag

   あなたの現在の状態をそのタグとdiffします。この時点では明らかに空の
diffになりますが、あなたが開発とコミットを続ければ、タグを「アンカーポイ
ント」として使用して、あなたがタグを付けてから何が変更されたかを確認でき
ます。

   「注釈付きタグ」(annotated tag)は現実には実際のGitオブジェクトです。
タグ付けする状態へのポインタだけでなく、小さなタグ名とメッセージ、および
オプションで「はい、あなたは実際にそのタグを作成した」というPGP署名もあ
ります。これらの注釈付きタグは、 ‘git tag’ に対して ‘-a’ または ‘-s’ フ
ラグを使用して作成します:

     $ git tag -s <tagname>

   これは現在の‘HEAD‘に署名します(しかし、あなたはタグ付けするものを指定
する別の引数を指定することもできます。たとえば、 ‘git tag <tagname>
mybranch’ を使用して現在の ‘mybranch’ ポイントにタグを付けることができま
す)。

   あなたは、通常は、メジャーリリースなどの署名付きタグ付けのみを行いま
すが、軽量タグ(light-weight tags)は、あなたがマーキングしたい時に便利で
す。つまり、特定のポイントを覚えておきたいと思ったときはいつでも、そのポ
イントのプライベートタグを作成するだけで、その時点の状態の適切なシンボル
名が得られます。

Copying repositories
********************

Gitリポジトリは通常、完全に自給自足で再配置可能です。たとえば、CVSとは異
なり、「リポジトリ」と「作業ツリー」という別個の概念はありません。Gitリ
ポジトリは通常、作業ツリーであり、ローカルのGit情報は ‘.git’ サブディレ
クトリに隠されています。他には何もありません。あなたが見たそのままです。

     *Note*

     あなたは、追跡中のディレクトリからGitの内部情報を分割するように
     Gitに指示できますが、我々は今のところはそれを無視します。なぜならそ
     れは、通常のプロジェクトの仕組みでなく、本当に特別な用途のためだけ
     のものだからです。よって、「Git情報は、それが記述する作業ツリーに常
     に直接関連付けられている」という概念は技術的には100%正確ではない可
     能性がありますが、通常はそれで通ります。

   これには2つの意味があります:

   • あなたが、作成したチュートリアルリポジトリに飽きてしまった場合(また
     は間違えて最初からやり直したい場合)は、単純に以下のようにするだけで
     す

          $ rm -rf git-tutorial

     そしてそれはなくなります。外部リポジトリはありませんし、あなたが作
     成したプロジェクト以外に履歴はありません。

   • あなたがGitリポジトリを移動または複製する場合は、あなたはそうするこ
     とができます。 ‘git clone’ コマンドがありますが、リポジトリ(と、そ
     れに伴うすべての完全な履歴とともに)のコピーを作成するだけの場合は、
     通常の ‘cp -a git-tutorial new-git-tutorial’ を使用して作成できます
     。

     注意: Gitリポジトリを移動またはコピーした場合、Gitインデックスファ
     イル(さまざまな情報、特に関連するファイルの「統計」情報の一部をキャ
     ッシュする)を更新する必要がある可能性があることに注意してください。
     したがって、 ‘cp -a’ を実行して新しいコピーを作成した後、あなたは以
     下を実行する必要があります

          $ git update-index --refresh

     これは、新しいリポジトリで、インデックスファイルが最新であることを
     確認します。

   注意: 2番目のポイントは、PC間でも当てはまることに注意してください。
scpやrsyncやwget等々、通常のコピーメカニズムを使用してリモートGitリポジ
トリを複製できます。

   リモートリポジトリをコピーするときは、あなたは、これを行うときに少な
くともインデックスキャッシュを更新する必要があります。特に、他の人のリポ
ジトリでは、インデックスキャッシュが既知の状態(あなたには、彼らが何をし
たのか、まだチェックインしていないのかわかりません)にあることを確認する
必要があるため、通常は ‘git update-index’ の前に以下のようにします。

     $ git read-tree --reset HEAD
     $ git update-index --refresh

   これにより、‘HEAD’ が指すツリーからインデックス全体が再構築されます。
それはインデックスの内容を ‘HEAD’ にリセットし、 ‘git update-index’ がす
べてのインデックスエントリをチェックアウトされたファイルと一致させるよう
にします。元のリポジトリの作業ツリーにコミットされていない変更があった場
合、 ‘git update-index --refresh’ はそれらに気づき、更新する必要があるこ
とをあなたに通知します。

   上記は以下のように簡単に書くこともできます

     $ git reset

   実際、一般的なGitコマンドの組み合わせの多くは、 ‘git xyz’ インターフ
ェースを使用してスクリプト化できます。あなたは、さまざまなgitスクリプト
が何をするかを見るだけで、物事を学ぶことができます。たとえば、 ‘git
reset’ は、以前は上記2行を記述したものでした。ただし、 ‘git status’ や
‘git commit’ などのいくつかは、基本的なGitコマンドを中心とした少し複雑な
スクリプトです。

   多くの(ほとんどの？)パブリックリモートリポジトリには、チェックアウト
されたファイルやインデックスファイルすら含まれず、実際のコアGitファイル
のみが含まれます。このようなリポジトリには通常、 ‘.git’ サブディレクトリ
すらなく、すべてのGitファイルが直接リポジトリにあります。

   このような「生の」Gitリポジトリのあなた独自のローカルな活きたコピー
(local live copy)を作成するには、最初にプロジェクト用の独自のサブディレ
クトリを作成し、次に生のリポジトリの内容を ‘.git’ ディレクトリにコピーし
ます。たとえば、Gitリポジトリのあなた独自のコピーを作成するには、以下の
ようにします

     $ mkdir my-git
     $ cd my-git
     $ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git

   これに、以下が続きます

     $ git read-tree HEAD

   インデックスにデータを入力します。ただし、これでインデックスにデータ
が入力され、すべてのGit内部ファイルが作成されましたが、実際に作業するツ
リーファイルがないことに気付くでしょう。 それらを取得するには、以下のよ
うにしてそれらをチェックアウトします

     $ git checkout-index -u -a

   ここで、 ‘-u’ フラグは、(後で更新する必要がないように)チェックアウト
でインデックスを最新の状態に保つことを意味し、 ‘-a’ フラグは「すべてのフ
ァイルをチェックアウトする」ことを意味します(古いコピーまたはチェックア
ウトされたツリーの古いバージョンがある場合は、最初に ‘-f’ フラグを追加し
て、 ‘git checkout-index’ に古いファイルの上書きを「強制」するように指示
する必要がある事があります)。

   繰り返しますが、これはすべて以下のように簡略化できます

     $ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git
     $ cd my-git
     $ git checkout

   これは正に上記のすべてを行います。

   これで、あなたは、他の誰か誰か(またはあなた自身の)のリモートリポジト
リをコピーし、チェックアウトすることに成功しました。

Creating a new branch
*********************

Gitのブランチは、実際には ‘.git/refs/’ サブディレクトリ内からGitオブジェ
クトデータベースへのポインタにすぎません。すでに説明したように、‘HEAD’ ブ
ランチはこれらのオブジェクトポインタの1つへのシンボリックリンクにすぎま
せん。

   あなたはプロジェクト履歴の任意のポイントを選択し、そのオブジェクトの
SHA-1名を ‘.git/refs/heads/’ の下のファイルに書き込むだけで、いつでも新
しいブランチを作成できます。任意のファイル名(実際にはサブディレクトリ名
)を使用できますが、慣例では、「通常の」ブランチ(normal branch)は「
master」と呼ばれます。 ただし、これは単なる慣例であり、強制されるもので
はありません。

   これを例として示すために、以前使用したgit-tutorialリポジトリに戻り、
その中にブランチを作成しましょう。これを行うには、あなたは新しいブランチ
をチェックアウトしたいと言うだけです:

     $ git switch -c mybranch

   現在の ‘HEAD’ 位置に基づいて新しいブランチを作成し、それに切り替えま
す。

     *Note*

     あなたが、履歴の現在のHEAD以外の時点で新しいブランチを開始すること
     を決定した場合は、 ‘git switch’ にチェックアウトの起点を指定するだ
     けで開始できます。 言い換えれば、以前に作ったタグまたはブランチがあ
     る場合は以下のようにします。

          $ git switch -c mybranch earlier-commit

     そうすると、これは以前のコミットにて新しいブランチ ‘mybranch’ を作
     成し、その時の状態をチェックアウトします。

   以下のように実行することで、あなたはいつでも元の ‘master’ ブランチに
戻ることができます

     $ git switch master

   (または、その他のブランチ名を指定します。) そして、あなたがたまたまど
のブランチにいるのかを忘れた場合は、単純に以下のようにします。

     $ cat .git/HEAD

   とすると、それが指している場所を教えてくれます。あなたが持っているブ
ランチのリストを取得するには、以下のようにします。

     $ git branch

   これは、以前は、 ‘ls .git/refs/heads’ を囲む単純なスクリプトにすぎま
せんでした。それはそれとして、これは、現在使用しているブランチの前にアス
タリスクが表示されます。

   実際にチェックアウトして切り替えることなく、新しいブランチを作成した
い場合があります。その場合は、以下のコマンドを使用してください

     $ git branch <branchname> [startingpoint]

   これは単にブランチを作成しますが、それ以上は何もしません。 その後 — そ
のブランチで実際に開発することを決定したら — 引数としてブランチ名を使用
して、通常の ‘git switch ‘を使用してそのブランチに切り替えることができま
す。

Merging two branches
********************

ブランチを持つことのアイデアの1つは、ブランチでいくつかの(おそらく実験的
な)作業を行い、最終的にそれをメインブランチにマージすることです。したが
って、元の ‘master’ ブランチと同じである、上記の ‘mybranch’ を作成したと
仮定して、我々がそのブランチにいることを確認し、そこでいくつかの作業を行
いましょう。

     $ git switch mybranch
     $ echo "Work, work, work" >>hello
     $ git commit -m "Some work." -i hello

   ここでは、 ‘hello’ に別の行を追加し、 ‘-i’ フラグ(コミット時にこれま
でにインデックスファイルに対して行ったことに加えて、そのファイルを「含め
る」ようにGitに指示)を使用してファイル名を ‘git commit’ に直接指定する、
‘git update-index hello’ と ‘git commit’ の両方を実行するための省略形を
使用しました。 ‘-m’ フラグは、コマンドラインからコミットログメッセージを
指定するためのものです。

   ここで、もう少し面白くするために、他の誰かが元のブランチで何らかの作
業を行っていると仮定し、マスターブランチに戻って同じファイルを別の方法で
編集することにより、それをシミュレートします:

     $ git switch master

   ここで、 ‘hello’ の内容を確認して、あなたが ‘mybranch’ で行った作業が
含まれていないことに注目してください。その作業は ‘master’ ブランチではま
ったく行われていないためです。確認後、以下のようにします

     $ echo "Play, play, play" >>hello
     $ echo "Lots of fun" >>example
     $ git commit -m "Some fun." -i hello example

   masterブランチもいい感じになってきました。

   いまや、2つのブランチがあり、あなたは完了した作業をマージすることにし
ました。 その前に、何が起こっているのかを確認するのに役立つクールなグラ
フィカルツールを紹介しましょう:

     $ gitk --all

   あなたのブランチ(これが ‘--all’ の意味です。通常は、現在の ‘HEAD’ が
表示されます)とその履歴の両方をグラフィカルに表示します。また、それらが
どのようにして共通のソースから得られたのかを正確に確認することもできます
。

   とにかく、 _gitk_ を終了( ‘^Q’ または Fileメニュー)し、 ‘mybranch’ ブ
ランチで行った作業を ‘master’ ブランチ（現在は ‘HEAD’ でもあります)にマ
ージすることにします。これを行うために、 ‘git merge’ と呼ばれる優れたス
クリプトがあり、それは、あなたがどのブランチを解決したいのか、そのマージ
が何なのかを知りたがっています:

     $ git merge -m "Merge work in mybranch" mybranch

   マージを自動的に解決できる場合は、最初の引数がコミットメッセージとし
て使用されます。

   さて、今回は、マージを手動で修正する必要がある状況を意図的に作成した
ので、Gitは可能な限り多くのことを自動的に実行(この場合は、 ‘mybranch’ ブ
ランチの、差異がない ‘example’ ファイルをマージするだけ)した上で、以下の
ように言います:

             Auto-merging hello
             CONFLICT (content): Merge conflict in hello
             Automatic merge failed; fix conflicts and then commit the result.

   これは、「自動マージ」(Automatic merge)を実行したら ‘hello’ の競合が
原因で失敗したと表示しています。

   でも心配無用。これにより、あなたがCVSを使ったことがあるなら既に慣れて
いる形式で ‘hello’ に競合を残したので、エディタで ‘hello’ を開いて、なん
とかして修正しましょう。私は ‘hello‘に4行すべてが含まれるようにすること
を提案することにします:

     Hello World
     It's a new day for git
     Play, play, play
     Work, work, work

   手動マージに満足したら、以下の手順を実行します。

     $ git commit -i hello

   これは、現在マージをコミットしていることを非常に大声で警告します(今回
は正しい事をしているので、警告は気にしないでください)。また、あなたは
‘git merge’ 遊園地でのあなたの冒険についての小さなマージメッセージを書く
ことができます。

   完了したら、 ‘gitk --all’ を起動して、履歴がどのように表示されるかを
グラフィカルに確認します。 ‘mybranch’ はまだ存在していることに注意してく
ださい。これに切り替えて、必要に応じて作業を続けることができます。
‘mybranch’ ブランチにはそのマージが含まれませんが、次回 ‘master’ ブラン
チにてそれをマージするときに、Gitはそれがどのようにマージされたかを知っ
ているため、再度マージを行う必要はありません。

   X-Window環境で常に作業するわけではない場合、もう1つの便利ツールは、
‘git show-branch’ です。

     $ git show-branch --topo-order --more=1 master mybranch
     * [master] Merge work in mybranch
      ! [mybranch] Some work.
     --
     -  [master] Merge work in mybranch
     *+ [mybranch] Some work.
     *  [master^] Some fun.

   最初の2行は、ツリーの最上位コミットのタイトル付の2つのブランチを示し
ています。あなたは現在(アスタリスク ‘*’ 文字に注意)、 ‘master’ ブランチ
を使用しており、その後の出力行は、 ‘master’ ブランチに含まれるコミットと
、 ‘mybranch’ ブランチの行の2桁目(‘+’)を表示するために使用されます。3つ
のコミットがタイトルとともに表示されます。それらはすべて1桁目に空白以外
の文字があり( ‘*’ は現在のブランチでの通常のコミットを示し、‘-’ はマージ
コミットです)、これはそれらが現在 ‘master’ ブランチの一部であることを意
味します。 ‘mybranch’ はmasterブランチからのこれらのコミットを組み込むた
めにマージされていないため、「Some work」コミットのみが2桁目にプラスの
‘+’ 文字を持っています。コミットログメッセージの前の括弧内の文字列は、コ
ミットに名前を付けるために使用できる短い名前です。上記の例では、
"master" と "mybranch" がブランチヘッドです。 "master^" は "master" ブラ
ンチヘッドの最初の親です。より複雑なケースを確認したい場合は、
gitrevisions(7) を参照してください。

     *Note*

     _–more=1_ オプションがないと、 _[mybranch]_ コミット は _master_ と
     _mybranch_ の両方の先端の共通の祖先であるため、 ‘git show-branch’ は
     ’[master^] コミットを出力しません。詳細については、
     git-show-branch(1) を参照してください。

     *Note*

     マージ後に ‘master’ ブランチにさらにコミットがあった場合、‘git
     show-branch’ はデフォルトではマージコミット自体を表示しません。この
     場合、マージコミットを表示するには、 ‘--sparse’ オプションを指定す
     る必要があります。

   さて、あなたが ‘mybranch’ ですべての作業を行ったとしましょう。そして
、あなたの努力の成果がついに ‘master’ ブランチに統合されました。あなたは
‘mybranch‘に戻り、 _git merge_ を実行して、「アップストリームの変更」を
あなたのブランチに戻しましょう。

     $ git switch mybranch
     $ git merge -m "Merge upstream changes." master

   これは以下のようなものを出力します(実際のコミットオブジェクト名は異な
ります)

     Updating from ae3a2da... to a80b4aa....
     Fast-forward (no commit created; -m option ignored)
      example | 1 +
      hello   | 1 +
      2 files changed, 2 insertions(+)

   あなたのブランチにはすでに ‘master’ ブランチにマージされたもの以外の
ものが含まれていなかったため、マージ操作は実際にはマージを実行しませんで
した。代わりに、あなたのブランチのツリーのトップを ‘master’ ブランチのツ
リーのトップに更新しました。これはしばしば「早送り」(fast-forward)マージ
と呼ばれます。

   あなたは再び ‘gitk --all’ を実行して、コミットの祖先がどのように見え
るかを確認するか、 ‘show-branch’ を実行して表示します。

     $ git show-branch master mybranch
     ! [master] Merge work in mybranch
      * [mybranch] Merge work in mybranch
     --
     -- [master] Merge work in mybranch

Merging external work
*********************

通常、自分のブランチとマージするよりも、他の誰かのとマージする方がはるか
に一般的です。そして、Gitを使用すると、これも非常に簡単になります。事実
、 ‘git merge’ を実行するのとそれほど違いはありません。 実際、リモートマ
ージは、「リモートリポジトリから一時的タグ(temporary tag)に作業をフェッ
チする」だけで、その後に ‘git merge’ が続きます。

   リモートリポジトリからのフェッチは、ご想像の通り、 ‘git fetch’ によっ
て行われます:

     $ git fetch <remote-repository>

   以下の転送方法(transport)のいずれかを使用して、ダウンロード元のリポジ
トリに名前を付けることができます:

SSH
     ‘remote.machine:/path/to/repo.git/’ または

     ‘ssh://remote.machine/path/to/repo.git/’

     この転送方法(transport)はアップロードとダウンロードの両方に使用でき
     、リモートマシンへの ‘ssh’ を介したログイン権限が必要です。転送元と
     転送先が持つヘッドコミットを交換し、オブジェクトの最小組を(限定的に
     )転送することにより、反対側に欠けているオブジェクトの組を見つけます
     。これは、リポジトリ間でGitオブジェクトを交換するための最も効率的な
     方法です。

ローカルディレクトリ
     ‘/path/to/repo.git/’

     この転送方法はSSH転送と同じですが、 ‘ssh’ を介してリモートマシンで
     もう一方の端を実行する代わりに、 ‘sh’ を使用してローカルマシンで転
     送元と転送先で実行します。

Gitネイティブ
     ‘git://remote.machine/path/to/repo.git/’

     この転送方法は、匿名(anonymous)でダウンロードするために設計されまし
     た。SSH転送と同様に、ダウンストリーム側にないオブジェクトの組を検出
     し、最小のオブジェクトの組を(限定的)転送します。

HTTP(S)
     ‘http://remote.machine/path/to/repo.git/’

     http URL や https URL からのダウンローダーは、最初に、
     ‘repo.git/refs/’ ディレクトリの下にある指定のref名を調べて、リモー
     トサイトから最上位のコミットオブジェクト名を獲得し、それから、その
     コミットオブジェクトのオブジェクト名を使用して
     ‘repo.git/objects/xx/xxx...’ からダウンロードすることにより、コミッ
     トオブジェクトの取得を試みます。次に、そのコミットオブジェクトを読
     み取り、その親コミットと関連するツリーオブジェクトを見つけます。必
     要なすべてのオブジェクトを取得するまで、このプロセスを繰り返します
     。この動作のため、これらは「コミットウォーカー」(commit walkers)と
     呼ばれることもあります。

     「コミットウォーカー」(commit walkers)は、Gitネイティブ転送のように
     Git対応のスマートサーバーを必要としないため、「バカ転送」(dumb
     transports)と呼ばれることもあります。ディレクトリインデックスさえサ
     ポートしていないストックHTTPサーバーで十分です。 ただし、バカ転送ダ
     ウンローダー(dumb transport downloaders)を支援するには、 ‘git
     update-server-info’ を使用してリポジトリを準備する必要があります。

   リモートリポジトリからフェッチしたら、あなたはそれを現在のブランチに
「マージ」します。

   ただし、「フェッチ」してすぐに「マージ」するのは非常に一般的なことな
ので、 ‘git pull’ を使えば簡単に実行できます:

     $ git pull <remote-repository>

   そして、オプションで、リモート側のブランチ名を2番目の引数として指定し
ます。

     *Note*

     あなたが持ちたいブランチの数のローカルリポジトリを保持し、ブランチ
     間のマージと同様に ‘git pull’ でそれらの間のマージを行うことで、ブ
     ランチを全く使用しないことも可能です。このアプローチの利点は、チェ
     ックアウトされた各々「ブランチ」のファイルの組を保持できることです
     。複数の開発ラインを同時に調整すると、切り替えが簡単になる場合があ
     ります。もちろん、複数の作業ツリーを保持するためにディスク使用量を
     増やすという代償を払うことにはなりますが、最近のディスク容量は安価
     です。

   あなたは同じリモートリポジトリからしばしばプルする可能性があります。
なので略記法として、リモートリポジトリのURLをローカルリポジトリの設定フ
ァイルに以下のように保存できます:

     $ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/

   そして、完全なURLの代わりに ‘git pull’ で "linus" キーワードを使用し
ます。

   例:

  1. ‘git pull linus’

  2. ‘git pull linus tag v0.99.1’

   上記は以下と同じです:

  1. ‘git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD’

  2. ‘git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1’

How does the merge work?
************************

このチュートリアルでは、動作しない磁器コマンドに対処するために配管コマン
ドがどのように機能するかを示していますが、これまでのところ、マージが実際
にどのように機能するかについては説明していません。あなたがこのチュートリ
アルを初めて読む時は、「Publishing your work」セクションにスキップして、
後でここに戻ってくることをお勧めします。

   上記を了承したとして、続きをやります。例を示すために、 ‘hello’ ファイ
ルと ‘example’ ファイルを使用した以前のリポジトリに戻り、マージ前の状態
に戻しましょう:

     $ git show-branch --more=2 master mybranch
     ! [master] Merge work in mybranch
      * [mybranch] Merge work in mybranch
     --
     -- [master] Merge work in mybranch
     +* [master^2] Some work.
     +* [master^] Some fun.

   ‘git merge’ を実行する前は、 ‘master’ ヘッドが "Some fun." コミット、
‘mybranch’ ヘッドが "Some work." コミットだったことを思い出してください
。

     $ git switch -C mybranch master^2
     $ git switch master
     $ git reset --hard master^

   巻き戻し後、コミット構造は以下のようになります:

     $ git show-branch
     * [master] Some fun.
      ! [mybranch] Some work.
     --
     *  [master] Some fun.
      + [mybranch] Some work.
     *+ [master^] second commit.

   これで、手動でマージを試す準備ができました。

   ‘git merge’ コマンドは、2つのブランチをマージするときに、3方向マージ
アルゴリズムを使用します。 まず、それらの間の共通の祖先を見つけます。使
用するコマンドは ‘git merge-base’ です:

     $ mb=$(git merge-base HEAD mybranch)

   このコマンドは、共通の祖先のコミットオブジェクト名を標準出力に書き込
むため、我々は次のステップで使用するため、その出力を変数にキャプチャしま
した。ちなみに、今回は、共通の祖先コミットは「second commit.」コミットで
す。あなたはそれを以下のように言うことができます:

     $ git name-rev --name-only --tags $mb
     my-first-tag

   共通の祖先コミットを見つけた後の、2番目のステップは以下のとおりです:

     $ git read-tree -m -u $mb HEAD mybranch

   これは、すでに見たのと同じ ‘git read-tree’ コマンドですが、前の例とは
異なり、3つのツリーが必要です。 これにより、各ツリーの内容がインデックス
ファイルの異なる「ステージ」に読み込まれます(最初のツリーはステージ1に、
2番目はステージ2に、等)。3つのツリーを3つのステージに読み取った後、3つの
ステージで同じパスがある場合はステージ0に「折りたたまれます」
(collapsed)。また、3つのステージのうちの2つで同じパスは、ステージ0に折り
たたまれ、ステージ1と異なるステージ2またはステージ3のいずれかからSHA-1を
取得します(つまり、共通の祖先から片側だけが変更されます)。

   「折りたたみ」(collapsing)操作の後、3つのツリーで異なるパスはゼロ以外
のステージに残されます。この時点で、以下のコマンドを使用してインデックス
ファイルを調査できます:

     $ git ls-files --stage
     100644 7f8b141b65fdcee47321e399a2598a235a032422 0       example
     100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1       hello
     100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2       hello
     100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello

   私達の2つのファイルのみの例では、変更されていないファイルがなかったた
め、 ‘example’ のみが折りたたまれました。 しかし、実際の大規模なプロジェ
クトでは、1回のコミットで変更されるファイルの数が少ない場合、この「折り
たたみ」はほとんどのパスをかなり迅速にマージする傾向があり、ゼロ以外のス
テージでの実際の変更はほんの一握りになります。

   ゼロ以外のステージのみを確認するには、 ‘--unmerged’ フラグを使用しま
す:

     $ git ls-files --unmerged
     100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1       hello
     100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2       hello
     100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello

   マージの次のステップは、3方向マージを使用して、これら3つのバージョン
のファイルをマージすることです。これは、 ‘git merge-index’ コマンドの引
数の1つとして ‘git merge-one-file’ コマンドを指定することによって行われ
ます:

     $ git merge-index git-merge-one-file hello
     Auto-merging hello
     ERROR: Merge conflict in hello
     fatal: merge program failed

   ‘git merge-one-file’ スクリプトは、これら3つのバージョンを記述するた
めのパラメーターを使用して呼び出され、マージ結果を作業ツリーに残す役割を
果たします。 これはかなり単純なシェルスクリプトであり、最終的にはRCSスイ
ートから ‘merge’ プログラムを呼び出して、ファイルレベルの3方向マージを実
行します。今回は、 ‘merge’ は競合を検出し、競合マークのあるマージ結果が
作業ツリーに残ります。これは、この時点で ‘ls-files --stage’ を再度実行す
ると確認できます:

     $ git ls-files --stage
     100644 7f8b141b65fdcee47321e399a2598a235a032422 0       example
     100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1       hello
     100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2       hello
     100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello

   これは、 ‘git merge’ が制御を返した後のインデックスファイルと作業ファ
イルの状態であり、競合するマージを解決できるようにします。 パス ‘hello’
はまだマージされておらず、この時点で ‘git diff’ で表示されるのは、ステー
ジ2(つまり、あなたのバージョン)との違いであることに注意してください。

Publishing your work
********************

そういうわけで、私達はリモートリポジトリから他の人の作業を使用することは
できますが、他の人がリポジトリからプルできるようにリポジトリを作成するに
は、あなたはどうすればよいのでしょうか？

   あなたのプライマリリポジトリが ‘.git’ サブディレクトリとしてその下に
ぶら下がっているあなたの作業ツリーで実際の作業を行っています。あなたはそ
のリポジトリにリモートでアクセスできるようにして、そこからプルするように
人々に依頼することも可能ですが、実際には、それは通常の方法ではありません
。推奨される方法は、パブリックリポジトリを用意し、他の人がアクセスできる
ようにすることです。あなたのプライマリ作業ツリーに加えた変更がよい状態に
なったら、そこからパブリックリポジトリを更新します。これはしばしば「プッ
シュ」(pushing)と呼ばれます。

     *Note*

     このパブリックリポジトリはさらにミラーリングされる可能性があり、そ
     れが ‘kernel.org’ のGitリポジトリの管理方法です。

   ローカル(プライベート)リポジトリからリモート(パブリック)リポジトリに
変更を公開するには、リモートマシンでの書き込み権限が必要です。単一のコマ
ンド ‘git-receive-pack’ を実行するには、そこにSSHアカウントが必要です。

   まず、パブリックリポジトリを格納する空のリポジトリをリモートマシンに
作成する必要があります。この空のリポジトリは、後でプッシュすることで、デ
ータが設定され、最新の状態に保たれる。明らかに、このリポジトリの作成は
1度だけ実行する必要があります。

     *Note*

     ‘git push’ は、ローカルマシンでは ‘git send-pack’ 、リモートマシン
     では ‘git-receive-pack’ というコマンドのペアを使用します。ネットワ
     ークを介した2つのコマンドの間の通信は、内部でSSH接続を使用します。

   あなたのプライベートリポジトリのGitディレクトリは通常 ‘.git’ ですが、
パブリックリポジトリはプロジェクト名にちなんで名付けられていることがよく
あります。つまり ‘<project>.git’ です。 プロジェクト ‘my-git’ のこのよう
なパブリックリポジトリを作成しましょう。リモートマシンにログインした後、
以下のように空のディレクトリを作成します:

     $ mkdir my-git.git

   次に、 _git init_ を実行してそのディレクトリをGitリポジトリにしますが
、今回はその名前が通常の ‘.git’ ではないため、我々は少し異なる方法で処理
します:

     $ GIT_DIR=my-git.git git init

   あなたが選択した転送方法(transport)を介して変更をプルする他のユーザー
がこのディレクトリを使用できることを確認してください。 また、あなたは
‘$PATH’ 上に _git-receive-pack_ プログラムがあることを確認する必要があり
ます。

     *Note*

     sshdの多くのインストールでは、あなたがプログラムを直接実行するとき
     に、ログインシェルとしてあなたのシェルが呼び出されません。これが意
     味するのは、ログインシェルが ‘bash’ の場合、 ‘.bashrc’ のみが読み取
     られ、 ‘.bash_profile’ は読み取られないということです。 回避策とし
     て、あなたが ‘git-receive-pack’ プログラムを実行できるように、
     ‘.bashrc’ で ‘$PATH’ を設定していることを確認してください。

     *Note*

     あなたがこのリポジトリを公開してhttp経由でアクセスする場合は、この
     時点で ‘mv my-git.git/hooks/post-update.sample
     my-git.git/hooks/post-update’ を実行する必要があります。これにより
     、このリポジトリにプッシュするたびに、 ‘git update-server-info’ が
     実行されます。

   これで、あなたの「パブリックリポジトリ」であなたの変更を受け入れる準
備が整いました。あなたのプライベートリポジトリがあるマシンに戻ってくださ
い。 そこから、以下のコマンドを実行します:

     $ git push <public-host>:/path/to/my-git.git master

   これにより、あなたのパブリックリポジトリが同期され、指定のブランチヘ
ッド(つまり、この場合は ‘master’)と、あなたの現在のリポジトリ内のそれら
から到達可能なオブジェクトが一致します。

   実例として、以下は私のパブリックGitリポジトリを更新する方法です。
Kernel.orgミラーネットワークは、他の公開されているマシンへの伝播を処理し
ます:

     $ git push master.kernel.org:/pub/scm/git/git.git/

Packing your repository
***********************

以前、私達は作成したGitオブジェクトごとに ‘.git/objects/??/’ ディレクト
リの下に1つのファイルが保存されていることを確認しました。この表現は、ア
トミックかつ安全に作成するには効率的ですが、ネットワークを介した転送には
それほど便利ではありません。Gitオブジェクトは、作成されると不変であるた
め、「一緒にパックする」ことでストレージを最適化する方法があります。以下
のコマンド

     $ git repack

   は、あなたのためにそれをします。チュートリアルの例に従うと、これまで
に約17個のオブジェクトが ‘.git/objects/??/’ ディレクトリに蓄積されている
はずです。 ‘git repack’ は、パックしたオブジェクトの数を示し、パックされ
たファイルを ‘.git/objects/pack’ ディレクトリに保存します。

     *Note*

     ‘.git/objects/pack’ ディレクトリに ‘pack-*.pack’ と ‘pack-*.idx’ の
     2つのファイルがあります。これらは互いに密接に関連しているため、何ら
     かの理由で手動で別のリポジトリにコピーする場合は、必ず一緒にコピー
     する必要があります。前者はパック内のオブジェクトからのすべてのデー
     タを保持し、後者はランダムアクセスのためのインデックスを保持します
     。

   あなたが病的なほど疑り深い場合は、 ‘git verify-pack’ コマンドを実行す
ると、破損したパックがあるかどうかが検出されますが、あまり心配する必要は
ありません。私たちのプログラムは常に完璧です ;-)

   オブジェクトをパックしたら、既にパックファイルに取り込まれている、パ
ックされていないオブジェクトを残す必要はありません。

     $ git prune-packed

   これは、あなたのためにそれらを削除します。

   あなたがもの好きならば、‘git prune-packed’ を実行する前後に ‘find
.git/objects -type f’ を実行してみてください。 また、 ‘git
count-objects’ は、リポジトリ内でパックされていないオブジェクト(unpacked
objects)の数と、それらが消費しているスペースの量を示します。

     *Note*

     パックされたリポジトリでは比較的大きなパックに含まれるオブジェクト
     が比較的少ない可能性があるため、HTTP転送(transport)での ‘git pull’
     は少々面倒です。パブリックリポジトリから多くのHTTPプルが予想される
     場合は、頻繁に再パックして整理するか、まったく行わないことをお勧め
     します。

   この時点で再度 ‘git repack’ を実行すると、「Nothing new to pack.」(新
しくパックするものはありません)と表示されます。あなたが開発を続行して変
更を蓄積してから、 ‘git repack’ を再度実行すると、前回リポジトリをパック
して以降に作成されたオブジェクトを含む新しいパックが作成されます。最初の
インポートの直後にプロジェクトをパックし(プロジェクトを最初から開始する
場合を除く)、プロジェクトの活発度度に応じて、時々 ‘git repack’ を実行す
ることをお勧めします。

   リポジトリが ‘git push’ と ‘git pull’ を介して同期される場合、転送元
リポジトリにてパックされてたオブジェクトは通常、転送先ではアンパックされ
て保存されます。これにより、転送元と転送先で異なるパッキング戦略を使用で
きますが、両方のリポジトリを時々再パックする必要がある場合もあります。

Working with Others
*******************

Gitは真に分散されたシステムですが、多くの場合、開発者の非公式な階層でプ
ロジェクト編成すると便利です。Linuxカーネル開発はこの方法で実行されます
。 Randy Dunlap’s presentation
(https://web.archive.org/web/20120915203609/http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf)
の (17ページ "Merges to Mainline") にイラストがあります。

   この階層は純粋に「非公式」であることを強調しておく必要があります。こ
の階層が意味する「パッチフローのチェーン」を強制するようなGitでの必須の
ものは何もありません。あなたはただ1つのリモートリポジトリからプルする必
要はありません。

   「プロジェクト指揮」(project lead)の推奨作業フローは以下のようになり
ます:

  1. あなたのローカルマシンで、あなたのプライマリリポジトリを準備します
     。あなたの作業はそこで行います。

  2. 他の人がアクセスできる公開リポジトリを準備します。

     他の人がバカ転送プロトコル(dumb transport protocols)(HTTP)を介して
     リポジトリからプルしている場合、このリポジトリを「バカ転送フレンド
     リー」(dumb transport friendly)に保つ必要があります。 ‘git init’ 後
     、標準テンプレートからコピーした
     ‘$GIT_DIR/hooks/post-update.sample’ には、 ‘git update-server-info’
     の呼び出しが含まれますが、あなたは ‘mv post-update.sample
     post-update’ を使用してフックを手動で有効にする必要があります。これ
     により、 ‘git update-server-info’ が必要なファイルを最新の状態に保
     つことができます。

  3. あなたのプライマリリポジトリから公開リポジトリにプッシュします。

  4. 公開リポジトリを ‘git repack’ します。これにより、オブジェクトの初
     期セットをベースラインとして含む大きなパックが確立されます。リポジ
     トリからのプルに使用される転送方法(transport)がパックされたリポジト
     リ(packed repositories)をサポートしている場合は、 ‘git prune’ が使
     える可能性があります。

  5. あなたはプライマリリポジトリで作業を続けます。あなたの変更は、あな
     た独自の変更や、電子メールで受信するパッチや、「サブシステム保守者
     」の「公開」リポジトリをプルした結果のマージを含んでいます。

     あなたはこのプライベートリポジトリはいつでも再パックできます。

  6. あなたの変更を公開リポジトリにプッシュし、公開します。

  7. 時々、公開リポジトリを ‘git repack’ します。 手順5に戻り、作業を続
     行します。

   そのプロジェクトに取り組んでいて、独自の「公開リポジトリ」を持つ「サ
ブシステム保守者」に推奨される作業サイクルは以下のようになります:

  1. 「プロジェクト指揮」の公開リポジトリ上で ‘git clone’ を実行して、あ
     なたの作業リポジトリを準備します。初期クローン作成に使用されるURLは
     、 remote.origin.url 構成変数に格納されます。

  2. 「プロジェクト指揮」の人と同じように、他の人がアクセスできる公開リ
     ポジトリを準備します。

  3. 「プロジェクト指揮」リポジトリが同じマシン上にある場合を除き、パッ
     クされたファイルを「プロジェク指揮」の公開リポジトリからあなたの公
     開リポジトリにコピーします。後者の場合、あなたは
     ‘objects/info/alternates’ ファイルを使用して、借用しているリポジト
     リを指すことができます。

  4. あなたのプライマリリポジトリから公開リポジトリにプッシュします。
     ‘git repack’ を実行し、そして、リポジトリからのプルに使用される転送
     方法(transport)がパックされたリポジトリ(packed repositories)をサポ
     ートしている場合は ‘git prune’ を実行します。

  5. あなたのプライマリリポジトリで作業を続けます。あなたの変更には、あ
     なた独自の変更や、電子メールで受信するパッチや、「プロジェクト指揮
     」と場合によっては「サブサブシステム保守者」の「公開」リポジトリを
     プルした結果のマージが含まれます。

     あなたはこのプライベートリポジトリはいつでも再パックできます。

  6. あなたの変更をあなたの公開リポジトリにプッシュし、「プロジェクト指
     揮」と、場合によっては「サブサブシステム保守者」にプルするように依
     頼します。

  7. 時々、公開リポジトリを ‘git repack’ します。 手順5に戻り、作業を続
     行します。

   「公開」リポジトリを持たない「個人開発者」に推奨される作業サイクルは
多少異なります。以下のようになります:

  1. 「プロジェクト指揮」(またはサブシステムで作業している場合は「サブシ
     ステム保守者」)の公開リポジトリを ‘git clone’ して、あなたの作業リ
     ポジトリを準備します。初期クローン作成に使用されるURLは、
     remote.origin.url 構成変数に格納されます。

  2. あなたは、あなたのリポジトリの _master_ ブランチで作業を行います。

  3. 時々、あなたのアップストリームの公開リポジトリから ‘git fetcho
     rigin’ を実行します。これは ‘git pull’ の前半のみを実行しますが、マ
     ージはしません。公開リポジトリのヘッドは
     ‘.git/refs/remotes/origin/master’ に保存されています。

  4. ‘git cherry origin’ を使用して、どのパッチが受け入れられたかを確認
     したり、 ‘git rebase origin’ を使用して、あなたのマージされていない
     変更を更新されたアップストリームに転送します。

  5. ‘git format-patch origin’ を使用して、アップストリームへの電子メー
     ル送信用のパッチを準備し、送信します。 手順2に戻り、作業を続行しま
     す。

Working with Others, Shared Repository Style
********************************************

あなたがCVS界隈から来ていたら、前のセクションで提案された協力のスタイル
はあなたにとって新しいものかもしれません。でも心配する必要はありません。
Gitは、おそらくあなたもよく知っている「共有公開リポジトリ」(shared
public repository)スタイルの協同作業をサポートしています。

   詳細については gitcvs-migration(7) を参照してください。

Bundling your work together
***************************

あなたは一度に複数のことに取り組む可能性があります。Gitでブランチを使用
すると、これらの多かれ少なかれ独立したタスクを簡単に管理できます。

   私達は2つのブランチを使用した「fun and work」の例で、ブランチがどのよ
うに機能するかはすでに見てきました。ブランチが3つ以上ある場合も、考え方
は同じです。 ‘master’ ヘッドから始めて、 ‘master’ ブランチにいくつかの新
しいコードがあり、 ‘commit-fix’ ブランチと ‘diff-fix’ ブランチに2つの独
立した修正があるとします:

     $ git show-branch
     ! [commit-fix] Fix commit message normalization.
      ! [diff-fix] Fix rename detection.
       * [master] Release candidate #1
     ---
      +  [diff-fix] Fix rename detection.
      +  [diff-fix~1] Better common substring algorithm.
     +   [commit-fix] Fix commit message normalization.
       * [master] Release candidate #1
     ++* [diff-fix~2] Pretty-print messages.

   両方の修正は十分にテストされており、この時点で、両方をマージする必要
があります。あなたは以下のように、最初に ‘diff-fix’ でマージし、次に
‘commit-fix’ でマージする事ができます:

     $ git merge -m "Merge fix in diff-fix" diff-fix
     $ git merge -m "Merge fix in commit-fix" commit-fix

   この結果は以下のようになります:

     $ git show-branch
     ! [commit-fix] Fix commit message normalization.
      ! [diff-fix] Fix rename detection.
       * [master] Merge fix in commit-fix
     ---
       - [master] Merge fix in commit-fix
     + * [commit-fix] Fix commit message normalization.
       - [master~1] Merge fix in diff-fix
      +* [diff-fix] Fix rename detection.
      +* [diff-fix~1] Better common substring algorithm.
       * [master~2] Release candidate #1
     ++* [master~3] Pretty-print messages.

   しかしながら、あなたが持っているものが真に独立した変更のセットである
場合、最初に一方のブランチにマージし、次にもう一方のブランチにマージする
特別な理由はありません(もし順序が重要な場合は、それらは定義上独立してい
るとは言えません)。代わりに、これら2つのブランチを現在のブランチに一度に
マージすることができます。まずは、今行ったことを元に戻して、最初からやり
直しましょう。 ‘master~2’ にリセットすることにより、これら2つのマージの
前のmasterブランチを取得する必要があります:

     $ git reset --hard master~2

   ‘git show-branch’ すれば、先ほど行った2つの ‘git merge’ の前の状態と
一致することを確認できます。 次に、2つの ‘git merge’ コマンドを連続して
実行する代わりに、これら2つのブランチヘッドをマージします(これは「making
an Octopus」(タコ足メイク)として知られています):

     $ git merge commit-fix diff-fix
     $ git show-branch
     ! [commit-fix] Fix commit message normalization.
      ! [diff-fix] Fix rename detection.
       * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
     ---
       - [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
     + * [commit-fix] Fix commit message normalization.
      +* [diff-fix] Fix rename detection.
      +* [diff-fix~1] Better common substring algorithm.
       * [master~1] Release candidate #1
     ++* [master~2] Pretty-print messages.

   注意: 可能であるからいって必ずしもタコ足(octopus)をやるべきではない、
ということに注意してください。タコ足(octopus)は有効な方法であり、2つ以上
の独立した変更を同時にマージする場合、コミット履歴を簡単に表示できること
がよくあります。しかし、マージしているブランチのいずれかとマージの競合が
あり、手動で解決する必要がある場合は、これは、これらのブランチで発生した
開発が結局独立していないことを示しています。そうすると、あなたは、どうし
て一度に2つをマージして、競合をどのように解決したか、および一方の側で行
われた変更をもう一方の側よりも優先した理由を文書化しなければならなくなり
ます。そうしないと、プロジェクトの履歴を追跡するのが難しくなり、簡単では
なくなります。

SEE ALSO
********

gittutorial(7), gittutorial-2(7), gitcvs-migration(7), git-help(1),
giteveryday(7), The Git User’s Manual (user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

gitcredentials — Gitにユーザー名とパスワードを提供する

Synopsis
********

     git config credential.https://example.com.username myusername
     git config credential.helper "$helper $options"

DESCRIPTION
***********

Gitは、操作を実行するためにユーザーからの資格情報を必要とする場合があり
ます。たとえば、HTTP経由でリモートリポジトリにアクセスするために、ユーザ
ー名とパスワードを要求する必要がある場合があります。このマニュアルでは、
Gitがこれらの資格情報を要求するために使用するメカニズムと、これらの資格
情報を繰り返し入力しないようにするためのいくつかの機能について説明します
。

REQUESTING CREDENTIALS
**********************

資格情報ヘルパーが定義されていない場合、Gitは以下の戦略でユーザーにユー
ザー名とパスワードを要求します:

  1. ‘GIT_ASKPASS’ 環境変数が設定されている場合、その環境変数で指定した
     プログラムが呼び出されます。コマンドラインでプログラムによって適切
     なプロンプトが表示され、ユーザーの入力が標準出力から読み取られます
     。

  2. それ以外の場合、 ‘core.askPass’ 構成変数が設定されていると、その値
     は上記と同様に使用されます。

  3. それ以外の場合、‘SSH_ASKPASS’ 環境変数が設定されていると、その値は
     上記と同様に使用されます。

  4. それ以外の場合、端末でユーザーの入力が促されます。

AVOIDING REPETITION
*******************

同じ資格情報を何度も入力するのは面倒な場合があります。 Gitには、この煩わ
しさを軽減する2つの方法があります:

  1. 指定の認証コンテキストのためのユーザー名の静的構成。

  2. パスワードをキャッシュまたは保存するため、またはシステムパスワード
     ウォレットまたはキーチェーンと対話するための資格情報ヘルパー。

   1つ目は、パスワードに使用できる安全なストレージがない場合に簡単で適切
です。これは通常、以下を構成に追加することによって設定します:

     [credential "https://example.com"]
             username = me

   一方、資格情報ヘルパーは、Gitがユーザー名とパスワードの両方を要求でき
る外部プログラムです。これらは通常、OSまたは他のプログラムによって提供さ
れる安全なストレージとインターフェイスします。

   ヘルパーを使用するには、最初に使用するヘルパーを選択する必要がありま
す。Gitには現在、以下のヘルパーが含まれています:

cache
     資格情報をメモリに短期間キャッシュします。 詳細については
     git-credential-cache(1) を参照してください。

store
     資格情報をディスクに無期限に保存します。詳細については
     git-credential-store(1) を参照してください。

   サードパーティのヘルパーがインストールされている場合もあります。 ‘git
help -a’ の出力で ‘credential-*’ を検索し、個々のヘルパーのドキュメント
を参照してください。あなたが使いたいヘルパーを選んだら、その名前を
credential.helper 変数に入力することで、Gitにそのヘルパーを使用するよう
に指示できます。

  1. ヘルパーを探す。

          $ git help -a | grep credential-
          credential-foo

  2. その説明を読む。

          $ git help credential-foo

  3. Gitにそれを使用するように伝えます。

          $ git config --global credential.helper foo

CREDENTIAL CONTEXTS
*******************

Gitは、各資格情報がURLによって定義されたコンテキストを持っていると見なし
ます。このコンテキストは、コンテキスト固有の構成を検索するために使用され
、すべてのヘルパーに渡されます。ヘルパーは、これを安全なストレージへのイ
ンデックスとして使用できます。

   たとえば、 ‘https://example.com/foo.git’ にアクセスしていると想像して
ください。Gitが構成ファイルを調べてセクションがこのコンテキストに一致す
るかどうかを確認するとき、コンテキストが構成ファイル内のパターンのより具
体的なサブセットである場合、Gitは2つが一致すると見なします。たとえば、設
定ファイルに以下がある場合:

     [credential "https://example.com"]
             username = foo

   これはマッチします。両方のプロトコルが同じで、かつ、両方のホストが同
じであり、かつ、パターンURLはパス部分を気にしないからです。ただし、以下
のコンテキストは一致しません:

     [credential "https://kernel.org"]
             username = foo

   なぜならホスト名が異なるためです。 また、 ‘foo.example.com’ とは一致
しません。 Gitは、2つのホストが同じドメインの一部であるかどうかを考慮せ
ずに、ホスト名を正確に比較します。 同様に、 ‘http://example.com’ の設定
エントリは一致しません。Gitはプロトコルを正確に比較します。 ただし、
‘http.<url>.*’ オプションと同様に、ドメイン名やその他のパターンマッチン
グにワイルドカードを使用できます。

   パターンURLにパス部分が含まれている場合、これも完全に一致する必要があ
ります。コンテキスト ‘https://example.com/bar/baz.git’ は
(‘https://example.com’ 部分の照合に加えてパス部分も一致する)
‘https://example.com/bar/baz.git’ の設定エントリとは一致しますが、
‘https://example.com/bar’ 構成エントリとは一致しません。

CONFIGURATION OPTIONS
*********************

コンテキストのオプションは、 ‘credential.*’ (すべての資格情報に適用) ま
たは ‘credential.<url>.*’ のいずれかで構成できます。ここで、 <url> は上
記のコンテキストと一致します。

   以下のオプションは、どちらの場所でも使用できます:

helper
     外部資格情報ヘルパーの名前、および関連するオプション。ヘルパー名が
     絶対パスでない場合は、文字列 ‘git credential-’ が先頭に追加されます
     。結果の文字列はシェルによって実行されます(たとえば、これを ‘foo
     --option=bar’ に設定すると、シェルを介して ‘git credential-foo
     --option=bar’ が実行されます。例については使用するヘルパーのマニュ
     アルを参照してください。

     ‘credential.helper’ 構成変数のインスタンスが複数ある場合、各ヘルパ
     ーが順番に試行され、ユーザー名 または パスワード または 何も提供し
     ない 場合があります。Gitがユーザー名とパスワードの両方を取得すると
     、それ以上ヘルパーは試行されません。

     ‘credential.helper’ が空の文字列に設定されている場合、これによりヘ
     ルパーリストが空にリセットされます(したがって、空の文字列ヘルパーを
     構成し、その後に必要なヘルパーのセットを構成することで、優先度の低
     い構成ファイルによって設定されたヘルパーをオーバーライドできます)。

username
     URLに指定されていない場合のデフォルトのユーザー名。

useHttpPath
     デフォルトでは、Gitはhttp URLのパス部分を外部ヘルパーを介して照合す
     る価値があるとは見なしません。 これは、
     ‘https://example.com/foo.git’ に保存されている資格情報が
     ‘https://example.com/bar.git’ にも使用されることを意味します。これ
     らの場合を区別したい場合は、このオプションを「true」に設定してくだ
     さい。

CUSTOM HELPERS
**************

あなた独自のカスタムヘルパーを作成して、資格情報を保持している任意のシス
テムとインターフェイスすることができます。

   資格情報ヘルパーは、資格情報を長期ストレージとの間でフェッチまたは保
存するためにGitによって実行されるプログラムです(「長期」とは単一のGitプ
ロセスよりも単純に長いという意味です。たとえば、資格情報はメモリ内に数分
間、またはディスク上で無期限に保存される場合があります)。

   各ヘルパーは、構成変数 ‘credential.helper’ の単一の文字列で指定されま
す(その他 git-config(1) を参照)。文字列はGitによって、以下のルールを使用
して実行されるコマンドに変換されます:

  1. ヘルパー文字列が "!" で始まる場合、それはシェルスニペットと見なされ
     、 "!" の後のすべてが コマンドになります。

  2. それ以外の場合、ヘルパー文字列が絶対パスで始まる場合は、文字列がそ
     のままコマンドとして扱われます。

  3. それ以外の場合は、文字列 "git credential-" がヘルパー文字列の前に付
     加され、その結果がコマンドになります。

   結果のコマンドには「operation」引数が追加され(詳細は下記参照)、結果は
シェルによって実行されます。

   仕様の例を以下に示します:

     # run "git credential-foo"
     [credential]
             helper = foo

     # same as above, but pass an argument to the helper
     [credential]
             helper = "foo --bar=baz"

     # the arguments are parsed by the shell, so use shell
     # quoting if necessary
     [credential]
             helper = "foo --bar='whitespace arg'"

     # you can also use an absolute path, which will not use the git wrapper
     [credential]
             helper = "/path/to/my/helper --with-arguments"

     # or you can specify your own shell snippet
     [credential "https://example.com"]
             username = your_user
             helper = "!f() { test \"$1\" = get && echo \"password=$(cat $HOME/.secret)\"; }; f"

   一般的に、上記の ルール(3）は、ユーザーが指定するのが最も簡単です。資
格情報ヘルパーの作成者は、プログラムに "git-credential-$NAME" という名前
を付け、インストール中に ‘$PATH’ または ‘$GIT_EXEC_PATH’ に配置して、ユ
ーザーが ‘git config credential.helper $NAME’ を有効にできるようにするこ
とで、ユーザーを支援するように努める必要があります。

   ヘルパーが実行されると、コマンドラインに以下のいずれかの「操作」引数
が追加されます:

‘get’
     一致する資格情報が存在する場合は、それを返します。

‘store’
     ヘルパーに該当する場合は、資格情報を保存します。

‘erase’
     もしあれば、ヘルパーのストレージから一致する資格情報を削除します。

   資格情報の詳細は、ヘルパーの標準入力ストリームで提供されます。正確な
形式は、 ‘git credential’ 配管コマンドの 入力/出力形式 と同じです(詳細な
仕様については、 git-credential(1) の「INPUT/OUTPUT FORMAT」のセクション
を参照してください)。

   ‘get‘操作の場合、ヘルパーは標準出力の属性のリストを同じ形式で作成する
必要があります(一般的な属性については git-credential(1) を参照してくださ
い)。ヘルパーはサブセットを自由に作成できます。提供するのに役立つものが
ない場合は、値をまったく作成しません。提供された属性は、Gitの資格情報サ
ブシステムによってすでに知られている属性を上書きします。

   すべての属性を上書きすることが可能ですが、正常に動作するヘルパーは、
ユーザー名とパスワード以外の属性については上書きしないようにする必要があ
ります。

   ヘルパーが ‘true’ または ‘1’ の値で ‘quit’ 属性を出力した場合、それ以
上のヘルパーは参照されず、ユーザーにプロンプトも表示されません(資格情報
が提供されていない場合、操作は失敗します)。

   同様に、ユーザー名とパスワードの両方が提供されると、ヘルパーに相談す
ることはありません。

   ‘store’ または ‘erase’ 操作の場合、ヘルパーの出力は無視されます。

   ヘルパーが要求された操作の実行に失敗した場合、または潜在的な問題をユ
ーザーに通知する必要がある場合、ヘルパーは標準エラー出力に書き込むことが
あります。

   要求された操作(読み取り専用ストアなど)をサポートしていない場合は、要
求を黙って無視する必要があります。

   ヘルパーが他の操作を受け取った場合、ヘルパーはその要求を黙って無視す
る必要があります。これにより、将来の操作を追加する余地が残ります(古いヘ
ルパーは新しい要求を無視するだけです)。

GIT
***

Part of the git(1) suite

Name
****

gitcvs-migration — CVSユーザー向けGit

Synopsis
********

     git cvsimport *

DESCRIPTION
***********

GitはCVSとは異なり、すべての作業ツリーにはプロジェクト履歴の完全なコピー
を含むリポジトリが含まれており、他のどのリポジトリよりも決定的に重要であ
るリポジトリなどというものはありません。ただし、あなたはユーザーが同期で
きる単一の共有リポジトリを指定することで、CVSモデルをエミュレートできま
す。このドキュメントでは、その方法について説明します。

   Gitに関する基本的な知識が必要ですが、 gittutorial(7) と
gitglossary(7) を理解しておけば十分です。

共有リポジトリに対面する開発
****************************

ホスト foo.com の /pub/repo.git に共有リポジトリが設定されているとします
。次に、個々のコミッターは、以下コマンドを使用してssh経由で共有リポジト
リのクローンを作成できます:

     $ git clone foo.com:/pub/repo.git/ my-project
     $ cd my-project

   そしてハックハックします。 ‘cvs update’ に相当するものは以下です

     $ git pull origin

   これは、クローン操作以降に他の人が行った可能性のあるすべての作業をマ
ージします。作業ツリーにコミットされていない変更がある場合は、まずは
‘git pull’ を実行する前にコミットしてください。

     *Note*

     ‘pull’ コマンドは、最初の ‘git clone’ コマンドによって設定された構
     成変数によって、更新をどこから取得するかを認識しています。詳細につ
     いては、 ‘git config -l’ および git-config(1) のマニュアルページを
     参照してください。

   まずあなたの変更をコミットしてから、その後 ‘git push’ コマンドを使用
することで、あなたの変更を採用して共有リポジトリを更新できます:

     $ git push origin master

   それらのコミットを共有リポジトリに「プッシュ」します。他の誰かが最近
リポジトリを更新した場合、「cvs commit」のように「git push」が文句を言い
ます。その場合、プッシュを再試行する前に変更をプルする必要があります。

   上記の ‘git push’ コマンドで、更新するリモートブランチの名前
(‘master’)を指定します。これを省略した場合、 ‘git push’ は、ローカルリポ
ジトリ内のブランチと同じ名前を持つリモートリポジトリ内のブランチを更新し
ようとします。したがって、最後の「プッシュ」は以下のいずれかで実行できま
す:

     $ git push origin
     $ git push foo.com:/pub/project.git/

   上記は共有リポジトリに ‘master’ 以外のブランチがない限りは動作します
。

Setting Up a Shared Repository
******************************

私達は、プロジェクトのGitリポジトリをすでに作成しているか、または最初か
らまたはtarballから作成したか(gittutorial(7) を参照)、または既存のCVSリ
ポジトリからインポートした(次のセクションを参照)と想定しします。

   あなたの既存のリポジトリが /home/alice/myproject にあると想定します。
新しい「ベア」リポジトリ(作業ツリーのないリポジトリ)を作成し、あなたのプ
ロジェクトをそのリポジトリにフェッチします:

     $ mkdir /pub/my-repo.git
     $ cd /pub/my-repo.git
     $ git --bare init --shared
     $ git --bare fetch /home/alice/myproject master:master

   次に、すべてのチームメンバーにこのリポジトリへの読み取り/書き込みアク
セスを許可します。これを行う簡単な方法の1つは、すべてのチームメンバーに
リポジトリがホストされているマシンへのsshアクセスを許可することです。マ
シン上で完全なシェルを提供したくない場合は、ユーザーがGitのプッシュとプ
ルのみを実行できる制限付きシェルがあります。 git-shell(1) を参照してくだ
さい。

   コミッター全員を同じグループに入れ、リポジトリをそのグループで書き込
み可能にします:

     $ chgrp -R $group /pub/my-repo.git

   コミッターが作成するディレクトリが他のグループメンバーによって書き込
みおよび検索できるように、コミッターのumaskが027であることを確認してくだ
さい。

Importing a CVS archive
***********************

     *Note*

     これらの手順では、gitに付属している ‘git-cvsimport’ スクリプトを使
     用しますが、他のインポーターがより良い結果を提供する場合があります
     。他のオプションについては、 git-cvsimport(1) のthe noteを参照して
     ください。

   まず、 https://github.com/andreyvit/cvsps
(https://github.com/andreyvit/cvsps) からバージョン2.1以降のcvspsをイン
ストールし、あなたの $PATH に含まれていることを確認します。次に、あなた
が関心を持っているプロジェクトのチェックアウトされたCVS作業ディレクトリ
にcdして、 git-cvsimport(1) を実行します:

     $ git cvsimport -C <destination> <module>

   これにより、指定されたCVSモジュールのGitアーカイブがディレクトリ
<destination> に必要に応じて作成され、配置されます。

   インポートは、すべてのファイルのすべてのリビジョンをCVSからチェックア
ウトします。聞いた限りでは、cvsimportは1秒あたり平均約20個のリビジョンを
処理できるので、中規模のプロジェクトの場合、これには数分以上かかることは
ありません。大規模なプロジェクトやリモートリポジトリには時間がかかる場合
があります。

   メインtrunkは ‘origin’ という名前のGitブランチに保存され、追加のCVSブ
ランチは同じ名前のGitブランチに保存されます。メインtrunkの最新バージョン
も ‘master‘ブランチにチェックアウトされたままなので、すぐにあなた独自の
変更を追加し始めることができます。

   インポートはインクリメンタルであるため、来月再度呼び出すと、その間に
行われたCVS更新がフェッチされます。これが機能するためには、インポートさ
れたブランチを変更してはなりません。代わりに、独自の変更のために新しいブ
ランチを作成し、必要に応じてインポートされたブランチをマージします。

   あなたが共有リポジトリが必要な場合は、上記のように、あなたはインポー
トされたディレクトリのベアクローンを作成する必要があります。次に、増分イ
ンポートをマージするために、インポートされたディレクトリを別の開発クロー
ンとして扱います。

Advanced Shared Repository Management
*************************************

Gitでは、特定の箇所で実行される「フック」(hooks)と呼ばれるスクリプトを指
定できます。これらを使用して、たとえば、共有リポジトリへのすべてのコミッ
トをメーリングリストに送信することができます。 githooks(5) を参照してく
ださい。

   更新フックを使用して、よりきめ細かいアクセス許可を適用できます。
Controlling access to branches using update hooks
(howto/update-hook-example.html) (更新フックを使用したブランチへのアクセ
スの制御) を参照してください。

Providing CVS Access to a Git Repository
****************************************

開発者が引き続きCVSを使用できるように、Gitリポジトリへの真のCVSアクセス
を提供することも可能です。詳細については、 git-cvsserver(1) を参照してく
ださい。

Alternative Development Models
******************************

CVSユーザーは、開発者のグループに共通のリポジトリへのコミットアクセスを
与えることに慣れています。これまで見てきたように、これはGitでも可能です
。ただし、Gitの分散性により、他の開発モデルが利用可能になるため、最初に
、そのうちのどれがプロジェクトにより適しているかどうかを検討することをお
勧めします。

   たとえば、プロジェクトのプライマリ公開リポジトリを保守するために1人の
人を選択できます。次に、他の開発者がこのリポジトリのクローンを作成し、そ
れぞれが独自のクローンで作業します。満足のいく一連の変更がある場合、変更
を含むブランチからプルするように保守者に依頼します。保守者は変更を確認し
、プライマリリポジトリにプルします。プライマリリポジトリは、他の開発者が
調整を維持するために必要に応じてプルします。 Linuxカーネルおよびその他の
プロジェクトは、このモデルのバリエーションを使用します。

   少人数のグループでは、開発者は中央の保守者を必要とせずに、互いのリポ
ジトリから変更をプルするだけで済みます。

SEE ALSO
********

gittutorial(7), gittutorial-2(7), gitcore-tutorial(7), gitglossary(7),
giteveryday(7), The Git User’s Manual (user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

gitdiffcore — diff出力の微調整

Synopsis
********

     git diff *

DESCRIPTION
***********

diffコマンド ‘gitdiff-index’ と ‘git diff-files’ と ‘git diff-tree’ は、
‘diff’ 出力を表示する前に、従来とは異なる方法で検出した差異を操作するよ
うに指示できます。この操作を総称して「diffcore変換」(diffcore
transformation)と呼びます。この短いノートでは、それらが何であるか、およ
びそれらを使用して、従来の種類よりも理解しやすい ‘diff’ 出力を生成する方
法について説明します。

The chain of operation
**********************

‘git diff-{asterisk}’ ファミリの仕事は、まずは2つのファイルセットを比較
することです:

   • ‘git diff-index’ は、 (‘--cached’ フラグが使用されていない場合)ツリ
     ーオブジェクトと作業ディレクトリの内容を比較するか、または(‘
     –cached‘ フラグが使用されている場合)ツリーオブジェクトとインデック
     スファイルの内容を比較します。

   • ‘git diff-files’ は、インデックスファイルと作業ディレクトリの内容を
     比較します。

   • ‘git diff-tree’ は、2つのツリーオブジェクトの内容を比較します。

   これらすべての場合において、コマンド自体は、最初にオプションで、コマ
ンドラインで指定されたパススペックによって2つのファイルの組を限定し、結
果として得られる2つのファイルの組の対応するパスを比較します。

   パススペックは、diffが動作するワールドを制限するために使用されます。
これらは、指定されたパス名の組の外側にあるファイルペア(filepairs)を削除
します。例えば。ファイルペアの入力組が含まれている場合:

     :100644 100644 bcd1234... 0123456... M junkfile

   しかし、コマンドの呼び出しが ‘git diff-files myfile’ の場合、
‘myfile’ のみが考慮されているため、junkfileエントリがリストから削除され
ます。

   比較の結果は、これらのコマンドから、 ‘-p｀ オプションが使用されていな
い場合に出力されるものと同様の形式で、内部的に「diffcore」と呼ばれるもの
に渡されます。例えば

     in-place edit  :100644 100644 bcd1234... 0123456... M file0
     create         :000000 100644 0000000... 1234567... A file4
     delete         :100644 000000 1234567... 0000000... D file5
     unmerged       :000000 000000 0000000... 0000000... U file6

   diffcoreメカニズムには、そのような比較結果のリストが提供され(それぞれ
が「ファイルペア」(filepair)と呼ばれますが、この時点ではそれぞれ1つのフ
ァイルについて話します)、そのようなリストを別のリストに変換します。現在
、そのような変換(transformations)は5つあります:

   • diffcore-break

   • diffcore-rename

   • diffcore-merge-broken

   • diffcore-pickaxe

   • diffcore-order

   • diffcore-rotate

   これらは順番に適用されます。 ‘git diff-{asterisk}’ コマンド群の探索の
ファイルペアのセットは、diffcore-breakへの入力として使用されます。
diffcore-breakからの出力は、次の変換への入力として使用されます。そして、
最終結果が出力ルーチンに渡され、diff-raw形式(マニュアルの ‘git
diff-{asterisk}’ コマンド の「Output format」セクションを参照)または
diff-patch形式のいずれかが生成されます。

diffcore-break: 完全な書き換えを分割するため
********************************************

操作チェーンの2番目の変換(transformation)はdiffcore-breakで、 ‘git
diff-{asterisk}’ コマンド群の ‘-B’ オプションによって制御されます。これ
は、「完全な書き換え」を表すファイルペアを検出し、そして、そのようなファ
イルペアを削除と作成を表す2つのファイルペアに分割するために使用されます
。例えば、入力に以下のファイルペアが含まれている場合:

     :100644 100644 bcd1234... 0123456... M file0

   そして、ファイル "file0" が完全に書き換えられたことを検出すると、以下
のように変更されます:

     :100644 000000 bcd1234... 0000000... D file0
     :000000 100644 0000000... 0123456... A file0

   ファイルペアを切断する(break)目的で、diffcore-breakは、変更前後のファ
イルの内容(つまり、上記の例では、SHA-1コンテンツIDとして ‘bcd1234...’ と
‘0123456...’ を持つコンテンツ)の間の変更の程度を調べます。元のコンテンツ
の削除と新しい素材の挿入の量が合計され、「ブレークスコア」(break score)を
超えると、ファイルペアが2つに分割されます。ブレークスコアのデフォルトは
、元のサイズと結果の小さい方のサイズの50%であり(つまり、編集によってファ
イルが縮小される場合は、結果のサイズが使用されます。編集によってファイル
が長くなる場合は、元のサイズが使用されます)、 ‘-B’ オプションの後に数字
を付けることでカスタマイズできます(たとえば、 ‘-B75’ で75%にするように指
示します)。

diffcore-rename: 名前変更とコピーを検出するため
***********************************************

この変換(transformation)は、名前変更とコピーを検出するために使用され、
‘git diff-{asterisk}’ コマンド群の ‘-M’ オプション(名前変更検出用）と
‘-C’ オプション(コピーも検出するため)によって制御されます。入力にこれら
のファイルペアが含まれている場合:

     :100644 000000 0123456... 0000000... D fileX
     :000000 100644 0000000... 0123456... A file0

   ここで、削除されたファイルfileXの内容は、作成されたファイルfile0の内
容と十分に類似しているため、名前変更検出はこれらのファイルペアをマージし
て以下を作成します:

     :100644 100644 0123456... 0123456... R100 fileX file0

   ‘-C’ オプションを使用すると、変更されたファイルと削除されたファイル(
‘--find-copies-harder’ オプションが使用されている場合は、変更されていな
いファイルも)の元の内容が、名前変更/コピー 操作のソースファイルの候補と
見なされます。入力がこれらのファイルペアのようなものである場合、変更され
たファイルfileYと新しく作成されたファイルfile0について以下のようになりま
す:

     :100644 100644 0123456... 1234567... M fileY
     :000000 100644 0000000... bcd3456... A file0

   fileYの元の内容とfile0の結果の内容が比較され、それらが十分に類似して
いる場合は、以下のように変更されます:

     :100644 100644 0123456... 1234567... M fileY
     :100644 100644 0123456... bcd3456... C100 fileY file0

   名前の変更とコピーの検出の両方で、diffcore-breakで使用されるのと同じ
「変更の範囲」(extent of changes)アルゴリズムを使用して、2つのファイルが
「十分に類似」しているかどうかを判断し、デフォルトの50%とは異なる類似ス
コアを使用するようにカスタマイズできます。 ‘-M’ または ‘-C’ オプションの
後に番号を付けます(たとえば、 ‘-M8’ で 8/10 = 80% にするように指示します
)。

   注意: 名前変更検出がオンで、コピーとブレークの両方の検出がオフの場合
、名前変更検出は、ファイル名を同じに保ちながらファイルがディレクトリ間で
移動されるかどうかを最初にチェックする予備ステップを追加することに注意し
てください。 別のディレクトリから削除された同じ名前のファイルと内容が十
分に類似しているファイルがディレクトリに追加されている場合、それらを名前
変更としてマークし、後の2次ステップ(一致しないすべてのファイルをペアごと
に比較して、コンテンツの類似性が最も高いことによって決定される「最良の」
一致を見つけるステップ)から除外します。したがって、たとえば、削除された
docs/ext.txt と追加された docs/config/ext.txt が十分に類似している場合、
それらは名前変更としてマークされ、削除された docs/ext.txt にさらに類似し
ている可能性のある、追加された docs/ext.md が後のステップで名前変更先と
見なされないようにします。 このため、予備の「同じファイル名に一致」ステ
ップでは、少し高いしきい値を使用してファイルペアを名前変更としてマークし
、他の候補をより適切に一致させることを検討しなくなります。 この予備ステ
ップでは、ファイルごとに最大で1つの比較が行われます。したがって、正確な
名前変更が検出された後、ディレクトリ階層全体にext.txtファイルがいくつか
残っている場合は、これらのファイルのこの準備手順をスキップできます。

   注意: ‘-C’ オプションを ‘--find-copies-harder’ オプションとともに使用
すると、 ‘git diff-{asterisk}’ コマンド群は、変更されていないファイルペ
アと変更されたファイルペアをdiffcoreメカニズムに送ります。これにより、コ
ピー検出器は、ファイルの速度を低下させる代わりに、変更されていないファイ
ルをコピーソース候補と見なすことができます。 ‘--find-copies-harder’ がな
いと、 ‘git diff-{asterisk}’ コマンド群は、コピーされたファイルがたまた
ま同じチェンジセットで変更された場合にのみコピーを検出できます。

diffcore-merge-broken: 完全な書き換えを元に戻すため
***************************************************

この変換は、diffcore-breakによって分割したファイルペアをマージするために
使用され、 diffcore-rename によって rename/copy に変換されず、単一の変更
に戻されます。これは、diffcore-breakが使用されている場合は常に実行されま
す。

   分割したファイルペアをマージする目的で、 diffcore-break および
diffcore-rename で使用されるものとは異なる「変更の範囲」の計算を使用しま
す。オリジナルからの削除のみをカウントし、挿入はカウントしません。100行
のドキュメントから10行だけを削除した場合、新しい1000行のドキュメントを作
成するために910行を追加しても、完全な書き換えは行われたとは見なしません
。 diffcore-break は、 diffcore-renameがそのようなファイルペアを 名前変
更/コピー 検出の候補と見なすのを助けるためにそのような場合のを分割します
が、その方法で分割したファイルペアが他のファイルペアと一致して 名前変更
/コピー を作成しなかった場合、この変換でそれらをマージして「元の変更」に
戻します 。

   「変更の範囲」パラメータは、 ‘-B’ に2番目の数値を指定することで、デフ
ォルトの80%から微調整できます(つまり、元のマテリアルの80%以上が削除され
ない限り、分割されたペアは1つの変更にマージされます)。以下のように指定で
きます:

   • ‘-B50/60’ (diffcore-breakに50%の「ブレークスコア」を与え、
     diffcore-merge-brokenに60%を与えます)。

   • ‘-B/60’ (上記と同じです。diffcore-breakのデフォルトは50%であるため
     )。

   注意:以前の実装では、個別の作成パッチと削除パッチとして分割したペアが
残っていたことに注意してください。これは不必要なハックであり、最新の実装
では常にすべての分割されたペアが変更にマージされます。ただし、結果のパッ
チ出力は、 ‘-’ で始まる古いバージョンのコンテンツ全体を表示することによ
り、このような完全な書き換えの場合に簡単に確認できるように、異なる形式に
なっています。その後に、接頭辞 ‘+’ が付いた新しいバージョンのコンテンツ
全体が続きます。

diffcore-pickaxe: 指定の文字列(string)の追加/削除の検知のため
*************************************************************

この変換により、ファイルペアの組が、特定の方法でプリイメージとポストイメ
ージの間で指した文字列を変更するものに制限されます。 ‘-S<テキストのブロ
ック>’ および ‘-G<正規表現>’ オプションは、これらの文字列を検索するさま
ざまな方法を指定するために使用されます。

   ‘-S<テキストブロック>’ は、指定されたテキストのブロックの出現回数がプ
リイメージとポストイメージで異なるファイルペアを検出します。定義上、ファ
イル内の移動は検出されません。また、チェンジセットが対象の文字列に影響を
与えずにファイルを大規模に移動すると、通常どおりdiffcore-renameが開始さ
れ、‘-S’ はファイルペアを省略します(その文字列の出現回数は、名前変更で検
出されたファイルペアで変更されなかったため)。 ‘--pickaxe-regex’ と一緒に
使用する場合、<テキストブロック>は、リテラル文字列ではなく、マッチする拡
張POSIX正規表現として扱います。

   ‘-G<正規表現>’ (grep文法)は、指定された正規表現にマッチする行が追加ま
たは削除されたテキスト差分を持つファイルペアを検出します。これは、ノイズ
であるファイル内の移動(またはrename-detectionが同じファイルと見なすもの
)を検出することを意味します。実装はdiffを2回実行してgrepsしますが、これ
は非常にコストがかかる可能性があります。高速化のため、textconvフィルタが
ないバイナリファイルは無視されます。

   ‘-S’ または ‘-G’ を ‘--pickaxe-all’ なしで使用すると、それぞれの基準
に一致するファイルペアのみが出力に保持されます。 ‘--pickaxe-all’ が使用
されている場合、1つのファイルペアでもチェンジセット内のそれぞれの基準に
一致すると、チェンジセット全体が保持されます。この振る舞いは、チェンジセ
ット全体のコンテキストでの変更のレビューを容易にするために設計されていま
す。

diffcore-order: ファイル名に基づいて出力をソートするため
********************************************************

これは、ユーザー(またはプロジェクト)の好みに応じてファイルペアを並べ替え
るために使用され、 ‘git diff-{asterisk}’ コマンド群の ‘-O’ オプションに
よって制御されます。

   これは、各行がシェルグロブパターンであるテキストファイルを取ります。
ファイルの前の行のグロブパターンに一致するファイルペアは、後の行に一致す
るファイルペアの前に出力され、どのグロブパターンにも一致しないファイルペ
アは最後に出力されます。

   例として、コアGitの一般的な orderfile おそらく以下のようになります:

     README
     Makefile
     Documentation
     *.h
     *.c
     t

diffcore-rotate: 出力開始パス(path)を変更するため
*************************************************

この変換は1つのパス名を取り、ファイルペアのセットをローテーションして、
指定されたパス名のファイルペアが最初に来るようにします。オプションで、そ
の前にあるパスを破棄します。これは、 ‘--skip-to’ および ‘--rotate-to’ オ
プションを実装するために使用されます。指定されたパス名がファイルペアのセ
ットにない場合はエラーになりますが、 ‘git log ` ファミリーのコマンドで使
用するとエラーになることはありません。 `git log’ コマンドで表示されるす
べてのコミットによって特定のパスが変更されることを期待するのは不合理だか
らです。このため、 ‘git log’ と一緒に使用すると、指定されたパス名と同じ
ように並べ替えられるファイルペア、または最初に並べ替えられるファイルペア
が出力の開始場所になります。

   この変換をdiffcore-orderと組み合わせて使用すると、diffcore-orderが有
効な場合、この変換への入力がソートされない可能性があるため、予期しない結
果が生成されます。

SEE ALSO
********

git-diff(1), git-diff-files(1), git-diff-index(1), git-diff-tree(1),
git-format-patch(1), git-log(1), gitglossary(7), The Git User’s Manual
(user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

giteveryday — Git日常利用に役立つ最小限のコマンドセット

Synopsis
********

Git日常利用の為の20程度のコマンド

DESCRIPTION
***********

日常のGit利用に役立つコマンドの小さなセットを説明するため、Gitユーザーを
大きく4つのカテゴリに分類します。

   • 開発者個人(スタンドアローン) (see [STANDALONE]) のコマンドは 一
     人で作業する人でも、コミットする人には不可欠です。

   • 他の人と一緒に作業する場合は、開発者個人(グループプロジェクト参加者
     ) (see [PARTICIPANT]) セクションにリストされているコマンドも必
     要になります。

   • インテグレーター (see [INTEGRATOR]) 役の人々は、 上記に加えて更
     に幾つかのコマンドを学ぶ必要があります。

   • リポジトリ管理 (see [ADMINISTRATION]) コマンドは、 Gitリポジト
     リの管理と提供を担当するシステム管理者向けです。

Individual Developer (Standalone)
*********************************

独立した個々の開発者は、他の人とパッチを交換せず、以下のコマンドを使用し
て、単一のリポジトリで単独で作業します。

   • git-init(1) 新しいリポジトリを作成します。

   • git-log(1) 何が起こったのか確認します。

   • git-switch(1) と git-branch(1) ブランチを切り替えます。

   • git-add(1) インデックスファイルを管理します。

   • git-diff(1) と git-status(1) を使用して、あなたは何をしている最中か
     確認します。

   • git-commit(1) を使用して、現在のブランチを進めます。

   • git-restore(1) を使用して、変更を元に戻します(undo)。

   • git-merge(1) は、ローカルブランチ間でマージします。

   • git-rebase(1) は、トピックブランチを保守します。

   • git-tag(1) を使用して、既知のポイントをマークします。

Examples
========

新しいリポジトリの開始点としてtarballを使用します
          $ tar zxf frotz.tar.gz
          $ cd frotz
          $ git init
          $ git add . (1)
          $ git commit -m "import of frotz source tree."
          $ git tag v2.43 (2)

     See (1).
          あなたが現在いるディレクトリ下のすべてをaddします。

     See (2).
          軽量で注釈のないタグを作成します。

トピックブランチを作成して開発します
          $ git switch -c alsa-audio (1)
          $ edit/compile/test
          $ git restore curses/ux_audio_oss.c (2)
          $ git add curses/ux_audio_alsa.c (3)
          $ edit/compile/test
          $ git diff HEAD (4)
          $ git commit -a -s (5)
          $ edit/compile/test
          $ git diff HEAD^ (6)
          $ git commit -a --amend (7)
          $ git switch master (8)
          $ git merge alsa-audio (9)
          $ git log --since='3 days ago' (10)
          $ git log v2.43.. curses/ (11)

     See (1).
          新しいトピックブランチを作成します。

     See (2).
          ‘curses/ux_audio_oss.c’ で失敗した変更を元に戻します(revert)。

     See (3).
          あなたは新しいファイルを追加したかどうかをGitに伝える必要があ
          ります。 後で ‘git commit -a’ を実行すると、削除と変更が捕捉さ
          れます。

     See (4).
          コミットしようとしている変更を確認します。

     See (5).
          あなたがテストしたと署名(sign-off)して、全てをコミットします。

     See (6).
          前のコミットを含むすべての変更を確認します。

     See (7).
          元のメッセージを流用して、以前のコミットを修正し、すべての新し
          い変更を追加します。

     See (8).
          masterブランチに切り替えます。

     See (9).
          トピックブランチをあなたのmasterブランチへマージします。

     See (10).
          コミットログを確認します。出力を制限する他の形式を組み合わせて
          、 ‘-10’ (最大10個のコミットを表示）、 ‘--until=2005-12-10’ な
          どを含めることができます。

     See (11).
          ‘v2.43’ タグ以降 、‘curses/’ ディレクトリにあるものに影響を与
          える変更のみを表示します。

Individual Developer(Participant;グループプロジェクト参加者)
************************************************************

グループプロジェクトの参加者として作業する開発者個人は、他の人と連絡する
方法を学ぶ必要があり、スタンドアロンの開発者個人が必要とするコマンドに加
えて、これらのコマンドを使用します。

   • git-clone(1) をアップストリームから実行して、あなたのローカルリポジ
     トリを準備します。

   • git-pull(1) と git-fetch(1) により、 "origin" をアップストリームと
     共に最新の状態に保ちます。

   • CVSスタイルの共有リポジトリワークフローを採用している場合、共有リポ
     ジトリのために git-push(1) を使います。

   • Linuxカーネルスタイルのパブリックフォーラムワークフローを採用してい
     る場合に、 git-format-patch(1) は電子メール送信を準備します。

   • git-send-email(1) を使用して、MUAによる破損なしに電子メール送信を送
     信します。

   • git-request-pull(1) を使用して、あなたのアップストリームがプルする
     変更の概要を作成します。

Examples
========

アップストリームのクローンを作成して作業します。 変更をアップストリームに送ります。
          $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
          $ cd my2.6
          $ git switch -c mine master (1)
          $ edit/compile/test; git commit -a -s (2)
          $ git format-patch master (3)
          $ git send-email --to="person <email@example.com>" 00*.patch (4)
          $ git switch master (5)
          $ git pull (6)
          $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
          $ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
          $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
          $ git reset --hard ORIG_HEAD (10)
          $ git gc (11)

     See (1).
          master から新ブランチ ‘mine’ を作成し、 ‘mine’ でチェックアウ
          トします。

     See (2).
          必要に応じてこの作業を繰り返します。

     See (3).
          masterに関連して、あなたのブランチからパッチを抽出します。

     See (4).
          そしてそれらを電子メールで送ります。

     See (5).
          ‘master’ に戻り、最新情報を確認する準備をします

     See (6).
          ‘git pull’ はデフォルトで ‘origin’ からフェッチし、現在のブラ
          ンチにマージします。

     See (7).
          プルした直後に、前回チェックしてから上流で行われた変更を、関心
          のある領域でのみ確認します。

     See (8).
          (不明な場合)外部リポジトリのブランチ名を確認します。

     See (9).
          指定のリポジトリから、指定のブランチ ‘ALL’ をフェッチしマージ
          します。

     See (10).
          プルしたのを元に戻します。(revert)

     See (11).
          ガベージコレクションは、元に戻されたプルからゴミオブジェクト
          (leftover objects)を収集します。

別のリポジトリにプッシュします。
          satellite$ git clone mothership:frotz frotz (1)
          satellite$ cd frotz
          satellite$ git config --get-regexp '^(remote|branch)\.' (2)
          remote.origin.url mothership:frotz
          remote.origin.fetch refs/heads/*:refs/remotes/origin/*
          branch.master.remote origin
          branch.master.merge refs/heads/master
          satellite$ git config remote.origin.push \
                     +refs/heads/*:refs/remotes/satellite/* (3)
          satellite$ edit/compile/test/commit
          satellite$ git push origin (4)

          mothership$ cd frotz
          mothership$ git switch master
          mothership$ git merge satellite/master (5)

     See (1).
          マザーシップ機には、ホームディレクトリの下にfrotzリポジトリが
          あります。そこからクローンを作成して、サテライト機でリポジトリ
          を開始します。

     See (2).
          cloneは、これらの構成変数をデフォルトで設定します。 これは、マ
          ザーシップ機のブランチをフェッチしてローカルの
          ‘remotes/origin/*’ リモートトラッキングブランチに保存するため
          に ‘git pull’ を手配します。

     See (3).
          すべてのローカルブランチをマザーシップ機の対応するブランチにプ
          ッシュするために ‘git push’ を手配します。

     See (4).
          pushは、マザーシップ機の ‘remotes/satellite/*’ リモートトラッ
          キングブランチへすべての作業をstashします。これをバックアップ
          方法として使用できます。同様に、あなたはそのマザーシップ機があ
          なたから「フェッチされた」ふりをすることができます(アクセスが
          一方的な場合に便利です)。

     See (5).
          マザーシップ機で、サテライト機で行われた作業をmasterブランチに
          マージします。

Branch off of a specific tag.
          $ git switch -c private2.6.14 v2.6.14 (1)
          $ edit/compile/test; git commit -a
          $ git checkout master
          $ git cherry-pick v2.6.14..private2.6.14 (2)

     See (1).
          よく知られている(ただし多少遅れている)タグに基づいてプライベー
          トブランチを作成します。

     See (2).
          forward port all changes in ‘private2.6.14’ branch to ‘master’
          branch without a formal "merging".  Or longhand + ‘git
          format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3
          -k’

   別の参加者送信メカニズム(participant submission mechanism)は、 ‘git
request-pull’ または pull-request メカニズム(GitHub（www.github.com）で
使用されているものなど)を使用して、あなたの貢献をあなたのアップストリー
ムに通知します。

インテグレーター
****************

グループプロジェクトのインテグレーターとして機能するかなり中心的な人物は
、他の人が行った変更を受け取り、それらをレビューして統合し、参加者が必要
とするコマンドに加えて以下のコマンドを使用して、他の人が使用できるように
結果を公開します。

   このセクションのコマンドは、GitHub（www.github.com）で ‘git
request-pull’ または pull-request に応答するユーザーが、他のユーザーの作
業を履歴に統合するために使用することもできます。 リポジトリの部分担当サ
ブリーダー(sub-area lieutenant)は、参加者とインテグレーターの両方として
機能します。

   • git-am(1) を使用して、寄稿者から電子メールで送信されて来たパッチを
     適用します。

   • git-pull(1) を使用して、信頼できる部分担当サブリーダーの分からマー
     ジします。

   • git-format-patch(1) を準備し、提案された代替案を寄稿者に送信します
     。

   • git-revert(1) は、失敗したコミットを元に戻します。(revert)

   • git-push(1) を使用して、最先端を公開します。

Examples
========

典型的なGitインテグレーターの一日。
          $ git status (1)
          $ git branch --no-merged master (2)
          $ mailx (3)
          & s 2 3 4 5 ./+to-apply
          & s 7 8 ./+hold-linus
          & q
          $ git switch -c topic/one master
          $ git am -3 -i -s ./+to-apply (4)
          $ compile/test
          $ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5)
          $ git switch topic/one && git rebase master (6)
          $ git switch -C seen next (7)
          $ git merge topic/one topic/two && git merge hold/linus (8)
          $ git switch maint
          $ git cherry-pick master~4 (9)
          $ compile/test
          $ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
          $ git fetch ko && for branch in master maint next seen (11)
              do
                  git show-branch ko/$branch $branch (12)
              done
          $ git push --follow-tags ko (13)

     See (1).
          どちらかといえば、あなたが途中で何をしていたかを見てください。

     See (2).
          ‘master’ にマージされていないのがどのブランチかを確認してくだ
          さい。他の統合ブランチ(‘maint’ 、‘ next‘ 、 ‘seen’)についても
          同様です。

     See (3).
          メールを読んだり、該当するものを保存したり、準備が整っていない
          ものを保存したりします(他のメールリーダーも利用できます)。

     See (4).
          あなたの署名伴って、対話的にそれらを適用します。

     See (5).
          必要に応じてトピックブランチを作成し、再度署名して適用します。

     See (6).
          masterにマージされていない、または安定したブランチの一部として
          公開されていない内部トピックブランチをリベースします。

     See (7).
          next から 毎回 ‘seen’ を再スタートします。

     See (8).
          そして、まだ調理中のトピックブランチをバンドルします。

     See (9).
          深刻な修正をバックポートします。

     See (10).
          署名付きタグを作成します。

     See (11).
          masterがすでにpushされたものを超えて誤って巻き戻されていないこ
          とを確認してください。

     See (12).
          ‘git show-branch’ からの出力では、 ‘master’ には ‘ko/master’ が
          持つすべてのものが含まれ、 ‘next’ には ‘ko/next’ が持つすべて
          のものが含まれる必要があります。

     See (13).
          プッシュされた履歴を指す新しいタグとともに、最先端をプッシュし
          ます。

   この例では、 ‘ko’ の省略形はkernel.orgにあるGitメンテナのリポジトリを
指しており、以下のようになります:

     (in .git/config)
     [remote "ko"]
             url = kernel.org:/pub/scm/git/git.git
             fetch = refs/heads/*:refs/remotes/ko/*
             push = refs/heads/master
             push = refs/heads/next
             push = +refs/heads/seen
             push = refs/heads/maint

リポジトリ管理
**************

リポジトリ管理者は、以下のツールを使用して、開発者によるリポジトリへのア
クセスを設定および維持します。

   • git-daemon(1) を使用して、リポジトリからの匿名ダウンロードを許可し
     ます。

   • git-shell(1) は、共有中央リポジトリユーザーの「制限付きログインシェ
     ル」として使用できます。

   • git-http-backend(1) は、フェッチサービスとプッシュサービスの両方を
     可能にする Git-over-HTTP(スマートhttp)のサーバー側実装を提供します
     。

   • gitweb(1) は、GitリポジトリへのWebフロントエンドを提供します。これ
     は、 git-instaweb(1) スクリプトを使用して設定できます。

   update hook howto (howto/update-hook-example.html) には、共有中央リポ
ジトリを管理する良い例があります。

   さらに、以下のような他の広く展開されているホスティング、ブラウジング
、レビューソリューションがいくつかあります:

   • gitolite 、 gerrit code review 、 cgit 、その他。

Examples
========

‘/etc/services’ では以下を前提としています
          $ grep 9418 /etc/services
          git             9418/tcp                # Git Version Control System

Run git-daemon to serve /pub/scm from inetd.
          $ grep git /etc/inetd.conf
          git     stream  tcp     nowait  nobody \
            /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

     実際の行は1行で書く必要があります。

Run git-daemon to serve /pub/scm from xinetd.
          $ cat /etc/xinetd.d/git-daemon
          # default: off
          # description: The Git server offers access to Git repositories
          service git
          {
                  disable = no
                  type            = UNLISTED
                  port            = 9418
                  socket_type     = stream
                  wait            = no
                  user            = nobody
                  server          = /usr/bin/git-daemon
                  server_args     = --inetd --export-all --base-path=/pub/scm
                  log_on_failure  += USERID
          }

     あなたの xinetd(8) のドキュメントとセットアップを確認してください。
     これはFedoraシステムからのものです。その他は異なる場合があります。

Give push/pull only access to developers using git-over-ssh.
     例えばこのように使います: ‘$ git push/pull
     ssh://host.xz/pub/scm/project’

          $ grep git /etc/passwd (1)
          alice:x:1000:1000::/home/alice:/usr/bin/git-shell
          bob:x:1001:1001::/home/bob:/usr/bin/git-shell
          cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
          david:x:1003:1003::/home/david:/usr/bin/git-shell
          $ grep git /etc/shells (2)
          /usr/bin/git-shell

     See (1).
          ログインシェルは /usr/bin/git-shell に設定されており、 ‘git
          push’ と ‘git pull’ 以外は許可されていません。ユーザーはマシン
          へのsshアクセスを必要とします。

     See (2).
          多くのディストリビューションでは、 /etc/shells にはログインシ
          ェルとして使用されるものをリストする必要があります。

CVS-style shared repository.
          $ grep git /etc/group (1)
          git:x:9418:alice,bob,cindy,david
          $ cd /home/devo.git
          $ ls -l (2)
            lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
            drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
            -rw-rw-r--   1 david git    84 Dec  4 22:40 config
            -rw-rw-r--   1 david git    58 Dec  4 22:40 description
            drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
            -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
            drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
            drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
            drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
            drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
          $ ls -l hooks/update (3)
            -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
          $ cat info/allowed-users (4)
          refs/heads/master       alice\|cindy
          refs/heads/doc-update   bob
          refs/tags/v[0-9]*       david

     See (1).
          開発者を同じgitグループに配置します。

     See (2).
          そして、共有リポジトリをグループで書き込み可能にします。

     See (3).
          ブランチポリシーの制御には、 Documentation/howto/ の Carl によ
          る update-hook の例を使用してください。

     See (4).
          alice と cindy はmasterにプッシュでき、bobだけがdoc-updateにプ
          ッシュできます。 davidはリリースマネージャーであり、バージョン
          タグを作成してプッシュできる唯一の人物です。

GIT
***

Part of the git(1) suite

Name
****

gitfaq — Gitの使用に関するよくある質問(FAQ)

Synopsis
********

gitfaq

DESCRIPTION
***********

このFAQの例では、 ‘bash’ や ‘dash’ などの標準のPOSIXシェルと、ホスティン
グプロバイダー ‘git.example.org’ にアカウント ‘author’ を持つユーザー A
U Thor を想定しています。

Configuration
*************

‘user.name’ には何を入れるべきですか？
     個人名、通常は名前とファミリーネームを使用した形式を入力する必要が
     あります。たとえば、Gitの現在のメンテナは "Junio C Hamano" (濱野 純
     )を使用しています。 これは、コミットするたびに保存される名前の部分
     になります。

     この構成は、リモートサービスへの認証には影響しません。 そのためには
     、 git-config(1) の ‘credential.username’ を参照してください。

‘http.postBuffer’ は実際には何をしますか？
     このオプションは、HTTPまたはHTTPSを介してデータをリモートにプッシュ
     するときにGitが使用するバッファーのサイズを変更します。データがこの
     サイズより大きい場合、GitのHTTPサポートを処理するlibcurlは、プッシ
     ュされたデータのサイズが事前にわからないため、チャンク転送エンコー
     ディングを使用します。

     リモートサーバーまたは中間のプロキシが、(チャンク転送エンコーディン
     グを導入している) HTTP/1.1 をサポートしていないか、チャンクデータが
     壊れていることがわかっている場合を除いて、この値をデフォルトサイズ
     のままにしておくことは問題ありません。これは一般的なプッシュ問題の
     解決策として、(誤って)提案されることがよくありますが、ほとんどすべ
     てのサーバーとプロキシが少なくとも HTTP/1.1 はサポートしているため
     、この値を上げてもほとんどのプッシュ問題は解決されません。 HTTP/1.1
     とチャンク転送エンコーディングを正しくサポートしていなかったサーバ
     ーまたはプロキシは、大量のトラフィックを遮断するため、今日のインタ
     ーネットでは無用の長物です。

     注意: この値を増やすと、GitがHTTPまたはHTTPSを介して行うすべての関
     連プッシュで使用されるメモリが増えることに注意してください。これは
     、すべてが使用されているかどうかに関係なく、バッファ全体が割り当て
     られるためです。したがって、別の値が必要であることが確実でない限り
     、デフォルトのままにしておくことをお勧めします。

別のエディタを構成するにはどうすればよいですか？
     Git専用のエディターを指定していない場合は、デフォルトで、「VISUAL」
     または「EDITOR」環境変数を使用して構成したエディターが使用されます
     。どちらも指定されていない場合は、システムのデフォルト(通常は「vi」
     )が使用されます。 ‘vi’ は使いにくい、または別のエディターを好む人も
     いるため、使用するエディターを変更することが望ましい場合があります
     。

     エディタを必要とするプログラム用に、あなたがエディタを構成したい場
     合、シェル構成(つまり、 ‘~/.bashrc’ とか ‘~/.zshenv’)を編集して、
     ‘EDITOR’ または ‘VISUAL’ 環境変数に適切な値に設定する行を含めること
     ができます。たとえば、エディタ ‘nano’ が必要な場合は、以下のように
     記述できます:

          export VISUAL=nano

     あなたがGit専用のエディタを構成したい場合は、 ‘core.editor’ 構成 ま
     たは ‘GIT_EDITOR’ 環境変数を設定できます。これらのオプションが参照
     される順序の詳細については git-var(1) を参照してください。

     注意: いずれの場合も、エディタの値はシェルに渡されるため、スペース
     を含む引数は適切に引用符で囲む必要があることに注意してください。さ
     らに、エディタが呼び出されたとき、通常ターミナルからデタッチするタ
     イプのエディタ場合は、それを行わないようにする引数を指定して指定す
     る必要があります。そうしないと、Gitはエディタでの変更を認識しません
     。 Windowsでこれらの問題の両方に対処する構成の例は、構成
     ‘"C:\Program Files\Vim\gvim.exe" --nofork’ です。これは、空白を含ん
     だファイル名をクォートし、プロセスのバックグラウンド実行を回避する
     ため ‘--nofork’ オプションを指定します。

Credentials
***********

HTTPでプッシュするときに資格情報を指定するにはどうすればよいですか？
     これを行う最も簡単な方法は、 ‘credential.helper’ 構成を介して資格情
     報ヘルパーを使用することです。ほとんどのシステムは、システム資格情
     報マネージャーと統合するための標準的な選択肢を提供します。たとえば
     、Git for Windowsは「wincred」資格情報マネージャーを提供し、macOSは
     「osxkeychain」資格情報マネージャーを提供し、標準デスクトップ環境を
     備えたUnixシステムは「libsecret」資格情報マネージャーを使用できます
     。 これらはすべて、パスワードまたはトークンを安全に保つために暗号化
     されたストアに資格情報を保存します。

     さらに、ホームディレクトリのファイルに保存する ‘store’ 資格情報マネ
     ージャー、または資格情報を永続的に保存しないが、特定の時間、資格情
     報の入力を求められないようにする ‘cache’ 資格情報マネージャーを使用
     できます。

     プロンプトが表示されたら、パスワードを入力することもできます。 URLに
     パスワード(パーセントエンコードする必要があります)を配置することは
     可能ですが、これは全然安全じゃ無く、誤って資格情報が公開される可能
     性があるため、お勧めしません。

環境変数からパスワードまたはトークンを読み取るにはどうすればよいですか？
     ‘credential.helper’ 構成オプションは、標準出力で資格情報プロトコル
     を生成する任意のシェルコマンドを受け取ることもできます。これは、た
     とえば、資格情報をコンテナに渡すときに役立ちます。

     このようなシェルコマンドは、オプション値を感嘆符(‘!’)で開始すること
     で指定できます。パスワードまたはトークンが ‘GIT_TOKEN’ に保存されて
     いる場合は、以下のコマンドを実行して資格情報ヘルパーを設定できます:

          $ git config credential.helper \
                  '!f() { echo username=author; echo "password=$GIT_TOKEN"; };f'

資格情報マネージャーに保存したパスワードまたはトークンを変更するにはどうすればよいですか？
     通常、パスワードまたはトークンが無効な場合、Gitはそれを消去し、新し
     いものを要求します。ただし、これが常に発生するとは限りません。パス
     ワードまたはトークンを変更するには、既存の資格情報を消去してくださ
     い。そうすればGitが新しい資格情報の入力を求めます。資格情報を消去す
     るには、以下の構文を使用します(ユーザー名(「author」の部分)とホスト
     名(「git.example.org」の部分)をあなた自身のに置き換えてください):

          $ echo url=https://author@git.example.org | git credential reject

HTTPを使用して同じホスティングプロバイダーで複数のアカウントを使用するにはどうすればよいですか？
     通常、これらのアカウントを区別する最も簡単な方法は、URLでユーザー名
     を使用することです。 たとえば、 ‘git.example.org’ にアカウント
     ‘author’ と ‘committer’ がある場合、URLに
     https://author@git.example.org/org1/project1.git
     (https://author@git.example.org/org1/project1.git) と
     https://committer@git.example.org/org2/project2.git
     (https://committer@git.example.org/org2/project2.git) を使用できま
     す。このように、資格情報ヘルパーを使用すると、アカウントの正しい資
     格情報が自動的に検索されます。すでにリモートを設定している場合は
     ‘git remote set-url origin
     https://author@git.example.org/org1/project1.git’ としてURLを変更で
     きます(詳細は git-remote(1) を参照)。

SSHを使用して同じホスティングプロバイダーで複数のアカウントを使用するにはどうすればよいですか？
     SSHをサポートするほとんどのホスティングプロバイダーでは、単一のキー
     ペアがユーザーを一意に識別します。したがって、複数のアカウントを使
     用するには、アカウントごとにキーペアを作成する必要があります。適度
     に最新のOpenSSHバージョンを使用している場合は ‘ssh-keygen -t
     ed25519 -f ~/.ssh/id_committer’ などとして新しいキーペアを作成でき
     ます。次に、公開鍵(この場合は ‘~/.ssh/id_committer.pub’ ※拡張子
     ‘.pub’ に注意) をホスティングプロバイダーに登録できます。

     ほとんどのホスティングプロバイダーは、プッシュに単一のSSHアカウント
     を使用します。つまり、すべてのユーザーが ‘git’ アカウント(例:
     ‘git@git.example.org’)にプッシュします。プロバイダーの場合は、SSHで
     複数のエイリアスを設定して、使用するキーペアを明確にすることができ
     ます。たとえば、以下のようなのを ‘~/.ssh/config’ に記述して、適切な
     秘密鍵ファイルに置き換えることができます:

          # This is the account for author on git.example.org.
          Host example_author
                  HostName git.example.org
                  User git
                  # This is the key pair registered for author with git.example.org.
                  IdentityFile ~/.ssh/id_author
                  IdentitiesOnly yes
          # This is the account for committer on git.example.org.
          Host example_committer
                  HostName git.example.org
                  User git
                  # This is the key pair registered for committer with git.example.org.
                  IdentityFile ~/.ssh/id_committer
                  IdentitiesOnly yes

     こうすれば、あなたはプッシュURLを調整して、 ‘git@example.org’ の代
     わりに ‘git@example_author’ または ‘git@example_committer’ を使用で
     きます(例: ‘git remote set-url
     git@example_author:org1/project1.git’) 。

Common Issues
*************

前回のコミットでミスをしました。どうすれば変更できますか？
     作業ツリーに適切な変更を加え、必要に応じて ‘git add <file>’ または
     ‘git rm <file>’ を実行してステージングしてから、 ‘git commit
     --amend’ を実行できます。変更はコミットに含まれ、コミットメッセージ
     を再度編集するように求められます。元のメッセージをそのまま使用した
     い場合は、 ‘--no-edit’ オプションを伴ってて ‘git commit’ を使用する
     か、または、エディタが開いたら何もせず保存して終了して済ませること
     もできます。

バグで変更を加えましたが、それは既にメインブランチに含まれてしまっています。どうすれば元に戻すことができますか？
     これに対処する通常の方法は、 ‘git revert’ を使用することです。これ
     により、元の変更が行われて貴重な貢献であった、という履歴が保持され
     るとともに、元の変更に問題があったためにそれらの変更を元に戻す新し
     いコミットも導入されます。revertのコミットメッセージは、復帰
     (revert)されたコミットを示し、通常、復帰(revert)が行われた理由に関
     する説明を含むように編集されます。

追跡されているファイルへの変更を無視するにはどうすればよいですか？
     Gitはこれを行う方法を提供していません。 その理由は、チェックアウト
     中など、Gitがこのファイルを上書きする必要がある場合、ファイルへの変
     更が貴重で保持されるべきかどうか、または無関係で安全に破棄できるか
     どうかがわからないためです。したがって、安全なルートを取り、常にそ
     れらを保存する必要があります。

     ‘git update-index’ の特定の機能、つまり、assume-unchangedビットと
     skip-worktreeビットを使おうとするのは魅力的ですが、これらはこの目的
     には適切に機能しないため、このように使用しないでください。

     あなたの目的が構成ファイルを変更することの場合は、テンプレートまた
     はデフォルトのセットであるファイルをリポジトリにチェックインして、
     一緒にコピーして必要に応じて変更できると便利なことがよくあります。
     この場合の変更されたファイルは、誤ってコミットすることを防ぐために
     、通常は無視されます。

さまざまなファイルを無視するようにGitに依頼したはずなのに、それらはまだ追跡されています
     ‘gitignore’ ファイルは、Gitによって追跡されていない特定のファイルが
     追跡されないままであることを保証します。ただし、特定のファイルが
     ‘.gitignore’ に追加される前に追跡されている場合は追跡されたままにな
     ります。ファイル/パターン を追跡解除して無視するには、 ‘git rm
     --cached <file/pattern>’ を使用し、 <file> に一致するパターンを
     ‘.gitignore’ に追加します。詳細については gitignore(5) を参照してく
     ださい。

フェッチまたはプルのどちらを実行すればよいか知るにはどうすればよいですか？
     フェッチは、作業ツリーや現在のブランチを変更せずに、リモートリポジ
     トリからの最新の変更のコピーを保存します。その後、自由に、アップス
     トリームの変更を検査、マージ、リベース、または無視することができま
     す。プルは、フェッチとその直後のマージまたはリベースで構成されます
     。 git-pull(1) を参照してください。

Merging and Rebasing
********************

寿命の長いブランチをスカッシュマージとマージすると、どのような問題が発生する可能性がありますか？
     一般に、スカッシュマージを使用して2つのブランチを複数回マージすると
     、さまざまな問題が発生する可能性があります。これには、GUIを使用した
     場合、または ‘...`表記を使用して範囲を表す場合に、 `git log’ 出力で
     追加のコミットが表示されることや、競合を何度も再解決する必要がある
     可能性が含まれます。

     Gitが2つのブランチ間で通常のマージを行う場合、正確に3者が考慮されま
     す。2つのブランチと、通常は2つのコミットの共通の祖先である「マージ
     ベース」(merge base)と呼ばれる3番目のコミットです。マージの結果は、
     マージベースと各headの間の変更の合計です。2つのブランチを通常のマー
     ジコミットでマージすると、新しい共通の祖先を持つ、新しいコミットが
     発生し、再度マージされるときはそれが最終的なマージベースになります
     。そうすると、Gitは、マージベースの前に発生した変更を考慮する必要が
     ないため、以前に解決した競合を再解決する必要がありません。

     スカッシュマージを実行する場合、マージコミットは作成されません。代
     わりに、一方の側からの変更は、もう一方の側への通常のコミットとして
     適用されます。つまり、これらのブランチのマージベースは変更されない
     ため、Gitが次のマージを実行するときに、前回考慮したすべての変更と新
     しい変更が考慮されます。つまり、競合を再解決する必要があるかもしれ
     ません。 同様に、 ‘git diff’ または ‘git log’ またはGUIで ‘...’ 表
     記を使用すると、元のマージベース以降のすべての変更が表示されます。

     結果として、2つの長期間有効なブランチを繰り返しマージする場合は、常
     に通常のマージコミットを使用するのが最善です。

2つのブランチに変更を加えた後、それを1つに戻した場合、それら2つのブランチのマージに変更が含まれるのはなぜですか？
     デフォルトでは、Gitがマージを行うとき、それは「ort」戦略と呼ばれる
     戦略を使用します。これは、派手な3者間マージ(fancy three-way merge)を
     行います。 このような場合、Gitはマージを実行するときに、正確に3つの
     ポイントを考慮します。2つのheadと、通常はこれらのコミットの共通の祖
     先である「マージベース」(merge base)と呼ばれる3番目のポイントです。
     Gitは、これらのブランチで発生した履歴や個々のコミットをまったく考慮
     しません。

     その結果、両方の側に変更があり、一方の側がその変更を元に戻した場合
     、結果には変更が含まれます。 これは、コードが一方の側で変更され、も
     う一方の側では正味の変更がないためです。このシナリオでは、Gitが変更
     を採用します。

     これが問題になる場合は、代わりにリベースを実行して、ブランチを他の
     ブランチに戻すことでリベースすることができます。このシナリオでのリ
     ベースは変更を元に戻します。これは、リベースが元に戻すことを含め、
     個々のコミットを適用するためです。リベースは書き換え履歴(rewrite
     history)をリベースするため、問題がない場合を除いて、公開されたブラ
     ンチのリベースは避けてください。詳細については、 git-rebase(1)の
     NOTESセクションを参照してください。

Hooks
*****

フックを使用して、ユーザーが特定の変更を行うのを妨げるにはどうすればよいですか？
     これらの変更を行うための唯一の安全な場所は、リモートリポジトリ(つま
     り、Gitサーバー)で、通常は ‘pre-receive’ フックまたは継続的インテグ
     レーション(CI)システムです。これらは、ポリシーを効果的に実施できる
     場所です。

     ‘pre-commit’ フック(または、コミットメッセージの場合は ‘commit-msg’
     フック)を使用してこれらをチェックするのが一般的です。これは、単独の
     開発者として作業していて、ツールが役立つことを望んでいる場合に最適
     です。ただし、開発者のマシンでフックを使用することは、ユーザーが(他
     のさまざまな方法の中でも)気付かれることなく ‘--no-verify’ でこれら
     のフックをバイパスできるため、ポリシーコントロールとしては効果的で
     はありません。 Gitは、ユーザーがローカルリポジトリを管理しているこ
     とを前提としており、これを防止したり、ユーザーを攻撃したりすること
     はありません。

     さらに、一部の上級ユーザーは、「pre-commit」フックが、一時的なコミ
     ットを使用して進行中の作業をステージングしたり、修正コミットを作成
     したりするワークフローの障害であると感じているため、とにかくこれら
     の種類のチェックはサーバーに押しやることをお勧めします。

Cross-Platform Issues
*********************

Windowsを使用していますが、テキストファイルがバイナリとして検出されます。
     Gitは、テキストファイルをUTF-8として保存する場合に最適に機能します
     。Windows上の多くのプログラムはUTF-8をサポートしていますが、Gitがバ
     イナリとして検出するリトルエンディアンのUTF-16形式を使用していない
     プログラムもあります。プログラムでUTF-8を使用できない場合は、これら
     のファイルをUTF-8としてリポジトリに保存しながら、ファイルをチェック
     アウトするエンコードを示す作業ツリーエンコーディング(working tree
     encoding)を指定できます。これにより、 git-diff(1) などのツールを期
     待どおりに機能させながら、ツールを機能させることができます。

     これを行うには、 ‘working-tree-encoding’ 属性を使用して
     gitattributes(5) パターンを指定できます。たとえば、以下のパターンは
     、Windowsで一般的なエンコーディングである UTF-16LE-BOM を使用するよ
     うにすべてのC言語ファイルを設定します:

          *.c     working-tree-encoding=UTF-16LE-BOM

     これを有効にするには、 ‘git add --renormalize’ を実行する必要があり
     ます。プラットフォーム間で使用されるプロジェクトでこれらの変更を行
     う場合は、ユーザーごとの構成ファイルまたは
     ‘$GIT_DIR/info/attributes’ の構成ファイルで行う必要があることに注意
     してください。リポジトリ内の ‘.gitattributes’ ファイルは、リポジト
     リのすべてのユーザーに適用されます。

     行末の正規化については以下のエントリを参照してください。属性ファイ
     ルの詳細については、gitattributes(5) を参照してください。

Windowsの git diff はファイルの最後に ‘^M’ があると表示します。
     デフォルトでは、GitはファイルがUnixの行末で保存されることを想定して
     います。そのため、Windowsの行末の一部であるキャリッジリターン
     (‘^M’)は、末尾の空白と見なされるため、表示されます。Gitはデフォルト
     で、既存の行ではなく、新しい行にのみ末尾の空白を表示します。

     ファイルをUnixの行末でリポジトリに保存し、プラットフォームの行末に
     自動的に変換できます。 これを行うには、構成オプション ‘core.eol’ を
     ‘native’ に設定し、以下のエントリで、ファイルをテキストまたはバイナ
     リとして構成する方法について確認してください。

     行末からキャリッジリターン(CR;\x0d)を削除したくない場合は、
     ‘core.whitespace’ 設定を使用してこの動作を制御することもできます。

常に変更されるファイルがあるのはなぜですか？
     内部的には、Gitは常にファイル名をバイトのシーケンスとして保存し、エ
     ンコードや大文字と小文字の区別は行いません。 ただし、Windowsと
     macOSはどちらも、デフォルトでファイル名に対して大文字と小文字を区別
     します。その結果、大文字と小文字が区別される場合にのみ名前が異なる
     複数のファイルまたはディレクトリが作成される可能性があります。Gitは
     これを問題なく処理できますが、ファイルシステムはこれらのファイルの
     1つしか保存できないため、Gitが他のファイルを読み取ってその内容を確
     認すると、変更されているように見えます。

     ファイルが1つだけになるように、ファイルの1つを削除することをお勧め
     します。これは、以下のようなコマンド(2つのファイル ‘AFile.txt’ と
     ‘afile.txt‘ を想定)を使用して、他の点ではクリーンな作業ツリーで実行
     できます:

          $ git rm --cached AFile.txt
          $ git commit -m 'Remove files conflicting in case'
          $ git checkout .

     これにより、ディスクへの変更は回避され、追加のファイルは削除されま
     す。プロジェクトでは、この問題が再発しないように、すべて小文字の名
     前などの命名規則を採用することをお勧めします。このような規則は、
     ‘pre-receive’ フックを使用して、または継続的インテグレーション
     (CI)システムにてチェックできます。

     システムでスマッジまたはクリーンフィルター(a smudge or clean
     filter)が使用されているが、スマッジまたはクリーンフィルターを実行せ
     ずにファイルが以前にコミットされた場合、任意のプラットフォームで永
     続的に変更されたファイルが発生する可能性もあります。これを修正する
     には、他の点ではクリーンな作業ツリーで以下を実行します:

          $ git add --renormalize .

Gitにファイルを保存するための推奨の方法は何ですか？
     Gitはあらゆるタイプのあらゆるファイルを保存および処理できますが、他
     の設定よりもうまく機能する設定がいくつかあります。一般に、テキスト
     ファイルは、LF(Unixスタイル)で終わるバイト順マーク(BOM)なしで
     UTF-8に保存することをお勧めします。また、コミットメッセージで
     UTF-8(ここでもBOMなし)を使用することをお勧めします。これらは、プラ
     ットフォーム間や ‘git diff’ や ‘git merge’ などのツールで最適に機能
     する設定です。

     さらに、テキストベースまたは非テキストベースのストレージ形式を選択
     できる場合は、ファイルをテキスト形式で保存し、必要に応じて他の形式
     に変換することをお勧めします。たとえば、1行に1つのレコードを持つテ
     キストベースのSQLダンプは、実際のデータベースファイルよりも差分とマ
     ージにはるかに適しています。同様に、MarkdownやAsciiDocなどのテキス
     トベースの形式は、MicrosoftWordやPDFなどのバイナリ形式よりもうまく
     機能します。

     同様に、バイナリ依存関係(共有ライブラリやJARファイルなど)を格納した
     り、リポジトリに製品をビルドしたりすることは、通常はお勧めしません
     。依存関係とビルド製品は、リポジトリに保存されている参照、URL、ハッ
     シュのみを使用して、アーティファクトサーバーまたはパッケージサーバ
     ーに保存するのが最適です。

     また、 gitattributes(5) ファイルを設定して、どのファイルがテキスト
     でどのファイルがバイナリであるかを明示的にマークすることをお勧めし
     ます。Gitに推測させたい場合は、属性 ‘text=auto’ を設定できます。 た
     とえば、一部のプロジェクトでは以下の設定が適切な場合があります:

          # By default, guess.
          *       text=auto
          # Mark all C files as text.
          *.c     text
          # Mark all JPEG files as binary.
          *.jpg   binary

     これらの設定は、ツールがパッチなどの出力に適切な形式を選択するのに
     役立ち、プラットフォームに適切な行末コードでファイルがチェックアウ
     トされます。

GIT
***

Part of the git(1) suite

Name
****

gitglossary — Git用語集

Synopsis
********

*

DESCRIPTION
***********

alternate object database
     代役(alternate)メカニズムを介して、 リポジトリ (see
     [def_repository]) は オブジェクトデータベース (see
     [def_object_database]) の一部を "alternate" (代役) 呼ばれる別のオ
     ブジェクトデータベースから継承できます。

bare repository
     ベアリポジトリは通常、適切な名前のディレクトリ (see
     [def_directory])で、接尾辞は ‘.git’ で、リビジョン管理下にあるフ
     ァイルのローカルでチェックアウトされたコピーはありません。つまり、
     通常は非表示の ‘.git’ サブディレクトリに存在するすべてのGit管理ファ
     イルと制御ファイルは、代わりに ‘repository.git’ ディレクトリに直接
     存在し、他のファイルは存在せず、チェックアウトされません。通常、公
     開リポジトリの発行者は、ベアリポジトリを利用可能にします。

blob object(ブロブオブジェクト)
     型の無いオブジェクト (see [def_object])。例:ファイルの中身。

branch
     「ブランチ」は開発ラインです。ブランチの最新のコミット (see
     [def_commit])は、そのブランチの先端(the tip of that branch)と呼ば
     れます。ブランチの先端はブランチhead (see [def_head])によって参
     照され、ブランチで追加の開発が行われると前進します。単一のGit リポ
     ジトリ (see [def_repository])は任意の数のブランチを追跡できます
     が、あなたの作業ツリー (see [def_working_tree])はそのうちの1つ
     (「current branch」(現在のブランチ)または「checked out branch」(チ
     ェックアウトされたブランチ))に関連付けられ、 HEAD (see
     [def_HEAD]) はそのブランチを指します。

cache
     廃止。 index (see [def_index]) を使ってください。

chain(チェーン,チェイン)
     オブジェクトのリスト。リスト内の各 オブジェクト (see
     [def_object]) には、その後ろへの参照が含まれます(たとえば、 コミ
     ット (see [def_commit]) の後ろはその 親 (see [def_parent])
     の1つである可能性があります)。

changeset
     "コミット (see [def_commit])" の BitKeeper/cvsps での言い方です
     。 Git は変更(change)ではなく状態(state)を保存するため、Gitでコミッ
     トを「changeset」と呼ぶのはナンセンスです。

checkout
     作業ツリー (see [def_working_tree])の全部または一部をオブジェク
     トデータベース (see [def_object_database])のツリーオブジェクト
     (see [def_tree_object])またはブロブ (see
     [def_blob_object])で更新し、作業ツリー全体が新しいブランチ (see
     [def_branch])を指している場合は、インデックス (see
     [def_index])とHEAD (see [def_HEAD])を更新する操作。

cherry-picking(チェリーピック,チェリーピッキング)
     SCM (see [def_SCM]) の専門用語では、 "cherry pick" (つまみ食い
     )とは、一連の変更(通常はコミット)から変更のサブセットを選択し、それ
     らを別のコードベースの上に新しい一連の変更として記録することを意味
     します。Gitでは、これは "git cherry-pick" コマンドによって実行され
     、既存のコミット (see [def_commit])によって導入された変更を抽出
     し、現在のブランチ (see [def_branch])の先端に基づいてそれを新し
     いコミットとして記録します。

clean
     現在のヘッド (see [def_head])が参照するリビジョン (see
     [def_revision])と作業ツリー (see [def_working_tree])が完全に
     一致(correspond)しているのであれば、その作業ツリー (see
     [def_working_tree])はクリーンです。「dirty (see [def_dirty])」
     も参照下さい。

commit
     名詞として: Gitの履歴における一つのポイント。プロジェクトの履歴全体
     は、相互に関連する一連のコミットとして表されます。「コミット」とい
     う言葉は、他のリビジョン管理システムが「リビジョン」または「バージ
     ョン」という言葉を使用するのと同じ場所で、Gitによってよく使用されま
     す。 コミットオブジェクト (see [def_commit_object]) の省略形と
     しても使用されます。

     動詞として(コミットする): インデックス (see [def_index])の現在
     の状態を表す新しいコミットを作成し、その新しいコミットをポイントす
     るようにHEAD (see [def_HEAD])を進めることにより、プロジェクトの
     状態の新しいスナップショットをGit履歴に保存する操作。

commit object
     親 (see [def_parent])、コミッター、作者、日付、保存されたリビジ
     ョンの最上位ディレクトリ (see [def_directory])に対応するツリー
     オブジェクト (see [def_tree_object])など、特定のリビジョン
     (see [def_revision])に関する情報を含むオブジェクト (see
     [def_object])。

commit-ish (also committish)(コミットっぽい;コミット風)
     コミットオブジェクト (see [def_commit_object])または、コミット
     オブジェクト (see [def_commit_object])に再帰的に逆参照可能なオ
     ブジェクト (see [def_object])。 コミットオブジェクト (see
     [def_commit_object])や、コミットオブジェクト (see
     [def_commit_object])を指すタグオブジェクト (see
     [def_tag_object])や、コミットオブジェクト (see
     [def_commit_object])を指すタグオブジェクト (see
     [def_tag_object])を指すタグオブジェクト (see
     [def_tag_object])などは全てcommit-ish(commit-ishes)です。

core Git
     Gitの基本的なデータ構造とユーティリティ。これは、限定的なソースコー
     ド管理ツールのみです。

DAG
     有向非巡回グラフ(Directed acyclic graph)。 コミットオブジェクト
     (see [def_commit_object]) は、(有向の)親を持ち、コミットオブジ
     ェクトのグラフが非巡回(同じ オブジェクト (see [def_object]) で
     開始・終了する チェイン (see [def_chain]) はありません)であるた
     め有向非巡回グラフを形成します。

dangling object
     (ぶらぶら揺れるオブジェクト)他の到達不能オブジェクト (see
     [def_unreachable_object])からでも到達できない到達不能オブジェクト
     (see [def_unreachable_object])。 danglingオブジェクトには、リポ
     ジトリ (see [def_repository])内の任意のrefまたはオブジェクト
     (see [def_object])からの参照はありません。

detached HEAD
     通常、HEAD (see [def_HEAD])はブランチ (see [def_branch])の
     名前を格納し、HEADが示す履歴を操作するコマンドは、HEADが指すブラン
     チの先端につながる履歴を操作します。 ただし、Gitでは、必ずしも特定
     のブランチの先端ではない任意のコミット (see [def_commit])をチェ
     ックアウト (see [def_checkout])することもできます。このような状
     態のHEADを「detached」(切り離されている、デタッチされている)と呼び
     ます。

     注意: 現在のブランチの履歴を操作するコマンド(たとえば、その上に新し
     い履歴を構築するための ‘git commit’)は、HEADがデタッチされている間
     も機能することに注意してください。それらは、ブランチに影響を与える
     ことなく、更新された履歴の先端を指すようにHEADを更新します。現在の
     ブランチに関する情報を更新または照会するコマンド(たとえば、現在のブ
     ランチが統合するリモートトラッキングブランチを設定する ‘git branch
     --set-upstream-to’)は、この状態で問い合わせる(実際の)現在のブランチ
     がないため、明らかに機能しません。

directory
     あなたが "ls" で得られる一覧の事 :-)

dirty
     作業ツリー (see [def_working_tree])で、現在のブランチ (see
     [def_branch])に対してコミット (see [def_commit])されてない変
     更が含まれている場合、「作業ツリー (see [def_working_tree])はダ
     ーティーである」と言われます。

evil merge
     邪悪なマージとは、どの 親 (see [def_parent]) にも表示されない変
     更を導入する マージ (see [def_merge]) です。

fast-forward
     fast-forward(早送り)は、とあるリビジョン (see [def_revision])に
     、その子孫である別のブランチ (see [def_branch])の変更をマージす
     る特殊なタイプのマージ (see [def_merge])です。このような場合、
     新しいマージ (see [def_merge])コミット (see [def_commit])を
     行うのではなく、マージするブランチと同じリビジョンを指すようにブラ
     ンチを更新するだけです。これは、リモートリポジトリ (see
     [def_repository])のリモート追跡ブランチ (see
     [def_remote_tracking_branch])で頻繁に発生します。

fetch
     ブランチ (see [def_branch])をフェッチするということは、リモート
     リポジトリ (see [def_repository])からブランチのhead ref (see
     [def_head_ref])を取得して、ローカルのオブジェクトデータベース
     (see [def_object_database])に欠落しているオブジェクトを見つけ、
     そして欠落したオブジェクトを取得することを意味します。 git-fetch(1)
     も参照してください。

file system
     リーナス・トーバルズは当初、Gitをユーザー空間ファイルシステム、つま
     りファイルとディレクトリを保持するインフラストラクチャとして設計し
     ました。これにより、Gitの効率と速度が保証されました。

Git archive
     リポジトリ (see [def_repository]) の同義語(arch people 向け)。

gitfile
     実際のリポジトリであるディレクトリを指す、作業ツリーのルートにある
     プレーンファイル ‘.git’

grafts
     graftsは、コミットの偽の祖先情報を記録することで、他の点では異なる
     2つの開発ラインを結合できます。こうすることで、あるコミット (see
     [def_commit])が持つ親 (see [def_parent])の組を、コミット作成
     時に記録されたものとは異なるものとして Git に見せかけることができる
     のです。これは ‘.git/info/grafts’ ファイルを介して構成されます。

     注意: graftsメカニズムは時代遅れであり、リポジトリ間でオブジェクト
     を転送する際に問題が発生する可能性があることに注意してください。 同
     じことを行うためのより柔軟で堅牢なシステムについては、
     git-replace(1) を参照してください。

hash
     Gitの文脈では オブジェクト名 (see [def_object_name]) と同義語。

head
     ブランチ (see [def_branch]) の先端にある コミット (see
     [def_commit]) への、 名付けられた参照 (see [def_ref]) です。
     パックされた参照を使用する場合を除いて、headは
     ‘$GIT_DIR/refs/heads/’ ディレクトリのファイルに保存されます。
     (linkgit: git-pack-refs[1] を参照してください。)

HEAD
     現在のブランチ (see [def_branch])。 より詳細に言うと、あなたの
     作業ツリー (see [def_working_tree])は通常、HEADによって参照され
     るツリーの状態から派生します。HEADは、リポジトリ内のhead (see
     [def_head])達のうちの一つへの参照です。ただし、detached HEAD
     (see [def_detached_HEAD])をの場合は、任意のコミットを直接参照し
     ています。

head ref
     head (see [def_head]) の同義語。

hook
     いくつかのGitコマンドの通常の実行中に、開発者が機能を追加したりチェ
     ックしたりできるようにするオプションのスクリプトを呼び出します。通
     常、フックを使用すると、コマンドを事前に確認して中止することができ
     、そしてまた、操作の完了後に事後通知を行うことができます。フックス
     クリプトは ‘$GIT_DIR/hooks/’ ディレクトリにあり、ファイル名から
     ‘.sample’ サフィックスを削除するだけで有効になります。以前のバージ
     ョンのGitでは、それらを実行可能にする必要がありました。

index
     状態情報を含むファイルのコレクションで、その内容はオブジェクトとし
     て保存されます。インデックスは、あなたの作業ツリー (see
     [def_working_tree])の保存バージョンです。正直なところ、これには、
     マージ (see [def_merge])のときに使用される、作業ツリーの2番目お
     よび3番目のバージョンを含めることもできます。

index entry
     インデックス (see [def_index])に保存されている特定のファイルに
     関する情報。マージ (see [def_merge])が開始されたが、まだ終了し
     ていない場合(つまり、インデックスにそのファイルの複数のバージョンが
     含まれている場合)、インデックスエントリをマージ解除(unmerge)できま
     す。

master
     デフォルトの開発 ブランチ (see [def_branch]) 。 Git リポジトリ
     (see [def_repository]) を作成するたびに、「master」という名前の
     ブランチが作成され、アクティブなブランチになります。 ほとんどのロー
     カル開発に含まれていますが、これは純粋に慣例によるものであり、必須
     ではありません。

merge
     動詞として: 別のブランチ (see [def_branch])(あるいは外部のリポ
     ジトリ (see [def_repository])から)の内容を現在のブランチに取り
     込むこと。マージされたブランチが別のリポジトリからのものである場合
     、これは最初にリモートブランチをフェッチ (see [def_fetch])し、
     次に結果を現在のブランチにマージすることによって行われます。このフ
     ェッチ操作とマージ操作の組み合わせは、プル(pull) (see
     [def_pull])と呼ばれます。マージは、ブランチが分岐してから行われた
     変更を識別し、それらすべての変更を一緒に適用する自動プロセスによっ
     て実行されます。変更が競合する場合は、マージを完了するために手動に
     よる介入が必要になる場合があります。

     名詞として: fast-forward (see [def_fast_forward])でない限り、マ
     ージ成功の結果として、マージされたブランチ (see [def_branch])の
     先端を親 (see [def_parent])に持つ新しいコミット (see
     [def_commit])が作成されます。このコミットは「マージコミット」と呼
     ばれます。または単に「マージ」と呼ばれることもあります。

object(オブジェクト)
     Gitの保管ユニット(unit of storage)。その内容による SHA-1 (see
     [def_SHA1]) によって一意に識別されます。したがって、オブジェクト
     を変更することはできません。

object database
     「オブジェクト」の組を格納し、個々のオブジェクト (see
     [def_object])はそのオブジェクト名 (see [def_object_name])によ
     って識別されます。オブジェクトは通常、 ‘$GIT_DIR/objects/’ にありま
     す。

object identifier(オブジェクトID)
     object name (see [def_object_name]) (オブジェクト名)の同義語

object name(オブジェクト名)
     オブジェクト> の一意の識別子。オブジェクト名は通常、40文字の16進文
     字列で表されます。一般に <<def_SHA1 (see [def_object]) とも呼ば
     れます。

object type(オブジェクトタイプ)
     「コミット (see [def_commit_object]) 識別子」または「ツリー
     (see [def_tree_object]) 識別子」または「タグ (see
     [def_tag_object]) 識別子」または「ブロブ (see
     [def_blob_object]) 識別子」のいずれかで、 オブジェクト (see
     [def_object]) のタイプを表します。

octopus
     3つ以上(more than two)のブランチをマージします

origin
     デフォルトの上流(upstream)リポジトリ (see [def_repository])。ほ
     とんどのプロジェクトには、追跡する上流プロジェクトが少なくとも1つあ
     ります。デフォルトでは、「origin」がその目的で使用されます。新しい
     上流更新分は、 origin/name-of-upstream-branch という名前の リモート
     追跡ブランチ (see [def_remote_tracking_branch])にフェッチされま
     す。これは、 ‘git branch-r’ を使用して確認できます。

overlay
     ‘cp -R’ が宛先ディレクトリの内容を更新するのと同様に、ファイルを更
     新して作業ディレクトリに追加するのみで削除を行いません。これは、イ
     ンデックス (see [def_index])またはツリー風の何か(tree-ish)
     (see [def_tree-ish])からファイルをチェックアウトするときの
     checkout (see [def_checkout])のデフォルトモードです。対照的に、
     オーバーレイなしモード(no-overlay mode)では、 ‘rsync --delete’ と同
     様に、ソース側に存在しない追跡ファイルは削除されます。

pack
     1つのファイルに圧縮されたオブジェクトの組(スペースを節約するため、
     またはそれらを効率的に送信するため)。

pack index
     パックの内容に効率的にアクセスするのに役立つ、パック (see
     [def_pack])内のオブジェクトの識別子とその他の情報のリスト。

pathspec
     Gitコマンドでパスを制限するために使用されるパターン。

     pathspecsは、「git ls-files」、「git ls-tree」、「git add」、「git
     grep」、「git diff」、「git checkout」、および、ツリーまたはワーク
     ツリーのサブセットへの操作の為にスコープを制限する他の多くのコマン
     ドのコマンドラインで使用されます。パスが現在のディレクトリまたはト
     ップレベルのどちらを基準にしているかについては、各コマンドのドキュ
     メントを参照してください。 pathspecの構文は以下のとおりです:

        • どのパスもそれ自体と一致します

        • 最後がスラッシュであるpathspecは、ディレクトリプレフィックスを
          表します。そのpathspecのスコープは、そのサブツリーに制限されて
          います。

        • pathspecの残りの部分は、pathnameの残りの部分のパターンです。 デ
          ィレクトリプレフィックスに関連するパスは、 fnmatch(3) を使用し
          てそのパターンと照合されます。特に、 _*_ と _?_ はディレクトリ
          区切り文字と一致させる事ができます。

     たとえば、 ‘Documentation/*.jpg’ は、
     ‘Documentation/chapter_1/figure_1.jpg’ を含む、Documentationサブツ
     リー内のすべての ‘.jpg’ ファイルと一致します。

     コロン(‘:’)で始まるpathspecには特別な意味があります。短い形式では、
     先頭のコロン(‘:’)の後に0個以上の「魔法記号」(magic signature)(オプ
     ションで別のコロン(‘:’)で終了)が続き、残りはパスと照合するパターン
     です。「魔法記号」は、英数字、グロブ、正規表現の特殊文字でもコロン
     でもないASCII記号で構成されます。パターンが「魔法記号」シンボルセッ
     トに属さず、コロンではない文字で始まる場合、「魔法記号」を終了する
     オプションのコロンは省略できます。

     長い形式では、先頭のコロン(‘:’)の後に開き括弧(‘(’) 、0個以上の「魔
     法単語」(magic words)のコンマ区切りリスト、および閉じ括弧(‘)’) が続
     き、残りは次のパターンです。パスと一致します。

     コロンのみのpathspecは、「pathspecがない」ことを意味します。 この形
     式は、他のpathspecと組み合わせないでください。

     top
          魔法単語 ‘top’ (魔法記号: ‘/’)は、サブディレクトリ内からコマン
          ドを実行している場合でも、作業ツリーのルートからパターンを一致
          させます。

     literal
          ‘*’ または ‘?’ などのパターンのワイルドカードはリテラル文字と
          して扱われます。

     icase
          (英文字の)大文字小文字区別せずにマッチ

     glob
          Gitはパターンを、 FNM_PATHNAMEフラグを指定した fnmatch(3) に消
          費されるのに適したシェルグロブとして扱います。パターン内のワイ
          ルドカードは、パス名内の / と一致しません。 たとえば、「
          Documentation/*.html」は「Documentation/git.html」と一致します
          が、「Documentation/ppc/ppc.html」または「
          tools/perf/Documentation/perf.html」とは一致しません。

          フルパス名と一致するパターンの2つの連続するアスタリスク ‘**’ は
          、特別な意味を持つ場合があります:

             • 先頭の ‘**’ の後にスラッシュが続く場合は、すべてのディレ
               クトリで一致することを意味します。たとえば、 ‘**/foo’ は
               、パターン ‘foo’ と同じように、ファイルまたはディレクトリ
               ‘foo’ のどこにでも一致します。 ‘**/foo/bar’ は、ディレク
               トリ ‘foo’ の直下にあるファイルまたはディレクトリ ‘bar’ と
               一致します。

             • 末尾の ‘/**’ は、内部のすべてに一致します(matches
               everything inside)。たとえば、 ‘abc/**’ は、 ‘.gitignore’
               ファイルの場所を基準にして、ディレクトリ "abc" 内のすべて
               のファイルと無限の深さで一致します。

             • スラッシュの後に2つの連続するアスタリスクが続く場合、スラ
               ッシュは0個以上のディレクトリに一致します。 たとえば、
               ‘a/**/b’ は ‘a/b’ 、 ‘a/x/b’ 、‘a/x/y/b’ などと一致します
               。

             • 他の連続するアスタリスクは無効と見なされます。

               グロブ魔法はリテラル魔法と互換性がありません。

     attr
          ‘attr:’ の後には、スペースで区切られた「属性要件」(attribute
          requirements)のリストがあります。パスが一致すると見なされるに
          は、これらすべてを満たす必要があります。これは、通常の非魔法
          pathspecパターンマッチングに追加されます。 gitattributes(5) 参
          照。

          パスの各属性要件は、以下のいずれかの形式を取ります:

             • ‘ATTR’ では、属性 ‘ATTR’ を設定する必要があります。

             • ‘-ATTR’ では、属性 ‘ATTR’ が設定されていない必要がありま
               す。

             • ‘ATTR = VALUE’ では、属性 ‘ATTR’ を文字列 ‘VALUE’ に設定
               する必要があります。

             • ‘!ATTR’ では、属性 ‘ATTR’ が指定されていない必要がありま
               す。

               注意: ツリーオブジェクトと照合する場合、属性は、指定され
               たツリーオブジェクトからではなく、作業ツリーから取得され
               ることに注意してください。

     exclude
          パスが非除外パススペックと一致すると、すべての除外パススペック
          (魔法記号: ‘!’ またはその同義語 ‘^’)が実行されます。一致する場
          合、パスは無視されます。非除外パススペックがない場合、パススペ
          ックなしで呼び出されたかのように、除外が結果セットに適用されま
          す。

parent(親)
     コミットオブジェクト (see [def_commit_object])には、開発ライン
     で論理的に前にあったもののリスト、つまり親が含まれています(あるいは
     、前・親が無い場合は空です)。

pickaxe
     pickaxe (see [def_pickaxe])(ピカクス;十字鋤;鶴嘴;つるはし)とい
     う用語は、特定のテキスト文字列を追加または削除する変更を選択するの
     に役立つdiffcoreルーチンのオプションを指します。 ‘--pickaxe-all’ オ
     プションを使用すると、特定のテキスト行などを導入または削除した完全
     なチェンジセット (see [def_changeset])を表示するために使用でき
     ます。 git-diff(1) を参照してください。

plumbing(配管)
     core Git (see [def_core_git]) のキュートな呼び方。

porcelain(磁器)
     core Git (see [def_core_git])に依存するプログラムとプログラムス
     イートのキュートな名前で、コアGitへの高レベルのアクセスを示します。
     磁器(porcelain)は、配管(plumbing) (see [def_plumbing])よりも多
     くのSCM (see [def_SCM])インターフェースを公開します。

per-worktree ref
     グローバルではなく、ワークツリー (see [def_working_tree])ごとの
     ref。これは現在、HEAD (see [def_HEAD])と ‘refs/bisect/’ で始ま
     るすべての参照のみですが、のちには普通でない他の参照が含まれる可能
     性があります。

pseudoref
     疑似参照(pseudoref)は ‘$GIT_DIR’ の下にあるファイルのクラスであり、
     rev-parseしたときrefのように動作しますが、それはgitによって特別扱さ
     れます。疑似参照はすべて大文字の名前を持ち、かつ、常にSHA-1 (see
     [def_SHA1])とそれに続く空白(whitespace)で構成される行で始まります
     。したがって、HEADは疑似参照ではありません。なぜならHEADはシンボリ
     ック参照である場合があるためです。オプションで、いくつかの追加デー
     タが含まれる場合があります。例としては ‘MERGE_HEAD’ と
     ‘CHERRY_PICK_HEAD’ があります。 per-worktree refs (see
     [def_per_worktree_ref]) とは異なり、これらのファイルはシンボリッ
     クrefにすることはできず、reflogを含めることはできません。 また、通
     常のref更新機構を使用して更新することもできません。代わりに、ファイ
     ルに直接書き込むことによって更新されます。ただし、それらはrefである
     かのように読み取ることができるため、 ‘git rev-parse MERGE_HEAD’ は
     機能します。

pull
     ブランチ (see [def_branch])をプルするとは、それをフェッチ
     (see [def_fetch])しマージ (see [def_merge])することを意味し
     ます。 git-pull(1) も参照してください。

push
     ブランチ (see [def_branch])をプッシュするとは、リモートリポジト
     リ (see [def_repository])からブランチのヘッド参照 (see
     [def_head_ref])を取得し、それがブランチのローカルヘッド参照の祖先
     であるかどうかを確認し、そしてその場合ローカルヘッド参照から到達可
     能 (see [def_reachable])であり、かつ、リモートリポジトリに欠落
     しているすべてのオブジェクトを、リモートオブジェクトデータベース
     (see [def_object_database])に持っていき、リモートヘッド参照を更
     新します。リモートヘッド (see [def_head])がローカルヘッドの祖先
     でない場合、プッシュは失敗します。

reachable(到達可能)
     特定のコミット (see [def_commit])のすべての祖先は、その特定のコ
     ミットから到達可能(reachable)であると言われます。より一般的には、タ
     グ (see [def_tag])付けしたものだったり、親またはツリーへのコミ
     ットオブジェクト (see [def_commit_object])だったり、ツリー
     (see [def_tree_object])に含まれるツリーやブロブだったり、をたど
     るチェーン (see [def_chain])によって、あるオブジェクト (see
     [def_object])から別のオブジェクト (see [def_object])に到達で
     きる場合に到達が可能です。

rebase
     一連の変更をブランチ (see [def_branch])から別のベースに再適用し
     、そのブランチのヘッド (see [def_head])を再適用した結果にリセッ
     トします。

ref
     オブジェクト名または別のrefを指す ‘refs/’ で始まる名前(例:
     ‘refs/heads/master’;別のrefを指すrefは シンボリックref (see
     [def_symref]) と呼ぶ)。便宜上、Gitコマンドの引数として使用する場
     合は ‘refs/’ を省略できる場合があります。詳細については
     gitrevisions(7) を参照してください。 refs は repository (see
     [def_repository]) に保存されます。

     ref名前空間は階層的です。さまざまなサブ階層がさまざまな目的で使用さ
     れます(たとえば、 ‘refs/heads/’ 階層はローカルブランチを表すために
     使用されます)。

     ‘refs/’ で始まらない特別な目的のrefがいくつかあります。最も注目すべ
     き例は ‘HEAD’ です。

reflog
     reflogは、refのローカルの「履歴」を示します。 つまり、このリポジト
     リの最後の3番目のリビジョンが何であったか、およびこのリポジトリの昨
     日の午後9時14分時点での「現在の状態」が何であったかを知ることができ
     ます。詳細については git-reflog(1) を参照してください。

refspec
     「refspec」は、フェッチ (see [def_fetch])やプッシュ (see
     [def_push])によって使用され、リモートref (see [def_ref])とロ
     ーカルrefの間のマッピングを記述します。

remote repository
     同じプロジェクトを追跡するために使用されるが、別の場所にあるリポジ
     トリ (see [def_repository])。リモートと通信するには、フェッチ
     (see [def_fetch])またはプッシュ (see [def_push])を参照して
     ください。

remote-tracking branch
     別のリポジトリ (see [def_repository])からの変更を追跡するために
     使用されるref (see [def_ref])。 これは通常、
     ‘refs/remotes/foo/bar’ のように見え(「foo」という名前のリモートで「
     bar」という名前のブランチを追跡することを示します)、構成されたフェ
     ッチrefspec (see [def_refspec])の右側(right-hand-side)に一致し
     ます。リモート追跡ブランチには、直接の変更を含めたり、ローカルコミ
     ットを行ったりしないでください。

repository
     << def_ref,refs>>のコレクションと、refから到達可能 (see
     [def_reachable])なすべてのオブジェクトを含むオブジェクトデータベ
     ース (see [def_object_database])。1つまたは複数の磁器 (see
     [def_porcelain])コマンドからのメタデータが付随している可能性があ
     ります。リポジトリは、代替メカニズム (see
     [def_alternate_object_database])を介してオブジェクトデータベース
     を他のリポジトリと共有できます。

resolve
     失敗した自動 マージ (see [def_merge]) が残したものを手動で修正
     する操作。

revision
     コミット (see [def_commit]) (名詞) の同義語

rewind(巻き戻し)
     開発の一部を破棄する、つまり、 head (see [def_head]) を以前の リ
     ビジョン (see [def_revision]) に割り当てる。

SCM
     Source code management (tool).

SHA-1
     セキュアハッシュアルゴリズム1(Secure Hash Algorithm 1);暗号化ハッシ
     ュ関数。 Git界隈ではオブジェクト名 (see [def_object_name])の同
     義語として使用されます。

shallow clone
     ほとんどの場合 shallowリポジトリ (see [def_shallow_repository])
     の同義語ですが、この言い方は、 ‘git clone --depth=...’ コマンドを実
     行して作成されたこと明言したものです。

shallow repository
     浅いリポジトリ(shallow repository)には不完全な履歴があり、そのコミ
     ットの一部では親が削除されて(cauterized away)います(言い換えると、
     Gitは、コミットオブジェクトに記録があっても、これらのコミットには親
     がないふりをするように指示されます)。これは、アップストリームで記録
     された実際の履歴がはるかに大きい場合でも、プロジェクトの最近の履歴
     のみに関心がある場合に役立つことがあります。浅いリポジトリは、
     git-clone(1) に ‘--depth’ オプションを指定することで作成され、その
     履歴は後で git-fetch(1) で深めることができます。

stash entry
     ダーティ (see [def_dirty]) な作業ディレクトリの内容とインデック
     スを、将来の再利用のために一時的に保存するのに使用される オブジェク
     ト (see [def_object]) 。

submodule
     とあるリポジトリの内部で、それとは別個のプロジェクトの履歴を保持す
     る リポジトリ (see [def_repository]) (ここで、その、とあるリポ
     ジトリを スーパープロジェクト (see [def_superproject]) と呼びま
     す)。

superproject
     作業ツリー内の他のプロジェクトのリポジトリを サブモジュール (see
     [def_submodule]) として参照する リポジトリ (see
     [def_repository]) 。 スーパープロジェクトは、含まれているサブモジ
     ュールのコミットオブジェクトの名前を知っています(ただし、そのコピー
     は保持していません)。

symref
     シンボリックref(シンボリック参照): SHA-1 (see [def_SHA1]) ID自
     体を含む代わりに「ref: refs/some/thing」の形式であり、参照されると
     、この参照を再帰的に逆参照します。 _HEAD (see [def_HEAD])_ は
     symrefの代表的な例です。シンボリックrefは git-symbolic-ref(1) コマ
     ンドで操作されます。

tag
     任意のタイプのオブジェクトを指す ‘refs/tags/’ 名前空間の下のref
     (see [def_ref])(通常、タグは タグ (see [def_tag_object]) ま
     たは コミットオブジェクト (see [def_commit_object]) のいずれか
     を指します)。head (see [def_head])とは対照的に、タグは ‘commit’
     コマンドによって更新されません。Gitタグは、Lispタグとは何の関係もあ
     りません(Git界隈では、それはオブジェクトタイプ (see
     [def_object_type])と呼ばれます)。タグは通常、コミットの祖先チェー
     ン (see [def_chain])の特定のポイントをマークするために使用され
     ます。

tag object
     別のオブジェクトを指すref (see [def_ref])を含むオブジェクト
     (see [def_object])。これには、コミットオブジェクト (see
     [def_commit_object])のようにメッセージを含めることができます。ま
     たPGP署名を含めることもでき、その場合、「署名付きタグオブジェクト」
     (signed tag object)と呼ばれます。

topic branch
     開発者が概念的な開発ラインを識別するために使用する通常のGitブランチ
     (see [def_branch])。(従来のSCMに比べて)ブランチは非常に簡単で処
     理コストが掛からないため、それぞれが非常に明確に定義された概念また
     は小さな増分であるが関連する変更を含む、いくつかの小さなブランチを
     持つことが望ましい場合がよくあります。

tree
     作業ツリー (see [def_working_tree])、または、ツリーオブジェクト
     (see [def_tree_object])とそれに依存するブロブ (see
     [def_blob_object])やツリーオブジェクト(つまり、作業ツリーの保存さ
     れた表現)、のいずれか。

tree object
     ファイル名とモードのリスト、および関連するブロブやツリーオブジェク
     トへのrefを含むオブジェクト (see [def_object])。<< def_tree,ツ
     リー>>とディレクトリ (see [def_directory])は同じ意味です。

tree-ish (also treeish)
     ツリーっぽい何か。ツリーオブジェクトに再帰的に逆参照できる ツリーオ
     ブジェクト (see [def_tree_object]) または オブジェクト (see
     [def_object]) です。 コミットオブジェクト (see
     [def_commit_object]) を逆参照すると、その リビジョン (see
     [def_revision]) の最上位 ディレクトリ> に対応するツリーオブジェク
     トが生成されます。※右記は全てツリーっぽい(tree-ish)モノです:
     <<def_commit-ish (see [def_directory]) 、ツリーオブジェクト、ツ
     リーオブジェクトを指す タグオブジェクト (see [def_tag_object])
     、タグオブジェクトを指すタグオブジェクト

unmerged index
     マージされていないインデックスエントリ (see [def_index_entry])を
     含むインデックス (see [def_index])。

unreachable object
     ブランチ (see [def_branch]) または タグ (see [def_tag]) ま
     たはその他の参照から 到達可能 (see [def_reachable]) ではない(辿
     れない、ポイントされてない) オブジェクト (see [def_object]) 。

upstream branch
     当該のブランチからマージされる(または当該のブランチがリベースされる
     )デフォルトのブランチ (see [def_branch])。これは、
     ‘branch.<name>.remote’ や ‘branch.<name>.merge’ を介して構成されま
     す。Aのアップストリームブランチが ‘origin/B’ の場合、「Aは
     ‘origin/B’ を追跡しています」と言うことがあります。

working tree
     実際にチェックアウトされたファイル群のツリー。 作業ツリーには通常、
     HEAD (see [def_HEAD]) コミットのツリーの内容に加えて、任意の、
     まだコミットされていないローカルの変更が含まれています。

SEE ALSO
********

gittutorial(7), gittutorial-2(7), gitcvs-migration(7), giteveryday(7),
The Git User’s Manual (user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

githooks — Gitで使われるフック

Synopsis
********

$GIT_DIR/hooks/* (or ‘git config core.hooksPath‘/*)

DESCRIPTION
***********

フック(hook)は、フックディレクトリ(hooks directory)に配置して、gitの実行
の特定の時点でアクションをトリガーできるプログラムです。実行可能ビットが
設定されていないフックは無視されます。

   デフォルトでは、フックディレクトリ(ooks directory)は ‘$GIT_DIR/hooks’
ですが、これは ‘core.hooksPath’ 構成変数を介して変更できます
(git-config(1) を参照)。

   Gitはフックを呼び出す前に、ベアリポジトリでは作業ディレクトリを
$GIT_DIRに変更し、非ベアリポジトリではの作業ディレクトリを作業ツリーのル
ートに変更します。例外は、プッシュ中にトリガーされるフック(_pre-receive_
、_update_ 、_post-receive_ 、_post-update_ 、_push-to-checkout_)で、常
に $GIT_DIR で実行されます。

   フックは、環境変数やコマンドライン引数やstdinを介して引数を取得できま
す。詳細については、以下の各フックのドキュメントを参照してください。

   ‘git init’ は、その構成に応じて、フックを新しいリポジトリにコピーする
場合があります。詳細については、 git-init(1) の「TEMPLAT EDIRECTORY」セ
クションを参照してください。このドキュメントの残りの部分で「デフォルトの
フック」について言及している場合は、Gitに付属しているデフォルトのテンプ
レートについて説明しています。

   現在サポートされているフックを以下に説明します。

HOOKS
*****

applypatch-msg
==============

このフックは git-am(1) によって呼び出されます。単一のパラメータとして、
提案するコミットログメッセージを保持するファイルの名前を取ります。ゼロ以
外のステータスで終了すると、パッチを適用する前に ‘git am’ が中止されます
。

   フックを使用すると、メッセージファイルを所定の場所で編集でき、メッセ
ージをプロジェクトの標準形式に正規化するために使用できます。 また、メッ
セージファイルを検査した後にコミットを拒否するために使用することもできま
す。

   デフォルトの ‘applypatch-msg’ フックが有効になっている場合に
‘commit-msg’ フックが有効になっていれば、 ‘commit-msg’ フックを実行しま
す。

pre-applypatch
==============

このフックは git-am(1) によって呼び出されます。これはパラメーターを受け
取らず、パッチが適用された後、コミットが行われる前に呼び出されます。

   これがゼロ以外のステータスで終了する場合、パッチの適用後に作業ツリー
はコミットされません。

   現在の作業ツリーを検査し、特定のテストに合格しない場合はコミットを拒
否するために使用できます。

   デフォルトの ‘pre-applypatch’ フックが有効になっている場合に
‘pre-commit’ フックが有効になっている場合は、 ‘pre-commit’ フックが実行
されます。

post-applypatch
===============

このフックは git-am(1) によって呼び出されます。これはパラメーターを受け
取らず、パッチが適用されてコミットが行われた後に呼び出されます。

   このフックは主に通知用であり、 ‘git am’ の結果に影響を与えることはで
きません。

pre-commit
==========

このフックは git-commit(1) によって呼び出され、 ‘--no-verify’ オプション
でバイパスできます。パラメータを必要とせず、提案したコミットログメッセー
ジを取得してコミットする前に呼び出されます。このスクリプトをゼロ以外のス
テータスで終了すると、コミットを作成する前に ‘git commit’ コマンドが中止
(abort)されます。

   デフォルトの ‘pre-commit’ フックを有効にすると、末尾に空白がある行の
導入をキャッチし、そのような行が見つかるとコミットを中止(abort)します。

   すべての ‘git commit’ フックは環境変数 $GIT_EDITOR を ‘GIT_EDITOR=:’
とすれば、 コミットメッセージを変更するためのエディターを起動しません。

   デフォルトの ‘pre-commit’ フックが有効になっていて、かつ、
‘hooks.allownonascii’ 構成オプションが設定されていないかfalseに設定され
ている場合、非ASCIIファイル名の使用を防止します。

pre-merge-commit
================

このフックは git-merge(1) によって呼び出され、 ‘--no-verify’ オプション
でバイパスできます。パラメータを必要とせず、マージが正常に実行された後、
提案したコミットログメッセージを取得してコミットする前に呼び出されます。
このスクリプトをゼロ以外のステータスで終了すると、コミットを作成する前に
‘git merge’ コマンドが中止(abort)されます。

   デフォルトの ‘pre-merge-commit’ フックが有効になっている場合に
‘pre-commit’ フック後者が有効になっている場合は、 ‘pre-commit’ フックが
実行されます。

   このフックは環境変数 $GIT_EDITOR を ‘GIT_EDITOR=:’ とすれば、 コミッ
トメッセージを変更するためのエディターを起動しません。

   マージを自動的に実行できない場合は、競合を解決し、結果を個別にコミッ
トする必要があります(git-merge(1) 参照)。その時点では、このフックは実行
されませんが、 ‘pre-commit’ が有効になっている場合は ‘pre-commit’ フック
が実行されます。

prepare-commit-msg
==================

このフックは、デフォルトのログメッセージを準備した直後、エディターを起動
する前に、 git-commit(1) によって呼び出されます。

   1つから3つのパラメーターを取ります。 1つ目は、内容がコミットログメッ
セージであるファイルの名前です。2番目はコミットメッセージのソースであり
、‘message’(‘-m’ または ‘-F’ オプションが指定された場合)、 ‘template’(
‘-t’ オプションが指定された場合、または構成オプション ‘commit.template’
が設定されている場合)、 ‘merge’(コミットがマージであるか、
‘.git/MERGE_MSG’ ファイルが存在する場合)、 ‘squash’( ‘.git/SQUASH_MSG’ フ
ァイルが存在する場合)、または ‘commit’( ‘-c’ または ‘-C’ または
‘--amend’ オプションが指定された場合)に続いて(3つ目のパラメータとして)
commitオブジェクト名。

   終了ステータスがゼロ以外の場合、 ‘git commit’ は中止(abort)されます。

   フックの目的は、メッセージファイルを所定の位置で編集することであり、
‘--no-verify’ オプションによって抑制されることはありません。ゼロ以外ステ
ータスでの終了は、フックの失敗を意味し、コミットを中止(abort)します。
pre-commitフックの代わりとして使用すべきではありません。

   Gitに付属するサンプルの ‘prepare-commit-msg’ フックは、コミットテンプ
レートのコメント部分にあるヘルプメッセージを削除します。

commit-msg
==========

このフックは git-commit(1) と git-merge(1) によって呼び出され、
‘--no-verify’ オプションでバイパスできます。単一のパラメータとして提案さ
れたコミットログメッセージを保持するファイルの名前を取ります。ゼロ以外の
ステータスで終了すると、コマンドは中止(abort)されます。

   フックを使用すると、メッセージファイルを所定の場所で編集でき、メッセ
ージをプロジェクトの標準形式に正規化するために使用できます。 また、メッ
セージファイルを検査した後にコミットを拒否するために使用することもできま
す。

   デフォルトの ‘commit-msg’ フックを有効にすると、重複する
‘Signed-off-by’ トレーラーが検出され、見つかった場合はコミットが中止
(abort)されます。

post-commit
===========

このフックは git-commit(1) によって呼び出されます。パラメータを必要とせ
ず、コミットが行われた後に呼び出されます。

   このフックは主に通知用であり、 ‘git commit’ の結果に影響を与えること
はできません。

pre-rebase
==========

このフックは git-rebase(1) によって呼び出され、ブランチがリベースされる
のを防ぐために使用できます。フックは、1つまたは2つのパラメーターで呼び出
すことができます。最初のパラメーターは、シリーズがフォークされたアップス
トリームです。2番目のパラメーターは、リベースされるブランチであり、現在
のブランチをリベースするときは設定されません。

post-checkout
=============

このフックは、ワークツリーを更新した後に git-checkout(1) または
git-switch(1) が実行されたときに呼び出されます。フックには、以前のHEADの
ref、新しいHEADのref(変更されている場合と変更されていない場合があります
)、およびチェックアウトがブランチチェックアウト(ブランチの変更、
flag=1)あるいはファイルのチェックアウト(インデックスからファイルを取得、
flag=0)のいずれかであるかどうかを示すフラグ、の3つのパラメーターが与えら
れます。このフックは、フックの終了ステータスがこれら2つのコマンドの終了
ステータスになることを除いて、 ‘git switch’ または ‘git checkout’ の結果
に影響を与えることはできません。

   これは ‘--no-checkout’ (‘-n’)オプションが使用されていない限り、
git-clone(1)の後でも実行されます。 フックに指定された最初のパラメーター
は null-refで、2番目は新しいHEADのrefであり、フラグは常に1です。
‘--no-checkout’ が使用されていない限り、 ‘git worktree add’ についても同
様です。

   このフックを使用して、リポジトリの有効性チェックを実行したり、以前の
HEADとの違いを自動表示したり、作業ディレクトリのメタデータプロパティを設
定したりできます。

post-merge
==========

このフックは git-merge(1) によって呼び出されます。これは、ローカルリポジ
トリで ‘git pull’ が実行されたときに発生します。フックは単一のパラメータ
ー、つまり、実行されているマージがスカッシュマージ(squash merge)であるか
どうかを指定するステータスフラグを受け取ります。このフックは ‘git merge’
の結果に影響を与えることはできず、競合が原因でマージが失敗した場合は実行
されません。

   このフックを対応するpre-commitフックと組み合わせて使用すると、作業ツ
リーに関連付けられている任意の形式のメタデータ(たとえば、権限/所有権、
ACLSなど)を保存および復元できます。これを行う方法の例については、
contrib/hooks/setgitperms.perl を参照してください。

pre-push
========

このフックは git-push(1) によって呼び出され、プッシュが行われないように
するために使用できます。フックは、宛先リモートの名前と場所を提供する2つ
のパラメーターで呼び出されます。名前付きリモートが使用されていない場合、
両方の値は同一になります。

   何をプッシュするかについての情報は、フックの標準入力に次の形式の行で
提供されます:

     <local ref> SP <local object name> SP <remote ref> SP <remote object name> LF

   たとえば、コマンド ‘git push origin master:foreign’ を実行すると、フ
ックは以下のような行を受け取ります:

     refs/heads/master 67890 refs/heads/foreign 12345

   ただし、完全なオブジェクト名が提供されます。外部参照がまだ存在しない
場合、 <remote object name> はすべてゼロのオブジェクト名になります。
refを削除する場合は、 <local ref> が ‘(delete)’ として提供され、 ‘<local
object name>’ がすべてゼロのオブジェクト名になります。ローカルコミットが
拡張可能な名前以外の名前(‘HEAD~’ やオブジェクト名など)で指定された場合は
、最初に指定されたとおりに提供されます。

   このフックがゼロ以外のステータスで終了した場合、 ‘git push’ は何もプ
ッシュせずに中止(abort)します。プッシュが拒否された理由に関する情報は、
標準エラーに書き込むことでユーザーに送信される場合があります。

pre-receive
===========

このフックは、 ‘git push’ に反応し、リポジトリ内の参照を更新するときに、
git-receive-pack(1) によって呼び出されます。リモートリポジトリのrefの更
新を開始する直前に、pre-receiveフックが呼び出されます。その終了ステータ
スによって、更新の成功または失敗が決まります。

   このフックは、受信操作に対して1回実行されます。引数は必要ありませんが
、更新される各refについて、標準入力で以下の形式の行を受け取ります:

     <old-value> SP <new-value> SP <ref-name> LF

   ここで、 ‘<old-value>’ は、refに保存されている古いオブジェクト名です
。 ‘<new-value>’ はrefに格納される新しいオブジェクト名です。
‘<ref-name>’ はrefのフルネームです。 新しいrefを作成する場合、
‘<old-value>’ はすべてゼロのオブジェクト名です。

   フックがゼロ以外のステータスで終了した場合、どのrefも更新されません。
フックがゼロで終了する場合でも、個々のrefの更新は_update_ (see
update)フックによって防ぐことができます。

   標準出力と標準エラー出力の両方がもう一方の側の ‘git send-pack’ に転送
(forward)されるため、ユーザーにメッセージを ‘echo’ するだけで済みます。

   ‘git push --push-option=...’ のコマンドラインで指定された、プッシュオ
プションの数は環境変数 ‘GIT_PUSH_OPTION_COUNT’ から読み取ることができ、
オプション自体は ‘GIT_PUSH_OPTION_0’ 、 ‘GIT_PUSH_OPTION_1’ 、 … から読
み取る事ができます。プッシュオプションフェーズを使用しないように取り決め
た場合、環境変数は設定されません。クライアントがプッシュオプションの使用
を選択したが、何も送信しない場合、カウント変数はゼロ、つまり
‘GIT_PUSH_OPTION_COUNT=0’ に設定されます。

   いくつかの注意点については、 git-receive-pack(1) の「Quarantine
Environment」のセクションを参照してください。

update
======

このフックは、 ‘git push’ に反応し、リポジトリ内の参照を更新するときに、
git-receive-pack(1) によって呼び出されます。リモートリポジトリのrefを更
新する直前に、 update フックが呼び出されます。その終了ステータスによって
、ref更新の成功または失敗が決まります。

   フックは、更新されるrefごとに1回実行され、以下の3つのパラメーターを取
ります:

   • 更新されるrefの名前

   • refに保存されている古いオブジェクト名

   • refに格納される新しいオブジェクト名

   更新フックがゼロステータスで終了すると、refを更新できます。ゼロ以外の
ステータスで終了すると、 ‘git receive-pack’ はそのrefを更新できなくなり
ます。

   このフックは、オブジェクト名が古いオブジェクト名で指定されたコミット
オブジェクトの子孫であるコミットオブジェクトであることを確認することによ
り、特定のrefでの「強制」更新を防ぐために使用できます。つまり、「早送り
のみ」(fast-forward only)のポリシーを適用します。

   また、 old..new ステータスをログに記録するために使用することもできま
す。ただし、ブランチのセット全体を認識しているわけではないため、単純に使
用すると、refごとに1つの電子メールが送信されることになります。そのために
は_post-receive_ (see post-receive)フックの方が適しています。

   ユーザーのアクセスをネットワーク経由のgitコマンドのみに制限する環境で
は、このフックを使用して、ファイルシステムの所有権やグループメンバーシッ
プに依存せずにアクセス制御を実装できます。ログインシェルを使用してユーザ
ーのアクセスをgitコマンドのみに制限する方法については、 git-shell(1) を
参照してください。

   標準出力と標準エラー出力の両方がもう一方の側の ‘git send-pack’ に転送
(forward)されるため、ユーザーにメッセージを ‘echo’ するだけで済みます。

   デフォルトの ‘update’ フックが有効になっている場合 — および
‘hooks.allowunannotated’ 構成オプションが設定されていないかfalseに設定さ
れている場合 — 注釈のないタグ(unannotated tags)がプッシュされるのを防ぎ
ます。

proc-receive
============

このフックは git-receive-pack(1) によって呼び出されます。サーバーが複数
値の構成変数 ‘receive.procReceiveRefs’ を設定し、そして ‘receive-pack’ に
送信されるコマンドの参照名が一致する場合、これらのコマンドは、内部の
‘execute_commands()’ 関数ではなく、このフックによって実行されます。この
フックは、関連する参照を更新し、結果を ‘receive-pack’ に報告する役割を果
たします。

   このフックは、受信操作に対して1回実行されます。引数は取りませんが、
pkt-line形式のプロトコルを使用して ‘receive-pack’ と通信し、コマンド、プ
ッシュオプションを読み取り、結果を送信します。行かのプロトコルの例では、
文字 ‘S’ は ‘receive-pack’ を表し、文字 ‘H’ はこのフックを表します。

     # Version and features negotiation.
     S: PKT-LINE(version=1\0push-options atomic...)
     S: flush-pkt
     H: PKT-LINE(version=1\0push-options...)
     H: flush-pkt

     # Send commands from server to the hook.
     S: PKT-LINE(<old-oid> <new-oid> <ref>)
     S: ... ...
     S: flush-pkt
     # Send push-options only if the 'push-options' feature is enabled.
     S: PKT-LINE(push-option)
     S: ... ...
     S: flush-pkt

     # Receive result from the hook.
     # OK, run this command successfully.
     H: PKT-LINE(ok <ref>)
     # NO, I reject it.
     H: PKT-LINE(ng <ref> <reason>)
     # Fall through, let 'receive-pack' to execute it.
     H: PKT-LINE(ok <ref>)
     H: PKT-LINE(option fall-through)
     # OK, but has an alternate reference.  The alternate reference name
     # and other status can be given in option directives.
     H: PKT-LINE(ok <ref>)
     H: PKT-LINE(option refname <refname>)
     H: PKT-LINE(option old-oid <old-oid>)
     H: PKT-LINE(option new-oid <new-oid>)
     H: PKT-LINE(option forced-update)
     H: ... ...
     H: flush-pkt

   _proc-receive_ フックの各コマンドは、疑似参照(pseudo-reference)を指す
場合があり、そのold-oidとして常にゼロオールドを持ちます。一方、
‘proc-receive’ フックは代替参照(alternate reference)を更新する可能性があ
り、代替参照はゼロ以外のold-oidで既に存在する可能性があります。この場合
、このフックは ‘option’ ディレクティブを使用して、先頭の ‘ok’ ディレクテ
ィブによって指定された参照の拡張属性を報告します。

   このフックのコマンドの報告は、入力と同じ順序である必要があります。
‘proc-receive’ フックの終了ステータスは、アトミックプッシュ(atomic
push)が使用されていない限り、送信したコマンドグループの成功または失敗の
みを決定します。

post-receive
============

このフックは、 ‘git push’ に反応し、リポジトリ内の参照を更新するときに、
git-receive-pack(1) によって呼び出されます。すべてのrefが更新された後、
リモートリポジトリで実行されます。

   このフックは、受信操作に対して1回実行されます。引数は取りませんが、
_pre-receive_ (see pre-receive) フックが標準入力で行うのと同じ情報を
取得します。

   このフックは、実際の作業が完了した後に呼び出されるため、 ‘git
receive-pack’ の結果には影響しません。

   これは、名前に加えてすべてのrefの古い値と新しい値の両方を取得するとい
う点で、 _post-update_ (see post-update) フックに取って代わります。

   標準出力と標準エラー出力の両方がもう一方の側の ‘git send-pack’ に転送
(forward)されるため、ユーザーにメッセージを ‘echo’ するだけで済みます。

   デフォルトの ‘post-receive’ フックは空ですが、Gitディストリビューショ
ンの ‘contrib/hooks’ ディレクトリにサンプルスクリプト
‘post-receive-email’ があり、コミットメールの送信を実装しています。

   ‘git push --push-option=...’ のコマンドラインで指定された、プッシュオ
プションの数は環境変数 ‘GIT_PUSH_OPTION_COUNT’ から読み取ることができ、
オプション自体は ‘GIT_PUSH_OPTION_0’ 、 ‘GIT_PUSH_OPTION_1’ 、 … から読
み取る事ができます。プッシュオプションフェーズを使用しないように取り決め
た場合、環境変数は設定されません。クライアントがプッシュオプションの使用
を選択したが、何も送信しない場合、カウント変数はゼロ、つまり
‘GIT_PUSH_OPTION_COUNT=0’ に設定されます。

post-update
===========

このフックは、 ‘git push’ に反応し、リポジトリ内の参照を更新するときに、
git-receive-pack(1) によって呼び出されます。すべてのrefが更新された後、
リモートリポジトリで実行されます。

   可変数のパラメーターを取ります。各パラメーターは、実際に更新された
refの名前です。

   このフックは主に通知用であり、 ‘git receive-pack’ の結果に影響を与え
ることはできません。

   _post-update_ フックは、プッシュされたヘッドが何であるかを知ることが
できますが、元の値と更新された値が何であるかを知らないため、 logold..new
を実行するのに適した場所ではありません。 _post-receive_ (see
post-receive)フックは、参照の元の値と更新された値の両方を取得するので
、必要に応じて、このフックの代わりに検討することもできます。

   有効にすると、デフォルトの ‘post-update’ フックが ‘git
update-server-info’ を実行して、バカ転送(dumb transports)(例:HTTP)で使用
される情報を最新の状態に保ちます。 HTTP経由でアクセスできるGitリポジトリ
を公開している場合は、あなたはおそらくこのフックを有効にする必要がありま
す。

   標準出力と標準エラー出力の両方がもう一方の側の ‘git send-pack’ に転送
(forward)されるため、ユーザーにメッセージを ‘echo’ するだけで済みます。

reference-transaction
=====================

このフックは、参照の更新を実行するGitコマンドによって呼び出されます。参
照トランザクションが、準備またはコミットまたは中止されるたびに実行される
ため、複数回呼び出される可能性があります。このフックはシンボリック参照を
カバーしていません(ただし、将来変更される可能性があります)。

   フックは引数を1つだけ取りますが、これは指定された参照トランザクション
の現在の状態です:

   • "prepared" : すべての参照更新がトランザクションのキューに入れられ、
     参照がディスク上でロックされました。

   • "committed": 参照トランザクションがコミットされ、すべての参照にそれ
     ぞれの新しい値が追加されました。

   • "aborted": 参照トランザクションが中止され、変更は実行されず、ロック
     が解放されました。

   トランザクションに追加された参照更新ごとに、フックは標準入力で以下の
形式の行を受け取ります:

     <old-value> SP <new-value> SP <ref-name> LF

   ここで、 ‘<old-value>’ は、参照トランザクションに渡された古いオブジェ
クト名です。 ‘<new-value>’ はrefに格納される新しいオブジェクト名であり、
‘<ref-name>’ はrefのフルネームです。現在の値に関係なく参照を強制的に更新
する場合、または参照を新たに作成する場合は、 ‘<old-value>’ はすべてゼロ
のオブジェクト名です。あなたは、これらのケースを区別するために、
‘gitrev-parse’ を介して ‘<ref-name>’ の現在の値を調べることができます。

   フックの終了ステータスは、「prepared」(準備済み)状態を除くすべての状
態で無視されます。「prepared」状態では、ゼロ以外の終了ステータスにより、
トランザクションが中止(abort)されます。その場合、フックは「中止」状態で
呼び出さることはありません。

push-to-checkout
================

プッシュが現在チェックアウトされているブランチを更新しようと試み、かつ、
‘receive.denyCurrentBranch’ 構成変数が ‘updateInstead’ に設定されている
場合、このフックは、 ‘git push’ に反応し、リポジトリ内の参照を更新すると
きに、 git-receive-pack(1) によって呼び出されます。作業ツリーとリモート
リポジトリのインデックスが現在チェックアウトされているコミットと異なる場
合、このようなプッシュはデフォルトで拒否されます。作業ツリーとインデック
スの両方が現在のコミットと一致する場合、それらは、ブランチの新しくプッシ
ュされた先端に一致するように更新されます。このフックは、デフォルトの動作
をオーバーライドするために使用されます。

   フックは、現在のブランチの先端が更新されるコミットを受け取ります。ゼ
ロ以外のステータスで終了してプッシュを拒否できます(そうする場合は、イン
デックスまたは作業ツリーを変更してはいけません)。または、作業ツリーとイ
ンデックスに必要な変更を加えて、現在のブランチの先端が新しいコミットに更
新されたときにそれらを目的の状態にし、ゼロステータスで終了することもでき
ます。

   例えば、フックは単純に ‘git read-tree -u -m HEAD "$1"’ を実行して、
‘git push’ と逆方向に実行する ‘git fetch’ をエミュレートすることができま
す。 ‘git read-tree -u -m’ の二木形式(two-tree form)は、ブランチの違いを
妨げない範囲で作業ツリー(working tree)のローカル変更を維持しながらブラン
チを切り替える ‘git switch’ や ‘git checkout’ と本質的に同じものだからで
す。

pre-auto-gc
===========

このフックは ‘git gc --auto’ によって呼び出されます(git-gc(1) を参照)。
パラメータを必要とせず、このスクリプトをゼロ以外のステータスで終了させる
と、 ‘git gc --auto’ が中止(abort)されます。

post-rewrite
============

このフックは、commitを書き換えるコマンド(‘--amend’ や git-rebase(1) から
呼び出された場合の git-commit(1) 。ただし、 git-fast-import(1)や
git-filter-repo (https://github.com/newren/git-filter-repo) などの完全な
履歴(再)書き込みツールは通常、呼び出さないでください！)によって呼び出さ
れます。その最初の引数は、それが呼び出されたコマンドを示します。それは現
在、‘amend’ または ‘rebase’ のいずれかです。将来、コマンドに依存する引数
がさらに渡される可能性があります。

   フックは、stdinから、書き換えられたコミットのリストを以下の形式で受け
取ります。

     <old-object-name> SP <new-object-name> [ SP <extra-info> ] LF

   ‘extra-info’ もコマンド依存です。空の場合、先行するSPも省略されます。
現在、 ‘extra-info’ を渡すコマンドはありません。

   フックは常に、自動noteコピー(git-config(1)の
‘notes.rewrite.<command>’ 参照)が発生した後に実行されるため、フックはこ
れらのnoteにアクセスできます。

   以下のコマンド固有のコメントが適用されます:

rebase
     _squash_ 操作と _fixup_ 操作の場合、スカッシュされたすべてのコミッ
     トは、スカッシュされたコミットに書き換えられたものとしてリストされ
     ます。これは、同じ「new-object-name」を共有する複数の行があることを
     意味します。

     コミットは、リベースによって処理された順序でリストされることが保証
     されています。

sendemail-validate
==================

このフックは git-send-email(1) によって呼び出されます。単一のパラメータ
ーとして、送信する電子メールを保持するファイルの名前を取ります。ゼロ以外
のステータスで終了すると、電子メールを送信する前に ‘git send-email’ が中
止(abort)されます。

fsmonitor-watchman
==================

このフックは、使用するフックのバージョンに応じて、構成オプション
‘core.fsmonitor’ が ‘.git/hooks/fsmonitor-watchman’ または
‘.git/hooks/fsmonitor-watchmanv2’ に設定されている場合に呼び出されます。

   バージョン1は、バージョン(つまり、1)と、1970年1月1日の0:00から経過し
たナノ秒単位の時間の、2つの引数を取ります。

   バージョン2は、バージョン(つまり、2)と、トークン以降の変更を識別する
ために使用されるトークンの、2つの引数を取ります。ウォッチマン
(watchman)の場合、これはクロックID(clock id)になります。このバージョンで
は、新しいトークンの後のファイルのリストの前にNULを付けて標準出力しなけ
ればなりません。

   フックは、要求された時間以降に変更された可能性のある作業ディレクトリ
内のすべてのファイルのリストをstdoutに出力する必要があります。潜在的な変
更を見逃さないように、ロジックは包括的(inclusive)である必要があります。
パスは、作業ディレクトリのルートを基準にして、単一のNULで区切る必要があ
ります。

   実際に変更されていないファイルを含めてもかまいません。新しく作成およ
び削除されたファイルを含むすべての変更を含める必要があります。ファイルの
名前を変更するときは、古い名前と新しい名前の両方を含める必要があります。

   Gitは、指定のパス名に基づいて、変更をチェックするファイルと、追跡され
ていないファイルをチェックするディレクトリを制限します。

   gitに「すべてのファイルが変更されました」と伝えるための最適化された方
法は、ファイル名 ‘/’ を返すことです。

   終了ステータスは、gitがフックからのデータを使用して検索を制限するかど
うかを決定します。エラーが発生すると、すべてのファイルとフォルダーの検証
にフォールバックします。

p4-changelist
=============

このフックは ‘git-p4 submit’ によって呼び出されます。

   ‘p4-changelist’ フックは、ユーザーがチェンジリストメッセージ
(changelist message)を編集した後に実行されます。 ‘--no-verify’ オプショ
ンでバイパスできます。提案されたチェンジリストテキストを保持するファイル
の名前という単一のパラメータを取ります。ゼロ以外のステータスで終了すると
、コマンドは中止(abort)されます。

   フックはチェンジリストファイル(changelist file)の編集を許可されており
、テキストをプロジェクトの標準形式に正規化するために使用できます。また、
メッセージファイルを検査した後に送信を拒否するために使用することもできま
す。

   詳細については、 ‘git-p4 submit --help’ を実行してください。

p4-prepare-changelist
=====================

このフックは ‘git-p4 submit’ によって呼び出されます。

   ‘p4-prepare-changelist’ フックは、デフォルトのチェンジリストメッセー
ジ(changelist message)を準備した直後、エディタが起動する前に実行されます
。これは、チェンジリストのテキストを含むファイルの名前という1つのパラメ
ーターを取ります。スクリプトをゼロ以外のステータスで終了すると、プロセス
が中止(abort)されます。

   フックの目的は、メッセージファイルを所定の位置で編集することであり、
‘--no-verify’ オプションによって抑制されることはありません。 このフック
は、 ‘--prepare-p4-only’ が設定されている場合でも呼び出されます。

   詳細については、 ‘git-p4 submit --help’ を実行してください。

p4-post-changelist
==================

このフックは ‘git-p4 submit’ によって呼び出されます。

   ‘p4-post-changelist’ フックは、送信(submit)がP4で正常に発生した後に呼
び出されます。これはパラメーターを必要とせず、主に通知を目的としており、
git p4 submitアクションの結果に影響を与えることはできません。

   詳細については、 ‘git-p4 submit --help’ を実行してください。

p4-pre-submit
=============

このフックは ‘git-p4 submit’ によって呼び出されます。これはパラメータを
とらず、標準入力から何も取りません。このスクリプトをゼロ以外のステータス
で終了すると、 ‘git-p4 submit’ の起動を妨げます。 ‘--no-verify’ コマンド
ラインオプションでバイパスできます。詳細については、 ‘git-p4 submit
--help’ を実行してください。

post-index-change
=================

このフックは、インデックスが read-cache.c の do_write_locked_index に書
き込まれるときに呼び出されます。

   フックに渡される最初のパラメーターは、更新される作業ディレクトリのイ
ンジケーターです。「1」は作業ディレクトリが更新されたことを意味し、「0」
は作業ディレクトリが更新されなかったことを意味します。

   フックに渡される2番目のパラメーターは、インデックスが更新され、
skip-worktree ビットが変更された可能性があるかどうかを示すインジケーター
です。「1」はskip-worktreeビットが更新された可能性があることを意味し、「
0」は更新されなかったことを意味します。

   フックの実行時に "1" に設定するパラメーターは1つだけです。 両方のパラ
メータを "1" に設定してはいけません。

GIT
***

Part of the git(1) suite

Name
****

gitignore — 無視する、意図的に追跡しないファイルを指定します

Synopsis
********

$XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore

DESCRIPTION
***********

‘gitignore’ ファイルは、Gitが無視する必要のある意図的に追跡しないファイ
ルを指定します。 Gitによってすでに追跡されているファイルは影響を受けませ
ん。 詳細については、以下のNOTESを参照してください。

   ‘gitignore’ ファイルの各行にはパターンを指定します。パスを無視するか
どうかを決定するとき、Gitは通常、複数のソースからの ‘gitignore’ パターン
を、最高から最低の順に以下の優先順位でチェックします(各レベルの優先順位
内では最後に一致するパターンが結果を決定します)。

   • パターンは、それらをサポートするコマンドのコマンドラインから読み取
     られます。

   • そのパスから見て同じディレクトリまたは親ディレクトリ(作業ツリーの最
     上位まで)にある ‘.gitignore’ ファイルから読み取られたパターン。ディ
     レクトリの上位レベルのファイルのパターンは、‘.gitignore’ ファイルを
     含むディレクトリまでディレクトリ下位レベルの ‘.gitignore’ ファイル
     のパターンによって上書きされますこれらのパターンは、 ‘.gitignore’ フ
     ァイルのあるディレクトリを基準にしてマッチします。 プロジェクトは通
     常、リポジトリにそのような、プロジェクトビルドの部品として生成され
     たファイルのパターンを含んだ ‘.gitignore’ ファイルを含みます。(訳注
     :各サブディレクトリに .gigignore ファイルを含む事ができ、各ディレク
     トリの .gitignore はその親ディレクトリまたはその上位ディレクトリの
     .gitignore をオーバーライドする)

   • パターンは ‘$GIT_DIR/info/exclude’ から読み取られます。

   • 構成変数 ‘core.excludesFile’ で指定されたファイルから読み取られたパ
     ターン。

   パターンを配置するファイルは、パターンの使用方法によって異なります。

   • バージョン管理され、クローンを介して他のリポジトリに配布される必要
     があるパターン(つまり、すべての開発者が無視したいファイル)は、
     ‘.gitignore’ ファイルに入れる必要があります。

   • 特定のリポジトリに固有であるが、他の関連するリポジトリと共有する必
     要のないパターン(たとえば、リポジトリ内に存在するが1人のユーザーの
     ワークフローに固有の補助ファイル)は、 ‘$GIT_DIR/info/exclude’ ファ
     イルに配置する必要があります。

   • ユーザーがすべての状況でGitに無視させたいパターン(たとえば、選択し
     たユーザーのエディタによって生成されたバックアップファイルまたは一
     時ファイル)は、通常、ユーザーの ‘~/.gitconfig’ の
     ‘core.excludesFile’ で指定されたファイルに入ります。デフォルト値は
     $XDG_CONFIG_HOME/git/ignore です。 $XDG_CONFIG_HOME が設定されてい
     ないか空の場合、代わりに $HOME/.config/git/ignore が使用されます。

   _gitls-files_ や _git read-tree_ などの基盤となるGit配管ツールは、コ
マンドラインオプションで指定された ‘gitignore’ パターンを読み取るか、コ
マンドラインオプションで指定されたファイルから読み取ります。「git
status」や「git add」などの高レベルのGitツールは、上記で指定されたソース
からのパターンを使用します。

PATTERN FORMAT
**************

   • 空行はどのファイルともマッチしないため、読みやすくするための区切り
     として使えます。

   • ‘#’ で始まる行はコメントとして機能します。 ‘#’ で始まるパターンの最
     初の ‘#’ の前にはバックスラッシュ(「‘\’」)を置きます。

   • 末尾の空白は、バックススラッシュ(‘\’)でクォートされていない限り無視
     されます。

   • パターンを否定するオプションのプレフィックス ‘!’ 。以前のパターンで
     除外されたマッチするファイルは、再び含まれるようになります。そのフ
     ァイルの親ディレクトリが除外されている場合、そのファイルを再インク
     ルードすることはできません。Gitはパフォーマンス上の理由から除外され
     たディレクトリを一覧表示しないため、含まれているファイルのパターン
     は、それらがどこで定義されていても効果がありません。 リテラル ‘!’ で
     始まるパターンの場合は、最初の ‘!’ の前にバックスラッシュ(‘\’)を付
     けます(例: ‘\!important!.txt’)。

   • スラッシュ ‘/’ はディレクトリ区切り文字として使用されます。区切り文
     字は、 ‘.gitignore’ 検索パターンの最初、中間、または最後に発生する
     可能性があります。

   • パターンの先頭または中間(あるいはその両方)に区切り文字がある場合、
     パターンは特定の ‘.gitignore’ ファイル自体のディレクトリレベルに関
     連しています。そうしないと、パターンは ‘.gitignore’ レベルより下の
     任意のレベルでも一致する可能性があります。

   • パターンの最後に区切り文字がある場合、パターンはディレクトリのみに
     一致します。それ以外の場合、パターンはファイルとディレクトリの両方
     に一致する可能性があります。

   • たとえば、パターン ‘doc/frotz/’ は ‘doc/frotz’ ディレクトリと一致し
     ますが、 ‘a/doc/frotz’ ディレクトリとは一致しません。 ただし、
     ‘frotz/’ は ‘frotz’ およびディレクトリである ‘a/frotz’ と一致します
     (すべてのパスは ‘.gitignore’ ファイルのあるディレクトリからの相対パ
     スです)。

   • アスタリスク(‘*’)はスラッシュ(‘/’)以外のものと一致します。文字 ‘?’
     は、 ‘/’ 以外の任意の1文字と一致します。 範囲表記、例えば
     ‘[a-zA-Z]’ は、範囲内の文字の1つと一致させるために使用できます。詳
     細については、 fnmatch3）および FNM_PATHNAME フラグを参照してくださ
     い。

   フルパス名と一致するパターンの、2つの連続するアスタリスク(‘**’)は、以
下の特別な意味を持つ場合があります:

   • 先頭の ‘**’ の後にスラッシュ(‘/’)が続く場合は、すべてのディレクトリ
     で一致することを意味します。 たとえば、 ‘**/foo’ は、パターン ‘foo’
     と同じように、任意の場所のファイルまたはディレクトリ ‘foo’ と一致し
     ます。 ‘**/foo/bar’ は、ディレクトリ ‘foo’ の直下にあるファイルまた
     はディレクトリ ‘bar’ と一致します。

   • 末尾の ‘/**’ は内部のすべてに一致します。 たとえば、 ‘abc/**’ は、
     ‘.gitignore’ ファイルの場所を基準にして、ディレクトリ ‘abc’ 内のす
     べてのファイルと無限の深さで一致します。

   • スラッシュ(‘/’)の後に2つの連続するアスタリスク(‘**’)が続く場合、ス
     ラッシュは0個以上のディレクトリに一致します。たとえば、 ‘a/**/b’ は
     ‘a/b’ や ‘a/x/b’ や ‘a/x/y/b’ などと一致します。

   • 他の連続するアスタリスクは通常のアスタリスクと見なされ、以前のルー
     ルに従って一致します。

CONFIGURATION
*************

オプションの構成変数 ‘core.excludesFile’ は、 ‘$GIT_DIR/info/exclude’ と
同様に、除外するファイル名のパターンを含むファイルへのパスを示します。
‘$GIT_DIR/info/exclude’ のパターンに加えて、excludeファイルのパターンが
使用されます。

NOTES
*****

gitignoreファイルの目的は、Gitによって未だ追跡されていない特定のファイル
がGitによって追跡される事が無いようにすることです。

   現在追跡されているファイルの追跡を停止するには、 ‘git rm --cached’ を
使用します。

   作業ツリーの ‘.gitignore’ ファイルにアクセスするとき、Gitはシンボリッ
クリンクをたどりません。これにより、ファイルシステムからではなく、インデ
ックスまたはツリーからファイルにアクセスする場合の動作の一貫性が保たれま
す。

EXAMPLES
********

   • パターン ‘hello.*’ は、名前が ‘hello.’ で始まるすべてのファイルまた
     はフォルダーにマッチします。これをディレクトリのみに制限し、そのサ
     ブディレクトリには制限したくない場合は、パターンの前にスラッシュを
     付けることができます。つまり、 ‘/hello.*’ とします。このパターンは
     ‘hello.txt’ や ‘hello.c’ とマッチしますが、 ‘a/hello.java’ とはマッ
     チしません。

   • パターン ‘foo/’ は、ディレクトリ ‘foo’ とその下のパスに一致しますが
     、通常のファイルまたはシンボリックリンク ‘foo’ には一致しません(こ
     れは、Gitでのpathspecの一般的な動作方法と一致します)

   • パターン ‘doc/frotz’ と ‘/doc/frotz’ は、どの ‘.gitignore’ ファイル
     でも同じ効果があります。つまり、パターンの中間にスラッシュ(‘/’)があ
     る場合、先頭のスラッシュは関係ありません。

   • パターン ‘foo/*’ は、 ‘foo/test.json’ (通常のファイル) や ‘foo/bar’
     (ディレクトリ)とマッチしますが、パターンのアスタリスク(‘*’)がスラッ
     シュ(‘/’)を含む ‘bar/hello.c’ とマッチしないため、
     ‘foo/bar/hello.c’ (通常のファイル)とは一致しません。

         $ git status
         [...]
         # Untracked files:
         [...]
         #       Documentation/foo.html
         #       Documentation/gitignore.html
         #       file.o
         #       lib.a
         #       src/internal.o
         [...]
         $ cat .git/info/exclude
         # ignore objects and archives, anywhere in the tree.
         *.[oa]
         $ cat Documentation/.gitignore
         # ignore generated html files,
         *.html
         # except foo.html which is maintained by hand
         !foo.html
         $ git status
         [...]
         # Untracked files:
         [...]
         #       Documentation/foo.html
         [...]

   別の例:

         $ cat .gitignore
         vmlinux*
         $ ls arch/foo/kernel/vm*
         arch/foo/kernel/vmlinux.lds.S
         $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore

   2番目の .gitignore は、Gitが ‘arch/foo/kernel/vmlinux.lds.S’ を無視す
るのを防ぎます。

   特定のディレクトリ ‘foo/bar’ 以外のすべてを除外する例(‘/*’ に注意して
ください。スラッシュ(‘/’)なしでワイルドカード(‘*’)は、 ‘foo/bar’ 内のす
べても除外します):

         $ cat .gitignore
         # exclude everything except directory foo/bar
         /*
         !/foo
         /foo/*
         !/foo/bar

SEE ALSO
********

git-rm(1), gitrepository-layout(5), git-check-ignore(1)

GIT
***

Part of the git(1) suite

Name
****

gitk — Gitリポジトリブラウザ

Synopsis
********

     gitk [<options>] [<revision range>] [–] [<path>…]

DESCRIPTION
***********

リポジトリまたは選択したコミットのセットの変更を表示します。 これには、
コミットグラフの視覚化、各コミットに関連する情報、および各リビジョンのツ
リー内のファイルの表示が含まれます。

OPTIONS
*******

表示するリビジョンを制御するために、gitkは ‘git rev-list’ コマンドに適用
できるほとんどのオプションをサポートしています。 また、 ‘git diff-*’ コ
マンド群に適用できるいくつかのオプションをサポートして、各コミットによっ
て導入される変更の表示方法を制御します。最後に、いくつかのgitk固有のオプ
ションをサポートします。

   gitkは通常、コマンドラインパーサーの制限により、串刺し形式(sticked
form)の引数を持つオプションのみを理解します(linkgit: gitcli[7] を参照)。

rev-list options and arguments
==============================

このマニュアルページでは、最も頻繁に使用されるオプションについてのみ説明
しています。 完全なリストについては、 git-rev-list(1) を参照してください
。

‘--all’
     全ての参照(ブランチ、タグ、等)を表示します。

‘--branches[=<pattern>]’
‘--tags[=<pattern>]’
‘--remotes[=<pattern>]’
     すべてのブランチ(タグ、リモートブランチ、等)がコマンドラインに
     <commit> としてリストされているかのように見せかけます。 <pattern> が
     指定されている場合、参照を指定されたシェルグロブに一致するものに制
     限します。

‘--since=<date>’
     指定の日付よりも新しいコミットを表示します。

‘--until=<date>’
     指定の日付より古いコミットを表示します。

‘--date-order’
     可能な場合は、コミットを日付順で並べ替えます。

‘--merge’
     マージの試みが競合で停止した後、競合するファイルを変更し、マージさ
     れるすべてのヘッドに存在しない2つのブランチ間(つまり、HEADと
     MERGE_HEAD)の履歴のコミットを表示します。

‘--left-right’
     対称差のどちら側からコミットに到達できるかをマークします。左側から
     のコミットには ‘<’ 記号が接頭辞として付けられ、右側からのコミットに
     は ‘>’ 記号が付けられます。

‘--full-history’
     ‘<path>...’ で履歴をフィルタリングする場合、一部の履歴は削除されま
     せん。(詳細な説明については、 git-log(1) の「History
     simplification」を参照してください。)

‘--simplify-merges’
     ‘--full-history’ への追加オプションで、このマージに寄与する選択され
     たコミットがないため、結果の履歴からいくつかの不要なマージを削除し
     ます。(詳細な説明については、 git-log(1) の「History
     simplification」を参照してください。)

‘--ancestry-path’
     表示するコミットの範囲が指定されている(例: ‘commit1..commit2’ また
     は ‘commit2 {caret}commit1’)場合、 commit1とcommit2の間の祖先チェー
     ンに直接存在するコミット、つまりcommit1の子孫であり、commit2の祖先
     でもあるコミットのみを表示します。(詳細な説明については、 linkgit：
     git-log[1] の「History simplification」を参照してください。)

‘-L<start>,<end>:<file>’
‘-L:<funcname>:<file>’
     <file> 内で、 ‘<start>,<end>’ 、または正規表現の関数名 <funcname> で
     指定された行範囲をトレースします。pathspec リミッターを指定すること
     はできません。これは現在、単一のリビジョンから開始するウォークに制
     限されています。つまり、0個または1個の正のリビジョン引数のみを指定
     でき、 <start> と <end> (または <funcname>) が開始リビジョンに存在
     する必要があります。このオプションは複数回指定できます。これは
     ‘--patch’ オプションの機能を含んでいます。パッチ出力は ‘--no-patch’
     を使用して抑制できますが、他の差分形式(つまり、 ‘--raw’,
     ‘--numstat’, ‘--shortstat’, ‘--dirstat’, ‘--summary’,
     ‘--name-only’, ‘--name-status’, ‘--check’)は現在実装されていません
     。

     <start> と <end> は、以下のいずれかの形式です:

        • 数値

          <start> または <end> が数値の場合、絶対行番号を指定します(行は
          1から数えます)。

        • ‘/regex/’

          この形式は、指定されたPOSIX正規表現に一致する最初の行を使用し
          ます。 <start> が正規表現の場合、前の ‘-L’ 範囲の末尾から検索
          します。それ以外の場合は、ファイルの先頭から検索します。
          <start> が ‘^/regex/’ の場合、ファイルの先頭から検索します。
          <end> が正規表現の場合、 <start> で指定された行から検索開始し
          ます。

        • +offset or -offset

          これは <end> に対してのみ有効であり、 <start> で指定された行の
          前後の行数を指定します。

     <start> と <end> の代わりに ‘:<funcname>’ が指定されている場合、こ
     れは <funcname> に一致する最初の関数名行から次の関数名行までの範囲
     を示す正規表現です。 ‘:<funcname>’ は、前の ‘-L’ 範囲の末尾から検索
     します。それ以外の場合は、ファイルの先頭から検索します。
     ‘^:<funcname>’ はファイルの先頭から検索します。関数名は、 ‘git
     diff’ がパッチハンクヘッダーを処理するのと同じ方法で決定されます
     (gitattributes(5) の「Defining a custom hunk-header」参照)。

<revision range>
     表示するリビジョンを制限します。これは、指定されたリビジョンからの
     表示を意味する単一のリビジョンのいずれか、または、
     "_<from>_.._<to>_" 形式の範囲で、 <from> から <to> までのすべてのリ
     ビジョンを表示することもできます。注意:より高度なリビジョン選択を適
     用できることに注意してください。オブジェクト名のスペルのより完全な
     リストについては、 gitrevisions(7) を参照してください。

<path>…
     指定されたパス内のファイルにアクセスするモノだけにコミットを制限し
     ます。注意:リビジョン名に関するあいまいさを避けるために、 ‘--’ を使
     用してパスを先行するオプションから分離することに注意してください。

gitk-specific options
=====================

‘--argscmd=<command>’
     gitkが表示するリビジョン範囲を決定する必要があるたびに実行されるコ
     マンド。このコマンドは、標準出力に、表示される追加のリビジョンのリ
     ストを1行に1つずつ出力することが期待されています。表示するコミット
     のセットが更新ごとに異なる可能性がある場合は、<リビジョン範囲> を明
     示的に指定する代わりにこれを使用してください。

‘--select-commit=<ref>’
     グラフを読み込んだ後、指定したコミットを選択します。デフォルトの動
     作は、 ‘-select-commit=HEAD’ を指定するのと同じです。

Examples
********

gitk v2.6.12.. include/scsi drivers/scsi
     バージョン「v2.6.12」以降の変更で、include/scsiまたはdrivers/scsiサ
     ブディレクトリ内で変更されたファイルを表示する

gitk –since="2 weeks ago" – gitk
     ファイル ‘gitk’ について過去2週間の変更を表示します。 ‘--’ は、ブラ
     ンチ名 ‘gitk’ と混同されるのを避けるために必要です。

gitk –max-count=100 –all – Makefile
     ファイル ‘Makefile’ に加えられた最大100個の変更を表示します。現在の
     ブランチの変更だけを探すのではなく、すべてのブランチを調べます。

Files
*****

ユーザー構成と設定は以下の場所に保存されます:

   • 存在すれば ‘$XDG_CONFIG_HOME/git/gitk’ です。でなければ、

   • 存在すれば ‘$HOME/.gitk’ です。

   上記のいずれも存在しない場合は、デフォルトで
‘$XDG_CONFIG_HOME/git/gitk’ が作成されて使用されます。
_$XDG_CONFIG_HOME_ が設定されていない場合、すべての場合でデフォルトで
‘$HOME/.config’ になります。

History
*******

Gitkは最初のグラフィカルリポジトリブラウザでした。それはtcl/tkで書かれて
います。

   ‘gitk’ は実際には独立したプロジェクトとして維持されていますが、エンド
ユーザーの便宜のために安定したバージョンがGitスイートの一部として配布さ
れています。

   gitk-git/ は、 Paul Mackerras のgitkプロジェクトからのものです:

     git://ozlabs.org/~paulus/gitk

SEE ALSO
********

_qgit(1)_
     Qtを使用してC++で記述されたリポジトリブラウザです。

_tig(1)_
     Ncursesを使用してCで記述された最小限のリポジトリブラウザーとGitツー
     ルの出力ハイライト。

GIT
***

Part of the git(1) suite

Name
****

gitmailmap — 作者(author)/コミッター(committer) および/または 電子メール
アドレス(E-Mail addresses)をマップします

Synopsis
********

$GIT_WORK_TREE/.mailmap

DESCRIPTION
***********

ファイル ‘.mailmap’ がリポジトリのトップレベルに存在する場合、または
‘mailmap.file’ とか ‘mailmap.blob’ 構成オプション(git-config(1) 参照)が
指す場所(ファイルパスとかブロブ)に存在する場合は、 作者とコミッターの名
前と電子メールアドレスを、正規の本名と電子メールアドレスにマッピングする
ために使用されます。

SYNTAX
******

_#_ 文字から行末まではコメントで、空白行は無視されます。

   単純な形式では、ファイルの各行は、作成の正規の本名、空白、および名前
にマップするためにコミットで使用される電子メールアドレス(_<_ と _>_ で囲
まれている)で構成されます。 例えば:

     Proper Name <commit@email.xx>

   より複雑な形式では:

     <proper@email.xx> <commit@email.xx>

   で、これにより、メールマップはコミット用の電子メールアドレスのみを置
き換えることができます。そして:

     Proper Name <proper@email.xx> <commit@email.xx>

   では、mailmapは、指定されたコミット用電子メールアドレスに一致するコミ
ッターの名前と電子メールのアドレス両方を置き換えることができます。そして
:

     Proper Name <proper@email.xx> Commit Name <commit@email.xx>

   では、mailmapは、指定されたコミッターの名前と電子メールアドレスの両方
に一致するコミッターの名前と電子メールの両方を置き換えることができます。

   電子メールアドレスと名前の両方が大文字と小文字を区別せずに照合されま
す。たとえば、以下は上記の _Commit Name <commit@email.xx>_ とも一致しま
す:

     Proper Name <proper@email.xx> CoMmIt NaMe <CoMmIt@EmAiL.xX>

NOTES
*****

作業ツリーの ‘.mailmap’ ファイルにアクセスするとき、Gitはシンボリックリ
ンクをたどりません。 これにより、ファイルがインデックスまたはツリーから
アクセスされたときとファイルシステムからアクセスされたときの動作の一貫性
が保たれます。

EXAMPLES
********

あなたの履歴には、JaneとJoeの2人の作者(authors)によるコミットが含まれて
います。これらの作成の名前は、リポジトリにいくつかの形式で表示されます:

     Joe Developer <joe@example.com>
     Joe R. Developer <joe@example.com>
     Jane Doe <jane@example.com>
     Jane Doe <jane@laptop.(none)>
     Jane D. <jane@desktop.(none)>

   ここで、Joeが当初は、ミドルネームを使用することを望み、Janeが彼女の家
族名を完全に綴ることを好むとします。名前を修正するための ‘.mailmap’ ファ
イルは以下のようになります:

     Joe R. Developer <joe@example.com>
     Jane Doe <jane@example.com>
     Jane Doe <jane@desktop.(none)>

   注意: 名前を修正するためだけに、 _<jane@laptop.(none)>_ のnamesをマッ
プする必要はないことに注意してください。ただし、明らかに壊れた
_<jane@laptop.(none)>_ と _<jane@desktop.(none)>_ というの電子メールアド
レスをそのままにしておくことは、通常、希望するものではありません。したが
って、これらも修正する ‘.mailmap’ ファイルは以下のとおりです:

     Joe R. Developer <joe@example.com>
     Jane Doe <jane@example.com> <jane@laptop.(none)>
     Jane Doe <jane@example.com> <jane@desktop.(none)>

   最後に、JoeとJaneが電子メールアドレスを共有しているが、名前は共有して
いないとしましょう。バグ報告システムによって生成された履歴にそれぞれのコ
ミットを含めるとします。つまり、履歴には以下のように名前があらわれます:

     Joe <bugs@example.com>
     Jane <bugs@example.com>

   これらのケースも処理する完全な ‘.mailmap’ ファイル(上記の例に2行追加
)は以下のようになります:

     Joe R. Developer <joe@example.com>
     Jane Doe <jane@example.com> <jane@laptop.(none)>
     Jane Doe <jane@example.com> <jane@desktop.(none)>
     Joe R. Developer <joe@example.com> Joe <bugs@example.com>
     Jane Doe <jane@example.com> Jane <bugs@example.com>

SEE ALSO
********

git-check-mailmap(1)

GIT
***

Part of the git(1) suite

Name
****

gitmodules — サブモジュールプロパティの定義

Synopsis
********

$GIT_WORK_TREE/.gitmodules

DESCRIPTION
***********

Git作業ツリーの最上位ディレクトリにある ‘.gitmodules’ ファイルは、
git-config(1) の構文を持つテキストファイルです。

   このファイルには、サブモジュールごとに1つのサブセクションが含まれてお
り、サブセクションの値はサブモジュールの名前です。名前は、 ‘git
submodule add’ の ‘--name’ プションでカスタマイズされていない限り、サブ
モジュールが追加されたパス名として使用されます。各サブモジュールセクショ
ンには、以下の必須キーも含まれています:

submodule.<name>.path
     サブモジュールがチェックアウトされると予想される、Git作業ツリーの最
     上位ディレクトリを基準にしたパスを定義します。 パス名は‘/‘ で終わら
     せてはいけません。 すべてのサブモジュールパスは、 ‘.gitmodules’ フ
     ァイル内で一意である必要があります。

submodule.<name>.url
     サブモジュールリポジトリのクローンを作成できるURLを定義します。 こ
     れは、 git-clone(1) に渡す準備ができている絶対URLか、 ( ‘./’ または
     ‘../’ で始まる場合)スーパープロジェクトの、元のリポジトリ
     (superproject’s origin repository)から相対的な場所のいずれかです。

   さらに、いくつかのオプションのキーがあります:

submodule.<name>.update
     名前付きサブモジュールのデフォルトの更新手順を定義します。つまり、
     スーパープロジェクトの ‘git submodul eupdate’ コマンドによってサブ
     モジュールが更新される方法を定義します。これは、同一名称の構成変数
     を初期化するために ‘git submodule init’ によってのみ使用されます。
     ここで許可される値は、「checkout」、「rebase」、「merge」、「none」
     です。 それらの意味については、 git-submodule(1) の「update」コマン
     ドの説明を参照してください。セキュリティ上の理由から、「!command」
     形式は受け入れられません。

submodule.<name>.branch
     アップストリームサブモジュールの更新を追跡するためのリモートブラン
     チ名。このオプションが指定されていない場合のデフォルトは、リモート
     のHEADになります。 別な値 ‘.’ は、サブモジュール内のブランチ名が現
     在のリポジトリ内の現在のブランチ名と同一でなければならないことを示
     すために使用されます。詳細については、 git-submodule(1) の
     ‘--remote’ ドキュメントを参照してください。

submodule.<name>.fetchRecurseSubmodules
     このオプションは、このサブモジュールの再帰的フェッチを制御するため
     に使用できます。このオプションがスーパープロジェクトの
     ‘.git/config’ のサブモジュールのエントリにも存在する場合、そこでの
     設定は ‘.gitmodules’ にある設定を上書きします。コマンドラインで両方
     の設定を上書きするには、 ‘--[no-]recurse-submodules’ オプションを
     ‘git fetch’ と ‘git pull’ で使用します。

submodule.<name>.ignore
     どのような状況で ‘git status’ とdiffファミリーがサブモジュールを変
     更済みとして表示するかを定義します。指定できるのは以下の値です:

     all
          サブモジュールが変更されたと見なされる事は決してありません( た
          だし、ステータスの出力には表示され、ステージングされるとコミッ
          ト されます)。

     dirty
          サブモジュールの作業ツリーへのすべての変更は無視され、 サブモ
          ジュールの「HEAD」とスーパープロジェクトで記録された状態との間
          の コミットされた違いのみが考慮されます。

     untracked
          サブモジュール内の追跡されていないファイル(untracked files)の
          みが無視されます。 追跡中のファイルへのコミットされた違いと変
          更が 表示されます。

     none
          サブモジュールへの変更は無視されず、コミットされたすべての違い
          、 および追跡されたファイルと追跡されていないファイルへの変更
          が表示されます。 これはデフォルトのオプションです。

     このオプションがスーパープロジェクトの ‘.git/config’ のサブモジュー
     ルのエントリにも存在する場合、そこでの設定は ‘.gitmodules’ にある設
     定を上書きします。

     ‘--ignore-submodules’ オプションを使用すると、コマンドラインで両方
     の設定を上書きできます。 ‘git submodule’ コマンドは、この設定の影響
     を受けません。

submodule.<name>.shallow
     trueに設定すると、ユーザーが明示的に非浅いクローン(non-shallow
     clone)を要求しない限り、このサブモジュールのクローンは浅いクローン
     (shallow clone)(履歴の深さ1)として実行されます。

NOTES
*****

Gitは、作業ツリー内の ‘.gitmodules’ ファイルをシンボリックリンクにするこ
とを許可せず、そのようなツリーエントリのチェックアウトを拒否します。これ
により、ファイルがインデックスまたはツリーからアクセスされたときとファイ
ルシステムからアクセスされたときの動作の一貫性が保たれ、Gitがファイルの
内容のセキュリティチェックを確実に実施できるようになります。

EXAMPLES
********

以下の ‘.gitmodules’ ファイルについて考えてみます:

     [submodule "libfoo"]
             path = include/foo
             url = git://foo.com/git/lib.git

     [submodule "libbar"]
             path = include/bar
             url = git://bar.com/git/lib.git

   これは、‘libfoo’ と ‘libbar’ の2つのサブモジュールを定義します。 これ
らはパス ‘include/foo’ と ‘include/bar’ でチェックアウトされることが期待
されており、両方のサブモジュールに対して、サブモジュールのクローン作成に
使用できるURLが指定されています。

SEE ALSO
********

git-submodule(1), gitsubmodules(7), git-config(1)

GIT
***

Part of the git(1) suite

Name
****

gitnamespaces — Git名前空間

Synopsis
********

     GIT_NAMESPACE=<namespace> git upload-pack
     GIT_NAMESPACE=<namespace> git receive-pack

DESCRIPTION
***********

Gitは、単一のリポジトリのrefを複数の名前空間に分割することをサポートして
います。各名前空間には、独自のブランチ、タグ、およびHEADがあります。
Gitは、オブジェクトストアを共有し、すべてのrefを git-gc(1) などの操作に
公開しながら、プル元とプッシュ先の独立したリポジトリとして各名前空間を公
開できます。

   複数のリポジトリを単一のリポジトリの名前空間として保存すると、同じソ
ースの複数のブランチを保存する場合など、同じオブジェクトの重複コピーを保
存することを回避できます。代替メカニズムは、重複を回避するための同様のサ
ポートを提供しますが、名前空間が行うのに対し、代替は、継続的なメンテナン
スなしでリポジトリに追加された新しいオブジェクト間の重複を防止しません。

   名前空間を指定するには、 ‘GIT_NAMESPACE’ 環境変数に名前空間を設定しま
す。 ref名前空間ごとに、Gitは対応するrefを ‘refs/namespaces/’ の下のディ
レクトリに保存します。 たとえば、 ‘GIT_NAMESPACE=foo’ はrefを
‘refs/namespaces/foo/’ の下に保存します。 git(1) の ‘--namespace’ オプシ
ョンを使用して名前空間を指定することもできます。

   注意: ‘/’ を含む名前空間は、名前空間の階層に拡張されることに注意して
ください。たとえば、 ‘GIT_NAMESPACE=foo/bar’ はrefを
‘refs/namespaces/foo/refs/namespaces/bar/’ の下に保存します。 これにより
、 ‘GIT_NAMESPACE’ のパスが階層的に動作するため、
‘GIT_NAMESPACE=foo/bar’ でクローンを作成すると、 ‘GIT_NAMESPACE=foo’ で
クローンを作成してそのリポジトリから ‘GIT_NAMESPACE=bar’ でクローンを作
成するのと同じ結果が得られます。また、 ‘foo/refs/heads/’ などの奇妙な名
前空間パスとのあいまいさを回避します。そうしないと、 ‘refs’ ディレクトリ
内で ディレクトリ/ファイル の競合が発生する可能性があります。

   git-upload-pack(1) と git-receive-pack(1) は、 ‘GIT_NAMESPACE’ で指定
されているようにrefの名前を書き換えます。 git-upload-pack と
git-receive-pack は、指定された名前空間外のすべてのrefを無視します。

   スマートHTTPサーバー git-http-backend(1) は、 GIT_NAMESPACE をバック
エンドプログラムに渡します。リポジトリの名前空間をリポジトリとして公開す
るための設定例については、 git-http-backend(1) を参照してください。

   簡単なローカルテストには、あなたは git-remote-ext(1) を使用できます:

     git clone ext::'git --namespace=foo %s /tmp/prefixed.git'

SECURITY
********

フェッチおよびプッシュプロトコルは、共有することを意図していない一方の側
が他方のリポジトリからデータを盗むのを防ぐようには設計されていません。悪
意のある者から保護する必要のあるプライベートデータがある場合、最善のオプ
ションはそれを別のリポジトリに保存することです。これは、クライアントとサ
ーバーの両方に適用されます。特に、サーバー上の名前空間は、読み取りアクセ
ス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼
できるクライアントにのみ、名前空間への読み取りアクセスを許可する必要があ
ります。

   既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は、明示的に共有することを意図していないオブジェクトのIDをア
     ドバタイズする "have" 行を送信しますが、他にもIDを持っている者が居
     る場合は、転送を最適化するために使用できます。攻撃者はオブジェクト
     ID Xを選択して盗み、refをXに送信しますが、被害者はすでにXのコンテン
     ツを持っているため、Xのコンテンツを送信する必要はありません。 これ
     で、被害者は攻撃者がXを持っていると信じ、Xのコンテンツを後で攻撃者
     に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間
     にXへのrefを作成してフェッチすることにより、クライアントがサーバー
     上で実行するのが最も簡単です。サーバーがクライアント上で実行する最
     も可能性の高い方法は、Xをパブリックブランチにマージし、ユーザーがこ
     のブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュ
     バックすることを期待します。)

  2. #1 と同様に、攻撃者は盗むオブジェクトID Xを選択します。被害者は、攻
     撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持
     っていると誤って主張するため、被害者はYをXに対するデルタとして送信
     します。デルタは、攻撃者にYに類似したXの領域を明らかにします。

GIT
***

Part of the git(1) suite

Name
****

gitremote-helpers — リモートリポジトリと対話するためのヘルパープログラム
群

Synopsis
********

     git remote-<transport> <repository> [<URL>]

DESCRIPTION
***********

リモートヘルパープログラムは通常、エンドユーザーが直接使用することはあり
ませんが、Gitがネイティブでサポートしていないリモートリポジトリと対話す
る必要がある場合にGitによって呼び出されます。 特定のヘルパーは、ここに記
載されている機能のサブセットを実装します。 Gitがリモートヘルパーを使用し
てリポジトリと対話する必要がある場合、Gitは独立したプロセスとしてヘルパ
ーを生成し、ヘルパーの標準入力にコマンドを送信し、ヘルパーの標準出力から
の結果を期待します。 リモートヘルパーはGitから独立したプロセスとして実行
されるため、新しいヘルパーを追加するためにGitを再リンクする必要も、ヘル
パーをGitの実装にリンクする必要もありません。

   すべてのヘルパーは ‘capabilities’ (機能)コマンドをサポートする必要が
あります。これは、ヘルパーが受け入れる他のコマンドをGitが決定するために
使用します。これらの他のコマンドを使用して、リモート参照の検出と更新や、
オブジェクトデータベースとリモートリポジトリ間のオブジェクトの転送や、ロ
ーカルオブジェクトストアの更新を行うことができます。

   Gitには、 ‘git-remote-http’ や、 ‘git-remote-https’ や、
‘git-remote-ftp’ や、 ‘git-remote-ftps’ などのさまざまな転送
(transport)プロトコルを処理する "curl" ファミリーのリモートヘルパーが付
属しています。これらは、機能(capabilities)として、 ‘fetch’ と ‘option’ と
‘push’ を実装します。

INVOCATION
**********

リモートヘルパープログラムは、1つまたは(オプションで)2つの引数を使用して
呼び出されます。最初の引数は、Gitのようにリモートリポジトリを指定します
。それは設定されたリモートの名前またはURLのいずれかです。2番目の引数は
URLを指定します。 通常は ‘<transport>://<address>’ の形式ですが、任意の
文字列を使用できます。 ‘GIT_DIR’ 環境変数はリモートヘルパー用に設定され
ており、追加データを保存する場所や、補助Gitコマンドを呼び出すディレクト
リを決定するために使用できます。

   Gitが ‘<transport>://<address>’ の形式のURLを検出すると、ここで、
‘<transport>’ はネイティブに処理できないプロトコルで、2番目の引数として
完全なURLを使用して ‘git remote-<transport>’ を自動的に呼び出します。そ
のようなURLがコマンドラインで直接検出された場合は最初の引数は2番目の引数
と同じであり、構成されたリモートで検出された場合最初の引数はそのリモート
の名前です。

   ‘<transport>::<address>’ の形式のURLは、2番目の引数として ‘<address>’
を使用して ‘git remote-<transport>’ を呼び出すようにGitに明示的に指示し
ます。このようなURLがコマンドラインで直接検出された場合最初の引数は
‘<address>’ であり、構成されたリモートで検出された場合最初の引数はそのリ
モートの名前です。

   さらに、構成されたリモートで ‘remote.<name>.vcs’ が ‘<transport>’ に
設定されている場合、Gitは最初の引数として ‘<name>’ を使用して ‘git
remote-<transport>’ を明示的に呼び出します。 ‘remote.<name>.url’ が設定
されている場合は、2番目の引数は ‘remote.<name>.url’ です。
‘remote.<name>.url’ が設定されてない場合、2番目の引数は省略されます。

INPUT FORMAT
************

Gitは、リモートヘルパーの標準入力にコマンドのリストを1行に1つずつ送信し
ます。 最初のコマンドは常に ‘capabilities’ (機能)コマンドであり、これに
応答して、リモートヘルパーはサポートする機能のリスト(以下を参照)とそれに
続く空白行を出力する必要があります。機能コマンドへの応答により、Gitがコ
マンドストリームの残りの部分で使用するコマンドが決まります。

   コマンドストリームは空白行で終了します。場合によっては(関連するコマン
ドのドキュメントに示されています)、この空白行の後に他のプロトコル(packプ
ロトコルなど)のペイロードが続きますが、他の場合は入力の終了を示します。

Capabilities
============

各リモートヘルパーは、コマンド群のサブセットのみをサポートすることが期待
されています。ヘルパーがサポートする操作は、 ‘capabilities’ コマンドへの
応答でGitに宣言されます(以下のCOMMANDSを参照)。

   以下に、定義されているすべての機能をリストし、それぞれについて、その
機能を持つヘルパーが提供しなければならないコマンドをリストします。

Capabilities for Pushing
------------------------

_connect_
     gitのネイティブpackfileプロトコルを使用した通信のために、 ‘git
     receive-pack’(プッシュ用)、 ‘git upload-pack’ などへの接続を試みる
     ことができます。これには、双方向の全二重接続が必要です。

     サポートされているコマンド: _connect_

_stateless-connect_
     実験的:内部使用のみ。 gitのワイヤープロトコル バージョン2を使用して
     、通信のためにリモートサーバーへの接続を試みることができます。詳細
     については、 stateless-connect コマンドのドキュメントを参照してくだ
     さい。

     サポートされているコマンド: _stateless-connect_.

_push_
     リモートrefを発見する事ができ、そして、ローカルコミットとそれらに至
     るまでの履歴を、新規または既存のリモートrefにプッシュする事ができま
     す。

     サポートされているコマンド: _list for-push_, _push_.

_export_
     リモートrefを発見し、指定のオブジェクトを高速インポートストリームか
     らリモートrefにプッシュできます。

     サポートされているコマンド: _list for-push_, _export_.

   ヘルパーが ‘connect’ を広告(advertise)する場合、Gitは可能であればそれ
を使用し、接続時にヘルパーが要求すると別の機能にフォールバックします(「
COMMANDS」セクションの ‘connect’ コマンド参照)。 ‘push’ と ‘export’ のど
ちらかを選択する場合、Gitは ‘push’ を優先します。他のフロントエンドには
、他の優先順位がある場合があります。

_no-private-update_
     ‘refspec’ 機能を使用する場合、gitは通常、プッシュが成功するとプライ
     ベートrefを更新します。リモートヘルパーが機能 ‘no-private-update’ を
     宣言すると、この更新は無効になります。

Capabilities for Fetching
-------------------------

_connect_
     Gitのネイティブpackfileプロトコルを使用した通信のために、 ‘git
     upload-pack’(フェッチ用)、 ‘git receive-pack’ などへの接続を試みる
     ことができます。これには、双方向の全二重接続が必要です。

     サポートされているコマンド: _connect_

_stateless-connect_
     実験的:内部使用のみ。 gitのワイヤープロトコル バージョン2を使用して
     、通信のためにリモートサーバーへの接続を試みることができます。詳細
     については、 stateless-connect コマンドのドキュメントを参照してくだ
     さい。

     サポートされているコマンド: _stateless-connect_.

_fetch_
     リモートrefを発見し、それらから到達可能なオブジェクトをローカルオブ
     ジェクトストアに転送できます。

     サポートされているコマンド: _list_, _fetch_.

_import_
     リモートrefを発見し、それらから到達可能なオブジェクトを高速インポー
     ト形式(fast-import format)のストリームとして出力できます。

     サポートされているコマンド: _list_, _import_.

_check-connectivity_
     クローンを要求(request)されたときに、受信したパックが、自己完結して
     おり、そして、接続されていることを保証できます。

   ヘルパーが ‘connect’ を広告(advertise)する場合、Gitは可能であればそれ
を使用し、接続時にヘルパーが要求すると別の機能にフォールバックします(「
COMMANDS」セクションの ‘connect’ コマンド参照)。 ‘fetch’ と ‘import’ の
どちらかを選択する場合、Gitは ‘fetch’ を優先します。他のフロントエンドに
は、他の優先順位がある場合があります。

Miscellaneous capabilities
--------------------------

_option_
     他のコマンドの実行方法に影響を与える ‘verbosity’ (stderrに書き込む
     出力量)や、 ‘depth’ (浅いクローン(shallow clone)の場合に必要な履歴
     量)などの設定を指定します。

_refspec_ <refspec>
     ‘import’ または ‘export’ を実装するリモートヘルパーの場合、この機能
     により、 ‘refs/heads’ または ‘refs/remotes’ に直接書き込む代わりに
     、refsをプライベート名前空間に制約できます。 ‘import’ 機能を提供す
     るすべてのインポーターがこれを使用することをお勧めします。 ‘export’
     では必須です。

     機能 ‘refspec refs/heads/*:refs/svn/origin/branches/*’ を広告
     (advertise)するヘルパーは、 ‘import refs/heads/topic’ と問われた時
     に出力されるストリームは 、‘refs/svn/origin/branches/topic’ ref を
     更新します。

     この機能は複数回広告できます。最初に適用可能なrefspecが優先されます
     。この機能でアドバタイズされるrefspecの(‘:’ の)左側は、listコマンド
     によって報告されるすべてのrefをカバーする必要があります。 ‘refspec’
     機能が広告されていない場合は暗黙の ‘refspec *:*’ が設定されています
     。

     分散型バージョン管理システム用のリモートヘルパーを作成する場合は、
     リポジトリのローカルコピーを保持して対話することをお勧めします。プ
     ライベート名前空間refsがこのローカルリポジトリを指すようにし、
     refs/remotes 名前空間はリモートリポジトリを追跡するために使用されま
     す。

_bidi-import_
     これにより、 ‘import’ 機能が変更されます。fast-importコマンドの
     ‘cat-blob’ と ‘ls’ をリモートヘルパーが使用して、fast-importのメモ
     リにすでに存在するブロブとツリーに関する情報を取得できます。これに
     は、fast-importからリモートヘルパーへのチャネルが必要です。
     ‘import’ に加えて広告される場合、Gitはfast-importからリモートヘルパ
     ーのstdinへのパイプを確立します。 したがって、Gitとfast-importは両
     方ともリモートヘルパーのstdinに接続されています。Gitは複数のコマン
     ドをリモートヘルパーに送信できるため、データをfast-importに送信する
     前に、 ‘bidi-import’ を使用するヘルパーがバッチのすべての ‘import’
     コマンドをバッファリングする必要があります。 これは、ヘルパーの
     stdinでコマンドと、fast-import高速インポート応答が混在するのを防ぐ
     ためです。

_export-marks_ <file>
     これにより、 ‘export’ 機能が変更され、完了時に内部マークテーブル
     (internal marks table)を<file>にダンプするようにGitに指示します。詳
     細については git-fast-export(1) の ‘--export-marks=<file>’ を参照し
     てください。

_import-marks_ <file>
     これにより、 ‘export’ 機能が変更され、入力を処理する前に<file>で指
     定したマークをロードするようにGitに指示します。詳細については
     git-fast-export(1) の ‘--import-marks=<file>’ を参照してください。

_signed-tags_
     これにより、 ‘export’ 機能が変更され、 ‘--signed-tags=verbatim’ を
     linkgit：git-fast-export[1]に渡すようにGitに指示します。この機能が
     ない場合、Gitは ‘--signed-tags=warn-strip’ を使用します。

_object-format_
     これは、ヘルパーが明示的なハッシュアルゴリズム拡張(explicit hash
     algorithm extension)を使用してリモート側と対話できることを示してい
     ます。

COMMANDS
********

コマンドは、ヘルパーの標準入力に、呼び出し元によって1行に1つずつ与えられ
ます。

_capabilities_
     ヘルパーの機能を1行に1つずつリスト出力し、空白行で終わります。各機
     能の前に ‘*’ を付けることができます。これは、リモートヘルパーを使う
     Gitのバージョンで理解することが必須であることを示します。不明な必須
     機能は致命的なエラーです。

     このコマンドのサポートは必須です。

_list_
     refを1行に1つずつ、 ‘<value> <name> [<attr> ...]’ の形式で一覧出力
     します。 値は、16進のsha1ハッシュ または、symrefの場合は ‘@<dest>’
     または、キーと値のペアの場合は ‘:<keyword> <value>’ または、 ‘？｀
     の場合はヘルパーがrefの値を取得できなかったことを示します。 nameの
     後には、スペースで区切られたattributes(属性)のリストが続きます。認
     識されない属性は無視されます。リストは空白行で終わります。

     現在定義されている属性のリストについては、「REF LIST ATTRIBUTES」を
     参照してください。現在定義されているキーワードのリストについては、
     「REF LIST KEYWORDS」を参照してください。

     ヘルパーに「fetch」または「import」機能がある場合にサポートされます
     。

_list for-push_
     ‘list’ と似ていますが、呼び出し元が結果のrefリストでプッシュコマン
     ドを準備したい場合にのみ使用される点が異なります。プッシュとフェッ
     チの両方をサポートするヘルパーは、これを使用して、 ‘list’ の出力が
     使用される操作を区別し、実行する必要のある作業の量を減らすことがで
     きます。

     ヘルパーに "push" または "export" 機能がある場合にサポートされます
     。

_option_ <name> <value>
     転送(transport)ヘルパーオプション <name> を <value> に設定します。
     出力は、 ‘ok’(オプションが正常に設定された)または、 ‘unsupported’(オ
     プションが認識されない)または、 ‘error <msg>’(オプション<name>はサ
     ポートされていますが、<value>は無効です)のいずれかを含む単一行です
     。オプションは他のコマンドの前に設定する必要があり、それらのコマン
     ドの動作に影響を与える可能性があります。

     現在定義されているオプションのリストについては、OPTIONSを参照してく
     ださい。

     ヘルパーに "option" 機能がある場合にサポートされます。

_fetch_ <sha1> <name>
     指定されたオブジェクトをフェッチし、必要なオブジェクトをデータベー
     スに書き込みます。fetchコマンドは、1行に1つずつバッチで送信され、空
     白行で終了します。 同じバッチ内のすべてのfetchコマンドが完了すると
     、1行の空白行を出力します。この方法でフェッチできるのは、sha1を使用
     した ‘list’ の出力で報告されたオブジェクトのみです。

     オプションで、refが適切に更新されるまでパックを保持している
     ‘$GIT_DIR/objects/pack’ の下のファイルのフルパスを示す ‘lock<file>’
     行を出力できます。パスは ‘.keep’ で終わる必要があります。これは、
     keepコンポーネントのみを指定して、 <pack,idx,keep> タプルに名前を付
     けるメカニズムです。保持されたパックは、フェッチが完了するまでその
     オブジェクトが参照されない場合でも、並列再パック(concurrent
     repack)によって削除されません。 ‘.keep’ ファイルはフェッチの終了時
     に削除されます。

     オプション ‘check-connectivity’ が要求された場合、クローンが自己完
     結型(self-contained)で接続されていれば、ヘルパーは
     ‘connectivity-ok’ を出力する必要があります。

     ヘルパーに "fetch" 機能がある場合にサポートされます。

_push_ +<src>:<dst>
     指定された ローカル <src> コミットまたはブランチを、 <dst>で記述さ
     れたリモートブランチにプッシュします。 1つ以上の ‘push’ コマンドの
     バッチシーケンスは空白行で終了します(pushへの参照が1つしかない場合
     は、単一の ‘push’ コマンドの後に空白行が続きます)。たとえば、以下は
     ‘push’ の2つのバッチであり、最初のはリモートヘルパーに、ローカル参
     照 ‘master’ をリモート参照 ‘master’ にプッシュし、ローカル ‘HEAD’ を
     リモート ‘branch’ にプッシュするように要求します。2番目のは ref
     ‘foo’ を ref ‘bar’ にプッシュするように要求します(_+_ によって要求
     された強制更新です)。

          push refs/heads/master:refs/heads/master
          push HEAD:refs/heads/branch
          \n
          push +refs/heads/foo:refs/heads/bar
          \n

     最後の ‘push’ コマンドの後、バッチの終了空白行の前に、0個以上のプロ
     トコルオプションを入力できます。

     プッシュが完了すると、1つ以上の ‘ok <dst>’ または ‘error <dst>
     <why>?’ 行を出力して、プッシュされた各参照の成功または失敗を示しま
     す。ステータスレポートの出力は空白行で終了します。オプションフィー
     ルド <why> は、LFが含まれている場合、Cスタイルの文字列でクォートさ
     れる場合があります。

     ヘルパーに "push" 機能がある場合にサポートされます。

_import_ <name>
     名前付きrefの現在の値をインポートするfast-importストリームを生成し
     ます。履歴を効率的に構築するために、必要に応じて他の参照を追加でイ
     ンポートする場合があります。スクリプトは、ヘルパー固有のプライベー
     ト名前空間に書き込みます。名前付きrefの値は、「refspec」機能からの
     refspecをrefの名前に適用することによって派生した、この名前空間内の
     場所に書き込む必要があります。

     他のバージョン管理システムとの相互運用性に特に役立ちます。

     ‘push’ と同様に、1つ以上の ‘import’ のバッチシーケンスは空白行で終
     了します。 ‘import’ の各バッチごとに、リモートヘルパーは ‘done’ コ
     マンドで終了する fast-import ストリームを生成する必要があります。

     ‘bidi-import’ 機能を使用する場合は、ヘルパーのstdinでの、コマンドと
     fast-import応答の混合を防ぐために、fast-importへのデータの送信を開
     始する前にバッチシーケンスを完全にバッファリングする必要があること
     に注意してください。

     ヘルパーに "import" 機能がある場合にサポートされます。

_export_
     後続の入力は、リモートにプッシュする必要のあるオブジェクトを含む
     fast-importストリーム( ‘git fast-export’ によって生成される)の一部
     であることをリモートヘルパーに指示します。

     他のバージョン管理システムとの相互運用性に特に役立ちます。

     ‘export-marks’ と ‘import-marks’ 機能は、指定されている場合、 ‘git
     fast-export｀ に渡される限り、このコマンドに影響します。 `git
     fast-export’ は、ローカルオブジェクトのマークのテーブルを ロード/保
     存 します。 これは、増分操作の実装に使用できます。

     ヘルパーに "export" 機能がある場合にサポートされます。

_connect_ <service>
     指定のサービスに接続します。ヘルパーの標準入力と標準出力は、リモー
     ト側で指定指定のサービスに接続されます(gitプレフィックスはサービス
     名に含まれているので、例えばフェッチはサービスとして
     ‘git-upload-pack’ を使用します)。このコマンドに対する有効な応答は、
     空行(接続が確立されました)と、 ‘fallback’ (スマート転送サポートなし
     、バカ転送(dumb transports)にフォールバック)と、エラーメッセージが
     印刷された状態で終了するだけです(接続できません、フォールバックしよ
     うと気にしないで)。肯定(空)応答が改行で終了すると、サービスの出力が
     開始されます。接続が終了すると、リモートヘルパーは終了します。

     ヘルパーに "connect" 機能がある場合にサポートされます。

_stateless-connect_ <service>
     実験的: 内部使用のみ。 gitのワイヤープロトコルバージョン2を使用して
     通信するために、指定のリモートサービスに接続します。このコマンドへ
     の有効な応答は、空行(接続が確立されました)と、 ‘fall back’ (スマー
     ト転送サポートなし、バカ転送にフォールバック)と、エラーメッセージ出
     力するだけです(接続できません。わざわざフォールバックしようとしない
     でください)。 正の(空の)応答を終了する改行の後、サービスの出力が開
     始されます。 メッセージ(要求と応答の両方)は、0個以上のPKT-LINEで構
     成され、フラッシュパケットで終了する必要があります。 応答メッセージ
     には、応答の終了を示すフラッシュパケットの後に応答終了パケットがあ
     ります。 クライアントは、サーバーが要求と応答のペアの間に状態を保持
     することを期待してはなりません。接続が終了すると、リモートヘルパー
     が終了します。

     ヘルパーに "stateless-connect" 機能がある場合にサポートされます。

   致命的なエラーが発生した場合、プログラムはエラーメッセージをstderrに
書き込み、終了します。呼び出し元は、子が現在のコマンドに対する有効な応答
を完了せずに接続を閉じた場合に、適切なエラーメッセージを出力することを期
待します。

   ヘルパーによって報告された機能から判断できるように、追加のコマンドが
サポートされる場合があります。

REF LIST ATTRIBUTES
*******************

’list’コマンドは、各refの後に属性(attribute)のリストが続くことがある
refのリストを生成します。以下のrefリスト属性(ref list attributes)が定義
されています。

_unchanged_
     このrefは、最後にインポートまたはフェッチしたときから変更されていま
     せんが、ヘルパーは必ずしもどの値が生成されたかを判別することはでき
     るわけではありません。

REF LIST KEYWORDS
*****************

listコマンドは、キーと値のペア(key-value pairs)のリストを生成する場合が
あります。以下のキーが定義されています。

_object-format_
     refは指定のハッシュアルゴリズムを使用しています。このキーワードは、
     サーバーとクライアントの両方がオブジェクト形式の拡張機能
     (object-format extension)をサポートしている場合にのみ使用されます。

OPTIONS
*******

以下のオプションは、リモートヘルパーに option 機能がある場合にGitによっ
て定義され、(適切な状況下で)設定されます。

_option verbosity_ <n>
     ヘルパーによって表示されるメッセージの詳細度を変更します。 <n>の値
     0は、プロセスが静かに動作し、ヘルパーがエラー出力のみを生成すること
     を意味します。 1は冗長性のデフォルトレベルであり、<n>の値が大きさは
     、コマンドラインで渡される ‘-v’ フラグの数に対応します。

_option progress_ {_true_|_false_}
     コマンド実行中に転送(transport)ヘルパーによって表示される進行状況メ
     ッセージを有効(または無効)にします。

_option depth_ <depth>
     浅いリポジトリ(shallow repository)の履歴を深めます。

’option deepen-since <timestamp>
     時間に基づいて浅いリポジトリ(shallow repository)の履歴を深めます。

’option deepen-not <ref>
     refを除く浅いリポジトリ(shallow repository)の履歴を深めます。複数回
     使用できます。

_option deepen-relative {’true_|_false_}
     現在の境界に比べて浅いリポジトリの履歴を深めます。 「option depth」
     で使用する場合にのみ有効です。

_option followtags_ {_true_|_false_}
     有効にすると、フェッチコマンド中にタグが指すオブジェクトが転送され
     た場合、ヘルパーは注釈付きのタグオブジェクトを自動的にフェッチする
     必要があります。 タグがヘルパーによってフェッチされない場合、通常、
     2番目のフェッチコマンドが送信され、タグを具体的に要求します。一部の
     ヘルパーは、このオプションを使用して2番目のネットワーク接続を回避で
     きる場合があります。

_option dry-run_ {_true_|_false_}
     trueの場合、操作が正常に完了したふりをしますが、実際にはリポジトリ
     データを変更しません。 ほとんどのヘルパーの場合、これはサポートされ
     ている場合、 ‘push’ にのみ適用されます。

_option servpath <c-style-quoted-path>_
     次の接続のサービスパス(‘--upload-pack’ 、‘--receive-pack’ など)を設
     定します。 リモートヘルパーはこのオプションをサポートする場合があり
     ますが、接続要求が発生する前に、設定されているこのオプションに依存
     してはなりません。

_option check-connectivity_ {_true_|_false_}
     ヘルパーにクローンの接続を確認(check)するように依頼(request)します
     。

_option force_ {_true_|_false_}
     ヘルパーに強制更新を実行するように依頼(request)します。デフォルトは
     ‘false’ です。

_option cloning_ {_true_|_false_}
     これがクローンリクエストであることをヘルパーに通知します(つまり、現
     在のリポジトリは空であることが保証されています)。

_option update-shallow_ {_true_|_false_}
     新しいrefで必要な場合は、 .git/shallow を拡張できるようにします。

_option pushcert_ {_true_|_false_}
     GPG署名プッシュ。

’option push-option <string>
     <string>をプッシュオプションとして送信します。プッシュオプションに
     はLFまたはNUL文字を含めることはできないため、文字列はエンコードされ
     ません。

_option from-promisor_ {_true_|_false_}
     これらのオブジェクトがpromisorからフェッチされていることを示します
     。

_option no-dependents_ {_true_|_false_}
     依存関係ではなく、必要なオブジェクトのみをフェッチする必要があるこ
     とを示します。

_option atomic_ {_true_|_false_}
     プッシュするときは、リモートサーバーに単一のアトミックトランザクシ
     ョンで参照を更新するように要求します。 成功すると、すべての参照が更
     新されるか、何も更新されません。 リモート側がこの機能をサポートして
     いない場合、プッシュは失敗します。

_option object-format_ {_true_|algorithm}
     ‘true’ の場合、呼び出し元がハッシュアルゴリズム情報をリモートから返
     すことを望んでいることを示します。このモードは、参照をフェッチする
     ときに使用されます。

     アルゴリズムに設定されている場合は、発信者がそのアルゴリズムを使用
     してリモート側と対話することを希望していることを示します。

SEE ALSO
********

git-remote(1)

   git-remote-ext(1)

   git-remote-fd(1)

   git-fast-import(1)

GIT
***

Part of the git(1) suite

Name
****

gitrepository-layout — Gitリポジトリの間取り

Synopsis
********

$GIT_DIR/*

DESCRIPTION
***********

Gitリポジトリには2つの風味があります:

   • 作業ツリーのルートにある ‘.git’ ディレクトリ

   • bare(裸の)リポジトリである(つまり、独自の作業ツリーがない)「
     <project>.git」ディレクトリ。通常、このディレクトリにプッシュしてフ
     ェッチすることにより、他のユーザーと履歴を交換するために使用されま
     す。

   *注*: また、作業ツリーのルートにプレーンテキストファイル ‘.git’ を作
成できます。 このファイルには、リポジトリがある実際のディレクトリを指す
‘gitdir: <path>’ が含まれています。 このメカニズムは、サブモジュールチェ
ックアウトの作業ツリーによく使用され、 サブモジュールを含むスーパープロ
ジェクトで、 サブモジュールを持たないブランチを「git checkout」できるよ
うにします。 ‘checkout’ は、サブモジュールリポジトリを失うことなく、 サ
ブモジュール作業ツリー全体を削除する必要があります。

   以下のものがGitリポジトリに存在する可能性があります。

objects
     このリポジトリに関連付けられているオブジェクトストア。通常、オブジ
     ェクトストアは自給自足です(つまり、そこにあるオブジェクトによって参
     照されるすべてのオブジェクトもそこにあります)が、それに違反する方法
     はいくつかあります。

       1. 浅いクローン(shallow clone)を作成することにより、不完全である
          がローカルで使用可能なリポジトリを作成できます。 git-clone(1)
          を参照してください。

       2. ‘objects/info/alternates’ または
          ‘$GIT_ALTERNATE_OBJECT_DIRECTORIES’ メカニズムを使用して、他の
          オブジェクトストアからオブジェクトを「借用」(borrow)することが
          できます。この種の不完全なオブジェクトストアを持つリポジトリは
          、馬鹿プロトコル(dumb transport)で使用するために公開するのには
          適していませんが、それ以外の場合は「objects/info/alternates」
          が借用するオブジェクトストアを指している限り問題ありません。

          $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視さ
          れ、代わりに「$GIT_COMMON_DIR/objects」が使用されます。

objects/[0-9a-f][0-9a-f]
     新しく作成されたオブジェクトは、独自のファイルに保存されます。オブ
     ジェクトは、sha1オブジェクト名の最初の2文字を使用して、256個のサブ
     ディレクトリに分散され、 ‘objects’ 自体のディレクトリエントリの数を
     管理可能な数に保ちます。ここにあるオブジェクトは、「アンパックオブ
     ジェクト」(unpacked obuject)(または「ルーズオブジェクト」(loose
     object))と呼ばれることがよくあります。

objects/pack
     パック(多くのオブジェクトを圧縮形式で格納するファイルと、ランダムに
     アクセスできるようにするためのインデックスファイル)は、このディレク
     トリにあります。

objects/info
     オブジェクトストアに関する追加情報は、このディレクトリに記録されま
     す。

objects/info/packs
     このファイルは、馬鹿プロトコルがこのオブジェクトストアで使用可能な
     パックを検出するのに役立ちます。リポジトリが馬鹿プロトコル用に公開
     されている場合は、パックを追加または削除するたびに、 ‘git
     update-server-info’ を実行して、このファイルを最新の状態に保つ必要
     があります。 _git repack_ はデフォルトでこれを行います。

objects/info/alternates
     このファイルは、このオブジェクトストアがオブジェクトを借用
     (borrow)する代替オブジェクトストアへのパスを、1行に1つのパス名で記
     録します。ネイティブGitツールがローカルで使用するだけでなく、HTTP
     fetcher もリモートで使用しようとすることに注意してください。これは
     通常、代替ファイルに相対パス(リポジトリではなくオブジェクトデータベ
     ースに対して！)がある場合は機能しますが、ファイルシステムとWeb URLの
     絶対パスが同じでない限り、絶対パスを使用する場合は機能しません。
     ‘objects/info/http-alternates’ も参照してください。

objects/info/http-alternates
     このファイルは、このオブジェクトストアがオブジェクトを借用
     (borrow)する代替オブジェクトストアへのURLを記録し、リポジトリが
     HTTP経由でフェッチされるときに使用されます。

refs
     参照(reference)は、このディレクトリのサブディレクトリに保存されます
     。 _git prune_ コマンドは、このディレクトリとそのサブディレクトリに
     見つかったrefsから到達可能なオブジェクトを認識し保持します。
     $GIT_COMMON_DIRが設定されていて、代わりに「$GIT_COMMON_DIR/refs」が
     使用される場合、このディレクトリは無視されます(refs/bisectと
     refs/rewrittenとrefs/worktreeを除く)。

refs/heads/‘name’
     ブランチ ‘name’ のツリーの先端(tip-of-the-tree)のコミットオブジェク
     トを記録します

refs/tags/‘name’
     オブジェクト名を記録します(必ずしもコミットオブジェクト、またはコミ
     ットオブジェクトを指すタグオブジェクトである必要はありません)。

refs/remotes/‘name’
     リモートリポジトリからコピーされたブランチのツリーの先端
     (tip-of-the-tree)のコミットオブジェクトを記録します。

refs/replace/‘<obj-sha1>’
     ‘<obj-sha1>’ を置き換えるオブジェクトのSHA-1を記録します。これは
     info/graftsに似ており、 git-replace(1) によって内部的に使用および保
     守されます。 このようなrefsはリポジトリ間で交換できますが、graftsは
     交換できません。

packed-refs
     refs/heads/ や refs/tags/ と同じ情報を記録し、そして friends がより
     効率的な方法で記録します。 git-pack-refs(1) を参照してください。
     $GIT_COMMON_DIR が設定されている場合、このファイルは無視され、代わ
     りに「$GIT_COMMON_DIR/packed-refs」が使用されます。

HEAD
     現在アクティブなブランチを説明する ‘refs/heads/’ 名前空間へのシンボ
     リックref(symref;glossaryを参照)。リポジトリが作業ツリーに関連付け
     られていない場合(つまり、ベアリポジトリの場合)はあまり意味がありま
     せんが、有効なGitリポジトリにはHEADファイルが「必要」です。一部の磁
     器コマンドは、これを使用して、リポジトリの指定された「デフォルト」
     ブランチ(通常は「master」)を推測する場合があります。名前付きブラン
     チ _name_ が(まだ)存在しない場合も合法です。一部のレガシー設定では
     、現在のブランチを指すシンボリックref(symref)ではなくシンボリックリ
     ンクです。

     HEADは、現在のブランチを指すシンボリックref(symref)である代わりに、
     特定のコミットを直接記録することもできます。このような状態は「
     detached HEAD」と呼ばれることがよくあります。詳細については
     git-checkout(1)を参照してください。

config
     リポジトリ固有の構成ファイル。 $GIT_COMMON_DIR が設定されている場合
     、このファイルは無視され、代わりに「$GIT_COMMON_DIR/config」が使用
     されます。

config.worktree
     複数の作業ディレクトリ設定の、メイン作業ディレクトリための、作業デ
     ィレクトリ固有の構成ファイル(git-worktree(1) を参照)。

branches
     _git fetch_ や _git pull_ や _git push_ へのURLを指定するために使用
     される短縮形を格納するための、少々非推奨の方法。ファイルは
     ‘branches/<name>’ として保存でき、 _repository_ 引数の代わりに
     _name_ をこれらのコマンドに指定できます。詳細については、
     git-fetch(1) の REMOTES セクションを参照してください。この機構はレ
     ガシーであり、最新のリポジトリには見られない可能性があります。
     $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、
     代わりに「$GIT_COMMON_DIR/branches」が使用されます。

hooks
     フックは、さまざまなGitコマンドで使用されるカスタマイズスクリプトで
     す。 _git init_ を実行すると、いくつかのサンプルフックがインストー
     ルされますが、デフォルトではすべて無効になっています。有効にするに
     は、ファイル名から ‘.sample’ サフィックスを削除して名前を変更する必
     要があります。各フックの詳細については、 githooks(5) をお読みくださ
     い。 $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視さ
     れ、代わりに「$GIT_COMMON_DIR/hooks」が使用されます。

common
     複数の作業ツリーが使用されている場合、 $GIT_DIR 内のほとんどのファ
     イルは、いくつかの既知の例外を除いて、各作業ツリー毎とにありますで
     す。ただし、「common」の下にあるすべてのファイルは、すべての作業ツ
     リー間で共有されます。

index
     リポジトリの現在のインデックスファイル。通常、ベアリポジトリには見
     つかりません。

sharedindex.<SHA-1>
     $GIT_DIR/indexおよびその他の一時(temporary)インデックスファイルによ
     って参照される共有インデックス部分。スプリットインデックスモード
     (split index mode)でのみ有効です。

info
     リポジトリに関する追加情報は、このディレクトリに記録されます。
     $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、
     代わりに「$GIT_COMMON_DIR/info」が使用されます。

info/refs
     このファイルは、馬鹿プロトコル(dumb transports)がこのリポジトリで使
     用可能なrefsを検出するのに役立ちます。リポジトリが馬鹿プロトコル
     (dumb transports)用に公開されている場合、このファイルは、タグまたは
     ブランチが作成または変更されるたびに、「git update-server-info」に
     よって再生成される必要があります。これは通常、リポジトリに「git
     push」したときに「git-receive-pack」コマンドによって実行される「
     hooks/update」フックから実行されます。

info/grafts
     このファイルは、コミットが実際に作成された方法とは異なる親のセット
     を装うために、偽のコミットの祖先情報を記録します。1行に1つのレコー
     ドは、スペースで区切られ、改行で終了する40バイトの16進オブジェクト
     名をリストすることにより、コミットとその偽の親を記述します。

     graftsメカニズムは古臭く、リポジトリ間でオブジェクトを転送する際に
     問題が発生する可能性があることに注意してください。 同じことを行うた
     めのより柔軟で堅牢なシステムについては、 git-replace(1) を参照して
     ください。

info/exclude
     このファイルは、磁器コマンドの慣例により、除外パターンリストを格納
     します。 ‘.gitignore’ は、ディレクトリごとの無視ファイルです。「git
     status」、「git add」、「git rm」、「git clean」はこの除外パターン
     リストを調べますが、コアGitコマンドはこの除外パターンリストを調べま
     せん。 gitignore(5) も参照してください。

info/attributes
     ディレクトリごとの ‘.gitattributes’ ファイルと同様に、パスに割り当
     てる属性を定義します。 gitattributes(5) も参照してください。

info/sparse-checkout
     このファイルには、スパースチェックアウトパターン(sparse checkout
     patterns)が格納されています。 git-read-tree(1) も参照してください。

remotes
     _git fetch_ と _git pull_ と _git push_ コマンドを介してリモートリ
     ポジトリと対話するときに使用するURLの省略形とデフォルトのref名を格
     納します。詳細については、 git-fetch(1)のREMOTESセクションを参照し
     てください。このメカニズムはレガシーであり、最新のリポジトリには見
     られない可能性があります。 $GIT_COMMON_DIR が設定されている場合、こ
     のディレクトリは無視され、代わりに「$GIT_COMMON_DIR/remotes」が使用
     されます。

logs
     refに加えられた変更の記録は、このディレクトリに保存されます。詳細に
     ついては、 git-update-ref(1) を参照してください。 $GIT_COMMON_DIRが
     設定されていて、代わりに「$GIT_COMMON_DIR/logs」が使用される場合、
     このディレクトリは無視されます(但し、logs/HEADを除く)。

logs/refs/heads/‘name’
     ‘name’ という名前のブランチ先端(branch tip)に加えられたすべての変更
     を記録します。

logs/refs/tags/‘name’
     ‘name’ という名前のタグに加えられたすべての変更を記録します。

shallow
     これは ‘info/grafts’ に似ていますが、内部的に使用され、浅いクローン
     メカニズム(shallow clone mechanism)によって維持されます。
     git-clone(1) と git-fetch(1) の ‘--depth’ オプションを参照してくだ
     さい。 $GIT_COMMON_DIRが設定されている場合、このファイルは無視され
     、代わりに「$GIT_COMMON_DIR/shallow」が使用されます。

commondir
     このファイルが存在する場合、明示的に設定されていなければ、
     $GIT_COMMON_DIR (git(1) を参照)はこのファイルで指定されたパスに設定
     されます。指定されたパスが相対パスの場合、それは$GIT_DIRからの相対
     パスです。commondirのあるリポジトリは、「commondir」が指すリポジト
     リがないと不完全です。

modules
     サブモジュールのgitリポジトリが含まれています。

worktrees
     リンクされた作業ツリー(linked working trees)の管理データが含まれて
     います。各サブディレクトリには、リンクされた作業ツリーの作業ツリー
     関連部分が含まれています。 $GIT_COMMON_DIRが設定されている場合、こ
     のディレクトリは無視され、代わりに「$GIT_COMMON_DIR/worktrees」が使
     用されます。

worktrees/<id>/gitdir
     ここを指す .git ファイルに戻る絶対パスを含むテキストファイル。これ
     は、リンクされたリポジトリが手動で削除されているかどうかを確認する
     ために使用され、このディレクトリをこれ以上保持する必要はありません
     。 このファイルのmtimeは、リンクされたリポジトリにアクセスするたび
     に更新する必要があります。

worktrees/<id>/locked
     このファイルが存在する場合、リンクされた作業ツリーがポータブルデバ
     イス上にあり、使用できない可能性があります。このファイルが存在する
     と、 ‘git worktree prune’ によって ‘worktrees/<id>’ が自動または手
     動で剪定(prune)されるのを防ぎます。ファイルには、リポジトリがロック
     されている理由を説明する文字列が含まれている場合があります。

worktrees/<id>/config.worktree
     作業ディレクトリ固有の構成ファイル。

Git Repository Format Versions
******************************

すべてのgitリポジトリは、その ‘config’ ファイルの
‘core.repositoryformatversion’ キーに、バージョン数値が印されています。
このバージョン数値は、ディスク上のリポジトリデータを操作するためのルール
を指定します。 ディスク上のリポジトリから告知された特定のバージョンを理
解しないgitの実装は、そのリポジトリで動作してはなりません。そうすること
は、間違った結果を生み出すだけでなく、実際にデータを失うリスクがあります
。

   このルールのため、バージョンアップは最小限に抑える必要があります。代
わりに、我々は一般的に以下の戦略を好みます:

   • 個々のデータファイル(インデックス、パックファイルなど)のフォーマッ
     トバージョン番号をバージョンアップします。これにより、非互換性がそ
     れらのファイルのみに制限されます。

   • 古いクライアントで使用すると正常に機能制限される(gracefully
     degrade)新しいデータを導入します(たとえば、パックビットマップファイ
     ルは古いクライアントでは無視され、提供される最適化を利用しません)。

   リポジトリ全体の形式のバージョンアップは、個別にバージョン管理できな
い部分だけにするべきです。たとえば、オブジェクトの到達可能性ルール、また
はrefをロックするためのルールを変更する場合、リポジトリ形式バージョンの
バージョンアップが必要になります。

   注意: これは、リポジトリのディスクコンテンツに直接アクセスする場合に
のみ適用されることに注意してください。 フォーマット ‘0’ のみを理解する古
いクライアントは、サーバープロセスがフォーマット ‘1’ を理解している限り
、フォーマット ‘1’ を使用して ‘git://’ を介してリポジトリに接続できます
。

   バージョンアップをお披露目するための推奨される戦略(リポジトリ全体また
は単一ファイル)は、gitに新しい形式を読み取るように教え、(実験用または古
いgitとの下位互換性については気にしないでいいように)構成スイッチまたはコ
マンドラインオプションを使用して新しい形式を記述できるようにすることです
。その後、読み取り機能が一般的になるまでの長い期間の後、デフォルトを新し
い形式の書き込みに切り替える場合があります。

   現在定義されているフォーマットバージョンは以下のとおりです:

Version 0
=========

これは、gitの初期バージョンで定義されている形式であり、リポジトリディレ
クトリ、リポジトリ構成ファイル、オブジェクトおよびrefストレージの形式が
含まれま すが、これらに限定されません。gitの完全な動作を記述することは、
このドキュメントの役割ではありません。

Version 1
=========

この形式は、以下の例外を除いて、バージョン ‘0‘と同じです:

  1. ‘core.repositoryformatversion’ 変数を読み取る場合、バージョン1をサ
     ポートするgit実装は、構成ファイルの ‘extensions’ セクションにある構
     成キーも読み取る必要があります。

  2. バージョン1リポジトリが、実行中のgitが実装していない ‘extensions.*’
     キーを指定している場合、操作の続行は禁止です。同様に、既知のキーの
     値が実装によって理解されない場合、操作の続行は禁止です。

   注意: 設定ファイルに拡張機能(extension)の指定が無い場合は、
‘core.repositoryformatversion’ を ‘0’ に設定する必要があります(‘1‘に設定
してもメリットはなく、リポジトリはgitの古い実装と互換性がなくなります)。

   このドキュメントは、拡張機能のマスターリストとして機能します。新しい
拡張機能を定義したい実装は、名前を主張するために、ここにそれを書き留めて
おく必要があります。

   定義されている拡張機能は以下のとおりです:

noop
----

この拡張機能は、gitの動作をまったく変更しません。 これは、フォーマット
1の互換性をテストする場合にのみ役立ちます。

preciousObjects
---------------

設定キー ‘extensions.preciousObjects’ が ‘true’ に設定されている場合、リ
ポジトリ内のオブジェクトを削除してはなりません(たとえば、 ‘git-prune’ ま
たは ‘git repack -d’ など)。

partialclone
------------

設定キー ‘extensions.partialclone’ が設定されている場合、リポジトリが部
分クローンで作成された(または後で部分フェッチを実行した)こと、およびリモ
ートが特定の不要なオブジェクトの送信を省略した可能性があることを示します
。 このようなリモートはpromisor remoteと呼ばれ、将来、このような省略され
たオブジェクトをすべてフェッチできることを約束します。

   このキーの値は、promisor remoteの名前です。

worktreeConfig
--------------

設定されている場合、デフォルトでは、「git config」はGIT_DIRの「config」
ファイルと「config.worktree」ファイルの両方からこの順序で読み取ります。
複数の作業ディレクトリモードでは、「config.worktree」が作業ディレクトリ
ごとにある間（つまり、 GIT_COMMON_DIR/worktrees/<id>/config.worktree に
あります)、「config」ファイルは共有されます。

SEE ALSO
********

git-init(1), git-clone(1), git-fetch(1), git-pack-refs(1), git-gc(1),
git-checkout(1), gitglossary(7), The Git User’s Manual
(user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

gitrevisions — Gitのリビジョンと範囲を指定する

Synopsis
********

gitrevisions

DESCRIPTION
***********

多くのGitコマンドは、リビジョンパラメーターを引数として取ります。コマン
ドに応じて、特定のコミットを示します。リビジョングラフをたどるコマンド
(git-log(1) など)の場合は、そのコミットから到達可能なすべてのコミットを
示します。リビジョングラフをたどるコマンドの場合、リビジョンの範囲を明示
的に指定することもできます。

   さらに、一部のGitコマンド(git-show(1) や git-push(1) など)は、コミッ
ト以外のオブジェクトを示すリビジョンパラメーターを受け取ることもできます
。例えば、ブロブ(ファイル)またはツリー(ファイルのディレクトリ)です。

SPECIFYING REVISIONS
********************

リビジョンパラメータ ‘<rev>’ は必ずしもそうとは限りませんが、通常はコミ
ットオブジェクトに名前を付けます。これは、いわゆる「拡張SHA-1」構文を使
用します。 オブジェクト名を綴るにはさまざまな方法があります。このリスト
の終わり近くにリストされているものは、コミットに含まれているツリーとブロ
ブに名前を付けています。

     *Note*

     この文書は、gitで見られる「生の」構文を示しています。シェルおよびそ
     の他のUIでは、特殊文字を保護し、単語の分割を回避するために、追加の
     引用符が必要になる場合があります。

‘<sha1>’ 例: ‘dae86e1950b1277e545cee180551750029cfe735’, ‘dae86e’
     完全なSHA-1オブジェクト名(40バイトの16進文字列)、またはリポジトリ内
     で一意の先頭のsubstring。例えば
     dae86e1950b1277e545cee180551750029cfe735 と dae86e はどちらも、リポ
     ジトリ内にオブジェクト名が dae86e で始まる他のオブジェクトがない場
     合、全く同じコミットオブジェクトに名前を付けます。

‘<describeOutput>’ 例: ‘v1.7.4.2-679-g3bee7fb’
     ‘git describe’ からの出力。つまり、現在のコミットから最も近いタグ。
     オプションで、ダッシュ(-)とそのタグ以降現在のコミットが何番目になる
     かの数が続き、その後にダッシュ(-)、「g」、および省略されたオブジェ
     クト名が続きます。

‘<refname>’ 例: ‘master’, ‘heads/master’, ‘refs/heads/master’
     シンボリックref名。例えば ‘master’ は通常、 ‘refs/heads/master’ に
     よって参照されるコミットオブジェクトを意味します。 ‘heads/master’ と
     ‘tags/master’ の両方がある場合は、あなたは ‘heads/master’ と明示的
     に指定して、どちらを意味するかをGitに伝えることができます。 あいま
     いな場合、 ‘<refname>’ は、以下のルールに従い最初の一致を採用ことで
     明確になります:

       1. もし ‘$GIT_DIR/<refname>’ が存在するならば、それはあなたが指定
          した通りのものです(これは通常、‘HEAD’ と ‘FETCH_HEAD’ と
          ‘ORIG_HEAD’ と ‘MERGE_HEAD’ と ‘CHERRY_PICK_HEAD’ のみで役に立
          ちます)

       2. でなければ ‘refs/<refname>’ が存在すればそれを採用します。

       3. でなければ ‘refs/tags/<refname>’ が存在すればそれを採用します
          。

       4. でなければ ‘refs/heads/<refname>’ が存在すればそれを採用します
          。

       5. でなければ ‘refs/remotes/<refname>’ が存在すればそれを採用しま
          す。

       6. でなければ ‘refs/remotes/<refname>/HEAD’ が存在すればそれを採
          用します。

          ‘HEAD’ は、作業ツリーの変更に基づいたコミットに名前を付けます
          。 ‘FETCH_HEAD’ は、最後の ‘git fetch’ 呼び出しでリモートリポ
          ジトリからフェッチしたブランチを記録します。 ‘ORIG_HEAD’ は、
          ‘HEAD’ を大幅に移動するコマンドによって作成され、操作前の
          ‘HEAD’ の位置を記録します。これにより、ブランチの先端を実行前
          の状態に簡単に戻すことができます。 ‘MERGE_HEAD’ は、 ‘git
          merge’ を実行するときにブランチにマージするコミットを記録しま
          す。 ‘CHERRY_PICK_HEAD’ は、 ‘git cherry-pick’ を実行したとき
          にチェリーピックしているコミットを記録します。

          注意: 上記の ‘refs/*’ の場合、 ‘$GIT_DIR/refs’ ディレクトリま
          たは ‘$GIT_DIR/packed-refs’ ファイルのいずれかから発生する可能
          性があることに注意してください。ref名のエンコードは指定されて
          いませんが、一部の出力処理ではUTF-8でref名を想定する場合がある
          ため、UTF-8が推奨されます。

‘@’
     ‘@’ 単独では ‘HEAD’ のショートカットを意味します。

‘[<refname>]@{<date>}’ 例: ‘master@{yesterday}’, ‘HEAD@{5 minutes ago}’
     refの後に接尾辞 ‘@’ が続き、日付指定が中括弧のペアで囲まれています
     (例: ‘{yesterday}’ 、 ‘{1 month 2 weeks 3 days 1 hour 1 second
     ago}’ 、‘{1979-02-26 18:30:00}’ )。これは以前の時点でのrefの値を指
     定します。この接尾辞は、ref名の直後にのみ使用でき、refには既存のロ
     グ( ‘$GIT_DIR/logs/<ref>’ )が必要です。これは、特定の時点での *ロー
     カル* refの状態を検索することに注意してください。たとえば、先週ロー
     カルの ‘master’ ブランチに何があったか、です。特定の時間に行われた
     コミットを確認する場合は、 ‘--since’ と ‘--until’ を参照してくださ
     い。

‘<refname>@{<n>}’ 例: ‘master@{1}’
     refの後に接尾辞 ‘@’ が続き、数の指定が中括弧のペアで囲まれている場
     合(たとえば ‘{1}’, ‘{15}’)、そのrefのn個前の値を指定します。たとえ
     ば ‘master@{1}’ は ‘master’ の直前の値であり、 ‘master@{5}’ は
     ‘master’ の5個前の値です。この接頭辞は、ref名の直後にのみ使用でき、
     refには既存のログ( ‘$GIT_DIR/logs/<refname>’ )が必要です。

‘@{<n>}’ 例: ‘@{1}’
     空のref部分で ‘@’ コンストラクトを使用して、現在のブランチの
     reflogエントリを取得できます。たとえば、あなたがブランチ ‘blabla’ を
     使用している場合、 ‘@{1}’ は ‘blabla@{1}’ と同じ意味になります。

‘@{-<n>}’ 例: ‘@{-1}’
     構成 ‘@{-<n>}’ は、現在のブランチ/コミットの前にチェックアウトされ
     た<n>番目のブランチ/コミットを意味します。

‘[<branchname>]@{upstream}’ 例: ‘master@{upstream}’, ‘@{u}’
     ブランチ名の接尾辞 ‘@{upstream}’ (短縮形 ‘<branchname>@{u}’)は、
     branchnameで指定されたブランチの上部に構築するように設定されている
     ブランチを指します(‘branch.<name>.remote’ と ‘branch.<name>.merge’
     によって設定されます)。ブランチ名が欠落している場合は、デフォルトで
     現在のブランチ名になります。これらの接尾辞は、大文字で綴る場合にも
     受け入れられ、大文字と小文字を問わず同じ意味になります。

‘[<branchname>]@{push}’ 例: ‘master@{push}’, ‘@{push}’
     接尾辞 ‘@\{push}’ は、 ‘branchname’ がチェックアウトされているとき
     に ‘git push’ が実行された場合(またはブランチ名が指定されていない場
     合は現在の ‘HEAD’ )、「プッシュ先」のブランチを報告します。もちろん
     、プッシュ先はリモートリポジトリにあるため、そのブランチに対応する
     ローカルトラッキングブランチ(つまり、 ‘refs/remotes/’ 内の何か)を報
     告します。

     ここで、よりはっきり分かる例を以下に示します:

          $ git config push.default current
          $ git config remote.pushdefault myfork
          $ git switch -c mybranch origin/master

          $ git rev-parse --symbolic-full-name @{upstream}
          refs/remotes/origin/master

          $ git rev-parse --symbolic-full-name @{push}
          refs/remotes/myfork/mybranch

     注意: この例では、ある場所からプルして別の場所にプッシュする三角形
     のワークフローを設定していることに注意してください。非三角形のワー
     クフローでは、 ‘@\{push}’ は ‘@\{upstream}’ と同じであり、このよう
     なことをする必要はありません。

     この接尾辞は大文字で綴る場合にも受け入れられ、大文字と小文字を問わ
     ず同じことを意味します。

‘<rev>^[<n>]’ 例: ‘HEAD^, v1.5.1^0’
     リビジョンパラメータの接尾辞 ‘^’ は、そのコミットオブジェクトの最初
     の親を意味します。 ‘^<n>’ は <n> 番目の親を意味します(つまり、
     ‘<rev>^’ は ‘<rev>^1’ と同じです)。特別ルールとして、 ‘<rev>^0’ は
     コミット自体を意味し、 ‘<rev>’ がコミットオブジェクトを参照するタグ
     オブジェクトのオブジェクト名である場合に使用されます。

‘<rev>~[<n>]’ 例: ‘HEAD~, master~3’
     リビジョンパラメータの接尾辞 ‘~’ は、そのコミットオブジェクトの最初
     の親を意味します。リビジョンパラメータの接尾辞 ‘~<n>’ は、最初の親
     のみに続く、指定されたコミットオブジェクトの <n> 世代の祖先であるコ
     ミットオブジェクトを意味します。つまり、 ‘<rev>~3’ は ‘<rev>^^^’ と
     同じで、するってぇと ‘<rev>^1^1^1’ と同じということです。この形式に
     ついては以下の図を参照してください。

‘<rev>^{<type>}’ 例: ‘v0.99.8^{commit}’
     接尾辞 ‘^’ の後に中括弧のペアで囲まれたオブジェクトタイプ名が続くと
     いうことは、タイプ ‘<type>’ のオブジェクトが見つかるか、オブジェク
     トを逆参照できなくなるまで、 ‘<rev>’ でオブジェクトを再帰的に逆参照
     する(この場合は、いろいろ一旦飲み込んでしまったのを吐きもどすような
     感じだぬ)ことを意味します。 たとえば、 ‘<rev>’ がコミットっぽい場合
     、 ‘<rev>^{commit}’ は対応するコミットオブジェクトを記述します。同
     様に、 ‘<rev>’ がツリーっぽい場合、 ‘<rev>^{tree}’ は対応するツリー
     オブジェクトを記述します。 ‘<rev>^0’ は ‘<rev>^{commit}’ の省略形で
     す。

     ‘<rev>^{object}’ を使用すると、 ‘<rev>’ がタグである必要がなく、
     ‘<rev>’ を逆参照することなく、 ‘<rev>’ が存在するオブジェクトに名前
     を付けることができます。なお、タグはすでにオブジェクトであるため、
     オブジェクトに到達するために一度も逆参照する必要はありません。

     ‘<rev>^{tag}’ を使用して、 ‘<rev>’ が既存のタグオブジェクトを確実に
     識別することができます。

‘<rev>^{}’ 例: ‘v0.99.8^{}’
     接尾辞 ‘^’ の後に空のブレースペアが続くということは、オブジェクトが
     タグである可能性があることを意味し、タグ以外のオブジェクトが見つか
     るまでタグを再帰的に逆参照します。

‘<rev>^{/<text>}’ 例: ‘HEAD^{/fix nasty bug}’
     リビジョンパラメータの接尾辞 ‘^’ と、それに続くスラッシュで始まるテ
     キストを含む中括弧のペアは、以下の ‘:/fix nasty bug’ 構文と同じです
     が、 ‘^’ の前の ‘<rev>’ から到達可能な一致する最も若いコミットを返
     す点が異なります。

‘:/<text>’ 例: ‘:/fix nasty bug’
     コロンに続いてスラッシュそしてそれに続くテキストは、コミットメッセ
     ージが指定された正規表現と一致するコミットを示します。この名前は、
     HEADを含む任意のrefから到達可能な最も若い一致するコミットを返します
     。正規表現は、コミットメッセージの任意の部分に一致できます。文字列
     で始まるメッセージを照合するには、たとえば、 ‘:/^foo’ とします。特
     別なシーケンス ‘:/!’ はマッチングの修飾子用に予約されています。ます
     。 ‘:/!-foo’ は一致の否定を実行し、 ‘:/!!foo’ はリテラル ‘!’ 後に
     ‘foo’ が続く文字列とマッチします。 ‘:/!’ で始まるその他のシーケンス
     は今のところ予約されています。指定されたテキストによっては、シェル
     により追加の引用符が必要になる場合があります。

‘<rev>:<path>’ 例: ‘HEAD:README’, ‘master:./README’
     接尾辞 ‘:’ の後にパス(path)を続けると、コロンの前の部分によって名前
     が付けられたツリー風のオブジェクト内の、指定されたパスにあるブロブ
     またはツリーに名前が付けられます。 ‘./’ または ‘../’ で始まるパスは
     、現在の作業ディレクトリからの相対パスです。指定のパスは、作業ツリ
     ーのルートディレクトリからの相対パスに変換されます。これは、作業ツ
     リーと同じツリー構造を持つコミットまたはツリーからブロブまたはツリ
     ーをアドレス指定するのに最も役立ちます。

‘:[<n>:]<path>’ 例: ‘:0:README’, ‘:README’
     コロンに、オプションでステージ番号(0〜3)とコロンが続き、それにパス
     が続くと、指定されたパスのインデックス内のブロブオブジェクトに名前
     を付けます。ステージ番号省略(およびそれに続くコロン)は、ステージ0エ
     ントリーを示します。マージ作業中、ステージ1は共通の祖先、ステージ
     2はターゲットブランチのバージョン(通常は現在のブランチ)、ステージ
     3はマージされるブランチのバージョンです。

   以下はJon Loeligerによる図解です。コミットノードBとCはどちらもコミッ
トノードAの親です。親コミットは左から右に順序付けられます。

     G   H   I   J
      \ /     \ /
       D   E   F
        \  |  / \
         \ | /   |
          \|/    |
           B     C
            \   /
             \ /
              A

     A =      = A^0
     B = A^   = A^1     = A~1
     C =      = A^2
     D = A^^  = A^1^1   = A~2
     E = B^2  = A^^2
     F = B^3  = A^^3
     G = A^^^ = A^1^1^1 = A~3
     H = D^2  = B^^2    = A^^^2  = A~2^2
     I = F^   = B^3^    = A^^3^
     J = F^2  = B^3^2   = A^^3^2

SPECIFYING RANGES
*****************

‘git log’ などの履歴トラバースコマンドは、単一のコミットだけでなく、一連
のコミットで動作します。

   これらのコマンドの場合、前のセクションで説明した表記法を使用して単一
のリビジョンを指定することは、指定のコミットから「到達可能」なコミットの
組を意味します。

   複数のリビジョンを指定するということは、指定のコミットのいずれかから
到達可能なコミットの組を意味します。

   コミットの到達可能な組は、コミット自体とその祖先チェーン内のコミット
です。

   以下に示すように、接続されたコミット(connected commits)の組(「リビジ
ョン範囲」(revision range)と呼ばれる)を指定するためのいくつかの表記法が
あります。

Commit Exclusions
=================

‘^<rev>’ (カレット)記法
     とある到達可能なコミットをコミット達から除外するには、接頭辞 ‘^’ 表
     記を使用します。 例えば ‘^r1 r2’ は ‘r2’ から到達可能なコミットだけ
     ども、 ‘r1’ から到達可能なコミット(つまり ‘r1’ とその祖先)は除外す
     る事を意味します。

Dotted Range Notations
======================

‘..’ (2ドット)範囲記法
     ‘^r1 r2’ 操作は頻繁に表示されるため、省略形があります。(上記の
     SPECIFYING REVISIONS で説明されている構文に従って名前が付けられてい
     る)2つのコミット ‘r1’ と ‘r2’ がある場合、あなたは ‘^r1 r2’ によっ
     てr1から到達可能なコミットを取り除き、r2から到達可能なコミットを要
     求できます。そしてこれは ‘r1..r2’ と書くことができます。

‘...’ (3ドット)対称差記法
     似た表記 ‘r1...r2’ は ‘r1’ と ‘r2’ の対称差と呼ばれ、 ‘r1 r2 --not
     $(git merge-base --all r1 r2)’ として定義されます。 これは、 ‘r1’
     (左側)または ‘r2’ (右側)のいずれかから到達可能であるが、両方からは
     到達できないコミットの組です。

   これらの2つの省略表記では、一方の端を省略して、デフォルトでHEADにする
ことができます。たとえば、 ‘origin..’ は ‘origin..HEAD’ の省略形であり、
「originブランチから分岐(fork)してから何をしましたか？」と尋ねます。 同
様に、 ‘..origin’ は ‘HEAD..origin’ の省略形であり、「私がそれらから分岐
してから、originは何をしましたか？」と尋ねます。 ‘..’ は ‘HEAD..HEAD’ を
意味することに注意してください。これは、HEADから到達可能および到達不能の
両方の空の範囲です。

   2つの異なる範囲を取るように特別に設計されたコマンド(たとえば、2つの範
囲を比較するための "git range-diff R1 R2" ) は存在しますが、それらは例外
です。特に明記されていない限り、一連のコミットを操作するすべての "git" コ
マンドは、単一のリビジョン範囲で機能します。言い換えると、2つの「2ドット
範囲表記」を隣り合わせに記述します。

     $ git log A..B C..D

   ほとんどのコマンドでは2つのリビジョン範囲を指定しません。代わりに、接
続された単一のコミットの組、つまりBまたはDのいずれかから到達可能であるが
、AまたはCのどちらからも到達可能でないコミットの組に名前を付けます。線形
履歴では、以下のようになります:

     ---A---B---o---o---C---D

   AとBはCから到達可能であるため、これら2つの2ドット範囲記法で指定された
リビジョン範囲は単一のコミットDです。

Other <rev>^ Parent Shorthand Notations
=======================================

コミットとその親コミットによって形成される組に名前を付けるために、マージ
コミットに特に役立つ他の3つの省略形が存在します。

   ‘r1^@’ 表記は、 ‘r1’ のすべての親を意味します。

   ‘r1^!’ 表記には コミット ‘r1’ が含まれますが、そのすべての親は除外さ
れます。この表記自体は、単一のコミット ‘r1’ を示します。

   ‘<rev>^-[<n>]’ 表記には ‘<rev>’ が含まれますが、 <n> 番目の親(つまり
、 ‘<rev>^<n>..<rev>’ の省略形)は除外されます。 <n> が指定されていない場
合は ‘<n>’ = 1 とみなします。これは通常、 ‘<commit>^-’ を渡すだけで、マ
ージコミット ‘<commit>’(‘<commit>’ 自体を含む)でマージされたブランチ内の
すべてのコミットを取得できるマージコミットに役立ちます。

   ‘<rev>^<n>’ は単一のコミット親を指定することに関するものでしたが、こ
れらの3つの表記はその親も考慮します。たとえば、 ‘HEAD^2^@’ と言うことは
できますが、 ‘HEAD^@^2’ と言うことはできません。

Revision Range Summary
**********************

‘<rev>’
     <rev> から到達可能なコミット(つまり <rev> とその祖先)を含めます。

‘^<rev>’
     <rev> から到達可能なコミット(つまり <rev> とその祖先)を除外します。

‘<rev1>..<rev2>’
     <rev2> から到達可能なコミットを含めますが、 <rev1> から到達可能なコ
     ミットは除外します。 <rev1> または <rev2> のいずれかを省略すると、
     それらはそれぞれデフォルトで ‘HEAD’ になります。

‘<rev1>...<rev2>’
     <rev1> または <rev2> のいずれかから到達可能なコミットを含めますが、
     両方から到達可能なコミットは除外します。 <rev1> または <rev2> のい
     ずれかを省略すると、それらはそれぞれデフォルトで ‘HEAD’ になります
     。

‘<rev>^@’ 例: ‘HEAD^@’
     接尾辞 ‘^’ の後にアットマーク(‘@’)を付けることは、 ‘<rev>’ のすべて
     の親をリストすることと同じです(つまり、親から到達可能なものはすべて
     含まれますが、コミット自体は含まれません)。

‘<rev>^!’ 例: ‘HEAD^!’
     接尾辞 ‘^’ の後に感嘆符(‘!’)を付けることは、コミット ‘<rev>’ を指定
     し、そのすべての親の前に ‘^’ を付けてそれら(およびその祖先)を除外す
     ることと同じです。

‘<rev>^-<n>’ 例: ‘HEAD^-, HEAD^-2’
     ‘<rev>^<n>..<rev>’ と同等であり、 ‘<n>’ が指定されていない場合は
     ‘<n>’ = 1 です。

   上記のLoeliger図解を使用したいくつかの例を以下に示します。表記の拡張
と選択は、それぞれ段階が分かるようステップを踏んで説明してあります:

        Args   Expanded arguments    Selected commits
        D                            G H D
        D F                          G H I J D F
        ^G D                         H D
        ^D B                         E I J F B
        ^D B C                       E I J F B C
        C                            I J F C
        B..C   = ^B C                C
        B...C  = B ^F C              G H D E B C
        B^-    = B^..B
               = ^B^1 B              E I J F B
        C^@    = C^1
               = F                   I J F
        B^@    = B^1 B^2 B^3
               = D E F               D G H E F I J
        C^!    = C ^C^@
               = C ^C^1
               = C ^F                C
        B^!    = B ^B^@
               = B ^B^1 ^B^2 ^B^3
               = B ^D ^E ^F          B
        F^! D  = F ^I ^J D           G H D F

SEE ALSO
********

git-rev-parse(1)

GIT
***

Part of the git(1) suite

Name
****

gitsubmodules — あるリポジトリを別のリポジトリ内にマウントする

Synopsis
********

     .gitmodules, $GIT_DIR/config

     git submodule
     git <command> --recurse-submodules

DESCRIPTION
***********

サブモジュール(submodule)は、別のリポジトリ内に埋め込まれたリポジトリで
す。サブモジュールにはサブモジュール独自の履歴があります。 それが埋め込
まれているリポジトリはスーパープロジェクト(superproject)と呼ばれます。

   ファイルシステムでは、サブモジュールは通常(常にではありませんが。以下
のFORMSを参照)、(i)スーパープロジェクトの ‘$GIT_DIR/modules/’ ディレクト
リの下にあるGitディレクトリや、(ii)スーパープロジェクトの作業ディレクト
リ内の作業ディレクトリや、(i)の指すサブモジュールの作業ディレクトリのル
ートにある ‘.git’ ファイルで構成されます。

   サブモジュールのGitディレクトリが ‘$GIT_DIR/modules/foo/’ にあり、作
業ディレクトリが ‘path/to/bar/’ にあるとすると、スーパープロジェクトは、
ツリーの ‘path/to/bar’ にある ‘gitlink’ エントリと、‘submodule.foo.path
= path/to/bar’ 形式の ‘.gitmodules’ ファイル(linkgit: gitmodules[5] を参
照)のエントリを介してサブモジュールを追跡します。

   ‘gitlink’ エントリには、スーパープロジェクトがサブモジュールの作業デ
ィレクトリにあると予想するコミットのオブジェクト名が含まれています。

   ‘.gitmodules’ ファイルのセクション ‘submodule.foo.*’ は、Gitの磁器レ
イヤーに追加のヒントを提供します。 たとえば、 ‘submodule.foo.url’ 設定は
、サブモジュールを取得する場所を指定します。

   サブモジュールは、少なくとも2つの異なるユースケースに使用できます:

  1. 独立した履歴を維持しながら別のプロジェクトを使用。サブモジュールを
     使用すると、両方のプロジェクトの履歴を分離したまま、あなた独自の作
     業ツリー内に別のプロジェクトの作業ツリーを含めることができます。ま
     た、サブモジュールは任意のバージョンに固定できるため、別のプロジェ
     クトは、スーパープロジェクトに影響を与えることなく独立して開発でき
     、スーパープロジェクトプロジェクトが必要とした場合にのみ別プロジェ
     クトを新しいバージョンに固定できます。

  2. (論理的に単一の)プロジェクトを複数のリポジトリに分割し、それらを結
     び付けます。これを使用して、Gitの実装の現在の制限を克服し、よりきめ
     細かいアクセスを実現できます:

     Gitリポジトリのサイズ
          現在の形式では、 Gitは、ツリー間のデルタ計算によって圧縮されて
          いないコンテンツを含む大規模なリポジトリではスケールアップが十
          分にできません。 たとえば、あなたはサブモジュールを使用して大
          きなバイナリアセットを保持し、 これらのリポジトリを浅く複製し
          て、 ローカルに大きな履歴がないようにすることができます。

     転送サイズ
          現在の形式では、Gitは作業ツリー全体が存在する必要があります。
          部分的なツリーをフェッチまたはクローンで転送することはできませ
          ん。 あなたが作業しているプロジェクトが、 スーパープロジェクト
          のサブモジュールとして結合された複数のリポジトリで構成されてい
          る場合は、 関心のないリポジトリの作業ツリーをフェッチすること
          を回避できます。

     アクセス制御
          サブモジュールへのユーザーアクセスを制限することにより、 さま
          ざまなユーザーの読み取り/書き込みポリシーを実装できます。

The configuration of submodules
*******************************

サブモジュール操作は、以下のメカニズムを使用して構成(configure)できます
(優先順位の高い順です):

   • パススペックの一部としてサブモジュールを使用することをサポートする
     コマンドのコマンドライン。 ほとんどのコマンドには、サブモジュールに
     再帰するかどうかを指定するブールフラグ ‘--recurse-submodules’ があ
     ります。 例としては、 ‘grep’ や ‘checkout’ があります。 ‘fetch’ や
     ‘push’ などの一部のコマンドは、サブモジュールがどのように影響を受け
     るかを指定できる列挙型を取ります。

   • サブモジュール内の構成。 これには、サブモジュール内の
     ‘$GIT_DIR/config’ だけでなく、サブモジュール内のコマンドの動作を指
     定する ‘.gitattributes’ または ‘.gitignore’ ファイルなどのツリー内
     の設定も含まれます。

     たとえば、スーパープロジェクトで ‘git status
     --ignore-submodules=none’ を実行すると、サブモジュールの
     ‘.gitignore’ ファイルの効果が確認できます。これは、サブモジュールの
     ‘.gitignore’ ファイルに注意を払いながらサブモジュールで ‘status’ を
     実行することにより、サブモジュールの作業ディレクトリから情報を収集
     します。

     サブモジュールの ‘$GIT_DIR/config’ ファイルは、スーパープロジェクト
     で ‘git push --recurse-submodules=check’ を実行すると機能します。こ
     れは、サブモジュールにリモートに公開されていない変更があるかどうか
     をチェックするためです。リモートは、通常どおりサブモジュールの
     ‘$GIT_DIR/config’ ファイルで構成されます。

   • スーパープロジェクトの構成ファイル ‘$GIT_DIR/config’ 。Gitはアクテ
     ィブなサブモジュールのみ再帰します(以下の「ACTIVE SUBMODULES」セク
     ションを参照)。

     サブモジュールがまだ初期化されていない場合、サブモジュール内の構成
     (configuration)はまだ存在しないため、たとえば、サブモジュールを取得
     する場所はここで構成されます。

   • スーパープロジェクト内の ‘.gitmodules’ ファイル。プロジェクトは通常
     、このファイルを使用して、サブモジュールの名前とパスの間に必要なマ
     ッピングについて、上流のリポジトリコレクションのデフォルトを提案し
     ます。

     このファイルは主に、スーパープロジェクト内のサブモジュールの名前と
     パスの間のマッピングとして機能し、サブモジュールのGitディレクトリを
     見つけることができます。

     サブモジュールが初期化されていない場合、これはサブモジュール構成が
     見つかる唯一の場所です。 これは、サブモジュールを取得する場所を指定
     するための最後のフォールバックとして機能します。

FORMS
*****

サブモジュールは以下の形式をとることができます:

   DESCRIPTIONで説明されている、Gitディレクトリと、作業ディレクトリと、
‘gitlink’ と、 ‘.gitmodules‘エントリ、を含む基本形式。

   「古い形式」のサブモジュール: ‘.git’ ディレクトリが埋め込まれた作業デ
ィレクトリと、スーパープロジェクトの ‘gitlink’ および ‘.gitmodules’ エン
トリの追跡。 これは通常、古いバージョンのGitを使用して生成されたリポジト
リにあります。

   + これらの古い形式のリポジトリを手動で構築することは可能です。

   + 非初期化(deinitialized)または削除されると(以下を参照)、サブモジュー
ルのGitディレクトリはスーパープロジェクトの ‘$GIT_DIR/modules/<name>/’ に
自動的に移動されます。

   非初期化された(deinitialized)サブモジュール: ‘gitlink’ と
‘.gitmodules’ エントリがありますが、サブモジュールの作業ディレクトリはあ
りません。サブモジュールのGitディレクトリは、Gitディレクトリを初期化解除
した後も保持されているため、そこにある可能性があります。 代わりに、作業
ディレクトリであるはずのディレクトリが空になります。

   + サブモジュールは、 ‘git submodule deinit’ を実行することで非初期化
(deinitialized)できます。このコマンドは、作業ディレクトリを空にするだけ
でなく、スーパープロジェクトの ‘$GIT_DIR/config’ ファイルのみを変更する
ため、スーパープロジェクトの履歴は影響を受けません。 これは、 ‘git
submodule init’ を使用して元に戻すことができます。

   削除されたサブモジュール: サブモジュールは、 ‘git rm <submodule path>
&& git commit’ を実行することで削除できます。これは、 ‘git revert’ を使
用して元に戻すことができます。

   + 削除すると、スーパープロジェクトの追跡データが削除されます。これは
、 ‘gitlink’ エントリと ‘.gitmodules’ ファイルのセクションの両方です。サ
ブモジュールの作業ディレクトリはファイルシステムから削除されますが、
Gitディレクトリは、別のリポジトリからフェッチすることなく過去のコミット
をチェックアウトできるようにするために保持されます。

   + サブモジュールを完全に削除するには、手動で
‘$GIT_DIR/modules/<name>/’ を削除します。

ACTIVE SUBMODULES
*****************

サブモジュールがアクティブと見なされるには、

  1. if ‘submodule.<name>.active’ が ‘true’ に設定されている

     or

  2. if サブモジュールのパスが ‘submodule.active’ のパススペックと一致す
     る

     or

  3. if ‘submodule.<name>.url’ が設定されている

   これらは上記の順序で評価されます。

   例:

       [submodule "foo"]
         active = false
         url = https://example.org/foo
       [submodule "bar"]
         active = true
         url = https://example.org/bar
       [submodule "baz"]
         url = https://example.org/baz

   上記の構成では、サブモジュール ‘bar’ と ‘baz’ のみがアクティブになり
ます。 ‘bar’ は上記(1)により、 ‘baz’ は上記(3)によりアクティブになります
。 (1)が(3)よりも優先されるため、 ‘foo’ は非アクティブです。

   上記(1)と(2)でサブモジュールがアクティブでないことを指定している場合
は、(3)は歴史的遺物であり、無視されることに注意してください。 つまり、
‘submodule.<name>.active’ が ‘false’ に設定されている場合、またはサブモ
ジュールのパスが ‘submodule.active’ のパススペックで除外されている場合、
URLは存在するかどうかは関係ありません。これを以下の例に示します。

       [submodule "foo"]
         active = true
         url = https://example.org/foo
       [submodule "bar"]
         url = https://example.org/bar
       [submodule "baz"]
         url = https://example.org/baz
       [submodule "bob"]
         ignore = true
       [submodule]
         active = b*
         active = :(exclude) baz

   ここでは、 baz を除くすべてのサブモジュール(foo、bar、bob)がアクティ
ブになっています。 foo はそれ自体のアクティブフラグによるものであり、他
のすべては submodule active パススペック によるものです。これは、 .url フ
ィールドの存在に関係なく、baz を除く _b_ で始まるすべてのサブモジュール
もアクティブであることを指定します。

Workflow for a third party library
**********************************

       # サブモジュールの追加
       git submodule add <url> <path>

       # ときどきサブモジュールを新しいバージョンに更新します:
       git -C <path> checkout <new version>
       git add <path>
       git commit -m "update submodule to new version"

       # スーパープロジェクト内でサブモジュールのリストを表示します
       git submodule status

       # サブモジュールの削除については、「FORMS」を参照してください

Workflow for an artificially split repo
***************************************

       # 関連するコマンドの再帰(recursion)を有効にし、
       # 対象のコマンドがデフォルトでサブモジュールで再帰処理するようにします
       git config --global submodule.recurse true

       # 他のほとんどのコマンドとは異なり、
       # cloneには独自の再帰フラグが必要です:
       git clone --recurse <URL> <directory>
       cd <directory>

       # (ソース)コードを知る為に取得する
       git grep foo
       git ls-files --recurse-submodules

     *Note*

     ‘git ls-files’ もまた、それ独自の ‘--recurse-submodules’ フラグが必
     要です。

       # 新しいコードを得る
       git fetch
       git pull --rebase

       # 作業ツリーの変更
       git checkout
       git reset

Implementation details
**********************

サブモジュールを含むリポジトリのクローンを作成またはプルする場合、デフォ
ルトではサブモジュールはチェックアウトされません。クローンにサブモジュー
ルに再帰するように指示できます。 ‘git submodule’ の ‘init’ および
‘update’ サブコマンドは、チェックアウトされたサブモジュールを維持し、作
業ツリーの適切なリビジョンに維持します。 または、 ‘submodule.recurse’ を
設定して ‘checkout’ をサブモジュールに再帰させることもできます(
‘submodule.recurse’ は他のGitコマンドにも影響することに注意してください
。完全なリストについてはgit-config(1) を参照してください)。

SEE ALSO
********

git-submodule(1), gitmodules(5).

GIT
***

Part of the git(1) suite

Name
****

gittutorial-2 — Git入門パート2

Synopsis
********

     git *

DESCRIPTION
***********

このGit入門パート2を読む前に、 gittutorial(7) (Git入門)を読んで下さい。

   この入門の目的は、Gitのアーキテクチャの2つの基本的な部分(オブジェクト
データベースとインデックスファイル)を紹介し、残りのGit文書を理解するため
に必要なすべてのものを読者に提供することです。

The Git object database
***********************

新しいプロジェクトを開始して、履歴を少々作成しましょう:

     $ mkdir test-project
     $ cd test-project
     $ git init
     Initialized empty Git repository in .git/
     $ echo 'hello world' > file.txt
     $ git add .
     $ git commit -a -m "initial commit"
     [master (root-commit) 54196cc] initial commit
      1 file changed, 1 insertion(+)
      create mode 100644 file.txt
     $ echo 'hello world!' >file.txt
     $ git commit -a -m "add emphasis"
     [master c4d59f3] add emphasis
      1 file changed, 1 insertion(+), 1 deletion(-)

   さて、ここで、Gitがコミットで返してきた7桁の16進数は一体何でしょうか
？

   入門のパート1で、コミットには名前が付いていることがわかりました。
Git履歴内のすべてのオブジェクトは、40桁の16進名で保存されていることがわ
かりました。その名前は、オブジェクトの内容のSHA-1ハッシュです。特に、こ
れにより、Gitが同じデータを2回保存することはなく(同一のデータには同一の
SHA-1名が付けられるため)、Gitオブジェクトの内容が変更されることはありま
せん(オブジェクトの名前も変更されるため)。ここでの7文字の16進文字列は、
このような40文字の長さの文字列の略語です。 略語は、明確である限り(訳注
:その環境で一意になる限り)、40文字の16進文字列を使用できるすべての場所で
使用できます。

   上記の例に従って作成したコミットオブジェクトのコンテンツは、コミット
オブジェクトが作成された時刻とコミットを実行した人の名前を記録するため、
上記とは異なるSHA-1ハッシュを生成することが期待されます。

   ‘cat-file’ コマンドを使用して、この特定のオブジェクトについてGitに問
い合わせることができます。上記の例から40桁の16進数をコピーするのではなく
、あなたの手元で実行したバージョンの16進数を使用してください。40桁すべて
の16進数を入力する手間を省くために、数文字に短縮できることに注目です:

     $ git cat-file -t 54196cc2
     commit
     $ git cat-file commit 54196cc2
     tree 92b8b694ffb1675e5975148e1121810081dbdffe
     author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
     committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500

     initial commit

   ツリーは、それぞれがファイルに対応する、1つ以上のブロブ(blob)オブジェ
クトを参照できます。さらに、ツリーは他のツリーオブジェクトを参照すること
もできるため、ディレクトリ階層が作成されます。 ls-tree を使用して任意の
ツリーの内容を調べることができます(その際、SHA-1の最初の部分を指定するだ
けで十分なことを忘れないでください)。

     $ git ls-tree 92b8b694
     100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    file.txt

   これで、このツリーには1つのファイルが含まれていることがわかります。
SHA-1ハッシュは、そのファイルのデータへの参照(reference)です:

     $ git cat-file -t 3b18e512
     blob

   「blob」は単なるファイルデータであり、cat-fileで調べることもできます:

     $ git cat-file blob 3b18e512
     hello world

   注意: これは古いファイルデータであることに注意してください。つまり、
Gitが最初のツリーに対する応答で名付けたオブジェクトは、最初のコミットで
記録されたディレクトリ状態のスナップショットを持つツリーです。

   これらのオブジェクトはすべて、Gitディレクトリ内部にSHA-1名で保存され
ます:

     $ find .git/objects/
     .git/objects/
     .git/objects/pack
     .git/objects/info
     .git/objects/3b
     .git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
     .git/objects/92
     .git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
     .git/objects/54
     .git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
     .git/objects/a0
     .git/objects/a0/423896973644771497bdc03eb99d5281615b51
     .git/objects/d0
     .git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
     .git/objects/c4
     .git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241

   そして、これらのファイルの内容は、圧縮されたデータに加えて、ファイル
の長さとタイプを識別するヘッダーだけです。 タイプは、blob、tree、
commit、tag のいずれかです。

   見つけるのが最も簡単なコミットはHEADコミットで、これは .git/HEAD から
見つけることができます:

     $ cat .git/HEAD
     ref: refs/heads/master

   ご覧のとおり、これにより、現在どのブランチを使用しているかがわかりま
す。 ‘.git’ ディレクトリの下にあるファイルに名前を付ける事でこれを私達に
知らせます。このディレクトリ自体には、コミットオブジェクトを参照する
SHA-1名が含まれていて、 cat-file で調べることができます:

     $ cat .git/refs/heads/master
     c4d59f390b9cfd4318117afde11d601c1085f241
     $ git cat-file -t c4d59f39
     commit
     $ git cat-file commit c4d59f39
     tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
     parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
     author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
     committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500

     add emphasis

   ここでの「tree」オブジェクトは、ツリーの新しい状態を指します:

     $ git ls-tree d0492b36
     100644 blob a0423896973644771497bdc03eb99d5281615b51    file.txt
     $ git cat-file blob a0423896
     hello world!

   そして「親」オブジェクトは前のコミットを参照します:

     $ git cat-file commit 54196cc2
     tree 92b8b694ffb1675e5975148e1121810081dbdffe
     author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
     committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500

     initial commit

   そのツリーオブジェクトは最初に調べたツリーであり、このコミットには親
がないという点でレアです。

   多くのコミットでは親が1つしかないですが、 複数の親を持つコミットも割
とあります。 その場合、コミットはマージを表し、 親参照はマージされたブラ
ンチのヘッドを指します。

   ブロブ・ツリー・コミット以外に残っているオブジェクトのタイプは「タグ
」だけです。これについてはここでは説明しません。 詳細については、
git-tag(1) を参照してください。

   これで、Gitがオブジェクトデータベースを使用してプロジェクトの履歴を表
す方法がわかりました:

   • 「コミット」オブジェクトは、履歴の特定のポイントでのディレクトリツ
     リーのスナップショットを表す「ツリー」オブジェクトを指し、「親」コ
     ミットを、プロジェクト履歴にどのように接続されているかを示すために
     参照します。

   • 「ツリー」オブジェクトは単一のディレクトリの状態を表し、ディレクト
     リ名をファイルデータを含む「ブロブ」オブジェクトとサブディレクトリ
     情報を含む「ツリー」オブジェクトに関連付けます。

   • 「ブロブ」オブジェクトには、他の構造でないファイルデータが含まれて
     います。

   • 各ブランチのヘッドにあるコミットオブジェクトへの参照は、
     .git/refs/heads/ の下のファイルに保存されます。

   • 現在のブランチの名前は .git/HEAD に保存されます。

   注意: ちなみに、多くのコマンドは引数としてツリーを使用することに注意
してください。 しかし、上で見ることができるように、ツリーは多くの異なる
方法(そのツリーのSHA-1名、そのツリーを参照するコミットの名前、そのツリー
を参照するヘッドを持つブランチの名前など)で参照できます。そのツリーの
SHA-1名、ツリーを参照するコミットの名前、ヘッドが参照するブランチの名前
そのツリーなどに-そしてそのようなコマンドのほとんどはこれらの名前のいず
れかを受け入れることができます。

   コマンドの概要では、「tree-ish」(ツリーっぽい)という単語がそのような
引数を示すために使用されることがあります。

The index file
**************

コミットを作成するために使用している主なツールは ‘git-commit -a’ です。
これは、作業ツリーに加えたすべての変更を含むコミットを作成します。しかし
、特定のファイルの変更のみをコミットしたい場合はどうでしょうか？ または
、特定のファイルの特定(一部の)の変更のみをコミットしたい場合はどうでしょ
うか？

   コミット作成の秘密を知れば、コミットを作成するより柔軟な方法があるこ
とがわかります。

   我々のテストプロジェクトを続けて、file.txt を再び変更しましょう:

     $ echo "hello world, again" >>file.txt

   しかし、今回はすぐにコミットするのではなく、中間のステップを踏んで、
何が起こっているかを追跡するために途中でdiffを要求しましょう:

     $ git diff
     --- a/file.txt
     +++ b/file.txt
     @@ -1 +1,2 @@
      hello world!
     +hello world, again
     $ git add file.txt
     $ git diff

   最後の差分は空ですが、新しいコミットは行われておらず、ヘッドにはまだ
新しい行が含まれていないからです:

     $ git diff HEAD
     diff --git a/file.txt b/file.txt
     index a042389..513feba 100644
     --- a/file.txt
     +++ b/file.txt
     @@ -1 +1,2 @@
      hello world!
     +hello world, again

   つまり、「git diff」はヘッド以外のものと比較しているのです。比較して
いるのは、実際にはインデックスファイルです。これはバイナリ形式で
.git/index に保存されていますが、その内容はls-filesで調べることができま
す:

     $ git ls-files --stage
     100644 513feba2e53ebbd2532419ded848ba19de88ba00 0       file.txt
     $ git cat-file -t 513feba2
     blob
     $ git cat-file blob 513feba2
     hello world!
     hello world, again

   したがって、「git add」が行ったことは、新しいブロブを格納し、それへの
参照をインデックスファイルに配置することでした。ファイルを再度変更すると
、新しい変更が「git diff」出力に反映されていることがわかります:

     $ echo 'again?' >>file.txt
     $ git diff
     index 513feba..ba3da7b 100644
     --- a/file.txt
     +++ b/file.txt
     @@ -1,2 +1,3 @@
      hello world!
      hello world, again
     +again?

   正しい引数を使用すると、 _git diff_ は、作業ディレクトリと最後のコミ
ットの違い、またはインデックスと最後のコミットの違いを示すこともできます
:

     $ git diff HEAD
     diff --git a/file.txt b/file.txt
     index a042389..ba3da7b 100644
     --- a/file.txt
     +++ b/file.txt
     @@ -1 +1,3 @@
      hello world!
     +hello world, again
     +again?
     $ git diff --cached
     diff --git a/file.txt b/file.txt
     index a042389..513feba 100644
     --- a/file.txt
     +++ b/file.txt
     @@ -1 +1,2 @@
      hello world!
     +hello world, again

   何度でも私達は「git commit」( ‘-a’ オプションなし）を使用して新しいコ
ミットを作成することができ、コミットされた状態にはインデックスファイルに
保存されている変更のみが含まれ、作業ツリーにのみ残っている追加の変更が含
まれていないことを確認できます:

     $ git commit -m "repeat"
     $ git diff HEAD
     diff --git a/file.txt b/file.txt
     index 513feba..ba3da7b 100644
     --- a/file.txt
     +++ b/file.txt
     @@ -1,2 +1,3 @@
      hello world!
      hello world, again
     +again?

   つまり、デフォルトでは、「git commit」は、作業ツリーではなく、インデ
ックスを使用してコミットを作成します。 コミットでの ‘-a’ オプションの指
定は、最初に作業ツリーのすべての変更をインデックスに反映するように指示し
ます。

   最後に、インデックスファイルに対する「git add」の効果を確認しておきま
しょう:

     $ echo "goodbye, world" >closing.txt
     $ git add closing.txt

   _git add_ の効果は、インデックスファイルに1つのエントリを追加すること
でした:

     $ git ls-files --stage
     100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0       closing.txt
     100644 513feba2e53ebbd2532419ded848ba19de88ba00 0       file.txt

   そして、 cat-file でわかるように、この新しいエントリはファイルの現在
の内容を参照しています:

     $ git cat-file blob 8b9743b2
     goodbye, world

   「status」コマンドは、状況の概要をすばやく取得するための便利な方法で
す:

     $ git status
     ブランチ master
     コミット予定の変更点:
       (use "git restore --staged <file>..." to unstage)

             new file:   closing.txt

     Changes not staged for commit:
       (use "git add <file>..." to update what will be committed)
       (use "git restore <file>..." to discard changes in working directory)

             modified:   file.txt

   closeing.txtの現在の状態はインデックスファイルにキャッシュされている
ため、「コミット予定の変更点」(Changes to be committed)としてリストされ
ます。 file.txtには、インデックスに反映されていない作業ディレクトリの変
更があるため、「Changes not staged for commit」とマークされています。 こ
の時点で、「git commit」を実行すると、（新しいコンテンツを含む
)closeing.txtが追加されたコミットが作成されますが、file.txtは変更されま
せんでした。

   また、裸の ‘git diff’ はfile.txtへの変更を示しますが、closeing.txtの
追加は示しません。これは、インデックスファイルのcloseing.txtのバージョン
が作業ディレクトリのバージョンと同じであるためです。

   インデックスファイルは、新しいコミットのステージング領域であることに
加えて、ブランチをチェックアウトするときにオブジェクトデータベースからも
入力され、マージ操作に関係するツリーを保持するためにも使用されます。詳細
については、 gitcore-tutorial(7) および関連するマニュアルページを参照し
てください。

What next?
**********

この期に及んでは、あなたはgitコマンドのマニュアルページを読むために必要
なすべてを知っている必要があります。それを始めるのに適した場所の1つは、
giteveryday(7) に記載されているコマンドを使用することです。また、あなた
は gitglossary(7) で不明な専門用語を調べる事もできます。

   Git User’s Manual (user-manual.html) は、Gitのより包括的な紹介を提供
します。

   gitcvs-migration(7) は、CVSリポジトリをGitにインポートする方法を説明
し、CVSのような方法でGitを使用する方法を示しています。

   Gitの使用に関する興味深い例については、 howtos (howto-index.html) を
参照してください。

   Git開発者向けに、 gitcore-tutorial(7) で、新しいコミットの作成などに
関連する低レベルのGitメカニズムについて詳しく説明しています。

SEE ALSO
********

gittutorial(7), gitcvs-migration(7), gitcore-tutorial(7),
gitglossary(7), git-help(1), giteveryday(7), The Git User’s Manual
(user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

gittutorial — Git入門

Synopsis
********

     git *

DESCRIPTION
***********

このチュートリアルでは、新しいプロジェクトをGitにインポートし、変更を加
え、他の開発者と変更を共有する方法について説明します。

   Gitを使用してプロジェクトをフェッチする方に主な関心がある場合、たとえ
ば、最新バージョンをテストする場合は、 The Git User’s Manual
(user-manual.html) の最初の2つの章から始めることをお勧めします。

   注意: まず最初に、 あなたは ‘git log --graph’ などのコマンドの文書を
以下のようにして入手する事ができます:

     $ man git-log

   または:

     $ git help log

   後者では。あなたが選択したマニュアルビューアを使用できます。詳細につ
いては git-help(1) を参照してください。

   操作を行う前に、名前と公開メールアドレスを使用してあなた自身をGitに紹
介する(introduce yourself)ことをお勧めします。これを行う最も簡単な方法は
以下のとおりです:

     $ git config --global user.name "Your Name Comes Here"
     $ git config --global user.email you@yourdomain.example.com

Importing a new project
***********************

既にtarball project.tar.gz があると仮定します。あなたは以下にしてそれを
Gitリビジョン管理下に置くことができます。

     $ tar xzf project.tar.gz
     $ cd project
     $ git init

   Gitは以下のメッセージを返すでしょう

     Initialized empty Git repository in .git/

   これで作業ディレクトリが初期化されました。あなたは ".git" という名前
の新しいディレクトリが作成されていることに気付くかもしれません。

   次に、Gitに、現在のディレクトリ(_._ に注意)の下にあるすべてのファイル
の内容のスナップショットを「git add」で取得するように指示します:

     $ git add .

   このスナップショットは、Gitが「インデックス」と呼ぶ一時的な足場領域
(temporary staging area)に保存されました。 _git commit_ を使用して、イン
デックスの内容をリポジトリに永続的に保存できます:

     $ git commit

   これにより、コミットメッセージの入力を求められます。 これで、プロジェ
クトの最初のバージョンがGitに保存されました。

Making changes
**************

いくつかのファイルを変更してから、更新された内容をインデックスに追加しま
す:

     $ git add file1 file2 file3

   これで、コミットする準備ができました。 ‘--cached’ オプションを指定し
た「git diff」を使用して、何がコミットされようとしているのかを確認できま
す:

     $ git diff --cached

   (‘--cached’ を指定しない場合、「git diff」は、編集を行ったがまだイン
デックスに追加されていない変更を表示します。）あなたは「git status」を使
用して状況の簡単な要約を取得することもできます:

     $ git status
     On branch master
     Changes to be committed:
     Your branch is up to date with 'origin/master'.
       (use "git restore --staged <file>..." to unstage)

             modified:   file1
             modified:   file2
             modified:   file3

   さらに調整が必要な場合は、ここで調整してから、新しく変更したコンテン
ツをインデックスに追加します。 最後に、以下のコマンドであなたの変更をコ
ミットします。

     $ git commit

   これにより、変更を説明するメッセージの入力を再度求められ、プロジェク
トの新しいバージョンが記録されます。

   または、事前に「git add」を実行する代わりに、あなたは以下を使用できま
す。

     $ git commit -a

   これにより、変更された(ただし新規ではない)ファイルが自動的に認識され
、それらがインデックスに追加され、コミットされます。それらがすべて1つの
ステップで実行されます。

   コミットメッセージに関する注意: 必須ではありませんが、コミットメッセ
ージは、変更を要約した1行の短い(50文字未満)行で始まり、空行が1行あり、そ
の後にさらに詳細な説明が続くようにすることをお勧めします。コミットメッセ
ージの最初の空白行までのテキストはコミットタイトルとして扱われ、そのタイ
トルはGit全体で使用されます。たとえば、 git-format-patch(1) はコミットを
電子メールに変換し、件名としてコミットタイトル、本文として残りのコミット
メッセージを使用します。

Git tracks content not files
****************************

【Gitはファイルではなくコンテンツを追跡する】多くのリビジョン管理システ
ムは、新しいファイルへの変更の追跡を開始するようにシステムに指示する
‘add’ コマンドを提供します。 Gitの ‘add’ コマンドは、よりシンプルで強力
な機能を実行します。 ‘git add’ ’は、新しいファイルと新しく変更されたファ
イルの両方に使用されます。どちらの場合も、指定されたファイルのスナップシ
ョットを取得し、そのコンテンツをインデックスにステージングして、次のコミ
ットにすぐに含めることができます。

Viewing project history
***********************

あなたはいつでも、以下を使用して変更の履歴を表示できます

     $ git log

   あなたが各ステップで完全な差分も表示したい場合は、以下を使用してくだ
さい

     $ git log -p

   多くの場合、以下のような変更の概要は、各ステップの感触をつかむのに役
立ちます

     $ git log --stat --summary

Managing branches
*****************

単一のGitリポジトリで、開発の複数のブランチを維持できます。「
experimental」という名前の新しいブランチを作成するには、以下のようにしま
す。

     $ git branch experimental

   そして、以下のようにすることができます

     $ git branch

   そうすると、既存のすべてのブランチのリストが表示されます。

       experimental
     * master

   「experimental」ブランチは作成したばかりのブランチであり、「master」
ブランチは自動的に作成されたデフォルトのブランチです。アスタリスク
(‘*’)は、現在使用しているブランチを示します。そして以下のようにタイプし
ます。

     $ git switch experimental

   するとexperimentalブランチに切り替えます。次に、ファイルを編集し、変
更をコミットして、masterブランチに戻ります:

     (edit file)
     $ git commit -a
     $ git switch master

   その変更はexperimentalブランチで行われ、masterブランチに戻ったため、
その変更が表示されなくなったことを確認します。

   masterブランチで別の変更を加えることができます:

     (edit file)
     $ git commit -a

   この時点で、2つのブランチは分岐しており、それぞれに異なる変更が加えら
れています。experimentalで行った変更をmasterにマージするには、以下を実行
します

     $ git merge experimental

   変更が競合しない場合は、これで完了です。 競合がある場合、競合を示すマ
ーカーが問題のあるファイルに残されます。

     $ git diff

   とすると、これを表示します。あなたが競合を解決するためにファイルを編
集したら

     $ git commit -a

   とすると、マージの結果をコミットします。そして最後に、

     $ gitk

   とすると、結果の履歴の優れたグラフィック表現が表示されます。

   この時点で、以下のコマンドでexperimentalブランチを削除できます

     $ git branch -d experimental

   このコマンドは、experimentalブランチでの変更がすでに現在のブランチに
あることを確認します。

   あなたがブランチクレイジーアイデアで開発し、それを後悔しているなら、
あなたはいつでもブランチを(マージせずに)削除することができます

     $ git branch -D crazy-idea

   ブランチのコストは安くて、かつ操作は簡単なので、これは何かを一時的に
試す良い方法です。

Using Git for collaboration
***************************

アリス(Alice)が /home/alice/project にGitリポジトリを使用して新しいプロ
ジェクトを開始し、同じマシンにホームディレクトリを持っているボブ(Bob)が
貢献したいとします。

   ボブは以下のように始めます:

     bob$ git clone /home/alice/project myrepo

   これにより、アリスのリポジトリのクローンを含む新しいディレクトリ「
myrepo」が作成されます。クローンは元のプロジェクトと同等の立場にあり、元
のプロジェクトの履歴の独自のコピーを所有しています。

   次に、ボブはいくつかの変更を加えてコミットします:

     (edit files)
     bob$ git commit -a
     (repeat as necessary)

   準備ができたら、ボブはアリスに /home/bob/myrepo のリポジトリから変更
をプルするように指示します。アリスはこれを以下のように行います:

     alice$ cd /home/alice/project
     alice$ git pull /home/bob/myrepo master

   これにより、ボブの「master」ブランチからの変更がアリスの現在のブラン
チにマージされます。その間にアリスが自分で変更を加えた場合は、競合を手動
で修正する必要があります。

   つまり「pull」コマンドは2つの操作を実行します。リモートブランチから変
更をフェッチしてから、それらを現在のブランチにマージします。

   一般に、アリスが「プル」を開始する前に、アリス自身のローカルの変更を
コミットすることを望んでいることに注意してください。ボブの作業が、履歴が
分岐してからアリスが行ったことと競合する場合、アリスは作業ツリーとインデ
ックスを使用して競合を解決し、既存のアリス自身のローカル変更は競合解決プ
ロセスの障害となります(Gitは引き続きフェッチを実行しますが、マージを拒否
します。アリスは、何らかの方法でアリス自身のローカルの変更を取り除き、再
度プルする必要があります)。

   アリスは、「fetch」コマンドを使用して、マージせずにボブが行ったことを
確認できます。 これにより、アリスはボブが何をしたかを特別な記号「
FETCH_HEAD」を使用して検査し、プルする価値があるかどうかを判断できます。

     alice$ git fetch /home/bob/myrepo master
     alice$ git log -p HEAD..FETCH_HEAD

   この操作は、アリスがアリス自身のローカルの変更をコミットしていない場
合でも安全です。 範囲表記 ‘HEAD..FETCH_HEAD’ は、「FETCH_HEADから到達可
能なすべてのものを表示し、HEADから到達可能なものはすべて除外する」ことを
意味します。 このコマンドで、アリスは、現在の状態（HEAD）につながるすべ
てのことをすでに知っているとして、ボブが持っている状態（FETCH_HEAD）で、
かつ、アリスが持っていないモノを確認します。

   アリスが、ボブとの履歴が分岐してから何をしたかを視覚化したい場合は、
以下のコマンドを実行できます:

     $ gitk HEAD..FETCH_HEAD

   これは、前に「git log」で見たのと同じ2ドットの範囲表記を使用します。

   アリスは、フォークして以来、アリスとボブの両方が何をしたかを見たいと
思うかもしれません。その場合、アリスはは2ドット形式の代わりに3ドット形式
を使用できます:

     $ gitk HEAD...FETCH_HEAD

   これは、「どちらか一方から到達可能なものはすべて表示し、両方から到達
可能なものはすべて除外する」ことを意味します。

   これらの範囲表記は、gitkと「git log」の両方で使用できることに注意して
ください。

   ボブが何をしたかを調べた後、緊急のことがなければ、アリスはボブからプ
ルせずに作業を続けることを決定するかもしれません。ボブの履歴にアリスがす
ぐに必要とするものがある場合、アリスは最初に進行中の作業をstashし、「プ
ル」を実行し、最後に結果の履歴に加えて進行中の作業をunstashすることを選
択できます。

   小さな緊密なグループで作業している場合、同じリポジトリを何度も操作す
ることは珍しくありません。リモートリポジトリの省略形を定義すると、作業は
以下のように簡単になります:

     alice$ git remote add bob /home/bob/myrepo

   これにより、アリスは「git fetch」コマンドを使用して、「pull」操作の最
初の部分を自分のブランチとマージせずに、以下のコマンドを使用して単独で実
行できます:

     alice$ git fetch bob

   直接書いた形式とは異なり、アリスが「git remote」で設定したリモートリ
ポジト省略形を使用してボブからフェッチする場合、フェッチされたものはリモ
ート追跡ブランチ(この場合は「bob/master」）に保存されます。 したがって、
以下のようにすると:

     alice$ git log -p master..bob/master

   ボブがアリスのmasterブランチから分岐してから行ったすべての変更のリス
トを示します。

   これらの変更を調べた後、アリスは変更をアリス自身のmasterブランチにマ
ージできます。

     alice$ git merge bob/master

   この「マージ」は、以下のように「アリス自身のリモート追跡ブランチから
プルする」ことによっても実行できます:

     alice$ git pull . remotes/bob/master

   注意: コマンドラインで他に何が指定されているかに関係なく、 ‘git pull’
は常に現在のブランチにマージされることに注意してください。

   その後、ボブは以下を使用してアリスの最新の変更でボブのリポジトリを更
新できます

     bob$ git pull

   注意: ボブはアリスのリポジトリへのパスを指定する必要がないことに注意
してください。ボブがアリスのリポジトリのクローンを作成したとき、Gitはア
リスのリポジトリの場所をリポジトリ構成に保存し、その場所がプルに使用され
ます。

     bob$ git config --get remote.origin.url
     /home/alice/project

   ( _git clone_ によって作成される完全な構成は、 ‘git config -l’ を使用
して表示でき、 git-config(1) のマニュアルページで各オプションの意味を説
明しています。)

   Gitは、「origin/master」という名前でアリスのmasterブランチの当初の綺
麗なコピー(pristine copy)も保持しています。

     bob$ git branch -r
       origin/master

   ボブが後で別のホストから作業することを決定した場合でも、sshプロトコル
を使用してクローンとプルを実行できます:

     bob$ git clone alice.org:/home/alice/project myrepo

   代わりに、Gitのネイティブプロトコルや、httpを使用できます。詳細につい
ては、 git-pull(1) を参照してください。

   Gitは、さまざまなユーザーが変更をプッシュする中央リポジトリを使用して
、CVSのようなモードで使用することもできます。 git-push(1) と
gitcvs-migration(7) を参照してください。

Exploring history
*****************

Gitの履歴は、相互に関連する一連のコミットとして表されます。 _git log_ コ
マンドでこれらのコミットを一覧表示できることはすでに見てきました。注意:
各gitログエントリの最初の行には、コミットの名前も示されていることに注意
してください:

     $ git log
     commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
     Author: Junio C Hamano <junkio@cox.net>
     Date:   Tue May 16 17:18:22 2006 -0700

         merge-base: Clarify the comments on post processing.

   このコミットの詳細を確認するには、この名前を「git show」に与えます。

     $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7

   ただし、コミットを参照する方法は他にもあります。あなたはコミットを一
意に識別するのに十分な長さであれば名前の最初の部分だけを指定できます:

     $ git show c82a22c39c   # the first few characters of the name are
                             # usually enough
     $ git show HEAD         # the tip of the current branch
     $ git show experimental # the tip of the "experimental" branch

   通常、あらゆるコミットには、プロジェクトの以前の状態を指す1つの「親」
コミットがあります:

     $ git show HEAD^  # to see the parent of HEAD
     $ git show HEAD^^ # to see the grandparent of HEAD
     $ git show HEAD~4 # to see the great-great grandparent of HEAD

   注意: マージコミットには複数の親が含まれる場合があることに注意してく
ださい:

     $ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
     $ git show HEAD^2 # show the second parent of HEAD

   コミットに独自の名前を付けることもできます。

     $ git tag v2.5 1b2e1d63ff

   と実行すると、1b2e1d63ff は「v2.5」という名前で参照できます。この名前
を他の人と共有する場合(たとえば、リリースバージョンを識別するため)、「タ
グ」オブジェクトを作成し、おそらくそれに署名する必要があります。 詳細に
ついては git-tag(1) を参照してください。

   コミットを知る必要のあるGitコマンドは、これらの名前のいずれかを指定す
ることができます。 例えば:

     $ git diff v2.5 HEAD     # compare the current HEAD to v2.5
     $ git branch stable v2.5 # start a new branch named "stable" based
                              # at v2.5
     $ git reset --hard HEAD^ # reset your current branch and working
                              # directory to its state at HEAD^

   最後のコマンドには注意してください。作業ディレクトリの変更が失われる
だけでなく、このブランチからそれ以降のすべてのコミットも削除されます。こ
のブランチがそれらのコミットを含む唯一のブランチである場合、それらは失わ
れます。また、他の開発者がプルする公開ブランチで「git reset」を使用しな
いでください。他の開発者に不必要なマージを強制して、履歴をクリーンアップ
してしまうためです。プッシュした変更を元に戻す必要がある場合は、代わりに
「git revert」を使用してください。

   _git grep_ コマンドは、プロジェクトの任意のバージョンで文字列を検索で
きます。

     $ git grep "hello" v2.5

   これは、v2.5で出現するすべての「hello」を検索します。

   以下のようにコミット名を省略すると、「git grep」は現在のディレクトリ
で管理しているファイルを検索します。

     $ git grep "hello"

   これは、Gitによって追跡されているファイルだけですばやく検索する方法で
す。

   多くのGitコマンドは、さまざまな方法で指定できる一連のコミットも指定で
きます。 _git log_ の例を以下に示します:

     $ git log v2.5..v2.6            # commits between v2.5 and v2.6
     $ git log v2.5..                # commits since v2.5
     $ git log --since="2 weeks ago" # commits from the last 2 weeks
     $ git log v2.5.. Makefile       # commits since v2.5 which modify
                                     # Makefile

   ’git log’にコミットの「範囲」を与えることもできます。ここで、最初のコ
ミットは必ずしも2番目の祖先とは限りません。 たとえば、ブランチの「
stable」と「master」の先端が、しばらく前に共通のコミットから分岐した場合
、

     $ git log stable..master

   とすると、masterブランチで行われたコミットはリストされますが、
stableブランチに対しては行われません。

     $ git log master..stable

   とすると、stableブランチで行われたコミットのリストが表示されますが、
masterブランチに対しては表示されません。

   「git log」コマンドには弱点があります。コミットを一覧として表示する必
要があることです。履歴に分岐してからマージされた開発ラインがある場合、「
git log」がそれらのコミットを提示する順序は無意味な順序になります。

   複数のコントリビューター（LinuxカーネルやGit自体など）を持つほとんど
のプロジェクトでは、頻繁にマージが行われ、「gitk」はそれらの履歴をより適
切に視覚化できます。

     $ gitk --since="2 weeks ago" drivers/

   これは、「drivers」ディレクトリの下のファイルを変更した過去2週間のコ
ミットからのコミットを参照できます。 (注: Ctrlキーを押しながら「-」また
は「+」を押すと、gitkのフォントサイズを調整できます。）

   最後に、ファイル名を取得するほとんどのコマンドでは、オプションで、フ
ァイルの特定のバージョンを指定するために、任意のファイル名の前にコミット
を付けることができます:

     $ git diff v2.5:Makefile HEAD:Makefile.in

   _git show_ を使用して、任意のファイルを表示することもできます:

     $ git show v2.5:Makefile

Next Steps
**********

このチュートリアルは、プロジェクトの基本的な分散リビジョン管理を実行する
のに十分なはずです。ただし、Gitの奥深さとパワーを完全に理解するには、
Gitの基礎となる2つの簡単なアイデアを理解する必要があります:

   • オブジェクトデータベースは、あなたのプロジェクトの履歴（ファイル、
     ディレクトリ、コミット）を格納するために使用されるかなり洗練された
     システムです。

   • インデックスファイルは、ディレクトリツリーの状態のキャッシュであり
     、コミットの作成、作業ディレクトリのチェックアウト、およびマージに
     関係するさまざまなツリーの保持に使用されます。

   このチュートリアルのパート2では、オブジェクトデータベース、インデック
スファイル、およびGitを最大限に活用するために必要なその他のいくつかのガ
ラクタについて説明します。 linkgit: gittutorial-2[7] をご覧下さい。

   すぐにそれを続けたくない場合は、この時点で興味深いかもしれない他のい
くつかのより道は以下のとおりです:

   • git-format-patch(1) 、git-am(1): これらは一連のgitコミットを電子メ
     ールで送信されたパッチに変換します。その逆も同様です。電子メールで
     送信されたパッチに大きく依存するLinuxカーネルなどのプロジェクトで役
     立ちます。

   • git-bisect(1): プロジェクトにデグレがある場合、バグを追跡する1つの
     方法は、履歴を検索して、原因となる正確なコミットを見つけることです
     。 Git bisectは、そのコミットの二分木検索を実行するのに役立ちます。
     マージされたブランチが多数ある複雑な非線形履歴の場合でも、最適に近
     い検索を実行するのに十分賢いです。

   • gitworkflows(7): 推奨される作業の流れの概要を示します。

   • giteveryday(7): 20コマンド程度で綴る日々のGit。

   • gitcvs-migration(7): CVSユーザー向けのGit。

SEE ALSO
********

gittutorial-2(7), gitcvs-migration(7), gitcore-tutorial(7),
gitglossary(7), git-help(1), gitworkflows(7), giteveryday(7), The Git
User’s Manual (user-manual.html)

GIT
***

Part of the git(1) suite

Name
****

gitweb.conf — Gitweb(Git Webインターフェイス)構成ファイル

Synopsis
********

/etc/gitweb.conf, /etc/gitweb-common.conf, $GITWEBDIR/gitweb_config.perl

DESCRIPTION
***********

Web上でGitリポジトリを表示するためのgitweb CGIスクリプトは、設定ファイル
としてperlスクリプト断片を使用します。 ‘our $variable = value’ を使用し
て変数を設定できます。 ‘#’ 文字から行末までのテキストは無視されます。 詳
細については、「perlsyn(1)」を参照してください。

   とある例:

     # gitweb configuration file for http://git.example.org
     #
     our $projectroot = "/srv/git"; # FHS recommendation
     our $site_name = 'Example.org >> Repos';

   構成ファイルは、 ‘gitweb.cgi’ スクリプトが生成されたときにgitwebに組
み込み済みのデフォルト設定を上書きするために使用されます。

   gitweb CGI自体の構成設定を変更することもできますが、それらの変更はア
ップグレード時に失われます。構成設定は、デフォルト名が
‘gitweb_config.perl’ のCGIスクリプトと同じディレクトリ内のファイルに配置
される場合もあります。これにより、シンボリックリンクを使用して、構成が異
なる複数のgitwebインスタンスを作成できます。

   注意: 一部の構成は、gitweb全体ではなく、リポジトリごとに制御できるこ
とに注意してください。 gitweb(1)の manpage の「Per-repository gitweb
configuration」サブセクションを参照してください。

DISCUSSION
**********

gitwebは、以下のソースから以下の順序で構成データを読み取ります:

   • 組み込み値(ビルド段階で設定されるものもあります)

   • 共通のシステム全体の構成ファイル(デフォルトは
     ‘/etc/gitweb-common.conf’)

   • インスタンスごとの構成ファイル(デフォルトでは、インストールされた
     gitwebと同じディレクトリにある ‘gitweb_config.perl’ になります)。ま
     たは、存在しない場合は、システム全体の構成ファイル(デフォルトは
     ‘/etc/gitweb.conf’)にフォールバックします。

   後から構成ファイルで得られた値は、上記の順序で先に得られた値を上書き
します。

   共通のシステム全体の構成ファイルや、フォールバックシステム全体の構成
ファイルや、インスタンスごとの構成ファイルの場所は、ビルド時のMakefile構
成変数、それぞれ ‘GITWEB_CONFIG_COMMON’ と ‘GITWEB_CONFIG_SYSTEM’ と
‘GITWEB_CONFIG’ を使用して定義されます。

   あなたは環境変数 ‘GITWEB_CONFIG_COMMON’ と ‘GITWEB_CONFIG_SYSTEM’ と
‘GITWEB_CONFIG’ を空でない値に設定することにより、実行時にgitweb構成ファ
イルの場所をオーバーライドすることもできます。

   構成ファイルの構文はPerlの構文です。これらのファイルは、Perlコード
(gitweb自体が記述されている言語)の断片としてそれらをsourceすることによっ
て処理されるためです。 変数は通常、 (‘our $variable = <value>;’ のように
) ‘our’ 修飾子を使用して設定され、新しいバージョンのgitwebがとある変数を
使用しなくなったために、とある変数の宣言で停止(stop)する構文エラーを回避
します。

   あなたは read_config_file() サブルーチンを使用して、他の構成ファイル
を含めることができます。たとえば、(Gitリポジトリ管理ツールの1つである
)Gitoliteを介してリポジトリを表示するための、アクセス制御に関連する
gitweb構成を別のファイルに入れたい場合があります。例えばそれが
‘/etc/gitweb-gitolite.conf’ にあるとすると、それを含めるには以下のように
します。

     read_config_file("/etc/gitweb-gitolite.conf");

   これを、使用されているgitweb構成ファイルのどこか、例えばインストール
ごとのgitweb構成ファイルに置きます。 注意: read_config_file()は、読み取
ったファイルが存在することを自分自身でチェックし、見つからない場合は何も
しないことに注意してください。 また、インクルードファイルのエラーも処理
します。

   一部のインストールでは、構成ファイルがまったくないデフォルトの構成が
完全に機能する場合があります。それでも、構成ファイルはgitwebの動作をさま
ざまな方法でカスタマイズまたは微調整するのに役立ち、構成可能な
‘%features’ 変数を使用して明示的に有効にしない限り、一部のオプション機能
は有効になりません(以下の「Configuring gitweb features」セクションも参照
)。

CONFIGURATION VARIABLES
***********************

設定変数の中には、gitwebのビルド時にデフォルト値が設定されるものがありま
す(CGIスクリプトに埋め込まれています) — その場合は、その事実を記述してい
ます。 gitwebのビルドとインストールについては、gitwebの INSTALL ファイル
を参照してください。

Location of repositories
========================

以下で説明する構成変数は、gitwebがGitリポジトリを見つける方法、およびリ
ポジトリが表示およびアクセスされる方法を制御します。

   gitweb(1)の manpage の「Repositories」以降のサブセクションも参照して
ください。

$projectroot
     プロジェクトパスの前に付加されるファイルシステム絶対パス。リポジト
     リへのパスは ‘$projectroot/$project’ です。 インストール時に
     ‘$GITWEB_PROJECTROOT’ に設定します。gitwebがリポジトリを見つけるに
     は、この変数を正しく設定する必要があります。

     たとえば、 ‘$projectroot’ が ‘/srv/git’ に設定されている場合、
     gitweb構成ファイルに以下のように入力します:

          our $projectroot = "/srv/git";

     これは以下のようになります

          http://git.example.com/gitweb.cgi?p=foo/bar.git

     そして以下はpath_infoベースの同等のものです

          http://git.example.com/gitweb.cgi/foo/bar.git

     これはファイルシステムのパス ‘/srv/git/foo/bar.git’ にマップされま
     す。

$projects_list
     プロジェクトを一覧表示するプレーンテキストファイルの名前、またはプ
     ロジェクトをスキャンするディレクトリの名前。

     プロジェクトリストファイルには、1行に1つのプロジェクトがリストされ
     、各行の形式は以下のとおりです

          <URI-encoded filesystem path to repository> SP <URI-encoded repository owner>

     この変数のデフォルト値は、インストール時に ‘GITWEB_LIST’ makefile変
     数によって決定されます。この変数が空の場合、gitwebはフォールバック
     して ‘$projectroot’ ディレクトリのリポジトリをスキャンします。

$project_maxdepth
     ‘$projects_list’ 変数が設定されていない場合、gitwebはファイルシステ
     ムを再帰的にスキャンしてGitリポジトリを探します。
     ‘$project_maxdepth’ は、 ‘$projectroot’ (開始点)を基準にしてトラバ
     ーサル深度を制限するために使用されます。 これは、
     ‘$project_maxdepth’ よりも ‘$projectroot’ から離れているディレクト
     リがスキップされることを意味します。

     これは純粋にパフォーマンスの最適化であり、元々は再帰的なディレクト
     リトラバーサルが遅い MacOS X を対象としています。Gitwebはシンボリッ
     クリンクをたどりますが、重複するファイルやディレクトリを無視して循
     環を検出します。

     この変数のデフォルト値は、ビルド時の構成変数
     ‘GITWEB_PROJECT_MAXDEPTH’ によって決定されます。デフォルトは2007で
     す。

$export_ok
     この(変数の値のファイル名の)ファイルが(リポジトリに)存在する場合に
     のみリポジトリを表示します。この変数がtrueと評価された場合にのみ有
     効です。 ‘GITWEB_EXPORT_OK’ を設定することにより、gitwebを構築する
     ときに設定できます。 このパスは ‘GIT_DIR’ からの相対パスです。
     git-daemon[1] は、 ‘--export-all’ で開始されていない限り、
     ‘git-daemon-export-ok’ を使用します。デフォルトでは、この変数は設定
     されていません。つまり、この機能はオフになっています。

$export_auth_hook
     表示するリポジトリを決定するために使用される関数。このサブルーチン
     は、プロジェクトへのフルパスという1つのパラメーターを受け取る必要が
     あり、trueを返した場合、そのプロジェクトはプロジェクトリストに含ま
     れ、 ‘$export_ok’ と $‘projects_list’ と ‘$projects_maxdepth’ とで
     説明されている他の要件を満たしている限り、gitwebからアクセスできま
     す。例:

          our $export_auth_hook = sub { return -e "$_[0]/git-daemon-export-ok"; };

     上記は代わりに、以下のように ‘$export_ok’ を使用して行うことができ
     ますが

          our $export_ok = "git-daemon-export-ok";

     設定されていない場合(デフォルト)は、この機能はが無効になっています
     。

     より複雑な例として、 gitweb(1) manpage の「Controlling access to
     Git repositories」サブセクションも参照してください。

$strict_export
     概要ページにも表示されているリポジトリの表示のみを許可します。これ
     により、たとえば、 ‘$ export_ok’ ファイルは、リポジトリが表示されて
     いるかどうかだけでなく、リポジトリが使用可能かどうかを判断します。
     ‘$projects_list’ がプロジェクトのリストを含むファイルを指している場
     合、リストされているリポジトリのみがgitwebで使用できます。
     ‘GITWEB_STRICT_EXPORT’ を介してgitwebの構築中に設定できます。デフォ
     ルトでは、この変数は設定されていません。つまり、プロジェクトリスト
     ページから非表示になっている(たとえば、 ‘$projects_listファイルにリ
     ストされいない)リポジトリに直接のアクセスができます。

Finding files
=============

以下の構成変数は、ファイルの場所をgitwebに指示します。これらの変数の値は
、ファイルシステム上のパスです。

$GIT
     使用するコアgit実行可能ファイル。デフォルトでは ‘$GIT_BINDIR/git’ に
     設定されており、これはデフォルトで ‘$(bindir)/git’ に設定されていま
     す。バイナリパッケージからインストールされたGitを使用する場合は、通
     常、これを ‘/usr/bin/git’ に設定する必要があります。Webサーバーに適
     切なPATHが通っている場合、これは単に ‘git’ になる可能性があります。
     セキュリティの観点から、gitバイナリへの絶対パスを使用することをお勧
     めします。複数のGitバージョンがインストールされている場合は、gitバ
     イナリへの絶対パスを使用して、使用するバージョンを選択できます。
     gitwebが機能するには、(正しく)設定する必要があります。

$mimetypes_file
     ‘/etc/mime.types’ を試す前に、(ファイル名拡張子に基づいて)MIMEタイ
     プを推測するために使用するファイル。 *NOTE* このパスは、相対的であ
     る場合、CGIスクリプトではなく、現在のGitリポジトリに相対的であると
     見なされます。 設定されていない場合、 ‘/etc/mime.types’ のみが使用
     されます(‘/etc/mime.types’ がファイルシステムに存在する場合)。
     mimetypesファイルが見つからない場合、ファイルの拡張子に基づく
     mimetypeの推測は無効になります。デフォルトでは設定されていません。

$highlight_bin
     使用するhighlight実行可能ファイルのパス(パラメーターと出力に関して
     仮定してあるため、 http://www.andre-simon.de
     (http://www.andre-simon.de) からのものである必要があります)。デフォ
     ルトでは ‘highlight’ に設定されています。WebサーバーのPATHが通った
     ところにインストールされていない場合は、highlight実行可能ファイルへ
     のフルパスを設定します。gitwebが実際に構文の強調表示(syntax
     highlighting)を使用するには、 ‘highlight’ 機能を設定する必要がある
     ことに注意してください。

     *注意* : ファイルを強調表示するには、その構文タイプを検出し、 その
     構文を ‘highlight’ でサポートする必要があります。 デフォルトの構文
     検出は最小限であり、 デフォルトで検出されない多くのサポートされてい
     る構文タイプがあります。 構文検出を追加するには、3つのオプションが
     あります。 1番目と2番目の優先順位は ‘%highlight_basename’ と
     ‘%highlight_ext’ で、 これらはベース名(完全なファイル名、たとえば
     ‘Makefile’)と拡張子(たとえば ‘sh’)に基づいて検出します。 これらのハ
     ッシュのキーはそれぞれベース名と拡張子であり、 指定されたキーの値は
     、‘--syntax<syntax>’ を介して ‘highlight’ に渡される構文の名前です
     。 最後の優先順位は、 ファイルの最初の行に基づいて言語を検出するた
     めの ‘Shebang’ 正規表現の ‘highlight’ 構成です (たとえば、行
     ‘#!/bin/bash’ とマッチします)。 highlightのドキュメントとデフォルト
     の設定を参照してください。 詳細については、
     ‘/etc/highlight/filetypes.conf’ を参照してください。

     たとえば、ホストしているリポジトリがPHPファイルに ‘phtml’ 拡張子を
     使用していて、それらのファイルに正しい構文を強調表示したい場合は、
     gitweb構成に以下を追加できます:

          our %highlight_ext;
          $highlight_ext{'phtml'} = 'php';

Links and their targets
=======================

以下で説明する構成変数は、いくつかのgitwebリンクを構成します。ターゲット
と外観(テキストまたは画像)、およびページの前提条件(スタイルシート、
favicon、画像、スクリプト)の場所です。 通常、 ‘@stylesheets’ 変数を除い
て、デフォルト値のままになります。

‘@stylesheets’
     スタイルシートのURIのリスト(ページのベースURIからの相対パス)。複数
     のスタイルシートを指定する場合があります。たとえば、 ‘gitweb.css’ を
     ベースとして使用し、サイト固有の変更を別のスタイルシートに追加して
     、gitwebのアップグレードを容易にします。 たとえば、あなたが ‘site’
     スタイルシートを追加するには以下のようにします

          push @stylesheets, "gitweb-site.css";

     これをgitweb構成ファイルに追加します。相対パスであるこれらの値は、
     gitwebのベースURIを基準にしています。

     このリストには、gitwebの標準スタイルシートのURIが含まれている必要が
     あります。gitwebスタイルシートのデフォルトURIは、ビルド時に
     ‘GITWEB_CSS’ makefile変数を使用して設定できます。デフォルト値は
     ‘static/gitweb.css’ (または、 ‘CSSMIN’ 変数が定義されている場合、つ
     まり、ビルド中にCSS minifierが使用されている場合は
     ‘static/gitweb.min.css’ ) です。

     *注意*: 古いgitwebで使用されていた従来の ‘$stylesheet’ 構成変数もあ
     ります。 ‘$stylesheet‘変数が定義されている場合、 この変数によって指
     定されたCSSスタイルシートのみがgitwebによって使用されます。

$logo
     Webサーバー上で ‘git-logo.png’ を配置する場所を指定します。または、
     72x27サイズの汎用ロゴのURIを指します。この画像は、各gitwebページの
     右上隅に表示され、Atomフィードのロゴとして使用されます。 gitwebのベ
     ースURIからの相対パスです。 ‘GITWEB_LOGO’ 変数を使用してgitwebを構
     築するときに調整できます。デフォルトでは ‘static/git-logo.png’ に設
     定されています。

$favicon
     Webサーバー上で ‘git-favicon.png’ を配置する場所を指します。または
     、 ‘image/png’ タイプとして提供されるfaviconの汎用URIを指します。
     favicon(Webサイトアイコン)をサポートするWebブラウザーは、
     favicon(Webサイトアイコン)をブラウザーのURLバーに表示し、ブックマー
     クのサイト名の横に表示する場合があります。gitwebのベースURIからの相
     対パスです。 ‘GITWEB_FAVICON’ 変数を使用してビルド時に調整できます
     。 デフォルトでは ‘static/git-favicon.png’ に設定されています。

$javascript
     Webサーバー上で ‘gitweb.js’ を配置する場所を指します。より一般的に
     は、gitwebで使用されるJavaScriptコードのURIを指します。 gitwebのベ
     ースURIを基準にしています。 ‘GITWEB_JS’ ビルド時構成変数を使用して
     ビルド時に設定できます。

     デフォルト値は、 ‘static/gitweb.js’ または ‘JSMIN’ ビルド変数が定義
     されている場合、つまりビルド時にJavaScript minifierが使用されている
     場合は ‘static/gitweb.min.js’ です。 *注意* この単一のファイルは、
     複数の個別のJavaScriptモジュール達から生成されます。

$home_link
     すべてのページの上部にあるホームリンク(home link)のターゲット(パン
     くずリスト(breadcrumbs)ビューの最初の部分)。 デフォルトでは、現在の
     ページの絶対URIに設定されます(‘$my_uri’ 変数の値、または ‘$my_uri’
     が未定義または空の文字列の場合は ‘/’ に設定されます)。

$home_link_str
     すべてのページの上部にある「home link」のラベルで、‘$home_link’ に
     誘導します(通常、プロジェクトリストを含むメインのgitwebページです
     )。 ‘<home link> / <project> / <action>’ は、gitwebの「パンくずリス
     ト」の最初のコンポーネントとして使用されます。
     ‘GITWEB_HOME_LINK_STR’ 変数を使用してビルド時に設定できます。このリ
     ンクからプロジェクトのリストが表示されるため、デフォルトではラベル
     は "projects" に設定されています。もう1つの一般的な選択肢は、サイト
     の名前に設定することです。生のHTMLとして扱われるため、信頼できない
     ソースからは設定しないでください。

‘@extra_breadcrumbs’
     ホームリンクの前のパンくずリスト(breadcrumb trail)の先頭に、
     gitwebサーバーをホストする組織や部門など、gitwebプロジェクトリスト
     の論理的に「上位」にあたるページに追加される追加のリンク。リストの
     各要素は配列への参照であり、要素0はリンクテキスト(‘$home_link_str’
     相当)で、要素1はターゲットURL(‘$home_link’ 相当)です。

     たとえば、以下の設定では、 ‘home/dev/projects/ ...’ のようなパンく
     ずリストが生成されます。ここで、 ‘projects’ はホームリンクです。

              our @extra_breadcrumbs = (
                [ 'home' => 'https://www.example.org/' ],
                [ 'dev'  => 'https://dev.example.org/' ],
              );

$logo_url
$logo_label
     Gitロゴリンク(または、別のロゴ画像を使用することを選択した場合はサ
     イトのロゴ)の、URIとラベル(タイトル)。デフォルトでは、これらは両方
     ともGitホームページ https://git-scm.com (https://git-scm.com) を参
     照します。 過去には、 https://www.kernel.org
     (https://www.kernel.org) のGitのドキュメントを参照していました。

Changing gitweb’s look
======================

あなたは、以下で説明する変数を使用して、gitwebによって生成されたページの
外観を調整できます。サイト名を変更したり、すべてのページに共通のヘッダー
とフッターを追加したり、メインページ(プロジェクトリストページ)に、この
gitwebインストールの説明を追加したりできます。

$site_name
     ページタイトルに表示される、サイト名または組織名です。 ブックマーク
     などを分かりやすくするために、何か説明的なものに設定してください。
     この変数が設定されていない場合、あるいは設定されていても、gitweb は
     ‘SERVER_NAME’ CGI環境変数の値を使用して、サイト名を "$SERVER_NAME
     Git" に設定し、この環境変数が設定されていない場合(例: gitweb がスタ
     ンドアローンのスクリプトとして起動している場合など)は "Untitled
     Git" に設定します。

     ビルド時に ‘GITWEB_SITENAME’ を使用して設定できます。 デフォルトで
     は設定されていません。

$site_html_head_string
     各ページの<head>セクションに含まれるHTMLスニペット。ビルド時に
     ‘GITWEB_SITE_HTML_HEAD_STRING’ を使用して設定できます。 デフォルト
     値はありません。

$site_header
     各ページの先頭にインクルードされるHTMLを記述したファイル名。
     ‘gitweb.cgi’ スクリプトを含むディレクトリからの相対パスです。 ビル
     ド時に ‘GITWEB_SITE_HEADER’ を使用して設定することができる。デフォ
     ルト値はありません。

$site_footer
     各ページの下部にインクルードされるHTMLを含むファイルの名前。
     ‘gitweb.cgi’ スクリプトを含むディレクトリに相対的です。ビルド時に
     ‘GITWEB_SITE_FOOTER’ を使用して設定できます。 デフォルト値はありま
     せん。

$home_text
     存在すればgitwebプロジェクトの概要ページ(‘projects_list’ ビュー)に
     インクルードされるHTMLファイルの名前。 ‘gitweb.cgi’ スクリプトを含
     むディレクトリに相対的です。デフォルト値は、 ‘GITWEB_HOMETEXT’ 変数
     を使用してビルド時に調整できます。デフォルトでは ‘indextext.html’ に
     設定されています。

$projects_list_description_width
     プロジェクトリストの「説明」列の幅(文字数)。長い説明は切り捨てられ
     ます(単語の境界で切り取ろうと試みます)。完全な説明は、(通常はマウス
     オーバーで表示される)title属性にあります。デフォルトは25ですが、長
     いプロジェクトの説明を使用する場合は小さすぎる可能性があります。

$default_projects_order
     プロジェクトリストページでのプロジェクトの順序のデフォルト値。これ
     は、プロジェクトリストを明示的に並べ替えない場合に使用される順序を
     意味します(URLに ‘o’ CGIクエリパラメータがない場合)。 有効な値は、
     「none」(並べ替えなし)、「project」(プロジェクトはプロジェクト名、
     つまり「$ projectroot」からのリポジトリへのパス)、「descr」(プロジ
     ェクトの説明)、「owner」、「age」(最新のコミットの日付) です。

     デフォルト値は ‘project’ です。不明な値は、ソートされていないことを
     意味します。

Changing gitweb’s behavior
==========================

これらの構成変数は、gitwebの「内部」動作を制御します。

$default_blob_plain_mimetype
     mimetypeチェックで他のタイプが生成されない場合の、blob_plain (raw)ビ
     ューのデフォルトのmimetype。デフォルトでは "text/plain" です。
     Gitwebは、 ‘$mimetypes_file’ (設定されていてfileが存在する場合)と
     ‘/etc/mime.types’ ファイルを使用して、ファイル名の拡張子に基づいて
     表示するファイルのmimetypeを推測します。( mime.types(5) manpage を
     参照してください。gitwebではファイル名拡張子ルールのみがサポートさ
     れています。)

$default_text_plain_charset
     テキストファイルのデフォルトの文字セット。これが設定されていない場
     合は、Webサーバー構成が使用されます。デフォルトでは設定されていませ
     ん(unset)。

$fallback_encoding
     行にUTF-8以外の文字が含まれている場合、Gitwebはこの文字セットを想定
     します。フォールバックデコードはエラーチェックなしで使用されるため
     、「utf-8」にすることもできます。値は有効なエンコーディングである必
     要があります。 リストについては、 Encoding::Supported (3pm) の
     manpage を参照してください。デフォルトは「latin1」、別名「
     iso-8859-1」です。

‘@diff_opts’
     git-diffおよびgit-diff-treeの検出オプションの名前を変更します。デフ
     ォルトは (’-M’) です。コピーも検出するには (’-C’) または (’-C’,
     ’-C’）に設定するか、名前変更を検出したくない場合は () 、つまり空の
     リストに設定します。

     *注意* 名前変更(rename)、特にコピーの検出は、CPUにかなりの負荷がか
     かる可能性があります。 また、Git以外のツールでは、 上記のオプション
     で生成されたパッチで問題が発生する可能性があることにも注意してくだ
     さい。 特に、ファイルのコピー (’-C’) または交差名前変更(criss-cross
     renames) (’-B’) が含まれる場合はそうです。

Some optional features and policies
===================================

ほとんどの機能は ‘%feature’ ハッシュを介して構成されます。ただし、追加の
gitweb機能の一部は、以下で説明する変数を使用してオンにして構成できます。
gitwebの外観を制御する構成変数の傍にあるこのリストには、gitwebの管理側を
構成する変数が含まれています。(例: クロスサイトスクリプティングの防止。
ご存知のとおり、これは副作用として「要約」ページの外観や負荷制限に影響し
ます)

‘@git_base_url_list’
     GitベースURLのリスト。これらのURL群は、プロジェクトの概要ページに表
     示される、プロジェクトを取得する場所を説明するURLを生成するために使
     用されます。このリストの各要素の完全なフェッチURLは
     ‘$git_base_url/$project’ です。 複数のベースURLを設定できます(たと
     えば、1つは ‘git://’ プロトコル用、もう1つは ‘http://’ プロトコル用
     )。

     注意: リポジトリごとの構成は、 ‘$GIT_DIR/cloneurl’ ファイルで設定す
     ることも、プロジェクト構成の、複数値の ‘gitweb.url’ 構成変数の値と
     して設定することもできます。リポジトリごとの構成は、
     ‘@git_base_url_list’ 要素とプロジェクト名で構成される値よりも優先さ
     れます。

     あなたは ‘GITWEB_BASE_URL’ ビルド時構成変数を設定することにより、ビ
     ルド時に単一の値(1つの entry/item だけを持つリスト)を設定できます。
     デフォルトでは、 () 、つまり空のリストに設定されています。これは、
     gitwebがプロジェクト名から(フェッチのための)プロジェクトURLを作成し
     ようとしないことを意味します。

$projects_list_group_categories
     プロジェクトリストページでカテゴリ別にプロジェクトをグループ化でき
     るようにするかどうか。プロジェクトのカテゴリは、各リポジトリの構成
     の ‘$GIT_DIR/category’ ファイル、または ‘gitweb.category’ 変数によ
     って決定されます。デフォルトでは無効になっています(0に設定)。

$project_list_default_category
     何も指定されていないプロジェクトのデフォルトカテゴリ。 これが空の文
     字列に設定されている場合、そのようなプロジェクトは未分類のままで、
     分類されたプロジェクトの上に表示されます。 プロジェクトカテゴリが有
     効になっている場合、つまり ‘$projects_list_group_categories’ が
     trueの場合にのみ使用されます。デフォルトでは "" (空文字列)に設定さ
     れています。

$prevent_xss
     trueの場合、リポジトリ内のコンテンツがクロスサイトスクリプティング
     (XSS)攻撃を開始するのを防ぐために、一部のgitweb機能が無効になってい
     ます。リポジトリのコンテンツを信頼できない場合は、これをtrueに設定
     します。デフォルトではFalse(0に設定)。

$maxload
     gitwebクエリに応答する最大負荷を設定するために使用されます。サーバ
     ーの負荷がこの値を超えると、gitwebは「503 Service Unavailable」エラ
     ーを返します。 gitwebがその値を判別できない場合、サーバーの負荷は
     0と見なされます。 現在、Linuxでのみ動作し、 ‘/proc/loadavg’ を使用
     します。 負荷は、システム上でアクティブなタスクの数 — 実際に実行さ
     れているプロセス — が最後の1分間に平均化されたものです。

     この機能をオフにするには、 ‘$maxload’ を未定義の値(undef)に設定しま
     す。デフォルト値は300です。

$omit_age_column
     trueの場合、プロジェクトリストページの最新のコミットの日付の列を省
     略します。リポジトリごとに少しのI/Oとフォークを節約できます。

$omit_owner
     trueの場合、リポジトリ所有者に関する情報を表示できなくなります。

$per_request_config
     これがコードへの参照に設定されている場合、リクエストごとに1回実行さ
     れます。この方法で、セッションごとに構成の一部を変更設定できます。
     たとえば、gitweb構成ファイルで以下のコードを使用する場合があります

          our $per_request_config = sub {
                  $ENV{GL_USER} = $cgi->remote_user || "gitweb";
          };

     ‘$per_request_config’ がコードへの参照でない場合、ブール値として解
     釈されます。trueの場合、gitwebはリクエストごとに1回設定ファイルを処
     理し、falseの場合、gitwebは実行されるたびに1回だけ設定ファイルを処
     理します。デフォルトではtrueです(1に設定)。

     *注意*: ‘$my_url’ と ‘$my_uri’ と ‘$base_url’ は、すべてのリクエス
     トの発生前にデフォルト値で上書きされるため、 変更する場合は、必ずこ
     の変数をtrueに設定するか、 必要な変更を行うコードへの参照を設定して
     ください。

     この変数は、mod_perl、FastCGI、Plackupなどの単一のgitwebインスタン
     スを使用して複数のリクエストを処理する永続的なWeb環境を使用する場合
     にのみ重要です。

Other variables
===============

通常、あなたは以下で説明する構成変数を変更(調整)する必要はありません。 そ
れらは正しい値にするために、gitwebが自動で設定する必要があります。

$version
     Gitwebバージョン。gitweb.perlからgitweb.cgiを作成するときに自動的に
     設定されます。たとえば、あなたが変更したgitwebを実行している場合は
     、変更することをお勧めします。

          our $version .= " with caching";

     あなたがキャッシュのサポートがある、変更バージョンのgitwebを実行す
     る場合。この変数は純粋に情報提供用であり、たとえばHTMLヘッダーの「
     generator」メタヘッダー内で使われます。

$my_url
$my_uri
     gitwebスクリプトの完全なURLと絶対URL。以前のバージョンのgitwebでは
     、これらの変数を設定する必要があるかもしれませんが、今では設定する
     必要はありません。 まだ設定する必要がある場合は、
     ‘$per_request_config’ を参照してください。

$base_url
     gitwebによって生成されたページ内の相対URLのベースURL(例えば、相対
     URLの場合は _$logo_ 、 _$favicon_ 、 _@stylesheets_)が必要で、空で
     ないPATH_INFOを持つURLに対してのみ _<base href="$base_url">_ が必要
     でした。通常、gitwebはその値を正しく設定し、この変数に $my_uri や
     "/" などを設定する必要はありません。あなたがとにかくそれをオーバー
     ライドする必要がある場合は、 _$per_request_config_ を参照してくださ
     い。

CONFIGURING GITWEB FEATURES
***************************

多くのgitweb機能は、 ‘%feature’ ハッシュ(連想配列)を使用して有効化(また
は無効化)および構成できます。gitweb機能の名前は、このハッシュのキーです
。

   各 ‘％feature’ ハッシュ(連想配列)要素はハッシュへの参照であり、以下の
構造を持っています:

     "<feature_name>" => {
             "sub" => <feature-sub (subroutine)>,
             "override" => <allow-override (boolean)>,
             "default" => [ <options>... ]
     },

   一部の機能は、プロジェクトごとにオーバーライドできません。 これらの機
能の場合、適切な ‘%feature’ ハッシュ要素の構造はより単純な形式になります
:

     "<feature_name>" => {
             "override" => 0,
             "default" => [ <options>... ]
     },

   上記にはご覧のとおり、’sub’ 要素がありません。

   機能構成の各部分の意味を以下に説明します:

default
     機能パラメータ(存在する場合)のリスト(配列への参照)。特定の機能を切
     り替える(有効または無効にする)ためにも使用されます。

     注意: 機能が構成パラメーターを受け入れない場合でも、現在は常に配列
     への参照であり、’default’ はオンまたはオフにするためにのみ使用され
     ることに注意してください。 このような場合は、この要素を ‘[1]’ に設
     定して機能をオンにし、 ‘[0]’ に設定して機能を解除します。「
     Examples例」セクションの「blame」機能に関する一節も参照してください
     。

     パラメータを受け入れる(設定可能な)機能を無効にするには、この要素を
     空のリスト、つまり ‘[]’ に設定する必要があります。

override
     このフィールドにtrue値がある場合、指定の機能はオーバーライド可能で
     す。つまり、リポジトリごとに構成(または 有効/無効 化)できます。

     通常、指定の「<feature>」は、リポジトリごとのGit構成ファイルの
     ‘gitweb.<feature>’ 構成変数を介して構成できます。

     *注意* デフォルトではオーバーライド可能な機能はありません。

sub
     実装の内部詳細。重要なのは、このフィールドが存在しない場合、特定の
     機能のリポジトリごとのオーバーライドはサポートされないということで
     す。

     あなたはgitweb構成ファイルでこれを変更する必要はありません。

Features in %feature
====================

‘%feature’ ハッシュを介して構成可能なgitweb機能を以下に示します。これは
完全なリストであるべきですが、最終的に信頼できる完全なリストは
gitweb.cgiソースコードにあり、機能はそのコメントで説明されています。

blame
     「blame」および「blame_incremental」ブロブビューを有効にし、各行に
     それを変更した最後のコミットを表示します。 git-blame(1) を参照して
     ください。 これはCPUに非常に負荷がかかる可能性があるため、デフォル
     トでは無効になっています。

     この機能は、リポジトリの ‘gitweb.blame’ 構成変数(ブール値)を介して
     リポジトリごとに構成できます。

snapshot
     「snapshot」アクションを有効にして構成します。これにより、ユーザー
     は、 git-archive(1) によって生成され、そして、場合によってはさらに
     圧縮された、任意のツリーまたはコミットの圧縮アーカイブをダウンロー
     ドできます。大規模なプロジェクトがある場合、これにより大量のトラフ
     ィックが発生する可能性があります。

     ’default’ の値は、提供するスナップショット形式の名前のリストであり
     、 ‘%known_snapshot_formats’ ハッシュで定義されています。サポートさ
     れている形式には、"tgz"、"tbz2"、"txz" (gzip/bzip2/xz で圧縮された
     tarアーカイブ)、および "zip" が含まれます。完全なリストについては、
     gitwebのソースを参照してください。 デフォルトでは、"tgz"のみが提供
     されます。

     この機能は、リポジトリの ‘gitweb.snapshot’ 構成変数を介してリポジト
     リごとに構成できます。この変数には、書式のコンマ区切りリストが含ま
     れるか、スナップショットを無効にする場合は ‘none’ が含まれます。不
     明な値は無視されます。

grep
     grep検索を有効にします。これにより、現在選択されているツリー(ディレ
     クトリ)内で指定の文字列を含むファイルが一覧表示されます。
     git-grep(1) を参照してください。 もちろん、これは潜在的にCPUを集中
     的に使用する可能性があります。 デフォルトで有効になっています。

     この機能は、リポジトリの ‘gitweb.grep’ 構成変数(ブール値)を介してリ
     ポジトリごとに構成できます。

pickaxe
     いわゆるpickaxe検索を有効にします。これにより、ファイル内の特定の文
     字列を導入または削除したコミットが一覧表示されます。 これは実用的で
     、「blame」アクションの非常に高速な代替手段ですが、それでもCPUに負
     荷がかかる可能性があります。 デフォルトで有効になっています。

     pickaxe検索については、 git-log(1) で説明されています(詳細について
     は gitdiffcore(7) のpickaxeエントリの ‘-S<string>’ オプションを参照
     してください)。

     この機能は、リポジトリの ‘gitweb.pickaxe’ 構成変数(ブール値)を設定
     することにより、リポジトリごとに構成できます。

show-sizes
     ‘ls -l’ と同様に、別の列の「ツリー」ビューにブロブ(通常のファイル
     )のサイズを表示できるようにします。 git-ls-tree(1) のmanpageにある
     ‘-l’ オプションの説明を参照してください。これにはちょびっとI/Oコス
     トがかかります。デフォルトで有効になっています。

     この機能は、リポジトリの ‘gitweb.showSizes’ 構成変数(ブール値)を介
     してリポジトリごとに構成できます。

patches
     コミットのリストを電子メール(プレーンテキスト)出力形式で表示する「
     パッチ」ビューを有効にして構成します。 git-format-patch(1) も参照し
     てください。 この値は、「パッチ」ビューで生成されたパッチセット内の
     パッチの最大数です。 _default_ フィールドを、パッチビューを無効にす
     るための単一の項目を含むリストまたは空のリストに設定するか、制限を
     削除するために単一の負の数を含むリストに設定します。デフォルト値は
     16です。

     この機能は、リポジトリの ‘gitweb.patches’ 構成変数(整数)を介してリ
     ポジトリごとに構成できます。

avatar
     アバター(avatar)のサポート。この機能を有効にすると、「shortlog」や
     「commit」などのビューに、各コミッターと作成者の電子メールに関連付
     けられたアバターが表示されます。

     現在利用可能なプロバイダーは、 gravatar と picon です。 一度に選択
     できるプロバイダーは1つだけです(「default」は要素1つだけのリストで
     す)。不明なプロバイダーが指定されている場合、この機能は無効になりま
     す。 *注意* 一部のプロバイダーでは、追加のPerlパッケージをインスト
     ールする必要がある場合があります。 詳細については、
     ‘gitweb/INSTALL’ を参照してください。

     この機能は、リポジトリの ‘gitweb.avatar’ 構成変数を介してリポジトリ
     ごとに構成できます。

     アイコンとアバターのピクセルサイズを含む ‘%avatar_size’ も参照して
     ください( "default" は "log" や "shortlog" などの1行モノに使用され
     、 "double" は "commit"、"commitdiff"、"tag" などの2行モノに使用さ
     れます)。デフォルトのフォントサイズまたは行の高さが変更された場合は
     、これらの値を変更すること(たとえば、 ‘@stylesheets’ にCSSスタイル
     シートを追加するなど)が適切な場合があります。

email-privacy
     生成されたHTMLなどのコンテンツの電子メールアドレスを改訂します。こ
     れにより、Gitログの作者/コミッターおよびコメントセクションから取得
     された電子メールアドレスを不明瞭にします。 これは、アドレスを収集し
     て悪用するWebクローラーを妨害することを目的としています。このような
     クローラーはrobots.txtを尊重しない場合があります。 注意: ユーザーと
     ユーザーツールもアドレスが編集されたものとして表示されることに注意
     してください。Gitwebがワークフローの最後のステップではない場合、後
     続のステップは、受け取った情報が編集されているために誤動作する可能
     性があります。デフォルトでは無効になっています。

highlight
     「ブロブ」ビューでサーバー側構文ハイライトサポートします。
     ‘$height_bin’ プログラムが使用可能である必要があるため(上記の「構成
     変数」セクションの、この変数の説明を参照)、デフォルトで無効になって
     います。

     この機能は、リポジトリの ‘gitweb.highlight’ 構成変数(ブール値)を介
     してリポジトリごとに構成できます。

remote_heads
     「ヘッド」リストにリモートヘッド(リモート追跡ブランチ)を表示できる
     ようにします。ほとんどの場合、リモート追跡ブランチのリストは不要な
     内部プライベート詳細であるため、この機能はデフォルトで無効になって
     います。 git-instaweb(1) は、通常、ローカルリポジトリを参照するため
     に使用され、この機能を有効にして使用します。

     この機能は、リポジトリの ‘gitweb.remote_heads’ 構成変数(ブール値)を
     介してリポジトリごとに構成できます。

   以下の、残りの機能は、プロジェクトごとにオーバーライドすることはでき
ません。

search
     テキスト検索を有効にします。これにより、作者(author)または、コミッ
     ターまたは、コミットテキストが特定の文字列に一致するコミットが一覧
     表示されます。 git-log(1) のmanpage にある ‘--author’ と
     ‘--committer’ と ‘--grep’ オプションの説明を参照してください。デフ
     ォルトで有効になっています。

     プロジェクト固有のオーバーライドはサポートされていません。

forks
     この機能が有効になっている場合、gitwebは、プロジェクトルート(ベース
     名)のサブディレクトリ内のプロジェクトを既存のプロジェクトのフォーク
     と見なします。 ‘$projname.git’ プロジェクトごとに、 ‘$projname/’ デ
     ィレクトリ内のプロジェクトとそのサブディレクトリはメインプロジェク
     トリストに表示されません。代わりに、 ‘$projname’ の横に ‘+’ マーク
     が表示されます。これは、すべてのフォーク(‘$projname/’ サブディレク
     トリ内のすべてのプロジェクト)を一覧表示する "forks" ビューにリンク
     しています。さらに、プロジェクトの「fork」ビューは、プロジェクトの
     概要ページからリンクされています。

     プロジェクトリストがファイルから取得された場合( ‘$projects_list’ は
     ファイルを指している)、フォーク(fork)は、そのファイルのメインプロジ
     ェクトの後にリストされている場合にのみ認識されます。

     プロジェクト固有のオーバーライドはサポートされていません。

actions
     すべてのプロジェクトページのアクションバーへのカスタムリンクを挿入
     します。これにより、あなたはgitwebに統合されているサードパーティの
     スクリプトにリンクできます。

     「default」値は、 ‘("<label>", "<link>", "<position>")’ という3要素
     組形式の、リストで構成されます。ここで、 "position" は、リンクを挿
     入するラベルです。 "link" はフォーマット文字列で、 ‘%n’ はプロジェ
     クト名に展開され、 ‘%f’ はファイルシステム内のプロジェクトパス(つま
     り "$projectroot/$project")に展開され、 ‘%h’ は現在のハッシュ(‘h’
     gitwebパラメーター)、 ‘%b’ は現在のハッシュベース(‘hb’ ’gitwebパラ
     メーター) です。‘%%’ は ‘%’ に展開されます。

     たとえば、このページが作成された時点で、 http://repo.or.cz
     (http://repo.or.cz) Gitホスティングサイトは、グラフィカルログを有効
     にするために次のように設定しました(サードパーティツール git-browser
     を使用):

          $feature{'actions'}{'default'} =
                  [ ('graphiclog', '/git-browser/by-commit.html?r=%n', 'summary')];

     これにより、「summary」リンクの後に「graphiclog」というタイトルのリ
     ンクが追加され、クエリパラメータとして ‘r=<project>’ を渡して、
     ‘git-browser’ スクリプトへ誘導します。

     プロジェクト固有のオーバーライドはサポートされていません。

timed
     ページフッター(ページの下部)に各ページを生成して表示するのにかかっ
     た時間とGitコマンドの数を表示できるようにします。たとえば、フッター
     には次のように含まれます。「This page took 6.53325 seconds and 13
     Git commands to generate.」(このページの生成には6.53325秒と13の
     Gitコマンドが必要でした。)。デフォルトでは無効になっています。

     プロジェクト固有のオーバーライドはサポートされていません。

javascript-timezone
     JavaScriptを介してgitweb出力の日付の共通タイムゾーンを変更する機能
     を有効にして構成します。 gitweb出力の日付には、「commit」ビューと「
     commitdiff」ビューと「log」ビューでのauthordateとcommitterdate、お
     よび「tag」ビューでのtaggerdateが含まれます。デフォルトで有効になっ
     ています。

     値は、3つの値のリストです。デフォルトのタイムゾーン(default time
     zone)(クライアントが他のタイムゾーンを選択してCookieに保存していな
     い場合)と、選択したタイムゾーンを保存するCookieの名前と、操作の日付
     をマークアップするために使用されるCSSクラスです。この機能をオフにす
     る場合は、「default」を空のリストに設定します。つまり ‘[]’ 。

     通常のgitweb構成ファイルでは、最初の、(default)タイムゾーンのみを変
     更し、他の要素はデフォルト値のままにします:

          $feature{'javascript-timezone'}{'default'}[0] = "utc";

     ここに示されている構成例は、下位互換性と上位互換性が保証されていま
     す。

     タイムゾーンの値は、 "local"(ブラウザが使用するローカルタイムゾーン
     の場合)、"utc"(JavaScriptまたは、この機能が無効になっている場合に
     gitwebが使用するもの)、または "‘0200" のような "’/-HHMM" 形式の数値
     のタイムゾーンにすることができます。

     プロジェクト固有のオーバーライドはサポートされていません。

extra-branch-refs
     "refs" の下にある、ブランチのrefとして使用される追加ディレクトリの
     リスト。たとえば、gerrit のセットアップで、refs/heads/ 以下のすべて
     のブランチが公式のもので、push-after-review のもの、そして
     refs/sandbox/, refs/wip, refs/other 以下のブランチはより広いパーミ
     ッションを持つユーザーのものである場合、あなたはこの変数を以下のよ
     うに設定したいと思うことでしょう。

          $feature{'extra-branch-refs'}{'default'} =
                  ['sandbox', 'wip', 'other'];

     この機能は、 $feature{_extra-branch-refs_}{_override_} をtrueに設定
     した後、リポジトリの ‘gitweb.extraBranchRefs’ 構成変数を介して、リ
     ポジトリごとに構成できます。これには、スペースで区切られたrefのリス
     トが含まれます。 例:

          [gitweb]
                  extraBranchRefs = sandbox wip other

     gitweb.extraBranchRefsは実際には複数値の構成変数であるため、以下の
     例も正しくて、結果は上記のスニペットと同じです:

          [gitweb]
                  extraBranchRefs = sandbox
                  extraBranchRefs = wip other

     「gitcheck-ref-format」の精査に合格しないrefを指定するとエラーにな
     ります。 重複した値はフィルタリングされます。

EXAMPLES
********

blameと、pickaxe検索と、スナップショットのサポート("tar.gz" と "zip" の
スナップショットを許可)を有効にし、個々のプロジェクトでそれらをオフにで
きるようにするには、GITWEB_CONFIGファイルに以下のように入力します:

     $feature{'blame'}{'default'} = [1];
     $feature{'blame'}{'override'} = 1;

     $feature{'pickaxe'}{'default'} = [1];
     $feature{'pickaxe'}{'override'} = 1;

     $feature{'snapshot'}{'default'} = ['zip', 'tgz'];
     $feature{'snapshot'}{'override'} = 1;

   スナップショット機能のオーバーライドを許可する場合は、グローバルに無
効にするスナップショット形式を指定できます。必要なコマンドラインオプショ
ン(圧縮レベルの設定など)を追加することもできます。 たとえば、gitweb構成
ファイルに以下の行を追加することで、Zip圧縮スナップショットを無効にし、
gzip(1)をレベル6で実行するように設定できます:

     $known_snapshot_formats{'zip'}{'disabled'} = 1;
     $known_snapshot_formats{'tgz'}{'compressor'} = ['gzip','-6'];

BUGS
****

フォールバック構成ファイル(‘/etc/gitweb.conf’)とその場所をオーバーライド
する環境変数(_GITWEB_CONFIG_SYSTEM_)に、「fallback」の役割を反映した名前
が付いていると、デバッグが容易になります。 現在の名前は、作業セットアッ
プを壊さないように保持されます。

ENVIRONMENT
***********

インスタンスごとおよびシステム全体の構成ファイルの場所は、以下の環境変数
を使用してオーバーライドできます:

GITWEB_CONFIG
     インスタンスごとの構成ファイルの場所を設定します。

GITWEB_CONFIG_SYSTEM
     フォールバックするシステム全体の構成ファイルの場所を設定します。 こ
     のファイルは、インスタンスごとのファイルが存在しない場合にのみ読み
     取られます。

GITWEB_CONFIG_COMMON
     共通のシステム全体の構成ファイルの場所を設定します。

FILES
*****

‘gitweb_config.perl’
     これは、インスタンスごとの構成ファイルのデフォルト名です。このファ
     イルの形式は前述のとおりです。

‘/etc/gitweb.conf’
     これは、フォールバックするシステム全体の構成ファイルのデフォルト名
     です。このファイルは、インスタンスごとの構成変数が見つからない場合
     にのみ使用されます。

‘/etc/gitweb-common.conf’
     これは、共通システム全体の構成ファイルのデフォルト名です。

SEE ALSO
********

gitweb(1), git-instaweb(1)

   _gitweb/README_, _gitweb/INSTALL_

GIT
***

Part of the git(1) suite

Name
****

gitweb — Git Webインターフェイス(GitリポジトリのためのWebフロントエンド)

Synopsis
********

gitwebの使用を開始するには、Gitリポジトリから git-instaweb(1) を実行しま
す。これにより、Webサーバーが構成および起動され、gitwebを指すWebブラウザ
ーが実行されます。

DESCRIPTION
***********

Gitwebは、GitリポジトリへのWebインターフェイスを提供します。その機能は以
下のとおりです:

   • 共通のルートを持つ複数のGitリポジトリを表示します。

   • リポジトリのすべてのリビジョンをブラウズします。

   • リポジトリ内の任意のリビジョンのファイルの内容を表示します。

   • ブランチのリビジョンログ、ファイルとディレクトリの履歴を表示して、
     何がいつ、誰によって変更されたかを表示します。

   • (有効になっている場合)ファイルの blame/annotation の詳細を表示しま
     す。

   • 任意のブランチに対して、コミットのRSSおよびAtomフィードを生成します
     。フィードは、最新のWebブラウザーで自動検出可能です。

   • リビジョンで変更されたすべてのものを表示し、一度に1つずつリビジョン
     をステップ表示して、リポジトリの履歴を表示します。

   • 指定した検索語にマッチするコミットメッセージのコミットを検索します
     。

   gitweb自体を使用してブラウズできるgitwebソースコードについては、
http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/
(http://repo.or.cz/w/git.git/tree/HEAD:/gitweb/) を参照してください。

CONFIGURATION
*************

gitwebの動作のさまざまな側面は、構成ファイル ‘gitweb_config.perl’ または
‘/etc/gitweb.conf’ を介して制御できます。詳細については gitweb.conf(5) を
参照してください。

Repositories
============

Gitwebは、1つ以上のGitリポジトリからの情報を表示できます。 これらのリポ
ジトリはすべてローカルファイルシステム上にあり、共通のリポジトリルートを
共有する必要があります。つまり、すべてが単一の親リポジトリの下にある必要
があります(ただし、「Advanced web server setup」セクションの「Webserver
configuration with multiple projects’ root」(複数のプロジェクトのルート
を使用したWebサーバーの構成)サブセクションも参照してください)。

     our $projectroot = '/path/to/parent/directory';

   ‘$projectroot’ のデフォルト値は ‘/pub/git’ です。 gitwebのビルド中に
、‘GITWEB_PROJECTROOT’ ビルド構成変数を介して変更できます。

   デフォルトでは、 ‘$projectroot’ の下にあるすべてのGitリポジトリが表示
され、gitwebで利用できます。 プロジェクトのリストは、デフォルトで
‘$projectroot’ ディレクトリをスキャンしてGitリポジトリを探します(オブジ
ェクトデータベースをより正確に言うと、gitwebは作業領域に関心がなく、「裸
の」(bare)リポジトリを表示するのに最適です)。

   gitwebのリポジトリの名前は、‘$projectroot’ を基準にした ‘$GIT_DIR’ (そ
のオブジェクトデータベース)へのパスです。 したがって、リポジトリ $repoは
‘$projectroot/$repo’ にあります。

Projects list file format
=========================

$projectroot から始まるファイルシステムをスキャンしてgitwebにリポジトリ
を検索させる代わりに、(いくつかの追加情報を含む)プロジェクトのリストを含
むプレーンテキストファイルを指すように ‘$projects_list’ を設定することに
より、事前生成された表示可能なプロジェクトのリストを提供できます。

   このファイルは以下の形式を使用します:

   • 1行に1つのレコード(プロジェクト/リポジトリ用)。行の継続(改行のエス
     ケープ)はサポートされていません。

   • 先頭と末尾の空白(whitespace)は無視されます。

   • 空白(whitespace)で区切られたフィールド。 空白(whitespace)はすべてフ
     ィールド区切り文字として使用できます(Perlの "‘split(" ", $line)’" ル
     ール)。

   • フィールドは、RFC 3986のセクション2.1(Percent-Encoding)で定義されて
     いるmodified URI encoding、または「Query string encoding」
     (https://en.wikipedia.org/wiki/Query_string#URL_encoding
     (https://en.wikipedia.org/wiki/Query_string#URL_encoding) 参照)を使
     用します。違いは次のとおりです。 そのSP（‘ ‘）は `{plus}’ としてエ
     ンコードできます(したがって、 ‘{plus}’ もパーセントエンコードする必
     要があります)。

     予約文字は次のとおりです: ‘%’ (エンコードに使用)と、 ‘{plus}’ (スペ
     ースのエンコードに使用可能)と SP・TAB・LFを含むPerlで定義されている
     すべての空白文字(レコード内のフィールドの区切りに使用)。

   • 現在認識されているフィールドは以下のとおりです:

     <repository path>
          ‘$projectroot’ に相対的なリポジトリ GIT_DIR へのパス

     <repository owner>
          リポジトリの所有者、できればフルネームまたは電子メール、または
          その両方として表示されます

   あなたはgitwebから直接project_indexアクション(プロジェクトリストペー
ジの TXT リンク)を使用して、プロジェクトリストインデックスファイルを生成
できます。 以下の「Generating projects list using gitweb」(gitwebを使用
したプロジェクトリストの生成)セクションも参照してください。

   内容例:

     foo.git       Joe+R+Hacker+<joe@example.com>
     foo/bar.git   O+W+Ner+<owner@example.org>

   デフォルトでは、このファイルはプロジェクトリストページに「表示」され
るプロジェクトのみを制御します(注意:正しく認識されたGitリポジトリを指し
ていないエントリはgitwebによって表示されないことに注意してください)。あ
なたはプロジェクトがプロジェクトリストページに表示されていない場合でも、
gitwebURLを手動で作成することでプロジェクトを表示できます。
‘$strict_export’ 構成変数(gitweb.conf(5) 参照)をtrueに設定すると、概要ペ
ージにも表示されるリポジトリのみを表示許可します(つまり、プロジェクトリ
ストファイルに明示的にリストされているプロジェクトのみのアクセス)。

Generating projects list using gitweb
=====================================

私達はGITWEB_CONFIGにはデフォルトのMakefile値、つまり「
gitweb_config.perl」があると想定しています。 ‘gitweb_make_index.perl’ フ
ァイルに以下を入れてください:

     read_config_file("gitweb_config.perl");
     $projects_list = $projectroot;

   次に、以下のスクリプトを作成して、GITWEB_LISTビルド構成変数(または
gitweb構成の ‘$projects_list’ 変数)に適した形式でプロジェクトのリストを
取得します。

     #!/bin/sh

     export GITWEB_CONFIG="gitweb_make_index.perl"
     export GATEWAY_INTERFACE="CGI/1.1"
     export HTTP_ACCEPT="*/*"
     export REQUEST_METHOD="GET"
     export QUERY_STRING="a=project_index"

     perl -- /var/www/cgi-bin/gitweb.cgi

   このスクリプトを実行し、その出力をファイルに保存します。このファイル
は、プロジェクトリストファイルとして使用できます。つまり
‘$projects_list’ にそのファイル名を設定できます。

Controlling access to Git repositories
======================================

デフォルトでは、 ‘$projectroot’ の下にあるすべてのGitリポジトリが表示さ
れ、gitwebで利用できます。 ただし、あなたはgitwebがリポジトリへのアクセ
スを制御する方法を構成できます。

   • 「Projects list file format」のセクションで説明したように、プロジェ
     クトリストファイルにリポジトリを選択的に含め、それを指すように ‘$
     projects_list’ gitweb構成変数を設定することにより、どのプロジェクト
     を「表示」するかを制御できます。 ‘$strict_export’ を設定すると、プ
     ロジェクトリストファイルを使用して、「利用可能な」リポジトリを制御
     することもできます。

   • あなたはgitweb構成ファイルの ‘$export_ok’ 変数を使用して、明示的に
     エクスポートされたリポジトリのみを一覧表示して表示できるように
     gitwebを構成できます。 gitweb.conf(5) のmanpageを参照してください。
     trueと評価された場合、gitwebは、 ‘$export_ok’ を評価したファイル名
     のファイルがオブジェクトデータベースに存在する場合にのみリポジトリ
     を表示します(つまりディレクトリに ‘$export_ok’ を評価した値のファイ
     ル名のマジックファイルがある場合)。

     たとえば、 git-daemon(1)は、デフォルトで(‘--export-all’ オプション
     が使用されていない限り)、 ‘git-daemon-export-ok’ ファイルを持つリポ
     ジトリに対してのみプルを許可します。以下のように追加します

          our $export_ok = "git-daemon-export-ok";

     こうすると、gitwebを表示し、 ‘git://’ プロトコルを介してフェッチで
     きるリポジトリへのアクセスのみを許可します。

   • 最後に、リポジトリごとに呼び出される任意のperlサブルーチンを指定し
     て、リポジトリをエクスポートできるかどうかを判断することができます
     。サブルーチンは、プロジェクト(リポジトリ)への絶対パスを唯一のパラ
     メータ(つまり、 ‘$projectroot/$ project’ )として受け取ります。

     たとえば、mod_perlを使用してスクリプトを実行し、リポジトリにバカ
     HTTPプロトコル認証(dumb HTTP protocol authentication)を構成している
     場合、以下のフックを使用して、ユーザーがファイルの読み取りを許可さ
     れている場合にのみアクセスを許可できます。

          $export_auth_hook = sub {
                  use Apache2::SubRequest ();
                  use Apache2::Const -compile => qw(HTTP_OK);
                  my $path = "$_[0]/HEAD";
                  my $r    = Apache2::RequestUtil->request;
                  my $sub  = $r->lookup_file($path);
                  return $sub->filename eq $path
                      && $sub->status == Apache2::Const::HTTP_OK;
          };

Per-repository gitweb configuration
===================================

gitwebに表示される個々のリポジトリを構成するには、Gitリポジトリの
‘GIT_DIR’ にファイルを作成するか、リポジトリ構成変数を設定します(
‘GIT_DIR/config’ で。 git-config(1) 参照)。

   あなたはリポジトリ内で以下のファイルを使用できます:

README.html
     gitwebプロジェクトの「summary」ページの ‘<div>’ ブロック要素内にイ
     ンクルードされるhtmlファイル(HTMLブロック)。プロジェクトのより長い
     説明、リンクの提供(たとえば、プロジェクトのホームページへ)などに使
     用できます。これは、XSS防止がオフの場合にのみ認識されます
     (‘$prevent_xss’ はfalseです。 gitweb.conf(5) 参照)。XSS防止がオンに
     なっているときにREADMEを安全に含める方法は、将来的には解決される可
     能性があります。

description (または ‘gitweb.description’)
     短いプロジェクトの(リポジトリの)1行説明(プロジェクトリストページで
     は ‘$ projects_list_description_width’ に長さをつめます。デフォルト
     では25文字です。 gitweb.conf(5) 参照)。プレーンテキストファイルです
     。 HTMLはエスケープされます。デフォルトで以下のように設定されていま
     す

          Unnamed repository; edit this file to name it for gitweb.

     リポジトリ作成中にテンプレートから引用されます。テンプレートは通常
     は ‘/usr/share/git-core/templates/’ にインストールされます。
     ‘gitweb.description’ リポジトリ構成変数を使用できますが、ファイルが
     優先されます。

category (または ‘gitweb.category’)
     プロジェクトの単一行カテゴリ。 ‘$projects_list_group_categories’ が
     有効になっている場合にプロジェクトをグループ化するために使用されま
     す。(ファイルと構成変数が設定されていない)デフォルトでは、分類され
     ていないプロジェクトは ‘$project_list_default_category’ カテゴリに
     入れられます。 ‘gitweb.category’ リポジトリ構成変数を使用できますが
     、ファイルが優先されます。

     構成変数‘$projects_list_group_categories‘ と
     ‘$project_list_default_category’ は gitweb.conf(5) で説明されていま
     す。

cloneurl (または 複数値変数の ‘gitweb.url’)
     1行に1つずつ、リポジトリURL(クローンとフェッチに使用)を含むファイル
     。プロジェクトの概要ページに表示されます。そのために複数値の
     ‘gitweb.url’ リポジトリ設定変数を使用できますが、ファイルが優先され
     ます。

     これは、グローバルプレフィックスベースの ‘@git_base_url_list’
     gitweb 設定変数をリポジトリ毎用に拡張/改造したものです
     (gitweb.conf(5) 参照)。

gitweb.owner
     ‘gitweb.owner’ リポジトリ設定変数を使用して、リポジトリの所有者を設
     定できます。 プロジェクトリストと概要ページに表示されます。

     これが設定されていない場合、 ‘$projects_list’ が設定されていなけれ
     ば(unset)、(gitweb は ‘$projectroot’ をスキャンしてリポジトリを探し
     、)ファイルシステムディレクトリの所有者(GECOSフィールド、つまり「
     getpwuid(3)」の実名フィールド経由)が使用されます。 ‘$projects_list’
     がリポジトリのリストを含むファイルを指している場合、プロジェクト所
     有者はデフォルトで、指定されたリポジトリのこのファイルの値になりま
     す。

various ‘gitweb.*’ config variables (in config)
     詳細なリストと説明については、 ‘%feature’ ハッシュ(連想配列)の説明
     をお読みください。 gitweb.conf(5) の「Configuring gitweb features」
     (gitweb機能の構成)セクションも参照してください。

ACTIONS, AND URLS
*****************

gitwebは、path_info (コンポーネント)ベースのURLを使用することも、クエリ
パラメーターを介して必要なすべての情報を渡すこともできます。一般的な
gitweb URLは、次の以下の5つのコンポーネントに分類されます:

     .../gitweb.cgi/<repo>/<action>/<revision>:/<path>?<arguments>

repo
     アクションが実行されるリポジトリ。

     利用可能なすべてのプロジェクトをリストするアクションを除く、すべて
     のアクションには、どのような形式でも、このパラメーターが必要です。

action
     実行されるアクション。 デフォルトは、リポジトリが設定されていない場
     合は ‘projects_list’ 、それ以外の場合は ‘summary’ です。

revision
     表示されるリビジョン。デフォルトはHEADです。

path
     それを必要とするアクション用の、アクションが実行される <repository>
     内のパス。

arguments
     アクションの振る舞いを制御する任意の引数。

   一部のアクションでは、2つのリビジョン、場合によっては2つのパス名を指
定する必要があります。最も一般的な形式では、このようなpath_info(コンポー
ネント)ベースの gitweb URL では以下のようになります:

     .../gitweb.cgi/<repo>/<action>/<revision_from>:/<path_from>..<revision_to>:/<path_to>?<arguments>

   各アクションはサブルーチンとして実装され、%actions ハッシュ(連想配列
)に存在する必要があります。一部のアクションはデフォルトで無効になってお
り、機能メカニズムを介してオンにする必要があります。たとえば、 ‘blame’ ビ
ューを有効にするには、gitweb構成ファイルに以下を追加します:

     $feature{'blame'}{'default'} = [1];

Actions:
========

標準のアクションは以下のとおりです:

project_list
     利用可能なGitリポジトリを一覧表示します。 URLにリポジトリが指定され
     ていない場合、これがデフォルトのコマンドです。

summary
     指定されたリポジトリに関する要約を表示します。 これは、URLにアクシ
     ョンが指定されておらず、リポジトリのみが指定されている場合のデフォ
     ルトのコマンドです。

heads
remotes
     特定のリポジトリ内の、すべてのローカル、またはすべてのリモート追跡
     ブランチを一覧表示します。

     後者は、構成されていない限り、デフォルトでは使用できません。

tags
     指定のリポジトリ内のすべてのタグ(軽量および注釈付き)を一覧表示しま
     す。

blob
tree
     指定のリポジトリパス内のファイルとディレクトリの指定のリビジョンを
     表示します。これは、URLにアクションが指定されておらず、パスが指定さ
     れている場合のデフォルトのコマンドです。

blob_plain
     指定されたリポジトリ内の指定されたパスとリビジョンのファイルの生デ
     ータを返します。このアクションへのリンクは ‘raw’ とマークされていま
     す。

blobdiff
     同一ファイルの2つのリビジョンの間の違いを示します。

blame
blame_incremental
     ファイルのblame(注釈とも呼ばれる)情報を表示します。行ごとに、その行
     が最後に変更されたリビジョンと、変更をコミットしたユーザーが表示さ
     れます。(設定されている場合は、JavaScriptが有効なときに自動的に使用
     される、)インクリメンタルバージョンは、Ajaxを使用して、指定されたフ
     ァイルのコンテンツにblame情報をインクリメンタルに追加します。

     このアクションは、パフォーマンス上の理由からデフォルトでは無効にな
     っています。

commit
commitdiff
     リポジトリ内の特定のコミットに関する情報を表示します。 ‘commit’ ビ
     ューにはコミットに関する情報がより詳細に表示され、 ‘commitdiff’ ア
     クションには特定のコミットの変更セットが表示されます。

patch
     git-am(1) で適用するのに適した、プレーンテキストのメール形式でコミ
     ットを返します。

tag
     特定の注釈付きタグ(タグオブジェクト)を表示します。

log
shortlog
     (特定のリビジョンから開始の)特定のブランチのログ情報(コミットメッセ
     ージまたはコミット件名)を表示します。

     shortlogビューはよりコンパクトです。1行に1つのコミットが表示されま
     す。

history
     指定されたリビジョンから開始して、指定されたリポジトリパス内のファ
     イルまたはディレクトリの履歴を表示します(デフォルトはHEAD、つまりデ
     フォルトのブランチ)。

     このビューは「shortlog」ビューに似ています。

rss
atom
     リポジトリへの変更のRSS(またはAtom)フィードを生成します。

WEBSERVER CONFIGURATION
***********************

このセクションでは、gitwebを実行するようにいくつかの一般的なWebサーバー
を構成する方法について説明します。いずれの場合も、例の ‘/path/to/gitweb’
は、インストールしたgitwebを実行したディレクトリであり、
‘gitweb_config.perl’ を含んでいます。

   あなたが、以下にリストされていない Web サーバーを gitweb 用に構成した
場合は、将来のリリースに含めることができるように、ぜひ手順を送ってくださ
い。

Apache as CGI
=============

Apacheは、gitwebがインストールされているディレクトリでCGIスクリプトをサ
ポートするように設定する必要があります。 それが ‘/var/www/cgi-bin’ ディ
レクトリであると仮定しましょう。

     ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

     <Directory "/var/www/cgi-bin">
         Options Indexes FollowSymlinks ExecCGI
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>

   この構成では、リポジトリをブラウズするためのフルパスは以下のようにな
ります:

     http://server/cgi-bin/gitweb.cgi

Apache with mod_perl, via ModPerl::Registry
===========================================

あなたはgitwebでmod_perlを使用できます。このサポートを有効にするには、
mod_perl 1.xの場合は Apache::Registry をインストールする必要があり、また
、 mod_perl 2.x の場合は ModPerl::Registry をインストールする必要があり
ます。

   gitwebが ‘/var/www/perl’ にインストールされていると仮定すると、以下の
Apache構成(mod_perl 2.xの場合)が適切です。

     Alias /perl "/var/www/perl"

     <Directory "/var/www/perl">
         SetHandler perl-script
         PerlResponseHandler ModPerl::Registry
         PerlOptions +ParseHeaders
         Options Indexes FollowSymlinks +ExecCGI
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>

   この構成では、リポジトリをブラウズするためのフルパスは以下のようにな
ります:

     http://server/perl/gitweb.cgi

Apache with FastCGI
===================

GitwebはApache＋FastCGIで動作します。 まず、 gitweb.cgiの名前を変更する
か、コピーするか、シンボリックリンクして gitweb.fcgi にする必要がありま
す。gitwebが ‘/usr/share/gitweb’ ディレクトリにインストールされていると
仮定しましょう。以下のApache構成が適しています(スマン。これれはテストさ
れていません！)

     FastCgiServer /usr/share/gitweb/gitweb.cgi
     ScriptAlias /gitweb /usr/share/gitweb/gitweb.cgi

     Alias /gitweb/static /usr/share/gitweb/static
     <Directory /usr/share/gitweb/static>
         SetHandler default-handler
     </Directory>

   この構成では、リポジトリをブラウズするためのフルパスは以下のようにな
ります:

     http://server/gitweb

ADVANCED WEB SERVER SETUP
*************************

これらの例はすべてリクエストの書き換えを使用しており、 ‘mod_rewrite’ (ま
たは同等のもの。以下の例はApache用に記述されています)が必要です。

Single URL for gitweb and for fetching
======================================

gitwebと あなたの ‘http://’ リポジトリの両方に1つのURLが必要な場合は、以
下のようにApacheを構成できます:

     <VirtualHost *:80>
         ServerName    git.example.org
         DocumentRoot  /pub/git
         SetEnv        GITWEB_CONFIG   /etc/gitweb.conf

         # turning on mod rewrite
         RewriteEngine on

         # make the front page an internal rewrite to the gitweb script
         RewriteRule ^/$  /cgi-bin/gitweb.cgi

         # make access for "dumb clients" work
         RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
                     /cgi-bin/gitweb.cgi%{REQUEST_URI}  [L,PT]
     </VirtualHost>

   上記の構成では、あなたのパブリックリポジトリが ‘/pub/git’ 下にあり、
クローン可能なGit URLとブラウズ可能なgitwebインターフェイスの両方として
‘http://git.domain.org/dir-under-pub-git’ としてサービス提供することを想
定しています。あなたの git-daemon(1) を ‘--base-path=/pub/git
--export-all’ を伴って開始すると、まったく同じパスで ‘git://’ URLを使用
することもできます。

   環境変数 ‘GITWEB_CONFIG’ を設定すると、名前付きファイル(つまり、この
例では ‘/etc/gitweb.conf’)をgitwebの構成として使用するようにgitwebに指示
します。 上記の例では、実際には必要ありません。構成ファイルが組み込み
(gitwebのコンパイル中) や ‘gitweb_config.perl’ や ‘/etc/gitweb.conf’ と
は異なる場所にある場合にのみ必要です。 詳細、特に優先順位ルールに関する
情報については、 gitweb.conf(5) を参照してください。

   あなたが例の書き換えルールを使用する場合は、gitweb構成ファイル(以下の
例の ‘/etc/gitweb.conf’)に以下のようなものも必要になる場合があります:

     @stylesheets = ("/some/absolute/path/gitweb.css");
     $my_uri    = "/";
     $home_link = "/";
     $per_request_config = 1;

   今どきでは、gitwebは必要に応じて、(相対リンクのベースURIを設定するた
めに、)HTMLベースタグを作成する必要があるため、自動的に機能するはずです
。

Webserver configuration with multiple projects’ root
====================================================

あなたが複数のプロジェクトルートでgitwebを使用する場合は、以下の方法で
Apache仮想ホストとgitweb構成ファイルを編集できます。

   (Apache構成ファイル内の)仮想ホスト構成は以下のようになります:

     <VirtualHost *:80>
         ServerName    git.example.org
         DocumentRoot  /pub/git
         SetEnv        GITWEB_CONFIG  /etc/gitweb.conf

         # turning on mod rewrite
         RewriteEngine on

         # make the front page an internal rewrite to the gitweb script
         RewriteRule ^/$  /cgi-bin/gitweb.cgi  [QSA,L,PT]

         # look for a public_git folder in unix users' home
         # http://git.example.org/~<user>/
         RewriteRule ^/\~([^\/]+)(/|/gitweb.cgi)?$   /cgi-bin/gitweb.cgi \
                     [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

         # http://git.example.org/+<user>/
         #RewriteRule ^/\+([^\/]+)(/|/gitweb.cgi)?$  /cgi-bin/gitweb.cgi \
                      [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

         # http://git.example.org/user/<user>/
         #RewriteRule ^/user/([^\/]+)/(gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
                      [QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]

         # defined list of project roots
         RewriteRule ^/scm(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
                     [QSA,E=GITWEB_PROJECTROOT:/pub/scm/,L,PT]
         RewriteRule ^/var(/|/gitweb.cgi)?$ /cgi-bin/gitweb.cgi \
                     [QSA,E=GITWEB_PROJECTROOT:/var/git/,L,PT]

         # make access for "dumb clients" work
         RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ \
                     /cgi-bin/gitweb.cgi%{REQUEST_URI}  [L,PT]
     </VirtualHost>

   ここで、実際のプロジェクトルートはWebサーバーから
‘GITWEB_PROJECT_ROOT’ 環境変数を介してgitwebに渡されるため、gitweb構成フ
ァイル(上記の例では ‘/etc/gitweb.conf’)に以下の行を入れる必要があります:

     $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";

   *Note* これはリクエストごとに設定する必要があるため、 ‘$
per_request_config’ はfalseであるか、 上記を ‘$per_request_config’ によ
って参照されるコードに含める必要があります。

   これらの構成により、2つのことが可能になります。 まず、サーバーの各
UNIXユーザー(‘<user>’)は、 ‘~/public_git/’ にある gitweb Gitリポジトリを
以下のURLで参照できます:

     http://git.example.org/~<user>/

   あなたがサーバーでこの機能を使用したくない場合は、2番目の書き換えルー
ルを削除してください。

   仮想ホストですでに ‘mod_userdir’ を使用している場合、または最初の文字
として ‘~‘ を使用したくない場合は、2番目の書き換えルールをコメント化また
は削除し、必要に応じてそれ以降のいずれかをコメント化解除します。

   次に、 ‘/pub/scm/’ と ‘/var/git/’ にあるリポジトリには、
‘http://git.example.org/scm/’ と ‘http://git.example.org/var/’ からアク
セスできます。3番目や4番目のような書き換えルールを追加することで、必要な
数のプロジェクトルートを追加できます。

PATH_INFO usage
===============

あなたがgitwebでPATH_INFOの使用を有効にするには以下のようにします

     $feature{'pathinfo'}{'default'} = [1];

   あなたのgitweb構成ファイルで、あなたのサーバーが以下の形式のURLを消費
および生成するようにサーバーを設定することができます

     http://git.example.com/project.git/shortlog/sometag

   つまり、以下のような構成を使用して、 ‘gitweb.cgi’ 部分を使用しません
。この構成では、 ‘/var/www/gitweb’ がWebサーバーのDocumentRootであり、
gitweb.cgiスクリプトと補完的な静的ファイル(スタイルシート、favicon、
JavaScript)が含まれていることを前提としています:

     <VirtualHost *:80>
             ServerAlias git.example.com

             DocumentRoot /var/www/gitweb

             <Directory /var/www/gitweb>
                     Options ExecCGI
                     AddHandler cgi-script cgi

                     DirectoryIndex gitweb.cgi

                     RewriteEngine On
                     RewriteCond %{REQUEST_FILENAME} !-f
                     RewriteCond %{REQUEST_FILENAME} !-d
                     RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
             </Directory>
     </VirtualHost>

   書き換えルールは、既存の静的ファイルが適切に提供されることを保証しま
すが、他のURLはPATH_INFOパラメーターとしてgitwebに渡されます。

   *注意* この場合、 ‘@stylesheets’ と ‘$my_uri’ と ‘$home_link’ の特別
な設定は必要ありません。 ただし、あなたのプロジェクトの .git ディレクト
リへの「ダムクライアント」(dumb client)アクセスは失われます (「Single
URL for gitweb and for fetching」セクションで説明されています)。 後者の
可能な回避策は次のとおりです。 つまり、あなたのプロジェクトのルートディ
レクトリ(例: ‘/pub/git’)に、 .git拡張子なしで名前を付けたプロジェクト(例
: ‘/pub/git/project.git’ の代わりに ‘/pub/git/project’)を作成し、
Apacheを以下のように構成します:

     <VirtualHost *:80>
             ServerAlias git.example.com

             DocumentRoot /var/www/gitweb

             AliasMatch ^(/.*?)(\.git)(/.*)?$ /pub/git$1$3
             <Directory /var/www/gitweb>
                     Options ExecCGI
                     AddHandler cgi-script cgi

                     DirectoryIndex gitweb.cgi

                     RewriteEngine On
                     RewriteCond %{REQUEST_FILENAME} !-f
                     RewriteCond %{REQUEST_FILENAME} !-d
                     RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
             </Directory>
     </VirtualHost>

   追加のAliasMatchにより、

     http://git.example.com/project.git

   これはプロジェクトのGitディレクトリへの生のアクセスを提供します(プロ
ジェクトのクローンを作成できるようにします)。

     http://git.example.com/project

   これは人間に優しいgitwebアクセスを提供します。

   この解決策100%安全ではありません。つまり、プロジェクトに ‘git/’ で始
まる名前付きref(ブランチ、タグ)がある場合、以下のようなパスがあります

     http://git.example.com/project/command/abranch..git/abranch

   これは404エラーで失敗します。

BUGS
****

お手数ですが、メールの件名に「gitweb」を入れて、バグや機能のリクエストを
git@vger.kernel.orgに報告してください (mailto:バグや機能のリクエストを
git@vger.kernel.orgに報告してください)。

SEE ALSO
********

gitweb.conf(5), git-instaweb(1)

   ‘gitweb/README’, ‘gitweb/INSTALL’

GIT
***

Part of the git(1) suite

Name
****

gitworkflows — Gitで推奨の作業手順の概要

Synopsis
********

     git *

DESCRIPTION
***********

この文書は、 ‘git.git’ 自体に使用されるワークフロー要素のいくつかを書き
留めて動機付けしようとしています。一般に多くのアイデアが当てはまりますが
、関係者が少ない小規模なプロジェクトではこのような完全なワークフローが必
要になることはめったにありません。

   私たちが、すぐに参照できるように一連の「ルール」を作ったのは、本当に
みんなのモチベーションを高めるためです。ですから常に文字通りに解釈する必
要はありません。このような文章よりも、自分の行動に対する正当な理由を大切
にしてください。

SEPARATE CHANGES
****************

原則として、変更を小さな論理ステップに分割し、それぞれでコミットするよう
にしてください。それらは一貫性があり、その後のコミットとは独立して機能し
、テストスイートに合格する必要があります。これにより、レビュープロセスが
はるかに簡単になり、その履歴は、たとえば git-blame(1) や git-bisect(1)を
使用して後で検査や分析する時にはるかに役立ちます。

   これを実現するには、最初から作業を小さなステップに分割してみてくださ
い。1つの大きなコミットを複数に分割するよりも、いくつかのコミットをまと
める方が常に簡単です。途中で小さすぎる、または不完全なステップを作成する
ことを恐れないでください。いつでも後で戻って、公開する前に ‘git rebase
--interactive’ を使用してコミットを編集できます。 ‘git stash push
--keep-index’ を使用して、他のコミットされていない変更とは無関係にテスト
スイートを実行できます。 git-stash(1) の「EXAMPLES」セクションを参照して
ください。

MANAGING BRANCHES
*****************

あるブランチから別のブランチへの変更を含めるために使用できる2つの主要な
ツールがあります。 git-merge(1) と git-cherry-pick(1) です。

   マージには多くの利点があるため、マージだけで可能な限り多くの問題を解
決しようとしています。 cherry-pickingまだ時々役に立ちます。例については
、以下の「Merging upwards」を参照してください。

   最も重要なことは、マージはブランチレベルで機能し、チェリーピッキング
はコミットレベルで機能することです。これは、マージが1、10、または1000の
コミットからの変更を同じように簡単に引き継ぐことができることを意味します
。つまり、ワークフローは多数の貢献者(および貢献)に対してはるかに適切にス
ケーリングされます。マージコミットは、すべての親からのすべての変更が含ま
れた「約束」(promise)であるため、マージも理解しやすくなります。

   もちろん、トレードオフがあります。マージには、より慎重なブランチ管理
が必要です。以下のサブセクションでは、重要なポイントについて説明します。

Graduation
==========

特定の機能が実験的なもの(experimental)から安定したもの(stable)に変わると
、ソフトウェアの対応するブランチ間でも「段階的に」(graduates)移行します
。 ‘git.git’ は以下の「統合ブランチ」(integration branches)を使用します:

   • _maint_ は、次の「メンテナンスリリース」(maintenance release)、つま
     り最後にリリースされた安定バージョンの更新に入るコミットを追跡しま
     す

   • _master_ は、次のリリースに入る予定のコミットを追跡します。

   • _next_ は、masterの安定性をテストするトピックのテストブランチとして
     意図されています。

   少し異なる方法で使用される4番目の公式ブランチがあります:

   • _seen_ (メンテナによって表示されるパッチ)は、まだ含める準備が整って
     いないモノの統合ブランチです(以下の「Integration Branches」を参照
     )。

   4つのブランチのそれぞれは、通常、その上のブランチの直接の子孫です。

   概念的には、機能(feature)は不安定なブランチ(通常は「next」または「
seen」)に入り、十分に安定している(stable)と見なされると、次のリリースの
ために「master」に「卒業」(graduates)します。

Merging upwards
===============

上記の「downwards graduation」(下向きの卒業)は、実際に下向きにマージする
ことによって実行することはできません。なぜなら、不安定なブランチの「すべ
ての」変更が安定したブランチにマージされるためです。 したがって、以下の
ようになります:

   *Merge upwards*

   修正を必要とするサポートされている最も古いブランチに常に修正をコミッ
トします。 次に、 (定期的に)統合ブランチを互いに上向きにマージします。

   これにより、修正のフローが非常によく制御されます。たとえば、修正を適
用したことに気付いた場合。 _maint_ でも必要な _master_ は、
(git-cherry-pick(1) を使用して)下向きにチェリーピックする必要があります
。これは数回発生しますが、頻繁に実行しない限り心配する必要はありません。

Topic branches
==============

重要な機能を実装するにはいくつかのパッチが必要であり、その存続期間中に追
加のバグ修正または改善が行われる可能性があります。

   統合ブランチですべてを直接コミットすると、多くの問題が発生します。不
正なコミットは元に戻せないため、1つずつ元に戻す必要があります。これによ
り、変更のグループの一部を元に戻すのを忘れると、混乱した履歴とエラーが発
生する可能性があります。並行して作業すると、変更がごちゃまぜになり、さら
に混乱が生じます。

   「topic branches」(トピックブランチ)を使用すると、これらの問題が解決
されます。名前はかなり自明ですが、上記の「merge upwards」(上向きにマージ
)ルールに由来する警告があります:

   *Topic branches*

   すべてのトピック(機能、バグ修正など)のサイドブランチを作成します。最
終的にマージする最も古い統合ブランチでフォークします。

   そうすれば、以下のように多くのことが非常に自然に実行できます:

   • 機能/バグ修正を統合ブランチに取り込むには、それをマージするだけです
     。その間にトピックがさらに進化した場合は、再度マージしてください。
     (必ずしも最初に最も古い統合ブランチにマージする必要はないことに注意
     してください。たとえば、最初にバグ修正を next にマージし、テスト時
     間を与え、安定していることがわかったら maint にマージできます。)

   • トピックの作業を続行するためにブランチ other の新機能が必要な場合は
     、 other を topic にマージします。 (ただし、これを「習慣的に」行わ
     ないでください。以下を参照してください。)

   • 分岐したブランチが間違っていることに気づき、それを「過去にさかのぼ
     って」移動したい場合は、 git-rebase(1) を使用してください。

   注意: 最後の項目が他の2つと衝突することに注意してください。他の場所で
マージされたトピックは、リベースしないでください。 git-rebase(1) の「
RECOVERING FROM UPSTREAM REBASE」に関するセクションを参照してください。

   (通常は理由もなく)「習慣的に」統合ブランチをあなたのトピックにマージ
すること(つまり、トピックを拡張し、定期的に上流からマージし続けること)は
眉をひそめられる行為であることを指摘しておく必要があります。

   *明確に定義されたポイントでのみ下流にマージします*

   正当な理由がある場合を除いて、ダウンストリームにマージしないでくださ
い。正当な理由とは、例えば、アップストリームAPIの変更がブランチに影響す
る、ブランチがアップストリームにきれいにマージされなくなりました、等です
。

   正当な理由以外の場合、マージされたトピックには、(激しくバラバラの)突
然の複数の変更が含まれます。結果として生じる多くの小さなマージは、履歴を
大幅に混乱させます。後でファイルの履歴を調査する人は、そのマージが開発中
のトピックに影響を与えたかどうかを確認する必要があります。アップストリー
ムは、誤って「より安定した」ブランチにマージされることさえあるかも等々。

使い捨て統合
============

先程の話題についていうと、多くの小さなトピックブランチがあり、あなたはそ
れらがどのように相互作用するのかワケワカメに思うことがあるでしょう。それ
らをマージしたらちゃんと機能しないかも？ そして、このようなマージは簡単
に元に戻せないため、我々はこれらに対して「安定した」場所でのマージは避け
たいと考えています。

   もちろん、解決策は、元に戻すことができるマージを作成することです。つ
まり、使い捨てブランチ(throw-away branch)にマージします。

   *Throw-away integration branches*

   いくつかのトピックの相互作用をテストするには、それらを使い捨てのブラ
ンチにマージします。あなたは決してそのようなブランチに基づいて作業を行っ
てはいけません！

   テストの直後にこのブランチが削除されることを(非常に)明確にすると、こ
のブランチを公開して、たとえば、テスターがこのブランチを操作できるように
したり、他の開発者が進行中の作業に互換性があるかどうかを確認したりするこ
ともできます。 ‘git.git’ には、「seen」と呼ばれるそのような公式の使い捨
て統合ブランチがあります。

Branch management for a release
===============================

上記のマージアプローチを使用していると仮定すると、プロジェクトをリリース
するときに、追加のブランチ管理作業を行う必要があります。

   「master」は次の機能(feature)リリースに入るコミットを追跡するため、機
能(feature)リリースは「master」ブランチから作成されます。

   _master_ ブランチは、 _maint_ のスーパーセットであると想定されていま
す。この条件が満たされない場合、「maint」には「master」に含まれていない
コミットが含まれています。したがって、「maint」のコミットによって表され
る修正は、機能(feature)リリースには含まれません。

   _master_ が実際に _maint_ のスーパーセットであることを確認するには、
‘git log’ を使用します:

   *「master」が「maint」のスーパーセットであることを確認(verify)します
:*

   ‘git log master..maint’

   このコマンドは、コミットを一切リストしないはずです。そうでない場合は
、「master」をチェックアウトし、「maint」をマージします。

   これで、あなたは機能(feature)リリースの作成に進むことができます。リリ
ースバージョンを示すタグを「master」の先端に適用します:

   *Release tagging*

   ‘git tag -s -m "Git X.Y.Z" vX.Y.Z master’

   あなたは新しいタグをパブリックGitサーバーにプッシュする必要があります
(以下の「DISTRIBUTED WORKFLOWS」参照)。これにより、プロジェクトを追跡し
ている他のユーザーがタグを利用できるようになります。プッシュでは、更新後
のフックをトリガーして、リリースtarballの作成や事前にフォーマットされた
ドキュメントページなどのリリース関連の項目を実行することもできます。

   同様に、メンテナンスリリースの場合、「maint」はリリースされるコミット
を追跡します。ゆえに、タグのリリース手順では、「master」ではなく「
maint」にタグを付けてプッシュするだけです。

機能リリース後のメンテナンスブランチ管理
========================================

機能(feature)リリース後、あなたはメンテナンスブランチを管理する必要があ
ります。

   まず、直近のリリースより前に行われた機能リリースのメンテナンス修正を
引き続きリリースする場合は、その前のリリースのコミットを追跡するために別
のブランチを作成する必要があります。

   これを行うために、現在のメンテナンスブランチは、以前のリリースバージ
ョン番号で名前が付けられた別のブランチにコピーされます(例:
maint-X.Y.(Z-1) ここでX.Y.Zは現在のリリースとする)。

   *Copy maint*

   ‘git branch maint-X.Y.(Z-1) maint’

   ’maint’ブランチは、新しくリリースされたコードに早送り
(fast-forwarded)され、現在のリリースのメンテナンス修正を追跡できるように
なります:

   *Update maint to new release*

   • ‘git checkout maint’

   • ‘git merge --ff-only master’

   早送り(fast-forwarded)ではないためにマージが失敗した場合は、機能リリ
ースで「maint」のいくつかの修正が欠落している可能性があります。前のセク
ションで説明したようにブランチのコンテンツを検証(verify)した場合、これは
発生しません。

機能リリース後の「next」と「seen」のブランチ管理
================================================

機能のリリース後、統合ブランチ _next_ は、オプションで、 _next_ の残りの
トピックを使用して、 _master_ の先端から巻き戻されて再構築される場合があ
ります:

   *Rewind and rebuild next*

   • ‘git switch -C next master’

   • ‘git merge ai/topic_in_next1’

   • ‘git merge ai/topic_in_next2’

   • …

   これを行うことの利点は、「next」の履歴がクリーンになることです。 たと
えば、「next」にマージされた一部のトピックは、最初は有望に見えたかもしれ
ませんが、後で望ましくないか時期尚早であることがわかりました。このような
場合、トピックは「next」から元に戻され(revert)ますが、一度マージされて元
に戻されたという事実は履歴に残ります。「next」を再作成することで、そのよ
うなトピックの別の化身に再試行するためのきれいな状態を与えることができま
す。機能のリリースは、これを行うための履歴上の良い地点です。

   これを行う場合は、「next」が巻き戻されて再構築されたことを示す公開ア
ナウンスを行う必要があります。

   「seen」についても、同じの巻き戻しと再構築のプロセスを行います。なお
、上記のとおり「seen」は使い捨てのブランチであるため、公の発表は必要あり
ません。

DISTRIBUTED WORKFLOWS
*********************

前セクションを読んだ今となっては、あなたはトピックを管理する方法を知って
おくべきです。 一般的に、プロジェクトに取り組んでいるのはあなただけでは
ないので、あなたの仕事は共有しなければなりません。

   大まかに言えば、マージとパッチという2つの重要な作業フローがあります。
重要な違いは、マージ作業フローはマージを含む完全な履歴を伝播できますが、
パッチは伝播できないことです。両方の作業フローを並行して使用できます。
‘git.git’ では、サブシステムメンテナのみがマージ作業フローを使用し、他の
すべての作業フローはパッチを送信します。

   注意: メンテナは、インクルードするために提出されたすべてのコミット/パ
ッチが遵守しなければならない「Signed-off-by」要件などの制限を課すことが
できることに注意してください。より詳細な情報については、プロジェクトのド
キュメントを参照してください。

Merge workflow
==============

マージ作業フローは、上流(upstream)と下流(downstream)の間でブランチをコピ
ーすることによって機能します。上流では、貢献の結果を公式の履歴に統合する
ことができます。下流では、公式の履歴に基づいて作業します。

   これに使用できる主なツールは3つあります:

   • git-push(1) は、ブランチをリモートリポジトリにコピーします。通常は
     、関係者全員が読み取れるリポジトリにコピーします。

   • git-fetch(1) は、リモートブランチをあなたのリポジトリにコピーします
     。

   • git-pull(1) は、フェッチしてマージするのを一度に行います。

   注意: 最後の点に注意してください。 実際にリモートブランチをマージする
場合を除いて ‘git pull’ を使用しないでください。

   変更を取得するのは簡単です:

   *push/pull: branches/topics の公開*

   ‘git push <remote> <branch>’ を実行、そして、どこからフェッチできるか
をみんなに伝えます。

   あなたは今の所メールなどの他の手段で人々に伝えなければなりません。
(Gitは git-request-pull(1) を提供して、このタスクを簡素化するために、事
前にフォーマットされたプルリクエストをアップストリームのメンテナーに送信
します。 )

   統合ブランチの最新のコピーを取得したいだけの場合は、最新の状態に保つ
のも簡単です:

   *push/pull: 最新の状態に保つ*

   最新の状態に保つには ‘git fetch <remote>’ または ‘git remote update’
を使います。

   次に、以前に説明したように、安定したリモートからトピックブランチをフ
ォークするだけです。

   あなたがメンテナであり、他の人のトピックブランチを統合ブランチにマー
ジしたい場合、他の人々は通常、メールでそうするようにリクエストを送信して
きます。そのようなリクエストは以下のようになります

     Please pull from
         <url> <branch>

   その場合、 ‘git pull’ は、以下のように、フェッチとマージを一度に実行
できます。

   *Push/pull: Merging remote topics*

   ‘git pull <url> <branch>’

   場合によっては、メンテナが下流(downstream)から変更をプルしようとする
と、マージの競合が発生することがあります。 この場合、下流にマージを実行
して競合を彼ら自身で解決するように依頼できます(おそらく、彼らは競合を解
決する方法をよりよく知っているでしょう)。これは、下流が上流(upsteram)か
らマージする必要があるまれなケースの1つです。

Patch workflow
==============

あなたが変更を電子メールの形式でアップストリームに送信する貢献者の場合は
、通常どおりトピックブランチを使用する必要があります(上記参照)。 次に、
git-format-patch(1) を使用して、対応する電子メールを生成します(メンテナ
の作業が楽になるため、手動でフォーマットするよりもこれを使うのを強く推奨
します)。

   *format-patch/am: Publishing branches/topics*

   • ‘git format-patch -M upstream..topic’ を使用して、事前に形式が決ま
     っているパッチファイルに変換します

   • ‘git send-email --to=<recipient> <patches>’

   使用上の注意については、 git-format-patch(1) と git-send-email(1) の
manpageを参照してください。

   あなたのパッチがもはや現在の上流(upstream)に適用されなくなったとメン
テナが告げた場合は、トピックをリベースする必要があります(format-patch マ
ージができないため、マージを使用できません):

   *format-patch/am: Keeping topics up to date*

   ‘git pull --rebase <url> <branch>’

   あなたはその後、リベース中に競合を修正できます。おそらくあなたはメー
ル以外であなたのトピックを公開していないので、それをリベースすることは問
題ではありません。

   あなたがこのようなパッチシリーズを受け取った場合(メンテナとして、また
は送信先のメーリングリストの読者として)、メールをファイルに保存し、新し
いトピックブランチを作成し、 ‘git am’ を使用してコミットをインポートしま
す:

   *format-patch/am: Importing patches*

   ‘git am < patch’

   指摘する価値のある機能の1つは、競合が発生した場合に役立つ3方向マージ
です。 ‘git am -3’ は、パッチに含まれるインデックス情報を使用して、マー
ジベースを把握します。他のオプションについては git-am(1) を参照してくだ
さい。

SEE ALSO
********

gittutorial(7), git-push(1), git-pull(1), git-merge(1), git-rebase(1),
git-format-patch(1), git-send-email(1), git-am(1)

GIT
***

Part of the git(1) suite