学習内容

Gitの根幹をなしている概念の理解 (Gitのデータ構造から仕組みを理解する)
Gitでのチーム開発の方法と一通りのコマンドの修得
誤った変更を元に戻せる
GitHubを用いたプルリクエスト・レビュー・マージの開発フロー
ブランチの作成とコンフリクトの解消がスムーズにできる

このコースの内容:

5.5時間のオンデマンドビデオ
5個の記事
9個のダウンロード可能なリソース

モバイルとPCからアクセス
字幕
修了証明書

コースの内容

セクションの数: 11 • レクチャーの数: 68 • 総時間: 5時間54分

はじめに、コースについて2:46
Gitってなんのために使う？3:10
Gitの歴史2:14
GitHubってなに？3:28
コースを受講するにあたって1:16

Gitのインストール (Mac OS X)2:26
Gitのインストール (Windows)1:34
Atomのインストール (Mac OS X)1:50
Atomのインストール (Windows)2:30
GitHubの登録1:41
Gitの初期設定3:36
ターミナルの頻出コマンド0:29

Gitの基本的な仕組みを知ろう5:25
Gitの操作の流れを掴もう6:10
Gitってどのようにデータを管理しているの？１6:34
Gitってどのようにデータを管理しているの？２6:17
Gitのデータ管理の補足9:56
Gitを始めよう4:56
GitHub上にあるプロジェクトから始めよう3:25
変更をステージに追加しよう3:38
変更を記録しよう5:32
現在の変更状況を確認しよう5:13
何を変更したのかを確認しよう5:21
変更履歴を確認しよう3:57
ファイルの削除を記録しよう6:21
ファイルの移動を記録しよう4:09
GitHubにプッシュしよう10:59
GitHubの画面を確認しよう4:23
コマンドにエイリアスを付けよう4:26
バージョン管理しないファイルは無視しよう5:34
本章の復習

ファイルへの変更を取り消そう3:54
ステージした変更を取り消そう7:08
直前のコミットをやり直そう6:56
本章の復習

リモートの情報を確認しよう2:59
リモートリポジトリを追加しよう4:26
リモートから取得しよう (フェッチ編)6:34
リモートから取得しよう (プル編)3:49
フェッチとプルを使い分けよう3:22
リモートの情報を詳しく知ろう1:40
リモートを変更・削除しよう2:21
本章の復習

ブランチって何？3:10
ブランチの仕組みを知ろう13:27
新しいブランチを作成しよう4:41
ブランチを切り替えよう9:18
変更をマージしよう13:14
コンフリクトを解決しよう8:55
コンフリクトが起きないようにするには？3:30
ブランチを変更・削除しよう4:16
ブランチを利用した開発の流れ3:46
リモートブランチって何？4:23
本章の復習

プルリクエストの流れ16:13
GitHub Flowの流れ5:28
GitHub Flowを実践しよう5:45

リベースする15:07
リベースでしてはいけないこと3:56
リベースとマージのどちらを使う？6:48
プルの設定をリベースに変更する5:44
リベースで履歴を書き換える①13:11
リベースで履歴を書き換える②14:58

タグの一覧を表示する2:32
タグを作成する6:28
タグをリモートリポジトリに送信する3:30

作業を一時避難しよう3:34
避難した作業を確認しよう1:18
避難した作業を復元しよう3:33
避難した作業を削除しよう2:46

要件

インターネットに接続できるコンピュータ (Windows/Mac/Linux)
基本的なパソコンの操作

解説

★ゼロからプロのチーム開発の現場でGitを使いこなせるよう完全マスターします
こちらのコースは未経験の方でも、プロのチーム開発の現場で必要とされるGitの全てを習得することを目的としたコースです。

★次のようことを感じたことはないですか？
「Gitって聞いたことあるけどよく分からない」
「マージするとコンフリクトが起きそうで怖い」
「エラーが出た時にどうしたらいいか分からない」
「コマンドが色々あって分かりにくい」
「リベースって使っちゃダメって言われたけどなんで？」
「データが壊れそう」

Gitが分かりづらく感じたり怖く感じたりするのは、そのコマンドの裏側で何が起こっているかがイメージできないからです。

