Git

関連記事

• Bisecting bugs with Git
• Concurrent Versions System
• Git サーバー
• Gitweb
• Cgit
• HTTP トンネリング#Git のトンネリング
• Subversion
• Concurrent Versions System

Git は Linux カーネルの創設者である Linus Torvalds によって設計・開発されたバージョン管理システム (VCS) です。現在 Git は Linux カーネルのソースの管理だけでなく、様々な他のプロジェクトにも使われており、Arch Linux プロジェクトもそれに含まれます。

インストール

git パッケージを インストール して下さい。開発版の場合は、git-git^AUR パッケージをインストールします。git svn、git gui、gitk などのツールを使用する場合は、オプションの依存関係を確認してください。

グラフィカルフロントエンド

参照 git GUI クライアント

• Giggle — Git の GTK フロントエンド

https://wiki.gnome.org/Apps/giggle/ || giggle

• GitAhead — 組み込みの Merge Tool を含むグラフィカル Git クライアント

https://gitahead.github.io/gitahead.com/ || gitahead^AUR

• Git Cola — Python で書かれた Git 用の洗練された強力なグラフィカル ユーザーインターフェイス

https://git-cola.github.io/ || git-cola^AUR

• Git Extensions — コマンドラインを使用せずに Git を制御できる Git のグラフィカルユーザーインターフェイス

https://gitextensions.github.io/ || gitextensions^AUR

• gitg — Git リポジトリを表示するための GNOME GUI クライアント

https://wiki.gnome.org/Apps/Gitg || gitg

• git-gui — Git への Tcl/Tk ベースの移植可能なグラフィカルインターフェイス

https://git-scm.com/docs/git-gui || git + tk

ノート: git-gui でスペル チェックを有効にするには、LC_MESSAGES 環境変数 に対応する辞書と共に aspell が必要です。FS#28181 そして aspell の記事を参照。

• GitHub Desktop — GitHub チームによって構築された Electron ベースのグラフィカルユーザーインターフェイス

https://github.com/desktop/desktop || github-desktop^AUR github-desktop-bin^AUR

• gitk — Tcl/Tk ベースの Git リポジトリブラウザ

https://git-scm.com/docs/gitk || git + tk

• Guitar — Git GUI クライアント

https://github.com/soramimi/Guitar || guitar^AUR

• lazygit — git コマンド用のシンプルなターミナル UI

https://github.com/jesseduffield/lazygit || lazygit

• QGit — リビジョン履歴を参照し、パッチの内容と変更されたファイルを表示し、さまざまな開発ブランチをグラフィカルにたどる Git GUI ビューア

https://github.com/tibirna/qgit || qgit

• RabbitVCS — 使用しているバージョン管理システムへのシンプルで直接的なアクセスを提供するために作成されたグラフィカルツールのセット

http://rabbitvcs.org/ || rabbitvcs^AUR

• Sublime Merge — Sublime Text のメーカーによる Git クライアント

https://www.sublimemerge.com/ || sublime-merge^AUR

• Tig — git 用の ncurses ベースのテキストモードインターフェイス

https://jonas.github.io/tig/ || tig

• ungit — git の汎用性を犠牲にすることなく、git に使いやすさをもたらします

https://github.com/FredrikNoren/ungit || nodejs-ungit^AUR

基本設定

Git を使うには少なくとも名前とメールアドレスを設定する必要があります:

$ git config --global user.name  "John Doe"
$ git config --global user.email "johndoe@foobar.com"

こちらも参照 Getting Started - First-Time Git Setup

他の設定については #高度な設定 を見て下さい。

基本的な使い方

Git リポジトリは .git ディレクトリに格納され、リビジョン履歴やその他のメタデータを保持します。リポジトリが追跡するディレクトリ (デフォルトでは親ディレクトリ) は、作業ディレクトリと呼ばれます。作業ツリーの変更は、リポジトリに記録 (コミット) される前にステージングされる必要があります。Git では、以前にコミットした作業ツリーのファイルを復元することもできます。

Getting Started - Git Basics を参照してください。

Git リポジトリの取得

• リポジトリの初期化

git init, 参照 git-init(1)

• 既存のリポジトリのクローンを作成

git clone repository, 参照 git-clone(1) (Git URL についても説明します)

