Chapter 4. 他のユーザと開発を共有する

Table of Contents

git pull を使用して更新する
プロジェクトにパッチをインポートする
git リポジトリの公開

git pull を使用して更新する

リポジトリを複製し、自分でソースを変更した後には、 元のリポジトリが更新されているかを確認し、自分の作業ディレクトリ上に マージしたいと思うでしょう。

既に git-fetch(1) を用いて 外部追跡ブランチを最新に保つ方法 と2つのブランチをマージする方法を見てきました。 従って、元のリポジトリのマスターブランチの変更をマージすることができます:

$ git fetch
$ git merge origin/master

しかし、git-pull(1) コマンドを使用すれば、1回のステップで この操作を行うことができます。

$ git pull origin master

実際のところ、あなたが "master" をチェックアウトしていたなら、"git pull" はデフォルトでは 元のリポジトリの HEAD ブランチからマージを行ないます。従って たいていは単に以下のようにするだけで、上記のことが出来ます。

$ git pull

より一般的には、リモートブランチで作成されたブランチは、 デフォルトではそのブランチから pull されます。 それらデフォルト値のコントロール方法を理解するには、 git-config(1) の branch.<name>.remote と branch.<name>.merge のオプション の記述と、git-checkout(1)—track オプションの説明を参照してください。

さらに、キータイプを省略する為に "git pull" は pull 元のブランチとリポジトリを説明したデフォルトのコミットメッセージを 生成してくれます。

(しかし、fast forward の場合にはそのようなコミットは 作成されないことに注意してください;その代わり、あなたのブランチには 上流のブランチの最新のコミット位置に更新されます。)

git pull コマンドは "." を "remote" のリポジトリとして扱い、 その場合、単に現在のリポジトリからブランチにマージを行います; 従って次のコマンド

$ git pull . branch
$ git merge branch

は、大雑把に言えば同じです。前者は実際に広く一般に使われています。

プロジェクトにパッチを投稿する

行なった変更を投稿する一番簡単な方法は email でパッチとして それらの変更を送信することです。

初めに、git-format-patch(1) を使用します。;例えば:

$ git format-patch origin

により、カレントディレクトリ内に番号付けされた一連のファイルが生成されます。 それらはカレントブランチには含まれるが origin/HEAD には含まれないパッチです。

これらをあなたのメールクライアントにインポートし、手作業でそれらを 送信できます。しかし、一度にたくさん送信したい時は、むしろ git-send-email(1) スクリプトを使用してこの作業を自動化させたいでしょう。 メーリングリストで助言を求め、あなたのプロジェクトがそのようなパッチを どのように扱うことを望むのか決定すると良いでしょう。