メインコンテンツへ飛ぶ

プルリクエスト

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

ステップ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 を実行して、プロジェクトのコードスタイルに従うようにしてください。

See coding style for more information about best practice when modifying code in different parts of the project.

ステップ5: コミット​

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

$ git add my/changed/files
$ git commit

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

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

良いコミットメッセージは、何が何故変更されたのか、が記述されるべきです。 このElectronプロジェクトはセマンティックコミットメッセージをつかって、このリリースプロセスを合理化しています。

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

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

  • 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 upstream
$ git rebase upstream/main

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

ステップ7: テスト​

バグの修正と機能追加には常にテストが必要です。 A testing guide has been provided to make the process easier. それらがどのように構築されるべきかを見るため、他のテストを見ることでも手助けになれます。

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

$ npm run test

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

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

$ npm run test -match=menu

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

ステップ8: プッシュ​

コミットの準備 ―― テストに合格して、lint をしている ―― ができたら、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 レビュー担当者にプルリクエスト内でコメントを投稿してください。 不慣れな言葉や頭字語に遭遇した場合は、この 用語集 を参照してください。

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

すべてのプルリクエストは、取り込むために、変更した部分の Code Owner の承認が必要です。 管理者はプルリクエストをレビューするたびに、変更を要求することができます。 これらは、タイプミスを修正するなどの小さなもから、実質的な変更を伴うものまでにもなります。 このような要求は役に立ちますが、時には、特に変更する やり方 についての具体的な提案が含まれていないために、唐突だったり親切でないものに出くわすことがあります。

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

ステップ11: 取り込み​

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

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

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

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

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

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