〖Git/GitHub 徹底入門〗コマンド暗記はもう不要 ── Claude Code・Codexで「話して使う」バージョン管理のすべて

6月 24, 2026

この記事は、AIコーディング(バイブコーディング)を始めた方が必ず最初にぶつかる「Git(ギット)」と「GitHub(ギットハブ)」を、専門知識ゼロからでも分かるように徹底解説するものです。土台にしたのは、安野貴博さんの「バイブコーディング超入門講座」第5回(概念編)と第6回(実演編)です。本稿では、その内容を入り口に、Claude CodeやCodexで使うことを前提に、Git/GitHubを1本につなぎ直します。読み終えるころには、5つの操作とその流れが、頭の中で1枚の地図になっているはずです。

まずは概念編(第5回)から、全体像をつかんでください。下の動画が、Git/GitHubの地図を一望させてくれます。

グロッサリー(用語の早見表)

Git(ギット): 手元のパソコン上で、ファイルの変更履歴を管理する仕組みです。バージョン管理機能とも呼びます。早い話が「セーブポイントを作る道具」です。
GitHub(ギットハブ): Gitで作ったセーブポイントを、クラウド上に上げて保存・共有・公開する場所です。
ローカル(local)とリモート(remote): ローカル(local)は手元のパソコン、リモート(remote)はGitHub(クラウド)側を指します。
リポジトリ(repository): ソースコードを入れておく箱です。プロジェクト1つにつき、1つの箱を使います。
クローン(clone): GitHub上のリポジトリ(repository)を、自分のパソコンにコピーして持ってくることです。
コミット(commit): その時点のファイルの状態を記録する、ゲームのセーブポイントです。
ブランチ(branch): 本流から枝分かれさせた、作業用の枝です。代表的な本流の名前がメイン(main)です。
プッシュ(push): 手元のコミット(commit)を、GitHubに上げることです。
プル(pull): GitHub上の最新の状態を、手元に持ってくることです。
プルリクエスト(pull request): 自分の枝の変更を、本流に取り込んでほしいと提案する依頼です。プルリク(pull request)、PRとも呼びます。
マージ(merge): プルリクエスト(pull request)を承認して、変更を本流に取り込むことです。
コンフリクト(conflict): 2つの変更が同じ場所を書き換えてぶつかり、どちらを採用するか機械では決められなくなった状態です。
README(リードミー): リポジトリ(repository)の説明を書く、最初に読まれる看板のファイルです。

はじめに ── なぜ今、Git/GitHubを学び直すのか

Claude CodeやCodexのおかげで、プログラミングの経験がない方でも、アプリやWebサイトを作れる時代になりました。いわゆるバイブコーディングです。頭の中のアイデアを言葉で伝えるだけで、AIがコードを書いてくれます。ところが、少し作り進めると、必ず「Git」と「GitHub」という言葉が立ちはだかります。入門者向けの解説でも「正直、かなりの難関」と言われるほどです。

少しだけ、私たちの立場を書きます。このニュースレターは普段、医療AIを主題にしています。Git/GitHubは、その文脈では一見、遠い話題に見えるかもしれません。けれども、AIが当たり前の道具になった今、Git/GitHubの基礎は、医療に携わる方にとっても、一人ひとりが身につけておきたいAIリテラシーの一部になりつつあります。ここで言いたいのは、医療従事者が自分でアプリを開発すべきだ、ということではありません。AIを使いこなす時代の個人の教養として、知っておく価値がある、ということです。だから、あえてここで正面から扱います。

学ぶ価値があるのは、ここを越えると、できることの幅が一気に広がるからです。Git/GitHubが効いてくる場面は、大きく3つあります。1つ目は、動いていた機能が壊れたときに、前の状態へ戻したい場面です。AIに頼んで直してもらううちに、かえっておかしくなることは珍しくありません。そんなとき、セーブポイントがあれば安全に巻き戻せます。2つ目は、誰かと一緒に開発したい、つまりチームで進めたい場面です。3つ目は、作ったものを全世界に公開したい場面です。この3つはどれも、Git/GitHubが土台になっています。

本稿のゴールは、この土台を、たった5つの操作で理解することです。ブランチ(branch)、コミット(commit)、プッシュ(push)、プルリクエスト(pull request)、プル(pull)。世の中のGit講座の中でも、ここまで削ぎ落とした説明はめずらしい、というほど絞り込んだ5つです。本来は20個ほどある操作を、超入門のために削れるだけ削った結果が、この5つだというわけです。そして、その5つを実際に動かすのは、もうあなたではなく、Claude CodeやCodexです。だからこそ、暗記ではなく、意味の理解に集中できます。

この記事は、コードを書いた経験がまったくない方を想定して書いています。専門用語はそのつど、やさしい言葉で言い換えますし、途中で分からない言葉が出てきたら、いつでも冒頭のグロッサリーに戻れば大丈夫です。順番に読み進めれば、リポジトリ(repository)という箱を作るところから、複数人の変更がぶつかる衝突を解決するところまで、ひとつながりの流れとして頭に入ります。逆に言えば、ここで扱うのはその一本道だけで、枝葉の機能はあえて省いています。まずは幹を太くするつもりで、肩の力を抜いて読んでみてください。

第1章: GitとGitHubの違い ── 手元のセーブとクラウドの共有

最初に、よく混同される2つを、はっきり分けておきます。

Gitは、手元のパソコン(ローカル(local))の中で、編集の履歴を管理する仕組みです。今の状態を保存しておく、つまりセーブポイントを作るのがGitの役目です。実は、Gitだけでもバージョン管理はできます。インターネットにつながっていなくても、手元で「ここまでの状態を記録する」ことが可能です。

GitHubは、そのGitで作ったセーブポイントを、クラウド上に上げて、保存・共有・公開・コミュニケーションする場所です。ソフトウェアエンジニアの世界では、これが業界標準になっていて、みんなが自分のセーブポイントをGitHubにどんどんアップロードし、データを共有しています。なぜ標準になったのかと言えば、コードを1か所に集めておけば、別のパソコンからでも続きができ、他の人にも見てもらえ、過去のどの時点にも戻れるからです。手元のセーブ(Git)だけでは、その箱は自分のパソコンの中に閉じてしまいます。クラウドの共有(GitHub)を足すことで、はじめてチームや世界とつながります。

この2つを合わせると、1本の流れができあがります。手元のパソコンで操作したものを保存し、それをGitHub(クラウド)に上げ、さらにそのコードを別のサーバーに移せば、Web上に公開できます。手元で作る、クラウドに上げる、世界に公開する。この道のりの土台が、GitとGitHubなのです。混乱したら、Gitは「手元のセーブ」、GitHubは「クラウドの共有」、とだけ覚えておけば迷いません。

もう少しイメージを足します。Gitが管理する歴史は、点が一列に並んだ線のようなものです。1つの点が1つのセーブポイントで、新しく保存するたびに、右へ点が増えていきます。GitHubは、その線をクラウドに置いて、いつでも誰でも同じ線を見られるようにする仕組みだと考えてください。手元にも線があり、クラウドにも線があって、その2本をそろえていくのが、これから説明するプッシュ(push)やプル(pull)です。この「2本の線をそろえる」という感覚が、Git/GitHub全体を貫く背骨になります。

第2章: リポジトリ(repository)とクローン(clone) ── 箱を作り、手元に持ってくる

実際の第一歩は、リポジトリ(repository)を用意することです。リポジトリ(repository)は、ソースコードを入れておく箱だと考えてください。Git/GitHubは、基本的にこの箱の単位で物事が進みます。1つのアプリやサイトにつき、1つの箱、というイメージです。

箱の中には、プログラムのファイルだけでなく、設定ファイルや、さきほど触れたREADMEなど、そのプロジェクトに関わるものをまとめて入れます。GitHubは、その箱を世界中から預かってくれる、巨大な倉庫のような場所だと考えると分かりやすいです。自分の棚を、世界に開放するのか、それとも鍵をかけて自分だけのものにするのか。それを選ぶのが、次に出てくる公開範囲の設定です。

箱はGitHubのサイトで作ります。ログインが必要です。GitHubは今のところ英語が中心なので、ハードルが高く見えるかもしれませんが、ブラウザの自動翻訳機能を使えば十分に進められます。新しいリポジトリ(repository)を作る画面で、名前を決め、簡単な説明を書き、公開範囲を選びます。