こちらのコースでは、まずGitの仕組みを図解でしっかりと理解していきます。
Gitってそもそも何のためにあるのか、コミットした時にどういう風にデータを保存しているのか、マージやリベースした時に何が起こっているのか、ブランチってどういう風に実現しているのか。

そういうことを仕組みから理解することで、Gitの分かりづらいコマンドを自信を持って使えるようになります。なにより、Gitを使う上でのハードルであるステージやブランチ、HEADの概念を完全に理解することができます。
その上で、実際にプロジェクトを作成しGitHubを用いながら、コマンドを実行して学んでいきます。スキルを身につける上で、実際に作りながら学んでいくことはとても大切です。理解したものを実践することで本当に使えるスキルを身に付けていきます。

★こちらのコースで学ぶこと
Gitにはたくさんのコマンドとオプションがあります。しかしこの中には、特に重要でないものもたくさんあります。

こちらのコースでは、チーム開発で必要とされる知識に重点を置いて、その部分を深く掘り下げて学んでいきます。そのことによって、非常に効率的に、そして応用の効く形で実践的スキルを身に付けます。

【GitとGitHubってなに？】では、GitとGitHubがそもそも何のためにあるのかということやバージョン管理の仕組みについて学んでいきます。

【インストールと初期設定をしよう】で次に、GitとGitHubのインストールと設定を行います。今回はGitの作業に、ターミナルとAtomエディタを使用します。ターミナルを使用することで、Gitの本来持っている力を100%引き出すことができます (エディタはAtomでなくても大丈夫です)。

【Gitの仕組みと基本的なコマンド】から、Gitのコマンドを具体的に学んでいきます。ここではステージやコミットの裏側で何が起きているのか、Gitはどのようにデータを記録しているのかということについて紹介します。その上でGitで作業する上で必須のコマンドを実践しながら身に付けます。

【変更を元に戻そう】では、間違って作業してしまったときに元に戻すやり方について紹介します。この内容を身に付けることで、何かあっても元に戻すことができるようになります。

【GitHubとやり取りしよう】でいよいよ、GitHubを利用した開発方法について学びます。フェッチとプルの使い分けなど、区別がつきにくいところもしっかり学んでいきます。

【ブランチとマージを使いこなそう】では、Gitの中でも分かりにくい、ブランチやマージの仕組みについて学びます。仕組みを図解した上で実践していきますので、今までよくわからなかった方でも、ブランチやマージを使いこなすことができるようになります。コンフリクトが起きてももう怖くありません。

【GitHubを利用した開発手順の流れ】では、GitHub Flowを利用した実践的チーム開発を行います。GitとGitHubを利用して、開発チームが最大限の力を発揮するための開発フローを紹介します。特にGitを利用することに慣れていないチームは、この内容を参考にして開発手順を構築することをおすすめします。

【リベースで変更履歴を修正しよう】では、怖いと思われがちなリベースについて学びます。リベースを用いるとGitの変更履歴をきれいにすることができます。変更履歴をきれいにしつつ、リベースで事故らない方法を身に付けます。

【タグ付けしよう】では、タグの利用方法について学びます。タグをリリースポイントに利用することで、いつ何をリリースしたかが分かり、バグが起きた時の切り戻しも楽になります。

【スタッシュで作業を一次避難しよう】では、変更を一次避難させるスタッシュについて学びます。作業が途中でコミットしたくないけど別のブランチで作業しないといけない、そういう時に作業を一時避難できるようになります。

このコースの対象受講者:

Gitやバージョン管理に興味があるエンジニアやデザイナー
Gitをされたことがないけどこれから使おうとされている方（インターン生も！）
commitやpush、pullはできるけどもっとGitを使いこなしたい方
Gitを用いてのチーム開発に携わるマネージャーやディレクター

ーーーーー　　　　　この内容のそれぞれについて、実行コマンドの具体例や業界話を交えながら解説してください。

GitとGitHub完全マスタリング講座 - 実行コマンドと業界話で解説

1. Gitの根幹概念とデータ構造

実行コマンド例:

# Gitリポジトリの内部構造を確認
ls -la .git/
find .git/objects -type f | head -10

