GitやGitHubをClaude Code経由で使う:リポジトリ作成からコンフリクト解決まで

YouTubeで開く ↗
概要

バイブコーディング超入門講座の第6回で、安野貴博氏はGitとGitHubの基本操作を実演した。コマンドを自分で打つのではなく、Claude Codeに日本語で頼みながら進めるのがこの回のやり方である。安野氏の立場は、「コミット」「プッシュ」といった単語さえ知っていれば、Claude Codeを通してGitやGitHubは使える、というものだ。画面上で氏がしているのは、話しかけて、Claude Codeの作業を確認し、許可ボタンを押すことだけだった。

12分で読めます

GitHubで新しいリポジトリを作る

実演はブラウザでGitHubにアクセスするところから始まる。ログインすれば各種機能が使える。安野氏によれば、GitHubはまだ英語にしか対応していないのでハードルが高く見えるかもしれないが、自動翻訳機能なども使いながら挑戦してほしいという。

最初にリポジトリを作る。安野氏はリポジトリを「ソースコードを入れておくための箱のようなもの」と説明し、GitやGitHubでは基本的にリポジトリ単位で作業を進めると述べた。リポジトリ名は「YouTubeテスト」とし、説明文(Description)にはこのリポジトリが何なのかを書く。

公開範囲(Visibility)には、パブリックとプライベートがある。パブリックにすると全世界に公開される。プライベートなら自分と、GitHub上で招待した人にしか見えない。安野氏は、最初からパブリックにすると公開してはいけないものが公開されてしまう事故が多いとして、よく分からないまま始める人にはまずプライベートを勧めた。その他の設定項目は上級者向けとして今回は触れていない。

「Create repository」を押すと、氏のユーザー名 takahiroanno の下にプライベートリポジトリができた。英語の説明がいろいろ表示されるが、まず見るべきは「Quick setup」の欄である。ここに書かれた文字列をコピーボタンでコピーし、Claude Codeに移る。

Claude Codeにリポジトリを手元へ持ってこさせる

Claude Codeには、コピーした文字列を貼り付けたうえで、「このリポジトリをGitHubで作ったので、手元のパソコンに持ってきてください」と頼む。安野氏によれば、Gitがきちんとインストールされていれば、あとはClaude Codeが自動でリポジトリを手元に持ってくる。

途中で、Bashコマンドを実行してよいかの確認が出る。安野氏は、ここで使われているのは一般的な方法なので「はい」を押してよいと説明した。これでリポジトリと同じ名前のフォルダが手元にでき、以降の開発はここで行う。

最初のファイルを作り、コミットする

次に安野氏は、「README.mdという名前のファイルを作って、『最初のセーブポイントを作るよ、コミットをするよ』と書いてください」と頼んだ。Claude Codeは作成するファイル名と内容を提示し、氏は内容を確認して許可した。

ここで「今のブランチの状況はどうなっていますか」と質問する。この指示は音声入力で出している。Claude Codeの回答は次のとおりだった。手元のmainブランチにいる。コミットはまだ1つもない。README.mdは作ったが、まだセーブされていない。リモートブランチもまだ空である。安野氏はリモートブランチを「GitHub上にあるリポジトリの状態」と補足した。

README.mdについては、リポジトリがどういうものかを伝えるため最初に読まれる「私を読んで」というファイルであり、GitHub上のさまざまなリポジトリにある、と説明した。

続けて「今のREADMEファイルをコミットして」と頼むと、コミットが完了した。画面にはコミットハッシュやメッセージ、ワーキングツリーといった言葉も出てきたが、安野氏はこれらを中級者向けとして脇に置き、「まずコミットが完了したこと」が大事だとした。

音声入力には「アクア」というツールを使っているという。コマンドキーを押しながら話すと、その部分だけが反映される仕組みで、安野氏は非常に便利だと評価している。

2つ目のセーブポイントと履歴の確認

もう1つファイルを作る。「メモというファイルを作って、『今日は2026年の5月です』と書いてください」と頼み、続けて「今の状態をコミットして」と指示した。これで2つ目のセーブポイントができた。

