はじめに

この記事は「これまでGitに触れる機会がなかった方へ、Gitについて教えてほしい」と頼まれた方向けの記事です。
いざ資料を作成する時に何から伝えればいいんだろう🤔と感じたため、同じ境遇の方への参考資料として残しております。

📖 目次

研修ステップ

Step 1: Gitって何？基礎編 ✨
- バージョン管理の概念を理解
- Gitの必要性を学ぶ
- 環境構築（Mac/Windows）
- 初期設定
Step 2: はじめてのGit操作 🎮
- リポジトリの概念を理解
- 基本コマンド実践（add, commit, status, log）
- コミットメッセージの書き方
- Git管理の仕組み（ワーキング/ステージング/リポジトリ）
Step 3: ブランチで遊ぼう！ 🌿
- ブランチの概念（パラレルワールド）
- ブランチ操作（作成・切り替え・マージ）
- コンフリクト解決の実践
Step 4: GitHub デビュー！ 🚀
- GitとGitHubの違い
- GitHubアカウント作成
- SSH鍵の設定（3つの方法を詳しく解説）
- リモートリポジトリ操作（push, pull, fetch）
- Pull Request入門
Step 5: チーム開発シミュレーション 👥
- チーム開発の流れ（Git Flow/GitHub Flow）
- 実践プロジェクト
- よくあるトラブルと対処法
- 便利な設定（.gitignore, alias, stash）

📚 まとめ

🎯 Git研修で身につけるスキル

この研修を通じて、以下のスキルを身につけることを目標とします。

バージョン管理の基礎概念を理解し、なぜGitが必要かを説明できる
基本的なGitコマンド（add, commit, push, pull）を使いこなせる
ブランチ操作を使った並行開発ができる
コンフリクト解決の手順を理解し、実践できる
GitHubを使ったリモート作業とチーム開発ができる
SSH鍵の設定と接続確認ができる
Pull Requestを使ったコードレビューフローを理解できる

1: Gitって何？基礎編 ✨

目標: Gitの概念を理解し、Gitを扱う環境を構築する！

1-1. はじめに

「バージョン管理について」

🎮 こんな経験ありませんか？
変更前の内容を残しておきたいため、ファイルがどんどん溜まっていく経験。

パーツ精査_v1-0.xml
パーツ精査_v1.1.xml
パーツ精査_v1.1_181001.xml
パーツ精査_v1.1_181001_2.xml
パーツ精査_v1.2_181001_修正.xml
パーツ精査_v1.2_最終修正.xml
パーツ精査_v1.2_提出用.xml

→ Gitを使えば、同じファイル名でバージョン管理できるようになります！

※ 全てをGitで管理する必要はありません。
Gitで管理するまでもないファイルは、そのまま管理することもあります！

✨ ほかにも、バージョン管理があれば...

📸 いつ - すべての変更に日時が記録される
👤 誰が - 変更した人が分かる
📝 何を - どんな変更をしたか分かる
💭 なぜ - 変更の理由も残せる
⏪ 戻せる - いつでも過去の状態に戻れる！

💡 Point

バージョン管理システム = ファイルの歴史を記録する仕組み

🎯 バージョン管理の3大メリット

タイムマシンみたいな機能 🕐

「あ、3日前のコードの方が良かった...」
→ 3日前のコードに戻せる！

パラレルワールド、または世界線のような機能 🌍

「新機能試したいけど、失敗したら怖い...」
→ 別の世界線（ブランチ）で安全に実験！

チーム連携機能 👥

「みんなで同時に開発したい！」
→ 各自の変更を上手に統合！

1-2. Gitについて

Git とは: ファイルの歴史を記録する仕組み
- いつでも過去に戻れる
- ファイルの変更履歴を記録
- チームで協力しやすい
なぜGitが必要？:
- 開発での失敗談
  - ファイルの手動管理によるデグレ(デグレード)の発生
    - ファイル名に「最終」「最終v2」「提出用」
- 作業履歴として残る
  - 別の人が作業する時に、変更の流れを追えたりする！

1-3. 環境構築

Git のインストール(Mac / Windows の手順)

MacではHomebrewを使用します

