blog 開発

【チーム開発】リポジトリ内のブランチを複数作るのはなぜ?

こんにちは鈴木です。
エンジニアとして働いている人には当たり前の概念ですが、ブランチを複数作る理由を紹介していきます。

想定読者

  • 未経験のエンジニア
  • チーム開発が初めてのGitユーザー

まだ下記記事を読んでいない場合は、先に下記記事を読んでからこちらの記事を読んでみてください!

鈴木の読み返す日記として書いていきます。
ぜひ参考にしてください。

ブランチとは

履歴などの流れを分岐しながら記録していくためのもの。分岐したブランチは他のブランチの影響を受けないので、リポジトリが同じでも複数の変更を同時に進めることができる。

すずき

ブランチを作ることを「ブランチを切る」という。

なぜブランチを複数作成するのか?

結論バグを起こさないように品質を管理するため!

すずき

まずは、リポジトリ内の構成から説明していくよ!

リポジトリ

Gitで管理されたフォルダのこと。常にフォルダ内に変更がないか監視している。

リポジトリ内の基本構成

開発では、基本的にリモートリポジトリでブランチを切ります(作る)。

すずき

すずきがGitflowでブランチを切っているので、今回はGitflowを参考に紹介していくよ!

Gitflow

Gitflowとは、フィーチャー ブランチと複数のブランチを使用する代替 Git ブランチ モデルのことです。

すずき

つまりどう言うことかは図で紹介していくよ!

基本的構成は「master」「develop」「feature」の3つにブランチを切る

すずき

イメージはこんな感じ!
実際はmasterとdevelopの間にブランチが入ったりするけど大枠で紹介するよ!

上記の図をアプリで例えます。
まず今回のアプリはもうリリースがされています。
その中でアップデートでバージョンを上げていく(新機能をつけていく)開発を行なっていると思ってください。

その上での各ブランチの役割を紹介します。

master

公式のリリースのバージョンを管理するブランチ。商用(ユーザーが使う製品(=アプリ)のための)ブランチと同義です。

develop

featureブランチの組み込みブランチ。つまり、自分だけでなく開発メンバー全員で共有するブランチ。

feature

主に自分がメインで使うブランチ。
featureブランチは必ず親ブランチがdevelopでmasterを親にしてはいけない。
基本的にdevelopから分岐し、完成したらdevelopに合流(マージ)する

流れとしては、ローカルリポジトリで修正を加え、修正したファイルと履歴をリモートリポジトリのfeatureにプッシュする。
featureからdevelopに合流(マージ)させる前に、自分が修正したファイル等のバグがないかチームメンバーで確認をします。
その確認依頼をPR(Pull Request)といい、PRが承認されたらdevelopに合流(マージ)する。

ちなみにこのPRをした際に「確認してー!」と依頼することをRv依頼と言います。

プッシュ

リモートリポジトリにローカルリポジトリからアップロードすること

Gitの流れ

STEP
featureで開発をする

ローカルリポジトリからプッシュする。

STEP
featureからdevelopに合流(マージ)するためにPRする。

PRしたらRv依頼をする

STEP
バグを確認し、バグがない場合は、developに合流(マージ)する

STEP
developで試験が通った場合資材がmasterにマージされる

これでアプリがアップデート完了

なぜブランチは複数作る必要があるのか

それぞれのブランチを役割や流れをみてなんとなく察したかもしれませんが、もし仮にfeatureやdevelopがなく直接masterにプッシュしていった場合、バグでアプリが止まってしまうかもしれません。

同じく直接developで作業した場合、みんなで共有をしているため、自分がバグをプッシュしてしまったら、開発チーム全員に迷惑がかかります。
なので、featureで開発者レベルで品質を担保して、developにて試験をおこない品質を担保してアプリをリリースしないとバグったアプリが世に出ることになってしまうから、ブランチは複数必要なのです。

  • この記事を書いた人

鈴木陽介

現役Javaエンジニア

2000年生まれ

もうすぐ書籍を出版します。

-blog, 開発