マージ、タグ、リリース：本番環境に何がデプロイされたかを追跡する

プルリクエストのレビューが終わりました。コードは問題なく、テストもパスし、チームメイトから承認も得られました。さて、次はどうするべきでしょうか？

ほとんどのチームは、変更をメインブランチにマージする必要があることを理解しています。しかし、マージの方法、残す記録、そして本番環境で実行されているものをどのようにマークするかによって、半年後に「その日、実際にデプロイされたコードは何か？」というシンプルな質問にチームが答えられるかどうかが決まります。

マージコミットが証跡となる

フィーチャーブランチからメインブランチに変更を統合する方法はいくつかあります。最も一般的な方法は、マージコミットを作成することです。

マージコミットは単にコードを移動するだけではありません。変更がどのブランチから来て、どのブランチに取り込まれたかという2つの情報を記録します。これにより、コミット履歴に「ここで何かがマージされた」という明確なエントリが作成されます。

これと比較して、ファストフォワードマージでは、Gitは新しいコミットを作成せずにポインタを前方に移動するだけです。ファストフォワードマージは履歴を直線的に保ちますが、マージが発生したというコンテキストが失われます。後でバグの原因を追跡する必要が生じた場合、マージコミットがあれば、プルリクエストの議論、レビューコメント、そして統合された正確な変更点への直接的なリンクが得られます。

マージコミットを使用すると、gitログが物語を語ります。火曜日にfeature-xがmainにマージされ、水曜日にfeature-yがマージされたことがわかります。木曜日に何かが壊れた場合、最初にどのマージを調査すべきかが正確にわかります。

次のフローチャートは、各ステップがどのように連携して明確な証跡を形成するかを示しています。

プルリクエスト承認後に実行する正確なコマンドシーケンスは次のとおりです。

# 1. 非ファストフォワードのマージコミットでマージ
$ git checkout main
$ git merge --no-ff feature-x -m "feature-xをmainにマージ"

# 2. マージコミットにリリースタグを付ける
$ git tag -a v1.2.3 -m "リリース v1.2.3"

# 3. mainブランチと新しいタグをリモートにプッシュ
$ git push origin main --tags

# 4. フィーチャーブランチをローカルとリモートから削除
$ git branch -d feature-x
$ git push origin --delete feature-x

マージ後のクリーンアップ

マージが完了したら、フィーチャーブランチはその役割を終えました。それを削除することでリポジトリを整理整頓し、新しいブランチを作成する必要があるときに古いブランチがリストを乱雑にするのを防ぎます。

チームによっては、マージ後すぐにブランチを削除するところもあれば、新しいバージョンが本番環境で1〜2日稼働するまで待ち、同じポイントからホットフィックスブランチを作成する必要がある場合に備えるところもあります。一貫したプラクティスがあれば、どちらのアプローチでも問題ありません。

削除する前に、そのブランチのすべての変更が実際にメインブランチに含まれていることを確認してください。簡単な確認方法：ブランチがプルリクエスト経由でマージされている場合、ほとんどのGitホスティングプラットフォームは「マージ済み」と表示し、ワンクリック削除を許可します。

タグ：バージョンに名前を付ける

メインブランチには最新のコードが含まれています。しかし、現在本番環境で実行されているコミットが正確にどれかをどうやって知るのでしょうか？メインブランチは新しい変更が入るたびに進み続けます。固定された参照点がなければ、推測するしかありません。

ここでタグの出番です。タグは特定のコミットに付けられるラベルです。ブランチとは異なり、タグは移動しません。タグを作成すると、そのコミットを永久に指し示します。

チームは通常、新しいバージョンをリリースするときにタグを作成します。例えば、テストが完了し、チームが本番環境にデプロイする準備ができたら、メインブランチの最後のコミットに v1.2.0 のようなタグを作成します。そのタグは永続的な参照となります。半年後、誰かがその日にどのコードが実行されていたかを尋ねたら、タグを確認します。

タグの命名規則を統一する

タグ名は、チームの全員が理解できる規則に従う必要があります。セマンティックバージョニングは一般的な選択肢です：v1.2.3 ここで、

• 最初の数字は、後方互換性を壊すメジャーリリースで変更
• 2番目の数字は、新機能で変更
• 3番目の数字は、バグ修正や小さな改善で変更

しかし、セマンティックバージョニングだけが選択肢ではありません。日付を使用するチームもあります：release-2024-11-15。ビルド番号を使用するチームもあります：build-142。重要なのは一貫性です。フォーマットを選び、文書化し、すべてのリリースでそれを使用してください。

どのフォーマットを選んでも、デプロイされた正確なコミットからタグが作成されていることを確認してください。異なるコミットにタグを付けると、信頼できる参照点としてのタグの価値が失われます。

リリースノート：何が変わったのか、そしてその理由

タグを作成した後、ほとんどのチームはリリースノートを作成します。リリースノートは、このバージョンで何が変わったのかを簡潔にまとめたものです。長くしたり詳細にしたりする必要はありません。「このリリースを気にすべきか？」という質問に答えれば十分です。

優れたリリースノートには以下が含まれます：

• ユーザーが気付く新機能
• 既知の問題を解決するバグ修正
• 他のチームやユーザーにアクションを要求する破壊的変更
• このバージョンの既知の問題や制限事項

リリースノートはゼロから作成する必要はありません。多くのチームは、最後のタグと現在のタグの間のプルリクエストのタイトルやコミットメッセージから生成しています。技術的な詳細を削除し、ユーザー向けのコンテキストを追加するための簡単なレビューで十分なことがよくあります。

開発と本番の架け橋

マージとタグ付けは、コードを書くことと本番環境で実行することの間の架け橋を形成します。マージは、レビューされた変更が共有コードベースに取り込まれることを保証します。タグは、特定のコミットを指して「これが現在実行されているバージョンです」と言えることを保証します。

タグがなければ、長いコミット履歴があり、実際にリリースされたコミットを知る方法がありません。推測したり、デプロイログを確認したり、覚えていないかもしれないチームメイトに尋ねたりすることになります。タグはその不確実性を排除します。

実践的なチェックリスト

次のリリースの前に、以下の手順を実行してください：

• ファストフォワードではなく、マージコミットでプルリクエストをマージする
• マージを確認した後、フィーチャーブランチを削除する
• デプロイされる正確なコミットにタグを作成する
• 何が変わったのか、そしてなぜそれが重要なのかをカバーするリリースノートを作成する
• タグがリモートリポジトリにプッシュされ、チーム全体が確認できることを確認する

これがチームにとって意味すること

次にプルリクエストをマージするときは、何を残しているのか考えてみてください。マージコミットとタグは小さなアクションですが、将来の自分が感謝する履歴を作成します。午前2時に何かがうまくいかず、何が変わったのかを知る必要があるとき、推測する必要はありません。本番環境の問題からマージコミット、プルリクエスト、そして変更に至った議論まで、明確なトレイルがあるでしょう。