Git-Flowの考察
会社でGit-Flowやります。
ということで、色々調べてみました。
今までSVNで管理していましたが、trunk一本でしたし、branchもよほどの事がない限り使っていません。そんなチームに天から「GitLabを使え」との指示が急に振ってきました。先鋒として調査と結果報告を行いましたので、これはその時に検討した資料を再構成（つまり外部用）したものです。その時はExcel方眼紙で作ってみましたが、このイメージはdiagrams.netを使用しました。
しかし、これはいい。今まで強力な図形ならVisioが必要と思っていましたが、これならVisioがなくても十分やっていけます。現在はGoogle Driveの追加アプリケーションとしてGoogle Driveから作っています。Google Driveには標準の「Google 図形描画」もありますが、そちらは残念な仕上がりです。
正直、Excelもなかなか詳しい図形を書けますが、曲線が美しく書けないですね。あと、アンカーポイントが固定的なので苦労します。見えないオブジェクトに線を連結してアンカーを増やして図形を整えるのは数が増えるとなかなか面倒になります。
さて、本題です。SVNと違って際限なくブランチを切って運用してしまいそうなGitではありますが、世の中にはリポジトリベースサイトの名を冠した、ブランチ運用フローが現時点で３つあるようです。それらの名称は以下の通りです。
- Git-Flow
- GitLab-Flow
- GitHub-Flow
GitLab-Flow
イメージはググってください。諸先輩方が色々調べて公開してくれています。運用方法はとてもしっくりきます。「水は高い所から、低い所へ流れる」を具現化したモデルのようです。開発者は常にマスターに機能を追加して、日々これらの安定稼働と問題対応を行います。masterを更新するので、一時的にバグによる汚染も発生するでしょう。テストの自動化や、しっかりしたリグレッションテスト計画など、できる限りのmaster保全計画をキッチリ進めておけば、下流に発生する支流には、その支流に必要な機能を取り込んで、「取り込んだ機能の組み合わせで問題ない」ことを確認するだけのように感じます。この時点で問題が発生しても、対応者は「master」に更新を行って支流に「バグ対応」を流し込んでいく運用イメージになっているようです。
この支流のイメージは、顧客単位のカスタマイズ対応とか、「今回はこれらの機能を実装して出荷していく」という明確な出荷計画がある場合には良いと思われます。
GitHub-Flow
先程の「水は高い所から、低い所へ流れる」の見方を逆にした感じなのが、この「GitHub-Flow」のイメージだと思います。バグ対応も、機能追加も常に「master」に終着する事を前提として活動していきます。こちらもGitLab-Flowと同様、「master」に到着する頃には問題をクリアした「良いコード」であることが求められます。そのための方策は前述のGitLab-Flowと同じだと思いますが、最初に「master」に流し込む緊張感に比べたら、鍛え上げてから「master」に登録する形は、よりナチュラルな感じがします。
Git-Flow
Git-Flowのイメージは、以下の通りです。この図では、Git-Flowに登場するHotFix系のラインがありませんが、すみません、書きそびれました。しかし、コミットの流れをシンプル、かつ明確に理解するにはちょっと端っこに寄っておいてもらいましょう。
前述の３つの運用フローのうち、このGit-Flowが一番複雑かもしれません。見ての通り、ブランチとブランチを移動する機能やBug Fixが縦横無尽な感じがします。それに「master」は完全に暇しているようです。そして、事を複雑にしているのが結合テストの実施中に発生した問題対処の「release sp1」と、通常の開発を行うSprint2での「develop」での作業が重複しているところです。
つまり、バグを退治しながら開発を行う事を想定しているのです。この方法を採用する事にした理由の一つはこの、ブランチを切り替えながら両方の作業に対応できる（ということを、図面から明確に説明できる）からです。二人で担当分けすれば、「機能#4」の部分の間延びしたところは解消されますけどね(^^;)
そして、開発チームとテストチームが明確に分かれて作業しているところもこれを採用した理由になります。テストチームは「release」ブランチに着目して作業を行います。バグでテストが止まったら、開発チームからのバグ対応の連絡をこのブランチで待つのです。開発チームはテストチームからのバグ情報を「release」ブランチから対処を行い、事を収めるべく齷齪(あくせく)しながら、自身の開発作業も行うのです。
私たちの現場では、今までもこの状況が続いていますので、SVN→Gitに切り替える際はこの運用フローがいいのでは、ということで採用された次第です。
私としては、待望の「世の中Gitでしょ」に近づけるため、運用フローに関してはどれでも良かったのです。でも、リーダーさんが「どの運用フローにしたらいいのだろう」と悩まれて私に「提案」を依頼されてきたので、色々検討してみました。最初はまったくちんぷんかんぷんでしたし、ネットの情報のどれを見てもなかなかイメージがわかなかったので、「なぜだろう」と思いながら図面を”写経”してイメージを固めていきました。そして図面に足りなかったのは「なにがどこに流れて行っているのか」を明確にすることだな、と感じてこの図面を作ってみた次第です。
さて、世の中の情報が正しいとは限らないことは、この私の図面にも適用されます。この図面のレビュー時に「pull」でなくて「clone」ですよね、とか「stash」ではないですよ、とか指摘を頂きました。まだ、なにか問題が含まれているかもしれません。バグを見つけたらなんなりと御指摘ください。よろしくお願い致します。
