図で理解する Git/GitHub 基本フロー （GitHub Desktop 版）
最初の共同開発に入る人向けに、GitHub Desktopを前提として「作業の最短ルート」を図と表でまとめました。
はじめてでも迷わないよう、Publish/Push/Pull/Fetch の早見表、PR（Pull Request）の最小ルール、やり直し早見表、さらにUnity プロジェクトでの注意点まで、必要最小限で実務に直結する形に整理しています。
1. バージョン管理とは
- プログラムやドキュメントの変更履歴を記録し、管理する仕組み。
- GitHub と Git を使うと、複数人でも効率よく開発を進められる。
「バージョン管理」とは、ファイルの過去の状態を記録し、誰が・いつ・どのように変更したかを追跡できる仕組みです。
→ もし間違えた場合でも、過去の状態に戻れるため安心して作業できます。
https://soft-rime.com/post-25290/
https://docs.github.com/ja/desktop?utm_source=chatgpt.com2. Git の初期化
- ローカルリポジトリ：自分のPC内の作業フォルダ。
- 「プロジェクト（作業）フォルダ（例：ソリューションフォルダ）を GitHub Desktop にドラッグ＆ドロップして初期化。」
「ローカルリポジトリ」とは、自分のPC上で変更履歴を記録するための箱のようなものです。
→ まだ他人と共有する段階ではなく、自分専用の作業履歴の保管庫と考えるとわかりやすいです。
GitHub Desktopの“3つの入り口”を1分で整理
- Add local repository：すでに
.gitがあるフォルダを Desktopに追加（管理に載せる）- Create a New Repository：選んだフォルダに 新しくGitを作成（初期化）
- Clone：リモートの複製をローカルに作成（
originや既定ブランチの追跡設定が自動）
3. Publish（パブリッシュ）
- ローカルからリモート（GitHub）へ最初にコピーする操作。
- GitHub Desktop で「Publish」を実行。
Publish は「最初のアップロード」のことです。
→ ローカルの履歴を GitHub 上にコピーして、チームメンバーがアクセスできる状態にします。
GitHub Desktop
主にローカルリポジトリを更新するツールです
GitHub
リモートリポジトリを管理するWebページになります
GitHub Desktopの画面から開くこともできます
4. Clone（クローン）
- リモートからローカルにコピーを作成。
- チームメンバーが同じリポジトリを利用する際に必要。
Clone は「コピーを作る操作」です。
→ チームメンバーが同じプロジェクトに参加する際は、リモートにある内容を自分のPCに丸ごと持ってきます。
GitHub の画面から「Open with GitHub Desktop」を選ぶと、自動的に GitHub Desktop が起動し、クローンを作成できます。
クローンの手順
- GitHub のリポジトリ画面で「Code」ボタンをクリック。
- 「Open with GitHub Desktop」を選択。
- GitHub Desktop が起動し、ローカルにコピーが作成されます。
ポイント
- Clone を使うと、チームのリポジトリを自分のPCにそっくり持ってこれます。
- 初心者は「GitHubのページ → GitHub Desktopで開く」と覚えればOKです。
- Clone 後は
originと既定ブランチ（例：main）の追跡設定が自動で入ります。
5. 運用パターン①：mainのみ
- main ブランチ一本で開発を進める。
- 個人や小規模開発向け。
main（メインブランチ）は「正しい状態を保つための基準の線」です。
→ 個人や小規模なら一本の線（main）だけで十分ですが、複数人で同時に作業すると衝突（コンフリクト）が起きやすいです。
コミット（Commit）
- ローカルリポジトリに「変更を記録する操作」。
- 例えるなら「ノートに書いた内容を保存して履歴を残す」ようなイメージ。
プッシュ（Push）
- ローカルのコミットをリモートリポジトリ（GitHub）に送信する操作。
- チーム全員が最新の変更を見られるようにする。
フェッチ（Fetch）
- リモートにある変更情報をローカルに取り込んで確認する操作。
- まだ自分の作業フォルダには反映されない（あくまで「更新があるかどうかのチェック」）。
プル（Pull）
- リモートの変更をローカルに取り込む操作。
- 「フェッチ＋マージ」を自動で行い、自分の作業環境を最新に更新する。
まとめ（早見表）
| 操作 | いつ使うか | 要点 | 役割 |
|---|---|---|---|
| Publish（パブリッシュ） | 最初の一度だけ（ローカル→GitHubを新規作成） | GitHub上にリポジトリ作成＋初回Pushをまとめて実行 | ローカルの変更をGitHubに送る |
| Push（プッシュ） | 2回目以降のアップロード | ローカルの新規コミットをリモートへ反映 | ローカルの変更をGitHubに送る |
| Fetch（フェッチ） | まず様子見したい | 変更情報を取得だけ。作業ツリーは書き換えない | GitHubの更新情報を確認する（まだ反映しない） |
| Pull（プル） | 取り込みたいとき | Fetch +（設定により）Merge または Rebase | GitHubの更新を自分の作業フォルダに反映する |
6. 運用パターン②：ブランチ運用
- main と branchA を分けて作業。
- 完了後に main に統合（マージ）。
ブランチは「作業用の分岐」です。
→ 本線（main）を汚さずに新機能を試せるため、チーム開発では必須の考え方です。
ブランチの作成
- GitHub Desktop の画面で「Current branch」から New branch を選ぶ。
- 作業名（例: feature-login）を入力して作成。
- そのまま新しいブランチで作業を始められます。
- ブランチ名は「作業内容がわかる名前」にすると便利。例: bugfix-ui, feature-login
- main に直接コミットしないのがチーム開発の基本ルール。
- 完了したら PR（プルリクエスト）→ マージ の流れで main に統合。
ブランチは main から枝分かれした「作業専用の線」です。GitHub Desktop では「New branch」を選んで名前を付けるだけで作成できます。作業はこの新しいブランチ上で進め、完成後に PR を通じて main に統合します。
7. プルリクエスト（Pull Request, PR）
本文:
- 作業ブランチ（例: branchA）で作業が終わったら、main に取り込む前に「PR（プルリクエスト）」を作成する。
- PR は「main に反映したい変更内容の提案」であり、他のメンバーに確認してもらえる。
プルリクエストは「main に変更を取り込みたい」という 提案 です。
→ チームメンバーに確認してもらう場でもあり、議論や改善のきっかけになります。
8. マージ（Merge）
- PR をレビューした結果、問題がなければ main に変更を反映する。
- チーム開発では必須の手順。
- レビュー担当者が「承認」してマージすることで、main が更新される。
マージは「枝分かれした作業を main に統合する操作」です。
→ チェックを通過した変更だけが main に入るので、品質を保つことができます。
９. まとめ
- Publish = 最初の公開
- Clone = リモートから取得
- main運用 = 個人向け
- ブランチ運用 = 複数人開発向け
- PR & マージ = 複数人開発で安全にmainを更新するための流れ
個人で学習するときは「Publish → Clone」だけでも十分ですが、チーム開発を想定するなら「Branch → PR → Merge」まで理解すると実務に直結します。
実際の運用練習：3〜4名でGitHubチーム開発を体験する
Designerドラッグ＆ドロップを用いた実践的な共同開発フロー
- この演習では、実際に3〜4名のチームを組み、GitHubを用いたバージョン管理の流れを体験します。
- WinFormsの小規模アプリを題材にすることで、ソースコードだけでなくUI設計ファイル（Designer）の変更も管理下に置く練習ができます。
- リーダー役はリポジトリをPublishし、メンバーはCloneで取得。→ 各メンバーはBranchを作成して作業し、PRでmainに統合する実務的な流れを経験します。
- 「クラス分けしないバトル」アプリはシンプルながらも、ボタン操作やイベント処理を含むため、実際の開発と同じような衝突（コンフリクト）や修正依頼を体験できます。
チーム開発で起こり得ること
- チーム開発では、同じファイルを複数人が同時に編集すると「コンフリクト（衝突）」が起きることがあります。
- Gitは「どこがぶつかっているか」を自動的に検出し、開発者に修正を促してくれる仕組みを持っています。
- コンフリクトは失敗ではなく、協力して開発している証拠。正しく解決すれば問題なく次に進めます。
コミット履歴で安心！やり直しとリカバリーの基本
- Gitでは、どの段階でも履歴を残しているため「やり直し」が可能です。
- 開発中にコードを間違えても、GitHub Desktop の操作で簡単に元に戻せます。
- 主なやり直しの方法は次のとおり：
- 直前の変更を取り消す（Changesタブでリセット）
- コミットを打ち消す（Undo Commit / Revert）
- 過去の履歴からやり直す（CheckoutやReset）
- 重要なのは、コミットしておくことで「戻れる地点」を確保できるという点。
- 「こまめにコミット＝安全にやり直しできる保険」で安心感がえらます。
やり直し早見表（安全な順）
| 操作 | 作用範囲 | 典型用途 | Desktopの目安 |
|---|---|---|---|
| Discard changes | 未コミットの変更 | 直前の編集を捨てたい | 変更右クリック |
| Undo last commit | 直前のローカルコミット | 直前のコミットをやり直し（未Push） | Historyから |
| Amend（編集） | 直前のローカルコミット編集 | メッセージ修正／小さな漏れの追記（未Push） | Commit欄（環境による） |
| Revert | 公開済みコミットを打ち消す | mainに入った誤りを安全に元に戻す | Historyから |
| Reset（高度・CLI） | 履歴を書き換え | ローカルだけで履歴を巻き戻したい（上級者向け） | CLI |
Push済みを戻すときは Revert推奨。reset --hard は公開履歴を壊す恐れがあります。