PMOの職種だと、Gitを普段使う機会はなくエンジニアにIssueを作成するくらいですが、現場の会話を踏まえて勉強メモとしてストーリーを作ってみました。
◎会話内で出てきた用語は、一番最後の表に記載
登場人物
開発リーダー（リーダー）
新人エンジニア（新エンジニア）
Step.1:Gitを導入する
新しいプロジェクトの立ち上げにあたり、チームでのコード管理方法を話し合っていた。
（リーダー）：「チーム開発を効率化するために、Gitを使おう。Gitはバージョン管理のためのツールで、変更履歴を管理しチームでスムーズに開発できるんだ。」
（新エンジニア）：「実は経験がなくて…」
（リーダー）：「心配しなくていいよ。まずはGitのインストールから始めよう。」
brew install git //Macのみ Windowsは公式からDL
git --version //Gitのバージョンを確認
（リーダー）：「次に、ユーザー情報を設定しよう。」
git config --global user.name "Your Name" //ユーザー名を設定
git config --global user.email "your.email@example.com" //メールアドレスを設定
Step.2:リポジトリの作成とブランチ運用
（リーダー）「まずは、作業用ディレクトリを作って、その中でGitリポジトリを作ろう。」
//プロジェクト用ディレクトリを作成
mkdir ~/projects
cd ~/projects
//プロジェクトフォルダを作成
mkdir my-project
cd my-project
//Gitリポジトリを作成し、最初のブランチを'main'に設定
git init --initial-branch=main
（新エンジニア）：「チームと共有するために、リモートリポジトリも作成しました。」
//新しいローカルリポジトリの作成
git remote add origin https://github.com/your-username/your-repo.git
Step.3:ブランチを活用した開発
（リーダー）：「ブランチを作って、機能ごとに開発しよう。」
git branch feature-login //mainブランチを基準に、新しいブランチを作成
git checkout feature-login //作成したブランチに切り替え
Step.4:コミットとプッシュ
（新エンジニア）：「HTMLの更新が終わりました。変更をGitに記録するにはどうしたらいいですか？」
git add . //変更をステージングエリアに追加
git commit -m "ログイン機能を追加" //変更をコミット（記録）
（リーダー）：「コミットしたら、リモートリポジトリに送ろう。」
git push origin feature-login //リモートに変更をプッシュ ``feature login``は任意の名前
※本投稿では省略していますが、GitHubにプッシュするときは、SSHキーやトークン認証が必要です。
Step.5:マージとコンフリクト対応
（リーダー）：「機能が完成したら、メインブランチに統合しよう。」
//最新のmainブランチを取得
git checkout main
git pull origin main
（新エンジニア）：「では、feature-loginを統合します。」
git marge feature-login //ブランチを統合
（新エンジニア）：「コンフリクトが...発生しました！」
（リーダー）：「大丈夫。コンフリクトの解決手順はこうだよ。」
//1.他にもコンフリクトしているファイルがないか確認
git status
//2.該当ファイル（例: index.html）を開き、衝突している部分を手動で修正
// <<< HEAD や >>> の間にある変更を整理する
//3.修正が終わったら、変更をステージングエリアに追加
git add index.html
//4.修正を確定するために、新しくコミットを作成
git commit -m "コンフリクト解決"
//5.最後にリモートにプッシュ
git push origin main
その他、コンフリクトを避けるプラクティス
1️⃣ コンフリクトは手動で解決する
2️⃣ git pull origin main をこまめにやると防げる
3️⃣ 同じファイルの同じ行を編集しないようにする
4️⃣ プルリクエストを使うと、チームで安全にマージできる
→→ エンジニアが実装した画面レビューを担当していたのですが、
プルリクしました〜の背景がわかってなく、こういう理由だからかと納得しました...
Step.6:履歴の管理とリベース
（新エンジニア）：「過去の変更履歴を確認したいときはどうしたらいいですか」
（リーダー）：「git logを使うとこれまでの履歴が見られるよ」
git log --online --graph
表示される履歴（例）
* abc1234 (HEAD -> main) Fix login bug //mainの最新
* def5678 Add new user registration //1つ前のコミット、新規登録機能追加
* ghi9101 Initial commit //最初のコミット。リポジトリの初期状態
（新エンジニア）：「今の履歴が前の状態とどう違うか知りたいのですが..」
（リーダー）：「git giffを使えば、変更点がわかるよ」
git giff
変更点
- <p> こっちが古いコード </p>
+ <p> こっちが新しいコード </p>
git rebase mainを実行すると、feature-branchのコミットが、最新の状態に積み直される。
Step.7:最終チェックとリリース準備
（リーダー）：「最終チェックをしよう」
git status //現在の状態を確認
不要な変更があればリセットする
//最新の1つ前のコミットに戻し、変更を完全に削除
git reset --hard HEAD~1
一連の流れ
流れ
git init //新しいリポジトリを作成
git remote add origin <リモートURL> //リモートリポジトリを登録
git checkout -b feature-branch //作業ブランチを作成して切り替え
git pull origin main //リモートの最新変更を取得）
（git branch -M main） //（デフォルトブランチをmainに変更）
git add . //変更をステージングエリアに追加
git commit -m "作業内容" //変更をローカルに記録
git push origin feature-branch //作業ブランチの変更をリモートにプッシュ
（プルリクエストを作成） //(GitHubでコードレビューのためのPRを出す）
git checkout main //メインブランチに移動
git pull origin main //最新の変更を取得
git merge feature-branch //作業ブランチの変更を統合
（git rebase main） //（履歴を整理する場合にリベースを実行）
git push origin main //mainブランチの変更をリモートにプッシュ
（git branch -d feature-branch） //（ローカルの作業ブランチを削除）
（git push origin --delete feature-branch） //（リモートの作業ブランチを削除）
| コマンド | 意味 |
|---|---|
git init |
新しいローカルリポジトリを作成 |
git remote add origin <URL> |
リモートリポジトリを登録 |
git checkout -b feature branch |
新しいブランチを作成し、切り替え |
git pull origin main |
リモートの最新変更を取得しローカルに反映 |
git branch -M main |
デフォルトブランチをmainに変更 |
git add . |
変更をステージングエリアに追加 |
git commit -m "メッセージ" |
変更をローカルリポジトリに記録 |
git push origin feature-branch |
作業ブランチをリモートにプッシュ |
git checkout main |
メインブランチに切り替え |
git merge feature-branch |
作業ブランチの変更をmainに統合 |
git branch -d feature-branch |
ローカルの作業ブランチを削除 |
git push origin --delete feature-branch |
リモートの作業ブランチを削除 |
git status |
作業ツリーの状態を確認 |
git log --oneline --graph |
コミット履歴を簡潔に表示 |
git log --name-only |
各コミットで変更されたファイルを表示 |
git stash |
作業中の変更を一時保存 |
git stash pop |
一時保存した変更を復元 |
git push --force |
git rebase などで書き換えた履歴をリモートに上書き |