Skip to main content

Git のワークフロー

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

使用するブランチの役割​

ブランチ名命名規則説明
Releaserelease現在本番環境にリリースされているブランチ
Mastermaster常時デプロイ可能なブランチ
Featurefeature/#IssueNumber-*

Masterブランチから生やしたブランチ。 各 issue,または epic 毎に作る

Topictopic/*Featureブランチから生やしたブランチ。Featureブランチにマージされる。
Fixfix/#IssueNumber-*

Masterブランチから生やしたブランチ。不具合対応のときに利用する。 issue番号を必ず残す

Hotfixhotfix/#IssueNumber-*

Releaseブランチから生やしたブランチ。緊急対応のときに利用する。 issue番号を必ず残す

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

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

緊急バグ対応​

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

基本原則​

機能追加、バグフィックスなどは issue の番号と説明的な名前のブランチ名にして master から作成する

  • hotfixブランチの場合はhotfix/ + issue の番号 と説明的な名前のブランチ名で命名する
  • ブランチ名で複数の単語を使う場合は-を使う

フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、Pull Request を作成する

  • フィードバックや助言が欲しい時、または作りかけの Pull Request には[WIP] をつける

issue テンプレート​

設定方法

要望テンプレート​

Title: 新規提案。

Description:このプロジェクトに必要と思った内容の提案。


# 目的

# 実装案

# 備考```

### 不具合テンプレート

Title:不具合報告。

Description:不具合と感じ改善が必要と思ったものの報告。

[設定方法](https://docs.github.com/ja/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository)```

# 概要

# 再現手順

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

# 原因と思われる部分

# 修正案 / 理想と思われるの状況

# 備考

Pull Request テンプレート​

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

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

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

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

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

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