[インデックス 15194] ファイルの概要
このコミットは、Goプロジェクトへの貢献方法を説明するドキュメント doc/contribute.html の更新に関するものです。主に、Mercurial (hg) コマンドの使用方法、コードレビュープロセス、および著作権に関するガイダンスを改善し、より明確にすることを目的としています。
コミット
commit eda9590aae3ef617a765bb5d925b8e25ca205f7f
Author: Dave Cheney <dave@cheney.net>
Date: Sun Feb 10 19:40:33 2013 -0500
doc: update contribute.html
Fixes #4582.
* mentioned hg upload.
* added section on hg file.
* added small mention about being inside $GOROOT.
* added hg revert @NNNN
* reorganise the hg submit section for the common case of a non committer.
* made the Copyright section h2
* added note about leaving copyright years unchanged.
R=golang-dev, metanata4, shivakumar.gn, minux.ma, adg, shanemhansen
CC=golang-dev, metanata4
https://golang.org/cl/7278047
GitHub上でのコミットページへのリンク
https://github.com/golang/go/commit/eda9590aae3ef617a765bb5d925b8e25ca205f7f
元コミット内容
doc: update contribute.html
このコミットは、Goプロジェクトへの貢献ガイドラインを記述した contribute.html ドキュメントを更新します。
主な変更点：
hg uploadコマンドについて言及。hg fileコマンドに関するセクションを追加。$GOROOT内での作業に関する簡単な注意書きを追加。hg revert @NNNNコマンドについて追加。- コミッターではない場合の一般的なケースに合わせて
hg submitセクションを再編成。 - Copyright セクションの見出しを
h2に変更。 - 著作権の年を変更しないことに関する注意書きを追加。
このコミットは、Issue #4582 を修正します。
変更の背景
このコミットの背景には、Goプロジェクトへの貢献プロセスをより明確にし、特にMercurial (hg) を使用したコードレビューと変更の提出に関するユーザーエクスペリエンスを向上させるという目的があります。当時のGoプロジェクトはMercurialをバージョン管理システムとして採用しており、貢献者がスムーズに作業を進められるよう、ドキュメントの精度と網羅性を高める必要がありました。
具体的には、以下の点が課題として認識されていた可能性があります。
- Mercurialコマンドの利用方法の不明瞭さ:
hg uploadやhg fileといった特定のコマンドの役割や使用例が十分に説明されていなかった。 - コードレビュープロセスの複雑さ: 変更のアップロード、レビュー依頼、他者の変更の取り込み、そして最終的な提出（コミット）までの流れが、特に非コミッターにとって分かりにくかった。
- 著作権表示に関する誤解: ファイルの著作権表示の更新ルールについて、誤解が生じる可能性があった。
- 作業環境の前提:
$GOROOT内での作業が前提となるコマンドについて、その前提が明示されていなかった。
これらの課題を解決し、新規貢献者がより容易にGoプロジェクトに参加できるようにするために、contribute.html の更新が必要とされました。
前提知識の解説
このコミットの変更内容を理解するためには、以下の前提知識が必要です。
-
Go言語プロジェクトの貢献モデル:
- Goプロジェクトは、当時Googleのコードレビューシステム（Gerritに似たもの）とMercurial (hg) を組み合わせて使用していました。貢献者はローカルで変更を加え、それをコードレビューサーバーにアップロードし、レビューを経てから公式リポジトリにマージされるというフローでした。
- Change List (CL): Goプロジェクトにおける変更の単位。Mercurialのチェンジセットに相当しますが、コードレビューシステム上で管理される一連の変更を指します。
- Committer: Goリポジトリに直接変更をコミットする権限を持つ開発者。非コミッターは、コミッターに自分の変更を提出してもらう必要があります。
- LGTM (Looks Good To Me): コードレビューにおいて、レビュアーが変更を承認する際に使用する略語。
-
Mercurial (hg):
- 分散型バージョン管理システム (DVCS) の一つで、Gitと同様にリポジトリのクローンをローカルに持ち、オフラインでの作業が可能です。
- 基本的なコマンド:
hg clone: リポジトリをクローンする。hg pull: リモートリポジトリから変更を取得する。hg update: 作業ディレクトリを特定のバージョンに更新する。hg commit: ローカルの変更をコミットする。hg push: ローカルのコミットをリモートリポジトリに送信する。
- Goプロジェクト特有のMercurial拡張: Goプロジェクトは、コードレビュープロセスを統合するためにMercurialの拡張機能（
codereview拡張）を使用していました。これにより、hg change,hg mail,hg upload,hg file,hg clpatch,hg submit,hg pendingなどのカスタムコマンドが利用可能でした。hg change <CL_ID>: 新しい変更リストを作成するか、既存の変更リストを編集する。hg mail <CL_ID>: コードレビューサーバーにアップロードされた変更をレビュアーに通知するメールを送信する。hg upload <CL_ID>: 変更をコードレビューサーバーにアップロードするが、通知は送信しない（レビュー後の修正版のアップロードなどに使用）。hg file <CL_ID> <file>: 指定したファイルを特定のCLに追加する。hg file -d <CL_ID> <file>: 指定したファイルを特定のCLから削除する。hg clpatch <CL_ID>: 他の人が作成したCLを自分のローカルリポジトリに適用する。hg submit <CL_ID>: レビューが承認されたCLを公式リポジトリにコミットする（コミッターのみ）。hg pending: 現在保留中のCLのリストを表示する。hg revert @NNNN: 特定のチェンジセット（リビジョン）の状態にファイルを戻す。@NNNNはリビジョン番号またはCL IDを指す。
-
$GOROOT環境変数:- Goのインストールディレクトリを指す環境変数。Goのツールや標準ライブラリが配置されています。Goプロジェクトに貢献する際には、通常
$GOROOTのクローン内で作業を行います。
- Goのインストールディレクトリを指す環境変数。Goのツールや標準ライブラリが配置されています。Goプロジェクトに貢献する際には、通常
これらの知識があることで、コミットがGoプロジェクトの貢献ワークフローのどの部分を改善しようとしているのか、そして各Mercurialコマンドがどのような役割を果たすのかを深く理解できます。
技術的詳細
このコミットは、doc/contribute.html ファイルに対する一連の修正を通じて、Goプロジェクトへの貢献ガイドラインの技術的な側面を強化しています。
-
$GOROOT内での作業の明示:codereview拡張が$GOROOT内でのチェックアウトでのみ有効であるという重要な前提が追加されました。これにより、ユーザーがMercurialコマンドを実行する際に、正しい作業ディレクトリにいることの重要性が強調されます。これは、Goのビルドシステムやツールが$GOROOTに依存しているため、一貫した開発環境を維持するために不可欠な情報です。
-
hg fileコマンドの詳細な説明:- 以前は簡潔だった
hg fileの説明が拡張され、特定のCLにファイルを追加 (hg file 99999 somefile) および削除 (hg file -d 99999 somefile) する具体的な構文が示されました。 - さらに、「ファイルは一度に一つのアクティブなCLにのみ属することができる」という重要な制約が明記されました。これは、複数のCL間でファイルが移動された場合に
hg fileが警告を発するという動作と合わせて、貢献者がCLの管理をより正確に行えるようにするためのものです。
- 以前は簡潔だった
-
hg uploadコマンドの導入:- レビューコメントに応じてコードを修正した後、レビュアーに通知せずに変更をコードレビューサーバーにアップロードするための
hg uploadコマンドが導入されました。これは、レビューサイクル中に頻繁に発生する修正版のアップロードにおいて、不要な通知を抑制し、レビュアーの負担を軽減するための実用的な改善です。
- レビューコメントに応じてコードを修正した後、レビュアーに通知せずに変更をコードレビューサーバーにアップロードするための
-
他者のコードレビューに関するセクションの追加:
hg clpatchとhg revert @NNNNコマンドに焦点を当てた新しいセクションが追加されました。hg clpatch 99999: 他の貢献者が提案したCLを自分のローカル作業コピーに適用する方法を説明します。これにより、レビュアーや他の開発者が提案された変更をローカルでテスト・検証することが容易になります。hg revert @99999: ローカルに適用したCLを元に戻す方法を提供します。これは、複数のCLを試したり、特定のCLの適用を取り消したりする際に非常に有用です。- これらのコマンドは、Goプロジェクトの分散型コードレビューワークフローにおいて、コラボレーションと変更の検証を効率化するための重要なツールです。
-
hg submitプロセスの再編成:- コミッターと非コミッターの
hg submitプロセスが明確に分離され、特に非コミッターのワークフローが先に説明されるように順序が変更されました。これは、非コミッターがGoプロジェクトへの貢献者の大多数を占めるため、彼らが最も関連性の高い情報を最初に見つけられるようにするための配慮です。 - 非コミッターは直接
hg submitできないため、コミッターがhg clpatchで変更を取り込み、その後hg submitするという流れが強調されています。これにより、役割分担が明確になり、混乱が少なくなります。
- コミッターと非コミッターの
-
著作権セクションの改善:
<h3>Copyright</h3>から<h2>Copyright</h2>への変更は、ドキュメントの構造とセマンティクスを改善し、著作権セクションの重要性を視覚的に高めます。- 「リポジトリ内のファイルは追加された年の著作権であり、変更するファイルであっても著作権の年を更新する必要はない」という明確な指示が追加されました。これは、著作権表示の管理を簡素化し、不必要な変更を防ぐための重要なガイドラインです。
-
Issueへのコメントの推奨:
- 変更が既存のIssueに関連する場合、提案された修正をIssueにコメントし、CLへのリンクを含めるよう推奨する文言が追加されました。これは、Issueトラッカーとコードレビューシステム間の連携を強化し、変更の追跡可能性を向上させるためのベストプラクティスです。
これらの技術的な詳細は、Goプロジェクトの貢献プロセスが、Mercurialとカスタムツールを組み合わせて、効率的かつ協調的な開発を促進するように設計されていたことを示しています。ドキュメントの更新は、この複雑なプロセスを新規および既存の貢献者にとってよりアクセスしやすく、理解しやすいものにすることを目的としています。
コアとなるコードの変更箇所
このコミットは、doc/contribute.html ファイルのみを変更しています。
--- a/doc/contribute.html
+++ b/doc/contribute.html
@@ -112,7 +112,9 @@ you are a committer (see below), but Mercurial complains if it is missing.\n
<p>\n After adding the extension, <code>hg help codereview</code>\n-will show documentation for its commands.\n+will show documentation for its commands. As the codereview extension is only\n+enabled for your checkout in <code>$GOROOT</code>, the remainder of this \n+document assumes you are inside <code>$GOROOT</code> when issuing commands.\n </p>\n \n <h3>Log in to the code review site.</h3>\n@@ -282,22 +284,37 @@ which <code>hg change</code> will print, something like:\n CL created: http://codereview.appspot.com/99999\n </pre>\n \n+<h3>Adding or removing files from an existing change</h3>\n+\n <p>\n If you need to re-edit the change description, or change the files included in the CL,\n-run <code>hg change 99999</code>. Alternatively, you can use <code>hg file 99999 somefile</code>\n-to add <code>somefile</code> to CL 99999, and use <code>hg file -d 99999 somefile</code> to remove\n-<code>somefile</code> from the CL.\n+run <code>hg change 99999</code>.\n </p>\n \n <p>\n-Creating the change uploads a copy of the diff to the code review server, but it does not\n-notify anyone about it. To do that, you need to run <code>hg mail</code> (see below).\n+Alternatively, you can use\n+<p/>\n+\n+<pre>\n+$ hg file 99999 somefile\n+</pre>\n+\n+<p>\n+to add <code>somefile</code> to CL 99999, and\n </p>\n \n+<pre>\n+$ hg file -d 99999 somefile\n+</pre>\n+\n <p>\n-You can see a list of your pending changes by running <code>hg pending</code> (<code>hg p</code> for short).\n+to remove <code>somefile</code> from the CL.\n </p>\n \n+<p>\n+A file may only belong to a single active CL at a time. <code>hg file</code>\n+will issue a warning if a file is moved between changes.\n+</p>\n \n <h3>Synchronize your client</h3>\n \n@@ -390,6 +407,12 @@ changes, but you may still need to run\n \n <h3>Mail the change for review</h3>\n \n+<p>\n+Creating or uploading the change uploads a copy of the diff to the code review server,\n+but it does not notify anyone about it. To do that, you need to run <code>hg mail</code>\n+(see below).\n+</p>\n+\n <p>To send out a change for review, run <code>hg mail</code> using the change list number\n assigned during <code>hg change</code>:</p>\n \n@@ -411,6 +434,10 @@ $ hg mail -r golang-dev@googlegroups.com --cc math-nuts@swtch.com 99999\n \n <p>Note that <code>-r</code> and <code>--cc</code> cannot be spelled <code>--r</code> or <code>-cc</code>.</p>\n \n+<p>\n+If your change relates to an open issue, please add a comment to the issue\n+announcing your proposed fix, including a link to your CL.\n+</p>\n \n <h3>Reviewing code</h3>\n \n@@ -424,7 +451,18 @@ to send comments back.\n \n <h3>Revise and upload</h3>\n \n-<p>You will probably revise your code in response to the reviewer comments.\n+<p>\n+You will probably revise your code in response to the reviewer comments. When\n+you have done this, you can upload your change to the code review server\n+without sending a notification by running <code>hg upload</code> using the change\n+list number assigned during <code>hg change</code>\n+</p>\n+\n+<pre>\n+$ hg upload 99999\n+</pre>\n+\n+<p>\n When you have revised the code and are ready for another round of review, run\n </p>\n \n@@ -445,39 +483,58 @@ The reviewer approves the change by replying with a mail that says\n <code>LGTM</code>: looks good to me.\n </p>\n \n-<h3>Submit the change after the review</h3>\n+<p>\n+You can see a list of your pending changes by running <code>hg pending</code> (<code>hg p</code> for short).\n+</p>\n+\n+<h3>Reviewing code by others</h3>\n \n <p>\n-After the code has been <code>LGTM</code>\'ed, it is time to submit\n-it to the Mercurial repository.\n-If you are a committer, you can run:\n+You can import a CL proposed by someone else into your local Mercurial client\n+by using the <code>hg clpatch</code> command. Running\n </p>\n \n <pre>\n-$ hg submit 99999\n+$ hg clpatch 99999\n </pre>\n \n <p>\n-This checks the change into the repository.\n-The change description will include a link to the code review,\n-and the code review will be updated with a link to the change\n-in the repository.\n+will apply the latest diff for CL 99999 to your working copy. If any of the\n+files referenced in CL 99999 have local modifications, <code>clpatch</code>\n+will refuse to apply the whole diff. Once applied, CL 99999 will show up in\n+the output of <code>hg pending</code> and others.\n </p>\n \n <p>\n-If your local copy of the repository is out of date,\n-<code>hg submit</code>\n-will refuse the change:\n+To revert a CL you have applied locally, use the <code>hg revert</code>\n+command. Running\n </p>\n \n <pre>\n-$ hg submit 99999\n-local repository out of date; must sync before submit\n+$ hg revert @99999\n </pre>\n \n+<p>\n+will revert any files mentioned on CL 99999 to their original state. This can\n+be an effective way of reverting one CL revision and applying another.\n+</p>\n+\n+<p>\n+Once the CL has been submitted, the next time you run <code>hg sync</code>\n+it will be removed from your local pending list. Occasionally the pending list\n+can get out of sync leaving stale references to closed or abandoned CLs. \n+You can use <code>hg change -D 99999</code> to remove the reference to CL 99999.\n+\n+<h3>Submit the change after the review</h3>\n+\n+<p>\n+After the code has been <code>LGTM</code>\'ed, it is time to submit\n+it to the Mercurial repository. \n+</p>\n+\n <p>\n If you are not a committer, you cannot submit the change directly.\n-Instead, a committer, usually the reviewer who said <code>LGTM</code>,\n+Instead a committer, usually the reviewer who said <code>LGTM</code>,\n will run:\n </p>\n \n@@ -486,19 +543,39 @@ $ hg clpatch 99999\n $ hg submit 99999\n </pre>\n \n-<p>The <code>clpatch</code> command imports your change 99999 into\n-the committer\'s local Mercurial client, at which point the committer\n-can check or test the code more.\n-(Anyone can run <code>clpatch</code> to try a change that\n-has been uploaded to the code review server.)\n The <code>submit</code> command submits the code. You will be listed as the\n author, but the change message will also indicate who the committer was.\n Your local client will notice that the change has been submitted\n when you next run <code>hg sync</code>.\n </p>\n \n+<p>\n+If you are a committer, you can run:\n+</p>\n+\n+<pre>\n+$ hg submit 99999\n+</pre>\n+\n+<p>\n+This checks the change into the repository.\n+The change description will include a link to the code review,\n+and the code review will be updated with a link to the change\n+in the repository.\n+</p>\n+\n+<p>\n+If your local copy of the repository is out of date,\n+<code>hg submit</code>\n+will refuse the change:\n+</p>\n+\n+<pre>\n+$ hg submit 99999\n+local repository out of date; must sync before submit\n+</pre>\n \n-<h3 id=\"copyright\">Copyright</h3>\n+<h2 id=\"copyright\">Copyright</h2>\n \n <p>Files in the Go repository don\'t list author names,\n both to avoid clutter and to avoid having to keep the lists up to date.\n@@ -541,3 +618,8 @@ This rigmarole needs to be done only for your first submission.\n // Use of this source code is governed by a BSD-style\n // license that can be found in the LICENSE file.\n </pre>\n+\n+<p>\n+Files in the repository are copyright the year they are added. It is not\n+necessary to update the copyright year on files that you change.\n+</p>\n```
## コアとなるコードの解説
このコミットは、Goプロジェクトの貢献ガイドラインである `doc/contribute.html` を更新し、Mercurial (hg) を使用したコードレビューと変更の提出プロセスに関する説明を改善しています。以下に主要な変更点とその解説を詳述します。
1. **`$GOROOT` 内での作業の強調**:
* 変更前: `hg help codereview` がコマンドのドキュメントを表示するとだけ記載。
* 変更後: `codereview` 拡張が `$GOROOT` 内のチェックアウトでのみ有効であること、およびドキュメントの残りの部分ではコマンド発行時に `$GOROOT` 内にいることを前提としている旨が追記されました。
* **解説**: これは、Goの開発環境のセットアップとMercurial拡張の動作に関する重要な前提条件を明確にすることで、ユーザーが正しい環境で作業を進められるようにするためのものです。Goのツールチェーンは `$GOROOT` に強く依存しており、この注意書きは潜在的な混乱を防ぎます。
2. **`hg file` コマンドの詳細化**:
* 変更前: `hg change 99999` の代替として `hg file 99999 somefile` でファイルを追加、`hg file -d 99999 somefile` でファイルを削除できると簡潔に記載。
* 変更後: `hg file` の使用例がより詳細に、独立したコードブロックで示され、さらに「ファイルは一度に一つのアクティブなCLにのみ属することができる。`hg file` はファイルが変更間で移動された場合に警告を発する」という重要な制約が追加されました。
* **解説**: `hg file` は、既存の変更リスト (CL) にファイルを追加したり削除したりするための重要なコマンドです。この変更により、その使用方法がより明確になり、特に複数のCLを扱う際のファイルの所属に関するルールが明示されました。これにより、貢献者がCLの内容を正確に管理し、意図しないファイルの移動による問題を回避できるようになります。
3. **`hg upload` コマンドの導入**:
* 変更前: レビューコメントに応じてコードを修正した後、`hg mail` を再度実行してレビューを依頼するとだけ記載。
* 変更後: レビューコメントに応じてコードを修正した後、通知を送信せずにコードレビューサーバーにCLをアップロードするために `hg upload 99999` を使用できるという新しい段落とコードブロックが追加されました。
* **解説**: `hg upload` は、レビューサイクル中にコードを修正し、その変更をレビュアーに再確認してもらう際に非常に便利です。`hg mail` と異なり、通知メールが送信されないため、レビュアーは自分の都合の良い時に変更を確認でき、不要なメールの洪水を防ぐことができます。これは、レビュープロセスの効率化に貢献します。
4. **他者のコードレビューに関する新しいセクション (`hg clpatch`, `hg revert`)**:
* 変更前: 他者のコードレビューに関する具体的なMercurialコマンドの説明は不足。
* 変更後: 「Reviewing code by others」という新しいセクションが追加され、`hg clpatch 99999` と `hg revert @99999` の使用方法が詳細に説明されました。
* `hg clpatch`: 他の人が提案したCLをローカルに適用し、テストする方法。
* `hg revert @NNNN`: ローカルに適用したCLを元に戻す方法。
* `hg change -D 99999`: 古いまたは放棄されたCLへの参照をローカルの保留リストから削除する方法。
* **解説**: これらのコマンドは、Goプロジェクトの分散型開発モデルにおいて、コラボレーションと変更の検証を促進するために不可欠です。レビュアーや他の開発者は、`hg clpatch` を使用して提案された変更を簡単にローカルで試すことができ、`hg revert` を使用してクリーンな状態に戻すことができます。これにより、コードレビューの質が向上し、問題の早期発見に繋がります。
5. **`hg submit` プロセスの再編成と明確化**:
* 変更前: コミッターが `hg submit` を実行するケースが先に説明され、非コミッターのケースがその後に続く。
* 変更後: 「Submit the change after the review」セクションが再編成され、まず非コミッターが直接コミットできないこと、そしてコミッターが `hg clpatch` と `hg submit` を使用して非コミッターの変更を代理でコミットする一般的なケースが説明されました。その後、コミッターが直接 `hg submit` するケースが改めて説明されています。
* **解説**: この再編成は、Goプロジェクトの貢献者の大多数が非コミッターであるという現実を反映しています。最も一般的なワークフローを最初に提示することで、ユーザーは自分に最も関連性の高い情報を迅速に見つけることができます。また、コミッターと非コミッターの役割分担と、変更が最終的にリポジトリにマージされるまでの具体的なステップがより明確になりました。
6. **著作権セクションの改善**:
* 変更前: `<h3>Copyright</h3>` という見出し。著作権の年に関する具体的な指示はなし。
* 変更後: 見出しが `<h2>Copyright</h2>` に変更され、新しい段落で「リポジトリ内のファイルは追加された年の著作権であり、変更するファイルであっても著作権の年を更新する必要はない」という明確な指示が追加されました。
* **解説**: 見出しの変更は、ドキュメント構造における著作権セクションの重要性を高めます。著作権の年に関する指示は、不必要なファイル変更を防ぎ、著作権表示の一貫性を保つための重要なガイドラインです。これは、オープンソースプロジェクトにおける著作権管理のベストプラクティスに沿ったものです。
7. **Issueへのコメントの推奨**:
* 変更前: Issueへのコメントに関する指示はなし。
* 変更後: 「変更がオープンなIssueに関連する場合、提案された修正をIssueにコメントし、CLへのリンクを含めるようお願いします」という新しい段落が追加されました。
* **解説**: これは、Issueトラッカーとコードレビューシステム間の連携を強化するためのものです。IssueにCLへのリンクを張ることで、関連する議論や進捗状況を容易に追跡できるようになり、プロジェクト管理の透明性が向上します。
これらの変更は、Goプロジェクトへの貢献プロセスをより効率的、明確、かつユーザーフレンドリーにするための包括的な取り組みの一環です。特に、Mercurialコマンドの具体的な使用例と、コミッターと非コミッターの間のワークフローの明確化は、新規貢献者にとって大きな助けとなります。
## 関連リンク
* Go言語公式ウェブサイト: [https://go.dev/](https://go.dev/)
* Mercurial公式ウェブサイト: [https://www.mercurial-scm.org/](https://www.mercurial-scm.org/)
* Goプロジェクトの貢献ガイドライン (現在のバージョン): [https://go.dev/doc/contribute](https://go.dev/doc/contribute) (このコミットで変更されたドキュメントの現在の状態)
* GoプロジェクトのIssueトラッカー: [https://go.dev/issue/](https://go.dev/issue/)
## 参考にした情報源リンク
* Goプロジェクトの当時のコードレビューシステムに関する情報 (2013年頃のGoの貢献プロセスを理解するために):
* "Go Code Review Comments" (当時のコードレビューの慣習): [https://go.dev/doc/effective_go#code-review](https://go.dev/doc/effective_go#code-review) (現在のドキュメントですが、当時の慣習を反映している可能性があります)
* Mercurialの `codereview` 拡張に関する情報 (当時のGoプロジェクトのMercurial拡張の動作を理解するために): [https://go.dev/doc/contribute#codereview](https://go.dev/doc/contribute#codereview) (現在のドキュメントですが、当時の拡張機能について言及している可能性があります)
* Mercurialコマンドに関する一般的なドキュメント:
* Mercurial: The Definitive Guide (オンライン版): [https://www.mercurial-scm.org/wiki/Book](https://www.mercurial-scm.org/wiki/Book)
* `hg help` コマンドの出力 (Mercurialの各コマンドの詳細な説明): ローカルのMercurialインストールで `hg help <command>` を実行。
* 分散型バージョン管理システム (DVCS) に関する一般的な情報。
* オープンソースプロジェクトにおける著作権表示に関する一般的な慣習。