変更の記録

Git プロジェクトにはステージング領域があります。これは、Git ディレクトリにある index ファイルで、次のコミットに反映される変更点を保存しておくものです。したがって、変更したファイルを記録するには、まずそれをインデックスに追加する (ステージングする) 必要があります。そして、git commit コマンドは現在のインデックスを新しいコミットに格納します。

ステージングの変更

• 作業ツリーの変更をインデックスに追加

git add pathspec, 参照 git-add(1)

• * インデックスから変更を削除

git reset pathspec, 参照 git-reset(1)

• コミットする変更、ステージングされていない変更、追跡されていないファイルを表示する

git status, 参照 git-status(1)

Git に特定の未追跡ファイルを無視させるには、.gitignore ファイルを使用します。

Git はファイルの動きを追跡しません。マージ中の移動の検出は、内容の類似性のみに基づいて行われます。git mv コマンドは便宜上存在するだけで、これと同等です。

$ mv -i foo bar
$ git reset -- foo
$ git add bar

変更をコミット

git commit コマンドは段階的な変更をリポジトリに記録します。git-commit(1) を参照してください。

• -m - デフォルトのテキストエディタでコミットメッセージを作成する代わりに、引数としてコミットメッセージを指定します。
• -a - 変更または削除されたファイルを自動的にステージングします (追跡されていないファイルは追加されません)
• --amend - 直近のコミットをやり直し、コミットメッセージやコミットされたファイルを修正します。

ヒント: 常に小さな変化を頻繁に、そして意味のあるメッセージを添えてコミットしてください。

リビジョンを選択

Git には、リビジョンを指定する方法が複数あります。gitrevisions(7) と Revision Selection を参照してください。

多くの Git コマンドは、リビジョンを引数として受け取ります。コミットは、以下のいずれかによって識別されます。

• コミットの SHA-1 ハッシュ (通常、最初の7桁でコミットを一意に識別できます。)
• ブランチ名やタグ名などの任意のコミット ラベル
• ラベル HEAD は常に現在チェックアウトされているコミット (通常はブランチの先頭、ただし git checkout を使って古いコミットに履歴を戻した場合は除く) を指します。
• 上記のいずれかと、前のコミットを参照するための ~ を加えたものです。例えば、HEAD~ は HEAD の一つ前のコミットを指し、HEAD~5 は HEAD の五つ前のコミットを指し示します。

変更を閲覧

コミット間の差分を表示:

$ git diff HEAD HEAD~3

ステージングエリアと作業ツリーの差分を表示:

$ git diff

変更の要点を表示:

$ git status

変更の履歴を表示 ("-N" は表示する直近のコミット数):

$ git log (-N)

元に戻す

• git checkout - を使って作業ツリーファイルを復元することができますgit-checkout(1)
• git reset - 現在の HEAD を指定された状態にリセット、git-reset(1) を参照
• git revert - 既存のコミットを revert するには git-revert(1) を参照してください。

これらについては、undoing-changes でさらに詳しく説明しています。

より複雑な履歴の変更、たとえば git commit --amend や git rebase については、たとえば rewriting-history をご覧ください。このような書き換えは、他のユーザーと共同で行ったコミットには使用しないことを強く推奨します。少なくとも、事前に十分な調整をする必要があります。

ブランチの作成

基本的に、修正や新しい機能などはブランチでテストします。変更が問題ないようだったら、デフォルトのブランチ (master) にマージします。ブランチを作成するときは、目的に適った名前を付けて下さい:

$ git branch help-section-addition

ブランチを一覧:

$ git branch

ブランチを切り替え:

$ git checkout branch

ブランチを作成して切り替え:

$ git checkout -b branch

ブランチを master ブランチにマージ:

$ git checkout master
$ git merge branch

変更が衝突しない場合はマージされます。衝突する場合は衝突箇所が記録されます。git diff を使ってどこで衝突しているのか確認することができるので、手動で衝突の解消をする必要があります。

ブランチが不要になったら、次のコマンドで削除します:

$ git branch -d branch

共同作業

エチケット

