Git
関連記事
Git は Linux カーネルの創設者である Linus Torvalds によって設計・開発されたバージョン管理システム (VCS) です。現在 Git は Linux カーネルのソースの管理だけでなく、様々な他のプロジェクトにも使われており、Arch Linux プロジェクトもそれに含まれます。
インストール
git パッケージを インストール して下さい。開発版の場合は、git-gitAUR パッケージをインストールします。git svn、git gui、gitk などのツールを使用する場合は、オプションの依存関係を確認してください。
グラフィカルフロントエンド
- Giggle — Git の GTK フロントエンド
- GitAhead — 組み込みの Merge Tool を含むグラフィカル Git クライアント
- Git Cola — Python で書かれた Git 用の洗練された強力なグラフィカル ユーザーインターフェイス
- Git Extensions — コマンドラインを使用せずに Git を制御できる Git のグラフィカルユーザーインターフェイス
- gitg — Git リポジトリを表示するための GNOME GUI クライアント
- git-gui — Git への Tcl/Tk ベースの移植可能なグラフィカルインターフェイス
- GitHub Desktop — GitHub チームによって構築された Electron ベースのグラフィカルユーザーインターフェイス
- gitk — Tcl/Tk ベースの Git リポジトリブラウザ
- Guitar — Git GUI クライアント
- lazygit — git コマンド用のシンプルなターミナル UI
- QGit — リビジョン履歴を参照し、パッチの内容と変更されたファイルを表示し、さまざまな開発ブランチをグラフィカルにたどる Git GUI ビューア
- RabbitVCS — 使用しているバージョン管理システムへのシンプルで直接的なアクセスを提供するために作成されたグラフィカルツールのセット
- Sublime Merge — Sublime Text のメーカーによる Git クライアント
- Tig — git 用の ncurses ベースのテキストモードインターフェイス
- ungit — git の汎用性を犠牲にすることなく、git に使いやすさをもたらします
基本設定
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
)。
メーリングリストにパッチを送信
メーリングリストに直接パッチを送る場合、次のパッケージをインストールする必要があります: 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
コマンドで中止してください。
高度な設定
Git は INI タイプの設定ファイルから設定を読み込みます:
- 各リポジトリにはリポジトリごとの設定を記述した
.git/config
ファイルが含まれます。 - 各ユーザーの
$HOME/.gitconfig
ファイルがフォールバックとして使われます。 - システム全体のデフォルト設定としては
/etc/gitconfig
が使われます。
上記のファイルは直接編集できますが、通常は下の例にあるように git config
を使います。
現在設定されている変数を確認:
$ git config {--local,--global,--system} --list
$ 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
パラメータでカスタムプロンプトを設定してください:
Git リポジトリのディレクトリに移動すると、プロンプトはブランチの名前を表示するようになります。他の情報もプロンプトに表示させるよう設定できます:
シェル変数 | 情報 |
---|---|
GIT_PS1_SHOWDIRTYSTATE | ステージ済みの場合は +、未ステージの場合は *。 |
GIT_PS1_SHOWSTASHSTATE | スタッシュが存在する場合は $。 |
GIT_PS1_SHOWUNTRACKEDFILES | 追跡されていないファイルが存在する場合は %。 |
GIT_PS1_SHOWUPSTREAM | 上流からの進み・戻り・分岐 (<,>,<>)。 |
変更を適用するには GIT_PS1_SHOWUPSTREAM
を auto
に設定する必要があります。
もしくは、bash-git-promptAUR や gittifyAUR など 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
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
。
詳しいドキュメントは以下のリンクを参照:
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 を参照してください。