「Git」の版間の差分
(→pull リクエスト: 翻訳を修正) |
(他言語へのリンクを追加) |
||
1行目: | 1行目: | ||
[[Category:バージョン管理システム]] |
[[Category:バージョン管理システム]] |
||
[[Category:コマンド]] |
[[Category:コマンド]] |
||
+ | [[de:Git]] |
||
[[en:Git]] |
[[en:Git]] |
||
+ | [[es:Git]] |
||
[[zh-hans:Git]] |
[[zh-hans:Git]] |
||
{{Related articles start}} |
{{Related articles start}} |
2023年7月7日 (金) 22:13時点における版
関連記事
Git は Linux カーネルの創設者である Linus Torvalds によって設計・開発されたバージョン管理システム (VCS) です。現在 Git は Linux カーネルのソースの管理だけでなく、様々な他のプロジェクトにも使われており、Arch Linux プロジェクトもそれに含まれます。
目次
- 1 インストール
- 2 基本設定
- 3 基本的な使い方
- 4 ヒントとテクニック
- 5 拡張機能
- 6 参照
インストール
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 するには:
$ 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
コマンドで中止してください。
ヒントとテクニック
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 や KeePass のような 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
パラメータでカスタムプロンプトを設定してください:
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
あるいは、.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 を参照してください。
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 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
他のブランチを取得する
上記の例では、ローカル リポジトリはメインラインカーネル、つまり 最新の開発が行われた カーネルのみを追跡します。たとえば、最新の 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 のリポジトリにアクセスできるようにするものです。(この Microsoft ブログ や Wikipedia article を参照してください。)
これは、gvfs と scalar を含む git の Microsoft のフォークである git-vfsAUR で利用可能です。
機密情報のフィルタリング
時には、ソフトウェアが平文のパスワードを設定ファイルに保存し、キーリングに接続するのとは対照的にすることがあります。このような場合、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/'"
HTML ヘルプファイル
git-htmldocsAUR をインストールすることで、git help
のドキュメントを HTML 形式で利用することもできます。インストール後、HTML ドキュメントには -w
フラグを付けてアクセスすることができます。例えば
$ git help -w merge
git config
オプションを設定すると、デフォルトで HTML ドキュメントを読み込むことができます。
$ git config --global help.format html
拡張機能
- gitflow-avh — Vincent Driessen の分岐モデル で git を拡張します。AVH Edition はより多くの機能を追加します。
- git-extras — git 用のいくつかのユーティリティ (リポジトリの概要、repl、変更ログの人数、作成者のコミット率など)
- https://github.com/tj/git-extras || git-extrasAUR - oh-my-zsh を使用している場合、git-extras プラグイン を有効にして下さい。
- gitmoji-cli — A gitmoji コミットメッセージで gitmojis を使用するためのインタラクティブな NodeJS クライアント。