GTE Git branching model
Posted on 2013-01-30 by k_ryokoこんにちは、アプリ開発プログラマ ryoco と申します。
最近 git 開発にして捗ったというスライドを読みまして、実は皆、他社の git の使いかたに興味があるのではと思い書いてみました。
まぁ、他社の開発スタイルというのは皆知りたい所ですよね!
という訳で、弊社のとあるwebアプリのVCSの歴史と使い方の紹介でございます。
9ヶ月くらい前まで svn で運用していましたが、開発者が増えたのでブランチを切る事が多くなり、git に変更しました。
ブランチ開発をする時は、svnよりgitの方がはるかに便利だからです。例えば、branchを切るのが高速、conflictが少ないなどの点で優れています。他にもありますが色々な所で見るので省略。
因みに開発規模は現在5~6人です。
主にプログラマが使う、html ファイルとプログラムソースファイルのプロジェクトのみで、仕様書や画像ファイルは相変わらず svn です。
- svn
- 適当な branching の git [git 第一段階]
- A successful Git branching model ベースのgit [git 第二段階] <- イマココ
という風に変わっていきました。
サブライブラリに hg を使っていた時代もありますが、省略。
svn の時代は別に説明しても仕方がないので、git から説明していきます。
git 第一段階
- ブランチは大きく分けて、3種類あります。
- master : 開発用
- feature branch : それぞれの開発用。名前は各自適当に決める
- release_yyMMdd : yyMMddリリースのリリースブランチ
- 時系列で使い方を説明していきます。
- それぞれの開発者が master から feature branch を作成し作業する。
- 開発が完了、もしくは開発かつデバッグが完了したら master にマージ。デバッグするときは、master から fearure branch にマージしたりしてました。
- リリースするときに master から release 用のブランチを切って本番にリリース。
- リリースが完了したrelease_yyMMdd ブランチは削除していきます。
-
図にすると以下のようになります。
- 追記
- releaseyyMMdd を切る前の master に、リリースしてはいけない機能というのがまれに混入します。
その時は releaseyyMMdd で revert してしまいます。 releaseyyMMdd はリリース後、捨てられるので躊躇なく revert できるんですね。
しかし、リリースしてはいけない機能は基本的に feature branch で管理していたので、revert しない事の方が多かったです。 - リリースする時はもちろん tag を切ります。
- リリースしてからバグに気がついた時は master で修正し、releaseyyMMdd に cherry-pick してました。
git 第二段階
-
第一段階の運用方法でも手動でデプロイする分にはあんまり問題なかったんですが、システムデプロイの都合上、git の運用方法を変更する事になりました。
自分達で考えても良い方法が思いつかなかったので、賢い人が考えたモデルに則り、慣れたら応用するか新しいモデルを考えようと思いました。
大体 A successful Git branching model の通りに運用していますが、運用上での問題点や注意点を書いていきたいので、簡易版で説明します。日本語訳もありますし、わざわざ説明する事も無いような気はしてますが。
-
できれば A successful Git branching model を読んでからの方が分かり易いです。
ちょっと休憩
A successful Git branching model がなんでこんな複雑で、このモデルで運用しなければならんのだ、という感じなんですが、なぜなんでしょう…。
自分達で git の運用を考える場合は、弊社第一段階みたいな感じか、cherry-pick職人が発生するとか、後々後悔する形になってしまうのだと思います。
master と develop は分離されていた方が安全ですし、コードレビューや gitlab で merge-requestを使った運用とか考えると、漏れなく master にも develop にも commit を含められる、今のところこの最強モデルなんでしょうね たぶん。
- ブランチは大きく分けて、5種類あります。
- develop : 開発用
- master : リリース用
- release_x.x : x.x (version) リリースのリリースブランチ
- hotfix_x.x : リリース後の修正ブランチ
- feature branch : それぞれの開発用。名前は各自適当に決める
- 同様に時系列で使い方を説明していきます。
(日付けからversionに変わったのは、実際の運用でこうしているというだけで、深い意味はありません。) - version は 1.0 から 2.0 に上がるという体で説明して行きます。
- develop から開発者が feature branch を切り、開発が完了したら develop に戻します。
- develop からrelease_2.0 のブランチを切ります。
このブランチで、デバッグ、修正をします。デバッグをしてくれる運営サイドの人とかが説明文などの html を修正したりもします。プログラマ以外も git ブランチくらいは使いこなすスキルが必要です。(誰でもできるよね!) - release_2.0 用のデバッグか完了し、リリースができる状態になったら develop 、master にマージします。
ここで release_2.0 の役目は終わりです。 - 最後に master からtagを切り、本番にリリースします。
- 本番でバグなど出た場合、master から hotfix ブランチを作成します。
master から hotfix_2.1 という感じでマイナーバージョンを付けています。 - バグの修正が完了したら hotfix_2.1 を master、develop or release_3.0にマージします。
develop or release_3.0である理由は、release_3.0 はそのうち develop にmergeされるからですね。
-
図にすると以下のようになります。
- 追記
-
非プログラマ以外への教育コスト
がかかるように見えますが、上記モデルを完全に理解させる必要は無く、今はreleasex.xだからこのブランチで作業してね、という情報共有さえできればなんとかなります。たぶん… - マージ多くて面倒臭そだし忘れそう…
という感じだと思いますが、基本的にマージをしなければいけないのは releasex.x と hotfixx.x で、しかもこれらは両方とも同じ2箇所にマージしてしまえば良いので、慣れれば楽です。(魔法の言葉ですね)
ただ、プロジェクトの git 管理者は立てて置いた方が良いと思います。 - 破綻するパターン
ルールに則らないと破綻します。develop から releasex.x を切らないとか、 releasex.x がいくつも切られてしまう場合などです。releasex.x も2個までだったらマージする人ががんばれば何とか対応ができなくないですが、辞めた方が良いです。 - feature branch の develop へのマージについて
releasex.x 上でのデバッグ中に致命的なバグが出て、リリースにまにあわないっていう事があると思います。
その場合、releasex.x からは必ず、場合によっては developからも revert 等する必要があります。
そういう時の為に、feature branch をdevelop にマージする際は、git merge –squash を使っています。
そうするとコミットが纏められるので revert が楽になり、release_x.x の他の機能の修正に影響を出さずにリリースできます。
ただコミットログがブランチにしか残らないです。良い方法があったら教えて下さい。
revertしたら feature branch に戻ってバグを潰しましょう。
なんとなく掴めたでしょうか。
このモデルではスケジュールの関係で無理、という所は無理だと思いますが、そもそも運営もうまく回っていないのではないでしょうか…。
弊社プロジェクトでも少し厳しい所があり、頭を使ってミスしないようにイレギュラー対応をしています。
イレギュラー対応について書こうかと思ったんですが、長くなるので辞めました。
ここの説明は簡易版ですので、実際使う時は本家や日本語訳を読んで自分のプロジェクトでも運用可能か考えて下さい。
ここまで読んで下さったのにアレですが、開発者が少なければ git 第一段階の運用でも賄えるかと思います。半年くらい第一段階のモデルで運用していました。git の開発モデルからは外れているのですが…
以上になります。
ここまで読んで下さり、ありがとうございました。
———————–キリトリ———————–
ここからは書いてみての感想です。(読み飛ばし推奨。下らない事しかかきません)
最初は、 A successful Git branching model を読んだ事があるとか、git での運用に興味があるので積極的に読むけど、
・非エンジニアへの教育コストかけられないとか (エンジニアへの教育コスト? 楽になる為だったらエンジニアは積極的に最先端を学ぶよね!ブーメラン!)
・実際これで運用できると言い張れないがために結局適当なモデルで運用せざるを得ない
・そもそも git での運用に懐疑的な人ばかりで git にできない
みたいな人が対象だったんですが、書いているうちに結局簡易な説明くらいはしないといかんな、という所と、A successful Git branching model 読んでなくても簡易版で説明できたらPV伸びるかも…という欲が出てきてしまい、すごい長くなってしまいました。
なるべく減らしたりしたんですが、すみません。
長くした癖に、結局読み手側にあるていど考えて貰わないと無理、という結論に。
感想というか、長くなった事への言い訳でした。