「Tezos開発への貢献方法」の版間の差分
(ページの作成:「= How to contribute = == Introduction == The purpose of this document is to help contributors get started with the Tezos OCaml codebase. == First steps == First, make...」) |
|||
1行目: | 1行目: | ||
− | = | + | =貢献する方法= |
− | == | + | ==はじめに== |
− | + | このドキュメントの目的は、貢献者がTezos OCamlコードベースを使い始めるのを支援することです。 | |
− | == | + | ==最初のステップ== |
− | + | まず、OCamlで十分に熟達していることを確認してください。以下のコミュニティウェブサイトhttp://www.ocaml.orgは、そのためのいくつかの指針を示しています。特に、私たちは多くのファンクタとコードベースのいくつかのGADTを使用していますので、これらの高度な概念をマスターすることをお勧めします。 | |
− | + | あなたがLwtライブラリについてよく知らないのなら、それはあなたが学びたいものです。このライブラリは、コードベース全体で広く使用されています。これは同時実行性を処理するために使用されるもので、Tezosは非常に並行したシステムです。 <code>オンラインドキュメント<https://ocsigen.org/lwt/3.2.1/manual/manual> </code> '' 'を使用できます。 <code> Real World OCaml <https://github.com/dkim/rwo-lwt> </code> '' 'の並行性に関する章もLwtに移植されています。 | |
− | + | その後、私たちが使用している2つの自家製ライブラリ:ref:<code> error_monad <error_monad> </code>と:ref:<code> data_encoding&lt; data_encoding&gt; </code>のチュートリアルを読むことは、普及する。 | |
− | == | + | ==どこから始めるか== |
− | + | 上に示唆したように基本を熟知している間に、Tezosの:ref:<code>ソフトウェアアーキテクチャー&lt; software_architecture&gt; </code>を見ることができます。主なコンポーネントとその相互作用、そしてさまざまなパーツのドキュメントへのリンクを提供します。 | |
− | == | + | ==私たちのgitワークフロー== |
− | + | まず、リポジトリはhttps://gitlab.com/tezos/tezosです.githubは歴史的な理由から存在するクローンです。だから貢献したいのであれば、アカウントを作成するだけです。 | |
− | + | 次に、Gitを使用する方法はたくさんありますが、ここでは私たちがあります。 | |
− | + | ほとんどの場合、マージ要求を使用してマスターにプッシュします。意味は、誰も直接マスターにプッシュする必要はありません。マージリクエストが準備完了したら、それを見直して承認します.Gitの<code> - fast-forward </code>オプションを使ってマージします。マージパッチなしで線形履歴を維持します。 | |
− | + | これが機能するには、マージリクエストがマスターブランチの直接サフィックスでなければならないということです。したがって、<code> origin / master </code>が変更されたときはいつでも、ブランチをブランチにリベースして、パッチが常にマスターの上に置かれるようにする必要があります。これが起こると、リベース中にパッチを編集し、ブランチの<code> push -f </code>を使って履歴を書き直す必要があります。 | |
− | + | また、いくつかの衛生ルールを適用していますので、MRがそれらを尊重していることを確認してください: | |
− | * | + | *小さな原子は、多くのことをする大きな原子よりも優先します。 |
− | * | + | *リファクタリングと新機能を混在させないでください。 |
− | * | + | *再インデント、空白の削除、または他のスタイルの変更を実際のコード変更と混同しないでください。 |
− | * | + | *最後のパッチだけでなく、すべてのパッチをコンパイルするために可能な限り試してください。 |
− | * | + | *ドキュメント化されたインターフェイスに新しい機能を追加する場合は、ドキュメントを拡張することを忘れないでください。 |
− | * | + | *仕様がリポジトリにある部品(たとえば、Michelson)の場合は、実装と同期させてください。 |
− | * | + | *コミットメッセージのスタイルを模倣してみてください。単純なコミットでは、拡張コミットメッセージを追加してください。 |
− | + | MR自身の衛生状態に応じて: | |
− | * | + | * MRに適切なタイトルをつけてください。自明ではない場合、詳細な動機付けされた説明を追加してください。 |
− | * | + | *ブランチに意味のある一貫した名前を付ける。 |
− | * | + | *進行中の作業中に<code> WIP:</code>フラグを置くことを忘れないでください |
− | + | いくつかの追加のCIテストは、マスタ以外のブランチに対してオンデマンドでのみ実行されます。ブランチ名にキーワードを含めることで、これらのテストをアクティブにすることができます。 | |
− | + | * MRがOPAMのパッケージングに影響する場合は、支店名に<code> opam </code>を使用してください。 | |
− | * | + | * MRがドキュメントを更新する場合は、ブランチ名に<code> doc </code>を使用してください。 |
− | * |
2018年5月30日 (水) 23:58時点における最新版
貢献する方法[編集]
はじめに[編集]
このドキュメントの目的は、貢献者がTezos OCamlコードベースを使い始めるのを支援することです。
最初のステップ[編集]
まず、OCamlで十分に熟達していることを確認してください。以下のコミュニティウェブサイトhttp://www.ocaml.orgは、そのためのいくつかの指針を示しています。特に、私たちは多くのファンクタとコードベースのいくつかのGADTを使用していますので、これらの高度な概念をマスターすることをお勧めします。
あなたがLwtライブラリについてよく知らないのなら、それはあなたが学びたいものです。このライブラリは、コードベース全体で広く使用されています。これは同時実行性を処理するために使用されるもので、Tezosは非常に並行したシステムです。 オンラインドキュメント<https://ocsigen.org/lwt/3.2.1/manual/manual>
'を使用できます。 Real World OCaml <https://github.com/dkim/rwo-lwt>
'の並行性に関する章もLwtに移植されています。
その後、私たちが使用している2つの自家製ライブラリ:ref: error_monad <error_monad>
と:ref: data_encoding&lt; data_encoding&gt;
のチュートリアルを読むことは、普及する。
どこから始めるか[編集]
上に示唆したように基本を熟知している間に、Tezosの:ref:ソフトウェアアーキテクチャー&lt; software_architecture&gt;
を見ることができます。主なコンポーネントとその相互作用、そしてさまざまなパーツのドキュメントへのリンクを提供します。
私たちのgitワークフロー[編集]
まず、リポジトリはhttps://gitlab.com/tezos/tezosです.githubは歴史的な理由から存在するクローンです。だから貢献したいのであれば、アカウントを作成するだけです。
次に、Gitを使用する方法はたくさんありますが、ここでは私たちがあります。
ほとんどの場合、マージ要求を使用してマスターにプッシュします。意味は、誰も直接マスターにプッシュする必要はありません。マージリクエストが準備完了したら、それを見直して承認します.Gitの - fast-forward
オプションを使ってマージします。マージパッチなしで線形履歴を維持します。
これが機能するには、マージリクエストがマスターブランチの直接サフィックスでなければならないということです。したがって、 origin / master
が変更されたときはいつでも、ブランチをブランチにリベースして、パッチが常にマスターの上に置かれるようにする必要があります。これが起こると、リベース中にパッチを編集し、ブランチの push -f
を使って履歴を書き直す必要があります。
また、いくつかの衛生ルールを適用していますので、MRがそれらを尊重していることを確認してください:
- 小さな原子は、多くのことをする大きな原子よりも優先します。
- リファクタリングと新機能を混在させないでください。
- 再インデント、空白の削除、または他のスタイルの変更を実際のコード変更と混同しないでください。
- 最後のパッチだけでなく、すべてのパッチをコンパイルするために可能な限り試してください。
- ドキュメント化されたインターフェイスに新しい機能を追加する場合は、ドキュメントを拡張することを忘れないでください。
- 仕様がリポジトリにある部品(たとえば、Michelson)の場合は、実装と同期させてください。
- コミットメッセージのスタイルを模倣してみてください。単純なコミットでは、拡張コミットメッセージを追加してください。
MR自身の衛生状態に応じて:
- MRに適切なタイトルをつけてください。自明ではない場合、詳細な動機付けされた説明を追加してください。
- ブランチに意味のある一貫した名前を付ける。
- 進行中の作業中に
WIP:
フラグを置くことを忘れないでください
いくつかの追加のCIテストは、マスタ以外のブランチに対してオンデマンドでのみ実行されます。ブランチ名にキーワードを含めることで、これらのテストをアクティブにすることができます。
- MRがOPAMのパッケージングに影響する場合は、支店名に
opam
を使用してください。 - MRがドキュメントを更新する場合は、ブランチ名に
doc
を使用してください。