本文へスキップ

プルリクエスト

ローカル環境の設定​

ステップ1：フォーク​

GitHub上でプロジェクトをフォークし、フォークをローカルにクローンします。

$ git clone git@github.com:username/electron.git
$ cd electron
$ git remote add upstream https://github.com/electron/electron.git
$ git fetch upstream

ステップ2：ビルド​

ビルド手順と依存関係は、オペレーティングシステムによってわずかに異なります。Electronをローカルでビルドする方法に関する詳細なガイドを参照してください。

プロジェクトをローカルでビルドしたら、変更を開始する準備が整いました！

ステップ3：ブランチ​

開発環境を整理するために、作業を保持するためのローカルブランチを作成します。これらは`main`ブランチから直接分岐する必要があります。

$ git checkout -b my-branch -t upstream/main

変更を加える​

ステップ4：コーディング​

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

プロジェクトのコードスタイルに従っていることを確認するために、コードの変更に対して適宜`npm run lint`を実行してください。

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

ステップ5：コミット​

変更を論理的にグループ化して個々のコミットに保持することをお勧めします。多くの貢献者は、複数のコミットに分割された変更をレビューする方が容易だと感じています。プルリクエスト内のコミット数に制限はありません。

$ git add my/changed/files
$ git commit

複数のコミットは、マージ時に圧縮されることに注意してください。

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

適切なコミットメッセージは、変更内容とその理由を説明する必要があります。Electronプロジェクトでは、リリースプロセスを合理化するためにセマンティックコミットメッセージを使用しています。

プルリクエストをマージするには、**必ず**セマンティックプレフィックスを含むプルリクエストタイトルが必要です。

セマンティックプレフィックス付きのコミットメッセージの例

  • fix: defaultが防止されていない場合、prevent_defaultを上書きしない
  • feat: app.isPackaged()メソッドを追加
  • docs: app.isDefaultProtocolClientはLinuxでも利用可能になりました

一般的なプレフィックス

  • fix: バグ修正
  • feat: 新機能
  • docs: ドキュメントの変更
  • test: 欠けているテストの追加または既存のテストの修正
  • build: ビルドシステムに影響を与える変更
  • ci: CI設定ファイルとスクリプトへの変更
  • perf: パフォーマンスを向上させるコード変更
  • refactor: バグを修正せず、機能も追加しないコード変更
  • style: コードの意味に影響を与えない変更（リンティング）

コミットメッセージを作成する際のその他の注意点

  1. 最初の行は
    • 変更内容の短い説明を含める必要があります（できれば50文字以内、72文字以内）。
    • 固有名詞、頭字語、関数名/変数名などのコードを参照する単語を除き、すべて小文字にする必要があります。
  2. 2行目は空行にしてください。
  3. その他の行はすべて72文字で折り返してください。

破壊的変更​

オプションの本文またはフッターセクションの先頭に`BREAKING CHANGE:`というテキストがあるコミットは、破壊的なAPIの変更（セマンティックバージョニングにおけるメジャーに対応）を導入します。破壊的変更は、あらゆるタイプのコミットの一部にすることができます。例として、`fix:`、`feat:`、`chore:`タイプはすべて有効です。

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

ステップ6：リベース​

変更をコミットしたら、作業をメインリポジトリと同期するために`git rebase`（`git merge`ではなく）を使用することをお勧めします。

$ git fetch upstream
$ git rebase upstream/main

これにより、作業ブランチに`electron/electron`メインからの最新の変更が含まれるようになります。

ステップ7：テスト​

バグ修正と機能には常にテストが付属する必要があります。テストガイドが提供されており、プロセスを容易にします。他のテストを見て、どのように構造化されているかを確認することも役立ちます。

プルリクエストで変更を送信する前に、必ず完全なテストスイートを実行してください。テストを実行するには

$ npm run test

リンターが問題を報告せず、すべてのテストがパスすることを確認してください。どちらかのチェックに失敗するパッチは送信しないでください。

テストを更新していて、単一のspecを実行して確認したい場合

$ npm run test -match=menu

上記は`menu`に一致するspecモジュールのみを実行します。これは、そうでなければテストサイクルの最後に位置するテストに取り組んでいるユーザーにとって便利です。

ステップ8：プッシュ​

テストとリンティングがパスしているコミットの準備が整ったら、作業ブランチをGitHub上のフォークにプッシュすることで、プルリクエストの作成プロセスを開始します。

$ git push origin my-branch

ステップ9：プルリクエストの作成​

GitHub内で新しいプルリクエストを作成すると、記入する必要があるテンプレートが表示されます。それはここにあります。

このテンプレートを適切に記入しないと、メンテナーが詳細な情報を探したり、曖昧さを明確にしたりするため、PRのマージが遅れる可能性があります。

ステップ10：議論と更新​

おそらく、プルリクエストに対するフィードバックや変更要求を受け取るでしょう。これは提出プロセスの大きな部分であるため、落胆しないでください！一部の貢献者はすぐにプルリクエストに署名するかもしれません。その他は、詳細なコメントやフィードバックがあるかもしれません。変更が正しく、必要かどうかを評価するために、これはプロセスの必要な部分です。

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

$ git add my/changed/files
$ git commit
$ git push origin my-branch

`git rebase`を使用してコミットを管理するためのより高度なメカニズムがいくつかありますが、このガイドの範囲外です。

何かについて回答を待っている場合は、プルリクエストにコメントを投稿してレビュアーに ping を送信してください。見慣れない単語や頭字語に遭遇した場合は、この用語集を参照してください。

承認と変更要求のワークフロー​

全てのプルリクエストは、変更を加えた部分のコードオーナーによる承認が必要です。メンテナがプルリクエストをレビューする際に、変更要求を行う場合があります。これは、タイプミス修正のような小さなものから、本質的な変更まで様々です。このような要求は役に立つことを意図していますが、特に具体的な変更方法の提案が含まれていない場合は、唐突で役に立たないと感じる場合もあります。

落胆しないでください。レビューが不公平だと感じた場合は、その旨を伝えたり、他のプロジェクト貢献者の意見を求めたりしてください。多くの場合、このようなコメントは、レビューアーが十分な時間を割いてレビューしなかった結果であり、悪意のあるものではありません。少しの忍耐で、このような問題は解決できることがよくあります。とは言え、レビューアーは有益なフィードバックを提供することが期待されています。

ステップ11：マージ​

プルリクエストをマージするには、少なくとも1人のElectronコードオーナーによるレビューと承認、およびCIの通過が必要です。その後、他の貢献者からの異議がなければ、プルリクエストをマージできます。

ご貢献いただきありがとうございます！

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

全てのプルリクエストは、Electronのサポート対象プラットフォームで動作することを確認するために、継続的インテグレーション（CI）システムでテストされます。

理想的には、プルリクエストは全てのCIプラットフォームで成功し（「グリーン」になります）、全てのテストがパスし、リンティングエラーがない状態になります。しかし、CIインフラストラクチャ自体が特定のプラットフォームで失敗したり、「不安定な」テストが失敗したり（「レッド」になります）することは珍しくありません。各CIの失敗原因は、手動で検査する必要があります。

プルリクエストを作成するとCIは自動的に開始されますが、CIの実行を再開できるのはコアメンテナのみです。CIが誤った結果を示していると考える場合は、メンテナにテストの再開を依頼してください。