■ コンフリクトを防ぐための基本
Git でコンフリクトが発生するのは避けられない。
しかし、発生頻度は明らかに減らせる。
防止策
- 複数人で同じファイルを同時に変更しない
- Pull / Merge を行う前に、作業中の変更を無くす（commit or stash）
- Pull は必ず Pullしたいブランチに checkout してから 行う
- コンフリクトしても慌てない
→ 差分確認をすれば必ず解消できる
■ ブランチ操作の基本
ブランチ名を変更する
git branch -m <new-name>
ブランチを削除する
git branch -d <branch> # マージ済みなら削除
git branch -D <branch> # 強制削除
運用の基本
- main（master）は常にデプロイ可能な状態を維持する
- 開発は 必ずトピックブランチで実施する
■ リモートブランチとは何か？
ローカル側に保存されている
「リモートリポジトリのブランチ状態へのポインタ」 のこと。
例：
remotes/origin/main
remotes/origin/feature
これはローカルの作業用ブランチではないため、直接 checkout すると detached HEAD になる。
■ プルリクエストとは？
自分が変更した内容をリポジトリへ取り込んでもらうための仕組み。
- 差分の確認
- レビュー
- ディスカッション
- マージ
この流れを正式に行うのがプルリクエスト。
■ GitHub Flow とは？
GitHub 社が採用している開発ワークフロー。
単純で覚えやすく、小規模〜中規模開発に向いている。
GitHub Flow のルール
- main は常にデプロイ可能
- 新機能は main からブランチを切って開始
- 作業ブランチでコミットし、適宜 push
- main に取り込むときは必ずプルリクエストを出す
- レビューを受けてから merge
- merge したらすぐデプロイ（テスト・デプロイは自動化が前提）
■ リベース（rebase）とは？
変更を統合しつつ、履歴をきれいに整えるための操作。
履歴の見通しがよく、コミットログが読みやすくなる。
基本コマンド
git rebase <branch>
きれいな rebase の流れ
git checkout feature
git rebase main
git checkout main
git merge feature
これで分岐していた履歴が一直線になる。
■ リベースの注意点
- GitHub に push 済みのコミットに対して rebase は NG
- git push -f は基本禁止（他人の履歴を破壊する）
- 履歴を書き換えるのは、ローカルでしか使わないブランチだけにする
■ リベースとマージの使い分け
マージ（merge）
- コンフリクト解決が簡単
- マージコミットが増えて履歴が複雑になりがち
リベース（rebase）
- 履歴がきれい
- コミット単位でコンフリクト解消が必要で手間
結論
- push していないローカルなら rebase
- push 済みのブランチは merge
- コンフリクトが起きそうなら merge
■ git pull の種類（マージ型・リベース型）
マージ型
git pull origin main
- マージコミットが残る
- “マージした証跡” を残したい場合に使う
リベース型
git pull --rebase origin main
- 履歴がきれいなまま
- GitHub の最新状態を取り込みたいだけならこちら
デフォルトをリベース型にする
git config --global``` pull.rebase true
main ブランチだけ変更したい場合：
git config branch.main.rebase true
■ rebase -i（履歴の書き換え）
直前のコミットを修正
git commit --amend
複数コミットを修正
git rebase -i <commit-id>
流れ
1.git rebase -i で対話モードに入る
2.修正したいコミット行を edit に変更
3.そのコミットで適用が止まる
4.git commit --amend で修正
5.git rebase --continue
6.pick → 適用
drop → 削除
squash → 直前のコミットにまとめる
■ HEAD~ と HEAD^ の違い
HEAD~
メインの履歴をまっすぐ遡る。
HEAD^
マージコミットで “親番号” を指定する。
- HEAD^1 → 親1（メイン側）
- HEAD^2 → 親2（マージしてきた側）
■ コミット操作
並び替え / 削除
git rebase -i HEAD~3
表示された行を並べ替えたり削除すればよい。
squash（まとめる）
git rebase -i HEAD~3
squash を指定すると直前のコミットと結合する。
コミットの分割
git rebase -i HEAD~3 # edit を設定
git reset HEAD^
git add <file1>
git commit -m "file1修正"
git add <file2>
git commit -m "file2修正"
git rebase --continue
■ タグ（tag）
一覧
git tag
作成
annotated タグ：
git tag -a <tag> -m "<message>"
lightweight タグ：
git tag <tag>
確認
git show <tag>
push
git push origin <tag>
まとめて push
git push origin --tags
■ stash（作業の一時退避）
作成
git stash
一覧
git stash list
復元
git stash apply
git stash apply --index
特定を復元
git stash apply stash@{n}
削除
git stash drop
git stash drop stash@{n}
git stash clear
■ まとめ
Git の本質は「履歴をどう扱うか」。
rebase・merge・stash・タグなどは目的が違うだけで、
自分が今どういう状態にいるのか理解して使えば問題は起きない。だけどその状態を理解するまでに量をこなさなければ理解できないと思うのでこれから自分でGitを触っていかなければいけないとさらに強く思いました。