GitHub Settings
GitHubリポジトリのbranch設定とは？
branch設定は、どの作業場所を本線にするか、どこへ変更を入れるかを管理する設定です。
このページで整理すること
- main branchの意味
- 作業branchの使い方
- Pull Requestとの関係
- branch protectionの考え方
- Codex作業でmain直pushを避けること
設定画面で見る場所
Settingsは、リポジトリの公開範囲、権限、branch、Secrets、Pages、危険操作が集まる場所です。初心者は変更する前に、まずどこに何があるかを確認するところから始めます。
| 設定 | 一言でいうと | 注意点 |
|---|---|---|
| Visibility | 公開範囲 | public/private変更は慎重に |
| Collaborators | 共同編集者 | 不要な権限を増やさない |
| Branch | 作業の本線 | main直pushに注意 |
| Secrets | 秘密情報の保管 | 実値を公開しない |
| Pages | Web公開設定 | 秘密情報を出さない |
| Danger Zone | 危険操作 | 基本触らない |
変更する前に確認すること
| 確認項目 | 見ること | 止める条件 |
|---|---|---|
| main | 本線のbranch | 直接変更しそう |
| 作業branch | 変更を分ける場所 | 作業場所が不明 |
| PR | 変更前の確認 | レビューなしでmergeしそう |
Codexと使う時の注意点
- Codexへ作業を頼む前に対象リポジトリとbranchを確認する
- public/privateとPages公開範囲を確認する
- Secretsや認証情報の実値を指示文に書かない
- 作業後はGitHubまたはGitHub Desktopで差分を見る
- push、merge、公開範囲変更は人間が慎重に判断する
やってはいけないこと
- Settings変更を軽作業扱いしない
- public/private変更を勢いで行わない
- Secretsの実値を書かない
- main直pushや強制pushをすすめない
- Danger Zoneの削除や転送を通常作業として扱わない
- Codexに設定変更を丸投げしない
- 事故が起きない、完全に安全、と保証しない
最初に決めるのは「直接触らない場所」だけ
ブランチの設計は凝りだすときりがありませんが、個人や少人数なら決めることは1つです。公開しているものの元になるブランチを、直接編集しないと決めるだけで、事故の大半が防げます。
流れはこうなります。作業は別のブランチで行い、確認してから元のブランチに取り込む。この一手間があるだけで、「直したつもりが公開側を壊していた」が起きなくなります。逆に、この一手間を省くと、AIに作業を任せる時にとくに危険です。生成された変更がそのまま公開側に入るためです。
保護設定は「自分のうっかり」を止めるために使う
ブランチの保護というと複数人向けの機能に見えますが、1人で使う場合こそ効きます。止めたい相手は他人ではなく、急いでいる時の自分だからです。
最低限入れておくと効くのは次の2つです。
- 直接の変更を禁止する：必ずPRを経由させます。ワンクッション入るだけで、意図しない変更に気づけます
- 強制的な上書きを禁止する：履歴ごと書き換える操作を止めます。これを許していると、復旧の手がかりまで消えることがあります
設定した直後は面倒に感じますが、1度でも助けられると外せなくなります。まず1つのリポジトリで試してから、他へ広げてください。
関連ページ
FAQ
Settingsは初心者が触ってもよいですか？
見ることは大切ですが、変更は影響を確認してからにします。特に公開範囲、権限、Danger Zoneは慎重に扱います。
CodexにSettings変更を頼んでよいですか？
確認リストの整理は頼めますが、公開範囲変更、削除、権限変更などは人間確認を前提にします。
privateなら安全ですか？
privateは見える人を制限できる設定です。APIキーやパスワードなどの秘密情報をそのまま入れてよいという意味ではありません。
Secretsの値を本文に書いてよいですか？
書かないのが基本です。実値ではなく「Secretsに設定済み」など一般化して扱います。