公開範囲は、とても大切な選択です。パブリックにすると全世界に公開され、プライベートにすると自分と、招待した人だけが見られます。慣れないうちは、必ずプライベートを選んでください。パブリックにすると、公開してはいけない情報、たとえばパスワードやAPIキー(外部サービスを使うための鍵)が、意図せず世界中に見える事故が起きがちだからです。まだよく分からないうちは、プライベートが鉄則です。公開は、慣れてから、公開してよい中身だと確信できたときに切り替えれば十分です。

箱をGitHub上に作ると、英語でいろいろな案内(クイックセットアップ)が表示されますが、Claude Codeに任せる場合は、深く読み込まなくても大丈夫です。やることは、その箱を手元のパソコンに持ってくることです。これがクローン(clone)です。Claude Codeに「このリポジトリ(repository)を手元のパソコンに持ってきて」とお願いすれば、AIが必要なコマンドを実行して、箱を手元にコピーしてくれます。途中で「このコマンドを実行していいですか」と聞かれますが、クローン(clone)のような一般的な操作なら、内容を確認して許可して構いません。これで、自分のパソコンの中で開発を始められます。

第3章: コミット(commit)とブランチ(branch) ── セーブポイントと枝分かれ

ここからは実際の操作です。手を動かす様子は、実演編(第6回)の動画と見比べると、画面とのつながりがつかめます。

開発を始めたら、まずファイルを作ります。最初におすすめなのが、READMEというファイルです。READMEは、そのリポジトリ(repository)が何なのかを最初に伝える看板で、GitHub上では特別に、トップページにその中身が表示されます。世の中のいろいろなリポジトリ(repository)を見ると、たいていREADMEが置かれていることに気づきます。「まず私を読んでね」という、案内役のファイルです。

ファイルを作ったり直したりしたら、コミット(commit)します。コミット(commit)は、ゲームのセーブポイントだと考えると、すっと腑に落ちます。ゲームでは、ボス戦の手前でセーブしておき、負けたらそこからやり直しますよね。Gitも同じで、うまくいったところでセーブし、その先で失敗したら、すぐに前のセーブポイントに戻れます。Claude Codeに「いまの状態をコミット(commit)して」と言えば、記録してくれます。このとき、AIは「何を変えたか」の一言メモ(コミットメッセージ(commit message))も一緒に書いてくれます。これが後から履歴を読むときの見出しになります。コミット(commit)には、ほかにもハッシュと呼ばれる長い文字列など、いろいろな情報が付きますが、それらは中級者向けなので、最初は気にしなくて大丈夫です。大事なのは「セーブが1つ増えた」という事実だけです。「今までに入ったコミット(commit)を見せて」と頼めば、これまでのセーブポイントが一覧で出てきます。こまめにセーブポイントを刻みながら前に進む、これがGitの基本動作です。

実演では、まずREADMEを作って1つ目のセーブポイントを記録し、続いてメモというファイルに「今日は2026年5月です」と書いて、2つ目のセーブポイントを記録していました。「今までに入ったコミット(commit)を見せて」と頼むと、この2つがちゃんと一覧で返ってきます。最初のうちは、こうして2つ、3つとセーブポイントが増えていく感覚をつかむだけで十分です。慣れてくると、「この区切りで残しておくと、後で戻しやすいな」という勘どころが、だんだん身についてきます。

もう1つの主役がブランチ(branch)です。ブランチ(branch)は、履歴を枝分かれさせる機能です。ここがゲームのセーブと決定的に違う点で、Gitでは、ある地点から歴史を複数のルートに分けられます。右に行く歴史と左に行く歴史を、別々に育てられるのです。枝の上での作業は、元のセーブポイントには影響しません。枝で試してうまくいけば、その歴史を正しい歴史として本流に採用し、ダメだった枝はそのまま捨てればよいので、本流はいつも安全なまま、新しい機能を試せます。新しい機能を作る前に枝を切る、これがプロの基本姿勢です。

状況が分からなくなったら、Claude Codeに「いまのブランチ(branch)の状況はどうなっていますか」と聞けます。最初はメイン(main)という本流にいて、まだコミット(commit)が1つもなく、クラウド側にも何も上がっていない、といった現在地を教えてくれます。迷子になっても、いつでも現在地を確認できる、と知っておくと安心です。

第4章: プッシュ(push)とプルリクエスト(pull request) ── クラウドに上げてレビューする

