業務でよく使う git 操作

概要

git 操作のチートシートです。
業務でよく使う操作を、目的別に記載しています（不定期に更新予定）。

期待する読者
- 目的からの逆引きで、git 操作を探したい方
- 実際の業務において、どんな git 操作をよく使うのか知りたい方
前提
- git レポジトリに移動している前提でコマンドを記載します
- Linux コマンドラインでの操作 を記載しています（エディタの操作には触れません）
- コミットの編集操作については、PUSH 前の状態 を想定して書いています（基本 force push はしません）
- あくまで、業務での活用事例をもとに書いています
  なので、俗にいう 教科書通りではない 操作も出てきます
検証した環境
- Rocky Linux 8
- git サーバは Gitlab を使用

コミット操作

コミット済みのコメントを修正する

活用シーン
- コミットの文言を間違えたので、修正したいとき
  - 急いでいて間違えたり、issue 番号の記載を忘れた時、など
コマンド
補足
1世代前のコミットの修正だけなら、amend だけでもOK
1. 修正を始める　＝＞エディタが開く
```
git commit --amend
```
2. コミットを修正する

コミット済みのコメントの、作業者名（Author）を修正する

活用シーン
- コミットの作業者名を間違えたので、修正したいとき
  - 特に、git config の user.name の指定を忘れて、デフォルト名や無記名で登録されてしまった場合の対処
- 基本的な手順は前述の「コミット済みのコメントを修正する」と同じなので、一部割愛します
コマンド
1. リベースする　＝＞コミット一覧の編集画面が開く
```
git rebase -i リビジョン
```
2. コミット文言を修正したいコミットの pick 部分を、edit に書き換える
3. 修正を始める　＝＞エディタが開く
```
git commit --amend --author="作業者名 <作業者のアドレス>
```
  - 作業者名: 正しい作業者名を記載する (例: hanzo-k)
  - 作業者のアドレス: 正しいメールアドレスを記載する (例: hanzo-k@example.com)
4. コミットを修正する
5. リベース処理を再開する
```
git rebase --continue
```

コミットを1つに統合する

活用シーン
- 細かい修正のコミットをたくさん作ってしまい、1つに集約したい
  - テストやレビューで修正コミットが乱立した場合など
- 異なる修正であれば、統合しない方がレビュアーにとって見やすい場合もある
コマンド
1. リベースする　＝＞コミット一覧の編集画面が開く
```
git rebase -i リビジョン
```
  - リビジョン: HEAD~ ＋直したいコミットの世代数
2. 一番下にあるコミット（最新）の pick 部分を、squash に書き換える　＝＞エディタが開く
```
pick 123456a コミットメッセージA
pick 123456b コミットメッセージB
↓
pick 123456a コミットメッセージA
squash 123456b コミットメッセージB
```
3. コミットを修正する
  以下のように、コメント付きで今までのコミットが列挙されるので、よしなに修正する
```
# This is a combination of 2 commits.
# This is the 1st commit message:

コミットメッセージA

# This is the commit message #2:

コミットメッセージB
```
  - Successfully rebased and updated ～ と出たら完了

ブランチ操作

新規ブランチを作りながらチェックアウトする

活用シーン
- 新規ブランチを作りつつ、そのブランチに切り替えたい場合
- 普通にやると、ブランチ作成＞チェックアウトの2操作必要なので、意外と重宝
コマンド
1. 派生元のブランチをチェックアウトする（main など）
```
git checkout 派生元のブランチ名
```
2. 新規ブランチを作りながらチェックアウトする
```
git checkout -b 新規ブランチ名
```

ローカルのブランチを消す

活用シーン
- 不使用の過去ブランチを消したい
  - リモートのブランチは消えないのでご安心
- 間違えて作ったブランチを消したい
コマンド
1. ローカルのブランチを消す
```
git branch -D ブランチ名
```
  - ブランチ名: 消したいローカルブランチ名
補足
現在ローカルにあるブランチを知るには？
1. ローカルのブランチ一覧を表示する
```
git branch
```
リモートのブランチを消す場合
gitlab などの UI から、古いブランチ（Stale branches など）だけを消した方が、事故を防げる

マージ、リベース操作

main の反映を開発ブランチに取り込む（過去のマージ履歴を残したい場合）

活用シーン
- コミットが時系列になるので、いつだれが何をした？ が git log コマンドだけで分かる
- マージ履歴が消えないので「あのリリース main に取り込んだっけ？」が git log だけで分かる
コマンド
1. 開発ブランチをチェックアウトする
```
git checkout 開発ブランチ名
```
2. リベース操作を マージ方式 に設定する
```
git config pull.rebase false
```
  - この設定だと、過去のマージ履歴が残る
  - コンフリクト（更新の衝突）は自分で直す必要がある
3. main ブランチの最新の変更を取得する
```
git pull origin main
```
  実行結果に応じて次の手順が変わる
  - Already up to date. の場合、すでに変更を取り込み済み　＝＞手順はここで終了
  - エディタが開いた場合は、自動的にマージが完了している。
    Merge branch 'main' of レポジトリのパス into 開発ブランチ名 というコミットメッセージがデフォルトで記入されているので、必要なら文言を直して保存する　＝＞手順はここで終了
  - 上記以外のメッセージが表示された場合、コンフリクトが発生しているので修正する　＝＞後述の手順へ
4. コンフリクトしているファイルを確認する
```
git status
```
  - Unmerged paths の欄に表示されているものが、コンフリクトしているファイル
5. 対象ファイルを開き、コンフリクトしている部分を直す
  - 以下のような部分が修正箇所
  - <<<<<<< HEAD, =======, >>>>>>> XXXXXXX の部分は消す
  - どう直せばよいか不明なときは、他の開発者に確認する
```
<<<<<<< HEAD
自分の変更
=======
リモートの変更
>>>>>>> XXXXXXX
```
6. 変更を確定する
```
git add 解消したファイル
```
7. コミットする
```
git commit -m 'コミットメッセージ'
```
8. まだコンフリクトエラーが出る場合は、git status から繰り返す