2024/04/12に
当時社内で公開したスライド資料をQiita版にしたものです。
対象範囲、対象外について
・今回の含む範囲
Githubのリポジトリ運用を引き継いだ際に起きた課題解決の話
・今回に含まない範囲
gitの機能や内部的な動作
Githubの色んな機能
ある日のGithubのリポジトリ管理を引き継いだ。
ある日のGithubのリポジトリ管理を引き継いだ。
そこのリポジトリはGitフローで運用されていたが、色んな課題が待っていた。
・Gitフローで運用できない問題
・プッシュされ、プルリクエストされたブランチが何の目的で作られた物なのか、不明になっている問題
・残り続けるissue問題
…etc
課題は上から順に一つ一つやっつけるしかない！
魔法による全体攻撃などはない、単体攻撃していくしかないのだ
Gitフロー改善
Gitフローで運用できない問題
developに反映した機能を全部mainに反映したいわけではなく
一部だけmainに反映したい時、Gitフローでは運用できない
そもそもGitフローとは何か？ 
Gitフローとは
2010年に git が普及してきた頃に登場した運用フロー。以下のルールで運用される。
- main(master):プロダクトとしてリリースする用のブランチ。※このブランチ上での作業は行わない
- develop:開発用ブランチ。リリース準備ができたらreleaseへマージする。※このブランチ上での作業は行わない
- feature:機能の追加用。developから分岐し、developにマージする。
- hotfix:リリース後の緊急対応（クリティカルなバグフィックスなど）用。mainから分岐し、mainにマージすると共にdevelopにマージする。
- release:プロダクトリリースの準備用。
リリース予定の機能やバグフィックスが反映された状態のdevelopから分岐する。
リリース準備が整ったら、mainにマージすると共にdevelopにマージする。
Git フロー イメージ図
Gitフローの問題点
developブランチをステージングとしてユーザーに確認して貰った時、
featureAは本番に反映したいが、featureBは別の機会にしたいなどの要望が出てくる。
そのため引き継いだ時は、developブランチをそのままreleaseブランチに反映する事ができず
cherry-pickで対象のコミットだけをひっぱってreleaseブランチにしていた。
別の問題発生
いざreleaseランチを作る際にコミットの履歴を確認すると…
コミット メッセージが大雑把すぎて
何を、どこまでcherry-pickすればいいのか分からない
releaseブランチを作るにあたって…
cherry-pickはマージ担当者が行うとき下記の問題が発生する。
マージ担当者がcherry-pickすべきcommitを判断できない
→ 漏れや余計なcherry-pickをマージしたり、コンフリクトが起きたとき対応できない
マージ担当者はそもそもコードを読めない可能性がある
commitした担当者もいつまでコードを覚えてるかわからない
→ 後から、どのコミット？って聞いても全部正確に覚えてるかどうかは難しい
→ releaseブランチをcherry-pickで作るのは運用するには厳しい
releaseブランチの作り方の改善
releaseブランチをdevelopから作るから問題なのでは？
mainブランチからreleaseブランチを作り、
releaseブランチには、本番に反映したいfeaterブランチをマージするフローにすれば
ユーザーの希望の機能だけを本番リリースできるのでは？
Custom Git フロー イメージ図
これでreleaseブランチ問題は解決した！
だが新しい問題が待っていた…
コミットメッセージ改善
新しい問題
先ほどもにも挙がっていたが
コミットメッセージ意味不明問題が課題として出てしまった。
なぜ発生するのか
コミットメッセージ意味不明問題、cherry-pickの問題だけではなかった
実装後はブランチを削除する為、コミットメッセージの重要性が増してしまう
これではGitを使う意味がない…
理想のコミットメッセージを探す旅が始まる…
案：コミットメッセージに長文を書く
修正内容の機能の詳細をコミットに全部書く
必然で複数行になる。
デメリット：
gitのコメント履歴一覧を見るときは、ぱっと見できるは一行目まで
メッセージ記入のコストはかかるがリターンが少ないでは？
また大事な情報をたくさん記述したい時、どこまで書いていいのか
案：大事な情報を別で管理するチケット駆動記述
コミットメッセージできるだけ、簡易にし
詳細をIssueで管理する事でコミットメッセージからIssueにたどり着く。
メッセージフォーマット：
チケット番号、ブランチの種類、機能要件のフォーマットにする
例：「#112 feat 会員情報の更新機能の拡張」
チケット駆動記述、これがいいぞ！
しかしまた新たな問題が発生する。
Issue改善
Issueなんも書いてない問題
せっかくコミットログからたどってIssueを見ても
取りあえず立てたIssueのせいで何も情報がない
これではコミットログで取りあえず修正しましたと書いてある情報量と変わらない…
Issueに最低限かかせよう
GithubはIssue発行用テンプレート機能を使って
ある程度の入力フォーマットが最初から埋まるようにする。
最初からフォーマットがあれば人は埋めようとするはず
ブランチ名改善
プッシュされ、プルリクエストされたブランチが何の目的で作られた物なのか、不明になっている問題
まだコミット番号をコミットメッセージに入れていなかったとき、
ブランチ名を {ブランチ}/{機能名}にしていた時、その問題は発生した。
リポジトリを引き継いだ時、ブランチ一覧に残る謎のブランチたち
削除するブランチの基準を決める
基本的に本番リリースしているなら、そのブランチは不要である
本番後に修正が必要なら、それは別のhotfixブランチを作る事になるから
逆に本番リリースに含まていないブランチは、消すとリリースブランチにマージできなくなるので残ておかなければいけない。
解決案：リリース作業後にブランチを削除するフローにしよう！
ブランチ名のルールの変更
ブランチ名は {ブランチの種類}/#{issueの番号}{自由枠}形式で発行
自由枠は、機能名等を追記してもよい。
対応したissue がない場合は、issueを発行して番号を生成する
これでうっかりプルリクエストで紐づけされてなくても
ブランチ名からIssueを追えるようになった
謎ブランチの削除
それで、引き継いだ時の謎ブランチたちはすべて
削除して、マージを行わなかった。
不明な実装をマージするリスクの方が高いと判断。
削除されたブランチの実装を行った人は、
実装したコードが日の目に見ることもなった。
まさに賽の河原の石積みの鬼のような行為になってしまったが、
恨むなら前任者を恨んでくれ…
改善内容のまとめ
- gitフローの破綻
→ 新しいフローを構築することで改善 - 価値のないコミットメッセージの対策
→ コミットメッセージにチケット番号を入れる事で改善 - 無言Issue問題
→ Issue発行の際に指定のフォーマットを出力して記入を促すことで改善 - 謎のブランチが残り続ける問題
→ ブランチ名の命名規約を変更、また古すぎるブランチは危険なので削除する方向にかじ取りをした。