手元で積み重ねたコミット(commit)は、まだ自分のパソコンの中だけにあります。これをGitHub(クラウド)に上げる操作が、プッシュ(push)です。プッシュ(push)は「押し込む」という意味で、手元の作業をGitHubにアップロードします。

ただし、上げただけでは本流には入りません。ここで、本流の歴史であるメインブランチ(main branch)が出てきます。自分は手元で枝分かれして作業をしました。その「こういう機能を作ったよ」という枝を、メイン(main)の歴史に取り込んでほしいと依頼するのが、プルリクエスト(pull request)です。プルリク(pull request)、あるいはPRとも呼びます。プルリクエスト(pull request)はGitHub上で一覧でき、中身をレビューできます。

なぜ、わざわざ提案とレビューをはさむのでしょうか。1人で開発していると遠回りに感じますが、これは複数人で開発するときに「いきなり本流が壊れる」のを防ぐ仕組みです。プルリクエスト(pull request)は、変更を本流に入れる前の確認ゲートだと考えてください。チームなら、ほかのメンバーがこの画面で差分を見て、コメントを付けたり、承認したりできます。1人開発でも、自分の変更を落ち着いて見直す、よい機会になります。

ここで、初心者がよくはまる落とし穴を1つ紹介します。これは実演でも起きた、定番のつまずきです。メインブランチ(main branch)のまま作業を進めてしまうと、メイン(main)からメイン(main)へ変更を提案することになり、プルリクエスト(pull request)が作れないのです。同じブランチ(branch)同士では提案ができません。正解は、作業を始める前に「この機能を作る用のブランチ(branch)」を先に1本切っておくことでした。実演では、後から枝を作り直し、それまでのセーブポイントをその枝へ移して立て直しています。最初に枝を切る、これを習慣にすると、この落とし穴を丸ごと避けられます。

プルリクエスト(pull request)を開くと、どのファイルが、どう変わったかが色付きで表示されます。赤が変更前、緑が変更後です。たとえば、メモというファイルの中身が「5月」から別の月に変わったとき、消える前の行が赤で、新しく入る行が緑で並びます。一目で「どこを、どう変えたか」が分かるので、コードが読めなくても、変更の大きさや方向はつかめます。プルリクエスト(pull request)を出すと、GitHubの画面には「1」という数字のしるしが付き、取り込みを待っている提案が1件あることを知らせてくれます。この数字をたどれば、いつでも提案の中身に戻れます。差分を見て、「うん、これをやりたかった」と納得できたら、次の取り込みの工程に進みます。

第5章: マージ(merge)とプル(pull) ── 本流に取り込み、最新を持ち帰る

プルリクエスト(pull request)の差分を確認して問題なければ、マージ(merge)を押します。マージ(merge)は、その提案を承認して、変更を本流に取り込む操作です。マージ(merge)すると、枝で作った複数のセーブポイントが、GitHub上のメイン(main)の記録に正式に入り込みます。表示が紫色の「Merged」に変わり、メイン(main)の歴史が一段、前に進みます。GitHubでは、こうしたセーブポイントの連なりを、時間が左から右へ伸びていく1本の線として眺められます。枝分かれと合流をくり返しながらその線が伸びていくのが、プロジェクトの歴史です。このとき、READMEのように特別扱いされるファイルは、リポジトリ(repository)のトップページに中身が表示され、さきほど書いた説明が、ちゃんと看板として出てきます。

最後の5つ目が、プル(pull)です。プル(pull)は「引っ張る」という意味で、クラウド上の最新の状態を、自分の手元に持ってくる操作です。これは複数人で開発するときに、特に大事になります。

具体例で考えましょう。自分は自分用のブランチ(branch)で作業し、同僚は同僚用のブランチ(branch)で作業して、それぞれプルリクエスト(pull request)を出してマージ(merge)したとします。すると、自分の手元には、自分が作った変更しか入っていません。なぜなら、自分のパソコンで作ったのはそれだけだからです。同僚の変更は、相手のパソコンとクラウドにはありますが、自分の手元にはまだないのです。そこでプル(pull)をすると、クラウドにある最新のメイン(main)、つまり同僚の変更も含んだ状態を、手元に取り込めます。

