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

名前

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

概要

20個程度のコマンドで日常のGitを

説明

Gitユーザーは、ここで日常のGitに役立つコマンドの小さなセットを説明する目的で、大きく4つのカテゴリに分類できます。

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

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

例

新しいリポジトリの開始点として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] で上流からローカルリポジトリを準備します。

  • git-pull[1] と git-fetch[1] で "origin" から最新の状態を維持します。

  • 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. クローンはデフォルトでこれらの構成変数を設定します。git pull がマザーシップマシンのブランチをローカルの remotes/origin/* リモート追跡ブランチにフェッチして保存するように設定します。

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

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

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

特定のタグからブランチを作成する。
$ 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 またはプルリクエストに対応し、他の人の作業を自分の履歴に統合する人にも使用できます。リポジトリのサブエリア責任者は、参加者とインテグレーターの両方として行動します。

  • git-am[1] で、貢献者からメールで送られてきたパッチを適用します。

  • 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. マスターにマージされていない、または安定ブランチの一部として公開されていない内部トピックブランチをリベースする。

  7. seen を毎回 next から再起動する。

  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 を使用する開発者に、プッシュ/プルのみのアクセス権を付与する。

例：$ 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. アリスとシンディはマスターにプッシュできるが、ボブだけがドキュメント更新にプッシュできる。デイビッドはリリース管理者であり、バージョンタグを作成してプッシュできる唯一の人物である。

GIT

git[1]スイートの一部

scroll-to-top