こんにちは！2021年2月にアンドパッドに入社しました、エンジニアの浜田です。
私の経歴として入社前までチームでの開発をほとんどしてきませんでした。アンドパッドに入社して初めてチーム開発をするようになりました。
入社当初、私がPR(Pull Request)を対応する中で教えてもらったことや、他の方が教えてもらっていたことを社内向けに初めてPRを対応する前に知りたいことというタイトルで記事をまとめました。今回はその記事の内容からGitに関してまとめた4点を紹介させていただきます。
- はじめに
- 1. コミットメッセージは1行目がタイトルで3行目から説明
- 2. 1コミットに複数の対応を混ぜない
- 3. コミットメッセージに有益な情報を残す
- 4. レビュー前にGitのコミット整理
- まとめ
はじめに
アンドパッドではGitHub上で開発を進めています。PRのマージ条件の1つにレビュアーのApproveがあります(必要なApprove数はリポジトリによって異なります)。そのため、1人が作業して誰も見ずに本番にリリースされる。ということはありません。
今回紹介する内容を意識して対応することでレビュアーの不明点が減り、より良いレビューができると考えています。
1. コミットメッセージは1行目がタイトルで3行目から説明
Gitのコミットメッセージは 1 行目がタイトル、 3行目以降が説明として扱われます。なので、タイトルの後は 1行空けて説明を書くのが良さそうです。知ってる人からすると何を今更。という内容ではありますが、Gitのコミットメッセージに想いがなく開発をしている現場では知らないこともあると思い、記載させていただきました。
Git公式のドキュメントでも必須ではないものの、推奨されています。
Git - git-commit Documentation
2行目を空けずに説明を書くと全てタイトル扱いになり、git log --oneline などで見た時に全てのメッセージが表示されます。
2. 1コミットに複数の対応を混ぜない
知っていても誰も気にしない現場で開発を続けていると、できていない内容かと思います。
私はPRのレビューする時はコミット単位でレビューして、最後に全体を眺めるように見ることが多いです。コミット単位で確認することで1度に確認すべき修正範囲が狭まるため、より正確なレビューができると考えています。
その時に、1つのコミットで複数の対応をしていたり、対応が大きくなっている場合、レビューのために処理する情報量が多くなります。その場合に不明点は残るものの、良さそう。としたり、手元で動かして問題ないからOK、としてしまうケースがあるかと思います。
これらを意識することで見やすいコミットになり、やる意味があると考えています。
そうなると、対応が大きくなっているに対して、1対応はどのくらいの粒度が適切か。気になると思います。
この部分については人によって粒度が異なると考えています。すみません。まだ、これだ！と言えるものはありません。直近の指針としては、自分のしたいこと(変更の目的)を伝えられる最小単位でコミットしています。
また、大切にしていることとして、初めて見る人にコミットの内容が伝わるかを意識しています。
コミットの粒度について記事にされている方も多いので、気になった方は検索してみて自分の粒度を模索していただければと思います。
3. コミットメッセージに有益な情報を残す
コミットメッセージは実装後、時間が経ってから見ることも多いと考えています。例えば、機能改修や障害調査などの対応は実装直後ではない場合が多いと思います。
その時に何を知りたくて過去のコミットを見るのでしょうか。対象のコミットが何をしていて、なぜその変更を加えたのかを知れると嬉しく感じます。
何をしたのか。はコミットの差分を見ることで知ることができると思います。ですが、なぜその変更を加えたのかをソースコードからエスパーするのは難しい場合が多いです。なので、なぜその変更を加えたのかを残せると有益なメッセージになると考えています。
私の場合、タイトルに何の変更なのかを記し、説明になぜその変更を行なったのかを記載しています(差分で変更理由が明らかな場合は省略します)。また、何かのコマンド実行でファイルを作成した場合は実行したコマンドをコミットメッセージに残しています。
もし、今積んでいるコミットのメッセージが "Fix!!" や "Aの文言を修正" のみのような場合、"なぜこの変更を行ったのか" を追記していただくとより親切なコミットメッセージになりそうです。
コミットメッセージについて、過去に弊社で勉強会を開催しました。以前のテックブログに勉強会の内容を記載しております。こちらもご覧ください。
4. レビュー前にGitのコミット整理
今までの流れで私が考える、何が親切なコミットメッセージで、どのくらいの粒度でコミットを分割すると良さそうか。をお伝えできたかと思います。
ただ、実装途中でとりあえずのセーブとしてコミットを積むことや、CIの検証などでそのコミットをリポジトリにpushすることもあると思います。そういった中途半端なコミットはレビュー前に整理するのが良い。と考えてます。(force pushについては現場により意見が分かれる場合もあるかと思いますが、作業ブランチでレビュー前の場合、問題ないと考えています。レビュー後もレビュアーとコミュニケーションが取れていれば問題ないと考えています。)
コミットを整理する時によく使うコマンドの git rebase -iに少し触れされていただきます。
最新のコミットから3つを変更したい場合、以下のコマンドを実行します。
git rebase -i HEAD~3
すると以下の内容がエディタで表示されます。下部のコメントの通りですが、pickと書いてある部分を適したコマンドに変更して保存します。その後、それぞれのコマンドの方法でコミットの整理を行います。
pick bbbbbb First commit message pick cccccc Second commit message pick dddddd Third commit message # Rebase aaaaaa..dddddd onto aaaaaa (3 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message.
まとめ
今回、Gitのコミットやコミットメッセージについてまとめさせていただきました。2つ目以降の内容は今意識していない場合、単純に追加の作業になるかと思います。
私も初めはこの作業に時間がかかり、1つ1つの対応スピードが落ちました。ですが、これらの作業を行うことで、後から見返した時に過去の実装意図が見えやすくなります。
改修時に既存機能の確認で、「なんでこの実装したんだっけ」から始まる調査時間の短縮や、改修時の認識漏れによる障害が少なくなっていくと考えています。
私自身まだまだ模索中ではありますが、少しでも顧客や一緒に働く仲間にとって、良いエンジニアになっていきたいと思います。
そして最後に、アンドパッドは今、共に働く仲間を募集しております！様々なポジションがありますので、共に成長していきたい。と思っていただけましたら、ご応募ぜひお待ちしております！
