英語 ▾ トピック ▾ 最新バージョン ▾ giteveryday は 2.43.0 で最終更新されました

名前

giteveryday - 日常のGitに役立つ最低限のコマンドセット

概要

約20のコマンドで日常のGitを使いこなす

説明

日常のGitに役立つ少数のコマンドを説明するため、Gitユーザーは大きく4つのカテゴリに分類できます。

  • 個人開発者（スタンドアロン）コマンドは、コミットを行うすべての人にとって必須であり、単独で作業する人にも必要です。

  • 他の人と共同で作業する場合は、個人開発者（参加者）セクションに記載されているコマンドも必要になります。

  • インテグレーターの役割を果たす人は、上記に加えてさらにいくつかのコマンドを学ぶ必要があります。

  • リポジトリ管理コマンドは、Gitリポジトリの管理と運用を担当するシステム管理者向けです。

個人開発者（スタンドアロン）

スタンドアロンの個人開発者は、他の人とパッチをやり取りせず、単一のリポジトリで単独で作業し、以下のコマンドを使用します。

  • 新しいリポジトリを作成するにはgit-init[1]を使用します。

  • 何が起こったかを確認するにはgit-log[1]を使用します。

  • ブランチを切り替えるにはgit-switch[1]およびgit-branch[1]を使用します。

  • インデックスファイルを管理するにはgit-add[1]を使用します。

  • 現在作業中の内容を確認するにはgit-diff[1]およびgit-status[1]を使用します。

  • 現在のブランチを進めるにはgit-commit[1]を使用します。

  • 変更を元に戻すにはgit-restore[1]を使用します。

  • ローカルブランチ間でマージするにはgit-merge[1]を使用します。

  • トピックブランチを管理するにはgit-rebase[1]を使用します。

  • 既知のポイントをマークするにはgit-tag[1]を使用します。

例

新しいリポジトリの開始点としてtarballを使用する。
$ tar zxf frotz.tar.gz
$ cd frotz
$ git init
$ git add . (1)
$ git commit -m "import of frotz source tree."
$ git tag v2.43 (2)

  1. 現在のディレクトリ以下のすべてを追加します。

  2. 軽量で注釈なしのタグを作成します。

トピックブランチを作成して開発します。
$ git switch -c alsa-audio (1)
$ edit/compile/test
$ git restore curses/ux_audio_oss.c (2)
$ git add curses/ux_audio_alsa.c (3)
$ edit/compile/test
$ git diff HEAD (4)
$ git commit -a -s (5)
$ edit/compile/test
$ git diff HEAD^ (6)
$ git commit -a --amend (7)
$ git switch master (8)
$ git merge alsa-audio (9)
$ git log --since='3 days ago' (10)
$ git log v2.43.. curses/ (11)

  1. 新しいトピックブランチを作成します。

  2. curses/ux_audio_oss.c で失敗した変更を元に戻します。

  3. 新しいファイルを追加した場合はGitに伝える必要があります。後で git commit -a を実行すれば、削除と変更は捕捉されます。

  4. コミットしようとしている変更を確認します。

  5. テスト済みのすべての変更を、署名付きでコミットします。

  6. 以前のコミットを含め、すべての変更を確認します。

  7. 以前のコミットを修正し、すべての新しい変更を元のメッセージを使用して追加します。

  8. masterブランチに切り替えます。

  9. トピックブランチをmasterブランチにマージします。

  10. コミットログを確認します。出力制限の他の形式は組み合わせることができ、-10 (最大10コミットを表示)、--until=2005-12-10 などを含みます。

  11. v2.43 タグ以降の curses/ ディレクトリ内の変更のみを表示します。

個人開発者（参加者）

グループプロジェクトの参加者として作業する開発者は、他の開発者とコミュニケーションをとる方法を学ぶ必要があり、スタンドアロン開発者が必要とするコマンドに加えてこれらのコマンドを使用します。

  • アップストリームからローカルリポジトリを準備するにはgit-clone[1]を使用します。

  • アップストリームと同期を保つには、"origin" からgit-pull[1]とgit-fetch[1]を使用します。

  • CVSスタイルの共有リポジトリワークフローを採用している場合は、共有リポジトリにgit-push[1]を使用します。

  • Linuxカーネルスタイルの公開フォーラムワークフローを採用している場合は、メール送信を準備するためにgit-format-patch[1]を使用します。

  • MUAによる破損なしにメール送信するにはgit-send-email[1]を使用します。

  • アップストリームがプルするための変更点の要約を作成するにはgit-request-pull[1]を使用します。

例

