この記事でわかること
AIエージェントを使ってWebサイトやアプリを作っていると、途中で「コミットしますか」「プッシュしますか」「PRを作りますか」「マージしますか」と聞かれることがあります。
これらはGitとGitHubの用語です。最初は難しく見えますが、本質は「変更を安全に記録し、確認してから公開へ進めるための言葉」です。
なお「ブッシュ」と聞こえる場合は、多くの場合「プッシュ」のことです。英語では push と書きます。
OVERVIEW
まず全体像
基本の流れは次の通りです。
- 1作業用のブランチを作る。
- 2変更を小さな単位でコミットする。
- 3コミットをGitHubへプッシュする。
- 4PRで変更内容を確認できる状態にする。
- 5問題なければmainへマージする。
- 6サイトやアプリへデプロイする。
GLOSSARY
用語集
| 用語 | ひとことで言うと | AIエージェントが確認していること |
|---|---|---|
| リポジトリ | プロジェクトと変更履歴をまとめて置く場所 | このプロジェクト全体を管理対象にしてよいか |
| ワークツリー | いま手元で開いている実際のファイル群 | まだ記録していない変更が残っているか |
| ステージング | コミットに入れる変更を選ぶ一時置き場 | どの変更だけを記録対象にするか |
| コミット | 変更をひとまとまりで記録すること | この内容を履歴として残してよいか |
| コミットメッセージ | その変更を説明する短い見出し | 後から読んで意味がわかる名前になっているか |
| ブランチ | mainから分かれた作業用の脇道 | 本流を壊さずに別ルートで作業してよいか |
| main | 公開・本番に近い本流のブランチ | ここに入る変更は十分確認済みか |
| プッシュ | 手元のコミットをGitHubへ送ること | ローカルの変更を外部の共有場所へ送ってよいか |
| プル | GitHub側の最新変更を手元へ取り込むこと | 他の変更とズレていないか更新してよいか |
| PR | Pull Request。変更内容を見せて合流を依頼する場 | この変更を本流へ入れる提案として出してよいか |
| レビュー | PRの内容を確認すること | 仕様、表示、セキュリティ、文章に問題がないか |
| マージ | ブランチの変更をmainなどへ合流させること | 確認済みの変更を本流へ入れてよいか |
| コンフリクト | 同じ場所を別々に変更してぶつかること | どちらの変更を採用するか人間の判断が必要か |
| デプロイ | 作ったものを公開環境へ反映すること | サイトやアプリに見える形で出してよいか |
| ロールバック | 問題があった変更を戻すこと | 直前の安定状態へ戻す必要があるか |
TRANSLATION
用語を会話に置き換える
| AIエージェントの言葉 | 普通の言い方 |
|---|---|
| ブランチを作ります | 本番とは別の作業スペースを作ります |
| 変更をステージします | 記録する変更だけを選びます |
| コミットします | ここまでの作業を保存ポイントとして残します |
| プッシュします | GitHubに送って共有します |
| PRを作ります | 変更内容の確認依頼を出します |
| マージします | 確認済みの変更を本流に入れます |
| デプロイします | サイトやアプリに反映します |
DECISION
迷ったときの判断基準
コミット
進めやすい手元の履歴を残す行為です。機密情報や不要なファイルが混ざっていなければ、こまめに残す方が安全です。
プッシュ
少し慎重GitHubへ送るため、ローカルだけの話ではなくなります。公開リポジトリでは特に確認してください。
PR
安全確認向き変更内容を一覧で確認できます。すぐマージせず、PRとして見える状態にするのは良い判断です。
マージ・デプロイ
慎重に判断本流や公開環境へ反映されます。ビルド、表示確認、公開してよい内容かを見てから進めます。
AIエージェントは作業係。最終承認者は人間です。
AIは作業を速くできます。ただし、公開してよいか、共有してよいか、本流に入れてよいかを判断するのは人間の役割です。特にプッシュ、マージ、デプロイは、内容を確認してから進めてください。
まとめ
ブランチ
作業する場所を分ける
コミット
変更を記録する
プッシュ
GitHubへ送る
PR
確認依頼を出す
マージ
本流へ入れる
デプロイ
公開環境へ出す
AIエージェントの導入や、GitHubとCloudflare Pagesを使ったWeb運用の整理もサポートしています。
お問い合わせ