チームのエンジニアからプロジェクトのGit運用とreleaseブランチのバージョン付け作法について教わったので、その概要をメモしておきます。developブランチを使わない場合の流れについてです。

releaseブランチの利用やバージョン付けのメリット

以下はreleaseブランチを使ったバージョン管理をするメリットだと思っていることです。

• バージョン管理によってチーム内で共通認識が持てる。
• 公開後に何か問題があった場合にすぐに過去バージョンに戻せる。
• 公開（リリース）ごとに実施した変更変更をわかりやすく記録できるので、これまでにどんな変更や追加がおこなわれてきたかを振り返って確認できる。
• チームに新しいメンバーが加わった際にこれまでの経緯を共有しやすい。

使用しているアプリケーションとサービス

前提として、以下のアプリケーションやサービスを使用している環境です。

• Sourcetree：Git管理アプリケーション。Git管理をコマンドではなくGUI（グラフィカルユーザーインタフェイス）で管理できる。
• GitHub：開発（ソースコード管理）プラットフォーム。ソースコードの管理をしやすくするためのサービスだと自分は認識している。
• Jenkins：WebサイトのデプロイをGitのブランチから選んで実行できる。releaseブランチからバージョンを指定してデプロイできる。

releaseブランチのバージョン付けと手順について

• 新しい変更や追加の内容はfeatureブランチで編集し、ステージング環境にJenkinsでデプロイ（配置）して確認する（普段はローカル環境で確認している）。
• featureブランチで編集完了後にGitHubでmasterブランチへのプルリクエストを出す（チームメンバーにコードレビューを依頼する）。
• masterブランチのコードレビューを受けて確定版になったのち、masterブランチからreleaseブランチへマージする。
• GitHub上のReleasesページで「Draft a new release」ボタンからreleaseブランチを選択し、そのときにバージョン用のタグをつける（バージョンはv1.0.0のような表記ルールで付ける）。
• 念のためバージョンを付けたreleaseブランチをステージング環境のJenkinsでデプロイして再確認（この過程は省略可）。
• プロダクション環境のJenkinsでバージョンを付けたreleaseブランチをデプロイして確認する。
• プロダクション環境を確認して問題がなければ完了。

最後に

一見複雑な手順に見えますが、手順を細かく分解して把握することで理解が深まりました。releaseブランチの管理についてまだ始めたばかりでわからないことも多いですが、今後少しずつ慣れていきたいです。