• 既存のプロジェクトに貢献しようと考えた場合、プロジェクトのライセンスを確認しましょう。コードの変更についてかなり制限がかけられている場合もあります。ライセンスによっては、コードの所有権について論争が生まれることも考えられます。
• プロジェクトのコミュニティを観測してどうやったら適合できるか考えましょう。プロジェクトの方向性を理解するために、ドキュメントやリポジトリのログを読むのも大切です。
• コミットを pull するようにリクエストしたり、パッチを送るときは、できるかぎりパッチを短くして説明を付加するようにしましょう。メンテナがあなたの変更箇所を理解するための手助けとなり、マージするか、もしくは修正を加えるよう要求すべきか判断する基準にもなります。
• リジェクトされたとしても、落胆する必要はありません。所詮他人のプロジェクトです。リクエストが重要な場合、出来るかぎり分かりやすく根気よくリクエストの理由を説明しましょう。いつかは解決に導かれるはずです。

リポジトリを複製

プロジェクトへの貢献を始めるには、まずリポジトリを clone します:

$ git clone location folder

location はパスでもネットワークアドレスでもかまいません。また、複製が完了すると場所が記録されるので、git pull だけで複製できるようになります。

プルリクエスト

変更を加えてコミットしたら、ソフトウェアの作者にマージするように要求することができます。これを「プルリクエスト」と呼びます。pull するには:

$ git pull location master

pull コマンドは fetch と merge の組み合わせです。衝突があった場合 (例えば同じ時間帯にソフトウェアの作者が変更を加えた場合)、手動で解消する必要があります。

もしくは、オリジナルの作者は取り込みたい変更を pick することができます。fetch オプションを使って (そして log オプションで特殊な FETCH_HEAD 記号を使用)、プルリクエストの中身を表示してから何をするか決められます:

$ git fetch location master
$ git log -p HEAD..FETCH_HEAD
$ git merge location master

リモートの使用

リモートは追跡しているリポジトリです。label で場所を定義します。大抵は頻繁にアクセスするリポジトリで使われます。リモートを作成:

$ git remote add label location

リモートを取得:

$ git fetch label

マスターとリモートのマスターの変更点を表示:

$ git log -p master..label/master

現在のリポジトリのリモートを表示:

$ git remote -v

フォーク元 (先行プロジェクト) のリモートを定義するときは upstream として定義します。

リポジトリにプッシュ

ソフトウェアの作者から権限を与えられたら、変更を push することができます:

$ git push location branch

git clone が実行されると、オリジナルの URL が記録され origin というリモート名が与えられます。大抵の場合は以下のようにしてプッシュできます:

$ git push origin master

-u (--set-upstream-to) オプションを使用すると、位置が記録されて次回からは git push だけでも実行できます。

マージの対処

マージの衝突を解決する方法は Git Book の マージ時のコンフリクト を見てください。マージは基本的に可逆です。--abort コマンドを使うことでマージを取り消すことができます (例: git merge --abort または git pull --abort)

履歴とバージョニング

履歴の検索

git log では履歴とコミットのチェックサムや作者、日付、ショートメッセージを表示します。チェックサムはコミットオブジェクトのオブジェクト名であり、通常は40文字の SHA-1 ハッシュになります。履歴とロングメッセージを表示するには ("checksum" は一意であるかぎり短く省略できます):

$ git show (checksum)

追跡されているファイルをパターン検索:

$ git grep pattern

.c と .h ファイルを検索:

$ git grep pattern -- '*.[ch]'

タグ付け

コミットにタグを付ける:

$ git tag 2.14 checksum

タグは一般的に リリースやバージョニング するときに付けられますが文字列は何でもかまいません。通常は Git データベースに追加される注釈付きタグが用いられます。最新のコミットにタグを付けるには:

$ git tag -a 2.14 -m "Version 2.14"

タグを確認:

$ git tag -l

タグを削除:

$ git tag -d 2.08

タグを更新:

$ git push --tags

コミットの修正

プルリクエストを送信する前に、コミットを整理・統合するのが望ましいことがあります。git rebase のインタラクティブオプションを使います:

$ git rebase -i checksum

コマンドを実行すると指定された範囲のコミットが全てエディタで開かれます。上記の場合、最新のコミット (HEAD) から checksum コミットまでが開かれます。数字で指定する場合、例えば HEAD~3 なら最後の3つのコミットがリベースされます:

