GitHub Desktopで学ぶGit—入門からチーム運用まで【完全版】
目次
① Git入門—最短でつかむ「しくみ」と言葉、最初の一歩
対象:初めて Git を触る人
ゴール:3つの領域(作業ツリー/ステージング/履歴)と、コミット・ブランチ・リモートの関係が分かる
1. Git は“コードの保険+協力の仕組み”
- いつでも過去に戻れる(保険)
- 誰が・いつ・何を変えたか見える(透明性)
- チーム開発が安全に進む(協調)
まずは GUI(GitHub Desktop)で成功体験→裏側の動きをCLIで補強の順で学ぶと挫折が少ないです。
2. 最小の用語セット
- リポジトリ:履歴の入れ物(ローカル/リモート)
- コミット:スナップショット(説明文=メッセージ付き)
- ブランチ:作業の枝分かれ(main は常に安定)
- ステージング(インデックス):コミット前の“載せる/載せない”選別エリア
作業フロー概要

作業ツリー ──(add)──> ステージング ──(commit)──> 履歴(ローカル)
│
└──(push)──> リモート(GitHub)
3. はじめの“成功体験”チェックリスト(GitHub Desktop)
- New/Clone でローカルに用意
- ファイルを1つ編集 → Summaryを書いて Commit
- Publish/Push で GitHub へ
- ブラウザの履歴でコミットを確認
4. つまずきやすい所と対処
- Behind/Ahead:ローカルとリモートの進み具合。まず Fetch で最新情報を取り込み、差分を見てから Pull/Push を判断。
- いらない変更の取り消し(Discard):ファイル単位/全体で安全に破棄。
演習
- 新規リポジトリを作成→hello.txt を追加→3回コミット(A/B/C)→GitHubへPush。
- 履歴画面で「いつ/なに/なぜ」がメッセージに書けているか自己点検。
参考リンク(Soft-Rime)
- Gitの仕組みをやさしく解説!
- GitHub Desktopの使い方
- GitのBehind,Aheadについて
- GitHub Desktop の「フェッチ」とは?
- GitHub Desktopで変更を破棄する方法
② 図で理解する Git ×GitHubDesktopClone→Branch→Commit→PR→Merge
対象:操作フローを GUI 中心で身につけたい人
ゴール:最小フローを手でなぞり、CLI対応も“見える化”して理解
1. 全体フロー(最小)
Clone → Branch → Commit → Push → Pull Request → Review → Merge
GitHub Desktop の画面遷移に沿ったステップ学習が安全です。
2. 手順(GitHub Desktop)
- Clone:GitHub のリポジトリをローカルへ
- Branch:feature/●● を作って作業を分離(命名はチームで統一)
- Commit:小さく頻繁に、要約→本文で「なぜ」を残す
- Push:リモートへ反映
- PR作成:目的/変更点/確認手順/影響範囲を明記
- レビュー→Merge:main 直コミットは避け、PR経由で統合
3. Desktop↔CLI 対応ミニ表
目的 | GitHub Desktop | Git(CLI) |
---|---|---|
ブランチ作成 | Branch → New Branch | git switch -c feature/foo |
変更の記録 | Summary入力→Commit | git add -A && git commit -m “…" |
反映 | Push origin | git push -u origin HEAD |
PR作成 | Create Pull Request | (GitHub 上でPRを作成) |
4. 同期のコツ(Behind/Ahead・Fetch/Pull)
- Fetch=最新情報の取得(自分の作業は変わらない)
- Pull=Fetch+取り込み(既定はマージ/必要なら Rebase)画面の状態表示(Up to date/n commits behind/ahead)で判断。
5. 事故を減らす小ワザ
- 不要変更は Discard(個別/全体)で早めに消す。
- 追わないファイルは右クリック→Ignoreで .gitignore に追加(既に履歴にある場合は git rm –cached を併用)。
演習
- リポジトリをクローン→feature/readme-fix で README に追記→コミット→Push→PR→Merge。
- Merge 後、ローカルの main を Pull して Behind/Ahead が 0 になることを確認。
参考リンク(Soft-Rime)
- GitHub Desktopの使い方
- GitコマンドとGitHub Desktopでのバージョン管理ガイド
- GitHub Desktop のコミット操作に関する技術資料
- GitHub Desktop の「フェッチ」とは?
- GitHub Desktopで変更を破棄する方法
- .gitignore/Ignore の扱い(大容量ファイルの注意)
③ コンフリクト最短マスター—6パターンの見分け方と最短解消手順
対象:ブランチ統合で衝突しがちな人
ゴール:よくある衝突を“型”で認識し、Desktop とエディタ/CLI の両面で解消できる
1. コンフリクトの正体(3語で理解)
- コンフリクト:Git が「どちらが正しいか決められない」状態
- 共通祖先:分岐前の基準コミット
- ours / theirs:マージ実行側/取り込み側の変更ファイル内には <<<<<<<, =======, >>>>>>> のマーカーが入ります。
2. 最小6パターン(代表例)
- 同一行の同時編集
- 同一ファイル別所編集(自動マージ不能)
- 片方が削除・片方が変更
- 改名(rename)絡み
- バイナリ衝突
- 依存ファイル(ロックファイル等)の衝突
3. 解消の定跡(Desktop→エディタ→記録)
- Desktop が衝突を検知→該当ファイルを外部エディタで開く
- どちら採用/手動統合を決めて編集→競合マーカーを除去
- Mark as resolved → Commit(「解決済み」を履歴に残す)
- テスト/ビルド→PR 継続/Merge
4. 予防のゴールデンルール
- ブランチを長く放置しない(こまめに Pull/Rebase)
- PR は小さく早く
- ファイル分担を明確に(ロックファイルや設定は責任者を決める)
付録:CLI派の最小コマンド
# 競合ファイルの確認
git status
# コンフリクト箇所を修正後に記録
git add <file>
git commit -m "Resolve conflict in <file>"
演習
- 同じ行を別ブランチで編集→PRで衝突→Desktopで解消→Mark as resolved→コミット→PRを完走。
参考リンク(Soft-Rime)
- 簡単な Git のコンフリクトのパターンと修正(GitHub Desktop 実践)
- GitHub Desktop でのコンフリクト解消方法
- 【Git】VisualStudioを使ったC#フォームアプリ開発でのコンフリクト解消
④ 小規模チームのGit運用テンプレ—規約・レビュー・保護設定
対象:授業/小チームの現場運用者
ゴール:最低限のルールで事故と手戻りを減らし、品質を底上げ
1. ブランチ戦略(最小)
- main:常に出荷可能。直コミット禁止(PR必須)
- feature/*:機能単位で枝分け(例:feature/add-login)
- 命名はガイドを共有(接頭辞の統一で迷いを減らす)
2. コミットメッセージ規約(最小)
- 要約(50字目安)+本文(Why/How)
- 1コミット=1意味単位、Issue/PR番号を本文末尾へ
3. PRテンプレ&レビュー観点
- テンプレ:目的/変更点/確認手順/影響範囲/関連Issue
- 観点:ビルド可否・影響範囲・命名・副作用・設計意図・テスト有無
4. 同期と保護の基本
- 毎日 Fetch→Behind/Ahead を確認→必要なら Pull/Rebase。
- Branch Protection(保護ルール):main に PR必須・レビュー必須・ステータスチェック必須を設定(作業誤爆を抑止)。
5. 運用中のよくある変更
- ブランチ名の後からの修正(ローカル+リモートの整合)
- リポジトリ名の変更(Fetch で最新化→各所の参照更新)
6. (任意).gitignore の最小例(Unity/VS向け)
Unity: Library/, Temp/, Logs/, Obj/, Build/, UserSettings/
VS: .vs/, *.user, bin/, obj/
巨大ファイルや生成物は最初から追わない。既に履歴に入った場合は git rm –cached を併用。
演習
- main に保護ルールを設定(PR必須+最低1レビュー+ステータスチェック1つ)。
- ブランチ命名規約を README に明文化。テンプレPRで運用開始。
参考リンク(Soft-Rime)
- Git ブランチ命名ガイド
- Gitで作成する名前のサンプルまとめ
- main ブランチ保護ルール設定ガイド
- ブランチに対する制約の方法(保護ルール概説)
- Gitで開発途中にブランチ名を変更するには(GitHub Desktop)
- Gitで開発途中にリポジトリ名を変更するには(GitHub Desktop)
- Visual Studio + GitHub Desktop で快適にソース管理を始めよう(.gitignore例あり)
訪問数 1 回, 今日の訪問数 3回
ディスカッション
コメント一覧
まだ、コメントがありません