現在、世界でも多くの開発者がシステム開発、アプリ開発の際に使用しているバージョン管理システム「Git flow」ですが、開発体制が大きくなるに従い、多く問題が起われました。例えば、「ソースコードのコンフリクトが頻繁に起きてしまう」・「先祖返りばかり発生して、なかなかプロジェクトが思うように進まない」・「Git flowは導入するだけじゃダメなの？

そのため、本記事では、バージョン管理システムの必要性と重要性、さらにGitを使用したバージョン管理のワークフローのうち、最もメジャーな「Git flow」の運用とケーススタディについて、ご紹介致します。

1. はじめに

Gitが人気を博している理由のひとつには、手軽に使えるブランチの存在があります。ブランチを効果的に使えなければ、Gitの真価を発揮することはできません。

しかし複数人での開発で、特になんの決まりもなくブランチを使っていると、無秩序にブランチの作成やマージが行われ、リポジトリが混沌としてきます。こうした問題を解決するために、「ブランチモデル」というブランチ管理方法が考案されました。

今回紹介するのは、Gitのブランチモデルのひとつである「Git-flow」です。

Git-flowはブランチモデルの中では比較的歴史が長く、Git-flowをサポートしているツールも数多くあります。やや複雑なモデルではありますが、ツールを使うことでブランチの操作をある程度自動的に行うことが可能です。

コマンドを覚えて流れをつかんでしまえば、それほど難しいことではありません。実際にやってみることで理解が深まります。

2. Git flowの概要

2.1. Git flowとは

Git flowは、「Vincentdriessen」によって提案された成功したgif分岐モデルと呼ばれる分岐モデルをサポートするツールです。それをモデルまたはツールと呼ぶことがよくあります。git flow には、役割の異なる５つのタイプがあります。

Gif flowは開発のためにタイプを切り替える事前にブランチを設定し、ルールをマージすることで、同時に開発している開発者の数に関係なく、ブランチを簡単に管理でき、次のマージによって発生する問題を回避できます。 Git-flow に含まれているブランチタイプを見てみましょう。

2.2. git-flowのメリット

作業の過程では、ブランチではなく、利用可能な機能の統合に基づいて動作するブランチのシステムであるため、作業の過程で特定の機能が原因で発生する問題を迅速かつ簡単に監視および処理することができます。

他の集中型ソースコード管理ツールと比較して、Git flowのメリットとデメリットを議論するときに、あまりにも多くの戦いが勃発しました。開発者として、私たちはGit-flowにもっと恋をしています。Git flow は、マージとブランチについての考え方を大きく変えました。 

• 本番リリースしたデータと、制作中のデータの区別が明確になる。
• 修正、リリース、機能追加などのいくつもの種類の違う作業を並行して進められる。
• リリースした内容の調査が簡単になる。
• git-flow用のコマンドでほとんどの管理を行えるので、操作マニュアルを用意しやすい。

▶詳細はこちらをご参照ください。

3. バージョン管理の必要性と重要性について

本記事では主にバージョン管理システム「Git-flow」を使用したワークフローについての解説をいたしますが、Git-flowについての解説に入る前に、開発をするうえで欠かせないバージョン管理の必要性と重要性について少し触れておきます。

「バージョン管理」とは一体何でしょうか。これは開発の中で更新されていくソースコードやファイルの変更を記録することです。

さらにそのサポートしてくれるソフトウェアのことをバージョン管理システムといいます。

では、なぜそのバージョン管理システムが開発をする上で必要になってくるのでしょうか？

バージョン管理システムを使用することによって、以下のことが可能になります。

✔️変更履歴の記録（= commit）
✔️変更の取り消し、復元
✔️変更理由、その担当者の履歴

バージョン管理システムを使用せずに開発を進めてしまうと、他の作業者が編集した内容に気づかずに、ソースコードを上書きしてしまったり、時には不要なコードと認識し、削除してしまい、結果としてエラーや*デグレードが多発してしまうことになります。

