前回のおさらい
【Unity/Git】Unityでチーム開発をする(1) 概要と初期設定編
上記エントリーで、Unity+Gitでチーム開発する際の初期設定まで終えました。
残念なことに、ツールを導入しただけではチーム開発が上手くいかず、遠からずリポジトリを消してやり直したくなることでしょう…。
チーム開発において有用なブランチモデルを学び、幸せになりましょう。
ブランチモデルとは
これまで先人たちがGitを利用していく中で、たくさんの地雷を踏みぬいた結果、チーム開発におけるGit上でのブランチ管理手法を編み出してくれています。
有名どころとして、以下のようなモデルがありますが、今回は私が利用していたGitFlowについて記載します。
(私見ですが、恐らく一番有名なブランチモデルだと思います)
- GitFlow
- GitHubFlow
- GitLabFlow
ブランチモデルを適用しない例
はい、皆さん。ご自分のGitブランチを思い出してください。
下記の様なブランチ構成になっていませんか？
チーム開発で下記の様なブランチのまま進めると地獄を見ます。
上記の様なmaster1本で開発を進めるにあたっては下記の問題があります。
- 開発途中の(正常に動かない)コミットをPushできない
- Pushした場合、ブランチは1本なので、正常に動かないコードをPullしたメンバー全員に影響が及びます
- タスクの開始～終了コミットが追えない
- タスクの開始～終了をコミットメッセージから追わなければならないので、コミットメッセージの入力ルールを設けていて尚且つ、抜けが無いことを保証しなければならず、実質的に無理。また、間に関係のないコミットが挟まっているので、特定のタスクで障害が混入した場合に、単純に差分を出すことができなくなります
他にも沢山あるとは思いますが、パッと思いつくだけでも上記の様にクリティカルな問題が発生することがわかります。
GitFlowを用いたブランチ管理
GitFlowに登場するブランチ
GitFlowでは、下記表のブランチが登場します。
とりあえず、最低限master, develop, featureの3つだけは覚えておいてください。
| ブランチ名 | 説明 |
|---|---|
| master | 正式にリリースする成果物をコミットするブランチ |
| hotfix | リリースした成果物(master)に緊急の不具合修正が必要となった場合にコミットするブランチ(正直使ったことない) |
| releas | リリース準備に使用するブランチ |
| develop | 開発ブランチ。各featureの成果物を集約する |
| feature | 各タスクの開発ブランチ。担当者が個々人で開発を進める際にコミットする |
各ブランチの関係は以下のようになっています。
GitFlowを用いたブランチ管理の例
開発がすんなり行くと、以下のようなブランチ構成になります。
各担当者はFeatureブランチの中でそれぞれ開発を進めることができ、タスクがブランチと紐づくため、非常に管理がしやすくなります。
featureブランチの粒度
1feature=1タスクにすると良いでしょう。1タスクって何かというとWBSの最下層とイコールです。
更に言うと、チケット駆動開発におけるチケット=1featureにすると、PJ管理上とても良いと思いますが、まだ実践したことがありません。
SourceTreeとJIRAで連携していい感じにチケット駆動ができるという情報を見た覚えがあるので、そのうちやりたい。
コミットメッセージの規則(18/03/27追記)
「GitFlowを用いたブランチ管理の例」で書いた図には、敢えて良くないコミットメッセージを書きました。
「Score機能を作成」等です。
これでは、Score機能の作成中なのか、作成完了なのか判然としません。
ステータスを表さずに体言止めを使うなということです。
そこで、前職ではコミットメッセージの規則として以下を設けていました。
「(○○の)○○を○○中 or 完了」
上記に従うと例えばこんな感じになります。
「Score機能のカウントロジックを作成中」
このようにすることで、多少はどういった意図のコミットか分かるようになるので、チーム内でどのようなルールとするか決めておくとよいでしょう。
SourceTree上でGitFlowを使う
SourceTreeには、GitFlowでブランチを管理するための機能が標準で搭載されています。
下記画像の通り、進めることでdevelopとfeatureブランチが生成され、GitFlow使うための補助機能が使えるようになります。
次回
長くなったので、一旦ここまで。
次回は「コンフリクトさせないためのシーン設計」を予定しています。