「今までに入ったコミットを見せて」と頼むと、Claude Codeは2つのコミットを示した。1つ目がREADME.mdの作成、2つ目がメモファイルの作成で、想定どおりの結果である。

mainで作業していたためプルリクエストが作れない

次に安野氏は、「この2つの今の状態をプッシュしてほしい。そのときにGitHubのmainに対してプルリクエストを出してほしい」と、プッシュとプルリクエストを一度に頼んだ。

Claude Codeはここで問題を指摘した。手元で作業しているのはmainブランチで、GitHub上にもmainブランチしかない。同じ名前のブランチからmainに向けてプルリクエストを出すことになるので、プルリクエストは作れない。プルリクエストを出すには別の対応が必要だ、という内容である。安野氏はこれを「いい指摘」と受け止め、最初にmainではなくブランチを切ってから作業を始めるべきだったと振り返った。

Claude Codeがどちらの対応にするか尋ねてきたので、安野氏は別ブランチを作ったことにして、2つのセーブポイントをそちらへ移す方法を選んだ。その結果、mainブランチと「initial-files」(最初のファイルを入れるブランチ)の2つができ、両方をプッシュしてプルリクエストを作成する流れになった。

この場面について安野氏は、自分で説明していても正直難しいことをやっていると認めている。そのうえで、難しい部分はClaude Codeがかなりうまく処理してくれるので、作業を始められるようになれば、「コミットして」「プッシュして」「プルリクエストを送って」「プルしてきて」とどんどん頼んでいけばよいと述べた。そうしているうちに、Gitがどういうものか分かってくるという。

GitHub上でプルリクエストを確認してマージする

GitHubに戻ると、Pull requestsに「1」と表示されていた。開くと「READMEを追加し、メモファイルを追加した」という内容になっている。「Files changed」を見ると、README.mdに「最初のセーブポイントを作るよ、コミットするよ」、メモに「今日は2026年の5月です」と書かれていることが確認できる。

内容を見て「これがやりたかった」と判断したら「Merge pull request」を押す。これでブランチ上の2つのセーブポイントがGitHub上のmainの記録に取り込まれ、表示が紫色の「Merged」に変わった。安野氏はこれを「mainの歴史が作られた」と表現した。

トップページのCodeタブには、README.mdとメモの2ファイルが並んでいる。README.mdはGitHub上で特別扱いされるファイルで、その内容がページ下部に表示される。

4月ブランチと6月ブランチでわざと衝突を作る

後半のテーマは、たとえば安野さんと山田さんが別々のプルリクエストを送り、内容がぶつかった場合、つまりコンフリクトが起きた場合の対処である。

まず新機能用のブランチを切る。安野氏は、先ほどのマージでGitHub上と手元の状態が食い違っているはずだと考え、「まずプルして状況を合わせてから、『4月』という名前のブランチを切ってください」と頼んだ。Claude Codeはmainをプルしてマージ後の最新状態に同期し、4月ブランチを作って移動した。安野氏は、日本語のブランチ名も作れるようになっていることに触れている。

4月ブランチでは、あえて「嘘」の変更を入れる。「メモに2026年5月と書いてあると思うが、それを2026年4月にしてください」と頼み、変更を確認してからコミットし、「2026年4月にする機能」としてプルリクエストを出させた。

このプルリクエストはすぐにマージせず、別の嘘を加える。「別の機能を作りたいので、4月ブランチのことは一度忘れて、mainをもとに『6月』というブランチを作ってください」と頼み、6月ブランチでメモを「今日は2026年の6月です」に書き換えた。こうして4月方向と6月方向に分岐した2つのブランチができ、両方についてプルリクエストを出した。

GitHub上で起きたコンフリクト

GitHubには「2026年4月になる機能」と「2026年6月になる機能」の2つのプルリクエストが並んだ。安野氏は、これらは真っ向からぶつかる機能で、「今何月やねん」と分からなくなると説明した。

