社内布教活動用

1. ブランチ戦略
～ソフトウェア開発のマナー

2. ブランチ

3. ブランチとは
• ブランチとは、履歴の流れを分岐して記録していくためのもの
です。分岐したブランチは他のブランチの影響を受けないため、
同じリポジトリ中で複数の変更を同時に進めていくことができ
ます。
• また、分岐したブランチは他のブランチと合流(マージ)するこ
とで、一つのブランチにまとめ直すことが出来ます。

4. ブランチを使用しない開発フロー
• ブランチを使用しない開発フローでは、V1（バージョン1）
→V2→V3...のように、何か変更を加えるたびにバージョンが積
み重なっていきます。
V1 V2 V3 V4

5. ブランチを利用した開発フロー
• ブランチを利用した開発フローでは、バージョンの流れが同時
に複数存在します。 ブランチを使用した開発フローではバー
ジョンの積み重なり同時に複数存在します。
• どこかのタイミングで「メインのソースコードを綺麗に保ちた
いバージョンの流れ」に、「何か修正を加えたブランチ」を取
り込むことで変更を反映していきます。

6. V1
V1β
V2β
V2β+V
2α
V1α V2α
機能追加タスクでの分岐
バグ修正タスクでの分岐
V2β
バグ修正を先にリリース

7. ブランチのメリデメ

8. コードを綺麗に保てる
• 修正途中の中途半端なコードがメインブランチに含まれない
例えば、
・Aの開発は途中で、まだ暫く掛かる
・Bのバグ修正は完了した
という状況でBのみをリリースしたい場合、ブランチを利用しなかっ
た場合はAの修正を取り除かなければなりません。
これは非常に面倒なことです。
ブランチの場合は完了したコードのみをマージすることさえ守れば、
常にリリース可能な状態を保つことができます。

9. バージョンの流れを綺麗にしやすい
修正ごとにブランチを切らない場合、明確に「この修正はこの
バージョンにまとまっている」という区切りがありません。
修正ごとにブランチを切らない場合、構造がシンプルというメ
リットはあります。
ブランチを利用した開発フローでは、完了した修正ごとに変更を
取り込むため、ある修正が完了したタイミングで開発中の中途半
端なソースが混じる、ということを防ぐことができます。
「1つのブランチでは1つの修正をする」ことによって特定の機
能が追加されたタイミングでのソースコードを取得したり、切り
戻したりしやすくなります。

10. 操作が複雑
• ブランチを利用した開発フローの方が明らかに複雑です。

11. ブランチの切り方が難しい
「どういう単位でブランチを切ればいいのか？」ということを考える
のにそれなりにコストを使います。
・別々のブランチで同じ共通機能ができた
・マージした時点で他ブランチのコードが反映されるのでクラス名を
変えるブランチとそのクラスを使用する修正のブランチがあった場合
にマージの際にあとにマージした際に大幅に修正をする必要があった
このようなことが発生しうるので連携しあって無駄な作業を増やさな
いように気をつける必要があります

12. シンプルなブランチモデルから始めよう！

13. ディベロップ・メイン・リリース
• 開発用に分岐、リリース用に分岐
D2
Main
Release
リリース用ブランチ
分岐
マージ
マージ
マージ
D1
分岐 マージ
開発用ブランチ開発用ブランチ
分岐

14. • Develop
• 機能の追加ごとに Main から分岐し、 Main にマージする
• Main
• リリース準備ができたら Releaseへマージする
• 常に最新版のプログラムが配置してある
• Release
• リリースするためのブランチ
• 機能追加毎に開発ブランチを分けることにより、関係ない修正が一
緒にMainにマージされることを防ぐことができ、
• リリース単位でMainからマージされることによりリリースごとの変
更内容も明確となる

15. 他にも、、、

17. GitFlow
というツールも

18. まとめ
• ブランチの分け方は開発体制や開発サイクルによって最適なも
のは異なります。小規模であればあまりにも分岐、マージの頻
度が高いと非効率であったり、逆にキチンと分けなければバー
ジョンや修正内容が不明確になってしまったりもします。
• プロジェクトごとにそれぞれの最適なスタイルを見つけて貰う
必要はありますが、ブランチを取り入れることにより不要なミ
スを大幅に減らすことが見込まれます。
• まずはシンプルなDevelop、Main、Releaseに分岐するブラン
チモデルから取り入れてみましょう！