Git-flowの導入

一人だけで開発しているものなので、Gitのブランチ分けとかいらんかなと思っていたのですが、せっかくなので一般的なやり方を学ぶという意味でGit-flowでやってみようと思います。
Git-flowについてはこちらのサイトなどで学びました。
【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう
※普段仕事ではGitLabを使っているので、時々用語がGitHubではなくGitLabのものになってしまっているかもしれません…

hgn開発に当てはめるとこうなるかなと思います。

  • master → 本番サーバーで動いているソースコード
  • develop → 開発サーバーで動かしていいソースコード。開発用
  • release → 本番サーバーアップデート前の最終チェック用
  • feature/xxxx → 実装ブランチ。機能毎に作成。
  • hotfix/xxxx → 本番サーバーで出たエラーを緊急で修正する用

それぞれのブランチについて、もう少し掘り下げてみます。でも、その前に…

サーバーについておさらい

その前に、hgnで使っているサーバーというか環境についておさらいです。

本番

https://horrorgame.netです。

ステージング

本番に乗せる直前に、本番とほとんど変わらない環境で動作確認するためのサーバーです。予算の都合上、本番サーバーと同居しています。略称stg

開発

このブログが稼働しているサーバーです。ブログとは別にhgnを動作させて、自動化させたテストツールを日夜稼働させたいと思っています。

ローカル

私の個人のPC上の環境です。ここでプログラムを実装していきます。ちなみにPCはDellのXPS 13 (2019)です。CPUが第10世代のCore i7のやつです。

hgnでの各ブランチの使い方

では、各ブランチをどのように扱っていく予定か紹介していきます。hgnではこういう風に使うという紹介なので、プロジェクトによっては微妙に使い方が違うこともあるかもしれません。

developブランチ

開発中ソースコードの大元となるブランチです。ここに対して直接ソースコードをpushすることはありません。次に記載するfutureブランチからマージされます。マージされると自動で開発サーバーにデプロイしてテストを実行します。これをjenkinsでやります。というか、まだ設定できてないのでそういう風にできたらいいなぁという希望です🤣

futureブランチ

developブランチを元に作成します。一つの機能毎に作成し、ローカルで実装が終わったらpush、developブランチにマージします。devサーバーでの自動テストでエラーが出なければ、ブランチを削除して実装完了です。
future/(機能名のそれっぽい英語) という名前で作成します。

releaseブランチ

developブランチでテストを終えて、リリースできそうとなったら作成するブランチです。developを元に作成します。ブランチ作成時点でstgサーバーに自動でデプロイ&テストを実行します。不具合があれば、修正を反映します。特にサブのブランチは作成せずにreleaseブランチに直接pushします。
テストが無事に終わればリリース直前にmasterとdevelopへマージして、本ブランチは削除します。

masterブランチ

https://horrorgame.netで動いているソースコードを置きます。

hotfixブランチ

本番サーバーにあげてから見つかった不具合を緊急で直すときのブランチです。masterから作成し、不具合修正後にstgサーバーにアップします。stgサーバーで動作に問題がなければ、masterとdevelopにマージしてブランチを削除します。masterから本番にデプロイして緊急対応完了です。
hotfix/(不具合のそれっぽい英語) という名前で作成します。

タグ

gitにはタグという機能もあるので、これも使っていきます。バージョン付けって感じですかね?本番にリリースするタイミングで、適当にバージョンをつけていこうと思います。

コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA