「Git」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(add Category.)
 
(5人の利用者による、間の36版が非表示)
1行目: 1行目:
 
[[Category:バージョン管理システム]]
 
[[Category:バージョン管理システム]]
  +
[[Category:コマンド]]
  +
[[Category:OpenPGP]]
  +
[[de:Git]]
 
[[en:Git]]
 
[[en:Git]]
[[zh-CN:Git]]
+
[[es:Git]]
  +
[[zh-hans:Git]]
 
{{Related articles start}}
 
{{Related articles start}}
{{Related4|Super Quick Git Guide}}
+
{{Related|Bisecting bugs with Git}}
  +
{{Related|Concurrent Versions System}}
  +
{{Related|Git サーバー}}
 
{{Related|Gitweb}}
 
{{Related|Gitweb}}
  +
{{Related|HTTP トンネリング#Git のトンネリング}}
{{Related|Cgit}}
 
{{Related3|HTTP tunneling#Tunneling Git|HTTP トンネリング#Git のトンネリング}}
 
 
{{Related|Subversion}}
 
{{Related|Subversion}}
  +
{{Related|VCS パッケージガイドライン}}
{{Related4|Concurrent Versions System}}
 
 
{{Related articles end}}
 
{{Related articles end}}
   
15行目: 20行目:
 
== インストール ==
 
== インストール ==
   
{{Pkg|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'' でスペル チェックを有効にするには、{{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}}}}
   
 
== 基本設定 ==
 
== 基本設定 ==
33行目: 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]
   
 
他の設定については [[#高度な設定]] を見て下さい。
 
他の設定については [[#高度な設定]] を見て下さい。
38行目: 56行目:
 
== 基本的な使い方 ==
 
== 基本的な使い方 ==
   
  +
Git リポジトリは {{ic|.git}} ディレクトリに格納され、リビジョン履歴やその他のメタデータを保持します。リポジトリが追跡するディレクトリ (デフォルトでは親ディレクトリ) は、作業ディレクトリと呼ばれます。作業ツリーの変更は、リポジトリに記録 (コミット) される前にステージングされる必要があります。Git では、以前にコミットした作業ツリーのファイルを復元することもできます。
このチュートリアルでは Git によるプロジェクトの基本的な分散バージョン管理について説明します。典型的な Git のワークフローは以下の通りです:
 
   
  +
[https://git-scm.com/book/en/Getting-Started-Git-Basics Getting Started - Git Basics] を参照してください。
# 新しいプロジェクトを作成、またはリモートのプロジェクトを複製する。
 
# ブランチを作成して変更を加え、変更をコミットする。
 
# コミットを統合して上手くまとめて分かりやすくする。
 
# メインのブランチにコミットをマージする。
 
# (任意) 変更をリモートサーバーにプッシュする。
 
   
=== ローカルリポジトリ ===
+
=== Git リポジトリの取得 ===
 
==== ステージング ====
 
 
新しいリポジトリを作成:
 
 
$ 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/**
 
}}
 
 
詳しくは [http://git-scm.com/docs/gitignore gitignore(5)] を参照。
 
}}
 
   
  +
* リポジトリの初期化
ステージングからファイルを削除 ({{ic|--cached}} を付けるとファイルを実際には削除しません):
 
  +
:{{ic|git init}}, 参照 {{man|1|git-init}}
  +
* 既存のリポジトリのクローンを作成
  +
:{{ic|git clone ''repository''}}, 参照 {{man|1|git-clone}} (Git URL についても説明します)
   
  +
=== 変更の記録 ===
$ git rm ''(--cached)'' ''file''
 
   
  +
Git プロジェクトにはステージング領域があります。これは、Git ディレクトリにある {{ic|index}} ファイルで、次のコミットに反映される変更点を保存しておくものです。したがって、変更したファイルを記録するには、まずそれをインデックスに追加する (ステージングする) 必要があります。そして、{{ic|git commit}} コマンドは現在のインデックスを新しいコミットに格納します。
ファイルを全て削除:
 
   
  +
==== ステージングの変更 ====
$ git reset HEAD -- .
 
   
  +
* 作業ツリーの変更をインデックスに追加
または:
 
  +
:{{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 -r .
 
   
  +
Git はファイルの動きを追跡しません。マージ中の移動の検出は、内容の類似性のみに基づいて行われます。{{ic|git mv}} コマンドは便宜上存在するだけで、これと同等です。
ファイルの名前を変更:
 
   
$ git mv ''file1'' ''file2''
+
$ mv -i foo bar
  +
$ git reset -- foo
 
  +
$ git add bar
ファイルのリストを表示:
 
 
$ git ls-files
 
   
 
==== 変更をコミット ====
 
==== 変更をコミット ====
   
  +
{{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 コマンドは、リビジョンを引数として受け取ります。コミットは、以下のいずれかによって識別されます。
Go back and '''edit''' the commit message:
 
   
  +
* コミットの SHA-1 ハッシュ (通常、最初の7桁でコミットを一意に識別できます。)
$ git commit --amend -m "''Message.''"
 
  +
* ブランチ名やタグ名などの任意のコミット ラベル
 
  +
* ラベル {{ic|HEAD}} は常に現在チェックアウトされているコミット (通常はブランチの先頭、ただし ''git checkout'' を使って古いコミットに履歴を戻した場合は除く) を指します。
Many of the commands in this article take commits as arguments. A commit can be identified by any of the following:
 
  +
* 上記のいずれかと、前のコミットを参照するための {{ic|~}} を加えたものです。例えば、{{ic|HEAD~}} は {{ic|HEAD}} の一つ前のコミットを指し、{{ic|HEAD~5}} は {{ic|HEAD}} の五つ前のコミットを指し示します。
 
* Its 40-digit SHA-1 hash (the first 7 digits are usually sufficient to identify it uniquely)
 
* Any commit label such as a branch or tag name
 
* The label {{ic|HEAD}} always refers to the currently checked-out commit (usually the head of the branch, unless you used {{ic|git checkout}} to jump back in history to an old commit)
 
* Any of the above plus {{ic|~}} to refer to previous commits. For example, {{ic|HEAD~}} refers to one commit before {{ic|HEAD}} and {{ic|HEAD~5}} refers to five commits before {{ic|HEAD}}.
 
   
 
==== 変更を閲覧 ====
 
==== 変更を閲覧 ====
   
 
コミット間の差分を表示:
 
コミット間の差分を表示:
  +
  +
$ git diff HEAD HEAD~3
  +
  +
ステージングエリアと作業ツリーの差分を表示:
   
 
$ git diff
 
$ git diff
139行目: 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) にマージします。ブランチを作成するときは、目的に適った名前を付けて下さい:
162行目: 160行目:
 
$ git merge ''branch''
 
$ git merge ''branch''
   
  +
変更が衝突しない場合はマージされます。衝突する場合は衝突箇所が記録されます。{{ic|git diff}} を使ってどこで衝突しているのか確認することができるので、手動で衝突の解消をする必要があります。
The changes will be merged if they do not conflict. If they do, the conflicts will be recorded. What is causing the conflicts can been seen with {{ic|git diff}}, then conflict resolution will need to be done manually.
 
   
  +
ブランチが不要になったら、次のコマンドで''削除''します:
When done with a branch, '''delete''' it with:
 
   
 
$ git branch -d ''branch''
 
$ git branch -d ''branch''
170行目: 168行目:
 
=== 共同作業 ===
 
=== 共同作業 ===
   
==== エチケット ====
+
==== プルリクト ====
   
  +
変更を加えてコミットしたら、ソフトウェアの作者にマージするように要求することができます。これを ''プルリクエスト'' と呼びます。
* When considering contributing to an existing project, read and understand its license, as it may excessively limit your ability to change the code. Some licenses can generate disputes over the ownership of the code.
 
* Think about the project's community and how well you can fit into it. To get a feeling of the direction of the project, read any documentation and even the [[#History and versioning|log]] of the repository.
 
* When requesting to pull a commit, or submit a patch, keep it small and well documented; this will help the maintainers understand your changes and decide whether to merge them or ask you to make some amendments.
 
* If a contribution is rejected, do not get discouraged, it is their project after all. If it is important, discuss the reasoning for the contribution as clearly and as patiently as possible: with such an approach a resolution may eventually be possible.
 
 
==== リポジトリを複製 ====
 
 
To begin contributing to a project, '''clone''' its repository:
 
 
$ git clone ''location'' ''folder''
 
 
{{ic|''location''}} can be either a path or network address. Also, when cloning is done, the location is recorded so just a {{ic|git pull}} will be needed later.
 
 
==== プルリクエスト ====
 
   
  +
pull するには:
After making and committing some changes, the contributor can ask the original author to merge them. This is called a ''pull request''. To '''pull''':
 
   
 
$ git pull ''location'' master
 
$ git pull ''location'' master
   
  +
''pull'' コマンドは ''fetch'' と ''merge'' の組み合わせです。衝突があった場合 (例えば同じ時間帯にソフトウェアの作者が変更を加えた場合)、手動で解消する必要があります。
The ''pull'' command combines both ''fetching'' and ''merging''. If there are conflicts (e.g. the original author made changes in the same time span), then it will be necessary to manually fix them.
 
   
  +
もしくは、オリジナルの作者は取り込みたい変更を '''pick''' することができます。''fetch'' オプションを使って (そして ''log'' オプションで特殊な {{ic|FETCH_HEAD}} 記号を使用)、プルリクエストの中身を表示してから何をするか決められます:
Alternatively, the original author can '''pick''' the '''changes''' wanting to be incorporated. Using the ''fetch'' option (and ''log'' option with a special {{ic|FETCH_HEAD}} symbol), the contents of the pull request can be viewed before deciding what to do:
 
   
 
$ git fetch ''location'' master
 
$ git fetch ''location'' master
201行目: 186行目:
 
==== リモートの使用 ====
 
==== リモートの使用 ====
   
  +
リモートは追跡しているリポジトリです。''label'' で場所を定義します。大抵は頻繁にアクセスするリポジトリで使われます。リモートを作成:
Remotes are tracked repositories, a ''label'' defining a location. They are commonly used for frequently accessed repositories. '''Create''' a remote:
 
   
 
$ git remote add ''label'' ''location''
 
$ git remote add ''label'' ''location''
   
  +
リモートを取得:
'''Fetch''' a remote:
 
   
 
$ git fetch ''label''
 
$ git fetch ''label''
   
  +
マスターとリモートのマスターの変更点を表示:
'''Show differences''' between master and a remote master:
 
   
 
$ git log -p master..''label''/master
 
$ git log -p master..''label''/master
   
  +
現在のリポジトリのリモートを表示:
'''View''' remotes for the current repository:
 
   
 
$ git remote -v
 
$ git remote -v
   
  +
フォーク元 (先行プロジェクト) のリモートを定義するときは ''upstream'' として定義します。
When defining a remote that is a parent of the fork (the project lead), it is defined as ''upstream''.
 
   
 
==== リポジトリにプッシュ ====
 
==== リポジトリにプッシュ ====
   
  +
ソフトウェアの作者から権限を与えられたら、変更を '''push''' することができます:
After being given rights from the original authors, '''push''' changes with:
 
   
 
$ git push ''location'' ''branch''
 
$ git push ''location'' ''branch''
   
  +
{{ic|git clone}} が実行されると、オリジナルの URL が記録され {{ic|origin}} というリモート名が与えられます。大抵の場合は以下のようにしてプッシュできます:
When {{ic|git clone}} is performed, it records the original location and gives it a remote name of {{ic|origin}}. So what '''typically''' is done is this:
 
   
 
$ git push origin master
 
$ git push origin master
   
If the {{ic|--set-upstream}} option is used, the location is recorded so the next time just a {{ic|git push}} is necessary.
+
{{ic|-u}} ({{ic|--set-upstream-to}}) オプションを使用すると、位置が記録されて次回からは {{ic|git push}} だけでも実行できます。
   
 
==== マージの対処 ====
 
==== マージの対処 ====
   
See [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging#Basic-Merge-Conflicts Basic Merge Conflicts] in the Git Book for a detailed explanation on how to resolve merge conflicts. Merges are generally reversible. If wanting to back out of a merge one can usually use the {{ic|--abort}} command (e.g. {{ic|git merge --abort}} or {{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}})
 
==== メーリングリストにパッチを送信 ====
 
 
If you want to send patches directly to a mailing list, you have to install the following packages: {{Pkg|perl-authen-sasl}}, {{Pkg|perl-net-smtp-ssl}} and {{Pkg|perl-mime-tools}}.
 
 
Make sure you have configured you username and e-mail address, see [[#Basic configuration]].
 
 
'''Configure''' your '''e-mail''' settings:
 
 
$ 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''
 
 
Now you should be able to '''send''' the '''patch''' to the mailing list (see also [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
 
   
 
=== 履歴とバージョニング ===
 
=== 履歴とバージョニング ===
258行目: 224行目:
 
==== 履歴の検索 ====
 
==== 履歴の検索 ====
   
  +
{{ic|git log}} では履歴とコミットのチェックサムや作者、日付、ショートメッセージを表示します。チェックサムはコミットオブジェクトのオブジェクト名であり、通常は40文字の SHA-1 ハッシュになります。履歴とロングメッセージを表示するには ("''checksum''" は一意であるかぎり短く省略できます):
{{ic|git log}} will give the history with a commit checksum, author, date, and the short message. For '''history''' with a '''long message''' (where the "''checksum''" can be truncated, as long as it is unique):
 
   
 
$ git show (''checksum'')
 
$ git show (''checksum'')
   
  +
追跡されているファイルをパターン検索:
'''Search''' for ''pattern'' in tracked files:
 
   
 
$ git grep ''pattern''
 
$ git grep ''pattern''
   
'''Search''' in '''{{ic|.c}}''' and '''{{ic|.h}}''' files:
+
'''{{ic|.c}}''' '''{{ic|.h}}''' ファイルを検索:
   
 
$ git grep ''pattern'' -- '*.[ch]'
 
$ git grep ''pattern'' -- '*.[ch]'
   
==== バージョニンとリリース ====
+
==== 付け ====
   
  +
コミットにタグを付ける:
'''Tag''' commits for versioning:
 
   
 
$ git tag 2.14 ''checksum''
 
$ git tag 2.14 ''checksum''
   
  +
タグは一般的に [https://www.drupal.org/node/1066342 リリースやバージョニング] するときに付けられますが文字列は何でもかまいません。通常は Git データベースに追加される注釈付きタグが用いられます。最新のコミットにタグを付けるには:
''Tagging'' is generally done for [https://www.drupal.org/node/1066342 releasing/versioning] but it can be any string. Generally annotated tags are used, because they get added to the Git database. '''Tag''' the '''current''' commit with:
 
   
 
$ git tag -a 2.14 -m "Version 2.14"
 
$ git tag -a 2.14 -m "Version 2.14"
   
  +
タグを確認:
'''List''' tags:
 
   
 
$ git tag -l
 
$ git tag -l
   
  +
タグを削除:
'''Delete''' a tag:
 
   
 
$ git tag -d 2.08
 
$ git tag -d 2.08
   
  +
タグを更新:
'''Update remote''' tags with a separate:
 
   
 
$ git push --tags
 
$ git push --tags
294行目: 260行目:
 
==== コミットの修正 ====
 
==== コミットの修正 ====
   
  +
プルリクエストを送信する前に、コミットを整理・統合するのが望ましいことがあります。{{ic|git rebase}} のインタラクティブオプションを使います:
Before submitting a pull request it may be desirable to '''consolidate/organize''' the commits. This is done with the {{ic|git rebase}} interactive option:
 
   
 
$ git rebase -i ''checksum''
 
$ git rebase -i ''checksum''
   
  +
コマンドを実行すると指定された範囲のコミットが全てエディタで開かれます。上記の場合、最新のコミット ({{ic|HEAD}}) から {{ic|''checksum''}} コミットまでが開かれます。数字で指定する場合、例えば {{ic|HEAD~3}} なら最後の3つのコミットがリベースされます:
This will open the editor with a summary of all the commits in the range specified; in this case including the newest ({{ic|HEAD}}) to, but excluding, {{ic|''checksum''}}. Or to use a number notation, use for example {{ic|HEAD~3}}, which will rebase the last three commits:
 
   
 
pick d146cc7 Mountpoint test.
 
pick d146cc7 Mountpoint test.
304行目: 270行目:
 
pick 8a4d479 Rename documentation.
 
pick 8a4d479 Rename documentation.
   
  +
最初のカラムに rebase で実行する動作を記述します。以下から選んでください:
Editing the action in the first column will dictate how the rebase will be done. The options are:
 
   
* {{ic|pick}} — Apply this commit as is (the default).
+
* {{ic|pick}} — コミットをそのまま適用します。(デフォルト)
* {{ic|edit}} — Edit files and/or commit message.
+
* {{ic|edit}} — ファイルやコミットメッセージを編集。
* {{ic|reword}} — Edit commit message.
+
* {{ic|reword}} — コミットメッセージを編集。
* {{ic|squash}} — Merge/fold into previous commit.
+
* {{ic|squash}} — 前のコミットにマージ。
* {{ic|fixup}} — Merge/fold into previous commit discarding its message.
+
* {{ic|fixup}} — 前のコミットにマージ。メッセージは破棄。
   
  +
コミットの順番を変えたり履歴から消去することが可能です (ただし注意して操作してください)。ファイルの編集後、Git は指示された作業を実施します。マージ時の問題を解決するように要求された場合、修正してから {{ic|git rebase --continue}} で続行するか、{{ic|git rebase --abort}} コマンドで中止してください。
The commits can be re-ordered or erased from the history (but be very careful with these). After editing the file, Git will perform the specified actions; if prompted to resolve merge problems, fix them and continue with {{ic|git rebase --continue}} or back out with the {{ic|git rebase --abort}} command.
 
   
  +
{{Note|コミットの squash はローカルコミットでのみ使います。他人と共有しているリポジトリで使うと問題が発生します。}}
{{Note|Squashing commits is only used for local commits, it will cause troubles on a repository that is shared by other people.}}
 
   
  +
== ヒントとテクニック ==
== 高度な設定 ==
 
   
  +
=== git-config の使用 ===
Git は INI タイプの設定ファイルから設定を読み込みます:
 
   
  +
Git は、4つの INI タイプの設定ファイルからその構成を読み取ります。
* 各リポジトリにはリポジトリごとの設定を記述した {{ic|.git/config}} ファイルが含まれます。
 
* 各ユーザーの {{ic|$HOME/.gitconfig}} ファイルがフォールバックとして使われます。
 
* システム全体のデフォルト設定としては {{ic|/etc/gitconfig}} が使われます。
 
   
  +
* {{ic|/etc/gitconfig}} システム全体のデフォルト
These files can be edited directly, but the usual method is to use {{ic|git config}}, as shown in the examples below.
 
  +
* {{ic|~/.gitconfig}} と {{ic|~/.config/git/config}} (since 1.7.12) ユーザー固有の設定用
  +
* {{ic|.git/config}} リポジトリ固有の設定用
   
  +
これらのファイルは直接編集できますが、通常の方法は、以下の例に示すように ''git config'' を使用することです。
List the currently set variables:
 
  +
  +
現在設定されている変数を一覧表示します。
   
 
$ git config {--local,--global,--system} --list
 
$ git config {--local,--global,--system} --list
   
Set the default editor from [[vim]] to [[nano]]:
+
デフォルトのエディターを [[vim]] から [[nano]] に設定します。
   
 
$ git config --global core.editor "nano -w"
 
$ git config --global core.editor "nano -w"
   
  +
デフォルトのプッシュアクションを設定します。
Set the default push action:
 
   
 
$ git config --global push.default simple
 
$ git config --global push.default simple
   
  +
''git difftool'' に別のツールを設定します (デフォルトでは ''meld''):
Set a different tool for {{ic|git difftool}} (''meld'' by default):
 
   
 
$ git config --global diff.tool vimdiff
 
$ git config --global diff.tool vimdiff
   
See [https://www.kernel.org/pub/software/scm/git/docs/git-config.html git-config(1)] and [http://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration Git Configuration] for more information.
+
詳細については、{{man|1|git-config}} および [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration Git 構成] を参照してください。
   
  +
=== 良いエチケットを採用する ===
=== SSH の高速化 ===
 
   
  +
* 既存のプロジェクトに貢献することを検討する場合、コードを変更する能力を過度に制限する可能性があるため、そのライセンスを読んで理解してください。ライセンスによっては、コードの所有権をめぐって紛争を引き起こす可能性があります。
Often if you find yourself pushing constantly to a few common servers, you may wish to remove the hassle of setting your username for each repository.
 
  +
* プロジェクトのコミュニティと、自分がそこにどれだけ溶け込めるかを考えましょう。プロジェクトの方向性を知るために、あらゆるドキュメントや、リポジトリの [[#History and versioning|log]] を読んでください。
  +
* コミットをプルしたり、パッチを提出したりするときは、小規模で十分な文書化を心がけましょう。そうすることで、メンテナがあなたの変更を理解し、マージするか修正を依頼するかを判断しやすくなります。
  +
* もし、投稿が拒否されても、落ち込まないでください。重要なことであれば、その理由をできるだけ明確に、忍耐強く議論してください。
   
  +
=== 認証の高速化 ===
If you do not already have the keys created, make them now.
 
   
  +
Git サーバーにプッシュする度に認証が面倒なのをなんとかしたいと思っている場合、以下を使って下さい。
$ ssh-keygen -N ’’ -b 4096 -t rsa -f ~/.ssh/aur -C "''user@domain.com''"
 
$ ssh-keygen -N ’’ -b 4096 -t rsa -f ~/.ssh/github -C "''user@domain.com''"
 
   
  +
* SSH 鍵を使って認証している場合、[[SSH 鍵#SSH エージェント|SSH エージェント]]を使って下さい。[[SSH#SSH の高速化]] や [[SSH#Keep alive]] も参照。
Add the resulting public keys to your accounts.
 
  +
* ユーザー名とパスワードを使って認証している場合、サーバーが 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 を認証情報ヘルパーとして使用する ===
Additionally, reusing the same SSH connection will drastically improve the time {{ic|git push}} takes.
 
   
  +
Git は [[GNOME/Keyring]] や [[KeePass]] のような org.freedesktop.secrets と互換性のあるキーリングから認証情報を取得することがあります。そのため、互換性のあるキーリングを一つセットアップし、キーリングが dbus に登録されているかどうかを確認します。
$ mkdir -p ~/.ssh/sockets/
 
   
  +
dbus-send --session --print-reply --dest=org.freedesktop.DBus / \
You may wish to adjust the {{ic|ServerAliveInterval}} depending on your connection.
 
  +
org.freedesktop.DBus.GetConnectionUnixProcessID \
  +
string:org.freedesktop.secrets
   
  +
実行
{{hc|~/.ssh/config|
 
Host *
 
ControlMaster auto
 
ControlPath ~/.ssh/sockets/%r@%h-%p
 
ControlPersist 8760h
 
'''ServerAliveInterval 5'''
 
ServerAliveCountMax 1
 
TCPKeepAlive yes
 
   
  +
git config --global credential.helper /usr/lib/git-core/git-credential-libsecret
Host aur-dev.archlinux.org
 
IdentityFile ~/.ssh/aur
 
User aur
 
Port 2222
 
   
  +
その後 git をセットアップします。
Host github.com
 
IdentityFile ~/.ssh/github
 
User [username here]
 
}}
 
   
  +
=== 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}} ファイルを [[作成]] します。
If you are running a multiplexed SSH connection as shown above, Git over SSH might be faster than HTTPS. Also, you will not have to enter your password on every push until your multiplexed connection goes down (and only if there is a passphrase on it). For example, the following config will set Git over SSH for any repository hosted on GitHub.
 
   
{{hc|~/.gitconfig|
+
{{hc|~/.netrc|
  +
machine git-host
[url "ssh://git@github.com/"]
 
  +
login username
insteadOf = https://github.com/
 
  +
password password
insteadOf = http://github.com/
 
insteadOf = git://github.com/
 
 
}}
 
}}
   
  +
認証情報ヘルパーは [[gpg]] で暗号化されたファイル ({{ic|~/.netrc.gpg}}) もサポートします。
Optionally, the Git protocol could be used for pulling instead.
 
   
  +
=== デフォルトプロトコル ===
{{Warning|There is absolutely no encryption or verification with the server using the Git protocol by itself. Please be careful with software after obtaining through this method.}}
 
   
  +
上述のように SSH で多重接続することで、Git over SSH の方が HTTPS よりも高速になります。また、(AUR など) サーバーによっては SSH を介して push することもできます。例えば、以下の設定をすると AUR でホストされているリポジトリで Git over SSH を設定します。
{{hc|~/.gitconfig|
 
[url "ssh://git@github.com/"]
 
pushInsteadOf = https://github.com/
 
[url "git://github.com/"]
 
insteadOf = https://github.com/
 
insteadOf = http://github.com/
 
}}
 
   
  +
{{hc|~/.gitconfig|<nowiki>
{{Note|Some corporate firewalls block port 9418/TCP, which the Git protocol uses. In those situations, Git over SSH or HTTPS will likely be the best option.}}
 
  +
[url "ssh://aur@aur.archlinux.org/"]
  +
insteadOf &#61; https://aur.archlinux.org/
  +
insteadOf &#61; http://aur.archlinux.org/
  +
insteadOf &#61; git://aur.archlinux.org/
  +
</nowiki>}}
   
 
=== Bash 補完 ===
 
=== Bash 補完 ===
   
In order to enable Bash completion, source {{ic|/usr/share/git/completion/git-completion.bash}} in a [[Bash#Configuration_files|Bash startup file]]. Alternatively, install {{pkg|bash-completion}}.
+
Bash の補完を有効にするには、[[Bash#設定ファイル|Bash のスタートアップファイル]]で {{ic|/usr/share/git/completion/git-completion.bash}} source してください。もしくは、{{pkg|bash-completion}} をインストールしてください。
   
 
=== Git プロンプト ===
 
=== Git プロンプト ===
   
  +
Git パッケージにはプロンプトスクリプトが付属しています。これを有効にするには、{{ic|/usr/share/git/completion/git-prompt.sh}} をソースし、{{ic|%s}} パラメータを使用してカスタムプロンプトを設定します。
The Git package comes with a prompt script. To enable it, source the {{ic|/usr/share/git/completion/git-prompt.sh}} script in a [[Autostarting#Shells|shell startup file]], then set a custom prompt with the {{ic|%s}} parameter:
 
   
 
* [[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 リポジトリのディレクトリに変更すると、プロンプトが変化してブランチ名が表示されます。対応する環境変数を設定することで、追加の詳細がプロンプトに表示されるように設定できます。
When changing to a directory of a Git repository, the prompt will change to show the branch name. Extra details can be set to be shown by the prompt:
 
   
 
{| class="wikitable"
 
{| class="wikitable"
 
|+
 
|+
! Shell variable !! Information
+
! シェル変数 !! 情報
 
|-
 
|-
| GIT_PS1_SHOWDIRTYSTATE || '''+''' for staged, '''*''' if unstaged.
+
| GIT_PS1_SHOWDIRTYSTATE || ステージ済みの場合は '''+'''、未ステージの場合は '''*'''
 
|-
 
|-
| GIT_PS1_SHOWSTASHSTATE || '''$''' if something is stashed.
+
| GIT_PS1_SHOWSTASHSTATE || スタッシュが存在する場合は '''$'''
 
|-
 
|-
| GIT_PS1_SHOWUNTRACKEDFILES || '''%''' if there are untracked files.
+
| GIT_PS1_SHOWUNTRACKEDFILES || 追跡されていないファイルが存在する場合は '''%'''
 
|-
 
|-
| GIT_PS1_SHOWUPSTREAM || '''<,>,<>''' behind, ahead, or diverged from upstream.
+
| GIT_PS1_SHOWUPSTREAM || 上流からの進み・戻り・分岐 ('''<,>,<>''')
  +
|-
  +
| GIT_PS1_STATESEPARATOR || ブランチ名と状態記号の間の区切り文字
  +
|-
  +
| GIT_PS1_DESCRIBE_STYLE || HEAD が切り離されている場合、タグまたはブランチに関連するコミットを表示します
  +
|-
  +
| GIT_PS1_SHOWCOLORHINTS || カラーで表示する
 
|}
 
|}
   
  +
環境変数の完全なドキュメントは、スクリプトのコメントで参照できます。
{{ic|GIT_PS1_SHOWUPSTREAM}} will need to be set to {{ic|auto}} for changes to take effect.
 
   
  +
{{Note|
{{Note|If you experience that {{ic|$(__git_ps1)}} returns {{ic|((unknown))}}, then there is a {{ic|.git}} folder in your current directory which does not contain any repository, and therefore Git does not recognize it. This can, for example, happen if you mistake Git's configuration file to be {{ic|~/.git/config}} instead of {{ic|~/.gitconfig}}.}}
 
  +
* {{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 シェルプロンプトのカスタマイズパッケージを利用することもできます。
== 高度な使い方 ==
 
   
  +
=== ビジュアル表現 ===
変更量を視覚的に表示するには:
 
  +
  +
作業量を把握するため:
   
 
$ git diff --stat
 
$ git diff --stat
   
{{ic|git log}} with forking representation:
+
''git log'' をフォーク表現:
   
 
$ git log --graph --oneline --decorate
 
$ git log --graph --oneline --decorate
   
  +
''git log'' グラフのエイリアス (つまり ''git graph'' は装飾されたバージョンを表示する):
{{ic|git log}} graph alias (i.e. {{ic|git graph}} will show a decorated version):
 
   
 
$ git config --global alias.graph 'log --graph --oneline --decorate'
 
$ git config --global alias.graph 'log --graph --oneline --decorate'
   
  +
=== コミットのヒント ===
Reset to previous commit (very dangerous, erases everything to specified commit):
 
  +
  +
前のコミットにリセット (非常に危険、指定したコミットまですべて消去されます):
   
 
$ git reset --hard HEAD^
 
$ git reset --hard HEAD^
   
  +
リポジトリのアドレスが変更された場合、そのリモートロケーションを更新する必要があります:
If a repository address gets changed, its remote location will need to be updated:
 
   
 
$ git remote set-url origin git@''address'':''user''/''repo''.git
 
$ git remote set-url origin git@''address'':''user''/''repo''.git
   
  +
あるいは、{{ic|.git/config}} を編集して新しい場所を指定します。
Signed-off-by line append (a name-email signature is added to the commit which is required by some projects):
 
   
  +
Signed-off-by line append (プロジェクトによっては必要な、名前と電子メールの署名がコミットに追加されます):
$ git commit -s
 
   
  +
$ git commit -s
Signed-off-by automatically append to patches (when using {{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
   
  +
変更されたファイルの特定の部分をコミットします。これは、多数の変更があり、複数のコミットに分けたほうがよい場合に有用です。
Commit specific parts of files that have changed. This is useful if there are a large number of changes made that would be best split into several commits:
 
   
 
$ 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
   
 
=== マスター以外のブランチで作業 ===
 
=== マスター以外のブランチで作業 ===
   
  +
ときに、メンテナからブランチで作業するように要求されることがあります。使われるブランチの名前は {{ic|devel}} や {{ic|testing}} などが一般的です。まずはリポジトリを複製します。
Occasionally a maintainer will ask that work be done on a branch. These branches are often called {{ic|devel}} or {{ic|testing}}. Begin by cloning the repository.
 
   
To enter another branch beside master ({{ic|git clone}} only shows master branch but others still exist, {{ic|git branch -a}} to show):
+
master 以外のブランチを開くには ({{ic|git clone}} master ブランチしか表示されない場合、{{ic|git branch -a}} で他のブランチを表示できます):
   
 
$ git checkout -b ''branch'' origin/''branch''
 
$ git checkout -b ''branch'' origin/''branch''
   
  +
通常通り編集を行ってください。ただし以下のコマンドを使ってリポジトリツリーを同期させてください:
Now edit normally; however to keep the repository tree in sync be sure to use both:
 
   
 
$ git pull --all
 
$ git pull --all
 
$ 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''
With SSH working and a key generated, paste the contents of {{ic|~/.ssh/id_rsa.pub}} to {{ic|~/.ssh/authorized_keys}} (be sure it is all on one line). Now the Git repository can be accessed with SSH by doing:
 
  +
$ 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''
You should now get an SSH yes/no question, if you have the SSH client setting {{ic|StrictHostKeyChecking}} set to {{ic|ask}} (the default). Type {{ic|yes}} followed by {{ic|Enter}}. Then you should have your repository checked out. Because this is with SSH, you also have commit rights now.
 
  +
$ git commit -s
  +
$ git send-email --to=''openembedded-core@lists.openembedded.org'' --confirm=always -M -1
   
  +
=== 大規模な git リポジトリの操作 ===
To modify an existing repository to use SSH, the remote location will need to be redefined:
 
   
  +
大規模なリモートリポジトリを操作する場合、大量のデータをフェッチする必要があります。次の例では、Linux カーネルを使用して、そのようなコードベースを操作する方法を示しています。
$ git remote set-url origin git@localhost:''my_repository''.git
 
   
  +
==== リポジトリ全体を取得する ====
Connecting on a port other than 22 can be configured on a per-host basis in {{ic|/etc/ssh/ssh_config}} or {{ic|~/.ssh/config}}. To set up ports for a repository, if the repository is in {{ic|~/}} and using 443 for the port:
 
   
  +
最も簡単な解決策は、リポジトリ全体を取得することです。
{{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 is able to use the HTTP(S) protocol as efficiently as the SSH or Git protocols, by utilizing the git-http-backend. Furthermore it is not only possible to clone or pull from repositories, but also to push into repositories over HTTP(S).
 
   
  +
{{ic|git pull}} でリポジトリを更新できます。
The setup for this is rather simple as all you need to have installed is the Apache web server ({{pkg|apache}}, with {{ic|mod_cgi}}, {{ic|mod_alias}}, and {{ic|mod_env}} enabled) and of course, {{pkg|git}}.
 
   
  +
==== リポジトリの部分的な取得 ====
Once you have your basic setup running, add the following to your Apache configuration file, which is usually located at:
 
   
  +
ローカルリポジトリをオリジンのより小さなサブセットに制限するには、たとえば v4.14 以降でバグを二分するために、浅いクローンを使用します。
{{hc|/etc/httpd/conf/httpd.conf|
 
  +
<Directory "/usr/lib/git-core*">
 
  +
$ git clone --shallow-exclude v4.13 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Require all granted
 
  +
</Directory>
 
  +
v4.14 以降は入手できますが、v4.13 以前は入手できません。
 
  +
SetEnv GIT_PROJECT_ROOT /srv/git
 
  +
すべての履歴を無視して、最新のスナップショットのみが必要な場合。(tarball が利用可能で、それで十分な場合は、それを選択してください。git リポジトリからダウンロードするには、より多くの帯域幅が必要です。) 次の方法で取得できます。
SetEnv GIT_HTTP_EXPORT_ALL
 
  +
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
 
  +
$ 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
  +
  +
{{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}} で利用可能です。
   
  +
=== 機密情報のフィルタリング ===
This assumes your Git repositories are located at {{ic|/srv/git}} and that you want to access them via something like: {{ic|<nowiki>http(s)://your_address.tld/git/your_repo.git</nowiki>}}.
 
   
  +
時には、ソフトウェアが平文のパスワードを設定ファイルに保存し、キーリングに接続するのとは対照的にすることがあります。このような場合、git clean-filters は機密情報を誤ってコミットしてしまうのを防ぐために便利です。たとえば、次のファイルでは "some-dotfile" というファイルにフィルタを割り当てています。
{{Note|Make sure that Apache can read and write to your repositories.}}
 
   
  +
{{hc|.gitattributes|<nowiki>
For more detailed documentation, visit the following links:
 
  +
some-dotfile filter=remove-pass
* http://progit.org/2010/03/04/smart-http.html
 
  +
</nowiki>}}
* https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-http-backend.html
 
   
  +
"some-dotfile" というファイルが git にチェックインされると、git はチェックイン前にこのファイルに対して "remove-pass" というフィルタを実行します。このフィルターは、git-configuration ファイルで定義しておく必要があります。
=== Git ===
 
   
  +
{{hc|.git/config|<nowiki>
{{Note|Git プロトコルでは読み取りアクセスだけが許可されます。}}
 
  +
[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 ヘルプファイル ===
The daemon is started with the following options:
 
   
  +
{{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
Repositories placed in {{ic|/srv/git/}} will be recognized by the daemon. Clients can connect with something similar to:
 
   
  +
{{ic|git config}} オプションを設定すると、デフォルトで HTML ドキュメントを読み込むことができます。
$ git clone git://''location''/''repository''.git
 
   
  +
$ git config --global help.format html
=== アクセス権限の設定 ===
 
   
  +
== 拡張機能 ==
To restrict read and/or write access, use standard Unix permissions. Refer to 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]) for more information.
 
   
  +
* {{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]] や [[en2:gitosis|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}}}}
   
 
== 参照 ==
 
== 参照 ==
   
* [http://git-scm.com/book Pro Git book]
+
* [https://git-scm.com/book Pro Git book]
 
* [http://gitref.org/ Git Reference]
 
* [http://gitref.org/ Git Reference]
 
* https://www.kernel.org/pub/software/scm/git/docs/
 
* https://www.kernel.org/pub/software/scm/git/docs/
561行目: 590行目:
 
* [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests Git overall2]
 
* [http://nathanhoad.net/git-workflow-forks-remotes-and-pull-requests Git overall2]
 
* https://wiki.videolan.org/Git
 
* https://wiki.videolan.org/Git
* [https://gist.github.com/grawity/4392747 A comparison of protocols offered by GitHub]
+
* [https://gist.github.com/grawity/4392747 GitHub が用意しているプロトコルの比較]

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

参照