Zenn
✨

GitHub運用

2022/09/13に公開
Git
tech

私の勤めている会社では、GitHub運用にgit-flow。Issueドリブン開発を採用しています。
gitは開発する上で、とても重要な概念なので自分自身の理解と整理のために、git-flow、Issueドリブン、ブランチの命名規則などについてまとめてみました。

git-flow

正確にいうと「A successful Git branching model」をサポートするためのツールの名称らしいです。

git-flowでは、下記の５つのブランチを利用します。

masterブランチ

リリースしたソースコードを管理するためのブランチ。

developブランチ

開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。
featureブランチなど、他のブランチで行った作業は、ここにマージされる。

featureブランチ

主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにdevelopブランチより
featureブランチを作成し、作業を行う。

releaseブランチ

リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブランチをdevelopブランチより作成し、微調整を行う。
releaseブランチで作業した内容を、同時にdevelopブランチにもマージし、最新の開発版を反映させる。
releaseブランチを作成することで、リリース準備と次のバージョンに向けた開発のコードを分けることができる。

hotfixesブランチ

リリースされたソフトウェアに緊急の修正を行うためのブランチ。

  • master：　本番、releaseからマージ
  • develop:　開発環境
  • release:　ステージング環境
  • feature:　各機能開発環境　developからブランチを切る
  • hotfixes:　バグ対応

Issueドリブン開発・命名規則

Issueドリブン開発とは、実装における課題をタスクとして管理・運用する開発手法になります。
新規機能の追加やバグ修正などをIssueとして立てて、それを解決するためのブランチを切り、
コミットやPRでIssueを参照しながら開発を進めるという流れになります。

Issueドリブン開発の流れ

1.　GitHub上で、課題（タスク）のIssueを立てる。
2.　Issue番号が発行されるので、Issue番号を付与したブランチを作成する。例）feature/#1-add-login
3.　Issueの課題（タスク）に沿った、開発を行う。
4.　開発が完了したら、developブランチにコミットする。PRのコメントにclose #1と記述すると、マージ後にIssueがクローズされます。

コミットメッセージ

例）[fix]refs #1 add-login

  • fix：バグ修正
  • add：新規（ファイル）機能追加
  • update：機能修正（バグではない）
  • clean：整理（リファクタリング等）
  • remove：削除（ファイル）

Discussion