pull リクエストはリポジトリの生命線のようなものです。すべてが健全で動きます。このページでは、包括的で確認しやすい PR の作成方法について説明します。これにより、PR が統合される可能性が高くなります。
ここでは、最高の PR を作成するための手順をご紹介します。
コミュニケーション
コードを記述し始める前に、コアチームとやり取りして、関心事項を把握しておくことをおすすめします。
関心がある問題がある場合は、これから取り組む旨をその問題にコメントします。同じ作業を行う従業員がいないようにしますチームメンバーが応答し あなたの本人確認です
どの課題にも当てはまらないアイデアがある場合は、作業を開始する前に書き出してください。これにより、構築を開始する前に、変更を組み込む最善の方法についてチームは話し合うことができます。これにより、長期的には作業の負担が軽減されます。
準備
Blockly または blockly-samples に初めて貢献する場合は、開発のセットアップページから始めます。
小さくする
変更は必ず、小さく、焦点を絞ったものにしてください。私たちは 1 つの巨大な PR ではなく、複数の小規模な PR を審査します。良い経験則は次のとおりです。
- 1 つの問題の解決複数の問題に一度に取り組まないでください。
- スコープを制限する。通常、PR にかかる時間は 8 時間未満です（コードベースの知識にもよります）。
- commit を使用する。PR が少し大きいと感じたら、git commit を使用して変更を論理グループに分割します。
常に清潔に保つ
コードスタイルが重要である理由継続して使用しており、スタイルが一貫しているためメンテナンスが容易になります。スタイルは変数の名前の付け方を指すだけでなく、コードの構造、コメントの記述なども網羅しています。可能な場合は eslint などのツールを使用して、スタイル チェックを自動化します。
eslint に加えて、以下のガイドをご覧ください。
変更をテストする
PR を設定する前に、後で戻って修正する必要がないように、変更が機能していることを常にテストする必要があります。さまざまなカテゴリのプロジェクトをテストする際のアイデアを次に示します。
- プラグイン: 変更を反映する自動 mocha テストを作成します。
- 例: デモしたすべての機能を手動でテストします。
- Codelab の場合: クリーン環境でチュートリアル全体を実行し、用意したサンプルコードをテストします。
コミュニケーション
これが PR 作成の最後であり、おそらく最も重要な部分である、まとめの記述です。
優れた PR サマリーを記述することで、他のデベロッパーが変更内容を確認しやすくなり、変更の受理が迅速になります。
サマリーには次の情報を含めてください。
- PR に関連する問題
- PR により追加される変化
- 変更のテスト方法
- レビュアーに精査してほしいものすべて。
- レビュアーに必要と思われるその他の情報
リクエストを作成する際に PR テンプレートに従っても大丈夫です。可能な限り簡潔かつ完全に作成してください。
コーディングをお楽しみください！