1. TL;DR
ソフトウェア開発では、試行錯誤の結果も重要な作業の一部です。
しかし、失敗したコードや不要な変更をProductionのcommitに残す必要はありません。
そこで、一時的なPRを作成し、履歴を残しつつもコードベースには影響を与えない方法があります。
この記事では、不要なPRを効率よく整理し、きれいな状態でレビューしてもらうための手順を紹介します。
# ただ、以下のコマンドを使ったことがある人は読まなくても問題ない記事だと思います。
git reset --soft main
2. よくある状況
- 実装方針が固まる前に、試行錯誤しながら改修を進める。
- 作業時間や試行ごとにgitのcommit履歴を積み重ねる。
- その過程で、不要となった試行や変更がいくつか発生する。
- そのままPRを出すと、無駄な変更が多く含まれ、レビューの負担が増えてしまう。
3. 対応方針
上記の状態に対して対応方針は２つ程度あるかと思います。
3.1. 方法1: 新規変更履歴はそのままに、tigで行単位の確認をしながらcommitを生成する
メリット
- 行単位でcommitを作成するため、詳細に変更内容を確認しながら整理ができる。
- 変更内容を失わずに、不要な部分だけをきれいに除去できる。
- 部分的に重要な変更を残しつつ、履歴を整理できる。
デメリット
- 手作業が多くなるため、大規模な変更や多くのcommitがある場合には時間がかかる。
- gitの操作に慣れていないと、commitの整理にミスが生じる可能性がある。
3.2. 方法2: rebaseを使用して履歴を整理する
メリット
- 一括でcommit履歴を修正でき、不要なcommitをまとめたり、編集したりできる。
- コマンド一つで履歴を再構築できるため、効率が良い。
- ローカルの履歴を綺麗に整えることができ、変更の流れが一目でわかりやすい。
デメリット
- 間違った操作をすると、変更が失われたり、履歴が複雑になったりするリスクがある。
-
rebase後は強制的にpushする必要があるため、共同作業者との履歴の不整合が起こりやすい。 - 自動化された履歴の再構築により、意図していた変更や試行の記録が削除される可能性がある。
3.3. 今回紹介する方法
冒頭で説明したとおり、変更履歴や試行履歴も価値あるものだと考えているため、今回はrebaseではなく前者の方法での作業を紹介します。
4. 具体的な手順
まず、commit履歴が煩雑になってしまったブランチとは別に、履歴を整理するための新しいブランチを作成します。
# 汚い履歴のブランチに移動してから新しいブランチを作成
# git switch dirty-branch-name
git checkout -b new-branch-name
次に、整理したいブランチをベースにして、以下のコマンドでmainなどのマージ先ブランチを指定し、履歴をリセットします。
git reset --soft main
その後、ステージングされた変更を一旦解除します。
git restore --staged .
ここからは、tigやgit diff、git statusなどのツールを使って変更内容を確認し、git addやgit commitを使って新しいcommitを作成していきます（tigを利用すると、1というコマンドを利用することで一行ずつadd できるためとても便利です。気になった方は調べてみてください）。
最後に、以下のコマンドで新しいブランチと元のブランチの差分がないか確認します。
git diff <new-branch-name> <dirty-branch-name>
差分がなければ、きれいなブランチを作成できたことになります。
5. 最後に
この方法を活用することで、作業履歴をきちんと残しつつ、Productionコードには整理されたcommitを反映させることができます。
ただし、PR内の作業内容が膨大になると、レビューする側の負担が増えることもあります。commit履歴をきれいにする前に、以下の記事も参考にしていただけると幸いです（もしcommitの整理が大変であれば、複数の関心事を含んでいる可能性があります）。
- そのPull Requestデカすぎませんか
-
Pull Request の関心事は一つにしよう | Wantedly Engineer Blog
- アクセス日はともに2024/10/20です
PRの作成者とレビュー担当者が、お互いに快適に作業できる環境を整えていきましょう。
最後までお読みいただきありがとうございました。