GitHub Desktopでパソコンとつなぐ。クローン、プッシュ、プルをコマンドなしで1周する【非エンジニアのGitHub入門⑥】

前回の最後に、「次回は自分のパソコンとGitHubをつなぐ」と予告しました。AIのCodexに手元で作業してもらうための、土台づくりです。今回はその約束どおり、GitHubのリポジトリをパソコンに写し、手元で直した内容をGitHubに送るところまでを体験します。

この連載の終盤で扱う道具に、Codex（OpenAIが提供する、開発作業を任せられるAI）¹と、Claude Code（Anthropicが提供する、同じ種類のAI）²があります。どちらも、パソコンの中にあるファイルを読み、書き換える形で作業できます。これまでブラウザの中で扱ってきたリポジトリには、パソコンで動く道具の手が届きません。だから、パソコンの側にも置いておく必要があります。

第1回の佐藤さんの共有フォルダでは、「完成版」「修正版」「最終版」と写しが増えていきました。今回の方法は違います。パソコンに写しても、「最終版」のような写しは増えません。ファイル名は1つのまま、履歴も一緒に付いてきます。

今回は、第3回で作った練習用のリポジトリ「work-notes」を使います。まだ作っていない場合は、第3回の手順で作ってください（約10分）。途中で出てくるプルリクエストは、第4回で説明しています。

先に覚えておく3つの言葉

今回の手順には、新しい言葉が3つ出てきます。

言葉	意味	仕事にたとえると
クローン	リポジトリを履歴ごとパソコンに写す	原本の綴りを手元に1冊もらう
プッシュ	パソコンで記録した変更をGitHubに送る	手元で直した分を原本の側に届ける
プル	GitHubの新しい変更をパソコンに取り込む	原本の更新分を手元の綴りに反映する

パソコンで記録（コミット）しただけでは、まだGitHubには届いていません。届けるのがプッシュです。

第3回では、ブラウザで「Commit changes」を押した瞬間に、記録がGitHubに残りました。パソコンでは、手元で記録してからGitHubへ送る、の2段階になります。

図にすると、次のような関係です。

最初の1回だけ丸ごと写すのがクローンで、あとはプッシュとプルで両方をそろえていきます³。

GitHub Desktopを入れてサインインする

今回使うのは、GitHubが無料で提供している公式のアプリ、GitHub Desktop（ギットハブ・デスクトップ）です。コマンドを打たずに、ボタン操作だけでクローンやプッシュができます。

使えるのはWindowsとMacです。Windowsは64ビット版が必要です。Linuxの公式版はありません⁴⁵。

1. GitHub Desktopの公式サイトから、自分のパソコン用のファイルをダウンロードします。
2. Windowsは、ダウンロードしたファイルを実行するとインストールが始まります。Macは、ダウンロードしたファイルを開いて出てきたアプリを、「アプリケーション」フォルダに移してから起動します。
3. 最初の画面で「Sign in to GitHub.com（GitHub.comにサインイン）」を押します。

画像① GitHub Desktop の最初の画面（Welcome to GitHub Desktop）。「Sign in to GitHub.com」から始める

1. 「Continue with browser（ブラウザで続ける）」を押すと、ブラウザが開きます。GitHubにサインインし、GitHub Desktopからのアクセスを認める画面で承認します。「GitHub Desktop を開きますか？」と聞かれたら「開く」を押します⁶。
2. 2段階認証を設定している場合は、第3回と同じ方法で確認コードを入力します。
3. 案内に従ってGitHub Desktopに戻ります。名前とメールアドレスの設定画面が出たら、GitHubのアカウントのものを使う選択肢のまま進めて構いません。

この名前とメールアドレスは、コミットの記録に残ります。公開リポジトリで使う予定がある場合は、GitHubの設定でメールアドレスを公開しない設定（Keep my email addresses private）にし、GitHub Desktopでも no-reply（ノーリプライ）のアドレスを選んでおくと安心です。no-reply は、本当のアドレスの代わりにコミットに残る、GitHubが用意した記録専用のアドレスです⁷。

work-notesをパソコンに写す

クローンの前に、1つ確かめておきたいことがあります。

非公開（Private）のリポジトリでも、クローンするとパソコンには中身がそのまま写ります。会社のパソコンで使う場合は、GitHubや外部のアプリを使ってよいか、業務の情報をどこに置いてよいかなど、社内のルールを先に確かめてください。情報の扱いについては、第1回の「仕事の成果物を置いてよいのか」で詳しく書いています。

1. 「Let's get started!（始めましょう）」の画面で、「Clone a repository from the Internet…（インターネットからリポジトリをクローン）」を押します。画面が違う場合は、上のメニューの「File」→「Clone repository」でも同じ窓が開きます。
2. 「GitHub.com」のタブに、自分のリポジトリの一覧が出ます。上の検索欄に「work-notes」と入れて絞り込み、選びます。
3. 下の「Local path（パソコンでの保存先）」を確かめます。同期フォルダの中でなければ、そのままで構いません（次の段落で説明します）。
4. 「Clone（クローン）」を押します⁸。

