#git

Gizumo開発チームで採用しているGitの運用ルールを紹介します

公開日：2023.07.11 更新日：2023.11.30

こんにちは、株式会社Gizumoでエンジニアをしている日野です。
弊社の長期研修プログラムを経てエンジニアとなり、客先常駐、社内エンジニア教育を経験後、現在は社内で受託開発や自社サービスの立ち上げに関わっています。
ここ2年弱で2件の新規プロダクト開発に携わる機会があり、その中でGitの運用方法について模索しながらGizumoのルールとして定着してきたのでその内容をご紹介したいと思います。

前提・対象とする読者
Gitのローカル設定
- ユーザー名
- メールアドレス
ブランチ戦略
コミットルール
- コミットの条件
PRルール
さいごに

前提・対象とする読者

この記事は以下を前提として読み進めてください。

Gitの操作はCLIで行う
記事内ではPull RequestをPRと表記
社内の技術スタックとしてフロントエンドにReact、バックエンドにPHPを採用している為、一部それらに依存した運用の手順を含む

また、対象とする読者は以下のような方を想定しています。

新しくプロジェクトを発足するにあたりGitの運用ルールを検討している方
Gitを使ったチーム開発のレベルをワンランクアップしたい方

Gitのローカル設定

はじめにGitのローカル設定について紹介します。
Gizumoではユーザー名とメールアドレスの2つについてルールを設けています。
目的としては、コミットログ確認時に誰のコミットかを瞬時に判断できるようにする為です。(GitHubのアカウント名だと誰だか分かりにくかったという背景があります。)

ユーザー名

Gizumo_Taroのようにローマ字表示で名字と名前をアンダースコア(_)で区切ります。

【設定方法】

git config user.name "Gizumo_Taro"

メールアドレス

社員ひとりひとりに対して会社が付与しているメールアドレスを設定します。

【設定方法】

git config user.email "gizumo@example.com"

※git configの操作を実行する際、--globalオプションをつけるとローカルマシンで管理している全てのGitリポジトリに対して設定が適用されてしまうので注意

ブランチ戦略

続いてブランチ戦略ですが、基本的にVincent Driessen氏が提唱したA successful Git branching modelという考え方を採用しています。
A successful Git branching modelと聞いてピンと来ない方もいるかも知れませんが、git-flowならば聞いたことがある方がほとんどではないでしょうか。
実はgit-flowはそれ自体がブランチ戦略というわけではなくA successful Git branching modelの実現をサポートするGitの拡張にあたります。(以降このモデルをgit-flowと読んで話を進めます。)
この戦略を採用した背景としては、2つ先のリリースに含める機能も早いタイミングでステージング環境で確認したい等の受託開発時のクライアント要望に対応するのに一番マッチした戦略であり、結果この戦略にメンバーが慣れたため引き続き採用しているという形です。

参照：A successful Git branching model by Vincent Driessen

各ブランチについて詳しく説明します。

ブランチ名	説明
master	直接の作業は行わない、実際に稼働しているサービスと同等のコードを管理するブランチ
hotfix	リリース後のバグ修正用ブランチ(本番環境で発生しているクリティカルなバグの修正用) ・`hotfix/{タスクNo}`という命名でmasterから派生させる・修正完了後はmaster、developへPRを作成してマージ
fix	緊急を要さない軽微なバグ修正用ブランチ・`fix/{タスクNo}`という命名でdevelopから派生させる・修正完了後はdevelopへPRを作成してマージ
release	リリース前の動作検証用ブランチ・リリースの約1週間前を目安に作成・developから派生させる・releaseブランチを作成してからは新規機能はreleaseブランチには取り込まない・基本はreleaseブランチ環境で発生しているバグがあればその修正、ドキュメントの整備のみ行う・releaseブランチで発見したバグの修正コミットをした場合はdevelopにも反映・諸々の準備が整いリリースのタイミングになったらmasterへマージ&タグ付けし、developへもマージ・リリース作業が完了したらreleaseブランチを削除
develop	開発用のベースとなるブランチ・masterから派生させる
feature	作業用、機能開発用ブランチ・developから派生させる・`feature/{タスクNo}`という命名にする・実装完了後はdevelopへPRを作成してマージ

※git-flowではPRについて言及がありませんが、弊社では機能実装が終わったらGitHubでPRを行った後に、権限を持った人がブランチのマージを行うフローにしています

コミットルール

