GitHub運用

2022/09/13に公開

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

git-flow

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

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

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

ログインするとコメントできます