どんな場面で検討するか
ソースコード・変更理由・レビュー・課題を同じリポジトリに残し、社内外で開発と保守引継ぎを行う場合。
組織で使う条件
会社管理の組織で最小権限と管理者の復旧経路を維持する。 保護ブランチで強制push・直接変更・未レビューのmerge条件を確認し、契約プランとの対応を照合する。
採用前に試すこと
- 合成アプリの非公開リポジトリと社員役/外部役を作り、変更をPRへ出す。
- 必須レビュー/チェックを設定し、直接pushとチェック失敗時のmergeを試す。
- 新担当が履歴から起動/変更/戻しを再現し、外部役の権限失効を確認する。
合格と判断する条件
- 機密を含まず、対象の役だけがソースを読める。
- 未承認変更が保護対象へ入らず、必要なレビュー履歴が残る。
- 新担当が再現でき、失効後の外部役はアクセスできない。
見落としたくない点
- 閉域/データ所在地/契約要件が満たせるか不明なら、Enterprise等の提供条件や他のソース基盤と比較する。 レビュー運用を定めず、GitHubへ保存しただけで品質管理が完了とは判断しない。
- 閉域/データ所在地/契約要件が満たせるか不明なら、Enterprise等の提供条件や他のソース基盤と比較する。
- レビュー運用を定めず、GitHubへ保存しただけで品質管理が完了とは判断しない。