こんにちは鈴木です。
エンジニアとして働いている人には当たり前の概念ですが、ブランチを複数作る理由を紹介していきます。
まだ下記記事を読んでいない場合は、先に下記記事を読んでからこちらの記事を読んでみてください！
鈴木の読み返す日記として書いていきます。
ぜひ参考にしてください。
ブランチとは
履歴などの流れを分岐しながら記録していくためのもの。分岐したブランチは他のブランチの影響を受けないので、リポジトリが同じでも複数の変更を同時に進めることができる。
ブランチを作ることを「ブランチを切る」という。
なぜブランチを複数作成するのか？
結論：バグを起こさないように品質を管理するため！
まずは、リポジトリ内の構成から説明していくよ！
リポジトリ
Gitで管理されたフォルダのこと。常にフォルダ内に変更がないか監視している。
リポジトリ内の基本構成
開発では、基本的にリモートリポジトリでブランチを切ります（作る）。
すずきがGitflowでブランチを切っているので、今回はGitflowを参考に紹介していくよ！
Gitflow
Gitflowとは、フィーチャー ブランチと複数のブランチを使用する代替 Git ブランチ モデルのことです。
つまりどう言うことかは図で紹介していくよ！
基本的構成は「master」「develop」「feature」の３つにブランチを切る
イメージはこんな感じ！
実際はmasterとdevelopの間にブランチが入ったりするけど大枠で紹介するよ！
上記の図をアプリで例えます。
まず今回のアプリはもうリリースがされています。
その中でアップデートでバージョンを上げていく（新機能をつけていく）開発を行なっていると思ってください。
その上での各ブランチの役割を紹介します。
流れとしては、ローカルリポジトリで修正を加え、修正したファイルと履歴をリモートリポジトリのfeatureにプッシュする。
featureからdevelopに合流（マージ）させる前に、自分が修正したファイル等のバグがないかチームメンバーで確認をします。
その確認依頼をPR（Pull Request）といい、PRが承認されたらdevelopに合流（マージ）する。
ちなみにこのPRをした際に「確認してー！」と依頼することをRv依頼と言います。
プッシュ
リモートリポジトリにローカルリポジトリからアップロードすること
Gitの流れ
ローカルリポジトリからプッシュする。
PRしたらRv依頼をする
これでアプリがアップデート完了
なぜブランチは複数作る必要があるのか
それぞれのブランチを役割や流れをみてなんとなく察したかもしれませんが、もし仮にfeatureやdevelopがなく直接masterにプッシュしていった場合、バグでアプリが止まってしまうかもしれません。
同じく直接developで作業した場合、みんなで共有をしているため、自分がバグをプッシュしてしまったら、開発チーム全員に迷惑がかかります。
なので、featureで開発者レベルで品質を担保して、developにて試験をおこない品質を担保してアプリをリリースしないとバグったアプリが世に出ることになってしまうから、ブランチは複数必要なのです。
