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 などで書き換えた履歴をリモートに上書き