「*デグレートとは、ファイルを更新した際に以前修正したバグや不具合が再発してしまうことです。」

しかし、上記の3つが可能になった場合はどうでしょう？変更履歴を辿ることで、変更理由が確認でき、さらにその担当者も確認できるので、不用意にコードを削除してしまうことも無くなるでしょう。それによりエラーやデグレートの発生率を下げることに繋がってきます。

4.「Git-flow」と「GitHub-flow」の違い

4.1.Git-flow

▼Git-flowの流れ

Git-flowとはオランダのエンジニア、Vincent Driessen氏の"A successful Git branching model" を元にしたワークフローです。Git-flowでは、役割が決められた6種類のブランチを切り替えながら開発を進めていきます。

※この6つのブランチについては以下の章で詳しくご説明いたします。

4.2.GitHub-flow

▼GitHub-flowの流れ

Git-flowでは6種類のブランチを使い分けるのに対して、GitHub-flowでは、2種類のブランチ（master、topic）しか使いません。つまりGitHub-flowでは、masterブランチへのマージとリリースはほぼ同義になってきます。

それぞれにメリット・デメリットがありますので、現場に合わせたよりよいブランチモデルを使用しましょう。

▶詳細はこちらをご参照ください。

5.Git-flowブランチの運用にルールが必要な理由

ではなぜ、ブランチの運用にルールが必要なのでしょうか？理由はたくさんありますが、大きな理由は以下の3点です。

• ルールがないと、各々の開発者が自由にブランチを切ることでリポジトリのブランチが乱立する。
• ルールがないと、各々の開発者が自由にPush等をしたりして、誰がどこをどれだけ作業したのか状況がつかめなくなる。
• ルールがないと、各々の開発者がmasterブランチ、developブランチにPushをしてしまい、誤って開発途中のソースコードや非公開の情報が本番公開されてしまう。

これらの問題が起こっていることに気づいた時にはもう手遅れで、これらの整理を行うのにかなりの工数がかかってしまいます。

しかし、ブランチモデルを利用することにより、これらの問題を回避することができます。

今回は、開発環境を明確にできることから、当社でもっとも利用されているGit-flowについて、掘り下げて説明をさせていただきます。

6. Git-flowを形成する2つのメインブランチと4つのサポートブランチ

Gif flow は二つのメインブランチと四つのサブブランチが含まれます。その中で、二つのメインブランチはマスター(master)と開発(devlop)で構成され、これはマスターブランチと固定ブランチです。

また、四つのサブブランチはリリース（ release)、supportブランチ(optional)、機能(feature)、修正プログラム(hotfix)であり、作業、作成、削除のプロセスでメインブランチをサポートするために作成されます。

6.1 Masterブランチ

Master ブランチは、リポジトリに新しく作成され、Gitにデフォルトで作成されるブランチです。初心者はマスターブランチに直接コミットする傾向がありますが、Git flowではMaster に直接コミットしません。これはマージを行うために使用されるブランチにすぎないので注意してください。

メインブランチと呼ばれ、データ管理が格納され、プロジェクト全体の操作を記録します。

たとえば、販売プロジェクトの倉庫全体のように、上級管理職だけがそれを見ることができ、それを見るだけで、従業員が何をしているのか、作業がどのように進んでいるのかを知ることができます。

6.2 DEVELOPブランチ

Developブランチは、開発するの中心的なブランチです。変更するたびに、対応する機能ブランチが壊れるので、これは開発プロセスで最も使用されるブランチであると言えます。ブランチには、他の人が変更内容をすぐに知ることができるように名前を付ける必要があります。

これを行うために各Branchが分割され、作成が完了したら、それをそれを開発にMergeして削除します。

6.3 Releaseブランチ。

