バイブコーディングのためのGit入門：まず覚える5つの操作とコンフリクト

なぜGitとGitHubが必要なのか

安野は、バイブコーディングをしていると次のような場面が出てくると話す。

今まで動いていた機能が壊れたので、元に戻したい
自分が作った機能を他の人と共有し、2人やチームで開発したい
作ったものを全世界に公開したい

これらはどれも、GitとGitHubを使えるようになれば実現できる。安野はこの技術を、いろいろなことの「コア」になっているものと位置づけ、これができるだけでできることがかなり広がると説明した。講義の図解は、話したい内容をChatGPTに入れて作ってもらった画像だという。

GitとGitHubの違い

安野の説明では、Gitはローカル、つまり自分のパソコン上で編集の履歴を管理する機能である。これはバージョン管理機能とも呼ばれるが、安野は要するに「セーブポイント」だと言い換える。今の状態を保存しておくのがGitの役割だ。

一方のGitHubは、Gitで作ったものをクラウド上で共有したり、公開したり、やり取りしたりする場所である。バージョン管理だけならGitだけでもできる。ただ業界標準としては、ソフトウェアエンジニアはGitのセーブポイントをGitHubに次々とアップロードし、それを通じてみんなでデータを共有している。

両方を使うと、次の一連の流れが可能になる。手元のパソコンで作業して保存し、それをGitHubに上げる。さらに、クラウド上のソースコードを別のサーバーに移してWeb上に公開する。

20個から5つへ絞った操作

安野によると、Gitの操作は本来20個くらいある。今回は「超入門講座」として削れるところを全部削り、それでも覚えてほしい5つだけを残した。本人も、世の中のGit講座の中で一番削ぎ落としているくらいだと言う。詳しい人が見れば「あの機能はどうした」「あれも必要だろう」という意見が色々あるはずだと認めている。そのうえで、AIの支援があればこの5つで足りるだろうという見立てを示した。

5つとは、ブランチ、コミット、プッシュ、プルリクエスト、プルである。

ブランチ：履歴を枝分かれさせる

安野はまずゲームのたとえを使う。ゲームでは、ボス戦の手前のようにいいところまで進んだらセーブしておき、負けたらそのセーブポイントに戻って再挑戦する。開発でも同じように、新しい機能を実装する前に今の状態をセーブしておけば、いつでもそこに戻れる。

講義の図では、時間は左から右へ流れ、線上の小さな丸がセーブポイントを表す。ゲームのセーブと違うのは、Gitでは歴史を枝分かれさせられる点だ。分かれ道で「右に行った場合」と「左に行った場合」を別々のルートとして進められる。この枝分かれを行う操作がブランチである。

ブランチした先での作業は、元のセーブポイントの状態に影響しない。安野によると、枝分かれしても元に戻せないわけではない。分岐先でいい機能ができれば、それを元の歴史に取り込める。枝分かれして試し、うまくいったものを正しい歴史として採用する、という使い方ができるわけだ。

コミット：セーブポイントを刻む

2つ目のコミットは、図の小さな丸を作ること、つまり今の状態をセーブポイントとして刻むことである。安野の説明する基本の進め方はこうだ。ブランチを切り、編集していい感じになったらコミットする。また編集して、いい感じになったらまたコミットする。こまめにコミットしてセーブポイントを作りながら前に進むのが、Gitでの作業になる。

プッシュ：手元の作業をクラウドへ送る

3つ目のプッシュは、手元のパソコンで作業したものをGitHubのクラウド上に送信する操作である。これで手元の作業をGitHubにアップロードできる。安野は「押し込む」という語の意味にも触れている。

プルリクエスト：メインの歴史への取り込みを依頼する

図の黒い線には「main」と書かれている。これはメインブランチ、名前の通りメインの歴史だ。手元で枝分かれして「こういう作業をした」「こういう機能を作った」という内容をGitHubにプッシュする。そして、それをメインの歴史に入れてほしいと依頼する。これがプルリクエストである。「プルリク」や「PR」とも呼ばれる。プルリクエストはGitHub上で内容を見たり、レビューしたりできる。

プル：最新の状態を手元に引っ張ってくる

ここまでの1〜4で、分岐を作り、セーブし、クラウドにアップロードし、メインの歴史に入れ込むことができた。次に、クラウド上で更新された新しい歴史を自分のパソコンに持ってきたい。そのときに使うのが5つ目のプル、つまり「引っ張る」操作である。

安野は、プルは複数人で開発しているときに特に大事だと説明し、例を挙げた。安野が自分のブランチ（仮に「安野」ブランチ）を作り、別の人が「山田」ブランチを作ってそれぞれ作業する。安野は自分のブランチをプッシュし、「安野の機能を作ったから入れてくれ」とプルリクエストを送る。山田さんも同じように「山田機能」のプルリクエストを送る。

両方が採用され、マージされたとする。このとき、安野の手元とクラウド上の正しい歴史には差がある。手元には自分で開発した安野の機能は入っているが、山田機能は入っていない。山田機能は山田さんのパソコンと、山田さんがプッシュしたGitHub上にしかない。だから自分の手元に山田機能を持ってくるには、プルが必要になる。

安野は全体を次のようにまとめる。クラウドへのプッシュとクラウドからのプルが対になっている。そのうえで、ブランチを切り、コミットでセーブポイントを打ち、プルリクエストを出すという一連の流れがある。

もう1つの重要概念：コンフリクト

5操作に加えて、安野は「コンフリクト（衝突）」を重要な概念として挙げた。

例として、ホームページ制作を考える。安野がブランチを切り、テーマカラーを赤にする作業をしてコミットし、プッシュしてプルリクエストを送る。その間に山田さんは「テーマカラーは青にしよう」と、青にする変更をプッシュする。すると、同じテーマカラーの項目に「赤」と書かれたブランチと「青」と書かれたブランチができ、2つが衝突する。

この状態では、プルリクエストを単純に採用することはできない。安野によると、Gitは「ここは衝突しているので、どうするか結論を出してください」とユーザーにしっかり伝えてくる。人間がそれを受けて、たとえば「青にしよう」と決めて解決する、という流れになる。

実演：ファイルを作ってコミットする

安野は、ここまでの説明だけでは「何のこっちゃよくわからん」というのが正直なところだろうと述べた。そこで、ブランチを切り、コミットし、プッシュし、プルリクエストを送り、プルしてくるという1〜5の流れを実際にやってみると予告し、AIへの指示による実演に移った。

字幕で確認できる実演は次の部分までである。まず、テキストファイルを作り「最初のセーブポイントを作るよ、コミットをするよ」と書くよう指示した。AIからはファイルを作成したという返答と、その内容が表示された。次に現在のブランチの状況を尋ねると、mainブランチにいるという答えが返ってきた。これまでのコミットを見せるよう頼むと、入っているコミットは2つで、無事作成されていることが示された。

字幕に残っている実演はここで終わっている。プッシュ、プルリクエスト、プルの手順が実際にどう進んだかは、字幕からは確認できない。