gitの概要メモ 7 共同開発の為の規約策定

Git Advent Calendar 2017の16日目のエントリです。

タイトルに「7」とあるのは、この僕のブログでGit関連というカテゴリーでgitについての備忘録を残しているので、その名残です。

開発しているアプリに開発メンバーが増えるので、
初めての共同開発となるというのと、
最近始めたバイト先で人の書いたコードを読むようになったのですが、
やはり共通の理解のあるコード規約なるものがないと大変なことになるのだなという風に思う今日このごろです。

なのでこのgitについても色々規約が始めに決まっていたほうが後々楽なのではないのかと思いました。

 

共同開発にルールを作るべき(と思っている)こと

・コミットの粒度
・コミットメッセージの書き方
・git hooksを使う
・プルリクの仕方
・gitを用いたワークフロー

などなど・・。
この辺を明確化することで、レビューする時の手間を減らし、
この辺を言語化することで、新規メンバーが増えた時も伝える労力を減らすことができるのではと思います。

また、このルール策定に関してはオリジナリティを出すのも良いのかもしれませんが、
できるだけ知名度のある合理的なものを選択したほうが良いと思います。
なぜなら、自分が全く知らなかった人の他のプロジェクトに参加する時にそういったルールに関して共通の理解があるとその分楽になるからです。
その中であまりにも非合理的だなと思う部分があれば部分的にオリジナルルールを加えると良いと思います。

 

コミットの粒度

まずコミットの粒度です。
基本的には、「できるだけ小さく、1つの意味をもつ単位で」という感じです。

例えば
「1ページ分作りました」→コミット。
まだまだでかい、でかすぎます。
「1コンポーネント作りました」とか「1アクションに対してのReduxを実装しました」のような大きさかなと思っています。

ここまでは、まぁなんとなく理解できるのですがさらに注意すべきところは
・フォーマッタの適用
・誤字の修正などのリファクタ
・ファイルの場所を変更
・ファイルを削除
などはそれぞれ異なるコミットに纏めるようにします。

その心は、A操作とB操作をまとめて1つのコミットにしてしまうと、
少し作業が進んだ時に「B操作が終わったところに戻りたいな」と思い、戻ってみると
A操作もまだしていない点にワープしてしまいます。
なので、再びA操作を実装し直す羽目になります。

また
「正常に動く時点でコミットする」というのは絶対条件です。
エラーが出ている時にコミットすると後々面倒すぎるのでこれは絶対避けたいです。

以下の記事が面白いです。
「テストコードを含めてコミットする」というのは初耳でした。参考にしてみます。
【参考】git commit するまえに考えるべき10のこと | Act as Professional

 

コミットメッセージのテンプレ

コミットする時にコミットメッセージを一緒に付します。
その時のテンプレをある程度決めて置いたほうが良いかと思います。

まずコミットメッセージの書き方は
1行目 要約
2行目 空行
3行目 要約では書ききれなかった詳細を書く
と書いていきます。

 

1行目

ここには長すぎず短すぎない程度のコミットの要約を書きます。
僕はあとでlogを見た時に見やすくなるようにコミット種別を文頭に書くようにしています。

[Add]:新しい機能を追加
[Clean]:リファクタ
[Fix]:バグ修正
[Remove]:削除
[Update]:機能修正(バグではない)
[Revert]:変更取り消し
[Upgrade]:バージョンアップ
[Disable]:無効化(コメントアウト等)
[Merge]:マージ

【参考】https://qiita.com/itosho/items/9565c6ad2ffc24c09364

コミット種別の後に、何をしたのかをわかりやすく書きます。
過去形ではなく現在形で書きます。
できれば英語でのコミットメッセージにも慣れたほうが良いと思うんですけど、そもそもGitに慣れるまでは日本語でも良いかなと思っています。

 

3行目

変更した理由を具体的に記載します。
「なぜ」、「何を」編集したのかをわかるように記述します。

 

最後に

・git hooksを使う
・プルリクの仕方
・gitを用いたワークフロー
の3つについては次回以降に書きます。

コメントを残す