RareTECH受講生のsayagonです。
１年ほどGitに触れていなかったので復習がてら調べて見ました。
※注意点
Git 2.23以降、git checkoutコマンドの非推奨化
→git switchやgit restoreの使用が推奨されています。
私の知識が古かった為、順次変更して行きますので少々お待ちください
📌 Gitの基本用語集
🔹 基本知識
| 用語 | 意味 |
|---|---|
| Git | ファイルの状態を更新履歴として保存できるツール |
| リポジトリ | Gitで管理したいディレクトリ |
| リモートリポジトリ | サーバ上にあるリポジトリ（GitHub など） |
| ローカルリポジトリ | 自分のPCにあるリポジトリ |
| ステータス | 変更内容を確認するコマンド（git status） |
| プル (git pull) | リモートリポジトリの最新の変更をローカルに取り込む |
| クローン (git clone) | リモートリポジトリをローカルにコピーする |
| コミット（git commit） | ローカルの変更を記録 |
| プッシュ (git push) | ローカルの変更をリモートにアップロード |
| プルリクエスト（PR） | 修正内容をリモートでレビュー依頼する |
| リセット (git reset) | コミットを取り消す（扱い要注意） |
| リバート (git revert) | コミットを取り消した内容を新たなコミットとして記録 |
| ワークツリー | 作業しているファイルがある場所 |
| インデックス | コミットするファイルを登録するステージング領域 |
| ハンク | 変更の一部分（Git では変更範囲を指す） |
🔹 ブランチ管理
| 用語 | 意味 |
|---|---|
| ブランチ | 変更履歴の分岐。機能ごと・リリースごとに管理する |
| メインブランチ (main) | 安定したリリース版が管理されるブランチ |
| 開発ブランチ (develop) | 新機能の開発が進められるブランチ |
| 機能ブランチ (feature) | 個別の機能開発用のブランチ |
| リリースブランチ (release) | バグ修正やドキュメントの整備、コードの最終的な調整を行うブランチ |
| ホットフィックス (hotfix) | 緊急修正用のブランチ |
命名規則
ブランチを切る際に命名規則っていうものがあるのは、知りませんでした。
いつも自分の名前で切って開発が終わるまでずっと使い続けていましたし。ハッカソンが終わった今でもブランチ残ったままですが。。
| ブランチ名 | 用途 |
|---|---|
| feature/login-ui | ログイン画面のUI開発 |
| feature/add-payment | 支払い機能を追加 |
| fix/bug-1234 | バグ修正（バグID: 1234） |
| hotfix/security-issue | 緊急のセキュリティ修正 |
📌 Gitの基本的な操作イメージ
※こちらはR５年春の応用情報技術者試験で出されたブランチの樹形図です。レビューの回数がものすごく少ないですが、試験問題用に簡略化されているからなので、現場ではもっとレビューが多くなると思われます。
例えば、上記の図を使って以下のような運用イメージを考えます：
- main = 実際に運用中のアプリ
- develop = 次回アップデート予定の格納庫
- feature = 担当別作業
- release = バグ修正やドキュメントの整備、コードの最終的な調整を行うブランチ
mainブランチは本番環境にデプロイされるブランチなので、誤って変更を加えないように注意する必要があります。そこで、mainブランチをクローンして、developブランチに格納することで、安全に開発作業を進めることができます。
次に、developには完了した内容を順次追加したいので、各作業ごとにfeatureブランチを作成します。このようにすることで、developブランチには承認済みの変更のみが格納され、安定した開発環境を維持できます。
作業が順調に進み、featureブランチでの作業が完了した後、その変更はdevelopブランチにマージします。このマージ操作を行うことで、developには新しい機能や修正が統合され、次のリリースに向けた準備が整います。
*** 
重要***
featureブランチの変更がdevelopブランチにマージされる前に、必ずコードレビューとテストが行われることです。このプロセスにより、バグや問題を早期に発見することができ、品質の高いコードを保つことができます。
また、releaseブランチは、次回のリリースに向けて最終的な調整を行う場所です。developブランチからreleaseブランチを切り出し、最終的なバグ修正や調整を行います。releaseブランチが完成すると、最終的にdevelopブランチとmainブランチにマージされ、実際の運用環境にデプロイされます。
何故releaseブランチが完成したらdevelopブランチとmainブランチにマージするのか
リリースする内容だけがdevelopブランチ入っているわけではありません！
develop は、どんどん開発が進んでいるブランチなので、releaseで行ったバグ修正や最終調整の内容をdevelopに戻さないと、次回のリリース時に再度同じバグが発生する可能性があります。
この流れを繰り返すことで、継続的にアプリケーションのアップデートが行われ、安定した運用が実現されます。
CI/CD（継続的インテグレーション/デリバリー）の導入などもありますが、ここでは取り上げません。
📌 Gitの基本的な操作の手順
1. リポジトリのクローン
最初にリポジトリを自分のPCにクローンします。これにより、作業を行うためのローカルコピーが手に入ります。
git clone <リポジトリのURL>
2. ブランチの確認と切り替え
Gitでは、main、develop、feature など、複数のブランチを使って作業を分けます。まずは、作業したいブランチに切り替えます。
現在のブランチの確認方法
作業中のブランチを確認するには、以下のコマンドを使います。
git branch # 現在のブランチが表示される
または、git statusコマンドでも確認できます。On branch <branch-name>という部分に現在のブランチ名が表示されます。
git status
確認後、developブランチにいない場合は、以下で切り替えます。
git checkout develop # 例えばdevelopブランチに切り替え
developブランチがない場合、developブランチを作成します。
git checkout -b develop # developブランチを作成
git push origin develop
3. ローカルリポジトリの最新化
他の人が変更を加えている可能性があるため、ローカルリポジトリを最新の状態に保つことが重要です。git pullコマンドを使って、リモートの最新の変更をローカルに反映させます。
git pull origin develop # developブランチの最新変更を取得
これにより、ローカルリポジトリがリモートリポジトリと同期されます。
4. 変更内容の確認
他の人が行った変更や、ローカルの変更を確認するためには以下のコマンドを使います。
変更内容の確認方法
- 変更されたファイルの確認: ローカルで変更されたファイルを確認するには、次のコマンドを使います。
git status # 変更されたファイルを表示
- 具体的な変更内容の確認: 各ファイルで行われた変更を確認するには、以下のコマンドを使います。
git diff # どのような変更が行われたのか確認するためのコマンド
これにより、まだコミットしていない変更の内容が表示されます。
5. ブランチの作成
新たに作業を行いたい場合、featureブランチを作成します。作業内容に応じて名前を付けるのが一般的です。
git checkout -b feature/xxxx # featureブランチを作成して切り替え
✅ チームで作業する場合のブランチ名
チームで開発していて「誰がどの機能を担当しているかを明確にしたい」場合、ブランチ名に名前を加えることもあります。例えば：
-
feature/taro-login-ui→ 太郎さんがログインUIを担当 -
fix/hanako-bug-5678→ 花子さんがバグ修正（ID 5678）
ただし、通常は 機能ごとに統一した命名規則（例: feature/〇〇）を使うことが推奨 されますとのことですが、現場の方針に合わせましょう😊
6. 変更の編集とコミット
必要な変更をローカルで行い、変更内容をステージしてコミットします。変更内容をコミットすることで、作業の履歴を保存できます。
git add . # 変更内容をステージング
git commit -m "作業内容の説明" # 変更をコミット
7. リモートリポジトリへのプッシュ
ローカルでの作業が完了したら、リモートリポジトリに変更を反映させるためにプッシュします。
git push origin feature/xxxx # リモートのfeatureブランチにプッシュ
8. Pull Request (PR) の作成
GitHubやGitLabなどのプラットフォームでは、作業が完了した後、featureブランチをdevelopブランチにマージするためのPull Request（PR）を作成します。
Pull Requestでは開発した機能や変更点などを明記し、チームの仲間にapprove（承認）してもらうことでfeatureブランチをdevelopブランチにマージします。
※注意点
ここのやり方がちょっとうろ覚えです。
GitHubの画面からリクエストを出していたような気がします。
また、承認がおりると勝手にマージされていたような気もします。
9. PRのマージ
コードレビューが完了したら、developブランチにマージします。マージが完了したら、featureブランチは削除しても構いません。
git checkout develop # developブランチに切り替え
git pull origin develop # 最新の状態に更新
git merge feature/xxxx # featureブランチをマージ
10. 本番環境へのデプロイ
developブランチが安定したら、いよいよmainブランチにマージします。これが実際にお客様への提供を意味します。
git checkout main # mainブランチに切り替え
git pull origin main # 最新の状態に更新
git merge develop # developの変更をmainにマージ
git push origin main # mainブランチをリモートにプッシュ
この流れを繰り返すことで、開発を効率よく進められます。また、他の人が行った変更や、ローカルの変更内容を必ず確認し、作業中に最新の状態を保つことが重要です。mainブランチに誤って変更を加えないよう、developやfeatureブランチでしっかりと作業を管理しましょう。
📌 よくあるGitのエラーと解決方法
❌ git pull エラー
error: Your local changes to the following files would be overwritten by merge:
🔹 原因: ローカルの変更がリモートと競合
🔹 解決方法:
git stash # 変更を一時保存
git pull # 最新の状態を取得
git stash pop # 一時保存した変更を戻す
❌ git push エラー
error: failed to push some refs to 'リモートリポジトリURL'
🔹 原因: 他の人の変更がリモートにあり、競合している
🔹 解決方法:
git pull --rebase # 最新の変更を適用
git push # 再度プッシュ
❌ git merge エラー
error: Merging is not possible because you have unmerged files.
🔹 原因: 競合が発生し、マージできない
🔹 解決方法:
# 競合を解決し、変更をコミット
git add <競合したファイル>
git commit -m "Conflict resolved"
📌 まとめ：Gitのワークフロー
✅ 1. クローンする（git clone）
✅ 2. ブランチを作成し切り替え（git checkout -b）
✅ 3. ファイルを変更＆ステージング（git add）
✅ 4. コミットする（git commit）
✅ 5. リモートにプッシュ（git push）
✅ 6. GitHub でプルリクエスト作成
✅ 7. マージして統合
✅ 8. 最新の状態を取得（git pull）
このサイクルを繰り返すことで、スムーズにGitを活用できます！🚀
🔹 誰が変更したかわかるのか？
Gitでは 誰がどの変更をしたのか履歴に記録される ので、ブランチ名に名前を入れなくても追跡できます。
1️⃣ 変更者を確認する（git log）
git log --oneline --author="名前"
→ 指定した名前の人が行ったコミットだけを表示できます。
または、すべてのコミットを見たい場合：
git log --oneline --decorate --graph --all
→ すべてのブランチの履歴を、グラフィカルに確認できます。
2️⃣ 変更履歴を詳細に見る
git blame ファイル名
→ そのファイルの各行が「誰によって、いつ変更されたのか」を表示します。
🔹 ブランチを削除するべきか？
✅ 1️⃣ 不要なブランチが増えすぎるのを防ぐ
残ったブランチが多いと、どれが現在進行中かわからなくなる
ずっと残しておくと「このブランチってもういらないよね？」と迷うことに
✅ 2️⃣ 誤って古いブランチで作業を始めるのを防ぐ
例えば、新しい feature/login-ui-v2 を作ったのに、古い feature/login-ui が残っていたら、間違えてそっちを使うかもしれない
✅ 3️⃣ チーム開発の整理整頓
GitHub上のブランチ一覧がスッキリする
どのブランチがまだ作業中で、どれが完了したのかが明確になる
🔹 ブランチ削除の手順
1️⃣ ローカルブランチを削除（自分のPCから）
git branch -d feature/xxx
→ マージされていないとエラーが出るので、強制削除したい場合は -D
git branch -D feature/xxx
→ でもGitHub上（リモート）にはまだ残ってる！
2️⃣ リモートブランチを削除（GitHubから）
git push origin --delete ブランチ名
→ 例: git push origin --delete feature/login-ui
→ これをやらないと、GitHub上にブランチが残り続けます。
🔹 まとめ
✅ マージしてもリモートブランチは自動削除されない！
✅ 作業が完了したら、担当者が不要なブランチを削除する
✅ リモートにブランチを残しておくと管理が大変なので、削除した方がいい
✅ ローカルとリモートはちゃんと分けて考えるのが大事