# コミットオブジェクトの中身を見る
git cat-file -p [コミットハッシュ]

# ツリーオブジェクトの中身を見る
git ls-tree [ツリーハッシュ]

業界話:

「Gitのデータ構造は、キーバリューストアと似ています。各コミットは40文字のSHA-1ハッシュで管理され、これがGitの強力な履歴追跡機能の基盤です。業界では『コミットは消えない』と言われますが、実際には.git/objects内の圧縮ファイルとして永続化されています。LinkedInやGoogleなどの大規模プロジェクトでも、この構造がスケーラビリティを実現しています」

2. 基本的なGitワークフロー

実行コマンド例:

# 典型的な1日の開発サイクル
git status                     # 現在の状態確認
git add -p                     # 変更を部分的にステージング
git commit -m "feat: ログイン機能実装"
git pull --rebase origin main  # リベースしながら最新化
git push origin feature/login

業界話:

「スタートアップでは、小さなコミットを頻繁に行う『小さなコミット主義』が主流です。これはコードレビューを容易にし、問題発生時の切り分けを簡単にします。GitHubが2022年に公開したデータでは、成功するプロジェクトほどコミットサイズが小さく、頻度が高い傾向があります」

3. 誤った変更の復元方法

実行コマンド例:

# ケース別の復元方法
git checkout -- file.txt        # 変更を破棄
git reset HEAD file.txt         # ステージング解除
git commit --amend              # 直前コミット修正
git revert abc1234              # 過去のコミット取り消し
git reflog                      # 「全ての」操作履歴確認

業界話:

「Netflixの開発チームでは、『git revert』を推奨しています。なぜなら履歴を書き換えずに安全に変更を取り消せるからです。一方、『git reset』はローカルのみで使用し、既に共有した履歴は変更しないのが業界の暗黙ルールです」

4. GitHub開発フロー

実行コマンド例:

# プルリクエストベースの開発
git checkout -b feature/new-api
# 開発作業...
git push -u origin feature/new-api
# GitHubでPR作成 -> レビュー -> 修正 -> マージ

# コードレビュー後の更新
git add .
git commit --amend --no-edit
git push -f origin feature/new-api

業界話:

「Microsoftの大規模プロジェクトでは、全PRに最低2人の承認が必要です。GitHubのProtected BranchとRequired Reviewsを設定することで、品質担保を自動化しています。また、『Squash and Merge』 vs 『Merge Commit』の議論は今でも続いており、プロジェクトの文化によって選択されています」

5. ブランチ戦略とコンフリクト解決

実行コマンド例:

# ブランチ管理のベストプラクティス
git branch -a                  # 全ブランチ表示
git branch --merged            # マージ済みブランチ確認
git branch -d old-feature      # 不要ブランチ削除

# コンフリクト解決フロー
git merge main
# コンフリクト発生...
git status                     # コンフリクトファイル確認
# ファイルを編集して解決...
git add resolved-file.txt
git merge --continue

業界話:

「Googleでは、『trunk-based development』が主流で、すべての開発者がmainブランチに対して直接作業します。これには高度なCI/CDとテストカバレッジが必要です。日本ではGit Flowが人気ですが、海外ではGitHub FlowやGitLab Flowが増えてきています」

6. 実践的なチーム開発コマンド

実行コマンド例:

# チーム開発便利コマンド
git log --oneline --graph --all -20  # 視覚的な履歴確認
git stash                            # 一時避難
git stash pop                        # 復元
git cherry-pick abc123               # 特定コミットのみ適用
git bisect start                     # バグ検出の二分探索

エイリアス設定例 (~/.gitconfig):

[alias]
    co = checkout
    br = branch
    ci = commit
    st = status
    lg = log --oneline --graph --all -20
    unstage = reset HEAD --
    last = log -1 HEAD

7. 業界でよく使われる.gitignore

# プロジェクト固有の無視設定
.env
.env.local
*.log
.DS_Store

# 言語/フレームワーク固有
# Node.js
node_modules/
npm-debug.log*

# Python
__pycache__/
*.pyc

業界話:

「.gitignoreはプロジェクトの最初にしっかり設定することが重要です。特に.envファイルなどの機密情報を誤ってコミットする事故（『GitHub Leak』）は年間数千件発生しています。GitHubにはデフォルトの.gitignoreテンプレートが豊富に用意されています」