先に4月のプルリクエストを開く。Files changedでは、赤が変更前、緑が変更後として、5月から4月への変更が示されている。これをマージすると、Codeタブのメモは「今日は2026年4月です」になった。

続いて6月のプルリクエストを開くと、5月から6月への変更が表示されるが、マージができない。英語の表示は、マージがブロックされている、マージの要件を満たしていない、というものだった。「This branch has conflicts that must be resolved」、つまり解決しなければならないコンフリクトがあるという意味である。

「Resolve conflicts」を押すと矛盾している箇所が表示される。mainでは4月、このブランチでは6月と書かれている、という状態だ。安野氏によれば、今回は1行だけなので単純だが、実際にさまざまな機能を開発していると、何行にもわたる食い違いが発生し、もっと大きなコンフリクトになることがある。GitHub上でも解決できるが、今回はClaude Codeで解決する。

Claude Codeでコンフリクトを解決する

プルリクエストには番号が振られている。安野氏は背番号のようなものと説明した。ここでは3番目が6月のプルリクエストだった。安野氏は「3番のプルリクエストをマージしようとしたらコンフリクトが発生していたので、解決したい。どうしたらいいですか」と尋ねた。コンフリクトが起きたらClaude Codeに何とかしてくれと頼む、基本的には「Claude Codeに頼みまくる人生」だ、というのが氏の言い方である。

Claude Codeは原因を説明した。先に4月がマージされたうえで、6月ブランチが元の5月を6月に変えているため、同じ行で衝突している。解決手順としては、手元の6月ブランチに最新のmainを取り込み、コンフリクトを解決してからプッシュすることを提案した。安野氏はこれを、自分のパソコンの中で一度解決し、その結果を3番のプルリクエストにプッシュするという意味だと言い換え、基本的に提案に従って進めた。

Claude Codeは解決方法として、マージとリベースの2つを示した。安野氏は、セーブポイントを編集する方法にはいろいろあり、これは上級者向けの話で流派もあると述べたうえで、ひとまずマージでよいとした。

取り込みの結果、コンフリクトが発生し、Claude Codeはメモの中身を示した。そして「このブランチは6月の機能なので、6月を採用してマーカーを取り除きます」と提案してきた。安野氏はここで、4月か6月かは最終的に人間が選ぶ必要があると強調した。Claude Codeにはどちらが正しいか分からないからである。自分が作ってきた機能に誤りがあったと気づいたら「ノー」と言えばよい。実演では提案を断り、「今は4月だったことに気づいたので、このコンフリクトでは4月を正しいことにして」と指示した。

Claude Codeは4月を採用し、差分では6月の行が赤く、消える行として表示された。「今日は2026年4月です」が残る形でコンフリクトが解決され、プッシュまで完了した。Claude Codeはこれでマージ可能になっているはずだと報告した。

まとめとして示された一連の流れ

安野氏は、今回はこれまでの超入門講座と比べて難しい内容が多かったと認めている。最初に覚える操作を5つに絞っているが、それでも大変だろうとし、実際に使い倒しながら、分からないことが出るたびにClaude Codeに聞いて、少しずつGitに慣れてほしいと述べた。

氏が整理したGitとGitHubの役割はこうだ。手元で保存し、クラウドのGitHubに上げる。GitHubの内容はWebに公開することもできる(これは今後の回で扱うという)。作業の流れは次のとおりである。ブランチを切って、どの機能を作るかという方向を決める。作業しながらコミットを重ねる。それをGitHubにプッシュしてプルリクエストを出す。内容を確認して、GitHub上のmainブランチに取り込む。次に作業するときは、取り込まれた内容をプルで手元に持ってきてから始める。安野氏は、この流れができるようになると、できることが大きく広がると述べている。

最後に氏は、以前はこうしたコマンドを全部自分の手で打たなければならなかったと振り返った。実演中にClaude Codeが実行していた「git add」やcommitなどのコマンドがそれにあたる。今はClaude Codeがすべてやってくれるので、超入門段階の人はまずClaude Codeに任せるところから始め、そのうちClaude Codeが何をしているのか分かるようになればよい、というのがこの回の結論だった。