GitHub Desktopで学ぶGit—入門からチーム運用まで【完全版】

2025年8月29日

目次

① Git入門—最短でつかむ「しくみ」と言葉、最初の一歩

対象：初めて Git を触る人

ゴール：3つの領域（作業ツリー／ステージング／履歴）と、コミット・ブランチ・リモートの関係が分かる

1. Git は“コードの保険＋協力の仕組み”

  • いつでも過去に戻れる（保険）
  • 誰が・いつ・何を変えたか見える（透明性）
  • チーム開発が安全に進む（協調）

まずは GUI（GitHub Desktop）で成功体験→裏側の動きをCLIで補強の順で学ぶと挫折が少ないです。

2. 最小の用語セット

  • リポジトリ：履歴の入れ物（ローカル／リモート）
  • コミット：スナップショット（説明文＝メッセージ付き）
  • ブランチ：作業の枝分かれ（main は常に安定）
  • ステージング（インデックス）：コミット前の“載せる／載せない”選別エリア

作業フロー概要

作業ツリー ──(add)──> ステージング ──(commit)──> 履歴（ローカル）
                                              │
                                              └──(push)──> リモート（GitHub）

3. はじめの“成功体験”チェックリスト（GitHub Desktop）

  1. New/Clone でローカルに用意
  2. ファイルを1つ編集 → Summaryを書いて Commit
  3. Publish/Push で GitHub へ
  4. ブラウザの履歴でコミットを確認

4. つまずきやすい所と対処

  • Behind/Ahead：ローカルとリモートの進み具合。まず Fetch で最新情報を取り込み、差分を見てから Pull/Push を判断。
  • いらない変更の取り消し（Discard）：ファイル単位／全体で安全に破棄。

演習

  • 新規リポジトリを作成→hello.txt を追加→3回コミット（A/B/C）→GitHubへPush。
  • 履歴画面で「いつ／なに／なぜ」がメッセージに書けているか自己点検。

参考リンク（Soft-Rime）

② 図で理解する Git ×GitHubDesktopClone→Branch→Commit→PR→Merge

対象：操作フローを GUI 中心で身につけたい人

ゴール：最小フローを手でなぞり、CLI対応も“見える化”して理解

1. 全体フロー（最小）

Clone → Branch → Commit → Push → Pull Request → Review → Merge

GitHub Desktop の画面遷移に沿ったステップ学習が安全です。

2. 手順（GitHub Desktop）

  1. Clone：GitHub のリポジトリをローカルへ
  2. Branch：feature/●● を作って作業を分離（命名はチームで統一）
  3. Commit：小さく頻繁に、要約→本文で「なぜ」を残す
  4. Push：リモートへ反映
  5. PR作成：目的／変更点／確認手順／影響範囲を明記
  6. レビュー→Merge：main 直コミットは避け、PR経由で統合

参考リンク（Soft-Rime）

3. Desktop↔CLI 対応ミニ表

目的GitHub DesktopGit（CLI）
ブランチ作成Branch → New Branchgit switch -c feature/foo
変更の記録Summary入力→Commitgit add -A && git commit -m “…"
反映Push origingit 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 を併用）。

6. Squash merge（History／メニュー）

6.1 やり方①：ブランチ内の複数コミットを 1 つにまとめる（History）

  1. Current Branch で対象ブランチを選択
  2. 左サイドバーの History を開く
  3. まとめたいコミットを Ctrl/Cmd または Shift で複数選択し、まとめ先コミットへ ドラッグ＆ドロップ
  4. ダイアログでメッセージを整えて Squash Commits
  • 公開済み履歴をまとめる場合は Force push が必要になることがある
  • マージコミットが含まれる範囲は失敗 する（範囲を分割する）
  • 未コミット変更があると Stash Changes and Continue の案内が出るヒント：History では Reorder（並べ替え） もドラッグ＆ドロップ対応。順序を整えてから Squash すると、履歴の読みやすさが上がる。  

