giteveryday(7)

SYNOPSIS

Git日常利用の為の20程度のコマンド

DESCRIPTION

日常のGit利用に役立つコマンドの小さなセットを説明するため、Gitユーザーを大きく4つのカテゴリに分類します。

開発者個人(スタンドアローン) のコマンドは一人で作業する人でも、コミットする人には不可欠です。
他の人と一緒に作業する場合は、開発者個人(グループプロジェクト参加者) セクションにリストされているコマンドも必要になります。
インテグレーター役の人々は、上記に加えて更に幾つかのコマンドを学ぶ必要があります。
リポジトリ管理コマンドは、 Gitリポジトリの管理と提供を担当するシステム管理者向けです。

Individual Developer (Standalone)

独立した個々の開発者は、他の人とパッチを交換せず、以下のコマンドを使用して、単一のリポジトリで単独で作業します。

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) を使用して、変更を元に戻します(undo)。
git-merge(1) は、ローカルブランチ間でマージします。
git-rebase(1) は、トピックブランチを保守します。
git-tag(1) を使用して、既知のポイントをマークします。

Examples

新しいリポジトリの開始点として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>

あなたが現在いるディレクトリ下のすべてをaddします。
軽量で注釈のないタグを作成します。

トピックブランチを作成して開発します

$ 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>

