git運用 メインラインモデルによる構成管理

Git

この記事は最終更新日から1年以上が経過しています。

gitを運用する際に基本的な部分は守るといいよというガイドラインの草案です。
≒この形にしていくのがおすすめです。

メインラインモデルによる構成管理

ちまたではA successfull git branching model(通称git-flow)というやり方が推奨されているようです。
しかし、少人数で運用する際には無駄が多かったり、煩雑だったりするため、
プロジェクトの初期段階から熟成段階に進むにつれて徐々にこの形にしていくのがおすすめです。

基本ルール

・コードラインの本流となる「メインライン(gitではmaster)」を決定し、ファイルを修正したら必ず修正した部分をメインラインに戻す(マージする)こと
・メインラインは常にビルドできる状態を保つ
・ブランチは必ずメインラインから作成する
・ブランチのブランチは作成せず、必ずメインラインから派生させる

下記のようなブランチを作成して運用します

git01.png

●master ブランチ

・デフォルトで存在するブランチ
・直接コミットは禁止
・他のブランチを作る際はここから行う

●release ブランチ

・リリースする際にmasterからブランチを作成orマージする
・直接コミットは禁止

●feature(task)ブランチ

・修正や機能改修の単位(チケットなど)で作成する作業用ブランチ
・作業が完了したらmasterにマージし、ブランチは削除する

運用例

Eggsでの実例を紹介

■ 開発→リリース

・featureブランチの作成

・開発などしてコミット&プッシュ

git02.png

・作業完了(masterにマージ(してブランチを消す))

git03.png

・リリース作業

git04.png
このリリースブランチを参照してデプロイなどをするようにします。

■ 開発&開発&開発&開発&開発&…→リリース

複数のチケットが並行に稼働しバラバラにリリースされたりされなかったりします。

・featureブランチの作成

git05.png

・それぞれ作業しコミット&プッシュ

・プレリリース用ブランチ(複数のコミットをまとめるようブランチ。いわゆるdevelop)作成

git06.png
masterの下にできています。

・作業完了しpre_releasesにマージ

git07.png

・リリース作業

マスターにマージして
git08.png
git09.png
リリースにマージします
git10.png

この記事を書いた人

鈴木juke / footworker

和服とジュークフットワークに傾倒する人です

Git