pull リクエストはリポジトリの命綱のようなものです。すべてが正常に動作し、動いている状態を維持します。このページでは、PR が完了し、レビューが容易になるように PR を作成する方法について説明します。これにより、PR が統合される可能性が高まります。
できる限り優れた PR を作成するための手順は次のとおりです。
コミュニケーション
コードの記述を開始する前に、コアチームとコミュニケーションを取って、興味のあることを伝えておくとよいでしょう。
関心のある問題がある場合は、その問題にコメントを追加して、作業を開始することを伝えます。これにより、複数の人が同じ作業に取り組むことがなくなります。担当チームから返信があり、お客様のアカウントであることを確認します。
問題に含まれないアイデアがある場合は、作業を開始する前にアイデアを書き留めてください。これにより、ビルドを開始する前に、変更を構築する最善の方法についてチームで話し合うことができます。これにより、長期的には作業を省くことができます。
準備
Blockly または blockly-samples に初めてコントリビュートする場合は、開発のセットアップ ページから始めてください。
小さくする
変更は常に小さく、焦点を絞ったものにしてください。1 つの巨大な PR をレビューするよりも、複数の小さな PR をレビューすることをおすすめします。次のような経験則があります。
- 1 つの問題を解決する。複数の問題に同時に取り組まないでください。
- スコープを制限する。通常、PR は 8 時間以内に完了する必要があります（コードベースの習熟度に応じて異なります）。
- commit を使用する。PR が少し大きい場合は、git コミットを使用して変更を論理グループに分割します。
清潔に保つ
コードスタイルを気にする理由長期的な視点で、一貫したスタイルにすることでメンテナンスが容易になります。スタイルとは、変数の名前付けを指しますが、コードの構造化やコメントの記述方法も含まれます。可能であれば、eslint などのツールを使用してスタイルチェックを自動化します。
eslint に加えて、以下のガイドも参照してください。
変更をテストする
PR を送信する前に、変更が機能していることを常にテストし、後で戻って修正する必要がないようにする必要があります。さまざまなカテゴリのプロジェクトをテストするためのアイデアをいくつかご紹介します。
- プラグインの場合: 変更内容を網羅する自動 mocha テストを作成します。
- 例: デモしたすべての機能を手動でテストします。
- codelabs の場合: クリーンな環境でチュートリアル全体を実行し、提供されているサンプルコードをテストします。
コミュニケーション
これが PR 作成の最後の部分であり、おそらく最も重要な部分です。要約を作成します。
優れた PR の概要を記述すると、他のデベロッパーが変更内容を確認しやすくなり、承認が早まる可能性が高まります。
要約には次のような情報が含まれます。
- PR が関連する問題。
- PR で追加される変更内容。
- 変更をテストした方法。
- 審査担当者に詳しく確認してもらいたい内容。
- 審査担当者に必要と思われるその他の情報
リクエストを作成するときに PR テンプレートに沿って作成すれば問題ありません。できるだけ簡潔かつ完全にしてください。
ぜひご活用ください。