「Git」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎基本設定: 情報を更新)
(5人の利用者による、間の13版が非表示)
1行目: 1行目:
 
[[Category:バージョン管理システム]]
 
[[Category:バージョン管理システム]]
  +
[[Category:コマンド]]
 
[[en:Git]]
 
[[en:Git]]
[[zh-CN: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|Cgit}}
 
{{Related|Cgit}}
{{Related3|HTTP tunneling#Tunneling Git|HTTP トンネリング#Git のトンネリング}}
+
{{Related|HTTP トンネリング#Git のトンネリング}}
 
{{Related|Subversion}}
 
{{Related|Subversion}}
{{Related4|Concurrent Versions System}}
+
{{Related|Concurrent Versions System}}
 
{{Related articles end}}
 
{{Related articles end}}
   
15行目: 18行目:
 
== インストール ==
 
== インストール ==
   
{{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行目: 47行目:
 
$ 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]
   
 
他の設定については [[#高度な設定]] を見て下さい。
 
他の設定については [[#高度な設定]] を見て下さい。
76行目: 92行目:
 
}}
 
}}
   
詳しくは [http://git-scm.com/docs/gitignore gitignore(5)] を参照。
+
詳しくは [https://git-scm.com/docs/gitignore gitignore(5)] を参照。
 
}}
 
}}
   
85行目: 101行目:
 
ファイルを全て削除:
 
ファイルを全て削除:
   
$ git reset HEAD -- .
+
$ git rm --cached -r .
   
 
または:
 
または:
   
$ git rm --cached -r .
+
$ git reset HEAD -- .
  +
  +
上記の {{ic|HEAD}} は現在の版の「シンボル参照」です。
   
 
ファイルの名前を変更:
 
ファイルの名前を変更:
98行目: 116行目:
   
 
$ git ls-files
 
$ git ls-files
  +
  +
上記のコマンドはデフォルトでステージングエリアのファイルを表示します ({{ic|--cached}} ファイル)。
   
 
==== 変更をコミット ====
 
==== 変更をコミット ====
128行目: 148行目:
   
 
コミット間の差分を表示:
 
コミット間の差分を表示:
  +
  +
$ git diff HEAD HEAD~3
  +
  +
ステージングエリアと作業ツリーの差分を表示:
   
 
$ git diff
 
$ git diff
175行目: 199行目:
 
* プロジェクトのコミュニティを観測してどうやったら適合できるか考えましょう。プロジェクトの方向性を理解するために、ドキュメントやリポジトリの[[#履歴とバージョニング|ログ]]を読むのも大切です。
 
* プロジェクトのコミュニティを観測してどうやったら適合できるか考えましょう。プロジェクトの方向性を理解するために、ドキュメントやリポジトリの[[#履歴とバージョニング|ログ]]を読むのも大切です。
 
* コミットを pull するようにリクエストしたり、パッチを送るときは、できるかぎりパッチを短くして説明を付加するようにしましょう。メンテナがあなたの変更箇所を理解するための手助けとなり、マージするか、もしくは修正を加えるよう要求すべきか判断する基準にもなります。
 
* コミットを pull するようにリクエストしたり、パッチを送るときは、できるかぎりパッチを短くして説明を付加するようにしましょう。メンテナがあなたの変更箇所を理解するための手助けとなり、マージするか、もしくは修正を加えるよう要求すべきか判断する基準にもなります。
  +
* リジェクトされたとしても、落胆する必要はありません。所詮他人のプロジェクトです。リクエストが重要な場合、出来るかぎり分かりやすく根気よくリクエストの理由を説明しましょう。いつかは解決に導かれるはずです。
* 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.
 
   
 
==== リポジトリを複製 ====
 
==== リポジトリを複製 ====
   
  +
プロジェクトへの貢献を始めるには、まずリポジトリを ''clone'' します:
To begin contributing to a project, '''clone''' its repository:
 
   
 
$ git clone ''location'' ''folder''
 
$ git clone ''location'' ''folder''
   
  +
{{ic|''location''}} はパスでもネットワークアドレスでもかまいません。また、複製が完了すると場所が記録されるので、{{ic|git pull}} だけで複製できるようになります。
{{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行目: 225行目:
 
==== リモートの使用 ====
 
==== リモートの使用 ====
   
  +
リモートは追跡しているリポジトリです。''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}} だけでも実行できます。
   
 
==== マージの対処 ====
 
==== マージの対処 ====
   
  +
マージの衝突を解決する方法は 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}})。
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}}).
 
   
 
==== メーリングリストにパッチを送信 ====
 
==== メーリングリストにパッチを送信 ====
258行目: 282行目:
 
==== 履歴の検索 ====
 
==== 履歴の検索 ====
   
  +
{{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]'
272行目: 296行目:
 
==== バージョニングとリリース ====
 
==== バージョニングとリリース ====
   
  +
コミットにタグを付ける:
'''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行目: 318行目:
 
==== コミットの修正 ====
 
==== コミットの修正 ====
   
  +
プルリクエストを送信する前に、コミットを整理・統合するのが望ましいことがあります。{{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行目: 328行目:
 
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.}}
 
   
 
== 高度な設定 ==
 
== 高度な設定 ==
324行目: 348行目:
 
* システム全体のデフォルト設定としては {{ic|/etc/gitconfig}} が使われます。
 
* システム全体のデフォルト設定としては {{ic|/etc/gitconfig}} が使われます。
   
  +
上記のファイルは直接編集できますが、通常は下の例にあるように {{ic|git config}} を使います。
These files can be edited directly, but the usual method is to use {{ic|git config}}, as shown in the examples below.
 
   
  +
現在設定されている変数を確認:
List the currently set variables:
 
   
 
$ git config {--local,--global,--system} --list
 
$ git config {--local,--global,--system} --list
334行目: 358行目:
 
$ 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
342行目: 366行目:
 
$ 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.
+
詳しくは [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] を見て下さい。
   
=== SSH の高速化 ===
+
=== 認証の高速化 ===
   
  +
Git サーバーにプッシュする度に認証が面倒なのをなんとかしたいと思っている場合、以下を使って下さい。
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.
 
   
  +
* SSH 鍵を使って認証している場合、[[SSH 鍵#SSH エージェント|SSH エージェント]]を使って下さい。[[SSH#SSH の高速化]] や [[SSH#Keep alive]] も参照。
If you do not already have the keys created, make them now.
 
  +
* ユーザー名とパスワードを使って認証している場合、サーバーが 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-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''"
 
 
Add the resulting public keys to your accounts.
 
 
Additionally, reusing the same SSH connection will drastically improve the time {{ic|git push}} takes.
 
 
$ mkdir -p ~/.ssh/sockets/
 
 
You may wish to adjust the {{ic|ServerAliveInterval}} depending on your connection.
 
 
{{hc|~/.ssh/config|
 
Host *
 
ControlMaster auto
 
ControlPath ~/.ssh/sockets/%r@%h-%p
 
ControlPersist 8760h
 
'''ServerAliveInterval 5'''
 
ServerAliveCountMax 1
 
TCPKeepAlive yes
 
 
Host aur-dev.archlinux.org
 
IdentityFile ~/.ssh/aur
 
User aur
 
Port 2222
 
 
Host github.com
 
IdentityFile ~/.ssh/github
 
User [username here]
 
}}
 
   
 
=== デフォルトプロトコル ===
 
=== デフォルトプロトコル ===
   
  +
上述のように SSH で多重接続することで、Git over SSH の方が HTTPS よりも高速になります。また、(AUR など) サーバーによっては SSH を介して push することもできます。例えば、以下の設定をすると AUR でホストされているリポジトリで Git over SSH を設定します。
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|~/.gitconfig|<nowiki>
[url "ssh://git@github.com/"]
+
[url "ssh://aur@aur.archlinux.org/"]
insteadOf &#61; https://github.com/
+
insteadOf &#61; https://aur.archlinux.org/
insteadOf &#61; http://github.com/
+
insteadOf &#61; http://aur.archlinux.org/
insteadOf &#61; git://github.com/
+
insteadOf &#61; git://aur.archlinux.org/
  +
</nowiki>}}
}}
 
 
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.}}
 
 
{{hc|~/.gitconfig|
 
[url "ssh://git@github.com/"]
 
pushInsteadOf &#61; https://github.com/
 
[url "git://github.com/"]
 
insteadOf &#61; https://github.com/
 
insteadOf &#61; http://github.com/
 
}}
 
 
{{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.}}
 
   
 
=== Bash 補完 ===
 
=== Bash 補完 ===
   
In order to enable Bash completion, source {{ic|/usr/share/git/completion/git-completion.bash}} in a [[Bash#設定ファイル|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}} スクリプトを source して、{{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 [[自動起動#シェル|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=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 || 上流からの進み・戻り・分岐 ('''<,>,<>''')。
 
|}
 
|}
   
{{ic|GIT_PS1_SHOWUPSTREAM}} will need to be set to {{ic|auto}} for changes to take effect.
+
変更を適用するには {{ic|GIT_PS1_SHOWUPSTREAM}} {{ic|auto}} に設定する必要があります。
   
  +
{{Note|{{ic|$(__git_ps1)}} が {{ic|((unknown))}} と返す場合、何もリポジトリが含まれていない {{ic|.git}} フォルダがカレントディレクトリに存在します。そのために Git が認識しなくなっています。{{ic|~/.gitconfig}} ではなく間違って {{ic|~/.git/config}} に Git の設定ファイルを作成した場合などに発生します。}}
{{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}}.}}
 
  +
  +
もしくは、{{AUR|bash-git-prompt}} や {{AUR|gittify}} など [[AUR]] にある git シェルプロンプトのカスタマイズパッケージを利用することもできます。
   
 
== 高度な使い方 ==
 
== 高度な使い方 ==
441行目: 424行目:
 
$ git diff --stat
 
$ git diff --stat
   
{{ic|git log}} with forking representation:
+
{{ic|git log}} でフォークを表示:
   
 
$ git log --graph --oneline --decorate
 
$ git log --graph --oneline --decorate
   
{{ic|git log}} graph alias (i.e. {{ic|git graph}} will show a decorated version):
+
{{ic|git log}} のグラフエイリアス ({{ic|git graph}} の表示が綺麗になります):
   
 
$ 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
   
  +
{{Note|gpg 署名で pinentry curses を使うには {{ic|1=export GPG_TTY=$(tty)}} (もしくは pinentry-tty を使用) を実行する必要があります。実行していないと gpg がロック状態の場合に署名が失敗します (pin の要求ができないためです)。}}
Signed-off-by line append (a name-email signature is added to the commit which is required by some projects):
 
  +
  +
Signed-off-by 行を追加 (プロジェクトによってはコミットに名前・メール署名の追加を必要とする場合があります):
   
 
$ 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
471行目: 456行目:
 
=== マスター以外のブランチで作業 ===
 
=== マスター以外のブランチで作業 ===
   
  +
ときに、メンテナからブランチで作業するように要求されることがあります。使われるブランチの名前は {{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
490行目: 475行目:
 
SSH プロトコルを使うには、まず SSH 公開鍵を設定します。[[SSH 鍵]]のガイドに従って設定してください。SSH サーバーを設定する方法は、[[SSH]] を見て下さい。
 
SSH プロトコルを使うには、まず SSH 公開鍵を設定します。[[SSH 鍵]]のガイドに従って設定してください。SSH サーバーを設定する方法は、[[SSH]] を見て下さい。
   
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:
+
SSH を動作させて鍵を生成したら、{{ic|~/.ssh/id_rsa.pub}} の中身を {{ic|~/.ssh/authorized_keys}} に貼り付けてください (1行に全て記述)。以下を実行することで SSH Git リポジトリにアクセスできます:
   
 
$ git clone ''user''@''foobar.com'':''my_repository''.git
 
$ git clone ''user''@''foobar.com'':''my_repository''.git
   
  +
SSH クライアントの {{ic|StrictHostKeyChecking}} 設定が {{ic|ask}} になっている場合 (デフォルト設定)、SSH は yes/no の確認を表示します。{{ic|yes}} と入力してから {{ic|Enter}} を押してください。それでリポジトリがチェックアウトされます。SSH を使用する場合、コミット権限も得られます。
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.
 
   
  +
SSH を使うように既存のリポジトリを設定するには、リモート URL を再定義してください:
To modify an existing repository to use SSH, the remote location will need to be redefined:
 
   
 
$ git remote set-url origin git@localhost:''my_repository''.git
 
$ git remote set-url origin git@localhost:''my_repository''.git
   
  +
{{ic|/etc/ssh/ssh_config}} や {{ic|~/.ssh/config}} の設定によって22番以外のポートに接続できます。リポジトリのポートを設定するには (例: 443):
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=
 
{{hc|~/.git/config|2=
509行目: 494行目:
 
=== Smart HTTP ===
 
=== Smart HTTP ===
   
  +
Git は git-http-backend を利用することで SSH や Git プロトコルと同じように HTTP(S) プロトコルを効率的に扱うことができます。リポジトリから clone あるいは pull できるだけでなく、HTTP(S) を使ってリポジトリに push することが可能です。
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).
 
   
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}}.
+
セットアップは大して難しくありません。Apache ウェブサーバー ({{pkg|apache}} {{ic|mod_cgi}}, {{ic|mod_alias}}, {{ic|mod_env}}) {{pkg|git}} をインストール・設定するだけです。
   
  +
基本的なセットアップが出来たら、Apache の設定ファイルに以下を追加してください:
Once you have your basic setup running, add the following to your Apache configuration file, which is usually located at:
 
   
 
{{hc|/etc/httpd/conf/httpd.conf|
 
{{hc|/etc/httpd/conf/httpd.conf|
525行目: 510行目:
 
}}
 
}}
   
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 リポジトリは {{ic|/srv/git}} としています。次のような URL でアクセスします: {{ic|<nowiki>http(s)://your_address.tld/git/your_repo.git</nowiki>}}
   
  +
{{Note|Apache からリポジトリに読み書きできることを確認してください。}}
{{Note|Make sure that Apache can read and write to your repositories.}}
 
   
  +
詳しいドキュメントは以下のリンクを参照:
For more detailed documentation, visit the following links:
 
* http://progit.org/2010/03/04/smart-http.html
+
* https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
* https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-http-backend.html
 
   
 
=== Git ===
 
=== Git ===
539行目: 523行目:
 
{{ic|git-daemon.socket}} を[[起動|起動・有効化]]してください。
 
{{ic|git-daemon.socket}} を[[起動|起動・有効化]]してください。
   
  +
デーモンは以下のオプションで起動します:
The daemon is started with the following options:
 
   
 
ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git
 
ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git
   
  +
{{ic|/srv/git/}} に置かれたリポジトリがデーモンによって認識されます。次のようなコマンドでクライアントで接続できます:
Repositories placed in {{ic|/srv/git/}} will be recognized by the daemon. Clients can connect with something similar to:
 
   
 
$ git clone git://''location''/''repository''.git
 
$ git clone git://''location''/''repository''.git
549行目: 533行目:
 
=== アクセス権限の設定 ===
 
=== アクセス権限の設定 ===
   
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.
+
読み書きアクセスを制限したいときは、標準の 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]) を参照してください。
   
より細かいアクセス管理については、[[gitolite]] や [[en2:gitosis|gitosis]] を参照してください。
+
より細かいアクセス管理については、[[gitolite]] や [[gitosis]] を参照してください。
   
 
== 参照 ==
 
== 参照 ==
   
* [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行目: 545行目:
 
* [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 が用意しているプロトコルの比較]

2023年1月18日 (水) 17:54時点における版

関連記事

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 のワークフローは以下の通りです:

  1. 新しいプロジェクトを作成、またはリモートのプロジェクトを複製する。
  2. ブランチを作成して変更を加え、変更をコミットする。
  3. コミットを統合して上手くまとめて分かりやすくする。
  4. メインのブランチにコミットをマージする。
  5. (任意) 変更をリモートサーバーにプッシュする。

ローカルリポジトリ

ステージング

新しいリポジトリを作成:

$ git init

リポジトリの変更を記録するには、先にインデックスまたはステージングエリア (ステージングとも呼ばれます) に変更を追加する必要があります。ファイルを追加するには:

$ git add file1 file2

ファイルを全て追加:

$ git add .
ヒント: git add . などのコマンドでファイルを無視するようにしたい場合、.gitignore ファイルを作成してください:
.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/**

詳しくは gitignore(5) を参照。

ステージングからファイルを削除 (--cached を付けるとファイルを実際には削除しません):

$ git rm (--cached) file

ファイルを全て削除:

$ git rm --cached -r .

または:

$ git reset HEAD -- .

上記の HEAD は現在の版の「シンボル参照」です。

ファイルの名前を変更:

$ git mv file1 file2

ファイルのリストを表示:

$ git ls-files

上記のコマンドはデフォルトでステージングエリアのファイルを表示します (--cached ファイル)。

変更をコミット

コンテンツをステージングに記録したら、次のコマンドでコミットします:

$ git commit -m "First commit."

-m, --message オプションを使うことで短いメッセージを残せます: オプションを省略した場合、事前に設定していたエディタが起動して長いメッセージを書くことができます。

ヒント:
  • 小さい変更でも頻繁にコミットを行ってちゃんとしたメッセージを書くようにしましょう。
  • 編集を加えたファイルを全てインデックスに追加して、それらをコミットするのは一つのコマンドで実行できます (-a--all の略式):
$ git commit -am "First commit."

過去に戻ってコミットメッセージを編集:

$ git commit --amend -m "Message."

この記事で使われるコマンドの多くはコミットを引数として指定します。コミットは以下の形式のどれかで指定することが可能です:

  • 40文字の SHA-1 ハッシュ (大抵は最初の7文字くらいで一意に識別できます)。
  • ブランチやタグの名前といったコミットのラベル。
  • HEAD ラベルはチェックアウトされた最新のコミットを示します (git checkout を使って古いコミットまで歴史を戻していない限り、ブランチの頭になります)。
  • 上記に加えて ~ を付けることで前のコミットを指定できます。例えば、HEAD~HEAD の一つ前のコミット、HEAD~5HEAD の五つ前のコミットを指します。

変更を閲覧

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

$ git diff HEAD HEAD~3

ステージングエリアと作業ツリーの差分を表示:

$ git diff

変更の要点を表示:

$ git status

変更の履歴を表示 ("-N" は表示する直近のコミット数):

$ git log (-N)

ブランチの作成

基本的に、修正や新しい機能などはブランチでテストします。変更が問題ないようだったら、デフォルトのブランチ (master) にマージします。ブランチを作成するときは、目的に適った名前を付けて下さい:

$ git branch help-section-addition

ブランチを一覧:

$ git branch

ブランチを切り替え:

$ git checkout branch

ブランチを作成して切り替え:

$ git checkout -b branch

ブランチを master ブランチにマージ:

$ git checkout master
$ git merge branch

変更が衝突しない場合はマージされます。衝突する場合は衝突箇所が記録されます。git diff を使ってどこで衝突しているのか確認することができるので、手動で衝突の解消をする必要があります。

ブランチが不要になったら、次のコマンドで削除します:

$ git branch -d branch

共同作業

エチケット

  • 既存のプロジェクトに貢献しようと考えた場合、プロジェクトのライセンスを確認しましょう。コードの変更についてかなり制限がかけられている場合もあります。ライセンスによっては、コードの所有権について論争が生まれることも考えられます。
  • プロジェクトのコミュニティを観測してどうやったら適合できるか考えましょう。プロジェクトの方向性を理解するために、ドキュメントやリポジトリのログを読むのも大切です。
  • コミットを pull するようにリクエストしたり、パッチを送るときは、できるかぎりパッチを短くして説明を付加するようにしましょう。メンテナがあなたの変更箇所を理解するための手助けとなり、マージするか、もしくは修正を加えるよう要求すべきか判断する基準にもなります。
  • リジェクトされたとしても、落胆する必要はありません。所詮他人のプロジェクトです。リクエストが重要な場合、出来るかぎり分かりやすく根気よくリクエストの理由を説明しましょう。いつかは解決に導かれるはずです。

リポジトリを複製

プロジェクトへの貢献を始めるには、まずリポジトリを clone します:

$ git clone location folder

location はパスでもネットワークアドレスでもかまいません。また、複製が完了すると場所が記録されるので、git pull だけで複製できるようになります。

プルリクエスト

変更を加えてコミットしたら、ソフトウェアの作者にマージするように要求することができます。これを「プルリクエスト」と呼びます。pull するには:

$ git pull location master

pull コマンドは 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)。

メーリングリストにパッチを送信

メーリングリストに直接パッチを送る場合、次のパッケージをインストールする必要があります: perl-authen-sasl, perl-net-smtp-ssl, perl-mime-tools

ユーザー名とメールアドレスを設定したか確認してください、#基本設定を参照。

メールアドレスを設定:

$ git config --global sendemail.smtpserver smtp.gmail.com
$ git config --global sendemail.smtpserverport 587
$ git config --global sendemail.smtpencryption tls
$ git config --global sendemail.smtpuser foobar@gmail.com

これでメーリングリストにパッチを送信することができます (OpenEmbedded:How to submit a patch to OpenEmbedded#Sending patches を参照):

$ git add filename
$ git commit -s
$ git send-email --to=openembedded-core@lists.openembedded.org --confirm=always -M -1

履歴とバージョニング

履歴の検索

git log では履歴とコミットのチェックサムや作者、日付、ショートメッセージを表示します。チェックサムはコミットオブジェクトのオブジェクト名であり、通常は40文字の SHA-1 ハッシュになります。履歴とロングメッセージを表示するには ("checksum" は一意であるかぎり短く省略できます):

$ git show (checksum)

追跡されているファイルをパターン検索:

$ git grep pattern

.c.h ファイルを検索:

$ git grep pattern -- '*.[ch]'

バージョニングとリリース

コミットにタグを付ける:

$ git tag 2.14 checksum

タグは一般的に リリースやバージョニング するときに付けられますが文字列は何でもかまいません。通常は Git データベースに追加される注釈付きタグが用いられます。最新のコミットにタグを付けるには:

$ git tag -a 2.14 -m "Version 2.14"

タグを確認:

$ git tag -l

タグを削除:

$ git tag -d 2.08

タグを更新:

$ git push --tags

コミットの修正

プルリクエストを送信する前に、コミットを整理・統合するのが望ましいことがあります。git rebase のインタラクティブオプションを使います:

$ git rebase -i checksum

コマンドを実行すると指定された範囲のコミットが全てエディタで開かれます。上記の場合、最新のコミット (HEAD) から checksum コミットまでが開かれます。数字で指定する場合、例えば HEAD~3 なら最後の3つのコミットがリベースされます:

pick d146cc7 Mountpoint test.
pick 4f47712 Explain -o option in readme.
pick 8a4d479 Rename documentation.

最初のカラムに rebase で実行する動作を記述します。以下から選んでください:

  • pick — コミットをそのまま適用します (デフォルト)。
  • edit — ファイルやコミットメッセージを編集。
  • reword — コミットメッセージを編集。
  • squash — 前のコミットにマージ。
  • fixup — 前のコミットにマージ。メッセージは破棄。

コミットの順番を変えたり履歴から消去することが可能です (ただし注意して操作してください)。ファイルの編集後、Git は指示された作業を実施します。マージ時の問題を解決するように要求された場合、修正してから git rebase --continue で続行するか、git rebase --abort コマンドで中止してください。

ノート: コミットの squash はローカルコミットでのみ使います。他人と共有しているリポジトリで使うと問題が発生します。

高度な設定

Git は INI タイプの設定ファイルから設定を読み込みます:

  • 各リポジトリにはリポジトリごとの設定を記述した .git/config ファイルが含まれます。
  • 各ユーザーの $HOME/.gitconfig ファイルがフォールバックとして使われます。
  • システム全体のデフォルト設定としては /etc/gitconfig が使われます。

上記のファイルは直接編集できますが、通常は下の例にあるように git config を使います。

現在設定されている変数を確認:

$ git config {--local,--global,--system} --list

デフォルトエディタを vim から nano に設定:

$ git config --global core.editor "nano -w"

デフォルトのプッシュアクションを設定:

$ git config --global push.default simple

git difftool で使用するツールを設定 (デフォルトでは meld になっています):

$ git config --global diff.tool vimdiff

詳しくは git-config(1)Git Configuration を見て下さい。

認証の高速化

Git サーバーにプッシュする度に認証が面倒なのをなんとかしたいと思っている場合、以下を使って下さい。

デフォルトプロトコル

上述のように SSH で多重接続することで、Git over SSH の方が HTTPS よりも高速になります。また、(AUR など) サーバーによっては SSH を介して push することもできます。例えば、以下の設定をすると AUR でホストされているリポジトリで Git over SSH を設定します。

~/.gitconfig
[url "ssh://aur@aur.archlinux.org/"]
	insteadOf = https://aur.archlinux.org/
	insteadOf = http://aur.archlinux.org/
	insteadOf = git://aur.archlinux.org/

Bash 補完

Bash の補完を有効にするには、Bash のスタートアップファイル/usr/share/git/completion/git-completion.bash を source してください。もしくは、bash-completion をインストールしてください。

Git プロンプト

Git パッケージにはプロンプトスクリプトが付属しています。プロンプトを有効にするには、シェルのスタートアップファイル/usr/share/git/completion/git-prompt.sh スクリプトを source して、%s パラメータでカスタムプロンプトを設定してください:

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

Git リポジトリのディレクトリに移動すると、プロンプトはブランチの名前を表示するようになります。他の情報もプロンプトに表示させるよう設定できます:

シェル変数 情報
GIT_PS1_SHOWDIRTYSTATE ステージ済みの場合は +、未ステージの場合は *
GIT_PS1_SHOWSTASHSTATE スタッシュが存在する場合は $
GIT_PS1_SHOWUNTRACKEDFILES 追跡されていないファイルが存在する場合は %
GIT_PS1_SHOWUPSTREAM 上流からの進み・戻り・分岐 (<,>,<>)。

変更を適用するには GIT_PS1_SHOWUPSTREAMauto に設定する必要があります。

ノート: $(__git_ps1)((unknown)) と返す場合、何もリポジトリが含まれていない .git フォルダがカレントディレクトリに存在します。そのために Git が認識しなくなっています。~/.gitconfig ではなく間違って ~/.git/config に Git の設定ファイルを作成した場合などに発生します。

もしくは、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
ノート: gpg 署名で pinentry curses を使うには export GPG_TTY=$(tty) (もしくは pinentry-tty を使用) を実行する必要があります。実行していないと gpg がロック状態の場合に署名が失敗します (pin の要求ができないためです)。

Signed-off-by 行を追加 (プロジェクトによってはコミットに名前・メール署名の追加を必要とする場合があります):

 $ git commit -s

パッチに Signed-off-by を自動で追加 (git format-patch commit を使用したとき):

$ git config --local format.signoff true

変更を加えたファイルの特定部分をコミット。大量の変更を行ったとき複数のコミットに分けたい場合に有用です:

$ git add -p

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

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

master 以外のブランチを開くには (git clone で master ブランチしか表示されない場合、git branch -a で他のブランチを表示できます):

$ git checkout -b branch origin/branch

通常通り編集を行ってください。ただし以下のコマンドを使ってリポジトリツリーを同期させてください:

$ git pull --all
$ git push --all

Git サーバー

様々なプロトコルによるリポジトリへの接続を設定する方法。

SSH

SSH プロトコルを使うには、まず SSH 公開鍵を設定します。SSH 鍵のガイドに従って設定してください。SSH サーバーを設定する方法は、SSH を見て下さい。

SSH を動作させて鍵を生成したら、~/.ssh/id_rsa.pub の中身を ~/.ssh/authorized_keys に貼り付けてください (1行に全て記述)。以下を実行することで SSH で Git リポジトリにアクセスできます:

$ git clone user@foobar.com:my_repository.git

SSH クライアントの StrictHostKeyChecking 設定が ask になっている場合 (デフォルト設定)、SSH は yes/no の確認を表示します。yes と入力してから Enter を押してください。それでリポジトリがチェックアウトされます。SSH を使用する場合、コミット権限も得られます。

SSH を使うように既存のリポジトリを設定するには、リモート URL を再定義してください:

$ git remote set-url origin git@localhost:my_repository.git

/etc/ssh/ssh_config~/.ssh/config の設定によって22番以外のポートに接続できます。リポジトリのポートを設定するには (例: 443):

~/.git/config
[remote "origin"]
    url = ssh://user@foobar.com:443/~my_repository/repo.git

Smart HTTP

Git は git-http-backend を利用することで SSH や Git プロトコルと同じように HTTP(S) プロトコルを効率的に扱うことができます。リポジトリから clone あるいは pull できるだけでなく、HTTP(S) を使ってリポジトリに push することが可能です。

セットアップは大して難しくありません。Apache ウェブサーバー (apachemod_cgi, mod_alias, mod_env) と git をインストール・設定するだけです。

基本的なセットアップが出来たら、Apache の設定ファイルに以下を追加してください:

/etc/httpd/conf/httpd.conf
<Directory "/usr/lib/git-core*">
    Require all granted
</Directory>
 
SetEnv GIT_PROJECT_ROOT /srv/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

上記の設定では Git リポジトリは /srv/git としています。次のような URL でアクセスします: http(s)://your_address.tld/git/your_repo.git

ノート: Apache からリポジトリに読み書きできることを確認してください。

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

Git

ノート: Git プロトコルでは読み取りアクセスだけが許可されます。

git-daemon.socket起動・有効化してください。

デーモンは以下のオプションで起動します:

ExecStart=-/usr/lib/git-core/git-daemon --inetd --export-all --base-path=/srv/git

/srv/git/ に置かれたリポジトリがデーモンによって認識されます。次のようなコマンドでクライアントで接続できます:

$ git clone git://location/repository.git

アクセス権限の設定

読み書きアクセスを制限したいときは、標準の Unix パーミッションを使います。詳しくは http://sitaramc.github.com/gitolite/doc/overkill.html[リンク切れ 2013-11-06] (archive.org mirror) を参照してください。

より細かいアクセス管理については、gitolitegitosis を参照してください。

参照