# すでにインストールされていないかチェック
which git
→ /usr/local/bin/git が表示されたらインストールされています！

# Homebrewをインストール
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# インストール後
vim ~/.bash_profile

# homebrew(.bash_profileの中)
export PATH="/opt/homebrew/bin:$PATH"

# Homebrewを使ってgitをインストール
brew install git

# 確認
git --version

Windowsではインストーラーを使用します

確認方法

# PowerShellまたはコマンドプロンプトを開いて
git --version
# → git version 2.47.1 みたいに表示されたら成功！✨

初期設定

git config --global user.name "あなたの名前"
git config --global user.email "メールアドレス"

1-4. 質問タイム

よしなに🍵

2: はじめてのGit操作 🎮

目標: 基本的なGitコマンドを使えるようになる！

2-1. リポジトリって何？

リポジトリ = プロジェクトの箱(ファイルやディレクトリの保存および、変更履歴が格納される場所)
ローカルリポジトリとリモートリポジトリ = ローカルリポジトリは手元にある自分のPCの中で管理するリポジトリ、リモートリポジトリとは、ウェブ上のサーバーに配置されていて複数にで共有できるリポジトリ

2-2. 基本コマンド実践

# リポジトリ作成
git init

# ファイルの追加(ステージングへ追加)
git add ファイル名
git add .  # 全部追加！

# コミット（セーブポイント作成）
git commit -m "メッセージ"

# 状態確認
git status
git log

# ファイルを前の状態に戻す
git restore ファイル名  # ワーーキングディレクトリの変更を最後のコミットの状態に戻す（変更を行った内容が消えるので注意！）
git restore --staged ファイル名  # ステージングから削除 (git addを取り消す)

実践演習（例）:

「初めてのコミット」を作ってみよう！
作ったコミットの状態を確認してみよう！
コミットに書いた内容を変更してみよう！ (git commit --amend)
作ったコミットをステージングから削除してみよう！

2-3. コミットメッセージの書き方

良い例 vs 悪い例
「あああ」「修正」のような後から確認した時に意味が通じない内容は避けた方がよいです

💡 コミットメッセージのプレフィックス

最近はコミットメッセージのプレフィックスに [] をつける方法をよく見ます。

メッセージ: プレフィックス＋用途

※ プレフィックス ... ファイルの先頭につける文字のこと

例: [add] [update] [fix] [実装] [修正] [リファクタ] [テスト]

※ プレフィックスを使用する時は、「英語で書く」「日本語で書く」のように、ルールを統一しておくと、履歴を見返したときに理解しやすくておすすめです。

機能追加時 [add]

[add] カウンセリング予約情報のCSVをS3へアップロードする機能とcronジョブを実装

機能更新時　[update]

[update] カウンセリング予約CSV出力機能の検索条件を修正

エラー修正時　[fix]

 [fix] ReceptionTime（受付不可時間）も予約と同様に40分のカウンセリング時間を考慮して判定されるように修正

2-4. Git管理の仕組み

名称	詳細
ワーキングディレクトリ	作業中のファイルがある場所
ステージングディレクトリ	`git add` でファイルを追加する場所
リポジトリ	`git add` でステージングに登録したファイルを `git commit` で履歴として記録する場所

💡 この段階はまだローカルリポジトリでの操作です。

2-5. 質問タイム

よしなに 🫖

3: ブランチで遊ぼう！ 🌿

目標: ブランチを使った並行作業ができるようになる！

3-1. ブランチの概念

ブランチ = パラレルワールドまたは世界線のようなもの！

3-2. ブランチ操作

# ブランチ作成(切り替えは行わない)
git branch 新機能

# ブランチ切り替え (Git 2.23.0（2019年8月）以降の推奨方法)
git switch 新機能

# ブランチ作成と同時に切り替え
git switch -c 新機能

# ベースのブランチから、新しいブランチを作成
git switch -c 新機能 ベースのブランチ

# ブランチ一覧
git branch

# マージ（統合）
git merge ブランチ名

実践演習（例）:

feature/新機能ブランチを作って作業
main にマージしてみる

ここで社内プロジェクトと同じルールを学習してもらってもよいかもです！

3-3. コンフリクト解決