pick d146cc7 Mountpoint test.
pick 4f47712 Explain -o option in readme.
pick 8a4d479 Rename documentation.

最初のカラムに rebase で実行する動作を記述します。以下から選んでください:

• pick — コミットをそのまま適用します。(デフォルト)
• edit — ファイルやコミットメッセージを編集。
• reword — コミットメッセージを編集。
• squash — 前のコミットにマージ。
• fixup — 前のコミットにマージ。メッセージは破棄。

コミットの順番を変えたり履歴から消去することが可能です (ただし注意して操作してください)。ファイルの編集後、Git は指示された作業を実施します。マージ時の問題を解決するように要求された場合、修正してから git rebase --continue で続行するか、git rebase --abort コマンドで中止してください。

ノート: コミットの squash はローカルコミットでのみ使います。他人と共有しているリポジトリで使うと問題が発生します。

ヒントとテクニック

git-config の使用

Git は、4つの INI タイプの設定ファイルからその構成を読み取ります。

• /etc/gitconfig システム全体のデフォルト
• ~/.gitconfig と ~/.config/git/config (since 1.7.12) ユーザー固有の設定用
• .git/config リポジトリ固有の設定用

これらのファイルは直接編集できますが、通常の方法は、以下の例に示すように git config を使用することです。

現在設定されている変数を一覧表示します。

$ git config {--local,--global,--system} --list

デフォルトのエディターを vim から nano に設定します。

$ git config --global core.editor "nano -w"

デフォルトのプッシュアクションを設定します。

$ git config --global push.default simple

git difftool に別のツールを設定します (デフォルトでは meld):

$ git config --global diff.tool vimdiff

詳細については、git-config(1) および Git 構成 を参照してください。

良いエチケットを採用する

• 既存のプロジェクトに貢献することを検討する場合、コードを変更する能力を過度に制限する可能性があるため、そのライセンスを読んで理解してください。ライセンスによっては、コードの所有権をめぐって紛争を引き起こす可能性があります。
• プロジェクトのコミュニティと、自分がそこにどれだけ溶け込めるかを考えましょう。プロジェクトの方向性を知るために、あらゆるドキュメントや、リポジトリの log を読んでください。
• コミットをプルしたり、パッチを提出したりするときは、小規模で十分な文書化を心がけましょう。そうすることで、メンテナがあなたの変更を理解し、マージするか修正を依頼するかを判断しやすくなります。
• もし、投稿が拒否されても、落ち込まないでください。重要なことであれば、その理由をできるだけ明確に、忍耐強く議論してください。

認証の高速化

Git サーバーにプッシュする度に認証が面倒なのをなんとかしたいと思っている場合、以下を使って下さい。

• SSH 鍵を使って認証している場合、SSH エージェントを使って下さい。SSH#SSH の高速化 や SSH#Keep alive も参照。
• ユーザー名とパスワードを使って認証している場合、サーバーが SSH をサポートしているなら SSH 鍵に切り替えてください。もしくは git-credential-cache や git-credential-store を使ってみて下さい。

git-credential-libsecret をクレデンシャルヘルパーとして使用する

Git は GNOME/Keyring や KeePassXC のような org.freedesktop.secrets と互換性のあるキーリングから認証情報を取得することがあります。そのため、互換性のあるキーリングを一つセットアップし、キーリングが dbus に登録されているかどうかを確認します。

dbus-send --session --print-reply --dest=org.freedesktop.DBus / \
    org.freedesktop.DBus.GetConnectionUnixProcessID \
    string:org.freedesktop.secrets

実行

git config --global credential.helper /usr/lib/git-core/git-credential-libsecret

その後 git をセットアップします。

デフォルトプロトコル

上述のように SSH で多重接続することで、Git over SSH の方が HTTPS よりも高速になります。また、(AUR など) サーバーによっては SSH を介して push することもできます。例えば、以下の設定をすると AUR でホストされているリポジトリで Git over SSH を設定します。

~/.gitconfig

[url "ssh://aur@aur.archlinux.org/"]
	insteadOf = https://aur.archlinux.org/
	insteadOf = http://aur.archlinux.org/
	insteadOf = git://aur.archlinux.org/

Bash 補完

