なぜブランチルールが必要？

Gitのブランチルール作ってますか？
私はずっと個人開発でGitHubを使用してきましたが、ブランチ名は特に意識していませんでした。
一人で開発する場合は、それで良いかもしれませんが、
共同開発になるとブランチルールを作っておかないと収集がつかなくなります。

共同開発の際は、まずブランチの運用ルールの確認が必要になりますが、
基礎知識としてgit-flowやgithub-flowについて知っておくと役に立ちそうなので下記にまとめました。
※概念の話で、コマンドなどは書きません。

もし間違いなどあれば教えていただけると嬉しいです！

どんなブランチルールがある？

• git-flow
• github-flow

※会社ごとのルールや作るものによっても異なる。

git-flowについて

5つのブランチに分かれる

下記5つのブランチに分かれます。

• main
• hotfix
• release
• develop
• feature

masterとdevelopはいつも存在するブランチで、その他は必要に応じて追加分岐する。

イメージ

A successful Git branching modelを参考に作った図です。

各ブランチの意味

main

常にデプロイできる状態にしておく。（開発中のものを置かない）

hotfix

リリース後のバグ対応など緊急用。
mainから分岐する。mainへのマージ＋developmentへのマージも行う。

release

リリースの準備用。テストなど行う。
developから分岐。リリース準備ができたらmainとdevelopへマージする。

develop

開発用、このブランチで作業は行わない。
（作業はここからfeatureを分岐させる）
開発が終わったらリリース準備のためにreleaseへマージする。

feature

機能開発用。developから分岐してdevelopにマージする。
feature/xxxとして複数存在してOK。

簡単な使い方

SourceTreeなどgit-flowを簡単に使える機能がついているようです。

メリット

• 本番データと開発中データがしっかり分かれる。

デメリット

• 複雑（マージ先が複数あったりする）

github-flowについて

イメージ

github-flowはgit-flowをもっとシンプルにしたもの、というイメージです。

参考サイト

GitHub フロー

フロー

1. mainからブランチ（feature-xxなど）を作成。
2. ブランチ（feature-xxなど）で開発。
3. pull request を作成する
4. レビュー コメントに対応する
5. pull request をマージする
6. ブランチを削除する

メリット

• シンプル
• レビューしてもらえる

git-flowとgithub-flow結局どっち？

どちらが優れているということはなく、
作るものやプロダクトのリリース方法によって、最適なブランチ管理方法は異なります。
上記2つ（github-flow、github-flow）の概念を知っておけば、
会社で新たにルールを作ることになった時や初めてのプロジェクトに参加するときも
慌てずに済むと思います。

以上です！