新しいトピックブランチを作成します。
curses/ux_audio_oss.c で失敗した変更を元に戻します(revert)。
あなたは新しいファイルを追加したかどうかをGitに伝える必要があります。後で git commit -a を実行すると、削除と変更が捕捉されます。
コミットしようとしている変更を確認します。
あなたがテストしたと署名(sign-off)して、全てをコミットします。
前のコミットを含むすべての変更を確認します。
元のメッセージを流用して、以前のコミットを修正し、すべての新しい変更を追加します。
masterブランチに切り替えます。
トピックブランチをあなたのmasterブランチへマージします。
コミットログを確認します。出力を制限する他の形式を組み合わせて、 -10 (最大10個のコミットを表示）、 --until=2005-12-10 などを含めることができます。
v2.43 タグ以降、curses/ ディレクトリにあるものに影響を与える変更のみを表示します。

Individual Developer(Participant;グループプロジェクト参加者)

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

git-clone(1) をアップストリームから実行して、あなたのローカルリポジトリを準備します。
git-pull(1) と git-fetch(1) により、 "origin" をアップストリームと共に最新の状態に保ちます。
CVSスタイルの共有リポジトリワークフローを採用している場合、共有リポジトリのために git-push(1) を使います。
Linuxカーネルスタイルのパブリックフォーラムワークフローを採用している場合に、 git-format-patch(1) は電子メール送信を準備します。
git-send-email(1) を使用して、MUAによる破損なしに電子メール送信を送信します。
git-request-pull(1) を使用して、あなたのアップストリームがプルする変更の概要を作成します。

Examples

アップストリームのクローンを作成して作業します。変更をアップストリームに送ります。

$ 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>

master から新ブランチ mine を作成し、 mine でチェックアウトします。
必要に応じてこの作業を繰り返します。
masterに関連して、あなたのブランチからパッチを抽出します。
そしてそれらを電子メールで送ります。
master に戻り、最新情報を確認する準備をします
git pull はデフォルトで origin からフェッチし、現在のブランチにマージします。
プルした直後に、前回チェックしてから上流で行われた変更を、関心のある領域でのみ確認します。
(不明な場合)外部リポジトリのブランチ名を確認します。
指定のリポジトリから、指定のブランチ ALL をフェッチしマージします。
プルしたのを元に戻します。(revert)
ガベージコレクションは、元に戻されたプルからゴミオブジェクト(leftover objects)を収集します。

別のリポジトリにプッシュします。

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>

マザーシップ機には、ホームディレクトリの下にfrotzリポジトリがあります。そこからクローンを作成して、サテライト機でリポジトリを開始します。
cloneは、これらの構成変数をデフォルトで設定します。これは、マザーシップ機のブランチをフェッチしてローカルの remotes/origin/* リモートトラッキングブランチに保存するために git pull を手配します。
すべてのローカルブランチをマザーシップ機の対応するブランチにプッシュするために git push を手配します。
pushは、マザーシップ機の remotes/satellite/* リモートトラッキングブランチへすべての作業をstashします。これをバックアップ方法として使用できます。同様に、あなたはそのマザーシップ機があなたから「フェッチされた」ふりをすることができます(アクセスが一方的な場合に便利です)。
マザーシップ機で、サテライト機で行われた作業をmasterブランチにマージします。

Branch off of a specific tag.

$ 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>

よく知られている(ただし多少遅れている)タグに基づいてプライベートブランチを作成します。
forward port all changes in private2.6.14 branch to master branch without a formal "merging". Or longhand + git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

別の参加者送信メカニズム(participant submission mechanism)は、 git request-pull または pull-request メカニズム(GitHub（www.github.com）で使用されているものなど)を使用して、あなたの貢献をあなたのアップストリームに通知します。

インテグレーター

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

このセクションのコマンドは、GitHub（www.github.com）で git request-pull または pull-request に応答するユーザーが、他のユーザーの作業を履歴に統合するために使用することもできます。リポジトリの部分担当サブリーダー(sub-area lieutenant)は、参加者とインテグレーターの両方として機能します。

git-am(1) を使用して、寄稿者から電子メールで送信されて来たパッチを適用します。
git-pull(1) を使用して、信頼できる部分担当サブリーダーの分からマージします。
git-format-patch(1) を準備し、提案された代替案を寄稿者に送信します。
git-revert(1) は、失敗したコミットを元に戻します。(revert)
git-push(1) を使用して、最先端を公開します。

Examples

典型的な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>

どちらかといえば、あなたが途中で何をしていたかを見てください。
master にマージされていないのがどのブランチかを確認してください。他の統合ブランチ(maint 、` next` 、 seen)についても同様です。
メールを読んだり、該当するものを保存したり、準備が整っていないものを保存したりします(他のメールリーダーも利用できます)。
あなたの署名伴って、対話的にそれらを適用します。
必要に応じてトピックブランチを作成し、再度署名して適用します。
masterにマージされていない、または安定したブランチの一部として公開されていない内部トピックブランチをリベースします。
next から毎回 seen を再スタートします。
そして、まだ調理中のトピックブランチをバンドルします。
深刻な修正をバックポートします。
署名付きタグを作成します。
masterがすでにpushされたものを超えて誤って巻き戻されていないことを確認してください。
git show-branch からの出力では、 master には ko/master が持つすべてのものが含まれ、 next には ko/next が持つすべてのものが含まれる必要があります。
プッシュされた履歴を指す新しいタグとともに、最先端をプッシュします。

この例では、 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(スマートhttp)のサーバー側実装を提供します。
gitweb(1) は、GitリポジトリへのWebフロントエンドを提供します。これは、 git-instaweb(1) スクリプトを使用して設定できます。

update hook howto には、共有中央リポジトリを管理する良い例があります。

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

gitolite 、 gerrit code review 、 cgit 、その他。

Examples

/etc/services では以下を前提としています

$ grep 9418 /etc/services
git             9418/tcp                # Git Version Control System

Run git-daemon to serve /pub/scm from inetd.

$ grep git /etc/inetd.conf
git     stream  tcp     nowait  nobody \
  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

実際の行は1行で書く必要があります。

Run git-daemon to serve /pub/scm from xinetd.

$ 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システムからのものです。その他は異なる場合があります。

Give push/pull only access to developers using 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

ログインシェルは /usr/bin/git-shell に設定されており、 git push と git pull 以外は許可されていません。ユーザーはマシンへのsshアクセスを必要とします。
多くのディストリビューションでは、 /etc/shells にはログインシェルとして使用されるものをリストする必要があります。

CVS-style shared repository.

$ 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

開発者を同じgitグループに配置します。
そして、共有リポジトリをグループで書き込み可能にします。
ブランチポリシーの制御には、 Documentation/howto/ の Carl による update-hook の例を使用してください。
alice と cindy はmasterにプッシュでき、bobだけがdoc-updateにプッシュできます。 davidはリリースマネージャーであり、バージョンタグを作成してプッシュできる唯一の人物です。

GIT

Part of the git(1) suite

giteveryday(7) Manual Page

NAME

SYNOPSIS

DESCRIPTION

Individual Developer (Standalone)

Examples

Individual Developer(Participant;グループプロジェクト参加者)

Examples

インテグレーター

Examples

リポジトリ管理

Examples

GIT