はじめに

この記事は、プログラミングスクールにてRuby on Railsを学んでいる初心者が書いた記事になります。

個人開発でアプリを作成する際、「実務を意識した開発をしたい」と考え、Git-flowを参考にしたブランチ運用を導入しました。
本記事では、既にデプロイ済みのアプリに対してdevelopブランチを導入し、ステージング環境での確認を経て本番環境にリリースするまでの流れと、実装時に気をつけたいポイントをあわせてまとめています。

本記事で紹介する運用は、Git-flowを簡略化したものです。
releaseブランチやhotfixブランチは省略し、
個人開発向けに「mainブランチ / developブランチ / 機能開発(feature)ブランチ」のみで運用しています。

今回は「Git-flowの流れを体験すること」を目的に、簡易的なステージング確認方法を採用しています。

前提条件

GitHubでリポジトリ管理
Renderにてデプロイ済み（mainブランチ）
個人開発（チーム開発ではない）

導入したブランチ運用（Git-flowを参考）

mainブランチ (本番環境)
  ↑
developブランチ (ステージング環境)
  ↑
機能開発(feature)ブランチ（今回例としてdesign/comment-buttonブランチとしています）

Git-flowの詳細な解説については、以下の公式ドキュメントが参考になります。

なぜdevelopブランチを作るのか

mainブランチに直接作業してしまうと、実装途中の不具合やバグによって本番環境のアプリが止まってしまう危険性があります。
一方で、developブランチに直接作業してしまうと、チーム開発の場合は他のメンバーの作業と競合したり、未完成のコードを共有してしまう可能性があります。あくまでdevelopブランチは次のリリースに向けて複数の変更を集めた場所です。
そのため、
機能開発(feature)ブランチ：実装作業を行う場所
developブランチ：複数の変更をまとめ、動作確認を行う場所
mainブランチ：本番リリース用の安定したコードを置く場所
と役割を分けます。

機能開発ブランチで実装した内容をdevelopブランチにマージし、
ステージング環境(本番リリース前の動作検証を行う環境)で問題なく動作することを確認したうえで、最終的にmainブランチへマージすることで、本番環境の品質を保ちながら安全にリリースすることができます。

実装手順

1. developブランチの作成

既存のmainブランチから、developブランチを作成します。

# mainブランチが最新であることを確認
git checkout main
git pull origin main

# developブランチを作成
git switch -c develop

# リモートリポジトリにpush
git push origin develop

developブランチを作る前に必ずmainブランチが最新の状態であることを確認しましょう。

2. 機能開発の流れ

developブランチから機能開発用ブランチを切り、実装をし、リモートにpushします。
今回例として、既存の個人開発アプリのコメント投稿ボタンデザインの変更作業を行いました。

# developブランチを最新にする
git checkout develop
git pull origin develop

# 機能開発用のブランチを作成
git switch -c design/comment-button

# 実装後、コミット
git add .
git commit -m 'コメント投稿ボタンデザイン変更'

# リモートにpush
git push origin design/comment-button

3. プルリクエストの作成、developブランチにマージ

GitHubでプルリクエストを作成します。自分のGithubのPull requestsタブに移動し、先ほどあげたプルリクエストを確認してください。

Base（マージ先）をdevelopに変更してプルリクをあげ、merge pull requestします。
Base: develop ← Compare: design/comment-button
Baseは「変更を取り込みたいブランチ」、
Compareは「変更元のブランチ」を意味します。
マージ後、delete branchをし、作業ブランチを削除しましょう（後片付け）。
次にローカルのdevelopブランチを更新します。

git checkout develop
git pull origin develop

ローカルでも作業ブランチは削除しましょう。

 # まず、削除したいブランチ以外に切り替える
git checkout main
# または
git checkout develop

# ローカルブランチを削除
git branch -d design/comment-button

4. ステージング環境で動作確認（飛ばしてもOK）

実務では、本番環境とは別にステージング環境用にwebサービスを作成してデプロイし、動作を確認するケースが多いようです。
しかし、ステージング環境用にDBなどストレージを確保するのは個人開発ではハードルが高いため、今回はデプロイ済みの本番環境のデプロイブランチをdevelopに一時的に変更し、問題ないかどうかを確認します。

この方法は本番環境に developブランチのコードが一時的に反映されるためあまりおすすめできません！あくまで勉強のための個人開発なので、サービス利用者がほぼおらず本番環境に万が一影響があっても良いという方だけ採用してください。

お勧めできない理由

手動切り替えのリスク
設定変更を忘れると、意図しないブランチがデプロイされてしまう可能性あり。
切り替えのタイミングでヒューマンエラーが起きやすい。
ステージング環境が常に存在しない
developを確認している間、本番環境がmainから更新されない。
実務の運用と異なる
実務では、多くの場合ステージング環境と本番環境は独立して存在するのが一般的。
同じサービスを使い回す運用は一般的でない。

Renderの該当する既存アプリのWeb Serviceを選択し、
Settingsを開いて「Build & Deploy」の項目を確認します。

ここをmainからdevelopに変更。
変更するとbuild、deploy作業が走ると思います。
デプロイ後動作を確認します。
これでステージング環境での確認作業が終了しました。
問題ないことを確認したらすぐにmainに戻しておきましょう。

5. 本番環境へリリース

ステージング環境でdevelopブランチが問題ないことを確認したら、いよいよmainブランチにdevelopブランチをマージします。

# develop が最新であることを確認
git checkout develop
git pull origin develop

# main ブランチに切り替え最新の状態する
git checkout main
git pull origin main

Github上をPullrequestsタブを確認すると

developブランチの変更が上がっていると思いますので
GitHubで本番リリース用のプルリクエストを作成します。
Base（マージ先）をmainにしてプルリクをあげ、merge pull requestします。
Base: main ← Compare: develop

マージ後、本番環境（mainブランチ）が自動デプロイされます。
最後にmainブランチを最新の状態にしましょう。

# main ブランチに切り替え最新の状態する
git checkout main
git pull origin main

以上で機能開発後、ステージング環境での動作確認を経て本番環境にリリースという一連の流れを体験することができました。

最後に

個人開発でも「develop → main」というワンクッションを挟むことで、mainに直接マージせず、事前に動作確認でき、安全なリリースフローを体験することができました。
これまで実務におけるdevelopブランチの役割が曖昧だったのですが、実際に運用してみることで、チーム開発においてなぜブランチを分けるのか、どの段階でコードを統合・検証するのかを具体的にイメージできるようになりました。
今回採用したステージング環境の方法は実務とは異なりますが、Git-flowの考え方やブランチ運用の意図を理解するという点では十分に学びがあり、個人開発でも取り入れる価値があると感じました。