Gitって何？ コミット・プッシュ・マージを「1日の流れ」で説明します

AI コーディングツールを使っていると、「コミットしてプッシュしました」「プルリクエストを作りました」といった報告を受けることがあります。たとえば Claude Code は、ブランチの作成から、変更の記録（コミット）、プルリクエストの作成までを自分で行えます。

便利な一方で、Git や GitHub に触れたことがないと、何が起きたのかが分かりません。この記事では、コマンドの使い方には踏み込まずに、それぞれの言葉が何をしているのかを、「みんなで1冊の本を作る」というたとえで説明します。

「最終版_v3」問題

企画書や資料を何人かで直していると、「企画書_最終」「企画書_最終2」「企画書_本当に最終」のようなファイルが増えていきます。どれが最新なのか、誰がどこを直したのか、前の版のどこが良かったのか、だんだん分からなくなります。

プログラムのソースコードでも同じことが起きます。しかも、ソースコードは何人もが同時に、毎日少しずつ書き換えます。そこで使われるのが、バージョン管理の仕組みです。ファイルの変更を時系列で記録しておき、あとから特定の版を呼び出せるようにします。Git はそうした道具の1つで、2005年に Linux の開発コミュニティ（Linus Torvalds ら）が作り始めました。

Git と GitHub は別のもの

名前が似ていますが、Git と GitHub は別のものです。

• Git：ファイルの変更を記録する道具です。手元のパソコンにインストールして使い、ほとんどの操作は手元だけで完結します
• GitHub：Git の記録をインターネット上に置いて、みんなで共有したり、確認し合ったりするためのサービスです

たとえるなら、Git は「原稿と、これまでの版の記録」を自分の手元で管理する仕組みで、GitHub は、その原稿を置いておくみんなの本棚です。原稿と版の記録をまとめた箱を、リポジトリと呼びます。

Git では、参加する人それぞれの手元に、リポジトリが履歴ごとまるごと複製されています。最後に本棚から持ってきた時点の原稿と記録が、全員の手元にもある、という形です。

1日の流れで見てみる

ここからが本題です。チームで1冊の本を作っているつもりで、ある1日の作業を追いかけてみます。時間帯は説明のための一例で、実際の頻度はチームや仕事の大きさで変わります。

朝：最新を持ってくる（プル）、自分の作業の道筋を分ける（ブランチ）

作業を始める前に、まず本体の流れの上で、みんなの本棚から最新の原稿を持ってきます。これがプルです。寝ているあいだに、ほかの人が新しい章を足しているかもしれません。古い原稿のまま書き始めると、あとで食い違いが起きやすくなります。

次に、自分の作業のためのブランチを作ります。ブランチは、本体の流れから分かれた「自分の作業の道筋」です。ブランチの上で書いているあいだは、ほかの人の変更と切り離して作業できますし、本体の原稿も汚しません。この記事の例では、仕事を1つ始めるたびにブランチを1つ作ります。

昼：区切りごとに記録する（コミット）、本棚へ置く（プッシュ）

書き進めて区切りがついたら、その時点の原稿を写真に撮ってアルバムに貼っておきます。これがコミットです。Git はコミットのたびに、すべてのファイルの状態を写真のように記録します。写真の裏には「第2章の見出しを直した」のようなメモ（コミットメッセージ）を書きます。

写真が残っていれば、あとで「3枚前の状態に戻したい」「どこを変えたのか見比べたい」ができます。区切りのいいところで、こまめに撮っておくと安心です。

ただし、コミットは自分の手元のアルバムに貼っただけです。ほかの人にはまだ見えません。そこで、アルバムをみんなの本棚に置きに行きます。これがプッシュです。プッシュしておけば、ほかの人も進み具合を見られますし、手元のパソコンが壊れても記録は本棚に残ります。

もっとも、本棚に置いたアルバムは、まだ自分のブランチの記録として置かれているだけです。本体の原稿に入るのは、このあと確認を経てマージしたときです。

コミットしておいた原稿なら、前の写真がアルバムに残り続けるので、間違って消しても取り戻せます。裏を返すと、パスワードのような秘密の値を一度コミットすると、あとのコミットで消しても前の写真に残り続ける、ということでもあります。