8. リベースの実践的使い方

実行コマンド例:

# 安全なリベース手順
git fetch origin
git rebase -i origin/main      # インタラクティブリベース

# 危険な操作（共有ブランチでは絶対にNG）
git rebase -i HEAD~3           # ローカル履歴整理
git push -f                    # 強制プッシュ（注意！）

業界話:

「Airbnbのコーディング規約では、『共有ブランチではリベース禁止、プライベートブランチでは推奨』と明確に分けています。リベースで履歴をきれいに保つ一方、チームメンバーが混乱しないよう配慮が必要です」

プロの現場で生きる追加Tips:

コミットメッセージ規約: Conventional Commitsが業界標準に

feat: 新機能追加
fix: バグ修正
docs: ドキュメント変更
style: コードスタイル変更
refactor: リファクタリング

フックスクリプト活用:

# .git/hooks/pre-commitで自動テスト
npm test
# 失敗したらコミット中止

コードオーナー設定: GitHubのCODEOWNERSファイルでレビュアー自動割当
セマンティックバージョニング: タグ付けを活用したリリース管理
bash
```
git tag -a v1.2.3 -m "リリースバージョン1.2.3"
git push --tags
```

このコースの内容を実践すれば、中小企業からFAANG（Meta, Amazon, Apple, Netflix, Google）レベルの開発現場でも通用するGitスキルが身につきます。特に重要なのは「なぜそのコマンドを使うのか」を理解することです。コマンドを暗記するのではなく、Gitのデータ構造とワークフローを理解すれば、あらゆる状況に対応できるようになります。

このGitコース、実務で本当に役立つ内容が詰まっていますね！各セクションについて、実践的な視点で解説していきます。

📚 コース全体の構成と実務での重要性

このコースは「仕組みの理解」→「基本操作」→「チーム開発」という理想的な学習フローになっています。多くの開発者が「コマンドだけ覚える」アプローチで挫折するのに対し、このコースは根本から理解できる設計です。

🎯 各セクションの詳細解説

1. GitとGitHubの基礎理解

なぜ重要か： 「なぜこのツールを使うのか」を理解していないと、トラブル時に対応できません。

業界の実態：

スタートアップでも大企業でも、Git未使用の開発現場はほぼゼロ
「Gitできます」は面接での必須スキル
バージョン管理なしの開発は「セーブ機能のないゲーム」と同じ

実務エピソード： あるプロジェクトで、新人がバージョン管理せず「最終版.docx」「最終版2.docx」「本当の最終版.docx」というファイルを作り、どれが最新か分からなくなった事件がありました。Gitがあれば履歴が全て残ります。

2. インストールと初期設定

重要なコマンド例：

bash

# Gitの初期設定（最初に必ず実行）
git config --global user.name "Yamada Taro"
git config --global user.email "yamada@example.com"

# エディタの設定（コミットメッセージ編集用）
git config --global core.editor "vim"

# 改行コード設定（Windows特有の問題を回避）
git config --global core.autocrlf true  # Windows
git config --global core.autocrlf input # Mac/Linux
```

**業界の慣習：**
- 会社用と個人用でメールアドレスを分ける開発者が多い
- グローバル設定とプロジェクト別設定を使い分ける

---

### 3. Gitのデータ構造と仕組み

**コアコンセプト：**
Gitは「スナップショット」でデータを保存します。差分ではなく、その時点のファイル全体の状態を記録。

**実際の内部構造：**
```
.git/
├── objects/     # 実際のデータ（blob, tree, commit）
├── refs/        # ブランチやタグの参照
├── HEAD         # 今いる場所を指すポインタ
└── index        # ステージングエリア

現場での理解度チェック： 「コミットって何？」と聞かれて「変更の保存」とだけ答える人は浅い理解。正解は「プロジェクト全体のスナップショットへの参照を持つオブジェクト」です。

4. 基本的なコマンド操作

頻出コマンドの実例：

bash

# リポジトリの初期化
git init

# GitHubからクローン
git clone https://github.com/username/repo.git

