gitに基づくworkflow

 こんにちわ、しょよです。今の会社に入社してから、もう2ヶ月経ちました。ちなみに前職は主に、CVSやSubversionでのコード管理だけでしたが、ここではじめて、gitに基づくworkflowを体験しました、Cultural Shockというものを感じました。ここて説明させていただきます。

CVSやSubversionによる単一リポジトリバージョン管理

まず、こちらの記事の説明を借ります。

Subversionによるバージョン管理システムは、単一リポジトリ型(中央リポジトリ)の版管理システムです。CVSやSubversionがこの仕組みを採用しています。単一型リポジトリでは、プロジェクトにリポジトリは1つしかありません。

CVSSubversionのようなVCS(バージョン管理システム)、一般的は以下の機能を備えている。

  • ディレクトリ構造によるファイルの保存
  • ファイルに加えられた変更履歴の保存/管理
  • 排他的編集を行うためのロック機構
  • 複数人が同時に同一のファイルに変更を加えた際の競合解決
  • ネットワーク経由でのアクセス
  • 差分による効率的なファイル転送

こういいても、自分は昔の仕事で、他のメンバーと同じファイルを修正した時、競合解決するために、たくさん辛い思いを残しました。
次は、gitの方を見ていきます。

gitによる分散リポジトリバージョン管理

同じ、上記の記事の説明を借ります。

Gitによるバージョン管理システムは、分散リポジトリ型の版管理システムです。 GitやMercurialがこの仕組みを採用しています。分散リポジトリはリポジトリ自体が複数存在し、分散しています。また分散リポジトリはすべて同じ情報を保持しています。

実際の運用を主に以下の二つあります。

git−flow

git-flowが最初紹介されるのはこちらの記事です。

why git?

記事の中身を見ってみると、まずgitを選んた原因として挙げられるのは、ブランチを切るやマージがよりやすいとシンプルのことです。

ブランチングモデル

実際運用する時は、以下のいくつのブランチを分けて運用する。

主要なブランチ

中心として、ずっと使い続けるブランチとして、以下の二つあります。

  • master ブランチ
    製品レベルのソースを持つブランチ、主にreleaseバージョンです。

  • develop ブランチ
    使える最新開発版を持つブランチ、主にnightly-buildバージョンです。

製品をリリースする時は、developブランチからmasterブランチにマージする。

サポーターブランチ

実際開発時は、直接にdevelopブランチで開発するわけではないです。
developブランチから以下のサポーターブランチを切って開発する。

  • Feature ブランチ
    機能開発ブランチ、開発完了後developブランチにマージする。

  • Release ブランチ
    リリースする時、developブランチやmasterブランチを影響しないために、リリースするタイミングでdevelopブランチから切ります。準備完了後はmasterブランチにマージする。

  • Hotfix ブランチ
    リリースした製品で、不具合が発生する場合、それを修正するために、masterブランチから切って、修正完了後はまた、masterブランチやdevelopブランチにマージする。

以上、結構シンプルな構成で、人を驚いするところがないですが、実際運用すると、昔のような辛い競合はほどんどいらなくなる。開発チームもお互い影響なく自分の開発に専念する。結果開発効率が上げらてました。
実際の運用はこちらの記事で確認できます。

Github-flow

Github-flowは最初、Github内部の開発で使われているもので、こちらの記事で紹介されている。
記事の中には、git−flowの問題として、そのブランチの切り方が、ほとんどの開発に対して、複雑すぎると主張します。

ブランチモデル

まず、masterとdevelopブランチについて、一つにまとめて、必要な時点でリリースすればいいです。
次に、サポーターブランチも、わざわざ三つに分ける必要がなく、何のブランチか、ブランチ命名で反映すればいいです。
結果、5つのブランチが2つになれます。

Pull request

もう一つ重要なポイントは、Github独自のPull request機能です。以下の場面で使います。

  • 開発ブランチからmasterブランチにマージする時、他のメンバーにレビューしてもらえます。
  • 開発の途中で、相談したい場合、[WIP]をつけてレビューしてもらいます。

実際の運用はこちらの記事で確認できます。

まとめ

以上、自分が勉強したことを簡単にまとめました。Github-flowは小さい規模や短期間の開発向きで、git-flowは規模がもっと大きい開発に向いていると考えています。
実際今の仕事はgit-flowとpull request、両方のメリットを合わせて運用している。
ちょっと長いですが、読んでいただけなら幸いです。

PlayFramework2.4におけるDIのテスト方法 Manage database with flyway and skinnyORM

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×