続いてコミットルールについてです。
Gizumoでは以下のコミット用テンプレート(.gitmessage)を事前に用意し、コミット時にこのテンプレートが表示されるようGitに設定をしておきます。
コミット時は設定したテンプレートを表示してコミットメッセージを作成するために、-mオプションは使用せずにgit commitでコミットを行います。

ex) .gitmessage

# ==== Format ====
# ${prefix}: 実装の概要を50文字以下で記述 ex)fix:ユーザー情報にnameが足りないのでnameを追加
#
# コミット本文(50文字で収まらない場合はこちらに)...

# ==== Prefix ====
# feat     新規機能、新規ファイル追加
# change   仕様変更による機能修正
# test     テスト追加や間違っていたテストの修正
# delete   ファイル削除
# fix      バグ修正
# style    空白、セミコロン、行、コーディングフォーマットなどの修正
# refactor 既存の振る舞いを変更しないコード改善
# perf     パフォーマンスを向上させるコード変更
# chore    ビルド、補助ツール、ライブラリ関連、開発環境変更
# docs     ドキュメントのみ修正

# ==== Emojis ====
# 🔖  :bookmark: バージョンタグ（Version Tag）
#
# ※リリースでバージョンタグを付ける際に使用

# ==== Rules ====
# 1. コミット本文を記述する場合は、概要とコミット本文の間に空行1行あける
# 2. 概要は50文字以下で記述する
# 3. 概要の末尾はピリオドで終わらない
# 4. 概要は命令法で記述する
# 5. 本文は72文字で改行する
# 6. 本文ではhowではなくwhatとwhyを記述する

【Gitの設定】

git config commit.template /path/to/.gitmessage

コミットの条件

コミット時点でコードが動くこと（ex. まだ存在しないクラスやパッケージをuseしたりimportした状態で先にコミットしてしまうケースはNG）
複数機能を一度に混ぜない（コードの量は問題ではない）

【特に注意】
以下のようなコメットメッセージはざっくりしすぎているのでNGとし、やったことをもっと詳細に記述するようにします。

NG
refactor:レビュー指摘事項の修正
style:軽微な修正
GOOD
refactor:記事投稿のビジネスロジック内に存在するマジックナンバーを定数化
style:ユーザーモデルクラスの不要な改行を削除

PRルール

最後にPRのルールとして、Gizumoでは以下を定めています。

レビュー依頼前に今一度開発ルール、コーディング規約を確認する
レビューコメントに対して、「修正しました」程度のシンプルな返信となる場合は👍等のスタンプでリアクションする
※リアクションのないコメントが残ってると、確認漏れなのか否かを判断し辛いため

PRの粒度

ひとつのPRが膨大にならないよう、差分が大きくなりそうな場合はキリのいいところで区切ってPRを出す
※例えばコードの差分が2倍になると確認作業は3倍、4倍の時間がかかってしまいます
目安としてはフロントであれば10ファイル程度までに抑えると良い（変数名の変更など、ロジックが無く単純なネーミング変更が多い場合などはこの限りではありません）
1日1PR程度になるようにタスクを細分化する（作業が1日越えてしまう時点で、それなりのコード量になってしまっているはずです）

PR記載項目

Gizumoでは以下のフォーマットテンプレートを予め用意し、テンプレートの内容に沿って記載します。
このフォーマットテンプレートを.githubディレクトリ内に置いておくと、PR作成時にテンプレートの内容がPR概要に反映され、入力が楽になります。

エビデンスとなる画像を添付する場合は、外部サービス(Gyazoなど)を経由せずGitHubに直接アップロードを行う※外部サービスだとリンク切れが発生する可能性があるため
作業中のPRの場合
PRを作成後、追加修正などが必要でまだレビューしてほしくない場合はdraft版でPR作成を行う（GitHubのTeamプラン以上にdraft機能が存在します）

ex.) PULL_REQUEST_TEMPLATE.md

## タスクのリンク
- タスクのURLをここに貼る

## やったこと
- このタスクでやったことはなにか？

## やらないこと
- このタスクでやらないことはなにか？（やらない場合いつやるのか？無ければ「なし」を記述）

## 動作確認
- どのような動作確認を行い、結果はどうだったのか？(適宜スクショ等添付)

## 特にレビューをお願いしたい箇所
- 特にチェックをお願いしたいポイントを簡潔に記述する

## その他
- 実装上の懸念点、注意点等あれば記載する

レビューコメントのprefix

prefix	説明
must	要修正
imo	コメントもらった人がいいと思ったら採用（絶対ではない）
ask	実装の意図などを確認している。コメントもらった人は要回答
nits	細かい内容だけど修正