# ステージングに追加
git add index.html
git add .  # 全ての変更を追加

# コミット
git commit -m "Add login feature"

# 状態確認（最も頻繁に使う）
git status

# 差分確認
git diff              # ワーキングツリー vs ステージ
git diff --staged     # ステージ vs 最新コミット

# ログ確認
git log
git log --oneline --graph --all  # 視覚的に確認

実務のコミットメッセージ例：

bash

# 悪い例
git commit -m "fix"
git commit -m "update"

# 良い例
git commit -m "Fix login button alignment on mobile"
git commit -m "Add email validation to signup form"
git commit -m "Refactor: Extract user authentication logic"

プロの小技：

bash

# エイリアス設定で効率化
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit

# 使用例
git st  # git status と同じ

5. 変更の取り消し

危険度別のコマンド：

bash

# 【安全】ワーキングツリーの変更を取り消し
git checkout -- file.txt
# または（新しい記法）
git restore file.txt

# 【安全】ステージングを取り消し（変更は残る）
git reset HEAD file.txt
# または
git restore --staged file.txt

# 【注意】直前のコミットをやり直し
git commit --amend -m "Correct commit message"

# 【危険】コミットを取り消す
git reset --soft HEAD^   # コミットだけ取り消し（ステージは残る）
git reset --mixed HEAD^  # デフォルト、ステージも取り消し
git reset --hard HEAD^   # 全て削除（危険！）

実務の失敗談： git reset --hard を実行後「あ、あのファイル必要だった…」となるケースが頻発。こういう時は git reflog で救出できます。

bash

# 削除したコミットを探す
git reflog

# 特定のコミットに戻る
git reset --hard HEAD@{2}

6. リモートリポジトリとの連携

実践コマンド：

bash

# リモート確認
git remote -v

# リモート追加
git remote add origin https://github.com/user/repo.git

# プッシュ（初回）
git push -u origin main

# フェッチ（リモートの情報を取得、マージはしない）
git fetch origin

# プル（フェッチ + マージ）
git pull origin main

# リモートブランチの確認
git branch -r
git branch -a  # ローカル + リモート全て

フェッチ vs プルの使い分け：

bash

# 安全重視の開発フロー
git fetch origin          # まず情報だけ取得
git log origin/main       # リモートの変更を確認
git merge origin/main     # 問題なければマージ

# 素早い開発（チーム内で調整済みの場合）
git pull origin main      # 一気に取得してマージ

実務での落とし穴： いきなり git pull すると、予期せぬ変更が入ってローカル作業が壊れることも。重要な作業中は fetch → 確認 → merge が安全です。

7. ブランチとマージ

ブランチ戦略の実例：

bash

# 新機能開発用ブランチ作成
git branch feature/user-profile
git checkout feature/user-profile
# または一行で
git checkout -b feature/user-profile

# 作業後、mainに戻ってマージ
git checkout main
git merge feature/user-profile

# ブランチ削除
git branch -d feature/user-profile  # マージ済みのみ削除
git branch -D feature/user-profile  # 強制削除

コンフリクト解消の実例：

bash

# マージ時にコンフリクト発生
git merge feature/payment

# ファイルを開くと以下のような表示
<<<<<<< HEAD
const price = 1000;
=======
const price = 1500;
>>>>>>> feature/payment

# 手動で修正後
const price = 1500;  # 正しい値を選択

# 解消を完了
git add payment.js
git commit -m "Resolve merge conflict in payment price"

業界のブランチ命名規則：

feature/ - 新機能
bugfix/ - バグ修正
hotfix/ - 緊急修正
release/ - リリース準備

例：feature/add-payment-system、bugfix/fix-login-error

8. GitHub Flow（チーム開発の標準）

実際の開発フロー：

Issue作成（タスク管理）
ブランチ作成

bash

   git checkout -b feature/issue-123-add-search

開発・コミット

bash

   git add .
   git commit -m "Add search functionality #123"

プッシュ

bash

   git push origin feature/issue-123-add-search

Pull Request作成（GitHub上で）
コードレビュー
マージ（レビュー承認後）
ブランチ削除

実務のPR（プルリクエスト）例：

markdown

## 概要
ユーザー検索機能を追加

