概要

エンジニアが仕事をする上でGitは必ず必要になる技術のうちの1つです. しかしながら、多くのエンジニアがGitでのファイルの変更履歴を管理することを蔑ろにしている気がしました. 例えば、Dockerのバージョンを変更するケースを考えてみましょう. 変更前は、image: node:16でした. image: node:18に変更する場合、みなさんはコミットメッセージをどのように記載しますか？私は、change: change the docker image versionなどと記載することが多々あります. しかしながら、レビュアーの視点に立つとこれが少し不親切であることは分かると思います. 多くのエンジニアはnodeのバージョンが16から18に変わっているのはコードを見ただけで分かります. なぜ変更したのだが分からないとapproveすることが難しいですよね. とはいっても、PRに理由は書きますし、チーム内で共通の認識として事前に共有している場合などもあるので問題ないといった意見も理解できます. しかし、3年後、5年後、10年後にコミットメッセージを確認する場合はどうでしょうか？ライセンスやコストの関係からGitHubから社内のコード管理サービスに移行してくださいということがないと言えますか？というわけで（無理やりですが）、Gitのコミットメッセージを適切に記載することは、レビューアーのレビュー時間を短縮し、プロジェクトに参画する未来のエンジニアの時間も短縮するというメリットがあります.

しかしながら、ここで問題があります. Gitのコミットメッセージを適切に記述するには、Gitについて知っている必要があります. よくあるのが、ファイルごとにコミットメッセージを記載するのは分かるのですが、ファイル内の行ごとでコミットメッセージを分けたいときはどうすれば良いのでしょうか？といった疑問があったりするかと思います. 私も、git add・git commit -m・git push origin mainという3つのコマンドのみしか知らなかった時期がありました. まぁ、新卒の時はレビュイーであった時がほとんどなので、個人的には問題はなかったのですが、年次が上がるにつれレビューを担当することが多くなると少しコミットメッセージに対してイライラすることが増えてきます（更年期も関係あるかもですが笑）.その結果、コミットメッセージは見ないといったことがあるのですが、適切なコミットメッセージが記載してある場合は、コミットメッセージと変更差分だけ確認することでレビューを完了せることがさできるのに...といった悲しい気持ちになりますし、レビュイーへの質問、レビュー時間を減らすことができるのになぁと思うことがあります.

というわけで、Gitについて一緒に学んでいきましょう.

基本的なコマンド

git init

git remote

git add

git commit

git push

中級者コマンド

git config

git switch ・ git checkout

git pull

git fetch

git merge

git stash

git cherry-pick

git rebase

git branch

git status

絵文字を用いたコミットメッセージ: 小休憩

上級者コマンド

git blame

git config

git reflag

git diff

git log

git column

git maintainace

Reference

© 2024 nakadats. Created by Satoru Nakadate.