Gitの基本ルール
Git-flow
基本的にはGit-flowの考えに則ります。
案件によっては若干の変更などもあると思うので、そこは柔軟に対応してください。
ブランチ
master（main）
production（製品）コードが格納されるブランチ。
運用に合わせ調整されるが、納品ソースも最終的にmasterから切り出される。
releaseブランチ
継続開発系でいうとリリースに向けたブランチ。
スポット制作でいうと、フェーズに合わせてmasterにマージすべきものを集約するブランチ。
例えば、フェーズ1では5ページ作成し、フェーズにでは追加で1ページとフェーズ1で作成したページの改修があるという場合にdevelopからフェーズ2リリース用のブランチが切られる。
当然マージ分が用意できるまではdevelopで作業がされるので、スポットの制作時には不要のことが多い。
hotfixブランチ
バグ対応、障害対応ブランチ。
developで開発中にmasterで問題が起きた場合に対応するブランチ。
対応分はdevelopにもマージされる。
マージ後はブランチが削除されることも多い。
developブランチ
開発コードブランチ。
基本的に開発時のコードの集約場所になる。
featureブランチ
作業ブランチ。
各々の作業はというような感じでブランチを切り作業を行う。
マージ先はdevelopとtestのみ。
git-flowにはないが、あると便利なブランチ
testブランチ
機能テスト用ブランチ。
機能テストとして検証を行う用の第二のdevelopブランチ的立ち位置。
切り出し元はdevelopまたはfeature。
マージ先はdevelopになるが、featureでは粒度として大きい場合や、
複数のfeatureを集約してテストする場合などに用いる。
developへマージ後は削除される場合もある。
PullRequest（PR）に関して
小規模なスポット案件では必ずではない。
教育目的でのPR＋レビューは適宜行なって良し。
機能開発系に関しては、壁打ちとして設計の問題点がないか、
思想的な部分も含めあらかじめ共有しておくという意味も込めて行う方が良い。
PRのコメントでどこに関してレビューをしてほしいか、不安点や前提の考えを含め
「こうしようと思っているけど」と記載すると、
レビュアーが何を見れば・考えればいいかが伝わり効率的。
機能開発系においても、慣習的な部分に関してはそこまで必要としないので、PJ開始時にスコープを定めておく方が良い。
オートデプロイに関して
AWSやCloudFlare、そのほかホスティングなどへオートデプロイをする場合には、
masterとdevelopとtestをデプロイ対象として設定する。
feature→developへのPullRequest時にはローカルで確認するが、
エンジニア以外にも確認が必要な場合はtestを利用すると良い。