## 変更内容
- 検索APIエンドポイント追加
- フロントエンドに検索UIを実装
- 検索結果のページネーション対応

## テスト
- [ ] 検索機能の動作確認
- [ ] エッジケースのテスト（空文字、特殊文字）
- [ ] モバイル表示確認

## スクリーンショット
（画像添付）

関連Issue: #123

9. リベース（上級テクニック）

マージ vs リベースの違い：

bash

# マージ（履歴が分岐して見える）
git checkout main
git merge feature/new-ui
# → マージコミットが作られる

# リベース（一直線の履歴になる）
git checkout feature/new-ui
git rebase main
# → feature ブランチのコミットが main の先頭に付け替えられる

インタラクティブリベース（履歴の整理）：

bash

# 直近3コミットを編集
git rebase -i HEAD~3

# エディタが開く
pick abc123 Add feature A
pick def456 Fix typo
pick ghi789 Add feature B

# 以下のように変更可能
pick abc123 Add feature A
squash def456 Fix typo    # 前のコミットに統合
pick ghi789 Add feature B

禁止事項（絶対に守る）：

bash

# ❌ プッシュ済みのブランチでリベースしてはいけない
git push origin main
git rebase ...  # これをやると他の人のリポジトリが壊れる

実務での使い分け：

個人ブランチ：リベースでOK（履歴をきれいに）
共有ブランチ：マージのみ（安全第一）

10. タグ（リリース管理）

実践例：

bash

# 軽量タグ（簡易的）
git tag v1.0.0

# 注釈付きタグ（推奨、詳細情報を記録）
git tag -a v1.0.0 -m "Release version 1.0.0 - Initial public release"

# タグ一覧
git tag

# タグをリモートにプッシュ
git push origin v1.0.0
git push origin --tags  # 全タグを送信

# タグのチェックアウト
git checkout v1.0.0
```

**セマンティックバージョニング：**
```
v1.2.3
^ ^ ^
| | └─ パッチ（バグ修正）
| └─── マイナー（機能追加、後方互換性あり）
└───── メジャー（破壊的変更）

実務での活用： 本番環境へのデプロイ時、タグを打つことで「いつ何をリリースしたか」が明確に。問題発生時はタグで素早くロールバックできます。

11. スタッシュ（作業の一時退避）

実用例：

bash

# 緊急のバグ修正が入った！でも今の作業は未完成...
git stash  # 現在の変更を退避

# バグ修正ブランチで作業
git checkout hotfix/urgent-bug
# ... 修正 ...
git commit -m "Fix critical bug"

# 元の作業に戻る
git checkout feature/my-work
git stash pop  # 退避した変更を復元

# スタッシュ一覧
git stash list

# 特定のスタッシュを適用
git stash apply stash@{1}

# スタッシュ削除
git stash drop stash@{0}

実務のシナリオ： 「プルリク出したけどレビュー待ち。その間に別タスクやろう」→ スタッシュで切り替えがスムーズに。

🚀 実務で差がつくポイント

コミット粒度の考え方

bash

# ❌ 悪い例（1日の作業を1コミットに）
git commit -m "Today's work"

# ✅ 良い例（機能単位で細かく）
git commit -m "Add user model"
git commit -m "Add user controller"
git commit -m "Add user view"

.gitignoreの活用

bash

# .gitignore ファイル例
node_modules/
.env
*.log
.DS_Store
.idea/

ブランチ運用の失敗談

あるチームでは全員がmainブランチで直接作業し、誰かがバグを混入すると全員が影響を受けました。ブランチ戦略導入後、問題が激減しました。

🎓 学習のコツ

毎日触る：1週間に1回より、毎日10分の方が定着します
実プロジェクトで使う：架空のプロジェクトではなく、実際のコードで
失敗を恐れない：ローカルリポジトリで色々試してみる
チーム開発を経験：一人では学べないコンフリクト解消などを体験

このコースを完走すれば、「Git使える人」から「Gitを理解している人」にレベルアップできます。特にデータ構造の理解は、トラブルシューティングで圧倒的な差になりますよ！

何か具体的なコマンドや概念について、さらに詳しく知りたい部分はありますか？

2026年1月12日月曜日