図で理解する Git/GitHub 基本フロー ー バージョン管理入門

1. バージョン管理とは

  • プログラムやドキュメントの変更履歴を記録し、管理する仕組み。
  • GitHub と Git を使うと、複数人でも効率よく開発を進められる。

「バージョン管理」とは、ファイルの過去の状態を記録し、誰が・いつ・どのように変更したかを追跡できる仕組みです。
　→ もし間違えた場合でも、過去の状態に戻れるため安心して作業できます。

2. Git の初期化

  • ローカルリポジトリ：自分のPC内の作業フォルダ。
  • ソリューションフォルダを GitHub Desktop にドラッグ＆ドロップして初期化。

「ローカルリポジトリ」とは、自分のPC上で変更履歴を記録するための箱のようなものです。
　→ まだ他人と共有する段階ではなく、自分専用の作業履歴の保管庫と考えるとわかりやすいです。

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 が起動し、クローンを作成できます。

クローンの手順

  1. GitHub のリポジトリ画面で「Code」ボタンをクリック。
  2. 「Open with GitHub Desktop」を選択。
  3. GitHub Desktop が起動し、ローカルにコピーが作成されます。

ポイント

  • Clone を使うと、チームのリポジトリを自分のPCにそっくり持ってこれます。
  • 初心者は「GitHubのページ → GitHub Desktopで開く」と覚えればOKです。

5. 運用パターン①：mainのみ

  • main ブランチ一本で開発を進める。
  • 個人や小規模開発向け。

main（メインブランチ）は「正しい状態を保つための基準の線」です。　
　→ 個人や小規模なら一本の線（main）だけで十分ですが、複数人で同時に作業すると衝突（コンフリクト）が起きやすいです。

コミット（Commit）

  • ローカルリポジトリに「変更を記録する操作」。
  • 例えるなら「ノートに書いた内容を保存して履歴を残す」ようなイメージ。

プッシュ（Push）

  • ローカルのコミットをリモートリポジトリ（GitHub）に送信する操作。
  • チーム全員が最新の変更を見られるようにする。

フェッチ（Fetch）

  • リモートにある変更情報をローカルに取り込んで確認する操作。
  • まだ自分の作業フォルダには反映されない（あくまで「更新があるかどうかのチェック」）。

プル（Pull）

  • リモートの変更をローカルに取り込む操作。
  • 「フェッチ＋マージ」を自動で行い、自分の作業環境を最新に更新する。

まとめ

操作役割
コミット自分のPCに変更履歴を記録する
プッシュローカルの変更をGitHubに送る
フェッチGitHubの更新情報を確認する（まだ反映しない）
プルGitHubの更新を自分の作業フォルダに反映する

6. 運用パターン②：ブランチ運用

  • main と branchA を分けて作業。
  • 完了後に main に統合（マージ）。

ブランチは「作業用の分岐」です。
　→ 本線（main）を汚さずに新機能を試せるため、チーム開発では必須の考え方です。

ブランチの作成

  1. GitHub Desktop の画面で「Current branch」から New branch を選ぶ。
  2. 作業名（例: feature-login）を入力して作成。
  3. そのまま新しいブランチで作業を始められます。
  • ブランチ名は「作業内容がわかる名前」にすると便利。例: 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）
  • 重要なのは、コミットしておくことで「戻れる地点」を確保できるという点。
  • 「こまめにコミット＝安全にやり直しできる保険」で安心感がえらます。
訪問数 50 回, 今日の訪問数 51回

バージョン管理,便利機能

Posted by hidepon