― 権限・レビュー・自動検査・リリースの役割を整理する
はじめに
一人で開発していたプロジェクトに、二人、三人とメンバーが加わると、ソースコードの共有に加えて、変更の確認方法や公開の責任範囲を決める必要が出てきます。
この記事では、Git・GitHubの基本操作を理解している人を対象に、少人数で共同開発を始めるための設定と運用をまとめます。
PR（Pull Request）によるレビューと、CI（Continuous Integration：継続的インテグレーション）による自動検査を組み合わせる構成です。ESP32のような実機を扱う開発も想定しています。
この文書は、私自身が共同開発の設定や手順を確認し直すための備忘録も兼ねています。
以前に書いた開発記とは別に、共同開発の準備と運用を整理した記事として残しておきたいと思います。
以下は設定例です。実際に適用する際は、プロジェクトの構成やGitHubの契約プランに合わせて調整してください。
1．共同開発の全体フロー
作業は、Issueで範囲を合意し、作業ブランチからPRを提出する流れにします。
PRでは、自動検査、レビュー、必要な実機確認を行い、条件がそろったらmainへマージします。
リリースでは、公開する版と配布物を改めて確認します。
それぞれの確認には、次の役割があります。
| 確認 | 主な役割 |
|---|---|
| CI | ビルドやテストなど、機械的に検査できる内容を確認する |
| レビュー | 変更の目的、設計、影響範囲が妥当か判断する |
| 実機確認 | 配線、電源、センサーを含めた動作を確認する |
修正を追加した場合は、変更に応じて検査とレビューをやり直します。
2．リポジトリの所有形態と権限を決める
既存の個人所有リポジトリに少人数で参加するなら、共同開発者として招待する方法で始められます。
個人所有リポジトリでは、所有者と共同開発者という権限構成になります。
共同開発者ごとに細かな権限を設定したい場合や、複数の管理者で運営したい場合は、Organizationを検討します。
Organizationを使う場合の構成例です。
| 担当 | 権限の例 | 主な役割 |
|---|---|---|
| 管理担当 | Admin | メンバー管理、保護ルール、公開設定 |
| 開発担当 | Write | ブランチへのPush、PR作成、レビュー |
| 運営担当 | Maintain | 日常のリポジトリ管理 |
| 閲覧・検証担当 | Read | ソース確認、検証結果の共有 |
参考：GitHub公式：Organizationのリポジトリロール
ソース用と公開サイト用など、リポジトリが分かれている場合は、それぞれに必要なアクセス権を設定します。
また、「公開担当者がマージする」という運用上の約束と、GitHubの設定によって強制する制限は区別しておきます。
3．メンバーを招待する
個人所有リポジトリの場合は、次の手順です。
- 対象リポジトリの Settings → Collaborators を開く
- Add peopleから参加者のGitHubユーザー名を指定する
- 参加者が招待を承認する
- 対象リポジトリへアクセスできることを確認する
招待先は、表示名だけで判断せず、プロフィールURLとユーザー名で確認します。
参加者は、それぞれ自分のアカウントと開発環境を使います。
複数のリポジトリを使用する場合、招待やアクセス権の設定もリポジトリごとに確認します。
4．mainの保護ルールを設定する
mainへの変更は、PR経由で確認して取り込む構成にします。
ブランチ保護は、公開リポジトリではGitHub Freeでも利用できます。非公開リポジトリで利用する場合は、所有形態に対応した有料プランが必要です。
ここでは、従来型のブランチ保護ルールを使います。
- Settings → Branchesを開く
- Add classic branch protection ruleを選ぶ
-
Branch name patternへ
mainを入力する - 必要な条件を設定する
少人数向けの設定例です。
| 設定 | 方針 |
|---|---|
| Require a pull request before merging | PRを必須にする |
| Require approvals | 作成者以外の承認を1名必要にする |
| Dismiss stale pull request approvals when new commits are pushed | 変更追加後は承認を再取得する |
| Require status checks to pass before merging | 指定した検査を必須にする |
| Require branches to be up to date before merging | 最新のmainを反映してから取り込む |
| Require conversation resolution before merging | レビューの指摘を解決する |
| Do not allow bypassing the above settings | 管理者にも条件を適用する |
| Allow force pushes／Allow deletions | 有効にしない |
詳細な操作は、次の公式ドキュメントを参照してください。
二人で運用する場合、承認を必須にすると、もう一人が不在の間はマージできません。対応可能な時間や、急ぎの修正をどう扱うかも合意しておきます。
なお、既にRulesetsなどで保護しているリポジトリでは、既存の設定を確認してから変更します。
5．CIと必須チェックを接続する
GitHub Actionsのワークフローについて、次の点を確認します。
-
main向けPRの作成・更新で必要な検査が実行される - 開発者間でツールや依存関係のバージョンがそろっている
- 検査に必要な権限が設定されている
- 検査用ジョブと公開用ジョブの実行条件が整理されている
そのうえで、実際に実行されたチェックをブランチ保護の必須チェックへ指定します。
例えば、次のような検査です。
| 検査 | 確認内容 |
|---|---|
| Build | ビルドできるか |
| Test | 既存機能と変更箇所のテストが成功するか |
| Lint | 静的検査を通るか |
| Firmware compile | 対象ボード向けにコンパイルできるか |
ブランチ保護で必須チェックを設定しても、それだけで検査処理が作られるわけではありません。
先にワークフローを実行できる状態にし、対象PRで動作するチェックを指定します。
条件付きでしか実行しないチェックを必須にすると、結果待ちのままマージできなくなる場合があります。また、複数のワークフローで検査ジョブ名が重複しないようにします。
設定後は、小さなPRで次の動作を確認します。
- 必要なCIが実行される
- 必須チェックがそろうまでマージできない
- 必要な承認がない状態ではマージできない
6．開発環境と作業ルールをリポジトリへ残す
参加者が、個人のチャット履歴を読まなくても作業を始められるようにします。
| ファイル | 記載する内容 |
|---|---|
README.md |
概要、起動方法、関連リンク |
CONTRIBUTING.md |
ブランチ、PR、レビューの運用 |
docs/DEVELOPMENT.md |
ツールの版、環境構築、検査コマンド |
docs/RELEASE.md |
公開する版の決め方、配布・復旧手順 |
AGENTS.md |
AI開発支援ツールへ伝える作業上の指示 |
参加者はクローン後、変更前の状態でビルドと基本動作を確認します。
例えば、Node.jsを使うプロジェクトなら、指定されたバージョンを準備し、プロジェクトの手順に従って実行します。
npm ci
npm run build
npm ciは、管理されたロックファイルに基づいて依存関係をインストールします。
参考：npm公式：npm ci
最初の状態で失敗した場合は、エラーログと環境情報を共有してから修正作業へ進みます。
実機を使う場合は、ボード、Firmware、配線条件も開発環境の一部として記録します。
7．Issueで担当と完了条件を合意する
少人数でも、作業範囲を記録すると重複や認識違いを減らせます。
Issueには、最低限次を記載します。
目的：
何を改善するか。
変更範囲：
変更する機能・ファイル。
維持する互換性。
担当：
実装担当と確認担当。
完了条件：
必要なテストと実機確認。
特に、通信プロトコル、共通処理、依存関係、公開設定など、複数の作業へ影響する変更は先に相談します。
同じファイルを複数人が変更する場合も、作業範囲を共有しておきます。
8．作業ブランチからPRを提出する
作業ブランチは、更新したmainから作成します。
main
├─ feat/new-sensor
├─ fix/connection-status
└─ docs/setup-guide
PRには、変更内容に加えて、確認結果と未確認事項を記載します。
## 目的
この変更で解決する問題。
## 変更内容
実装・設定・文書の変更。
## 確認結果
実行したコマンドと結果。
必要に応じて実機確認の条件。
## 未確認事項
未実施の確認と、残っている制限。
## 関連Issue
関連するIssueへのリンク。
一つのPRの目的を絞ると、レビューと問題発生時の切り分けがしやすくなります。
レビュー後に修正を追加した場合は、変更内容をPRへ追記し、必要な再確認を依頼します。
9．実機確認は、CIとは別に記録する
ESP32などを使う場合、CIの成功だけで配線やセンサーの動作を確認したことにはできません。
PRには、例えば次の情報を残します。
| 項目 | 記録する内容 |
|---|---|
| ボード | 型番、必要に応じて個体識別 |
| Firmware | バージョンまたはコミット |
| 配線 | 電源、GPIO、I2Cアドレスなど |
| 操作 | 実行した手順と試行回数 |
| 結果 | 正常動作、エラー、復帰状況 |
| 未確認 | 精度、長期動作、未試験の条件 |
確認担当は、CI結果、差分、実機記録を確認して承認します。
実機確認をマージ条件とする場合は、その条件をCONTRIBUTING.mdなどにも明記します。
文章で決めた条件が、GitHub上で自動的に強制されるわけではありません。自動検査で確認する範囲と、人が確認する範囲を共有しておきます。
10．mainへのマージと公開を区別する
mainの更新が、そのままWeb公開につながる構成もあります。別の公開操作や、公開用リポジトリの更新が必要な構成もあります。
どちらなのかを、参加者へ明示します。
Firmwareを含む場合は、次の対応を確認します。
- 公開するソースの版
- 配布バイナリーとビルド情報
- Installerの設定
- 説明書の対象バージョン
- 実機確認済みの構成
公開担当は、公開後の確認結果と、問題があった場合の復旧方法を共有します。
11．最初のPRで運用を確認する
初回は、説明書の修正など、小さな変更で一周してみます。
確認するのは、コードの内容だけではありません。
- 招待とアクセス権が正しいか
- 作業ブランチへPushできるか
- PRで必要なCIが動くか
- レビュー条件が適用されているか
- マージ後に全員が更新を取得できるか
このとき詰まった操作や不足していた説明を、開発手順へ反映します。
設定だけを見て完了とせず、参加者の環境から実際に一度通してみることが大切です。
おわりに
少人数の共同開発では、変更を確認する場所、取り込む条件、公開を判断する担当を明確にしておくと、作業を進めやすくなります。
最初から多くのルールを設けるよりも、小さなPRで運用を確かめ、実際の作業で見つかった問題に合わせて設定と手順を改善していく形で始めたいと考えています。
私自身も、時間を置くと設定の理由や操作の順序を忘れてしまうことがあります。そのため、今回の内容を備忘録として残し、今後の共同開発で確認しながら更新していくつもりです。
※GitHubの機能・画面名は、2026年10月時点の公式ドキュメントをもとに記載しています。利用プランとリポジトリの設定に合わせて確認してください。