🎮 ローカルでコンフリクトが起きるパターン

# main ブランチで作業
git switch -c main
echo "作業A-1" > README.md
git add . && git commit -m "作業Aを行った"

# feature-A ブランチを作って編集
git switch -c feature-A
echo "作業A-2✨" > README.md
git add . && git commit -m "A-1を更新した"

# feature-B ブランチを作って別の編集
git switch main
git switch -c feature-B
echo "作業B-1" > README.md
git add . && git commit -m "作業Bを行った"

# main に feature-A をマージ（成功）
git switch main
git merge feature-A

# main に feature-B もマージしようとすると...
git merge feature-B
# コンフリクト発生 ！！ `CONFLICT (content): Merge conflict in README.md`

コンフリクトが複雑でマージを中止したい場合

git merge --abort
# 元の状態に戻ります

🔧 コンフリクト解消の手順

📋 現在の状況確認

# まず状態を確認
git status

# こんな表示が出るはず
# On branch main
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#   (use "git merge --abort" to abort the merge)

# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
# 	both modified:   README.md

# no changes added to commit (use "git add" and/or "git commit -a")

🎯 Step 1: コンフリクトしたファイルを開く

README.mdを開くと、こんな感じになってるはず！

<<<<<<< HEAD
作業A-2✨
=======
作業B-1
>>>>>>> feature-B

これの意味は

<<<<<<< HEAD から ======= まで → 現在のブランチ（main）の内容
======= から >>>>>>> feature-B まで → マージしようとしてるブランチの内容

🌟 Step 2: どちらを残すか決める

パターン1: feature-Bの内容だけ残す

作業B-1

パターン2: 両方残す

作業A-2✨
作業B-1

パターン3: 新しく書き直す

作業A-2✨とB-1を統合しました

✨ Step 3: コンフリクトマーカーを削除

必ず以下の3つを全部消す！

<<<<<<< HEAD
=======
>>>>>>> feature-B

💫 Step 4: 修正をステージング＆コミット

# 修正したファイルをステージング
git add README.md

# 状態確認（緑色になってるはず！）
git status

----
On branch main
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:
	modified:   README.md

# マージコミットを作成
git commit -m "[merge] feature-B: A-2とB-1の内容を統合"

git status

On branch main
nothing to commit, working tree clean

# 完了！
git log --oneline -5

---
f94d17f (HEAD -> main) [merge] feature-B: A-2とB-1の内容を統合
dc52e83 (feature-B) 作業Bを行った
ebeac36 (feature-A) A-1を更新した
9c41490 作業Aを行った
f44f870 (master) [add] init commit

3-4. 質問タイム

よしなに 🍰

4: GitHub デビュー！ 🚀

目標: GitHubを使ってリモート作業ができるようになる！

📝 Git と GitHub の違い

Git = バージョン管理システム（ツール本体）

ローカル（自分のPC）だけで完結して使える！
ファイルの変更履歴を記録するシステム
2005年にリーナス・トーバルズさんが作った無料のオープンソース

GitHub = Git のホスティングサービス（クラウドサービス）

Git で管理してるリポジトリをオンラインで共有するための場所
Microsoft が運営してるWebサービス
GitLab、Bitbucket とかの競合サービスもある
アカウント作成が必要

4-1. GitHub アカウント作成

https://github.com/signup にアクセスし新規アカウントを作成します

プロフィール設定
SSH鍵の設定（ちょっと難しいけど頑張って！）

💡 空のリポジトリを作成したら、初期に実行するべきコマンドが記載されています！

4-1-1. SSHキー生成（手元のPCで実行します)

まずはSSH鍵を生成します。SSH鍵は「秘密鍵」と「公開鍵」のペアで、公開鍵をGitHubに登録することで安全に通信できます。

# .sshディレクトリを作成（既にある場合はスキップされます）
mkdir -p ~/.ssh

# .sshディレクトリに移動
cd ~/.ssh

# SSH鍵を生成（メールアドレスは自分のものに変更してください）
ssh-keygen -t ed25519 -C "your.email@example.com"

実行すると、以下のような質問が表示されます：

Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/your-name/.ssh/id_ed25519):

