プルリクエスト

• ローカル環境のセットアップ
  • ステップ1: フォーク
  • ステップ2: ビルド
  • ステップ3: ブランチ
• 変更を加える
  • ステップ4: コーディング
  • ステップ5: コミット
    • コミットメッセージのガイドライン
  • ステップ6: リベース
  • ステップ7: テスト
  • ステップ8: プッシュ
  • ステップ9: プルリクエストを開く
  • ステップ10: 議論と更新
    • 承認とリクエストの変更ワークフロー
  • ステップ11: 取り込み
  • 継続的インテグレーションテスト

ローカル環境のセットアップ

ステップ1: フォーク

Fork Electron's GitHub repository.

ステップ2: ビルド

We recommend using @electron/build-tools to build Electron itself.

# Install build-tools package globally:
npm install -g @electron/build-tools
# Run the init script where you want to clone the project and point it to your fork:
e init --fork my-org/electron --bootstrap testing

This will create a new electron folder in your working directory and initialize the project. Once the build completes, navigate to electron/src/electron, where your fork is actually cloned.

[!IMPORTANT] Your Electron project has a complex folder structure with nested repositories. See the Build Instructions docs for detailed Build Tools usage instructions (e.g. how to sync dependencies or how to recompile the binary) and platform-specific notices.

There, you should have two remote URLs in git:

• origin will point to electron/electron
• fork will point to your fork (my-org/electron)

プロジェクトをローカルに構築したら、変更を始める準備が整います！

ステップ3: ブランチ

開発環境を整理しておくために、作業を支えるローカルのブランチを作りましょう。 これらは、main ブランチから直接分岐する必要があります。

git checkout -b my-branch

変更を加える

ステップ4: コーディング

electron/electron リポジトリに対して開かれたほとんどのプルリクエストには、shell/ フォルダの C/C++ コード、lib/ フォルダの JavaScript コード、docs/api/ のドキュメント、spec/ フォルダのテストの変更が含まれます。

コードの変更時に yarn lint を実行して、プロジェクトのコードスタイルに従うようにしてください。

プロジェクトのさまざまな部分でコードを変更する際のベストプラクティスの詳細については、コーディングスタイル を参照してください。

ステップ5: コミット

変更を個々のコミット内で論理的にグループ化しておくことを推奨します。 コントリビューターの多くが、複数のコミットに分割された変更をより簡単に確認できます。 プルリクエストのコミット数に制限はありません。

git add my/changed/files
git commit

複数のコミットは、取り込み時にスカッシュされることに注意してください。

コミット署名

electron/electron リポジトリは、すべての PR 受け付けに対して コミット署名 を強制しています。 コミットに署名するには、GitHub のドキュメント Git へ署名キーを伝える を参照してください。

コミットメッセージのガイドライン

良いコミットメッセージは、何が何故変更されたのか、が記述されるべきです。 The Electron project uses semantic commit messages to streamline the release process.

プルリクエストがマージされるためには、プルリクエストにタイトルがあり、それには意図を示すプレフィックスがなければなりません

意図を示すプレフィックスのあるコミットメッセージのの例です。:

• fix: don't overwrite prevent_default if default wasn't prevented
• feat: add app.isPackaged() method
• docs: app.isDefaultProtocolClient is now available on Linux

プレフィックスの例:

• fix: バグ修正
• feat: 新機能
• docs: ドキュメントの変更
• test: 足りないテストの追加や既存のテストの訂正
• build: ビルドシステムに影響する変更
• ci: CI の設定ファイルとスクリプトへの変更
• perf: パフォーマンスを改善するコード変更
• refactor: バグ修正や機能追加の無いコード変更
• style: コードの意味を変えない変更 (lint)

その他、コミットメッセージを作成するときに留意すること:

1. 最初の行は、以下の通りにしてください。
   • 変更の簡単な説明を含める (50 文字以下が好ましく、72 文字を超えない)
   • 適切な名詞、頭字語、および関数/変数名のようなコードを参照する単語を除いて、完全な小文字にする
2. 2行目は空にしてください。
3. 他のすべての行は72列で折り返します。

破壊的変更

オプションの本体またはフッターのセクションの先頭に BREAKING CHANGE: のテキストがあるコミットは、API に破壊的な (セマンティックバージョン管理におけるメジャーと相関する) 変更をもたらします。 破壊的な変更はあらゆるタイプのコミットの一部になりえます。 例として、fix:、feat:、chore: やその他のタイプも加えてすべて当てはまります。

詳細については、conventionalcommits.org を参照してください。

ステップ6: リベース

