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 のワークフローは以下の通りです:

1. 新しいプロジェクトを作成、またはリモートのプロジェクトを複製する。
2. ブランチを作成して変更を加え、変更をコミットする。
3. コミットを統合して上手くまとめて分かりやすくする。
4. メインのブランチにコミットをマージする。
5. (任意) 変更をリモートサーバーにプッシュする。

ローカルリポジトリ

ステージング

新しいリポジトリを作成:

$ git init

リポジトリの変更を記録するには、先にインデックスまたはステージングエリア (ステージングとも呼ばれます) に変更を追加する必要があります。ファイルを追加するには:

$ git add file1 file2

ファイルを全て追加:

$ git add .

ヒント: git add . などのコマンドでファイルを無視するようにしたい場合、.gitignore ファイルを作成してください:

.gitignore

# File I'll likely delete
test-script

# Ignore all .html files, except 'important.html'
*.html
!important.html

# Ignore all files recursively in 'DoNotInclude'
DoNotInclude/**

詳しくは gitignore(5) を参照。

ステージングからファイルを削除 (--cached を付けるとファイルを実際には削除しません):

$ git rm (--cached) file

ファイルを全て削除:

$ git rm --cached -r .

または:

$ git reset HEAD -- .

上記の HEAD は現在の版の「シンボル参照」です。

ファイルの名前を変更:

$ git mv file1 file2

ファイルのリストを表示:

$ git ls-files

上記のコマンドはデフォルトでステージングエリアのファイルを表示します (--cached ファイル)。

変更をコミット

コンテンツをステージングに記録したら、次のコマンドでコミットします:

$ git commit -m "First commit."

-m, --message オプションを使うことで短いメッセージを残せます: オプションを省略した場合、事前に設定していたエディタが起動して長いメッセージを書くことができます。

ヒント:

• 小さい変更でも頻繁にコミットを行ってちゃんとしたメッセージを書くようにしましょう。
• 編集を加えたファイルを全てインデックスに追加して、それらをコミットするのは一つのコマンドで実行できます (-a は --all の略式):

$ git commit -am "First commit."

過去に戻ってコミットメッセージを編集:

$ git commit --amend -m "Message."

この記事で使われるコマンドの多くはコミットを引数として指定します。コミットは以下の形式のどれかで指定することが可能です:

• 40文字の SHA-1 ハッシュ (大抵は最初の7文字くらいで一意に識別できます)。
• ブランチやタグの名前といったコミットのラベル。
• HEAD ラベルはチェックアウトされた最新のコミットを示します (git checkout を使って古いコミットまで歴史を戻していない限り、ブランチの頭になります)。
• 上記に加えて ~ を付けることで前のコミットを指定できます。例えば、HEAD~ は HEAD の一つ前のコミット、HEAD~5 は HEAD の五つ前のコミットを指します。

変更を閲覧

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

$ git diff HEAD HEAD~3

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

$ git diff

変更の要点を表示:

$ git status

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

$ git log (-N)

ブランチの作成

基本的に、修正や新しい機能などはブランチでテストします。変更が問題ないようだったら、デフォルトのブランチ (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)。

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

メーリングリストに直接パッチを送る場合、次のパッケージをインストールする必要があります: 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 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 は INI タイプの設定ファイルから設定を読み込みます:

• 各リポジトリにはリポジトリごとの設定を記述した .git/config ファイルが含まれます。
• 各ユーザーの $HOME/.gitconfig ファイルがフォールバックとして使われます。
• システム全体のデフォルト設定としては /etc/gitconfig が使われます。

上記のファイルは直接編集できますが、通常は下の例にあるように 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 Configuration を見て下さい。

認証の高速化

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

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

デフォルトプロトコル

上述のように 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

ノート: gpg 署名で pinentry curses を使うには export GPG_TTY=$(tty) (もしくは pinentry-tty を使用) を実行する必要があります。実行していないと gpg がロック状態の場合に署名が失敗します (pin の要求ができないためです)。

Signed-off-by 行を追加 (プロジェクトによってはコミットに名前・メール署名の追加を必要とする場合があります):

 $ git commit -s

パッチに Signed-off-by を自動で追加 (git format-patch commit を使用したとき):

$ git config --local format.signoff true

変更を加えたファイルの特定部分をコミット。大量の変更を行ったとき複数のコミットに分けたい場合に有用です:

$ git add -p

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

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

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

$ git checkout -b branch origin/branch

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

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

Git サーバー

様々なプロトコルによるリポジトリへの接続を設定する方法。

SSH

SSH プロトコルを使うには、まず SSH 公開鍵を設定します。SSH 鍵のガイドに従って設定してください。SSH サーバーを設定する方法は、SSH を見て下さい。

SSH を動作させて鍵を生成したら、~/.ssh/id_rsa.pub の中身を ~/.ssh/authorized_keys に貼り付けてください (1行に全て記述)。以下を実行することで SSH で Git リポジトリにアクセスできます:

$ git clone user@foobar.com:my_repository.git

SSH クライアントの StrictHostKeyChecking 設定が ask になっている場合 (デフォルト設定)、SSH は yes/no の確認を表示します。yes と入力してから Enter を押してください。それでリポジトリがチェックアウトされます。SSH を使用する場合、コミット権限も得られます。

SSH を使うように既存のリポジトリを設定するには、リモート URL を再定義してください:

$ git remote set-url origin git@localhost:my_repository.git

/etc/ssh/ssh_config や ~/.ssh/config の設定によって22番以外のポートに接続できます。リポジトリのポートを設定するには (例: 443):

~/.git/config

[remote "origin"]
    url = ssh://user@foobar.com:443/~my_repository/repo.git

Smart HTTP

Git は git-http-backend を利用することで SSH や Git プロトコルと同じように HTTP(S) プロトコルを効率的に扱うことができます。リポジトリから clone あるいは pull できるだけでなく、HTTP(S) を使ってリポジトリに push することが可能です。

セットアップは大して難しくありません。Apache ウェブサーバー (apache と mod_cgi, mod_alias, mod_env) と git をインストール・設定するだけです。

基本的なセットアップが出来たら、Apache の設定ファイルに以下を追加してください:

/etc/httpd/conf/httpd.conf

<Directory "/usr/lib/git-core*">
    Require all granted
</Directory>
 
SetEnv GIT_PROJECT_ROOT /srv/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

上記の設定では Git リポジトリは /srv/git としています。次のような URL でアクセスします: http(s)://your_address.tld/git/your_repo.git。

ノート: Apache からリポジトリに読み書きできることを確認してください。

詳しいドキュメントは以下のリンクを参照:

• https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html

Git

ノート: Git プロトコルでは読み取りアクセスだけが許可されます。

git-daemon.socket を起動・有効化してください。

デーモンは以下のオプションで起動します:

ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git

/srv/git/ に置かれたリポジトリがデーモンによって認識されます。次のようなコマンドでクライアントで接続できます:

$ git clone git://location/repository.git

アクセス権限の設定

読み書きアクセスを制限したいときは、標準の Unix パーミッションを使います。詳しくは http://sitaramc.github.com/gitolite/doc/overkill.html^{[リンク切れ 2013-11-06]} (archive.org mirror) を参照してください。

より細かいアクセス管理については、gitolite や gitosis を参照してください。

参照

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