はじめに
この記事は「これまでGitに触れる機会がなかった方へ、Gitについて教えてほしい」と頼まれた方向けの記事です。
いざ資料を作成する時に何から伝えればいいんだろう🤔と感じたため、同じ境遇の方への参考資料として残しております。
📖 目次
研修ステップ
-
- バージョン管理の概念を理解
- Gitの必要性を学ぶ
- 環境構築（Mac/Windows）
- 初期設定
-
- リポジトリの概念を理解
- 基本コマンド実践（add, commit, status, log）
- コミットメッセージの書き方
- Git管理の仕組み（ワーキング/ステージング/リポジトリ）
-
- ブランチの概念（パラレルワールド）
- ブランチ操作（作成・切り替え・マージ）
- コンフリクト解決の実践
-
- GitとGitHubの違い
- GitHubアカウント作成
- SSH鍵の設定（3つの方法を詳しく解説）
- リモートリポジトリ操作（push, pull, fetch）
- Pull Request入門
-
- チーム開発の流れ（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 maingit pull origin maingit status
2️⃣ 次に覚える
git switch ブランチ名git switch -c 新ブランチgit log --onelinegit fetch origingit restore ファイル名
3️⃣ 実務で使うと便利
-
git stash/git stash pop git diffgit mergegit commit --amend-
.gitignoreの設定
TODO
1. Gitの概念を図で表したものを追加する
2. 各セクションに「つまずきポイント」を追加 (初心者が陥りやすいミスと対処法など)
3. Githubのアカウント作成やSSH鍵の登録で画像を追加してわかりやすさを向上させる
4. 実務でよく使うオプション集を追加
5. 演習の解答例を追加 (実践演習の具体的な手順)
6. コミットから差分を抽出する方法 （FTPでアップする必要のある案件で便利）
終わりに
まだまだ書ききれないことがありますが、ひとまずこれで実施してみて改善を重ねていこうと考えています...!