Git
日本語 ▾ トピック ▾ 最新バージョン ▾ giteveryday の最終更新は 2.43.0 です

NAME

giteveryday - Everyday Git で使用する便利な最小限のコマンドセット

SYNOPSIS

約20個のコマンドで実現する Everyday Git

DESCRIPTION

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

  • 個人開発者 (スタンドアロン) コマンドは、単独で作業する人であっても、コミットを行うすべての人にとって不可欠です。

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

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

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

個人開発者 (スタンドアロン)

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

例

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" から。

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

  • git-format-patch[1] Linux カーネルスタイルのパブリックフォーラムワークフローを採用する場合は、メール送信を準備します。

  • git-send-email[1] MUA によって破損することなく、メール送信を送信します。

  • 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. mothership マシンには、ホームディレクトリの下に frotz リポジトリがあります。そこからクローンして、サテライトマシンでリポジトリを開始します。

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

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

  4. プッシュすると、mothership マシンの remotes/satellite/* リモートトラッキングブランチにすべての作業が格納されます。これをバックアップ方法として使用できます。同様に、mothership があなたから「フェッチ」したと見なすことができます (アクセスが一方的な場合に役立ちます)。

  5. mothership マシンで、サテライトマシンで行われた作業を 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 またはプルリクエストに応答する人も使用できます。リポジトリのサブエリア担当者は、参加者とインテグレーターの両方として機能します。

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

  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-instaweb[1] スクリプトを使用して設定できる Git リポジトリの Web フロントエンドを提供します。

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. aliceとcindyはmasterにプッシュできます。bobのみがdoc-updateにプッシュできます。davidはリリース管理者であり、バージョンのタグを作成およびプッシュできる唯一の人物です。

GIT

git[1]スイートの一部

scroll-to-top