プルリクエストとは
プルリクエストは、変更をプロジェクトのメインブランチに含めるためのリクエストです。興味深いオープンソースプロジェクトを見つけたり、バグを見つけたり、改善を思いついたりしたとします。他の人のリポジトリのコードを直接変更することはできませんが、PRを介して変更を提案することはできます。
プロセスは次のようになります。プロジェクトのコピーを作成し、バージョンに変更を加え、プロジェクトの所有者に変更を「プル」するように依頼します。そのため、プルリクエストという名前が付けられました。
プルリクエストの作成準備
変更を加える前に、適切な準備をすることが重要です。
プロジェクトを調査する
貢献したいプロジェクトを研究する時間を取ってください。READMEファイルを読み、コードの構造を調べ、既存のプルリクエスト（オープンとクローズの両方）を確認してください。これは、プロジェクトのコーディングスタイルと変更の要件を理解するのに役立ちます。
CONTRIBUTINGファイルを検索する
多くのプロジェクトには、投稿ルールを含むCONTRIBUTING.mdファイルがあります。コード要件、PR作成プロセス、開発環境のセットアップ、その他の重要な情報が記載されている可能性があります。これらの規則に必ず従ってください。
問題を確認する
作業を開始する前に、問題セクションを確認してください。誰かがすでに同様のタスクに取り組んでいるか、あなたのアイデアがすでに議論されている可能性があります。バグを修正したり、新しい機能を追加したりする場合は、まずイシューを作成して、メンテナーと話し合うことをお勧めします。
フォークとリポジトリのクローン
最初の技術的なステップは、プロジェクトのフォークを作成することです。
フォークを作成する
GitHub では、リポジトリページの右上隅にある「Fork」ボタンでこれを行います。フォークは、アカウントにリポジトリのコピーを作成し、そこで自由に実験できます。
フォークをクローンする
次に、フォークをローカルマシンにクローンします。
git clone https:// github.com/あなたのユーザー名/プロジェクト名.git
cd название-проектаupstream remote を追加する
フォークを元のリポジトリと同期するには、それをアップストリームとして追加します。
git remote add upstream https:// github.com/owner/project-name.gitこれで、2つのリモートがあります。origin （あなたのフォーク）とupstream （元のリポジトリ）。
変更のためのブランチを作成する
メインブランチまたはマスターブランチで直接作業しないでください。タスクごとに常に個別のブランチを作成してください。
git checkout -b fix-navigation-bugブランチ名は説明的であり、変更の本質を反映する必要があります。良い例： feature-add-dark-mode、fix-login-error、docs-update-readme。
変更の適用
これでコードの作業を開始できます。
プロジェクトのスタイルに従ってください
プロジェクトと同じコーディングスタイルを使用してください。インデント、変数の命名、ファイル構造に注意してください。多くのプロジェクトでは、リントとフォーマットを使用しています。コミットする前に実行してください。
アトミックコミットを実行する
1つのコミットは1つの論理的な変更です。これにより、コードレビューが簡素化され、必要に応じて変更を簡単にロールバックできます。コミットメッセージは情報に富んでいる必要があります。
git add .
git commit -m "Fixed a bug with navigation freezing when scrolling quickly"悪いメッセージ：「修正」または「修正」。良い例：具体的に何が行われ、なぜ行われるのかを説明します。
テストを書く
プロジェクトでテストを使用している場合は、コードにテストを必ず追加してください。また、既存のテストがすべて合格していることを確認してください。
npm test
# または
pytest
プルリクエストの作成
変更の準備ができたら、ブランチをフォークに送信します。
git push origin fix-navigation-bugこれで、GitHubのフォークに「Compare & pull request」ボタンが表示されます。それをクリックしてください。
PRの説明を入力してください
説明プルリクエストは、何を、なぜ行ったのかを説明するチャンスです。良い説明には以下が含まれます。
変更点： 変更の簡単な説明。
理由： 変更の理由の説明、もしあればIssueへのリンク。
テスト方法： 変更を確認するための指示。
スクリーンショット： 変更がUIに影響する場合は、変更前と変更後のスクリーンショットを追加してください。
説明の例：
# # 説明
Исправлен баг с зависанием навигационного меню при быстрой прокрутке страницы.
# # 関連する問題
Closes #234
# # 変更
- Добавлен debounce для обработчика скролла
- Оптимизирован расчёт позиции меню
- Добавлены unit-тесты для новой логики
# # テスト
1. Откройте страницу с длинным контентом
2. Быстро прокрутите вниз и вверх
3. Навигация должна плавно следовать за скроллом без задержекコードレビューのプロセス
PRが作成されると、コードレビューのプロセスが開始されます。
編集の準備をしてください
メンテナーは変更を要求できます。これは正常であり、コードが悪いという意味ではありません。コードレビューは、プロジェクトの品質を向上させ、一貫性を維持するのに役立ちます。
コメントに返信する
査読者がコメントを残した場合は、それに返信してください。コメントに同意する場合は、編集してください。同意しない場合は、丁寧かつ建設的に自分の立場を説明してください。
同じスレッドに編集を加える
ブランチへの追加のコミットはすべて自動的にPRに追加されます。
# 編集中
git add .
git commit -m "Code review comments taken into account: improved error handling"
git push origin fix-navigation-bugメインブランチとの同期
レビューが進行している間、プロジェクトのメインブランチは先に進むことができます。ブランチを最新の状態に保つことが重要です。
# 元のリポジトリから変更を取得します
git fetch upstream
# メインに切り替えます
git checkout main
# main を更新します
git merge upstream/main
# ブランチに戻ります
git checkout fix-navigation-bug
# mainから変更を取り込む
git merge main競合が発生した場合は、それらを解決してコミットします。
よくある間違いとその回避方法
PRが大きすぎます
1つのPRは1つのタスクを解決する必要があります。バグを修正し、同時に新しい機能を追加した場合は、これを2つの個別のPRに分割します。大きなPRはレビューが難しく、受け入れられる可能性が低くなります。
他のユーザーのファイルの変更
タスクに関連しないファイルの書式設定やスタイルを変更しないでください。これにより、PR にノイズが発生し、レビューが複雑になります。
説明がありません
説明のないPRまたは「修正」の説明は受け入れられない可能性があります。通常の説明に時間をかけます。
CI/CDを無視する
プロジェクトで自動チェック（テスト、リンター）が設定されている場合は、それらが合格していることを確認してください。テストが失敗したPRは考慮されません。
PRの採用後
PRが受け入れられてメインブランチにマージされると、作業ブランチを削除できます。
# ローカルで削除します
git branch -d fix-navigation-bug
# GitHubで削除する
git push origin --delete fix-navigation-bugフォークを更新します。
git checkout main
git pull upstream main
git push origin main初心者向けのヒント
小さなことから始めましょう
すぐに大きなリファクタリングを行わないでください。ドキュメントの誤字脱字の修正、小さなバグ、例の追加など、簡単なタスクから始めましょう。これは、過度のストレスなしにプロセスに慣れるのに役立ちます。
「good first issue」のラベルを探す
多くのプロジェクトでは、初心者に適したタスクに特別なラベルが付けられています。例えば、good first issue、beginner friendly、help wantedなどです。まずはそれらから始めましょう。
質問をすることを恐れないでください
不明な点がある場合は、Issueまたはプロジェクトチャットで質問してください。オープンソースコミュニティは通常、理解しようとする初心者に優しいものです。
辛抱強く
メンテナーはしばしば自由な時間にこれを行います。PRがすぐに見られない場合もありますが、これは普通です。1週間以上経過した場合は、丁寧にリマインドすることができます。
オープンソースのエチケット
丁寧に
同意されない場合でも、敬意を持ってコミュニケーションを取ってください。画面の向こう側には生きた人間がいることを忘れないでください。
建設的な批判を受け入れる
コードレビューは、開発者としてのあなたを批判するのではなく、コードを改善する方法です。コメントを何か新しいことを学ぶ機会として捉えてください。
助けてくれてありがとう
問題の解決を手伝ってもらったり、レビューに時間を割いてもらったりした場合は、感謝の気持ちを伝えましょう。これは、人々がプロジェクトに時間を費やし続けるように動機付けます。
結論
プルリクエストの作成は、練習を重ねることで身につくスキルです。最初のPRは難しいように思えるかもしれませんが、次のプロセスごとに簡単かつ自然になります。間違いを恐れないでください。それが私たちが学ぶ方法です。
オープンソースプロジェクトに参加することは、技術スキルを向上させるだけでなく、開発者コミュニティへの扉を開き、ポートフォリオを構築し、実際のプロジェクトで経験を積むのに役立ちます。小さなことから始め、忍耐強く、細部に注意を払いましょう。そうすれば、すぐに自信を持って貢献できるようになります。
コディック — 初心者向けの開発者教育プラットフォームです。Python、JavaScript、HTML、CSS、その他の需要の高いテクノロジーに関するわかりやすいプログラミングコースを提供しています。
私たちの Telegramチャンネル、役立つ記事を共有し、複雑な概念を簡単な言葉で分析し、初心者が開発の世界で最初の一歩を踏み出すのを助けます。