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

プロジェクトに投稿する場合は、メインコードベースに影響を与える前に、コードを安全に記述して調整する必要があります。ブランチ、フォーク、コミット、プル要求は連携してその領域を提供するため、実験を行い、作業を段階的にチェックインし、完了した変更を提案してレビューを行うことができます。

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

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

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

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

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

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

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

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

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

基本ブランチをブランチに頻繁にマージまたはリベースして、変更によって生じる内容に差分が集中し続けます。 GitHub では、既定では 3 点の差分が表示されます。これは、分岐がベースから分岐したポイントと比較されます。
レビューを依頼する前に、コミットの並べ替え、結合、または言い換えなど、乱雑なコミット履歴を整理するためにリベースします。
Git が競合する変更を自動的に結合できない場合に、マージの競合を解決します。

経験豊富な共同作成者は、リポジトリが定義するガードレール内で作業します。これらのコントロールは、プッシュできる場所、作業を承認する必要があるユーザー、マージする前に渡す必要がある内容を形成します。

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

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

Code scanning を Dependabot 、変更がプル要求を通過する際にセキュリティの問題と脆弱な依存関係が表面化するため、セキュリティで保護されたコーディングプラクティスを早期に適用できます。
GitHub Actions では、プル要求へのプッシュごとに継続的インテグレーションを実行し、変更を自動的にビルドしてテストできます。