6.2 やり方②：他ブランチをスクワッシュして取り込む（メニュー）

  1. 取り込み先ブランチ（例：main）をチェックアウト
  2. メニュー Branch → Squash and Merge into Current Branch
  3. 取り込み元ブランチを選び Squash and merge → 終了後 Push origin（必要なら）  

6.3 PR（Pull Request）運用との関係

  • GitHub（Web）の PR でも “Squash and merge” を選べる
  • リポジトリ設定で Allow squash merging を有効化しておくと運用が安定する  

③ コンフリクト最短マスター — 

補足：Squash の注意点

  1. Squash は履歴の再構成 を伴う場合がある。共同作業では 事前告知 のうえ、feature ブランチ限定 で実施を推奨
  2. 「マージコミットを含んで失敗」 → 対象範囲を分割する／Reorder 等で解消
  3. 未コミット変更がある → 案内に従い Stash を使ってから続行
  4. 既存の Behind/Ahead→Fetch/Pull→判断 という基本リズムは 25604 の記述に従うこと  

④ 小規模チームのGit運用テンプレ — 

追記：9. Squash ベース運用ルール

  1. 原則：PR のマージ方式は “Squash and merge”（メイン履歴を「1PR=1コミット」に保ち、読みやすく・巻き戻しやすく）
  2. 例外：低レイヤや障害解析など 細粒度の履歴価値が高い リポジトリは通常マージ
  3. PR 前の整形：開発者は History → Squash で WIP/typo 修正などのノイズを事前整理
  4. メッセージ規約：Conventional Commits を推奨（feat: / fix: / docs: …）。共同作業者は必要に応じて本文末尾に Co-authored-by: を追記  

参考リンク（Soft-Rime）

付録：Desktop ↔ CLI 対応（Squash 版）

A. 別ブランチをスクワッシュ取り込み（マージコミットは作らない）

git switch main
git fetch origin
git merge --squash origin/feature-xyz
git commit -m "feat: 〇〇機能を追加（概要…）"
git push origin main

B. ブランチ内のコミットをまとめる（対話的リベースの一例）

git switch feature-xyz
git rebase -i origin/main     # pick/squash/fixup を使う
git push -f origin feature-xyz  # 公開後は要注意（Force push）

（概念対応の補強。実務は GitHub Desktop だけで完結可能。）  

演習

  • リポジトリをクローン→feature/readme-fix で README に追記→コミット→Push→PR→Merge。
  • Merge 後、ローカルの main を Pull して Behind/Ahead が 0 になることを確認。

参考リンク（Soft-Rime）

③ コンフリクト最短マスター—6パターンの見分け方と最短解消手順

対象：ブランチ統合で衝突しがちな人

ゴール：よくある衝突を“型”で認識し、Desktop とエディタ／CLI の両面で解消できる

1. コンフリクトの正体（3語で理解）

  • コンフリクト：Git が「どちらが正しいか決められない」状態
  • 共通祖先：分岐前の基準コミット
  • ours / theirs：マージ実行側／取り込み側の変更ファイル内には <<<<<<<, =======, >>>>>>> のマーカーが入ります。

2. 最小6パターン（代表例）

  1. 同一行の同時編集
  2. 同一ファイル別所編集（自動マージ不能）
  3. 片方が削除・片方が変更
  4. 改名（rename）絡み
  5. バイナリ衝突
  6. 依存ファイル（ロックファイル等）の衝突

3. 解消の定跡（Desktop→エディタ→記録）

  1. Desktop が衝突を検知→該当ファイルを外部エディタで開く
  2. どちら採用／手動統合を決めて編集→競合マーカーを除去
  3. Mark as resolved → Commit（「解決済み」を履歴に残す）
  4. テスト／ビルド→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運用テンプレ—規約・レビュー・保護設定

対象：授業／小チームの現場運用者

ゴール：最低限のルールで事故と手戻りを減らし、品質を底上げ

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）

訪問数 17 回, 今日の訪問数 1回

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

Posted by hidepon