保存先は、OneDriveやiCloud Driveのように、ファイルを自動で同期するフォルダの中を避けてください。筆者のWindowsでは、初期の保存先が「OneDrive\ドキュメント\GitHub」になっていました。欄に「OneDrive」や「iCloud」の文字が見えたら、「Choose…（選ぶ）」で同期していない場所に変えます。

クローンが終わったら、写ったことを確かめましょう。GitHub Desktopの画面にある「Show in Explorer（エクスプローラーで表示）」を押します。Macでは「Show in Finder（Finderで表示）」です。

work-notesというフォルダの中に、README.mdがあるはずです。Windows の初期の設定では、「.md」の部分が表示されず「README」とだけ見えることがあります。同じファイルです。

このフォルダには、普段は表示されない「.git」というフォルダも入っています。ここに、これまでの履歴がすべて詰まっています。クローンが「履歴ごと写す」と言えるのは、このフォルダのおかげです。消すと、パソコンの側の履歴が失われます（GitHubに送った分は、GitHubに残ります）。触らないでください。

パソコンで直して、記録して、送る

手元で1周してみます。第5回のように、Issueから始めてもかまいません。

ブランチを作る

第4回と同じく、本体（main）を直接書き換えず、ブランチ（作業用の写し）で修正案を作ります。

1. 上のメニューの「Branch」→「New branch（新しいブランチ）」を押します。
2. 名前に「add-desktop-note」と入力し、「Create branch（ブランチを作る）」を押します⁹。

画面上部の「Current branch（いまのブランチ）」が、add-desktop-noteに変わります。

README.mdを直す

先ほどのフォルダから、README.mdをテキストエディタで開きます。Windowsは右クリックして「プログラムから開く」→「メモ帳」、Macは右クリックして「このアプリケーションで開く」→「テキストエディット」を選びます。

いちばん下の行のあとに空行を1つ入れ、次の1文を書き足して保存します。

このメモは、パソコンからも更新できます。

保存してGitHub Desktopに戻ると、左側の「Changes（変更）」に README.md が出ています。右側には、書き足した行が緑、消した行が赤で表示されます。第3回で見たGitHubの比較画面と同じ見え方です。

記録する（コミット）

左下に、コミットメッセージを書く欄があります。「Summary（概要）」の欄に「READMEにパソコンからの更新を追記」と入力し、その下の「Commit to add-desktop-note（add-desktop-noteに記録）」を押します。ボタンの後ろには、いまのブランチの名前が入ります¹⁰。

これで、パソコンの中に記録が1つ増えました。ただし、まだGitHubには届いていません。

送る（プッシュ）

画面上部の右側に、「Publish branch（ブランチを公開）」というボタンが出ています。押してください。

新しいブランチを初めて送るときは、このボタンになります⁹。2回目からは「Push origin（originへプッシュ）」に変わります¹¹。origin は、送り先のGitHubのリポジトリを指す呼び名です。公開（Publish）といっても、見られる人の範囲は変わりません。リポジトリの設定（第3回で選んだ Private か Public）のまま、ブランチがGitHubの上のwork-notesに届く、という意味です。

プルリクエストを作る

送ったあと、画面の中央に「Create Pull Request（プルリクエストを作る）」というボタンが出ます。押すとブラウザが開き、第4回で見た「Open a pull request」の画面になります¹²。

ボタンが「Preview Pull Request（プルリクエストを下見する）」になっている場合は、押すと変更の下見の窓が開きます。その窓の「Create Pull Request」を押せば、同じ画面に進みます。

ここから先は、第4回と同じです。タイトルと説明を確かめて「Create pull request」を押し、差分を見て、「Merge pull request」→「Confirm merge」でマージします。第5回のようにIssueから始めた場合は、説明欄に「Closes #（Issueの番号）」も書いておきましょう。

大事なのは、受け取る側の画面が何も変わらないことです。ブラウザで作っても、パソコンで作っても、GitHubに届けば同じプルリクエストになり、確かめ方は第4回・第5回と同じです。

GitHubの変更を取り込む

次は反対向きに、GitHubの側で起きた変更をパソコンに取り込みます。ここでは、ブラウザの自分が同僚の田中さんの役を演じます。

1. ブラウザでwork-notesを開き、README.mdを鉛筆マーク（Edit file）で編集します。先ほどマージした内容が入っていることを確かめてから、いちばん下に空行を1つ入れ、「確認担当：田中」と書き足します。
2. 「Commit changes...」を押し、第3回と同じ「Commit directly to the main branch」を選んで記録します。練習を短くするための近道で、本来ならプルリクエストで出すところです。

これで、GitHubのmainは、パソコンの中より新しい状態になりました。パソコンに戻ります。

1. GitHub Desktopの「Current branch」を押し、「main」を選びます。
2. 画面上部の「Fetch origin（originを確認）」を押します。GitHubに新しい変更がないかを確かめるボタンです。
3. 新しい変更があると、ボタンが「Pull origin（originからプル）」に変わります。押してください¹³。

