約20個のコマンドによる日々のGIT活用

他のユーザとパッチを交換せずに一つのレポジトリ内で単独で作業するような、 独立した個々の開発者は、下記のコマンドを使います。

• git-init(1) は新しいレポジトリを作成します。

• git-show-branch(1) はあなたがどこにいるかを見ることが出来ます。

• git-log(1) は何が起きてきたかを見ることが出来ます。

• git-checkout(1) と git-branch(1) はブランチを切り替えます。

• git-add(1) はインデックスファイルを管理します。

• git-diff(1) と git-status(1) は、 あなたの途中経過を確認します。

• git-commit(1) は現在のブランチを前進させます。

• git-reset(1) と git-checkout(1) (パス名パラメータ付き) は変更を元に戻します。

• 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)

1. 現在ディレクリ以下全てを追加

2. 軽量で注釈の無いタグを作る

トピックブランチの作成と開発。

$ git checkout -b alsa-audio (1)
$ edit/compile/test
$ git checkout -- 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 reset --soft HEAD^ (6)
$ edit/compile/test
$ git diff ORIG_HEAD (7)
$ git commit -a -c ORIG_HEAD (8)
$ git checkout master (9)
$ git merge alsa-audio (10)
$ git log --since='3 days ago' (11)
$ git log v2.43.. curses/ (12)

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

2. `curses/ux_audio_oss.c`における失敗した変更を元に戻す。

3. 新しいファイルを追加した場合は、gitに伝える必要があります; 削除と変更については後から`git commit -a`を実行すれば補足されるでしょう。

4. コミットしたときから何が変わったのかを確認することが出来ます。

5. あなたがテストをしているものとして、あなたの署名付きで全てをコミットします。

6. ワーキングツリーの状態は保持したまま、一つ前のコミットの状態に戻します。

7. (訳注: git reset等を使い)元に戻した早まったコミットからの変更を見る。

8. あなたが最初に書いたメッセージを使い、もう一度コミットを前回の状態に戻す

9. masterブランチに切り替え

10. トピックブランチをmasterブランチにマージ

11. コミットログを見直す; 出力の制限--max-count=10 (10コミット分表示)等、 他の形式を連結したり組み合わせることが出来ます。 その他には以下のようなものもあります`--until=2005-12-10`。

12. タグv2.43以降、`curses/`ディレクトリに触った変更のみ表示

グループプロジェクトに参加する開発者は、単独の開発者にとって必要なものに加え、 他者とのコミュニケーションの仕方と、これらのコマンドを学ぶ必要があります。

• git-clone(1) は上流のリポジトリを複製(clone)し、 自分用のローカルリポジトリを作成します。

• "origin"からのgit-pull(1) と git-fetch(1) は、 上流との最新の状態を保ちます。

• git-pull(1) と git-fetch(1) は、 "origin" にある上流の情報を最新に保ちます。

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

• git-format-patch(1) はLinuxカーネル形式の公式討論型 ワークフローを採用している場合に、e-mailによる提案の準備を行います。

Examples

上流から複製(clone)して作業した後、変更を上流へ送る。

$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ edit/compile/test; git commit -a -s (1)
$ git format-patch origin (2)
$ git pull (3)
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (4)
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (5)
$ git reset --hard ORIG_HEAD (6)
$ git gc (7)
$ git fetch --tags (8)

1. 必要なだけ繰り返します。

2. emailで提案する為、あなたのブランチからパッチを抽出します。

3. `git pull`は、通常`origin`から変更を取得し、現在のブランチへマージします。

4. プルした直後、興味があるエリアのみ、前回チェックした時からの上流による変更を確認します。

5. レポジトリとブランチを指定し、取得後にマージします。

6. プルした状態を元に戻します。

7. プルした状態から元に戻した際、残されたオブジェクトをガベージコレクトします。

8. 時々、公式なタグを origin から手に入れ、 .git/refs/tags/ 以下へ格納します。

他のレポジトリへpushする。

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 \
           master:refs/remotes/satellite/master (3)
satellite$ edit/compile/test/commit
satellite$ git push origin (4)

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

1. mothershipマシンはホームディレクトリ以下にfrotzレポジトリを持っています; そこからクローンし、satelliteマシン上のレポジトリを開始します。

