(Photo by:Amy)
はじめに
ブランチをしっかり管理できていますか？Gitは便利なツールですが、自由度が高く、チーム内で使うにはなんらかのルールがないことにはリポジトリが混沌としてきます。
よくわからないブランチができていたり、誤ったマージでビルドが壊れたりしていませんか？ブランチをうまく管理できていないと感じたら開発フローの導入を検討してみましょう。有名な開発フローには「git-flow」と「GitHub Flow」の2つがあります。
この記事では、ブランチの管理方法を改善したいエンジニアの方のために、「git-flow」と「GitHub Flow」の2つの開発フローを解説していきます。まずは入門として基本的な知識を知っておきましょう。
git-flowの特徴
git-flowは、フローでありツールでもあります。Vincent Driessen氏は「A successful Git branching model」でブランチモデルを提唱し、そのフローを実践するためのツールとしてgit-flowを公開しました。そのため、正確にはgit-flowという言葉はツールを指しています。とはいえ、フロー自体を指すことも一般的になっているため、この記事ではフローを指すこととします。
git-flowでは、特定の役割を持った複数のブランチを使い分けながら開発を進めます。それぞれのブランチが特定の役割を持っているため、リポジトリの状態がわかりやすくなり、後に開発がどのように進んだかといったことが把握できるようになります。開発者の負担はやや増えますが、ブランチ管理を秩序だったものにすることができます。
git-flowのブランチモデル
masterブランチ
masterブランチは最初から存在しているブランチなので、何も考えずにGitを使おうと思うとmasterブランチにコミットすることになるでしょう。しかし、git-flowではmasterブランチにコミットすることはなくなります。なぜなら、後述するreleaseブランチをマージするのみになるからです。
developブランチ
メインとなるブランチで、このブランチを中心に開発を進めていきます。developブランチの親（分岐元）はmasterブランチです。直接このブランチで作業することはありません。
featureブランチ
実際に作業をするのは、featureブランチになります。機能の追加変更、不具合修正をする際にdevelopブランチからfeatureブランチを切ります。ブランチ名は、開発対象がすぐに分かるような名称にしましょう。開発が完了した（テスト含む）時点でdevelopブランチにマージします。マージをする際にはマージコミットを作成するようにしましょう。マージ後にfeatureブランチは削除します。
releaseブランチ
開発が進みリリースをする段階になった時点で、developブランチからreleaseブランチを切ります。そして、リリース時に必要になる作業を行った上で、masterブランチにマージします。マージしたmasterブランチのコミットには、リリースバージョンを示すタグを打ちます。また、developブランチにもreleaseブランチをマージして変更を反映させておきましょう。マージ後にreleaseブランチは削除します。
hotfixブランチ
ソフトウェアをリリースした直後に致命的な不具合が発覚することがあります。そんなときには、masterブランチからhotfixブランチを切って修正を行います。修正が完了した時点でmasterブランチにマージして、タグ付けを行った上でリリースします。また、developブランチにもマージしておきましょう。マージ後にhotfixブランチは削除します。だいたいreleaseブランチと同様の流れですね。
supportブランチ
場合によっては旧バージョンをサポートするために、masterブランチからsupportブランチを切ることもあります。supportブランチは、masterブランチとは別に保守・リリースを行います。旧バージョン用のmasterブランチといったところですね。
GitHub Flowの特徴
上述のようにgit-flowはブランチの種類が多く、やや複雑なフローになっています。プロジェクトによってはそこまでは必要ないことも多いはずです。そのため、git-flowを簡略化したGitHub Flowが考案されました。名前からお察しの通り、GitHubで採用されているフローなのです。git-flowとは違い、GitHub Flowは非常にシンプルなブランチ構成になっています。
GitHub Flowのブランチモデル
masterブランチ
git-flow同様、masterブランチで作業することはありません。実際の作業は、masterブランチから後述するtopicブランチを切って行います。また、リリースもmasterブランチから行います。
topicブランチ
git-flowでは実際の作業を行うために複数のブランチを使い分けていましたが、GitHub Flowではmasterブランチからtopicブランチを切り、開発が完了した時点でmasterブランチにマージするというシンプルな流れのみになります。
GitHub Flowの6つルール
masterブランチは常にリリース可能
GitHub Flowでは、役割的にmasterブランチがdevelopブランチの役目を果たします。そのため、masterブランチにマージする前にしっかりとテストをして不具合がないことを確認しておかなければなりません。そうしなければ、リリースにも不具合が混入することになり、障害につながってしまいます。masterブランチは常にリリースできるように安定していなければなりません。
masterブランチからブランチを切る
git-flowとは違いGitHub Flowは、すべてのブランチはmasterから派生します。機能の追加変更、不具合修正など種類にかかわらず、すべてをtopicブランチとして扱います。ブランチ名は開発対象を表すわかりやすい名称にしましょう。そうすれば、ブランチを見るだけでどんな開発が進行中かひと目で分かります。
ブランチを定期的にpushする
作業状況を共有するために、定期的にローカルブランチを共有リポジトリにpushしましょう。そうすれば、チーム内の進捗状況の把握がしやすくなります。また、ソースコードのバックアップとしても役立ちます。突然の不幸はいつやってくるかわかりませんからね。
GitHubのプルリクエストを使ってレビューをする
GitHubには、プルリクエストというコードレビューの機能があります。これを利用して、masterブランチにマージする前にかならずレビューを行うようにします。
マージはレビューを通過したものだけ
レビューされていないコードをマージしてはいけません。かならずプルリクエストを行い、レビューされた後にマージするようにしましょう。
レビューを通過したらすぐにデプロイする
コードがレビューを通過してmasterブランチにマージされたら、すぐに運用環境もしくはステージング環境にデプロイして動作確認をしましょう。不具合を早期に発見することで修正時間を短くすることができます。記憶が鮮明なうちにチェックしておきましょう。
まとめ
フローの流れがつかめましたか？そのまま使う必要はありません。実践する際には現場に合わせた独自のカスタマイズを加えるとよいでしょう。git-flowはやや複雑なので、git flowコマンドやSourceTreeなどのgit-flowに対応したGUIツールの力を借りることをおすすめします。もしくは、より軽量なGitHub Flowを選んでもよいでしょう。GitHub Flowの方が少ない負担で運用できます。git-flowとGitHub Flowあなたはどちらのフローを使ってみたいですか？
本ブログは、Git / Subversionのクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
