Git

提供: ArchWiki
2023年2月20日 (月) 16:10時点におけるKgx (トーク | 投稿記録)による版 (→‎変更の記録: 情報を更新)
ナビゲーションに移動 検索に移動

関連記事

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

インストール

git パッケージを インストール して下さい。開発版の場合は、git-gitAUR パッケージをインストールします。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/ || gitaheadAUR
  • Git Cola — Python で書かれた Git 用の洗練された強力なグラフィカル ユーザーインターフェイス
https://git-cola.github.io/ || git-colaAUR
  • Git Extensions — コマンドラインを使用せずに Git を制御できる Git のグラフィカルユーザーインターフェイス
https://gitextensions.github.io/ || gitextensionsAUR
  • 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-desktopAUR github-desktop-binAUR
  • gitk — Tcl/Tk ベースの Git リポジトリブラウザ
https://git-scm.com/docs/gitk || git + tk
  • Guitar — Git GUI クライアント
https://github.com/soramimi/Guitar || guitarAUR
  • lazygit — git コマンド用のシンプルなターミナル UI
https://github.com/jesseduffield/lazygit || lazygit
  • QGit — リビジョン履歴を参照し、パッチの内容と変更されたファイルを表示し、さまざまな開発ブランチをグラフィカルにたどる Git GUI ビューア
https://github.com/tibirna/qgit || qgit
  • RabbitVCS — 使用しているバージョン管理システムへのシンプルで直接的なアクセスを提供するために作成されたグラフィカルツールのセット
http://rabbitvcs.org/ || rabbitvcsAUR
  • Sublime Merge — Sublime Text のメーカーによる Git クライアント
https://www.sublimemerge.com/ || sublime-mergeAUR
  • Tig — git 用の ncurses ベースのテキストモードインターフェイス
https://jonas.github.io/tig/ || tig
  • ungit — git の汎用性を犠牲にすることなく、git に使いやすさをもたらします
https://github.com/FredrikNoren/ungit || nodejs-ungitAUR

基本設定

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 -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 には、リビジョンを指定する方法が複数あります。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 コマンドで中止してください。

ノート: コミットの 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 で多重接続することで、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-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
ノート: 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 からリポジトリに読み書きできることを確認してください。

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

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 を参照してください。

参照

「https://wiki.archlinux.jp/index.php?title=Git&oldid=30114」から取得