アップストリームをクローンして作業する。変更をアップストリームに送る。
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git switch -c mine master (1)
$ edit/compile/test; git commit -a -s (2)
$ git format-patch master (3)
$ git send-email --to="person <email@example.com>" 00*.patch (4)
$ git switch master (5)
$ git pull (6)
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
$ git reset --hard ORIG_HEAD (10)
$ git gc (11)

  1. masterから新しいブランチ mine をチェックアウトします。

  2. 必要に応じて繰り返します。

  3. masterに対するあなたのブランチからパッチを抽出します。

  4. そしてメールで送信します。

  5. master に戻り、新しい変更を確認する準備をします。

  6. git pull はデフォルトで origin からフェッチし、現在のブランチにマージします。

  7. プル後すぐに、前回確認してからアップストリームで行われた変更を、興味のある領域のみで確認します。

  8. 外部リポジトリのブランチ名を確認します（不明な場合）。

  9. 特定のブランチ ALL を特定のレポジトリからフェッチし、マージします。

  10. プルを元に戻します。

  11. 元に戻したプルから残ったオブジェクトをガーベージコレクトします。

別のリポジトリにプッシュする。
satellite$ git clone mothership:frotz frotz (1)
satellite$ cd frotz
satellite$ git config --get-regexp '^(remote|branch)\.' (2)
remote.origin.url mothership:frotz
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
branch.master.remote origin
branch.master.merge refs/heads/master
satellite$ git config remote.origin.push \
	   +refs/heads/*:refs/remotes/satellite/* (3)
satellite$ edit/compile/test/commit
satellite$ git push origin (4)

mothership$ cd frotz
mothership$ git switch master
mothership$ git merge satellite/master (5)

  1. マザーシップマシンにはホームディレクトリの下にfrotzリポジトリがあります。そこからクローンしてサテライトマシンにリポジトリを開始します。

  2. cloneはデフォルトでこれらの設定変数を設定します。git pull がマザーシップマシンのブランチをローカルの remotes/origin/* リモートトラッキングブランチにフェッチして保存するように設定します。

  3. すべてのローカルブランチをマザーシップマシンの対応するブランチにプッシュするように git push を設定します。

  4. pushは、私たちのすべての作業をマザーシップマシンの remotes/satellite/* リモートトラッキングブランチにスタッシュします。これはバックアップ方法として使用できます。同様に、マザーシップがあなたから「フェッチ」したと見なすこともできます（アクセスが一方的である場合に便利です）。

  5. マザーシップマシンで、サテライトマシンで行われた作業をmasterブランチにマージします。

特定のタグからブランチを作成する。
$ git switch -c private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git cherry-pick v2.6.14..private2.6.14 (2)

  1. よく知られている（しかし少し遅れている）タグに基づいてプライベートブランチを作成します。

  2. private2.6.14 ブランチのすべての変更を、正式な「マージ」なしで master ブランチにフォワードポートします。あるいは、
    git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

別の参加者による提出メカニズムとしては、git request-pull またはプルリクエストメカニズム（例: GitHub (www.github.com) で使用されるもの）を使用して、アップストリームに貢献を通知する方法があります。

インテグレーター

グループプロジェクトでインテグレーターとして中心的な役割を果たす人は、他者によって行われた変更を受け取り、レビューして統合し、その結果を他者が使用できるように公開します。これは参加者が必要とするコマンドに加えてこれらのコマンドを使用します。

このセクションは、GitHub (www.github.com) で git request-pull またはプルリクエストに対応し、他者の作業を自身の履歴に統合する人にも使用できます。リポジトリのサブエリアリエutenantは、参加者としてもインテグレーターとしても機能します。

  • コントリビューターからメールで送られてきたパッチを適用するにはgit-am[1]を使用します。

  • 信頼できるリエutenantからマージするにはgit-pull[1]を使用します。

  • コントリビューターに提案された代替案を準備して送信するにはgit-format-patch[1]を使用します。

  • 失敗したコミットを元に戻すにはgit-revert[1]を使用します。

  • 最新の変更を公開するにはgit-push[1]を使用します。

例

典型的なインテグレーターのGitの一日。
$ git status (1)
$ git branch --no-merged master (2)
$ mailx (3)
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git switch -c topic/one master
$ git am -3 -i -s ./+to-apply (4)
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5)
$ git switch topic/one && git rebase master (6)
$ git switch -C seen next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git switch maint
$ git cherry-pick master~4 (9)
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
$ git fetch ko && for branch in master maint next seen (11)
    do
	git show-branch ko/$branch $branch (12)
    done
$ git push --follow-tags ko (13)

  1. もし何か作業中のものがあれば、それを確認します。

  2. まだ master にマージされていないブランチを確認します。他の統合ブランチ（例: maint, next, seen）についても同様です。

  3. メールを読み、適用可能なものは保存し、まだ準備ができていないものは別に保存します（他のメールリーダーも利用可能です）。

  4. それらをインタラクティブに、あなたの署名付きで適用します。

  5. 必要に応じてトピックブランチを作成し、再び署名付きで適用します。

  6. masterにマージされていない、または安定ブランチの一部として公開されていない内部トピックブランチをリベースします。

  7. 毎回 seen を次の状態から再開します。

  8. そして、まだ作業中のトピックブランチをバンドルします。

  9. 致命的な修正をバックポートします。

  10. 署名付きタグを作成します。

  11. masterが、すでにプッシュされたポイントより誤って巻き戻されていないことを確認します。

  12. git show-branch の出力では、master には ko/master が持つすべてが含まれ、next には ko/next が持つすべてが含まれる、といったようになります。

  13. プッシュされた履歴を指す新しいタグとともに、最新の変更をプッシュします。

この例では、ko の省略形はkernel.orgにあるGitメンテナーのリポジトリを指しており、次のようになります。

(in .git/config)
[remote "ko"]
	url = kernel.org:/pub/scm/git/git.git
	fetch = refs/heads/*:refs/remotes/ko/*
	push = refs/heads/master
	push = refs/heads/next
	push = +refs/heads/seen
	push = refs/heads/maint

リポジトリ管理

リポジトリ管理者は、開発者によるリポジトリへのアクセスを設定・維持するために以下のツールを使用します。

  • リポジトリからの匿名ダウンロードを許可するにはgit-daemon[1]を使用します。

  • git-shell[1]は、共有中央リポジトリユーザーのための制限付きログインシェルとして使用できます。

  • git-http-backend[1]は、Git-over-HTTP ("Smart http") のサーバーサイド実装を提供し、フェッチとプッシュの両方のサービスを許可します。

  • gitweb[1]はGitリポジトリへのWebフロントエンドを提供し、git-instaweb[1]スクリプトを使用してセットアップできます。

update hook howtoには、共有中央リポジトリを管理する良い例が記載されています。

さらに、広く展開されている他のホスティング、ブラウジング、レビューソリューションがいくつかあります。

  • gitolite、gerrit code review、cgitなどです。

例

/etc/services に以下を想定します
$ grep 9418 /etc/services
git		9418/tcp		# Git Version Control System
inetdから/pub/scmをサービス提供するためにgit-daemonを実行する。
$ grep git /etc/inetd.conf
git	stream	tcp	nowait	nobody \
  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

実際の構成行は1行である必要があります。

xinetdから/pub/scmをサービス提供するためにgit-daemonを実行する。
$ cat /etc/xinetd.d/git-daemon
# default: off
# description: The Git server offers access to Git repositories
service git
{
	disable = no
	type            = UNLISTED
	port            = 9418
	socket_type     = stream
	wait            = no
	user            = nobody
	server          = /usr/bin/git-daemon
	server_args     = --inetd --export-all --base-path=/pub/scm
	log_on_failure  += USERID
}

xinetd(8) のドキュメントと設定を確認してください。これはFedoraシステムからのものです。他のシステムでは異なる場合があります。

git-over-sshを使用して開発者にpush/pullのみのアクセスを許可する。

例: $ git push/pull ssh://host.xz/pub/scm/project を使用するユーザー。

$ grep git /etc/passwd (1)
alice:x:1000:1000::/home/alice:/usr/bin/git-shell
bob:x:1001:1001::/home/bob:/usr/bin/git-shell
cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
david:x:1003:1003::/home/david:/usr/bin/git-shell
$ grep git /etc/shells (2)
/usr/bin/git-shell

  1. ログインシェルは /usr/bin/git-shell に設定されており、これは git push および git pull 以外の何も許可しません。ユーザーはマシンへのsshアクセスが必要です。

  2. 多くのディストリビューションでは、/etc/shells にログインシェルとして使用されるものがリストされている必要があります。

CVSスタイルの共有リポジトリ。
$ grep git /etc/group (1)
git:x:9418:alice,bob,cindy,david
$ cd /home/devo.git
$ ls -l (2)
  lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
  -rw-rw-r--   1 david git    84 Dec  4 22:40 config
  -rw-rw-r--   1 david git    58 Dec  4 22:40 description
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
  drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
  drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
$ ls -l hooks/update (3)
  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
$ cat info/allowed-users (4)
refs/heads/master	alice\|cindy
refs/heads/doc-update	bob
refs/tags/v[0-9]*	david

  1. 開発者を同じgitグループに入れます。

  2. そして、共有リポジトリをグループが書き込み可能にします。

  3. ブランチポリシー制御のために、Documentation/howto/にあるCarlによるupdate-hookの例を使用します。

  4. アリスとシンディはmasterにプッシュできますが、ボブだけがdoc-updateにプッシュできます。デイビッドはリリース管理者であり、バージョンタグを作成してプッシュできる唯一の人物です。

GIT

git[1] スイートの一部

scroll-to-top