はじめに
いつものように開発を行っていたある日のこと。
開発完了！さあレビュー依頼だ！ ...ん？ちょっと待った
コミット履歴を見てみると、コミットした修正をやっぱり違うなと戻してみたり、テスト作成中にメソッドのタイポを発見して一緒にコミットしていたりとぐちゃぐちゃ...
ということで、レビュワーの負担軽減のために（自分を頭良く見せるために）コミット履歴を整理したのでその手順メモを共有します。
PR,MRを作るときに参考になれば幸いです（余談ですが、PR：プルリクエスト → GitHubの用語、MR：マージリクエスト → GitLabの用語らしいです）。
手順
1. git checkout -b 整理用ブランチ
せっかくの修正が消えてしまっては困るので、コミット整理用ブランチを新しく作り移動します。
git checkout -b develop_MR
2. git log --oneline
git logで、整理が必要なコミット数を確認します。
git log --oneline
8da95c1a (HEAD -> develop) id/102 実装・テスト追加修正
2b9f8fe8 タイポ修正
f85688a4 id/102 Fugaテスト修正xxxを考慮
38be30ef id/102 テスト追加
8ed9ed6f id/102 hoge,fugaの修正
c6351458 (HEAD -> origin/develop) Merge branch 'develop' into 'master'
ad18eccc id/101 piyoの修正
（↑コミットメッセージの書き方が一定でないし、メッセージのprefixを忘れていたりとぐちゃぐちゃな内容）
3-1. git rebase -i HEAD~コミット数
必要なコミットの修正が少ない場合にはgit rebase -iで対応できます。解説は以下の記事が非常に詳しいのでお譲りします。
感覚的にはコミットの分割などオプションのeditやexecが必要になってきたら手順3‐2．のgit resetを使用したほうが簡単になります。
3-2. git reset HEAD~コミット数
git resetで、整理が必要なコミット数分戻ります。
git reset HEAD~5
Unstaged changes after reset:
M hoge.tsx
M fuga.tsx
M hoge.test.tsx
M fuga.test.tsx
4. きれいなコミット履歴の作成
ローカルに戻した差分から、一つ一つコミット履歴を作っていきます。どのようなコミット履歴が喜ばれるのかについては以下の記事が非常に分かりやすかったです。
コードブロック単位のステージングなど複雑な操作にはVSCodeの機能を利用すると便利ですが、CLIを使用する方は以下の記事が参考になります。
5. git log --oneline
git logで、修正したコミット履歴を確認します。
git log --oneline
hu5jikde (HEAD -> develop) id/102 xxxメソッドによる修正に伴うhogeテスト修正
8ityksp0 id/102 hogeにxxxメソッドの影響を考慮して修正
23g8er0w id/102 xxxメソッド追加に伴うfugaテスト修正
7s9v5iuq id/102 fugaにxxxメソッド追加
c6351458 (HEAD -> origin/develop) Merge branch 'develop' into 'master'
ad18eccc id/101 piyoの修正
（↑一つのコミットに一つの内容、コミットメッセージも具体的でだいぶ読みやすくなった）
6. git push origin ローカルブランチ:リモートブランチ
コミットを整理したブランチをリモートにgit pushします。
引数に<ローカルブランチ>:<リモートブランチ>を指定することで別名ブランチにもプッシュが可能です。
git push origin develop_MR:develop
7. レビュー依頼
ここまで来たら晴れてレビュー依頼提出です！自分がいかにレビュワー思いのレビュイーであり、論理的に考えてプログラミング開発ができるエンジニアであるかをPR,MRを通じてアピールしましょう☆