Bash の補完を有効にするには、Bash のスタートアップファイルで /usr/share/git/completion/git-completion.bash を source してください。もしくは、bash-completion をインストールしてください。

Git プロンプト

Git パッケージにはプロンプトスクリプトが付属しています。プロンプトを有効にするには、シェルのスタートアップファイルで /usr/share/git/completion/git-prompt.sh スクリプトを source して、%s パラメータでカスタムプロンプトを設定してください:

• Bash の場合: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
• zsh の場合: PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '

Git リポジトリのディレクトリに移動すると、プロンプトはブランチの名前を表示するようになります。他の情報もプロンプトに表示させるよう設定できます:

シェル変数	情報
GIT_PS1_SHOWDIRTYSTATE	ステージ済みの場合は +、未ステージの場合は *。
GIT_PS1_SHOWSTASHSTATE	スタッシュが存在する場合は $。
GIT_PS1_SHOWUNTRACKEDFILES	追跡されていないファイルが存在する場合は %。
GIT_PS1_SHOWUPSTREAM	上流からの進み・戻り・分岐 (<,>,<>)。

変更を適用するには GIT_PS1_SHOWUPSTREAM を auto に設定する必要があります。

ノート: $(__git_ps1) が ((unknown)) と返す場合、何もリポジトリが含まれていない .git フォルダがカレントディレクトリに存在します。そのために Git が認識しなくなっています。~/.gitconfig ではなく間違って ~/.git/config に Git の設定ファイルを作成した場合などに発生します。

もしくは、bash-git-prompt^AUR や gittify^AUR など AUR にある git シェルプロンプトのカスタマイズパッケージを利用することもできます。

ビジュアル表現

作業量を把握するため:

$ git diff --stat

git log をフォーク表現:

$ git log --graph --oneline --decorate

git log グラフのエイリアス (つまり git graph は装飾されたバージョンを表示する):

$ git config --global alias.graph 'log --graph --oneline --decorate'

コミットのヒント

前のコミットにリセット (非常に危険、指定したコミットまですべて消去されます):

$ git reset --hard HEAD^

リポジトリのアドレスが変更された場合、そのリモートロケーションを更新する必要があります:

$ git remote set-url origin git@address:user/repo.git

あるいは、.git/config を編集して新しい場所を指定します。

Signed-off-by line append (プロジェクトによっては必要な、名前と電子メールの署名がコミットに追加されます):

$ git commit -s

Signed-off-by は自動的にパッチに追加されます (git format-patch commit を使用する場合):

$ git config --local format.signoff true

変更されたファイルの特定の部分をコミットします。これは、多数の変更があり、複数のコミットに分けたほうがよい場合に有用です。

$ git add -p

コミットへの署名

Git では、コミットやタグに GnuPG を使って署名することができます。Signing Your Work を参照してください。

ノート: GPG 署名に pinentry curses を使用するには、 export GPG_TTY=$(tty) (あるいは pinentry-tty を使用) してください。そうしないと GPG が現在ロック状態にある場合に署名が失敗します (pin を要求できないため)。

Git が自動的にコミットに署名するように設定するには:

$ git config --global commit.gpgSign true

マスター以外のブランチで作業

ときに、メンテナからブランチで作業するように要求されることがあります。使われるブランチの名前は devel や testing などが一般的です。まずはリポジトリを複製します。

master 以外のブランチを開くには (git clone で master ブランチしか表示されない場合、git branch -a で他のブランチを表示できます):

$ git checkout -b branch origin/branch

通常通り編集を行ってください。ただし以下のコマンドを使ってリポジトリツリーを同期させてください:

$ git pull --all
$ git push --all

メーリングリストにパッチを送信

メーリングリストに直接パッチを送る場合、次のパッケージをインストールする必要があります: perl-authen-sasl, perl-net-smtp-ssl, perl-mime-tools。

ユーザー名とメールアドレスを設定したか確認してください、#基本設定を参照。

メールアドレスを設定:

$ git config --global sendemail.smtpserver smtp.gmail.com
$ git config --global sendemail.smtpserverport 587
$ git config --global sendemail.smtpencryption tls
$ git config --global sendemail.smtpuser foobar@gmail.com