2. クローンすると、これらの環境変数がデフォルトで設定されています。 mothershipマシンのブランチからローカルのremotes/origin/* 追跡ブランチに取得し格納するよう、`git pull`が変更されています。

3. ローカルの`master`ブランチから、mothershipマシンの `remotes/satellite/master`ブランチへプッシュするよう、`git push`を変更します。

4. pushは私たちの作業を遠方のmothiershipマシンの 追跡ブランチ、`remotes/satellite/master`に格納するでしょう。 これはバックアップとしても使えます。

5. mothershipマシン上で、satelliteマシン上で完了した作業を masterブランチへマージします。

特定タグのブランチを切る。

$ git checkout -b private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
  git am -3 -k (2)

1. 既知の(ただし幾分過去の)タグから、プラベートなブランチを作成 。

2. 通常のマージを使わずに、`private2.6.14`ブランチの全ての変更を `master`ブランチへ転送する

インテグレーターとしてふるまう人は、グループプロジェクトにおいてかなりの中心人物です、 他の人によって作られた変更を受け取り、それらのレビューと統合を行い、 他の人が使えるようにするため結果を公開します、参加者(participants)が 必要なものに加え、これらのコマンドを使います。

• git-am(1) は、(パッチの)寄稿者からe-mailされたパッチを適用します。

• git-pull(1) は、あなたの信用している副官(の修正)をマージします。

• git-format-patch(1) は、寄稿者への代案の準備と送信を行います。

• git-revert(1) はやり損なったコミットを元に戻します。

• git-push(1)は新しいテクノロジーを公開します。

Examples

私の典型的なGITの一日。

$ git status (1)
$ git show-branch (2)
$ mailx (3)
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git checkout -b topic/one master
$ git am -3 -i -s -u ./+to-apply (4)
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus (5)
$ git checkout topic/one && git rebase master (6)
$ git checkout pu && git reset --hard next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git checkout maint
$ git cherry-pick master~4 (9)
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
$ git fetch ko && git show-branch master maint 'tags/ko-*' (11)
$ git push ko (12)
$ git push ko v0.99.9x (13)

1. 何か作業途中のものが無かったか確認します。

2. 作っていたり準備しようとしていたトピックブランチがないか確認します。

3. メールを読みます、適用可能なものはセーブし、準備が完全に 整っていないものは違う場所にセーブします。

4. それらを対話的に、私の署名を付け、適用していきます。

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

6. 内部のトピックブランチをリベースします、まだマスターにもマージされませんし、 安定ブランチとして公開もされません。

7. pu(訳注:proposed updates=提案された更新 の略)は常にnextから再開します。

8. そしてトピックブランチをバンドルし、調理を進めていきます。

9. 重大な修正をバックポートします。

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

11. 意図せず、すでにpushしたバージョンよりもマスターを巻き戻してしまっていないか確認します。 `ko`は、私がkernel.orgに持っているレポジトリを簡潔に表したもので、このようになっています:

    $ cat .git/remotes/ko
    URL: kernel.org:/pub/scm/git/git.git
    Pull: master:refs/tags/ko-master
    Pull: next:refs/tags/ko-next
    Pull: maint:refs/tags/ko-maint
    Push: master
    Push: next
    Push: +pu
    Push: maint

    `git show-branch`の出力の中で、`master`は`ko-master`の持つ 全てを持っているべきであり、`next`は`ko-next`の持つ全てを 持っているべきです。

12. 新しい修正をプッシュします。

13. タグもプッシュします。

レポジトリ管理者は以下のツールを使い、デベロッパによるレポジトリアクセスの セットアップとメンテナンスを行います。

• git-daemon(1) レポジトリから匿名でダウンロード することを許可します。

• git-shell(1) は共有中央レポジトリのユーザーのために、 '制限されたログインシェル'のようなものが使えます。

update hook howto には 共有中央レポジトリ管理の良い例が載っています。

Examples

We assume the following in /etc/services

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

git-daemonを起動し、inetdから/pub/scmに供給します。

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

実際の設定行は一行にする必要があります。

git-daemonを起動し、xinetdから/pub/scmに供給します。

$ 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システムのものです。 他では違うかもしれません。

push/pull専用のアクセスを開発者に与える。

$ 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. update-hookの例は、Carlによって書かれた、Documentation/howto/にある ブランチポリシーの管理(branch policy control)を使って下さい。

4. aliceとcindyはマスターブランチに対してプッシュ出来ます、bobはdoc-updateにのみプッシュできます。 davidはリリースマネージャーであり、バージョンタグの生成とプッシュが行える 唯一の人物です。

HTTPサーバーがダム(dumb)プロトコルによる転送をサポートします。

dev$ git update-server-info (1)
dev$ ftp [email protected] (2)
ftp> cp -r .git /home/user/myproject.git

1. info/refsやobjects/info/packsが更新されているか確認します。

2. あなたのプロバイダがホスティングしている公開HTTPサーバーにアップロードします。