すでにボタンが「Pull origin」になっている場合は、GitHub Desktop が自動で確かめを済ませています。そのまま押してください。

メモ帳（テキストエディット）を一度閉じてから、README.md を開き直してみてください（開いたままの画面は、取り込む前の内容です）。パソコンで書いた1文と「確認担当：田中」の両方が入っているはずです。マージした修正と田中さんの修正が、プル1回でまとめて届きました。

つまずきやすいところ

コミットしたのにブラウザで見ても変わっていない場合は、まだプッシュしていない可能性が高いです。画面上部に「Push origin」や「Publish branch」が出ていないか見てください。記録と送信は、別の操作です。

同期フォルダにリポジトリを置くと、同期の仕組みとGitが同じファイルを同時に扱い、ファイルが壊れたり複製ができたりすることがあります。慌てずに、同期していない場所へもう一度クローンし直してください。GitHubに送ってある記録は、GitHubの側に残っています。

プルする前に、編集中のファイルは保存して閉じておきましょう。開いたまま古い内容を保存すると、取り込んだ変更を上書きしてしまいます。

Macのテキストエディットでは、書類が「リッチテキスト」の形式になっていることがあります。その場合は、メニューの「フォーマット」→「標準テキストにする」を選んでから保存します。

パソコンとGitHubで、同じファイルの同じ行をそれぞれ書き換えると、コンフリクト（衝突）が起きることがあります。どちらを残すかをGitが自動では決められない状態です¹⁴。今回は名前だけ覚えておけば十分で、作業前にプルしておけば、ほとんどは防げます。

佐藤さんのフォルダと比べると

第1回の佐藤さんの共有フォルダでは、誰かが手元で直すたびに写しが1つずつ増えました。どれが新しいのか、何が変わったのかは、開いて見比べるまで分かりません。

今日のwork-notesは、パソコンに写しても、「README_最終版.md」のような写しは増えていません。前の版を名前を変えて残す必要はなく、前の状態は見えない.gitフォルダの中に履歴として入っています。

田中さんの修正も、ファイルが別に届いたわけではありませんでした。プル1回で、同じREADME.mdの中に入ってきました。誰が、いつ、何を変えたのかは、GitHub Desktopの左側にある「History（履歴）」タブで確かめられます¹⁵。

History タブには、田中さんの記録、マージの記録、パソコンで書いた記録が並び、選べば変わった行が緑と赤で出てきます。佐藤さんがファイルを開いて見比べていた作業が、一覧を眺めるだけで済みます。

この流れは、直す人が誰であっても変わりません。

Codex や Claude Code がパソコンで直したファイルも、今日と同じように差分を見て、記録して、送れます。プルリクエストで受け取れば、確かめ方は第4・5回と同じです。

直す手が人からAIに変わっても、変わったところを見て、取り込むかどうかを決めるのは人です。そのための道具は、今日1周した中にそろっています。

コラム：画面の操作とコマンドの対応

GitHub Desktopのボタンは、裏側でGitのコマンドを動かしています。対応は次のとおりです。

GitHub Desktopの操作	対応するコマンド
Clone a repository	git clone
Commit to （ブランチ名）	git commit
Push origin／Publish branch	git push
Fetch origin	git fetch
Pull origin	git pull

覚える必要はありません。AIの道具の作業記録に、これらのコマンドが出てくることがあります。そのときに、何をしたのかが読めれば十分です。

まとめと次回予告

今回分かったことは3つです。

• リポジトリは、履歴ごとパソコンに写せる
• 記録（コミット）と送信（プッシュ）は、別の操作
• 作業を始める前に、まずプルする

次回は、AIに作業を任せるときの基本を扱います。Codex と Claude Code のどちらにも共通する考え方として、任せる範囲の決め方、パスワードなどの秘密の情報を渡さないこと、そして結果をプルリクエストで受け取ることを見ていきます。

実はこの連載も、2つのAIに役割を分けて作っています。その舞台裏は第8回でお見せします。

1. OpenAI（Codex） ↩

2. Claude Code ドキュメント（概要） ↩

3. GitHub Docs（リポジトリをクローンする） ↩

4. GitHub Docs（GitHub Desktopでサポートされているオペレーティングシステム） ↩

5. GitHub Docs（GitHub Desktopのインストール） ↩

6. GitHub Docs（GitHub DesktopでGitHubに認証する） ↩

7. GitHub Docs（コミットメールアドレスを設定する） ↩

8. GitHub Docs（GitHub Desktopからリポジトリをクローンおよびフォークする） ↩

9. GitHub Docs（GitHub Desktopでのブランチの管理） ↩ ↩²

10. GitHub Docs（GitHub Desktopでのコミットと変更の確認） ↩

11. GitHub Docs（GitHub DesktopからGitHubに変更をプッシュする） ↩

12. GitHub Docs（GitHub Desktopからのイシューまたはプルリクエストの作成） ↩

13. GitHub Docs（GitHub Desktopでのブランチの同期） ↩

14. GitHub Docs（マージの競合） ↩

15. GitHub Docs（GitHub Desktopでブランチ履歴を表示する） ↩