もしプル(pull)をし忘れて、手元が古いままだと、自分のパソコンの線と、クラウドの最新の線が、だんだんずれていきます。このずれが大きくなると、次の章で説明するコンフリクト(conflict)(衝突)が起きやすくなります。だから、作業を始める前に最新を持ち帰る、という習慣が効いてくるのです。実演でも、新しいブランチ(branch)を切る前に「まずプル(pull)して状況を合わせてから」と、わざわざ同期してから作業が始められていました。地味ですが、トラブルを未然に防ぐ、いちばん大事な一手です。

だからこそ、次の作業を始めるときは、まずプル(pull)で最新に同期してから、新しいブランチ(branch)を切るのが定石です。上げる(プッシュ(push))と持ち帰る(プル(pull))。この往復が、クラウドと手元をつなぐリズムであり、チーム開発の心臓部です。

第6章: コンフリクト(conflict) ── 「今日は何月?」で衝突を体験する

Gitで最もこわがられるのが、コンフリクト(conflict)(衝突)です。けれども仕組みは単純で、2つの変更が「同じ場所」を別々に書き換えたときに起きるだけです。

分かりやすい例で説明します。ホームページのテーマカラーを、ある人は赤にしたくて赤に変更し、その間に別の人は青にしたくて青に変更したとします。テーマカラーという同じ項目を、赤と青で奪い合う。これがコンフリクト(conflict)です。どちらも正しい作業をしているのに、2人が同じ1か所を別の値にしたために、機械がどちらを残すべきか決められなくなります。

実演では、これを実際に作って見せています。メモというファイルに「今日は2026年5月です」と書いてある状態から、4月という名前のブランチ(branch)で「4月」に書き換え、6月という名前のブランチ(branch)で「6月」に書き換えました。両方のプルリクエスト(pull request)を出し、先に4月をマージ(merge)します。すると、後から来た6月のプルリクエスト(pull request)は、同じ行を奪い合うことになり、マージ(merge)しようとしてもブロックされます。GitHubは「このブランチ(branch)には、解決しなければならないコンフリクト(conflict)があります」と表示して、合流を止めます。今回は1行だけのぶつかりなので単純ですが、実際の開発では、何十行にもわたる大きなコンフリクト(conflict)が起きることもあります。それでも、考え方はまったく同じです。

ここがGitの大事な思想です。4月が正しいのか6月が正しいのか、機械には判断できません。最後は人間が決めます。実演では、Claude Codeに「3番のプルリクエスト(pull request)でコンフリクト(conflict)が起きた。どうしたらいい?」と相談しています。プルリクエスト(pull request)には背番号のような番号が振られていて、3番が6月の提案でした。Claude Codeは、手元で最新のメイン(main)を取り込んでから衝突を直し、もう一度プッシュ(push)する、という手順を示してくれます。

解決の方式には、マージ(merge)とリベース(rebase)の2つがありますが、最初はマージ(merge)で十分です。Claude Codeが「この枝は6月の機能なので、6月を採用しますか」と確認してきても、考え直して「いや、今は4月が正しい」と言えば、その通りに直してくれます。AIの提案を、人間がいつでも上書きできるということです。残す行と消す行が決まり、消える行が赤で示され、衝突が解決され、プッシュ(push)すればマージ(merge)できるようになります。

この「いや、4月が正しい」と言い直せるところが、とても大切です。AIは、どちらが正解かを知りません。正解を知っているのは、何を作りたいかが分かっている人間だけです。だからGitは、最後の最後で必ず人間に判断を委ねます。AIは面倒な作業を代行してくれますが、意思決定はあなたの仕事として残る。この役割分担を覚えておくと、AIに任せるべきところと、自分が決めるべきところの線引きが、自然と分かるようになります。コンフリクト(conflict)は事故ではなく、間違った合流を防ぐためのGitの正常な機能だと捉えると、こわさが消えます。

第7章: 手打ち時代との違いと、Claude Code・Codexの役割

少し前まで、これらの操作は、すべて自分の手でコマンドを打つ必要がありました。git add、git commit、git push といった命令を、1つずつ正確に入力していたのです。打ち間違えればエラーになり、その意味を調べるだけで疲れてしまう。これが、多くの初心者がGitの入り口で挫折してきた理由でした。「昔はこのコマンドを全部、手で打たないといけなかった」と語られるほど、これは大きな変化です。

