はじめに
記事をご覧いただきありがとうございます。
みなさんGitHubはどのようにお使いでしょうか。
私は今まで、commit・push・pullくらいしか使っていませんでした。（もったいない！）
エンジニアの知人にブランチはどんな方法で運用してる？と聞かれてからいろいろと調べたので
それについて私なりに記事にできたらなと思ったのでこの記事を作成しました。
筆者は独学でプログラミングについて学んでいる最中なので、
あくまで一つの意見として参考にする程度にしてください！
ブランチの運用方法
ブランチの有名な運用方法は３つほどあるらしいです。
1. Git flow
2. GitHub flow
3. GitLab flow
それぞれの特徴について軽く説明します。
1.Git flow
Git flowはブランチを下記の５つに分けます。
master：実際の製品ファイルを置くブランチ、リリーズしたらタグ付けする。
develop：開発ブランチ。リリース前の最新のブランチであり、リリースの準備ができたらmasterブランチにマージします。
feature：追加機能やバグ修正を行う開発用のブランチ。developブランチから分岐し、ソース修正後にdevelopブランチにマージします。
release：リリース前に準備や微調整をおこなうブランチ。developブランチから分岐し、タグ付け（図：1.0）をします。調整後はmasterブランチにマージします。次にdevelopブランチにマージします。
hot-fix：masterブランチで緊急修正を行うブランチ。masterブランチから分岐し、masterブランチにマージしタグ付けをします。
正直、素人の私からするとブランチが多すぎてどこで修正すればいいのか、どこの修正をすればいいのかなど、
勘違いしてしまってミスに繋がりそうな気がします。
ただ、各ブランチで実施する作業は決まっているので自分が慣れれば使い安いのかもしれません。
2. GitHub flow
GitHub flowはブランチを下記の２つに分けます。
master：常時デプロイ可能である。（常に安定しているブランチで、リリース可能な状態であるということ）
作業用ブランチ：masterブランチから分岐し、masterブランチにマージする。ブランチ名はなんの作業をしているかわかるようにする。
かなりシンプルで個人的には一番いいなと思います(単純)
常にmasterブランチはリリースできる状態のものを置いておき、
追加したい機能ができたらその機能を追加するためのブランチを切るだけです。
例えば、「検索ボタンを追加」という作業をおこないたかったら、
「名前_addSearchButton」みたいな感じですかね？
誰が作業するためのブランチかもわかるのでいいですね！
3. GitLab flow
GitLab flowはブランチを下記の５つに分けます。
master：開発用のブランチ。直接変更（コミット）はしない。
feature：開発用のブランチ。機能追加用。masterから分岐し、masterにマージする。マージ後は削除する。
hotfix：開発用のブランチ。バグ対応用。masterから分岐し、全ブランチにマージする。全ブランチでマージ後は削除する。
pre-production：リリース前のテスト用ブランチ。masterブランチから分岐し、productionブランチにマージする。Git flowでいうreleaseブランチ。
production：リリース用ブランチ。
こちらも結構簡単ですね。
featureブランチとhotfixブランチは毎回削除するのブランチの構成もスッキリしていてわかりやすいと思います。
ただ、masterブランチからリリース前とリリース用でブランチが分かれているので、
Git flow同様に個人的には少しとっつきにくいです...。
これらの有名な運用方法ですが、個人的にGitHub flowがいいなと思ったのでそちらについて掘り下げていきます！
GitHub flowについて
GitHub flowはシンプルな管理方法をしたブランチ運用なのは先ほど記載しましたが、
それ以外にも下記のような利点があるらしいです。
・ルールが簡単なため導入コストが低く抑えられる
・インストールの必要がない
・デプロイや修正を素早く行うことができる
GitHub flowの最大の強みは３つ目だと思います。（違ったらすみません）
作業後にmasterブランチにマージするだけなので管理者側もそこさえ注意してチェックしておけば良さそうで楽ですもんね。
GitHub flowにはもちろん運用ルールがあるわけですが、
そのルールとは次のような内容になります。
1. masterブランチは、常時デプロイ可能な状態を保つ
2. 全てのブランチはmasterブランチから作成する
3. 作業内容が分かるようなブランチ名をつける
4. 作業中のブランチは定期的にプッシュする
5. Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
6. マージされたmasterブランチのコードはすぐにデプロイする
7. デプロイ後は速やかに作業していたブランチを削除する
1. masterブランチは、常時デプロイ可能な状態を保つ
このルールを徹底することにより、masterブランチは常にデプロイ可能な状態が保障されます。
2. 全てのブランチはmasterブランチから作成する
1 により、masterブランチがデプロイ可能な状態であることは保障されているので、
安心してそこから新しいブランチを作成することができます。
3. 作業内容が分かるようなブランチ名をつける
どのような目的で作成されたブランチなのかブランチ名から推測できるので、複数のブランチを管理する際に便利です。
また、ブランチ名の中でもルールを決めておくともっと便利かなと思いました。
機能追加をする場合のブランチ名：feature（機能を表す名称）
例）feature-user-icon
バグ修正の場合：fix（修正を表す名称）
例）fix-login-animation
みたいな感じですかね！
4. 作業中のブランチは定期的にプッシュする
作業中のブランチを定期的にpushすると、その時点の最新の作業がリモートにバックアップされます。
それだけでなく、他開発者が git getch すれば自分以外の課題がどのように進んでいるのかを確認できるらしいです。
5. Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
でました！
GitHubといったらPull Requestが最初に思い浮かんでしまうくらい優秀な機能ですよね！
Pull Requestによりコードレビューが行えるので上司や他の開発者にコードを確認してもらうことができます。
コードに問題がなかった場合はmasterにマージをしてデプロイすぐにデプロイすることができます。
少し心配なのが、上司や他の開発者も気づかないミスが会った時に、
masterの内容がデプロイできない状態のものになってしまうことですが、
これはPull Request前や、マージ前にテスト環境でテストを行えば問題ないのかなとも思います。
6. マージされたmasterブランチのコードはすぐにデプロイする
マージされたものは、デプロイできる状態のもののはずなので、すぐにデプロイします！
7. デプロイ後は速やかに作業していたブランチを削除する
作業が終わったブランチがいつまでも残らないように削除する必要があると思いますので削除！
簡単ですね！
さいごに
色々と調べていて、自分自身全くGitHubを使いこなせていなかったなと思いました。
業務で別の運用方法を採用していたらそちらを使うしかありませんが、
個人的にはこの運用方法でリリースしているアプリの管理をして行こうと思いました。
次の記事では、実際のGitHub flowの流れを記事にしてみたいと思います。
最後までご覧いただきありがとうございました。