「Git」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(関連記事を追加(英語版に追従))
(add Category.)
 
(他の1人の利用者による、間の23版が非表示)
1行目: 1行目:
 
[[Category:バージョン管理システム]]
 
[[Category:バージョン管理システム]]
 
[[Category:コマンド]]
 
[[Category:コマンド]]
  +
[[Category:OpenPGP]]
  +
[[de:Git]]
 
[[en:Git]]
 
[[en:Git]]
  +
[[es:Git]]
 
[[zh-hans:Git]]
 
[[zh-hans:Git]]
 
{{Related articles start}}
 
{{Related articles start}}
8行目: 11行目:
 
{{Related|Git サーバー}}
 
{{Related|Git サーバー}}
 
{{Related|Gitweb}}
 
{{Related|Gitweb}}
{{Related|Cgit}}
 
 
{{Related|HTTP トンネリング#Git のトンネリング}}
 
{{Related|HTTP トンネリング#Git のトンネリング}}
 
{{Related|Subversion}}
 
{{Related|Subversion}}
{{Related|Concurrent Versions System}}
+
{{Related|VCS パッケージガイドライン}}
 
{{Related articles end}}
 
{{Related articles end}}
   
18行目: 20行目:
 
== インストール ==
 
== インストール ==
   
{{Pkg|git}} パッケージを[[インストール]]してください。開発版を使いたいとき {{AUR|git-git}} パッケージをインストールしてください。
+
{{Pkg|git}} パッケージを [[インストール]] してさい。開発版の場合{{AUR|git-git}} パッケージをインストールします。''git svn''、''git gui''、''gitk'' などのツールを使用する場合は、オプションの依存関係を確認してください。
   
  +
=== グラフィカルフロントエンド ===
Git の補助ツールを使いたい場合は、必要に応じて任意の依存パッケージもインストールしてください。GUI ツール (例: ''gitk'' や ''git gui'') は {{Pkg|tk}} パッケージを必要とし、インストールしていない場合エラーで起動できません:
 
   
  +
参照 [https://git-scm.com/download/gui/linux git GUI クライアント]
/usr/bin/gitk: line 3: exec: wish: not found.
 
   
  +
* {{App|Giggle|Git の GTK フロントエンド|https://wiki.gnome.org/Apps/giggle/|{{Pkg|giggle}}}}
また、GUI ツールは {{pkg|gsfonts}} を必要とし、インストールしていない場合セグメンテーション違反でクラッシュします。
 
  +
* {{App|GitAhead|組み込みの Merge Tool を含むグラフィカル Git クライアント|https://gitahead.github.io/gitahead.com/|{{AUR|gitahead}}}}
 
  +
* {{App|Git Cola|Python で書かれた Git 用の洗練された強力なグラフィカル ユーザーインターフェイス|https://git-cola.github.io/|{{AUR|git-cola}}}}
Git SVN ブリッジ (''git svn'') を使いたい場合は {{pkg|perl-term-readkey}} も必要です。インストールしていない場合、次のエラーが表示されます:
 
  +
* {{App|Git Extensions|コマンドラインを使用せずに Git を制御できる Git のグラフィカルユーザーインターフェイス|https://gitextensions.github.io/|{{AUR|gitextensions}}}}
 
  +
* {{App|gitg|Git リポジトリを表示するための GNOME GUI クライアント|https://wiki.gnome.org/Apps/Gitg|{{Pkg|gitg}}}}
Can't locate Term/ReadKey.pm in @INC (you may need to install the Term::ReadKey module)
 
  +
* {{App|git-gui|Git への Tcl/Tk ベースの移植可能なグラフィカルインターフェイス|https://git-scm.com/docs/git-gui|{{Pkg|git}} + {{Pkg|tk}}}}
 
{{Note|''git-gui'' でスペルチェックを有効にするには {{Pkg|aspell}} と {{ic|LC_MESSAGES}} [[環境変数]]に対応する辞書が必要です。詳しくは {{Bug|28181}} [[aspell]] の記事を読んでください。}}
+
:{{Note|''git-gui'' でスペル チェックを有効にするには{{ic|LC_MESSAGES}} [[環境変数]] に対応する辞書と共に aspell が必要です。{{Bug|28181}} そして [https://wiki.archlinux.org/title/Language_checking#Spell_checkers aspell] の記事を参照。}}
  +
* {{App|GitHub Desktop|GitHub チームによって構築された Electron ベースのグラフィカルユーザーインターフェイス|https://github.com/desktop/desktop|{{AUR|github-desktop}} {{AUR|github-desktop-bin}}}}
  +
* {{App|gitk|Tcl/Tk ベースの Git リポジトリブラウザ|https://git-scm.com/docs/gitk|{{Pkg|git}} + {{Pkg|tk}}}}
  +
* {{App|Guitar|Git GUI クライアント|https://github.com/soramimi/Guitar|{{AUR|guitar}}}}
  +
* {{App|lazygit|git コマンド用のシンプルなターミナル UI|https://github.com/jesseduffield/lazygit|{{Pkg|lazygit}}}}
  +
* {{App|QGit|リビジョン履歴を参照し、パッチの内容と変更されたファイルを表示し、さまざまな開発ブランチをグラフィカルにたどる Git GUI ビューア|https://github.com/tibirna/qgit|{{Pkg|qgit}}}}
  +
* {{App|[[Wikipedia:RabbitVCS|RabbitVCS]]|使用しているバージョン管理システムへのシンプルで直接的なアクセスを提供するために作成されたグラフィカルツールのセット|http://rabbitvcs.org/|{{AUR|rabbitvcs}}}}
  +
* {{App|Sublime Merge|Sublime Text のメーカーによる Git クライアント|https://www.sublimemerge.com/|{{AUR|sublime-merge}}}}
  +
* {{App|Tig|git 用の ncurses ベースのテキストモードインターフェイス|https://jonas.github.io/tig/|{{Pkg|tig}}}}
  +
* {{App|ungit|git の汎用性を犠牲にすることなく、git に使いやすさをもたらします|https://github.com/FredrikNoren/ungit|{{AUR|nodejs-ungit}}}}
   
 
== 基本設定 ==
 
== 基本設定 ==
38行目: 49行目:
 
$ git config --global user.name "''John Doe''"
 
$ git config --global user.name "''John Doe''"
 
$ git config --global user.email "''johndoe@foobar.com''"
 
$ git config --global user.email "''johndoe@foobar.com''"
  +
  +
こちらも参照 [https://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Getting Started - First-Time Git Setup]
   
 
他の設定については [[#高度な設定]] を見て下さい。
 
他の設定については [[#高度な設定]] を見て下さい。
43行目: 56行目:
 
== 基本的な使い方 ==
 
== 基本的な使い方 ==
   
  +
Git リポジトリは {{ic|.git}} ディレクトリに格納され、リビジョン履歴やその他のメタデータを保持します。リポジトリが追跡するディレクトリ (デフォルトでは親ディレクトリ) は、作業ディレクトリと呼ばれます。作業ツリーの変更は、リポジトリに記録 (コミット) される前にステージングされる必要があります。Git では、以前にコミットした作業ツリーのファイルを復元することもできます。
このチュートリアルでは Git によるプロジェクトの基本的な分散バージョン管理について説明します。典型的な Git のワークフローは以下の通りです:
 
   
  +
[https://git-scm.com/book/en/Getting-Started-Git-Basics Getting Started - Git Basics] を参照してください。
# 新しいプロジェクトを作成、またはリモートのプロジェクトを複製する。
 
# ブランチを作成して変更を加え、変更をコミットする。
 
# コミットを統合して上手くまとめて分かりやすくする。
 
# メインのブランチにコミットをマージする。
 
# (任意) 変更をリモートサーバーにプッシュする。
 
   
=== ローカルリポジトリ ===
+
=== Git リポジトリの取得 ===
   
  +
* リポジトリの初期化
==== ステージング ====
 
  +
:{{ic|git init}}, 参照 {{man|1|git-init}}
  +
* 既存のリポジトリのクローンを作成
  +
:{{ic|git clone ''repository''}}, 参照 {{man|1|git-clone}} (Git URL についても説明します)
   
  +
=== 変更の記録 ===
新しいリポジトリを作成:
 
   
  +
Git プロジェクトにはステージング領域があります。これは、Git ディレクトリにある {{ic|index}} ファイルで、次のコミットに反映される変更点を保存しておくものです。したがって、変更したファイルを記録するには、まずそれをインデックスに追加する (ステージングする) 必要があります。そして、{{ic|git commit}} コマンドは現在のインデックスを新しいコミットに格納します。
$ git init
 
   
  +
==== ステージングの変更 ====
リポジトリの変更を記録するには、先に''インデックス''または''ステージングエリア'' (''ステージング''とも呼ばれます) に変更を追加する必要があります。ファイルを追加するには:
 
 
$ git add ''file1'' ''file2''
 
 
ファイルを全て追加:
 
 
$ git add .
 
 
{{Tip|{{ic|git add .}} などのコマンドでファイルを無視するようにしたい場合、{{ic|.gitignore}} ファイルを作成してください:
 
 
{{hc|.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/**
 
}}
 
 
詳しくは [https://git-scm.com/docs/gitignore gitignore(5)] を参照。
 
}}
 
   
  +
* 作業ツリーの変更をインデックスに追加
ステージングからファイルを削除 ({{ic|--cached}} を付けるとファイルを実際には削除しません):
 
  +
:{{ic|git add ''pathspec''}}, 参照 {{man|1|git-add}}
  +
* * インデックスから変更を削除
  +
:{{ic|git reset ''pathspec''}}, 参照 {{man|1|git-reset}}
  +
* コミットする変更、ステージングされていない変更、追跡されていないファイルを表示する
  +
:{{ic|git status}}, 参照 {{man|1|git-status}}
   
  +
Git に特定の未追跡ファイルを無視させるには、{{ic|.gitignore}} ファイルを使用します。
$ git rm ''(--cached)'' ''file''
 
   
  +
Git はファイルの動きを追跡しません。マージ中の移動の検出は、内容の類似性のみに基づいて行われます。{{ic|git mv}} コマンドは便宜上存在するだけで、これと同等です。
ファイルを全て削除:
 
   
$ git rm --cached -r .
+
$ mv -i foo bar
  +
$ git reset -- foo
 
  +
$ git add bar
または:
 
 
$ git reset HEAD -- .
 
 
上記の {{ic|HEAD}} は現在の版の「シンボル参照」です。
 
 
ファイルの名前を変更:
 
 
$ git mv ''file1'' ''file2''
 
 
ファイルのリストを表示:
 
 
$ git ls-files
 
 
上記のコマンドはデフォルトでステージングエリアのファイルを表示します ({{ic|--cached}} ファイル)。
 
   
 
==== 変更をコミット ====
 
==== 変更をコミット ====
   
  +
{{ic|git commit}} コマンドは段階的な変更をリポジトリに記録します。{{man|1|git-commit}} を参照してください。
コンテンツを''ステージング''に記録したら、次のコマンドでコミットします:
 
   
  +
* {{ic|-m}} - デフォルトのテキストエディタでコミットメッセージを作成する代わりに、引数としてコミットメッセージを指定します。
$ git commit -m "''First commit.''"
 
  +
* {{ic|-a}} - 変更または削除されたファイルを自動的にステージングします (追跡されていないファイルは追加されません)
  +
* {{ic|--amend}} - 直近のコミットをやり直し、コミットメッセージやコミットされたファイルを修正します。
   
  +
{{Tip|常に小さな変化を頻繁に、そして意味のあるメッセージを添えてコミットしてください。}}
{{ic|-m}}, {{ic|--message}} オプションを使うことで短いメッセージを残せます: オプションを省略した場合、事前に設定していたエディタが起動して長いメッセージを書くことができます。
 
   
  +
==== リビジョンを選択 ====
{{Tip|
 
* 小さい変更でも頻繁にコミットを行ってちゃんとしたメッセージを書くようにしましょう。
 
* 編集を加えたファイルを全てインデックスに追加して、それらをコミットするのは一つのコマンドで実行できます ({{ic|-a}} は {{ic|--all}} の略式):
 
   
  +
Git には、リビジョンを指定する方法が複数あります。{{man|7|gitrevisions}} と [https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection Revision Selection] を参照してください。
$ git commit -am "''First commit.''"
 
}}
 
   
  +
多くの Git コマンドは、リビジョンを引数として受け取ります。コミットは、以下のいずれかによって識別されます。
過去に戻ってコミットメッセージを編集:
 
   
  +
* コミットの SHA-1 ハッシュ (通常、最初の7桁でコミットを一意に識別できます。)
$ git commit --amend -m "''Message.''"
 
  +
* ブランチ名やタグ名などの任意のコミット ラベル
 
  +
* ラベル {{ic|HEAD}} は常に現在チェックアウトされているコミット (通常はブランチの先頭、ただし ''git checkout'' を使って古いコミットに履歴を戻した場合は除く) を指します。
この記事で使われるコマンドの多くはコミットを引数として指定します。コミットは以下の形式のどれかで指定することが可能です:
 
  +
* 上記のいずれかと、前のコミットを参照するための {{ic|~}} を加えたものです。例えば、{{ic|HEAD~}} は {{ic|HEAD}} の一つ前のコミットを指し、{{ic|HEAD~5}} は {{ic|HEAD}} の五つ前のコミットを指し示します。
 
* 40文字の SHA-1 ハッシュ (大抵は最初の7文字くらいで一意に識別できます)。
 
* ブランチやタグの名前といったコミットのラベル。
 
* {{ic|HEAD}} ラベルはチェックアウトされた最新のコミットを示します ({{ic|git checkout}} を使って古いコミットまで歴史を戻していない限り、ブランチの頭になります)。
 
* 上記に加えて {{ic|~}} を付けることで前のコミットを指定できます。例えば、{{ic|HEAD~}} は {{ic|HEAD}} の一つ前のコミット、{{ic|HEAD~5}} は {{ic|HEAD}} の五つ前のコミットを指します。
 
   
 
==== 変更を閲覧 ====
 
==== 変更を閲覧 ====
152行目: 127行目:
 
$ git log ''(-N)''
 
$ git log ''(-N)''
   
==== ブランチの作成 ====
+
=== 元に戻す ===
  +
  +
* {{ic|git checkout}} - を使って作業ツリーファイルを復元することができます{{man|1|git-checkout}}
  +
* {{ic|git reset}} - 現在の HEAD を指定された状態にリセット、{{man|1|git-reset}} を参照
  +
* {{ic|git revert}} - 既存のコミットを revert するには {{man|1|git-revert}} を参照してください。
  +
  +
これらについては、[https://www.atlassian.com/git/tutorials/undoing-changes undoing-changes] でさらに詳しく説明しています。
  +
  +
より複雑な履歴の変更、たとえば {{ic|git commit --amend}} や {{ic|git rebase}} については、たとえば [https://www.atlassian.com/git/tutorials/rewriting-history rewriting-history] をご覧ください。このような書き換えは、他のユーザーと共同で行ったコミットには使用しないことを強く推奨します。少なくとも、事前に十分な調整をする必要があります。
  +
  +
=== ブランチの作成 ===
   
 
基本的に、修正や新しい機能などはブランチでテストします。変更が問題ないようだったら、デフォルトのブランチ (master) にマージします。ブランチを作成するときは、目的に適った名前を付けて下さい:
 
基本的に、修正や新しい機能などはブランチでテストします。変更が問題ないようだったら、デフォルトのブランチ (master) にマージします。ブランチを作成するときは、目的に適った名前を付けて下さい:
183行目: 168行目:
 
=== 共同作業 ===
 
=== 共同作業 ===
   
==== エチケット ====
+
==== プルリクト ====
   
  +
変更を加えてコミットしたら、ソフトウェアの作者にマージするように要求することができます。これを ''プルリクエスト'' と呼びます。
* 既存のプロジェクトに貢献しようと考えた場合、プロジェクトのライセンスを確認しましょう。コードの変更についてかなり制限がかけられている場合もあります。ライセンスによっては、コードの所有権について論争が生まれることも考えられます。
 
* プロジェクトのコミュニティを観測してどうやったら適合できるか考えましょう。プロジェクトの方向性を理解するために、ドキュメントやリポジトリの[[#履歴とバージョニング|ログ]]を読むのも大切です。
 
* コミットを pull するようにリクエストしたり、パッチを送るときは、できるかぎりパッチを短くして説明を付加するようにしましょう。メンテナがあなたの変更箇所を理解するための手助けとなり、マージするか、もしくは修正を加えるよう要求すべきか判断する基準にもなります。
 
* リジェクトされたとしても、落胆する必要はありません。所詮他人のプロジェクトです。リクエストが重要な場合、出来るかぎり分かりやすく根気よくリクエストの理由を説明しましょう。いつかは解決に導かれるはずです。
 
 
==== リポジトリを複製 ====
 
 
プロジェクトへの貢献を始めるには、まずリポジトリを ''clone'' します:
 
 
$ git clone ''location'' ''folder''
 
 
{{ic|''location''}} はパスでもネットワークアドレスでもかまいません。また、複製が完了すると場所が記録されるので、{{ic|git pull}} だけで複製できるようになります。
 
 
==== プルリクエスト ====
 
   
  +
pull するには:
変更を加えてコミットしたら、ソフトウェアの作者にマージするように要求することができます。これを「プルリクエスト」と呼びます。'''pull''' するには:
 
   
 
$ git pull ''location'' master
 
$ git pull ''location'' master
246行目: 218行目:
 
==== マージの対処 ====
 
==== マージの対処 ====
   
マージの衝突を解決する方法は Git Book の [https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%A8%E3%83%9E%E3%83%BC%E3%82%B8%E3%81%AE%E5%9F%BA%E6%9C%AC#%E3%83%9E%E3%83%BC%E3%82%B8%E6%99%82%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%95%E3%83%AA%E3%82%AF%E3%83%88 マージ時のコンフリクト] を見てください。マージは基本的に可逆です。{{ic|--abort}} コマンドを使うことでマージを取り消すことができます (例: {{ic|git merge --abort}} または {{ic|git pull --abort}})
+
マージの衝突を解決する方法は Git Book の [https://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merge-Conflicts マージ時のコンフリクト] を見てください。マージは基本的に可逆です。{{ic|--abort}} コマンドを使うことでマージを取り消すことができます (例: {{ic|git merge --abort}} または {{ic|git pull --abort}})
 
==== メーリングリストにパッチを送信 ====
 
 
メーリングリストに直接パッチを送る場合、次のパッケージをインストールする必要があります: {{Pkg|perl-authen-sasl}}, {{Pkg|perl-net-smtp-ssl}}, {{Pkg|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''
 
 
これでメーリングリストにパッチを送信することができます ([http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches 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
 
   
 
=== 履歴とバージョニング ===
 
=== 履歴とバージョニング ===
283行目: 236行目:
 
$ git grep ''pattern'' -- '*.[ch]'
 
$ git grep ''pattern'' -- '*.[ch]'
   
==== バージョニンとリリース ====
+
==== 付け ====
   
 
コミットにタグを付ける:
 
コミットにタグを付ける:
319行目: 272行目:
 
最初のカラムに rebase で実行する動作を記述します。以下から選んでください:
 
最初のカラムに rebase で実行する動作を記述します。以下から選んでください:
   
* {{ic|pick}} — コミットをそのまま適用します (デフォルト)
+
* {{ic|pick}} — コミットをそのまま適用します(デフォルト)
 
* {{ic|edit}} — ファイルやコミットメッセージを編集。
 
* {{ic|edit}} — ファイルやコミットメッセージを編集。
 
* {{ic|reword}} — コミットメッセージを編集。
 
* {{ic|reword}} — コミットメッセージを編集。
329行目: 282行目:
 
{{Note|コミットの squash はローカルコミットでのみ使います。他人と共有しているリポジトリで使うと問題が発生します。}}
 
{{Note|コミットの squash はローカルコミットでのみ使います。他人と共有しているリポジトリで使うと問題が発生します。}}
   
  +
== ヒントとテクニック ==
== 高度な設定 ==
 
   
  +
=== git-config の使用 ===
Git は INI タイプの設定ファイルから設定を読み込みます:
 
   
  +
Git は、4つの INI タイプの設定ファイルからその構成を読み取ります。
* 各リポジトリにはリポジトリごとの設定を記述した {{ic|.git/config}} ファイルが含まれます。
 
* 各ユーザーの {{ic|$HOME/.gitconfig}} ファイルがフォールバックとして使われます。
 
* システム全体のデフォルト設定としては {{ic|/etc/gitconfig}} が使われます。
 
   
  +
* {{ic|/etc/gitconfig}} システム全体のデフォルト
上記のファイルは直接編集できますが、通常は下の例にあるように {{ic|git config}} を使います。
 
  +
* {{ic|~/.gitconfig}} と {{ic|~/.config/git/config}} (since 1.7.12) ユーザー固有の設定用
  +
* {{ic|.git/config}} リポジトリ固有の設定用
   
  +
これらのファイルは直接編集できますが、通常の方法は、以下の例に示すように ''git config'' を使用することです。
現在設定されている変数を確認:
 
  +
  +
現在設定されている変数を一覧表示します。
   
 
$ git config {--local,--global,--system} --list
 
$ git config {--local,--global,--system} --list
   
デフォルトエディタを [[vim]] から [[nano]] に設定:
+
デフォルトエディタを [[vim]] から [[nano]] に設定します。
   
 
$ git config --global core.editor "nano -w"
 
$ git config --global core.editor "nano -w"
   
デフォルトのプッシュアクションを設定:
+
デフォルトのプッシュアクションを設定します。
   
 
$ git config --global push.default simple
 
$ git config --global push.default simple
   
{{ic|git difftool}} で使用するツールを設定 (デフォルトでは ''meld'' になっています):
+
''git difftool'' に別のツールを設定します (デフォルトでは ''meld''):
   
 
$ git config --global diff.tool vimdiff
 
$ git config --global diff.tool vimdiff
   
しく [https://www.kernel.org/pub/software/scm/git/docs/git-config.html git-config(1)] [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration Git Configuration] をさい。
+
細について、{{man|1|git-config}} および [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration Git 構成] を参照しください。
  +
  +
=== 良いエチケットを採用する ===
  +
  +
* 既存のプロジェクトに貢献することを検討する場合、コードを変更する能力を過度に制限する可能性があるため、そのライセンスを読んで理解してください。ライセンスによっては、コードの所有権をめぐって紛争を引き起こす可能性があります。
  +
* プロジェクトのコミュニティと、自分がそこにどれだけ溶け込めるかを考えましょう。プロジェクトの方向性を知るために、あらゆるドキュメントや、リポジトリの [[#History and versioning|log]] を読んでください。
  +
* コミットをプルしたり、パッチを提出したりするときは、小規模で十分な文書化を心がけましょう。そうすることで、メンテナがあなたの変更を理解し、マージするか修正を依頼するかを判断しやすくなります。
  +
* もし、投稿が拒否されても、落ち込まないでください。重要なことであれば、その理由をできるだけ明確に、忍耐強く議論してください。
   
 
=== 認証の高速化 ===
 
=== 認証の高速化 ===
363行目: 325行目:
 
* SSH 鍵を使って認証している場合、[[SSH 鍵#SSH エージェント|SSH エージェント]]を使って下さい。[[SSH#SSH の高速化]] や [[SSH#Keep alive]] も参照。
 
* SSH 鍵を使って認証している場合、[[SSH 鍵#SSH エージェント|SSH エージェント]]を使って下さい。[[SSH#SSH の高速化]] や [[SSH#Keep alive]] も参照。
 
* ユーザー名とパスワードを使って認証している場合、サーバーが SSH をサポートしているなら [[SSH 鍵]]に切り替えてください。もしくは [https://git-scm.com/docs/git-credential-cache git-credential-cache] や [https://git-scm.com/docs/git-credential-store git-credential-store] を使ってみて下さい。
 
* ユーザー名とパスワードを使って認証している場合、サーバーが SSH をサポートしているなら [[SSH 鍵]]に切り替えてください。もしくは [https://git-scm.com/docs/git-credential-cache git-credential-cache] や [https://git-scm.com/docs/git-credential-store 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 をセットアップします。
  +
  +
=== git-credential-netrc を認証情報ヘルパーとして使用する ===
  +
  +
Git は、[https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html netrc] ファイルを読み取って認証情報にアクセスできます。まず、Git を netrc ヘルパースクリプトに誘導します。
  +
  +
$ git config --global credential.helper /usr/share/git/credential/netrc/git-credential-netrc.perl
  +
  +
次に、{{ic|.netrc}} ファイルを [[作成]] します。
  +
  +
{{hc|~/.netrc|
  +
machine git-host
  +
login username
  +
password password
  +
}}
  +
  +
認証情報ヘルパーは [[gpg]] で暗号化されたファイル ({{ic|~/.netrc.gpg}}) もサポートします。
   
 
=== デフォルトプロトコル ===
 
=== デフォルトプロトコル ===
381行目: 373行目:
 
=== Git プロンプト ===
 
=== Git プロンプト ===
   
Git パッケージにはプロンプトスクリプトが付属しています。プロンプトを有効にするには、[[自動起動#シェル|シェルのスタートアップファイル]]で {{ic|/usr/share/git/completion/git-prompt.sh}} スクリプトを source 、{{ic|%s}} パラメータカスタムプロンプトを設定してください:
+
Git パッケージにはプロンプトスクリプトが付属しています。これを有効にするには、{{ic|/usr/share/git/completion/git-prompt.sh}} をソースし、{{ic|%s}} パラメータを使用してカスタムプロンプトを設定します。
   
 
* [[Bash]] の場合: {{ic|1=PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '}}
 
* [[Bash]] の場合: {{ic|1=PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '}}
* [[zsh]] の場合: {{ic|1=PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '}}
+
* [[zsh]] の場合: {{ic|1=setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '}}
   
Git リポジトリのディレクトリに移動すると、プロンプトブランチ前を表示するようになります。情報もプロンプトに表示さるよう設定できます:
+
Git リポジトリのディレクトリに変更すると、プロンプトが変化してブランチ名表示されます。対応する環境変数を設定することで、追加詳細がプロンプトに表示さるよう設定できます
   
 
{| class="wikitable"
 
{| class="wikitable"
392行目: 384行目:
 
! シェル変数 !! 情報
 
! シェル変数 !! 情報
 
|-
 
|-
| GIT_PS1_SHOWDIRTYSTATE || ステージ済みの場合は '''+'''、未ステージの場合は '''*'''
+
| GIT_PS1_SHOWDIRTYSTATE || ステージ済みの場合は '''+'''、未ステージの場合は '''*'''
 
|-
 
|-
| GIT_PS1_SHOWSTASHSTATE || スタッシュが存在する場合は '''$'''
+
| GIT_PS1_SHOWSTASHSTATE || スタッシュが存在する場合は '''$'''
 
|-
 
|-
| GIT_PS1_SHOWUNTRACKEDFILES || 追跡されていないファイルが存在する場合は '''%'''
+
| GIT_PS1_SHOWUNTRACKEDFILES || 追跡されていないファイルが存在する場合は '''%'''
 
|-
 
|-
| GIT_PS1_SHOWUPSTREAM || 上流からの進み・戻り・分岐 ('''<,>,<>''')
+
| GIT_PS1_SHOWUPSTREAM || 上流からの進み・戻り・分岐 ('''<,>,<>''')
  +
|-
  +
| GIT_PS1_STATESEPARATOR || ブランチ名と状態記号の間の区切り文字
  +
|-
  +
| GIT_PS1_DESCRIBE_STYLE || HEAD が切り離されている場合、タグまたはブランチに関連するコミットを表示します
  +
|-
  +
| GIT_PS1_SHOWCOLORHINTS || カラーで表示する
 
|}
 
|}
   
  +
環境変数の完全なドキュメントは、スクリプトのコメントで参照できます。
変更を適用するには {{ic|GIT_PS1_SHOWUPSTREAM}} を {{ic|auto}} に設定する必要があります。
 
   
  +
{{Note|
{{Note|{{ic|$(__git_ps1)}} が {{ic|((unknown))}} と返す場合、何もリポジトリが含まれていない {{ic|.git}} フォルダがカレントディレクトリに存在します。そのために Git が認識しなくなっています。{{ic|~/.gitconfig}} ではなく間違って {{ic|~/.git/config}} に Git の設定ファイルを作成した場合などに発生します。}}
 
  +
* {{ic|$(__git_ps1)}} が {{ic|((unknown))}} と返す場合、何もリポジトリが含まれていない {{ic|.git}} フォルダがカレントディレクトリに存在するため Git が認識しなくなっています。{{ic|~/.gitconfig}} ではなく間違って {{ic|~/.git/config}} に Git の設定ファイルを作成した場合などに発生します。
  +
* 非常に大規模なリポジトリでプロンプトに遅延が発生している場合は、{{ic|GIT_PS1_SHOWUNTRACKEDFILES}} オプションが原因である可能性があります。このオプションは、新しいファイルを検出するたびに完全なディレクトリツリースキャンをトリガーし、パフォーマンスに顕著な影響を与えます。 これらのリポジトリに対してこのオプションをローカルで無効にするには、コマンド {{ic|git config --local bash.showUntrackedFiles false}} を使用できます。
  +
}}
   
 
もしくは、{{AUR|bash-git-prompt}} や {{AUR|gittify}} など [[AUR]] にある git シェルプロンプトのカスタマイズパッケージを利用することもできます。
 
もしくは、{{AUR|bash-git-prompt}} や {{AUR|gittify}} など [[AUR]] にある git シェルプロンプトのカスタマイズパッケージを利用することもできます。
   
== 高度な使い方 ==
+
=== ビジュアル表現 ===
   
変更量を視覚的に表示するには:
+
作業量を把握するため:
   
 
$ git diff --stat
 
$ git diff --stat
   
{{ic|git log}} フォーク:
+
''git log'' フォーク表:
   
 
$ git log --graph --oneline --decorate
 
$ git log --graph --oneline --decorate
   
{{ic|git log}} グラフエイリアス ({{ic|git graph}} 表示が綺麗になります):
+
''git log'' グラフエイリアス (つまり ''git graph'' は装飾されたバージョンを表示す):
   
 
$ git config --global alias.graph 'log --graph --oneline --decorate'
 
$ git config --global alias.graph 'log --graph --oneline --decorate'
   
  +
=== コミットのヒント ===
前のコミットにリセット (非常に危険なコマンドです。コミットで行われた変更が全て消去されます):
 
  +
  +
前のコミットにリセット (非常に危険、指定したコミットまですべて消去されます):
   
 
$ git reset --hard HEAD^
 
$ git reset --hard HEAD^
   
リポジトリのアドレスが変更された場合、リモートアドレスを更新する必要があります:
+
リポジトリのアドレスが変更された場合、そのリモートロケーションを更新する必要があります:
   
 
$ git remote set-url origin git@''address'':''user''/''repo''.git
 
$ git remote set-url origin git@''address'':''user''/''repo''.git
   
  +
あるいは、{{ic|.git/config}} を編集して新しい場所を指定します。
{{Note|gpg 署名で pinentry curses を使うには {{ic|1=export GPG_TTY=$(tty)}} (もしくは pinentry-tty を使用) を実行する必要があります。実行していないと gpg がロック状態の場合に署名が失敗します (pin の要求ができないためです)。}}
 
   
Signed-off-by 行を追加 (プロジェクトによってはコミットに名前メール署名追加を必要とする場合があります):
+
Signed-off-by line append (プロジェクトによっては必要な、名前と電子メール署名がコミットに追加されます):
   
$ git commit -s
+
$ git commit -s
   
パッチに Signed-off-by 自動追加 ({{ic|git format-patch ''commit''}} を使用したとき):
+
Signed-off-by 自動的にパッチに追加されます ({{ic|git format-patch ''commit''}} を使用する場合):
   
 
$ git config --local format.signoff true
 
$ git config --local format.signoff true
   
変更を加えたファイルの特定部分をコミット。大量の変更を行ったとき複数のコミットに分けたい場合に有用です:
+
変更されたファイルの特定部分をコミットしますこれは、多数の変更があり、複数のコミットに分けたほうがよい場合に有用です
   
 
$ git add -p
 
$ git add -p
  +
  +
=== コミットへの署名 ===
  +
  +
Git では、コミットやタグに [[GnuPG]] を使って署名することができます。[https://git-scm.com/book/en/Git-Tools-Signing-Your-Work Signing Your Work] を参照してください。
  +
  +
{{Note|GPG 署名に [[pinentry]] curses を使用するには、 {{ic|1=export GPG_TTY=$(tty)}} (あるいは pinentry-tty を使用) してください。そうしないと GPG が現在ロック状態にある場合に署名が失敗します (pin を要求できないため)。}}
  +
  +
Git が自動的にコミットに署名するように設定するには:
  +
  +
$ git config --global commit.gpgSign true
   
 
=== マスター以外のブランチで作業 ===
 
=== マスター以外のブランチで作業 ===
456行目: 469行目:
 
$ git push --all
 
$ git push --all
   
  +
=== メーリングリストにパッチを送信 ===
== Git サーバー ==
 
   
  +
メーリングリストに直接パッチを送る場合、次のパッケージをインストールする必要があります: {{Pkg|perl-authen-sasl}}, {{Pkg|perl-net-smtp-ssl}}, {{Pkg|perl-mime-tools}}
様々なプロトコルによるリポジトリへの接続を設定する方法。
 
   
  +
ユーザー名とメールアドレスを設定したか確認してください、[[Git#基本設定|基本設定]] を参照
=== SSH ===
 
   
  +
メールアドレスを設定:
SSH プロトコルを使うには、まず SSH 公開鍵を設定します。[[SSH 鍵]]のガイドに従って設定してください。SSH サーバーを設定する方法は、[[SSH]] を見て下さい。
 
   
  +
$ git config --global sendemail.smtpserver ''smtp.gmail.com''
SSH を動作させて鍵を生成したら、{{ic|~/.ssh/id_rsa.pub}} の中身を {{ic|~/.ssh/authorized_keys}} に貼り付けてください (1行に全て記述)。以下を実行することで SSH で Git リポジトリにアクセスできます:
 
  +
$ git config --global sendemail.smtpserverport ''587''
  +
$ git config --global sendemail.smtpencryption ''tls''
  +
$ git config --global sendemail.smtpuser ''foobar@gmail.com''
   
  +
これでメーリングリストにパッチを送信することができます ([http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches OpenEmbedded:How to submit a patch to OpenEmbedded#Sending patches] を参照):
$ git clone ''user''@''foobar.com'':''my_repository''.git
 
   
  +
$ git add ''filename''
SSH クライアントの {{ic|StrictHostKeyChecking}} 設定が {{ic|ask}} になっている場合 (デフォルト設定)、SSH は yes/no の確認を表示します。{{ic|yes}} と入力してから {{ic|Enter}} を押してください。それでリポジトリがチェックアウトされます。SSH を使用する場合、コミット権限も得られます。
 
  +
$ git commit -s
  +
$ git send-email --to=''openembedded-core@lists.openembedded.org'' --confirm=always -M -1
   
  +
=== 大規模な git リポジトリの操作 ===
SSH を使うように既存のリポジトリを設定するには、リモート URL を再定義してください:
 
   
  +
大規模なリモートリポジトリを操作する場合、大量のデータをフェッチする必要があります。次の例では、Linux カーネルを使用して、そのようなコードベースを操作する方法を示しています。
$ git remote set-url origin git@localhost:''my_repository''.git
 
   
  +
==== リポジトリ全体を取得する ====
{{ic|/etc/ssh/ssh_config}} や {{ic|~/.ssh/config}} の設定によって22番以外のポートに接続できます。リポジトリのポートを設定するには (例: 443):
 
   
  +
最も簡単な解決策は、リポジトリ全体を取得することです。
{{hc|~/.git/config|2=
 
[remote "origin"]
 
url = ssh://''user''@''foobar''.com:443/~''my_repository''/repo.git
 
}}
 
   
  +
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
=== Smart HTTP ===
 
   
  +
{{Note|{{ic|git clone}} を中断すると再開できません}}
Git は git-http-backend を利用することで SSH や Git プロトコルと同じように HTTP(S) プロトコルを効率的に扱うことができます。リポジトリから clone あるいは pull できるだけでなく、HTTP(S) を使ってリポジトリに push することが可能です。
 
   
  +
{{ic|git pull}} でリポジトリを更新できます。
セットアップは大して難しくありません。Apache ウェブサーバー ({{pkg|apache}} と {{ic|mod_cgi}}, {{ic|mod_alias}}, {{ic|mod_env}}) と {{pkg|git}} をインストール・設定するだけです。
 
   
  +
==== リポジトリの部分的な取得 ====
基本的なセットアップが出来たら、Apache の設定ファイルに以下を追加してください:
 
   
  +
ローカルリポジトリをオリジンのより小さなサブセットに制限するには、たとえば v4.14 以降でバグを二分するために、浅いクローンを使用します。
{{hc|/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 clone --shallow-exclude v4.13 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
上記の設定では Git リポジトリは {{ic|/srv/git}} としています。次のような URL でアクセスします: {{ic|<nowiki>http(s)://your_address.tld/git/your_repo.git</nowiki>}}。
 
   
  +
v4.14 以降は入手できますが、v4.13 以前は入手できません。
{{Note|Apache からリポジトリに読み書きできることを確認してください。}}
 
   
  +
すべての履歴を無視して、最新のスナップショットのみが必要な場合。(tarball が利用可能で、それで十分な場合は、それを選択してください。git リポジトリからダウンロードするには、より多くの帯域幅が必要です。) 次の方法で取得できます。
詳しいドキュメントは以下のリンクを参照:
 
* https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
 
   
  +
$ git clone --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
=== Git ===
 
   
  +
次の2つの例に示すように、後で古いコミットを取得できます。
{{Note|Git プロトコルでは読み取りアクセスだけが許可されます。}}
 
  +
  +
$ git fetch --tags --shallow-exclude v4.1
  +
$ git fetch --tags --shallow-since 2016-01-01
  +
  +
{{Note|{{ic|--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
  +
  +
いつものように、{{ic|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:Virtual File System for Git|Wikipedia article]] を参照してください。)
  +
  +
これは、gvfs と scalar を含む git の Microsoft のフォークである {{AUR|git-vfs}} で利用可能です。
  +
  +
=== 機密情報のフィルタリング ===
  +
  +
時には、ソフトウェアが平文のパスワードを設定ファイルに保存し、キーリングに接続するのとは対照的にすることがあります。このような場合、git clean-filters は機密情報を誤ってコミットしてしまうのを防ぐために便利です。たとえば、次のファイルでは "some-dotfile" というファイルにフィルタを割り当てています。
  +
  +
{{hc|.gitattributes|<nowiki>
  +
some-dotfile filter=remove-pass
  +
</nowiki>}}
  +
  +
"some-dotfile" というファイルが git にチェックインされると、git はチェックイン前にこのファイルに対して "remove-pass" というフィルタを実行します。このフィルターは、git-configuration ファイルで定義しておく必要があります。
  +
  +
{{hc|.git/config|<nowiki>
  +
[filter "remove-pass"]
  +
clean = "sed -e 's/^password=.*/#password=TODO/'"
  +
</nowiki>}}
   
  +
{{Note|sed 式の特殊文字をエスケープすることは、この文脈では [https://stackoverflow.com/questions/49652495/git-filter-and-sed-fight-over トリッキーな作業] になります。git は2つのバックスラッシュを1つに変え、一方 git がコマンドを実行するために呼び出すシェルは、2つのバックスラッシュを再び1つに変えることを思い出してください。詳しくは、[https://stackoverflow.com/a/49654653 Git filter and sed fight over `$`] をご覧ください。}}
{{ic|git-daemon.socket}} を[[起動|起動・有効化]]してください。
 
   
  +
=== HTML ヘルプファイル ===
デーモンは以下のオプションで起動します:
 
   
  +
{{AUR|git-htmldocs}} をインストールすることで、{{ic|git help}} のドキュメントを HTML 形式で利用することもできます。インストール後、HTML ドキュメントには {{ic|-w}} フラグを付けてアクセスすることができます。例えば
ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git
 
   
  +
$ git help -w merge
{{ic|/srv/git/}} に置かれたリポジトリがデーモンによって認識されます。次のようなコマンドでクライアントで接続できます:
 
   
  +
{{ic|git config}} オプションを設定すると、デフォルトで HTML ドキュメントを読み込むことができます。
$ git clone git://''location''/''repository''.git
 
   
  +
$ git config --global help.format html
=== アクセス権限の設定 ===
 
   
  +
== 拡張機能 ==
読み書きアクセスを制限したいときは、標準の Unix パーミッションを使います。詳しくは http://sitaramc.github.com/gitolite/doc/overkill.html{{Dead link|2013|11|06}} ([https://web.archive.org/web/20111004134500/http://sitaramc.github.com/gitolite/doc/overkill.html archive.org mirror]) を参照してください。
 
   
  +
* {{App|gitflow-avh|[https://nvie.com/posts/a-successful-git-branching-model/ Vincent Driessen の分岐モデル] で git を拡張します。AVH Edition はより多くの機能を追加します。|https://github.com/petervanderdoes/gitflow|{{AUR|gitflow-avh}}}}
より細かいアクセス管理については、[[gitolite]] や [[gitosis]] を参照してください。
 
  +
* {{App|git-extras|git 用のいくつかのユーティリティ (リポジトリの概要、repl、変更ログの人数、作成者のコミット率など)|https://github.com/tj/git-extras|{{AUR|git-extras}}}} - [https://ohmyz.sh oh-my-zsh] を使用している場合、[https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git-extras git-extras プラグイン] を有効にして下さい。
  +
* {{App|gitmoji-cli|A [https://gitmoji.dev/ gitmoji] コミットメッセージで gitmojis を使用するためのインタラクティブな NodeJS クライアント。|https://github.com/carloscuesta/gitmoji-cli|{{AUR|nodejs-gitmoji-cli}}}}
   
 
== 参照 ==
 
== 参照 ==

2024年5月1日 (水) 20:53時点における最新版

関連記事

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

インストール

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

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

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

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

リビジョンを選択

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

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

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

変更を閲覧

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

$ 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 --amendgit 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 コマンドは fetchmerge の組み合わせです。衝突があった場合 (例えば同じ時間帯にソフトウェアの作者が変更を加えた場合)、手動で解消する必要があります。

もしくは、オリジナルの作者は取り込みたい変更を 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 サーバーにプッシュする度に認証が面倒なのをなんとかしたいと思っている場合、以下を使って下さい。

git-credential-libsecret を認証情報ヘルパーとして使用する

Git は GNOME/KeyringKeePass のような 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 をセットアップします。

git-credential-netrc を認証情報ヘルパーとして使用する

Git は、netrc ファイルを読み取って認証情報にアクセスできます。まず、Git を netrc ヘルパースクリプトに誘導します。

$ git config --global credential.helper /usr/share/git/credential/netrc/git-credential-netrc.perl

次に、.netrc ファイルを 作成 します。

~/.netrc
machine git-host
login username
password password

認証情報ヘルパーは gpg で暗号化されたファイル (~/.netrc.gpg) もサポートします。

デフォルトプロトコル

上述のように 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 をソースし、%s パラメータを使用してカスタムプロンプトを設定します。

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

Git リポジトリのディレクトリに変更すると、プロンプトが変化してブランチ名が表示されます。対応する環境変数を設定することで、追加の詳細がプロンプトに表示されるように設定できます。

シェル変数 情報
GIT_PS1_SHOWDIRTYSTATE ステージ済みの場合は +、未ステージの場合は *
GIT_PS1_SHOWSTASHSTATE スタッシュが存在する場合は $
GIT_PS1_SHOWUNTRACKEDFILES 追跡されていないファイルが存在する場合は %
GIT_PS1_SHOWUPSTREAM 上流からの進み・戻り・分岐 (<,>,<>)
GIT_PS1_STATESEPARATOR ブランチ名と状態記号の間の区切り文字
GIT_PS1_DESCRIBE_STYLE HEAD が切り離されている場合、タグまたはブランチに関連するコミットを表示します
GIT_PS1_SHOWCOLORHINTS カラーで表示する

環境変数の完全なドキュメントは、スクリプトのコメントで参照できます。

ノート:
  • $(__git_ps1)((unknown)) と返す場合、何もリポジトリが含まれていない .git フォルダがカレントディレクトリに存在するため Git が認識しなくなっています。~/.gitconfig ではなく間違って ~/.git/config に Git の設定ファイルを作成した場合などに発生します。
  • 非常に大規模なリポジトリでプロンプトに遅延が発生している場合は、GIT_PS1_SHOWUNTRACKEDFILES オプションが原因である可能性があります。このオプションは、新しいファイルを検出するたびに完全なディレクトリツリースキャンをトリガーし、パフォーマンスに顕著な影響を与えます。 これらのリポジトリに対してこのオプションをローカルで無効にするには、コマンド git config --local bash.showUntrackedFiles false を使用できます。

もしくは、bash-git-promptAURgittifyAUR など 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

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

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

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 のリポジトリにアクセスできるようにするものです。(この 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/'"
ノート: sed 式の特殊文字をエスケープすることは、この文脈では トリッキーな作業 になります。git は2つのバックスラッシュを1つに変え、一方 git がコマンドを実行するために呼び出すシェルは、2つのバックスラッシュを再び1つに変えることを思い出してください。詳しくは、Git filter and sed fight over `$` をご覧ください。

HTML ヘルプファイル

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

$ git help -w merge

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

$ git config --global help.format html

拡張機能

https://github.com/petervanderdoes/gitflow || gitflow-avhAUR
  • git-extras — git 用のいくつかのユーティリティ (リポジトリの概要、repl、変更ログの人数、作成者のコミット率など)
https://github.com/tj/git-extras || git-extrasAUR - oh-my-zsh を使用している場合、git-extras プラグイン を有効にして下さい。
  • gitmoji-cli — A gitmoji コミットメッセージで gitmojis を使用するためのインタラクティブな NodeJS クライアント。
https://github.com/carloscuesta/gitmoji-cli || nodejs-gitmoji-cliAUR

参照