FeatureブランチはDevelop開発ブランチから作成されます。ブランチリリースは、その名前が示すように、製品をリリースするために使用されるブランチです。製品がリリースされると、他にも多くの関連タスクが必要になります。これらの関連タスクは、開発ブランチから切り離されたリリースブランチでリリースされます。リリースが完了したら、ブランチマスターとブランチ開発にマージし、リリースタグを書き込んでブランチマスターのコミットをマージしてから、リリースブランチを削除します。

リリースブランチは、新しい本番リリースを準備するために使用されます。散発的なバグの修正、メタデータ（バージョン番号、ビルド日など）の準備に加えて、リリース前のすべての最終作業はここで行われます。ブランチを開発から分離することで、他のリリースの機能を通常どおり開発し続けることができます。

開発から分岐するために選択された時は、開発が新しいリリースの望ましい状態を反映するときです。最低でも、すべてのリリース機能を開発に統合する必要があります。それ以降のリリースを対象とする機能はまだマージされていないため、分岐後待機する必要があります。

リリースブランチを作成した直後に、プロジェクトのルールに従ってバージョン管理を進めます。

6.4 Hotfixブランチ

HotfixブランチはMaster開発ブランチからを作成されます。製品をリリースしました時、非常に深刻なバグを発見することがあります。

確かに、皆様もがこの問題を経験したと思います。そのような場合、修正プログラムブランチをマスターブランチから直接切断して修正します。修正後、修正プログラムはマスターにマージされ、リリースタグを開発して記録して、次に修正プログラムブランチを削除します。

Hotfixブランチもが事前の計画がないことを除いて、新しい製品リリースの準備に使用されるという点でリリースブランチに似ています。すぐに対処する必要のある重大なバグが本番環境にある場合、ホットフィックスブランチはマスターからフォークされ、識別のためにバージョン管理されます。このフォークの利点は、他のチームメンバーが開発作業を継続できる一方で、他のメンバーが本番バグの修正に集中できることです。

Hotfixブランチのメリットは次のとおりです。他のメンバーはDEvelopの作業を続けることができ、他のメンバーは本番環境のバグの修正に集中できます。

6.5 Featureブランチ

Featureブランチはdevelop 開発ブランチから作成されます。機能ブランチ（Topic branchesとも呼ばれます）は、将来のリリースの新機能を開発するために使用されます。

Featureブランチは機能開発を開始するとき、その機能がいつシステムに統合されてリリースされるかが明確でない場合があります。機能ブランチは、機能が開発されても存続し、最終的には開発にマージされるか（次のリリースにその機能が含まれると決定された場合）、または削除されます（機能が不要になった場合）。基本的に、機能ブランチは開発者のリポジトリにのみ存在し、オリジンには存在しません。

6.6. supportブランチ（オプション）

プロジェクトによっては不要ですが、旧バージョンをサポートし続けなければいけないプロジェクトでは Supportブランチが必要です。Supportブランチでは、旧バージョンの保守とリリースを行います。サポートが必要なバージョンの master ブランチのコミットから派生させ、サポートを終了するまで独立してバグフィックスやリリースを行います。

7. まとめ

Gif flowは、情報技術の分野、特にWebサイトのデザインのプロセスにおいて、基本的かつ不可欠な部分です。現代、世界中のチームのチームワークプロセスを要約すると、Gif flowは効果的な結果を出しています。同時に、グループは互いに影響を与えることなく並行して機能します。特定の部分でエラーが発生した場合に、簡単かつ迅速に管理および処理できるため、Gif flow は世界 でますます開発され、広く使用されています。

オフショア開発をご検討されている方々はぜひ一度ご相談ください。

※以下通り弊社の連絡先

アカウントマネージャー: クアン(日本語・英語対応可)

電話番号:　(+84)2462 900 388

メール:  konnichiwa@hachinet.jp

お電話でのご相談/お申し込み等、お気軽にご連絡くださいませ。

無料見積もりはこちらから▶

Tags

ご質問がある場合、またはハチネットに協力する場合
こちらに情報を残してください。折り返しご連絡いたします。