これでメーリングリストにパッチを送信することができます (OpenEmbedded:How to submit a patch to OpenEmbedded#Sending patches を参照):

$ git add filename
$ git commit -s
$ git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

大規模な git リポジトリの操作

大規模なリモートリポジトリを操作する場合、大量のデータをフェッチする必要があります。次の例では、Linux カーネルを使用して、そのようなコードベースを操作する方法を示しています。

リポジトリ全体を取得する

最も簡単な解決策は、リポジトリ全体を取得することです。

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

ノート: git clone を中断すると再開できません

git pull でリポジトリを更新できます。

リポジトリの部分的な取得

ローカルリポジトリをオリジンのより小さなサブセットに制限するには、たとえば v4.14 以降でバグを二分するために、浅いクローンを使用します。

$ git clone --shallow-exclude v4.13 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

v4.14 以降は入手できますが、v4.13 以前は入手できません。

すべての履歴を無視して、最新のスナップショットのみが必要な場合。(tarball が利用可能で、それで十分な場合は、それを選択してください。git リポジトリからダウンロードするには、より多くの帯域幅が必要です。) 次の方法で取得できます。

$ git clone --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

次の2つの例に示すように、後で古いコミットを取得できます。

$ git fetch --tags --shallow-exclude v4.1
$ git fetch --tags --shallow-since 2016-01-01

ノート: --tags がないと、タグは取得されません。

他のブランチを取得する

上記の例では、ローカル リポジトリはメインラインカーネル、つまり 最新の開発が行われた カーネルのみを追跡します。たとえば、最新の 4.14 ブランチなど、最新の LTS が必要な場合、次の方法で取得できます。

$ git remote set-branches --add origin linux-4.17.y
$ git fetch
$ git branch --track linux-4.17.y origin/linux-4.17.y

最後の行は必須ではありませんが、おそらく必要でしょう。 (必要なブランチの名前を知るために、一般的なルールはありません。gitweb のインターフェイスにある "ref" リンクを見れば、推測することができます。)

linux-4.17.y のスナップショットについては、次のようにします。

$ git checkout -b linux-4.17.y

または、別のディレクトリに展開するには、

$ mkdir /path/to/src-4.17; cd /path/to /src-4.17
$ git clone --no-local --depth 1 -b linux-4.17.y  ../linux-stable

いつものように、git pull を実行してスナップショットを更新します。

代替案

Virtual File System for Git (VFS for Git) は、ローカルのリポジトリがなくても git のリポジトリにアクセスできるようにするものです。(https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/ この Microsoft ブログ] や Wikipedia article を参照してください。)

これは、gvfs と scalar を含む git の Microsoft のフォークである git-vfs^AUR で利用可能です。

機密情報のフィルタリング

時には、ソフトウェアが平文のパスワードを設定ファイルに保存し、キーリングに接続するのとは対照的にすることがあります。このような場合、git clean-filters は機密情報を誤ってコミットしてしまうのを防ぐために便利です。たとえば、次のファイルでは "some-dotfile" というファイルにフィルタを割り当てています。

.gitattributes

some-dotfile filter=remove-pass

"some-dotfile" というファイルが git にチェックインされると、git はチェックイン前にこのファイルに対して "remove-pass" というフィルタを実行します。このフィルターは、git-configuration ファイルで定義しておく必要があります。

.git/config

[filter "remove-pass"]
clean = "sed -e 's/^password=.*/#password=TODO/'"

ノート: sed 式の特殊文字をエスケープすることは、この文脈では トリッキーな作業 になります。git は2つのバックスラッシュを1つに変え、一方 git がコマンドを実行するために呼び出すシェルは、2つのバックスラッシュを再び1つに変えることを思い出してください。詳しくは、Git filter and sed fight over `$` をご覧ください。

HTML ヘルプファイル

git-htmldocs^AUR をインストールすることで、git help のドキュメントを HTML 形式で利用することもできます。インストール後、HTML ドキュメントには -w フラグを付けてアクセスすることができます。例えば

$ git help -w merge

git config オプションを設定すると、デフォルトで HTML ドキュメントを読み込むことができます。

$ git config --global help.format html

参照

• Pro Git book
• Git Reference
• https://www.kernel.org/pub/software/scm/git/docs/
• Git overall
• Git overall2
• https://wiki.videolan.org/Git
• GitHub が用意しているプロトコルの比較