gitのブランチ戦略

gitのブランチ戦略 Takashi Abe Mynet Inc. 24/02 2015

git初心者あるある

ブランチの子供が出来過ぎてマージ困難

いつの間にかmasterに取り込まれるコミット

ブランチ戦略決めましょう

ブランチ戦略とは新機能開発やリリースなど、各用途専用のブランチを用意する各ブランチに明確な意図を持たせて混ざらないようにすることで複数人での開発をやりやすくする

メジャーなブランチ戦略 git-flow 5種類のブランチを使って機能開発、リリース、hotfix などの役割を明確に分けている堅牢なモデルだが慣れないうちは煩雑 github flow masterと機能開発ブランチのみを持つ masterはすぐデプロイするワイルドなモデル

git-flow

使用するブランチ develop 開発安定版ブランチ。featureブランチなどはここにマージされる feature 機能開発用ブランチ。機能開発やバグフィックスなどの開発を機能ごとに開発するためのブランチ。最終的にdevelopにマージされる release リリース用ブランチ。リリース時にdevelopから作成される。リリース作業中でも developに対する変更を行えるようになる。 master
安定版ブランチ。リリースを終えたreleaseブランチからmasterにマージされる。 hotfix 緊急のバグ修正ブランチ。masterから作成され、releaseブランチを介さずにそのままmasterにマージされる。

feature

release

hotfix

git-flowの特徴 releaseやhotfixのための手順が明確に定められていてプロダクションに上げるコードを堅牢に保つことが出来る使用するブランチが多いため手順が煩雑

github flow

使用するブランチ master 安定版、リリース用ブランチ。featureブランチは全て masterにマージされ、即座にデプロイ対象になる。 feature 機能開発用ブランチ。masterから作成され、そのまま masterにマージされる。

github flowの特徴使用するブランチが最小限で理解しやすい masterを常にデプロイ可能な状態にしないといけないコードレビュー CI

弊チームのブランチ戦略

やりたいこと

やりたいこと規模の大きい新機能など、複数人で1つの機能を作りたいリリースする機能は絞る場合があるリリース前にQA環境でQAしたい

git-flowのアレンジ

featureブランチの亜種を2 つ追加した

追加したfeatureブランチ feature-develop 1つの大きな機能における開発安定版。developから作成され、feature-developから更にfeatureブランチを作成する。featureブランチはfeature-developブランチにマージされる。 QA QA用ブランチ。developから作成され、次回リリースに盛り込むブランチを全てマージする。ここにはfeature- developブランチが含まれる。

機能開発フロー developブランチからfeature-developブランチを作成 feature-developブランチからfeatureブランチを作成 featureブランチをfeature-developブランチにマージ

リリースフロー feature-developブランチをQAブランチにマージ QA中の修正は全てQAブランチにマージ QAが完了したらreleaseブランチにマージ

ブランチを作るときブランチ作成時は常にリモートブランチから作成することを意識する git checkout -b feature/a origin/develop GitHubなどのGUIフロントエンドが使えればそれでも古いローカルブランチから作成することによってリモート
の最新コミットが取り込まれないコンフリクトの原因になる

CUIでやる SourceTreeなど優秀なGUIツールを使うのもいいが、git の構造を知るにはCUIでやると捗るローカル/リモートリポジトリの違い working copy,index,ローカルリポジトリの違い慣れるとGUIでやるよりも捗る(と思う)

gitのブランチ戦略

gitのブランチ戦略

takashabe

More Decks by takashabe

Other Decks in Programming

Featured

Transcript