夕方：確認をお願いする（プルリクエスト）

自分の章が書き上がったら、編集長に「この章を本に入れてください」とお願いします。これがプルリクエストです。プルリクエストは、変更をプロジェクトに取り込むための提案で、取り込む前に、ほかの人が内容を確認して意見を書けます。

確認する人は、変わったところを見比べて、「ここは分かりにくい」「この書き方のほうが安全」とコメントします。指摘を受けたら、自分のブランチで直してコミットし、もう一度プッシュします。同じブランチへの直しは、そのままプルリクエストにも加わります。

ここで説明しているプルリクエストは、GitHub の上で行うやりとりで、GitHub がみんなで確認し合うために用意している仕組みです。

翌朝：本体に取り込む（マージ）

確認が済んで OK が出たら、自分の章を本体に綴じ込みます。これがマージです。分かれて進めていたブランチの変更が、本体の流れに合流します。取り込み方には、マージコミット・スカッシュ・リベースといった種類があり、リポジトリの設定に応じて選びます。最初は「合流させる方法にもいくつか種類がある」とだけ知っておけば十分です。

この記事の流れでは、マージは GitHub の上で行うので、手元のパソコンにはまだ反映されていません。そこでこの記事の例では、次の仕事を最新の本体から始めるために、自分のブランチから本体の流れに戻り、そこでプルして最新を持ってきます。そのうえで、新しい仕事のための新しいブランチを作り、使い終わったブランチは片付けます。

よくやることと、仕事ごとにやること

1日の流れを並べ直すと、次のようになります。

すること	この記事の例での頻度
コミット（区切りごとに記録する）	1日に何回も
プッシュ（本棚へ置く）	区切りのいいところで、1日に何回か
プル（最新を持ってくる）	作業を始める前に
ブランチ（作業の道筋を分ける）	仕事1件につき1回
プルリクエスト（確認をお願いする）	仕事1件につき1回
マージ（本体に取り込む）	仕事1件につき1回

よく手を動かすのはコミットとプッシュ、それに作業前のプルです。ブランチ・プルリクエスト・マージは、仕事が1つ始まって終わるまでに1回ずつ回ってきます。

たまに出てくる言葉

2人が同じ行を直した（コンフリクト）

自分がブランチで作業しているあいだに、ほかの人が同じファイルの同じ行を、違う形に直していることがあります。そうした変更どうしを合流させようとすると、Git には、どちらが正しいのか判断できず、自動ではまとめられません。これをコンフリクト（衝突）と呼びます。

コンフリクトが起きたら、人が2つの変更を見比べて、どちらを残すか、両方を合わせるかを決めます。解消するまで、プルリクエストは本体に取り込めません。作業を始める前に最新を持ってきておくと、食い違いを小さくできます。

リベース

リベースも、マージと同じく、分かれた変更を合流させる方法の1つです。マージコミットが「合流した跡」を残すのに対して、リベースは自分の変更を最新の本体の後ろに付け替えて、履歴を一本道に見せます。

どちらを使うかはチームの決まりによります。1つだけ大事な注意があり、ほかの人がすでに持っている記録はリベースしないことです。ほかの人の手元の記録と食い違って、混乱のもとになります。

AI と分担するとき、人は何をするか

冒頭で触れたとおり、Claude Code は、ブランチの作成、コミット、プルリクエストの作成までを自分で行えます。1日の流れのうち、手を動かす部分の多くを AI に任せられます。

そうなると、人の仕事は次の2つに寄っていく、というのがこの記事の考えです。

• 何を作るかを決める：どんな章を、なぜ書くのかを決めて伝える
• 本体に入れてよいかを判断する：プルリクエストを読み、変わったところが意図どおりか、入れてはいけないものが混ざっていないかを確かめる

AI が「コミットしてプッシュしました」と言ったら、それは「手元のアルバムに写真を貼って、本棚に置いた」という意味です。「プルリクエストを作りました」なら、「編集長役のあなたの確認を待っている」状態です。1日の流れを知っておくと、AI の報告を読んで、次に自分が何を判断すればよいかが分かるようになります。