→ 何も入力せずEnter（デフォルトの場所に保存）

Enter passphrase (empty for no passphrase):

→ 何も入力せずEnter（パスフレーズなし。セキュリティを高めたい場合は設定可）

Enter same passphrase again:

→ 何も入力せずEnter

成功すると以下のような表示が出ます：

The key fingerprint is:
SHA256:sRH2wj8bwOHVNdJilbSNtmRmmq+cptLJILcG8yIfH1Y your.email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        + ...==. |
|       = =  +.o= |
|        O .. .O .|
|         B   O . |
|        S E o .  |
|      + o. + .   |
|      .*o=..  .  |
|    . .+=.+..o   |
|     o.o...o+    |
+----[SHA256]-----+

生成された鍵ファイル：

~/.ssh/id_ed25519 (秘密鍵：絶対にネット上に公開しないこと)
~/.ssh/id_ed25519.pub (公開鍵：GitHubに登録するもの)

4-1-2. SSH鍵の管理方法（3つの方法）

SSH鍵をGitHubで使うための設定方法を3つ紹介します。
初心者の方は「方法1」がおすすめです。

方法1: デフォルトの場所で使う（最もシンプル！初心者向け）

鍵をデフォルトの場所（~/.ssh/id_ed25519）に置いたまま使う方法です。

# パーミッション設定（セキュリティのため必須）
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519      # 秘密鍵は自分だけ読み書き可能
chmod 644 ~/.ssh/id_ed25519.pub  # 公開鍵は他人も読める

# 公開鍵をクリップボードにコピー
# Mac
pbcopy < ~/.ssh/id_ed25519.pub

# Windows (Git Bash)
cat ~/.ssh/id_ed25519.pub | clip

# Linux
cat ~/.ssh/id_ed25519.pub  # 表示して手動でコピー

メリット：

設定が最小限で簡単
追加の設定ファイル不要

デメリット：

複数サービス（GitHub、GitLab等）で異なる鍵を使いたい場合は不便

方法2: フォルダ整理 + ssh-addで管理（中級者向け）

鍵を整理用フォルダに移動し、ssh-agentで管理する方法です。

# 1. GitHub用のフォルダを作成して鍵を移動
mkdir -p ~/.ssh/github
mv ~/.ssh/id_ed25519 ~/.ssh/github/
mv ~/.ssh/id_ed25519.pub ~/.ssh/github/

# 2. パーミッション設定
chmod 700 ~/.ssh
chmod 700 ~/.ssh/github
chmod 600 ~/.ssh/github/id_ed25519
chmod 644 ~/.ssh/github/id_ed25519.pub

# 3. ssh-agentを起動
eval "$(ssh-agent -s)"
# → Agent pid 12345 のように表示されれば成功

# 4. 鍵をssh-agentに追加
ssh-add ~/.ssh/github/id_ed25519
# → Identity added: ... と表示されれば成功

# macOSの場合（キーチェーンに保存して再起動後も有効にする）
ssh-add --apple-use-keychain ~/.ssh/github/id_ed25519

# 5. 公開鍵をクリップボードにコピー
# Mac
pbcopy < ~/.ssh/github/id_ed25519.pub

# Windows
cat ~/.ssh/github/id_ed25519.pub | clip

メリット：

鍵を整理できる
複数の鍵を使い分けやすい

デメリット：

PCを再起動するたびにssh-addが必要（macOS以外）
少し手順が増える

方法3: configファイルで永続化（上級者向け）

SSH configファイルを使って、永続的に設定する方法です。

# 1. 鍵をフォルダに整理（方法2と同じ）
mkdir -p ~/.ssh/github
mv ~/.ssh/id_ed25519 ~/.ssh/github/
mv ~/.ssh/id_ed25519.pub ~/.ssh/github/

# 2. パーミッション設定
chmod 700 ~/.ssh
chmod 700 ~/.ssh/github
chmod 600 ~/.ssh/github/id_ed25519
chmod 644 ~/.ssh/github/id_ed25519.pub

# 3. SSH configファイルを作成・編集
vim ~/.ssh/config
# または
nano ~/.ssh/config

