Git のワークフロー

一人での開発の場合、github flowを好み、複数人の開発では、git flowを好みます。

使用するブランチの役割

release ブランチ
現在本番環境にリリースされているブランチ
masterブランチ
常時デプロイ可能なブランチ
featureブランチ
masterブランチから生やしたブランチ。各 issue,または epic 毎に作る
topicブランチ
featureブランチから生やしたブランチ。featureブランチにマージされる。
hotfixブランチ
releaseブランチから生やしたブランチ。緊急対応のときに利用する。

通常の開発のブランチ管理の流れ

  • master から feature ブランチを切る
  • feature ブランチまたは feature ブランチの子ブランチ(topic ブランチ)で作業
  • 作業完了及びデバッグ完了したら親ブランチ(枝元のブランチ)にプルリクエストを出す
  • コードレビューとデバックが終わったらマージ後、feature ブランチの削除をして、すぐに master に取り込む。
  • プロジェクト管理をしている場合はチケットを本番反映済みにする

緊急不具合対応の場合

  • master から hotfix ブランチを生やす。修正の規模が大きい場合は hotfix ブランチから feature ブランチを生やす
  • feature ブランチで作業完了及びデバッグ完了したら hotfix ブランチにプルリクエストを出しレビュアーにマージしてもらう
  • hotfix ブランチを release ブランチにマージ。その後、release ブランチを master ブランチマージする。

基本原則

機能追加、バグフィックスなどは issue の番号と説明的な名前のブランチ名にして master から作成する
  • hotfixブランチの場合はhotfix/ + issue の番号 と説明的な名前のブランチ名で命名する
  • ブランチ名で複数の単語を使う場合は-を使う
フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、Pull Request を作成する
  • フィードバックや助言が欲しい時、または作りかけの Pull Request には[WIP] をつける

issue テンプレート

設定方法

要望テンプレート

# 概要/背景

# 目的

# 得られるもの

# 実装案

# 備考

不具合テンプレート

設定方法

# 概要

# 再現手順

# 修正しないとどう困るか

# 原因と思われる部分

# 修正案

# 備考

Pull Request テンプレート

<!-- あくまでテンプレートなので必ずしもすべての項目を埋めなくてよい -->

# 概要/対応issue
<!-- 変更の目的 もしくは 関連する Issue 番号 -->

# 変更内容
<!-- ビューの変更がある場合はスクショによる比較などがあるとわかりやすい -->

# 影響範囲
<!-- この関数を変更したのでこの機能にも影響がある、など -->

# 動作要件
<!-- 動作に必要な 環境変数 / 依存関係 / DBの更新 など -->

# 補足
<!-- レビューをする際に見てほしい点、ローカル環境で試す際の注意点、など -->