業務でよく使う git 操作 （逆引き）

業務でよく使う git 操作

概要

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

• 期待する読者

  • 目的からの逆引きで、git 操作を探したい方
  • 実際の業務において、どんな git 操作をよく使うのか知りたい方

• 前提

  • git レポジトリに移動している前提でコマンドを記載します
  • Linux コマンドラインでの操作 を記載しています（エディタの操作には触れません）
  • コミットの編集操作については、PUSH 前の状態 を想定して書いています（基本 force push はしません）
  • あくまで、業務での活用事例をもとに書いています
    なので、俗にいう 教科書通りではない 操作も出てきます

• 検証した環境

  • Rocky Linux 8
  • git サーバは Gitlab を使用

コミット操作

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

1. 活用シーン
   • コミットの文言を間違えたので、修正したいとき
     • 急いでいて間違えたり、issue 番号の記載を忘れた時、など
2. コマンド
   1. リベースする　＝＞コミット一覧の編集画面が開く

      git rebase -i リビジョン
      

      • リビジョン: HEAD~ ＋ 直したいコミットの世代数
        例えば、2個前のコミットを直したければ HEAD~2 とする
      • コミット一覧の表示例

        pick 123456a コミットメッセージA
        pick 987654b コミットメッセージB
        

   2. コミット文言を修正したいコミットの pick 部分を、edit に書き換える（複数のコミットを修正可能）

      pick 123456a コミットメッセージA
      ↓
      edit 123456a コミットメッセージA
      

   3. 修正を始める　＝＞エディタが開く

      git commit --amend
      

   4. コミット文言を修正する
   5. リベース処理を再開する

      git rebase --continue
      

      • Successfully rebased and updated ～ と出たら完了
      • Stopped at ～ と出たら、未編集のコミットがあるので、amend ～ continue の操作を繰り返す
3. 補足
   1世代前のコミットの修正だけなら、amend だけでもOK
   1. 修正を始める　＝＞エディタが開く

      git commit --amend
      

   2. コミットを修正する

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

1. 活用シーン
   • コミットの作業者名を間違えたので、修正したいとき
     • 特に、git config の user.name の指定を忘れて、デフォルト名や無記名で登録されてしまった場合の対処
   • 基本的な手順は前述の「コミット済みのコメントを修正する」と同じなので、一部割愛します
2. コマンド
   1. リベースする　＝＞コミット一覧の編集画面が開く

      git rebase -i リビジョン
      

   2. コミット文言を修正したいコミットの pick 部分を、edit に書き換える
   3. 修正を始める　＝＞エディタが開く

      git commit --amend --author="作業者名 <作業者のアドレス>
      

      • 作業者名: 正しい作業者名を記載する (例: hanzo-k)
      • 作業者のアドレス: 正しいメールアドレスを記載する (例: [e-mail])
   4. コミットを修正する
   5. リベース処理を再開する

      git rebase --continue
      

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

1. 活用シーン
   • 細かい修正のコミットをたくさん作ってしまい、1つに集約したい
     • テストやレビューで修正コミットが乱立した場合など
   • 異なる修正であれば、統合しない方がレビュアーにとって見やすい場合もある
2. コマンド
   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 ～ と出たら完了

ブランチ操作

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

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

      git checkout 派生元のブランチ名
      

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

      git checkout -b 新規ブランチ名
      

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

1. 活用シーン
   • 不使用の過去ブランチを消したい
     • リモートのブランチは消えないのでご安心
   • 間違えて作ったブランチを消したい
2. コマンド
   1. ローカルのブランチを消す

      git branch -D ブランチ名
      

      • ブランチ名: 消したいローカルブランチ名
3. 補足
   現在ローカルにあるブランチを知るには？
   1. ローカルのブランチ一覧を表示する

      git branch
      

   リモートのブランチを消す場合
   gitlab などの UI から、古いブランチ（Stale branches など）だけを消した方が、事故を防げる

マージ、リベース操作

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

1. 活用シーン
   • コミットが時系列になるので、いつだれが何をした？ が git log コマンドだけで分かる
   • マージ履歴が消えないので「あのリリース main に取り込んだっけ？」が git log だけで分かる
2. コマンド
   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 から繰り返す