RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

【Git】commitのタイミングと注意点

初めまして。新卒1年目エンジニアのrs_shoです。
今回はGitのcommitタイミングと注意点について書いていきたいと思います。

はじめに

皆さん、バージョン管理システムのGit、使ったことありますか?
僕は、社会人になって初めて「バージョン管理システム」を使いました。かなり便利ですね!
過去のある状態に戻したり、元のファイルを編集しないようにブランチを切って編集後に差分を反映したり・・・
学生時代から使っておきたかった、なんで使ってないんだ!過去の自分よ・・・と思うくらい便利です。

そもそもcommitって?

「commitってなんだ」と思う方もいるかもしれないので、つかみ程度に・・・

・Gitで「追加編集したファイルを登録するコマンド」のこと
・編集した履歴、差分などが記録される
・commitしたポイントに戻ることができる

3つ目が個人的にかなり便利だと思います。
具体的にはcommitする前にファイルをaddするなんてことも必要ですが、今回説明は割愛します。

commitのタイミング

ではそろそろ本題へ・・・
commitって便利ですが、「いつすればいいの?」っていう人多いんじゃないでしょうか。
僕がGitを使って間もない頃、commitをし忘れたり、あまり意味のないタイミングでcommitして、
一緒に研修していた同期に「またか」と言われてました。(だっていつしていいかわからない・・・)
実際、「commitのタイミング・頻度」ってどれくらいがいいのか、難しいところだと思います。

$ git add [ファイル名]
$ git commit

コマンドとしてはこれだけです。addしたファイルだけコミットされます。簡単ですね!
ではcommitっていつすればいいのという話ですが・・・

実は絶対この時commitするべきこの時はしない方がいいというタイミングはありません。
(じゃあなんでこの記事書いたんだというツッコミはご遠慮ください)
実はこの問題、僕もすごく悩みました
ネットで記事を探すと色々書いてありますが、僕が導き出した答えは以下の通りです。

  • 会社の規則に従う(会社で決まっているタイミングで行う)
  • 個人的に「この部分へは戻る可能性がある」と思ったとき
  • タスク単位(機能単位)※単一機能追加のみ
  • クラス単位(編集しているクラス1つにつき1回)

個人的な意見としては会社でグループ開発をしている場合は1つ目が絶対だと思います。
個人開発や他人に迷惑をかけない(自分のみが編集する部分)に関しては、個人のタイミングで良いと思います。
自分がcommitしてなくて最初からやり直し・・・なんてことになっても自分の責任で済みますからね・・・
僕は研修の時はクラス単位でcommitしていましたが、配属されてからは機能単位でcommitしています。

commitする際の注意点

commitする時に注意したいのが、余計なものはcommitするファイルに入れないことです。
僕が配属されてから失敗したこととして、commitしなくていい(しない方がいい)ファイルまでaddしてcommitしていました。
つまり、機能に関わりのない個人設定のファイル間違って編集したファイルはcommit対象にするべきではないということです。
理由としては、

  • 余計なファイルが入ると、確認する際(個人環境に持ってきたとき)に動作の妨げとなることがある
  • 機能単位で確認する際に編集した内容が見づらくなってしまう

などがあげられます。(実際に先輩に指摘を受けました)
1点目についてはレビュワーへの被害が大きいです。余計なファイルがあると、どこを編集したのか確認が大変です。
2点目は1点目に繋がりますが、後から見た人が「これ編集してあるみたいだけど、どう関係してるファイル?」となってしまいます。
個人で開発しているならまだしも、グループ開発だと、周りに多大な迷惑&手間をかけてしまうことがあります。

おわりに

皆さん、いかがでしたか?
commitのタイミングと注意点について個人的な意見ですがまとめてみました。
commitのタイミングについて困った方の参考になれば幸いです。

参考資料

Copyright © RAKUS Co., Ltd. All rights reserved.