開発者用Git
このドキュメントは、あなたがGitを使用してMoodle開発を始めるための参考となる資料です。MoodleのGitに関する詳細情報はCategory:Gitをご覧ください。
一般的なワークフロー
手短に言えば、Gitを使用したMoodleの開発手順は下記のようになります:
- コード提供者 (contributor ) として、あなたのコンピュータ内のパーソナルリポジトリに変更内容をコミットします。
- あなたのパブリックリポジトリに変更内容をプッシュ (push) して、その変更内容のリンクをMoodle Trackerに公開します。
- あなたは他の開発者にピアレビューを依頼することもできます (お勧めしますが、任意です)。
- あなたのコードに自信がある場合、統合のために送信してください (統合リクエスト (integration request)、プルリクエスト (pull request) としても知られています)。
- Moodleインテグレータはパブリックリポジトリより変更内容を取得 (pull) した後、気に入った場合はMoodle統合リポジトリに入れます。
- 統合された変更内容はテストされた後、最後にMoodleプロダクションリポジトリにプッシュ (push) されます。
- あなたのローカルリポジトリをプロダクションリポジトリのすべての変更をもとに更新して、再度次のサイクルを開始することができます。
このワークフローは大まかに1週間のサイクルで回ります。月曜日に統合が実施された後、火曜日にテストされます。通常、水曜日に前の週の開発での変更をもとに、公開moodle.gitが更新されます。
ほとんどのMoodle開発者はGithubに自分のパブリックリポジトリを持っています。あなたは代わりにGitoriousまたは伝説的なrepo.or.czを利用することもできます。このガイドの例では、あなたのパブリックリポジトリをGithubにセットアップしていると想定します。
あなたのコンピュータにGitをインストールする
あなたのコンピュータにGitをインストールします。ほとんどのLinuxディストリビューションにはパッケージとしてインストールできるGitがあります。あなたがMacを使用している場合、数回のクリックにより、git-osx-installerを使ってGitをインストールすることができます。
インストール直後に、あなたの名前および連絡先メールアドレスを設定してください。あなたの名前およびメールアドレスはコミット (commit) の一部となりますが、あなたのコミットがMoodleコード内に受け入れられた場合、後で変更することができなくなります。そのため、私たちはコード提供者に先頭に大文字を使った本名を使用するよう依頼しています: 例 "john smith" または "john5677" 等ではなく、"John Smith"
git config --global user.name "Your Name" git config --global user.email yourmail@domain.tld
あなたがリポジトリの管理者ではない場合、ファイルパーミッションにおいて、Gitが変更内容をpushしないよう設定することは賢明なことです:
git config --global core.filemode false
パブリックリポジトリをセットアップする
1. Githubにアクセスして、アカウントを作成してください。
2. 公式Moodle Githubリポジトリにアクセスして、「Fork」ボタンをクリックしてください。
3. ローカルMoodleリポジトリからGithub Moodleリポジトリにプッシュ (push) できるよう、あなたはSSHパブリックキーを設定する必要があります。あなたがMacを使用している場合、Githubヘルプページを参考にすることができます。あなたが別のシステムを使用している場合、Github管理ページのSSHパブリックキー (SSH Public Keys) セクションに移動することにより、ヘルプページへのリンクが表示されます。表示されましたか? 素晴らしい! これが最も難しい部分です!
あなたのコンピュータにローカルリポジトリをセットアップする
あなたのGithubリポジトリのローカルクローンリポジトリを作成してください。ターミナルでのコマンドは次のとおりです:
git clone git@github.com:YOUR_GITHUB_USERNAME/moodle.git YOUR_LOCAL_MOODLE_FOLDER
このコマンドは複数の処理をあなたのために実施します。新しいフォルダを作成、その中の空のGitリポジトリを初期化、あなたのGithubリポジトリをリモートリポジトリ「origin」として設定、「origin」からブランチ「master」のローカルチェックアウトを作成します。記憶すべき重要な点は、あなたのGithubリポジトリのローカルクローンでの別名が「origin」になったことです。
あなたのパブリックリポジトリを最新の状態にしておく
あなたがGithubから分岐させたデータは自動的に更新されるわけではありません。上流 (upstream) のMoodleリポジトリの同期を継続するには、公式moodle.gitより最新の修正部分を取得して、あなたのパブリックリポジトリにプッシュ (push) する必要があります。トラブルを避けるため、標準Moodleブランチを修正しないことを強くお勧めします。注意: masterおよび MOODLE_xx_STABLEブランチに直接コミットしないでください。言い換えれば、作業のためには常にトピックブランチを作成することです。Gitに関して言えば、masterブランチおよびMOODLE_xx_STABLEブランチは常にfast-forwardできるようになっているべきです。
あなたのパブリックリポジトリを最新にするために、上流 (upstream) のエイリアスとしてリモートリポジトリ git://git.moodle.org/moodle.git を登録します。そして、私たちは上流 (upstream) リポジトリから変更内容を取得するための定期的に実行されるスクリプトを作成して、あなたのパブリックリポジトリにプッシュ (push) します。この処理はあなたのローカル作業ディレクトリに影響を及ぼさないことに留意してください。
上流 (upstream) をリモート (remote) に登録するには:
git remote add upstream git://git.moodle.org/moodle.git
下記のコマンドにより、あなたのGithubリポジトリの標準Moodleブランチの上流 (upstream) リポジトリとの同期を保持することができます。このコマンドをスクリプトに保存して、毎週上流 (upstream) リポジトリが更新された後に実行しても良いでしょう。
git fetch upstream
for BRANCH in MOODLE_19_STABLE MOODLE_20_STABLE MOODLE_21_STABLE master; do
git push origin refs/remotes/upstream/$BRANCH:$BRANCH
done
どのように動作するのか
git-fetchコマンドが現在の作業ディレクトリ (あなたのチェックアウト) を更新することはありません。リモートリポジトリから変更内容すべてをダウンロードして、「remote-trackingブランチ」と呼ばれるブランチの中に保存します。git-pushコマンドはこれらのremote-trackingブランチを上流 (upstream) から取得して、同一名のGithubにプッシュ (push) します。これを完全に理解するには、Git内部に関する知識が少しだけ必要です - 詳細はgitrevisions(7) manページをご覧ください。
この間にローカルブランチをスイッチする必要はないことに留意してください。あなたのマシンのcronを使って、この処理を自動実行することができます。通常、上流 (upstream) のリポジトリは週1回更新されることに留意してください。
パッチを準備する
このページで先述したように、あなたが標準Moodleブランチで直接作業することはありません。あなたはローカルブランチにスイッチして、何かを編集することになります。まず、あなたがマージ (merge 結合) させたい標準ブランチからローカルブランチを分岐 (fork) させてください。例えば、あなたが1.9または2.0のパッチに関して作業している場合、それぞれMOODLE_19_STABLEまたはMOODLE_20_STABLEからブランチを分岐させてください。次のメジャーバージョンに対するパッチ作業では、マスターブランチがベースとされます。
git checkout -b MDL-xxxxx-nasty-bug origin/master
あなたが特定の開始点を忘れた場合、現在のチェックアウトブランチがブランチとなることに留意してください。これはあなたが望むところではないでしょう。ですから、常に開始点 (starting point) を指定することをお勧めします。
現在のブランチをチェックするには、下記のコマンドを実行してください。
git branch
現在のブランチがハイライト (強調) されます。
あなたの好きなIDE (Integrated development environment 統合開発環境) を使って問題点を修正してください。ファイルのステータスをチェックして、コミットする予定の修正を確認した後、最後にコミットします:
vim filename.php git status git diff git commit -a
これはローカルにのみコミットが記録されるだけで安全であり、まだサーバには何も送信されていないことに留意してください (CVSでは送信されていましたが)。コミットの履歴を閲覧するには、下記のコマンドを使用してください。
git log
あなたのローカルブランチに修正内容 (いくつかのパッチで構成されます) が含まれている場合、また、その内容で大丈夫だと思う場合、あなたのパブリックリポジトリにプッシュ (push) してください:
git push
私たちが明確にリモートリポジトリを指定しなかったため、「origin」が使われます。また、私たちがプッシュ (push) するためのブランチを指定しなかったため、gitは現在のブランチを使用して、同じ名称のリモートリポジトリにプッシュ (push) します (デフォルトでは、これはあなたの設定に依存します。詳細は、push.defalt設定変数を確認してください)。
これで、あなたのブランチは公開され、Moodleのコア開発者にレビューを依頼することができます。結果として、あなたのブランチが標準Moodleリポジトリに統合される可能性もあります。
すでにブランチがマージされている場合、チェックする
Moodleに何回かコードを投稿した後、あなたのローカルリポジトリおよびパブリックリポジトリ両方に多くのブランチを持つことになるでしょう。それらのリストを取り除いて、上流 (upstream) でアクセプトされたブランチを削除するには、以下のコマンドを使用してください。
git fetch upstream (1) git branch --merged upstream/master (2) git branch --merged upstream/MOODLE_20_STABLE (3)
コマンド (1) では、git.moodle.orgの上流 (upstream) リポジトリから修正内容を取得します (あなたの作業ディレクトリをgit-fetchが修正することはないため、このコマンドは常に安全に実行することができます)。コマンド (2) および (3) では、それぞれ上流 (upstream) およびMOODLE_20_STABLEにマージされるブランチすべてを表示します。これらのブランチを削除するには下記のコマンドを実行してください。
git branch -d MDL-xxxxx-accepted-branch
github.comに公開されたあなたのoriginリポジトリをチェックするため、下記のように似たようなアプローチを取ることができます。
git fetch origin (1) git fetch upstream git branch -r --merged upstream/master (2) git branch -r --merged upstream/MOODLE_20_STABLE (3)
コマンド (1) では、あなたがgithub.comのリモート追跡用ブランチとして保存したローカルブランチに、github.comのブランチすべてが保存されることを確実にします。コマンド (2) および (3) では、前述の例と同様の動きをしますが、前述の例はリモート追跡リポジトリを一覧表示するのみです (詳細は -r パラメータをご覧ください)。github.comからブランチを削除するには、下記コマンドを使用してください。
git push origin :MDL-xxxx-branch-to-delete
あなたにとって、この構文は奇妙に映るかもしれません。しかし、これは非常に道理に適った構文です。git-pushコマンドの一般的な構文は下記のようになります。
git push <repository> <source ref>:<target ref>
ですから、「空 (null) の参照」をプッシュ (push) することにより、リモートブランチが削除されることは理解できるでしょう。
他の人のコードをピアレビュー (Peer-reviewing 査読) する
誰かが自身のパブリックリポジトリにプッシュ (push) したブランチをレビューする場合、あなたは新しいリモート (remote) を登録する必要はありません (もちろん、あなたが頻繁にそのリポジトリで作業している場合を除きます)。例えば、アリスが作業中のブランチ「wip-feature」をGithubリポジトリにプッシュ (push) して、あなたにレビューを依頼したとしましょう。あなたは読み出し専用 (read-only) のリポジトリアドレスおよびブランチ名を知っている必要があります。
git fetch git://github.com/alice/moodle.git wip-feature
このコマンドでは必要なデータすべてのファイルをダウンロードして、ローカルのシンボル参照「FETCH_HEAD」内のブランチ「wip-feature」の先頭にポインタを配置します。そのブランチに何があるか確認するには、次のコマンドを使います:
git log -p FETCH_HEAD
アリスのブランチ内にある特定のファイルを表示するには次のコマンドを使います:
git show FETCH_HEAD:admin/blocks.php
アリスの開発作業を含む「alice-wip-feature」という名称の新しいローカルブランチを作成するには次のコマンドを使います:
git checkout -b alice-wip-feature FETCH_HEAD
アリスの開発作業をあなたの現在のブランチにマージするには次のコマンドを使います:
git merge FETCH_HEAD
実際に何も変更せずに、現在のブランチに何がマージされるか確認するには次のコマンドを使います:
git diff ...FETCH_HEAD
ブランチをリベースする
リベースとは、あなたが現在のスタートポイントからブランチを切り離して、別のポイントに移植することを指します。それでは、次のような履歴があると仮定しましょう:
A---B---C topic
/
D---E---F---G master
このポイントから次のコマンドを実行すると:
git rebase master topic
次のようになります:
A'--B'--C' topic
/
D---E---F---G master
そして、結果として「topic」があなたの現在のブランチとなります。
送信されたブランチが古いコミットをベースにしていた場合、あなたは統合のために送信したブランチをリベースするよう求められることでしょう。 典型的な例として、あなたが火曜日の上流 (upstream) マスターからフォーク (fork 分岐) した新しいブランチを作成したとしましょう。そして水曜日、最新の統合サイクルから変更内容すべてがマージされたため、上流 (upstream) マスターブランチが大きくなったとします。次週のレビューのプルリクエストでGithubのdiffを簡単に作成できるよう、あなたのブランチを更新済みマスターに対してリベース (rebase) しても良いでしょう。
git rebase master MDL-xxxxx-topic-branch
効果的にリベースするには、ブランチの履歴を書き換える必要があることに留意してください。他の人がすでにフォーク (fork 分岐) して、そこを自分のブランチのベースとしている場合、ブランチをリベースしないでください。 この理由から、多くのGitチュートリアルでは公開されているブランチからのリベースを推奨していません。しかし、Moodleにおいて、統合のために送信されたすべてのブランチは、私たちがそうならないように心がけたとしても、潜在的にリベースの問題に晒されてしまいます。ですから、私たちは、あなたのブランチをそれらのブランチのベースとならないよう、留意すべきです。
リベース内のコンフリクト(conflict 競合状態)
リベース処理中、コンフリクト (conflict 競合状態) が発生する可能性があります。git-statusコマンドでは、コンフリクトを起こしたファイルを確認します。内容を慎重に確認した後、あなたがCVSで経験したように、エディタで修正してください。そして、ファイルを 'git add' コマンドで追加して、リベースを続けてください。
vim conflicted.php git add conflicted.php git rebase --continue
1つのブランチから別のブランチに対して変更を適用する
ほとんどのバグは、MOODLE_20_STABLEのようなステイブルブランチ (stable branch) で修正されています。また、MOODLE_21_STABLEおよびメインの開発者ブランチ (master) を含む他のブランチに関しても修正が準備されています。Moodleにおいて、私たちはステイブルブランチをマスターブランチにマージすることはありません。そのため、通常、コントリビュータは少なくともステイブルブランチの修正用およびマスターブランチの修正用の2つのブランチを準備する必要があります。
例えば、MDL-xxxx-topic_20_STABLEのように、あなたにローカルブランチ上で準備したパッチがある場合、別のブランチに再適用することができます。
単一のコミットをチェリーピック (cherry-pick) する
Moodle 2.1のローカルインストール「 ~/public_html/moodle21 」および最新開発版のローカルインストール「 ~/public_html/moodledev 」の2つのローカルGitリポジトリを作成したとしましょう。両者とも、あなたのgithub.comにあるパブリックリポジトリをベース (origin) として使います。あなたには、 MOODLE_21_STABLEから取り出した (forked off) MDL-xxxx-topic_21_STABLEと呼ばれるブランチがあります。このブランチには、1件のコミットを含みます。さて、あなたはこのコミットをmoodledev内のブランチMDL-xxxx-topicに再適用したいと思っています。
cd ~/public_html/moodledev git checkout -b MDL-xxxx-topic origin/master (1) git fetch ../moodle21 MDL-xxxx-topic_21_STABLE (2) git cherry-pick FETCH_HEAD (3)
コマンド (1) では、 CONTHEREから取り出した (forked off) ローカルブランチを新しく作成します。コマンド (2) では、対象ブランチに再適用する必要のあるデータすべてを取得して、そのブランチに関して、FETCH_HEADシンボリックリファレンスの先頭にポインタを格納します。 コマンド (3) ではブランチの先頭 (コミットの最上位) を選択して、現在のブランチへの適用を試みます。複数のコマンドをサポートするチェリーピックコマンドの変形版 (詳細はmanページをご覧ください) もありますが、そのような状況に関して、私たちは別のアプローチを取ります。
一連のパッチを適用する
前の例のブランチMDL-xxxx-topic_21_STABLEが複数のコミットから成る場合、git-format-patchおよびgit-amの組み合わせにより、一連のパッチ (patchsetと呼ばれます) の再適用が簡単になります。あなたは最初にトピックブランチのコミットすべてをファイルにエクスポートします。
cd ~/public_html/moodle21 mkdir .patches git format-patch -o .patches MOODLE_21_STABLE..MDL-xxxx-topic_21_STABLE (1)
コマンド (1) では、MOODLE_21_STABLE内に存在しないトピックブランチからすべてのコミットを取得して、ひとつずつ出力用ディレクトリ「.patches」にエクスポートします。生成されたファイルを閲覧してください。diffフォーマットのパッチファイルおよびコミットに関する追加情報が含まれているはずです。例えば、あなはこれらのファイルをピアレビューのため、友だちにメール経由で送信することができます。私たちはこれらのファイルを別のリポジトリに使用します。
cd ~/public_html/moodledev git checkout -b MDL-xxxx-topic origin/master git am -3 ../moodle21/.patches/* (1)
コマンド (1) では、.patchesディレクトリからすべてのファイルにパッチを適用します。パッチが適切に適用されなかった場合、コマンドは3回のマージをトライします (-3 パラメータをご覧ください)。処理中にコンフリクト (conflict 衝突) が発生した場合、あなたは `git am --continue` コマンドを使って対処するか、`git am --abort` コマンドを使って全体の処理を中止することができます。
関連情報
- Moodleフォーラムディスカッション
- GITに関して教えてください - 英語
- GITでCONTRIBコードを管理するベストな方法 - 英語
- サードパーティモジュールおよびプラグインを追跡するGitに関する便利なヒント - 英語
- Moodle Gitリポジトリ - 英語
- Gitを教えてください!! リベースが分かりません ... - 英語
- 外部リソース
- Everyday GIT With 20 Commands Or So - 英語
- Git Reference - 英語
- Pro Git book - 英語