以下の内容を記入：

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/github/id_ed25519
  AddKeysToAgent yes
  UseKeychain yes  # macOSの場合のみこの行を追加

# 4. configファイルのパーミッション設定
chmod 600 ~/.ssh/config

# 5. 公開鍵をクリップボードにコピー
# Mac
pbcopy < ~/.ssh/github/id_ed25519.pub

# Windows
cat ~/.ssh/github/id_ed25519.pub | clip

メリット：

一度設定すれば永続的に有効
複数のGitHubアカウントも管理可能
細かい設定が可能

デメリット：

設定が複雑
初心者には難しい

4-1-3. GitHubに公開鍵を登録

どの方法を選んでも、この手順は同じです。

GitHubにログイン
右上のプロフィールアイコン → Settings
左メニューの SSH and GPG keys
New SSH key ボタンをクリック
Title：わかりやすい名前を入力（例：My MacBook、会社PC）
Key：公開鍵を貼り付け（4-1-2でクリップボードにコピー済み）
Add SSH key ボタンをクリック

4-1-4. 接続確認

設定が正しくできているか確認します。

ssh -T git@github.com

初回接続時は以下のような警告が表示されます：

The authenticity of host 'github.com (140.82.121.4)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

→ yes と入力してEnter

成功すると以下のメッセージが表示されます：

Hi あなたのユーザー名! You've successfully authenticated, but GitHub does not provide shell access.

トラブルシューティング

うまくいかない場合の確認方法：

# 1. 詳細なエラー情報を見る
ssh -vT git@github.com

# 2. 鍵が正しく認識されているか確認（方法2, 3の場合）
ssh-add -l

# 3. パーミッションの確認
ls -la ~/.ssh/

# 正しいパーミッション：
# drwx------  (700) .ssh/
# -rw-------  (600) id_ed25519 または config
# -rw-r--r--  (644) id_ed25519.pub

よくあるエラーと対処法：

Permission denied: パーミッションを確認、鍵の場所を確認
Could not open a connection: ssh-agentが起動していない → eval "$(ssh-agent -s)"
No such file or directory: パスが間違っている、鍵が存在しない

4-2. リモートリポジトリ操作

# 基本コマンド
git remote add origin URL

# 🆕 フェッチ（安全な確認方法）
git fetch origin           # リモートの変更を取得（マージはしない）
git status                 # ブランチの状態を確認
# → "Your branch is behind 'origin/main' by 3 commits" みたいな表示が出る！

# 差分確認コマンド
git log HEAD..origin/main --oneline # リモートとローカルの差分をログで見る
# → リモートにあって、自分にない変更を表示！

git log origin/main..HEAD --oneline # 逆パターン（自分だけの変更）
# → 自分だけが持ってる変更を確認できる〜

git diff origin/main       # 詳細な差分を見る
git log --graph --oneline --all --decorate # グラフで見る

# プル（ダウンロード）
git pull origin main       # fetch + merge を一気に！

# プッシュ（アップロード）
git push origin main       # mainブランチをプッシュ
git push origin HEAD       # 現在のブランチをプッシュ（便利！）

安全な作業フロー ✨

# 📥 最新を取り込んでからプッシュする安全フロー
git fetch origin                    # ① 最新を取得
git status                          # ② 状態確認
git log HEAD..origin/main --oneline # ③ 取り込む変更を確認
git merge origin/main               # ④ マージ
git log origin/main..HEAD --oneline # ⑤ プッシュする変更を確認
git push origin HEAD                # ⑥ プッシュ！

全体の流れ

# 基本コマンド
git remote add origin URL

# 🆕 フェッチ（安全な確認方法）
git fetch origin           # リモートの変更を取得（マージはしない）
git status                 # ブランチの状態を確認
# → "Your branch is behind 'origin/main' by 3 commits" みたいな表示が出る！

# 差分確認コマンド（どっちが新しい？）
git log HEAD..origin/main --oneline # これから取り込む変更を確認
git log origin/main..HEAD --oneline # これからプッシュする変更を確認

# プル（ダウンロード）
git pull origin main       # fetch + merge を一気に！

# プッシュ（アップロード）
git push origin main       # mainブランチをプッシュ
git push origin HEAD       # 現在のブランチをプッシュ（便利！）

