プロジェクトのコードを記述する

プロジェクトに投稿する場合は、メインコードベースに影響を与える前に、コードを安全に記述して調整する必要があります。ブランチ、フォーク、コミット、プルリクエストは連携してそのための場を提供し、実験したり、作業を少しずつコミットしたり、完成した変更をレビュー用に提案したりできるようにします。

ブランチとフォークを使用して作業を分離する

ほとんどの作業は、自由に変更できるコードの分離されたコピーを作成することから始まります。

リポジトリへの書き込みアクセス権がある場合は、 ブランチ を使用します。ブランチを使用すると、他のブランチに影響を与えることなく、リポジトリの包含領域で機能の開発、バグの修正、実験を行うことができます。既存のブランチ (通常は既定のブランチ) からブランチを作成します。
書き込みアクセス権がない場合、または元のプロジェクトから完全に独立したい場合は、 フォーク を使用します。フォークは、元の "アップストリーム" リポジトリとコードと可視性の設定を共有する別のリポジトリです。これには、独自のブランチ、問題、およびプル要求があります。フォークを使用すると、アップストリームリポジトリのプル要求を開くこともできます。

通常、ブランチは、共有リポジトリで既に共同作業を行う場合に最も簡単な選択肢です。多くの場合、フォークは、アップストリームリポジトリへの書き込みアクセス権がない可能性があるオープンソース貢献に最適な選択肢です。

コードを記述するときに、小規模で意味のある変更グループをコミットとして保存 します。各コミットには、変更内容を説明するメッセージと共に作業のスナップショットが記録されます。これにより、履歴の追跡、変更の確認、コードの進化の理解が容易になります。

ブランチまたはフォークで頻繁にコミットすると、次のことができます。

作業を共有する準備ができたら、 プル要求 を開いて、変更をベースブランチにマージすることを提案します。プルリクエストには、コミット、変更内容の説明、そしてマージされる前にレビュー担当者がその内容を議論して評価するために必要なツールがまとめられています。

作業の進行中に pull request を開くには、レビューを正式に要求せずに変更を共有する下書きプル要求を作成します。これは、早期のフィードバックが必要な場合や、コードに対して自動チェックを実行する場合に便利です。

pull request が開いている間は、他のユーザーが作業をマージするときに、ベースブランチを変更し続けることができます。変更をクリーンに保ち、競合を減らすには、次のことができます。

ベースブランチを自分のブランチに頻繁にマージまたはリベースして、自分の変更で加えた内容に差分を絞れるようにしてください。 GitHub では、デフォルトで 3 点比較が表示されます。これは、ブランチがベースから分岐した時点と比較します。
レビューを依頼する前に、コミットの並べ替え、結合、または言い換えなど、乱雑なコミット履歴を整理するためにリベースします。
Git が競合する変更を自動的に結合できない場合に、マージ競合を解決する。

経験豊富な共同作成者は、リポジトリが定義するガードレール内で作業します。これらの設定によって、どこにプッシュできるか、誰があなたの作業を承認しなければならないか、そしてマージされる前に何を通過する必要があるかが決まります。

保護されたブランチとルールセット は、重要なブランチへの直接プッシュをブロックし、線形履歴または署名されたコミットを必要とし、マージする前に状態チェックまたはレビューを必要とします。
コード所有者 は、自分が所有するファイルに変更が触れると自動的にレビューが要求されるため、機密性の高い領域に対する承認を計画します。
プッシュルールセット は、フォークネットワーク全体に適用でき、すべてのフォークのファイルパス、サイズ、または名前を制限できます。
受信前フックを 使用すると、 GitHub Enterprise Server の管理者は、コミットを受け入れる前にサーバーにポリシーチェックを適用できます。

プル要求は、コードを迅速かつ安全に記述するのに役立つ自動化とサービスにコードを接続します。

Code scanning と Dependabot は、変更がプルリクエストを進むにつれてセキュリティ上の問題や脆弱な依存関係を明らかにするため、早い段階でセキュアコーディングプラクティスを適用できます。
GitHub Actions では、プル要求へのプッシュごとに継続的インテグレーションを実行し、変更を自動的にビルドしてテストできます。