今は違います。Claude CodeやCodexが、これらのコマンドを代わりに打ってくれます。実際、「ここまで削ぎ落としても、Claude CodeやCodexのAIの支援があれば、Gitを使いこなせる」とも言われています。AIエージェントは、あなたの日本語の指示をコマンドに翻訳し、実行する前に「これを実行していいですか」と確認します。あなたは内容を見て、許可するだけです。実演では音声入力も併用され、ほとんど喋って、確認して、ボタンを押すだけで、一連の操作が進んでいきました。

大切なのは、最初から完璧に理解しようとしないことです。まずはClaude CodeやCodexに任せてみる。任せて動かすうちに、AIが何をしているのかが少しずつ見えてきて、「ああ、Gitってこういうことか」と腑に落ちてきます。順番は、理解してから使うのではなく、使いながら理解する、で大丈夫です。AIに任せられる時代になったからこそ、かえって全体の流れをつかむことに集中できる、とも言えます。

少しだけ裏側をのぞいてみます。あなたが「コミット(commit)して」と言ったとき、AIは内部で git add や git commit といった命令を組み立てて実行しています。「プッシュ(push)して」なら git push です。つまり、昔の人が手で打っていたものと、まったく同じ命令が走っています。違うのは、それを誰が組み立てるか、だけです。この対応関係を頭の片隅に置いておくと、将来もっと詳しく学びたくなったときに、すでに橋がかかっていることに気づくはずです。今のあなたは、その橋の手前で、全体の地図を眺めているところなのです。

第8章: Claude Code・Codexへの頼み方 ── そのまま使える声かけ例

ここまでの操作は、すべて日本語の声かけでAIに頼めます。最後に、そのまま真似できる言い方を、場面ごとにまとめておきます。難しいコマンドは一切覚える必要がありません。

箱を手元に持ってくる(クローン(clone)): 「このリポジトリ(repository)を手元のパソコンに持ってきてください」
今の居場所を確かめる: 「いまのブランチ(branch)の状況はどうなっていますか」
枝を作る(ブランチ(branch)): 「◯◯という機能を作りたいので、ブランチ(branch)を切ってください」
セーブする(コミット(commit)): 「いまの状態をコミット(commit)してください」
セーブの履歴を見る: 「今までに入ったコミット(commit)を見せてください」
クラウドに上げて提案する(プッシュ(push)とプルリクエスト(pull request)): 「いまの変更をプッシュ(push)して、メイン(main)にプルリクエスト(pull request)を出してください」
最新を持ち帰る(プル(pull)): 「まずメイン(main)をプル(pull)して、最新の状態に同期してください」
衝突を直す(コンフリクト(conflict)): 「◯番のプルリクエスト(pull request)でコンフリクト(conflict)が起きました。解決したいので、どうすればいいか教えてください」
前の状態に戻す: 「さっきのコミット(commit)の状態に戻してください」

コツは、1回に1つずつ、短く頼むことです。AIが「このコマンドを実行していいですか」と聞いてきたら、内容をざっと見て、おかしくなければ許可します。実演でも、ほとんどこの調子で、喋って、確認して、ボタンを押すだけで、ひととおりの操作を終えていました。困ったら「どうしたらいい?」と素直に相談するのも有効です。基本は、Claude CodeやCodexに頼みまくる、それで十分です。

第9章: 安全に使うためのチェックリスト

仕上げに、初心者がつまずかないための要点を、チェックリストにまとめます。どれも、ここまでの内容から自然に導かれる勘どころです。

最初のリポジトリ(repository)はプライベートで作る。公開は、慣れて、公開してよい中身だと確信してからにします。
パスワードやAPIキーを、コードに直接書かない。もし誤って公開してしまったら、リポジトリ(repository)を非公開に戻すだけでなく、その鍵自体を無効化して作り直します。
こまめにコミット(commit)する。セーブポイントが多いほど、戻れる地点が増え、失敗が怖くなくなります。
作業を始める前に、まずプル(pull)で最新に同期する。古い状態から始めると、衝突の原因になります。
本流(メイン(main))で直接作業せず、先にブランチ(branch)を切る。これだけで、プルリクエスト(pull request)の落とし穴を避けられます。
AIが提案した操作は、内容を一度見てから承認する。意味が分かる5つの操作だからこそ、おかしな動きに気づけます。