💡 HEAD と head の違いについて

実は小文字のheadでも動く場合があります。

Windowsの場合

大文字小文字を区別しないから head でも HEAD でも動く！
でもこれはWindowsのファイルシステムの特性

macOS（デフォルト）の場合

ファイルシステムは大文字小文字を区別しない
だから head でも動いてしまいます
デフォルトでは区別しませんが、設定により区別させることも可能です

Linuxの場合

大文字小文字を区別する！
HEAD じゃないと動かない

ファイルシステムの違い

Windows → NTFS というファイルシステム。headもHEADも同じと見なす
Mac → APFS（Apple File System 2017年以降）or HFS+（1998年〜2017年頃）。headもHEADも同じと見なす
Linux → ext4 などのファイルシステム。headとHEADは別物として扱う！

まとめ：ドキュメントでは HEAD（大文字）を使うのがベスト！

Gitの正式な仕様ではHEADが正しい
Linux環境では小文字だとエラーになる
チーム開発で環境が混在する時に問題になる

💡 git fetchとgit pullの違い

git pullは git fetch + git merge を実行しています。

他の人の変更を確認してからマージしたい時のように、安全に作業したい時は：

git fetch でリモートの変更を確認
内容を見てから git merge または git pull

git fetch origin
git log --oneline origin/main..HEAD  # 自分だけの変更を確認
git log --oneline HEAD..origin/main  # リモートだけの変更を確認
git merge origin/main  # 安全を確認してからマージ！

実践演習(例):

自分のリポジトリを GitHub に公開
有名プロジェクトのリポジトリをクローン

⚠️ gitにpushする前の重要確認

一般公開していいデータなのか？リポジトリがPublic または Privateなのかを把握してから作業することをお勧めします！

Public: 誰でも閲覧可能、機密情報は絶対にNG
Private: 自分だけや、招待されたメンバーのみアクセス可能
設定変更方法: Settings → Danger Zone → Change visibility

4-3. Pull Request 入門

PR = 「 Pull Request 」

📝 PRテンプレート例

## 変更内容
- 何をどう変えたか簡潔に

## 背景・目的
- なぜこの変更が必要だったか

## レビューポイント
- 特に見てほしい部分（性能・設計・仕様など）

## テスト
- [ ] 単体テスト完了
- [ ] 動作確認完了

## 補足
- その他の情報

4-4. GitHub の便利機能の紹介

Issues
Actions
スター機能（いいね！みたいなもの）

4-5. 質問タイム

よしなに 🥤

5: チーム開発シミュレーション 👥

目標: 実際のチーム開発の流れを体験する！

5-1. チーム開発の流れ

Git Flow / GitHub Flow
役割分担の重要性
チーム開発でのルールや注意事項
- PRの作成方法
- コミットの粒度について
- コミットのメッセージについて
- ブランチルール
- やってはいけないこと

5-2. 実践プロジェクト

ミニプロジェクト:

2〜3人でチーム結成
各自がブランチで担当ページ作成
Pull Request でレビュー
マージして完成！

5-3. よくあるトラブルと対処法

間違えてコミットしてしまった時(pushはしていない時)
```
git reset --soft HEAD^
```
ファイルを間違えて変更した時
```
git restore ファイル名
```

間違ったブランチで作業していた時

git stash  # 一時保存git switch 正しいブランチ  # 移動git stash pop  # 復元

プッシュ済みを取り消したい

⚠️ 履歴を書き換えるため、チームで相談してから実行しましょう

5-4. さらに便利に

.gitignore を使用してGit管理したくないファイルを管理

.gitignoreの例

.DS_Store
.env
node_modules/

aliasを使用してGitコマンドを省略

vim ~/.gitconfig

[commit]
        template = /Users/your-user-name/.commit_template
[user]
        name = Nanashi
        email = your.email@example.com
[alias]
        st = status
        cm = commit
        c = checkout
        sts = status --short
        push-f = push --force-with-lease                                                                                                                      9,25         全て

templateの設定は.commit_template に記載した内容を git commit 実行時に表示してくれるようになります。

.commit_templateの例