変更をコミットしたら、git rebase (git merge ではない) を使用してメインリポジトリと作業を同期させることを推奨します。

git fetch origin
git rebase origin/main

これにより作業ブランチに electron/electron の main の最新の変更が確実に反映されます。

ステップ7: テスト

バグの修正と機能追加には常にテストが必要です。 プロセスを簡単にするため、テストガイド が提供されています。 それらがどのように構築されるべきかを見るため、他のテストを見ることでも手助けになれます。

プルリクエストで変更を送信する前に、常に完全なテストスイートを実行してください。 テストを実行するには以下のようにします。

yarn test

リンターが問題を報告していないこと、そしてすべてのテストが合格していることを確認してください。 いずれかのチェックに失敗したパッチは提出しないでください。

テストを更新していて、単一の仕様を実行してチェックしたい場合は、以下のようにします。

yarn test -match=menu

上記の例では menu に一致する仕様のモジュールのみが実行されます。これは、テストサイクルの最後の最後にテストに取り組んでいる人にとって役に立ちます。

ステップ8: プッシュ

コミットの準備 ―― テストに合格して、lint をしている ―― ができたら、GitHub 上 のあなたのフォークに作業ブランチをプッシュして、プルリクエストを開くプロセスを開始します。

git push fork my-branch

ステップ9: プルリクエストを開く

GitHub で新しいプルリクエストを開くと、記入必須のテンプレートが表示されます。 It can be found here.

このテンプレートが適切に記入されていない場合、メンテナンス担当者がより多くの情報を求めたり、あいまいな点を明確にしたりするために、PR のマージが遅れるかもしれません。

ステップ10: 議論と更新

おそらく、あなたはプルリクエストの変更に対するフィードバックやリクエストを得ます。 これは提出プロセスの大事な部分なので、がっかりさせないでください！ コントリビューターの中には、すぐにプルリクエストを承認する人がいます。 他の人には詳細なコメントやフィードバックがあるかもしれません。 これは、変更が正しいかどうかを評価するために必要なプロセスの一部です。

既存のプルリクエストを変更するには、ローカルブランチに変更を加え、それらの変更で新しいコミットを追加し、それらをあなたのフォークにプッシュします。 GitHub は自動的にプルリクエストを更新します。

git add my/changed/files
git commit
git push fork my-branch

利用できる git rebase を使用して、コミットを管理するためのさらに高度なメカニズムがいくつかありますが、このガイドの範疇を超えています。

あなたが何らかの回答を待っている場合は、Ping レビュー担当者にプルリクエスト内でコメントを投稿してください。 If you encounter words or acronyms that seem unfamiliar, refer to the Chromium glossary.

承認とリクエストの変更ワークフロー

All pull requests require approval from a Code Owner of the area you modified in order to land. 管理者はプルリクエストをレビューするたびに、変更を要求することができます。 これらは、タイプミスを修正するなどの小さなもから、実質的な変更を伴うものまでにもなります。 このような要求は役に立ちますが、時には、特に変更する やり方 についての具体的な提案が含まれていないために、唐突だったり親切でないものに出くわすことがあります。

がっかりしないでください。 レビューが不公平であると感じる場合は、そう言い、別のプロジェクトのコントリビューターの意見を求めてください。 大抵の場合、そのようなコメントはレビュアーがレビューするのに十分な時間が無いためで、意図しないものです。 そのような困難はしばしば少しの忍耐で解決することができます。 要するに、レビュアーは親切なやりとりを提供することが期待されているということです。

ステップ11: 取り込み

取り込まれるには、少なくとも1人の Electron の Code Ownerがレビューして承認し、CI に合格する必要があります。 その後、他のコントリビューターからの異論がない場合、プルリクエストをマージすることができます。

おめでとう、あなたのコントリビューションに感謝します！

継続的インテグレーションテスト

すべてのプルリクエストは、継続的インテグレーション (CI) システムでテストされ、 それが Electron のサポートされているプラットフォームで動作することを確認されます。

理想的には、プルリクエストは CI のすべてのプラットフォーム上で合格します ("青になる") 。 これは、すべてのテストが合格し、lint のエラーがないことを意味します。 しかし、CI インフラストラクチャ自体が特定のプラットフォームで失敗したり、いわゆる "flaky" テストに失敗する ("赤になる") ことは珍しいことではありません。 各 CI の失敗を手動で検査して原因を特定する必要があります。

プルリクエストを開くと、CI が自動的に開始されますが、メンテナーだけが CI の実行をリスタートできます。 CI が誤検知をしていると思われる場合は、メンテナーにテストをリスタートするよう依頼してください。