はじめに
Gitのブランチを作成する際にfeature/〇〇などのブランチ名をつけたことがあると思うのですが、正直意味を理解していないまま使っていたりしませんか？
意外と知らないブランチの知識をまとめてみました！！
ブランチについて
作業履歴を枝分かれさせていきバージョン管理していくためのもの。切り取ったブランチは他ブランチの影響を受けないため複数の作業を同時に進めることが出来ます。
チームで開発する際は、それぞれが他のメンバーの作業の影響を受けずに開発が可能で、個人開発する際も作業履歴を綺麗に管理して見やすくなるので、利用しない選択肢は無い。
git-flowとは？
チーム開発では、特にルールを設けずにブランチを使っていると、無秩序にブランチの作成やマージが行われ、リポジトリが混沌化してきます。こうした問題を解決するために、「ブランチモデル」というブランチ管理方法が考案されました。
そこで、今回紹介するブランチモデル「git-flow」は、割と広く使われているブランチモデルです。
ブランチの種類
masterブランチ
Gitでリポジトリを新規作成するとデフォルトで作成されるブランチのこと。
git-flowでは、masterブランチに直接コミットすることはなく、マージを行うだけのブランチになります。
例 : master
developブランチ
開発の中心となるブランチのこと。
開発中は、developブランチからブランチを切って、作業完了後に再びマージするという作業を繰り返します。
リポジトリを新規作成したときに、masterブランチからdevelopブランチを切って作成します。
例 : develop/[バージョン番号など]
featureブランチ
機能の追加や変更、バグ修正などを行うブランチのこと。
ブランチの名前は、変更の内容が分かるような名称にします。developブランチから派生させ、作業完了後に再び developブランチにマージします。そして、マージ完了後に削除します。
例 : feature/[派生元バージョン番号など]/[機能名など]
releaseブランチ
製品をリリースするために使うブランチのこと。
製品のリリース時には、関連する作業が必要になる場合が多いでしょう。
developブランチからreleaseブランチを切って、そのブランチでリリース作業を行います。リリース作業が完了したら、masterブランチと developブランチにマージし、masterブランチのマージコミットにリリースタグ（バージョンなど）を打ち、その後、release ブランチは削除する。
例 : release/[バージョン番号]
hotfixブランチ
製品のリリース時に重大な不具合が見つかった際に使うブランチのこと。
masterブランチからhotfixブランチを切って、緊急の修正を行う。修正完了後には、masterブランチとdevelopブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後、hotfixブランチは削除します。
例 : hotfix/[バージョン番号]/[バグ識別名] or hotfix/[バグ識別名]
supportブランチ
旧バージョンの保守とリリースを行うブランチのこと。サポートが必要なバージョンのmaster ブランチのコミットから派生させ、サポートを終了するまで独立してバグフィックスやリリースを行う。
例 : support/[バージョン番号]
終わりに
最初に例で出したfeature/〇〇以外にもいろんなブランチの種類がありましたね！
こういったルールを設けて開発することで、リポジトリが綺麗さを保って確認等もしやすくなります。
是非開発時は、ブランチモデルを参考にルールを定めましょう！！
参考
[Gitブランチについての基本まとめ]
(https://qiita.com/katsunory/items/252c5fd2f70480af9bbb)
[Git-flow ～Gitのブランチモデルを知る～]
(https://tracpath.com/bootcamp/learning_git_git_flow.html)