# 🚑  :ambulance: バグ修正
# 👍  :+1: 機能改善
# ✨  :sparkles: 部分的な機能追加
# 🎉  :tada: 盛大に祝うべき大きな機能追加
# ♻️  :recycle: リファクタリング
# 🚿  :shower: 不要な機能・使われなくなった機能の削除
# 💚  :green_heart: テストやCIの修正・改善
# 👕  :shirt: Lintエラーの修正やコードスタイルの修正
# 🚀  :rocket: パフォーマンス改善
# 🆙  :up: 依存パッケージなどのアップデート
# 🔒  :lock: 新機能の公開範囲の制限
# 👮  :cop: セキュリティ関連の改善
# 🛀  :bath: ソースコードをきれいにしたとき
# 🔨 :hammer: ビルドしたときのファイル群
# ✏️  :pencil2: ドキュメントの追加・変更
# 💎 :gem: Gemの追加

作業中のファイルをコミットはせず、記録しておきたい時

git stash

git stash save
git stash pop

コミット履歴の整理

# コミット履歴を書き換えることができるので取り扱い注意。 リモートへプッシュしていないコミットの整理に使用
git rebase

差分を比較

git diff --cached

5-5. 質問タイム

よしなに ☕️

📚 まとめ

🎯 Git研修で身につくスキル

この研修を通じて、以下のスキルが身につきます

✅ バージョン管理の基礎概念を理解し、なぜGitが必要かを説明できる
✅ 基本的なGitコマンド（add, commit, push, pull）を使いこなせる
✅ ブランチ操作を使った並行開発ができる
✅ コンフリクト解決の手順を理解し、実践できる
✅ GitHubを使ったリモート作業とチーム開発ができる
✅ SSH鍵の設定と接続確認ができる
✅ Pull Requestを使ったコードレビューフローを理解できる

📝 最初の設定（初回のみ）

git config --global user.name "あなたの名前"
git config --global user.email "your.email@example.com"

🎮 基本操作

リポジトリ作成・初期化

git init                    # 新しいリポジトリを作成
git clone URL              # 既存のリポジトリをコピー

ファイル操作の基本フロー（3ステップ）

# 1. ワーキングディレクトリで編集
# 2. ステージングに追加
git add ファイル名          # 特定のファイルをステージング
git add .                   # 全ての変更をステージング
# 3. リポジトリに記録
git commit -m "メッセージ"  # コミット（セーブポイント作成）
git push origin main        # リモートにアップロード

状態確認

git status                  # 現在の状態を確認
git log --oneline          # コミット履歴を簡潔に表示
git diff                    # 変更内容を確認

🌿 ブランチ操作（2019年以降推奨）

ブランチの基本

git branch                  # ブランチ一覧を表示
git branch 新ブランチ名      # 新しいブランチを作成（切り替えなし）
git switch ブランチ名        # ブランチを切り替え ⭐新コマンド
git switch -c 新ブランチ名   # 作成と同時に切り替え ⭐新コマンド

マージとコンフリクト解決

git merge ブランチ名         # 指定ブランチを現在のブランチに統合

# コンフリクト発生時の対処
# 1. ファイルを編集してコンフリクトマーカーを削除
# 2. git add で解決をマーク
# 3. git commit でマージ完了

🔄 リモート操作（GitHub連携）

SSH接続の設定（重要！）

# SSH鍵の生成
ssh-keygen -t ed25519 -C "your.email@example.com"
# GitHubに公開鍵を登録後、接続確認
ssh -T git@github.com

安全な更新フロー ✨

# 1. リモートの変更を確認
git fetch origin            # 変更を取得（マージはしない）
git status                  # 状態確認

# 2. 差分を確認
git log HEAD..origin/main --oneline  # 取り込む変更を確認
git log origin/main..HEAD --oneline  # プッシュする変更を確認

# 3. マージまたはプル
git merge origin/main       # 確認後にマージ
# または
git pull origin main        # fetch + merge を一気に実行

プッシュ

git push origin main        # mainブランチをプッシュ
git push origin HEAD        # 現在のブランチをプッシュ（便利！）

🔧 変更の取り消し（2019年以降推奨）