この6つは、どれも難しい操作ではありません。大切なのは、考えなくても手が動くくらい、習慣にしてしまうことです。慣れてくれば、Claude CodeやCodexに頼むときも、自然と「先にブランチ(branch)を切って」「作業の前にまずプル(pull)して」と口から出るようになります。ここまで来れば、Git/GitHubのこわい場面のほとんどは、起きる前に避けられています。あとは、Claude CodeやCodexと一緒に、たくさん使って、自分の道具にしていくだけです。失敗しても、セーブポイントがあるかぎり、いつでもやり直せます。その安心感こそが、Gitが何十年も使われ続けてきた、いちばんの理由なのです。

FAQ

Q1. GitとGitHub、結局どちらを使えばいいのですか? 両方です。Gitは手元のパソコンでセーブポイントを作る仕組み、GitHubはそれをクラウドで共有・公開する場所で、役割が違います。ふだんはセットで使うものだと考えてください。Claude CodeやCodexは、その両方をまとめて操作してくれます。

Q2. 本当にコマンドを覚えなくていいのですか? 日常の開発では、ほぼ覚えなくて大丈夫です。AIが日本語の指示をコマンドに翻訳して実行してくれます。ただし、本稿の5つの操作の意味だけは理解しておくと、AIの提案を確認でき、事故を防げます。暗記ではなく、流れの理解が目標です。

Q3. Claude CodeとCodexで、やり方は変わりますか? 基本は変わりません。どちらのAIでも、Gitは同じように使いこなせます。コミット(commit)やプッシュ(push)といった概念はそのまま通用し、話しかけ方の細部が違うだけです。本稿の流れは、どちらでも当てはまります。

Q4. コンフリクト(conflict)が起きたら、もう手に負えないのでは? そんなことはありません。コンフリクト(conflict)は、同じ場所を2人が別々に直したときに起きる、ごく普通の状態です。焦って自分でファイルをいじる必要はありません。どちらを採用するかを人間が決め、その判断をClaude CodeやCodexに伝えれば、AIが直してくれます。「コンフリクト(conflict)を解決したい」と伝えて、あとはAIの案内に沿って進めれば大丈夫です。最初はマージ(merge)という方式で解決すれば十分で、リベース(rebase)はもっと慣れてからで構いません。

Q5. 1人で開発するときも、ブランチ(branch)やプルリク(pull request)は必要ですか? 必須ではありませんが、おすすめします。1人でも、機能ごとにブランチ(branch)を切れば、失敗しても本流が無事なので安心して試せます。プルリクエスト(pull request)は、自分の変更を後から見返す記録にもなります。チーム開発に移ったとき、そのまま通用する習慣にもなります。

Q6. まず何から始めればいいですか? プライベートのリポジトリ(repository)を1つ作り、READMEファイルを足して、Claude CodeやCodexに「コミット(commit)して」「ブランチ(branch)を切って」「プッシュ(push)して」「プルリク(pull request)を出して」と順に頼んでみてください。一度この往復を体験すると、言葉と動きが結びつきます。第8章の声かけ例を、そのまま使ってかまいません。

まとめ

AIコーディングの時代になり、Gitはコマンドを暗記する道具から、言葉でお願いする道具へと変わりました。Claude CodeやCodexが、裏側の操作をすべて引き受けてくれるからです。

それでも、ブランチ(branch)・コミット(commit)・プッシュ(push)・プルリクエスト(pull request)・プル(pull)という5つの操作と、枝を切ってから本流に合流させ、最新を手元に持ち帰るという一連の流れだけは、知っておく価値があります。意味が分かっていれば、安心してAIに任せられ、いざというときに止められるからです。GitとGitHubの違いも、手元のセーブとクラウドの共有、と覚えておけば迷いません。

最初の一歩は、とても小さくて構いません。プライベートの箱を1つ作り、Claude CodeやCodexに話しかけながら、この往復を一度だけ体験してみてください。理屈より先に、手が覚えます。そして気づけば、戻す・分ける・公開するという、できることの幅が、確実に広がっているはずです。Git/GitHubは、難関ではなく、あなたの作ったものを世界へ届けるための、いちばん頼れる土台になります。そして、Git/GitHubの基礎を知っておくことは、医療に携わる方も含め、AIを使いこなす時代の、一人ひとりの確かな教養になります。

なお、この記事を短くまとめた note 版もあります。あわせてどうぞ。

note 版(短縮版)を読む