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

ブランチ、フォーク、コミット、プル要求を使用して、コラボレーション プロジェクトのコード変更を安全に書き込み、調整し、提案します。

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

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

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

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

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

## コミットで作業をチェックインする

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

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

* 大きな変更をレビュー可能な手順に分割します。
* 実験がうまくいかない場合は、以前の状態にロールバックします。
* レビュー担当者に、最終的な変更に到達した方法の明確な履歴を提供します。

## pull request を使用した変更の提案

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

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

## コードを最新の状態に保ち、最適化する

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

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

## リポジトリ コントロール内での作業

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

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

## 統合ツールチェーン

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

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

## 詳細については、次を参照してください。

* [pull request の作成](/ja/enterprise-server@3.22/pull-requests/how-tos/create-pull-requests/creating-a-pull-request)