共同開発リポと個人リポを分ける — 次期アプリ用リポジトリ新設の判断

2026年7月8日

アマグラマー

共同開発リポと個人リポを分ける — 次期アプリ用リポジトリ新設の判断

GeoDiveExa（GDE）を含む .NET MAUI 群のリポジトリ「TypeA」は、共同開発者と共有しているリポジトリです。一方、次期アプリとして計画している GeoC（杭打ちナビ）、GeoD（工事写真の座標検証）、GeoE（RTK品質可視化）の3本は、まったく別のリポジトリ「TypeB」で開発しています。同じ .NET MAUI・同じ現場向けRTK技術を使うのに、なぜリポジトリを分けたのか。個人開発と共同開発が混在する構成の判断基準をまとめます。

※本記事では、非公開の次期アプリ名・リポジトリ名は伏せ、それぞれ GeoC/GeoD/GeoE、TypeA/TypeB/TypeC という仮称で表記しています。

1リポに全部入れる誘惑と問題

技術的には同じ言語・同じフレームワーク・共通ロジックを使うので、既存の TypeA に新アプリのフォルダを追加するだけで済ませたくなります。実際、兄弟アプリの GeoDiveMrg1（GDM1）・GeoDiveExa for GPS（GDP1）は、GDE と同じリポジトリに同居しています。

ただし次期アプリは「GDEの現場計測」とは別の事業ライン（杭打ちナビ・写真補正・RTK品質可視化）で、サブスクリプション課金や価格戦略など、共同開発者に開示する必要のない情報を含みます。1つのリポジトリに全部入れてしまうと、共同開発者に見せる範囲を細かく制御できず、コミット履歴・Issue・ブランチが事業ラインをまたいで混ざってしまいます。

分けた基準

観点	TypeA（共有）	TypeB（個人）
誰が触るか	共同開発者＋自分	自分のみ
課金・価格情報	含まない	含む（次期アプリの価格戦略など）
リリース周期	共同開発者のスケジュールに合わせる	自分の裁量で決められる
公開範囲	共同開発者と共有（Private）	完全に個人管理（Private リポジトリ）

判断のポイントは、技術的な近さではなく「誰が触るか」「見せてよい情報か」「リリースのタイミングを誰が決めるか」という運用面でした。

分けて困ったこと — ライブラリの手動同期

共通エンジンであるC#版 GeoCoreJP は、正本を TypeB リポジトリに置き、TypeA 側の 1net10-code/GeoCore はその複製として手動で同期しています。2リポジトリにまたがるため、GeoCoreJP を更新するたびに「正本はどちらか」を意識し、複製側へのコピー漏れがないよう注意する必要が出てきました。分割の代償として、この手動同期という運用コストは正直に認めておく必要があります。

GitHubのPrivate運用

TypeB は GitHub 上で Private リポジトリとして運用しています。共同開発者を招待しない前提のリポジトリなので、Issue・Project・Actions の設定も自分ひとりの作業フローに最適化できるのが利点です。TypeA 側は共同開発者の権限・レビュー体制に合わせた運用が必要になる一方、TypeB 側は変更の速度を優先できます。

リポ構成の全体図

TypeA（共有・.NET MAUI）: GeoDiveExa（GDE）／GeoDiveMrg1（GDM1）／GeoDiveExa for GPS（GDP1）
TypeB（個人・.NET MAUI）: GeoC／GeoD／GeoE（次期アプリ3本）
TypeC（個人・Swift/Xcode）: GeoConverterPro（GCVP）／GeoPrism JP（GPRM）／次期アプリ数本

同じ「Geo」ファミリーでも、事業ラインと開発体制の違いによって3つのリポジトリに分かれている、というのが現在の全体像です。