ファイルを戻す ⭐新コマンド

git restore ファイル名                # 作業ツリーのファイルを復元
git restore --staged ファイル名       # ステージングから削除

コミットの取り消し

git reset --soft HEAD^      # 直前のコミットを取り消し（変更は残る）
git reset --hard HEAD^      # 直前のコミットを完全に取り消し（危険！）
git commit --amend         # 直前のコミットメッセージを修正

🆘 よくあるトラブル対処法

間違ったブランチで作業してた！

git stash                   # 変更を一時保存
git switch 正しいブランチ     # 正しいブランチに移動
git stash pop              # 変更を復元

pushできない（リモートが更新されてる）

git pull origin main        # 最新を取り込む
git push origin main        # 再度プッシュ

コンフリクトが発生！

# 1. 手動でファイルを編集して解決
# 2. 解決したらaddしてcommit
git add 解決したファイル
git commit -m "[merge] コンフリクトを解決"

📋 コミットメッセージ規約

[add]      機能追加
[update]   機能更新
[fix]      バグ修正
[remove]   削除
[refactor] リファクタリング
[test]     テスト追加・修正
[docs]     ドキュメント更新
[merge]    マージ時

例

git commit -m "[add] ユーザー認証機能を追加"
git commit -m "[fix] ログイン時のエラーを修正"

🎯 状況別クイックリファレンス

やりたいこと	コマンド
現在の状態を見る	`git status`
変更を確認	`git diff`
履歴を見る	`git log --oneline`
ブランチを変える	`git switch ブランチ名`
変更を取り消す	`git restore ファイル名`
リモートを更新	`git pull origin main`
作業を一時保存	`git stash`
一時保存を復元	`git stash pop`

💡 便利な Tips

グラフで履歴を見る

git log --graph --oneline --all --decorate

.gitignoreの基本

# ファイルに以下を記述
node_modules/     # フォルダを無視
*.log            # 拡張子で無視
.env             # 特定ファイルを無視
.DS_Store        # macOSのシステムファイル

エイリアスで効率化

# ~/.gitconfigに設定
[alias]
    st = status
    cm = commit
    c = checkout
    sts = status --short

⚠️ 新旧コマンド対応表

用途	旧（checkout）	新（switch/restore）
ブランチ切り替え	`git checkout ブランチ名`	`git switch ブランチ名`
ブランチ作成+切替	`git checkout -b 新ブランチ`	`git switch -c 新ブランチ`
ファイル復元	`git checkout -- ファイル名`	`git restore ファイル名`
ステージング解除	`git reset HEAD ファイル名`	`git restore --staged ファイル名`

なんで変わったの？

git checkoutは万能すぎて分かりにくかったため

git checkout ブランチ名      # ブランチ切り替え
git checkout -b 新ブランチ   # ブランチ作成
git checkout -- ファイル名   # ファイル復元
git checkout コミットID     # 特定コミットに移動

✨ 役割分担した！

# 🆕 新コマンドは役割がハッキリ！
git switch ブランチ名        # ← ブランチ切り替え専用
git switch -c 新ブランチ     # ← ブランチ作成専用
git restore ファイル名       # ← ファイル復元専用

🌟 覚える優先順位

1️⃣ 最優先

git add .
git commit -m "メッセージ"
git push origin main
git pull origin main
git status

2️⃣ 次に覚える

git switch ブランチ名
git switch -c 新ブランチ
git log --oneline
git fetch origin
git restore ファイル名

3️⃣ 実務で使うと便利

git stash / git stash pop
git diff
git merge
git commit --amend
.gitignoreの設定

TODO

1. Gitの概念を図で表したものを追加する
2. 各セクションに「つまずきポイント」を追加 (初心者が陥りやすいミスと対処法など)
3. Githubのアカウント作成やSSH鍵の登録で画像を追加してわかりやすさを向上させる
4. 実務でよく使うオプション集を追加
5. 演習の解答例を追加 (実践演習の具体的な手順)
6. コミットから差分を抽出する方法　（FTPでアップする必要のある案件で便利）

終わりに

まだまだ書ききれないことがありますが、ひとまずこれで実施してみて改善を重ねていこうと考えています...!