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

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

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

基本ルール

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

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

●master ブランチ

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

●release ブランチ

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

●feature(task)ブランチ

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

運用例

Eggsでの実例を紹介

■ 開発→リリース

・featureブランチの作成

git checkout -b feature/11111_youken

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

git commit -am "コミットちゃんやで！"
git push

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

git checkout master
git merge feature/11111_youken
git push
git branch -d  feature/11111_youken

・リリース作業

git checkout release
git merge master
git push

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

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

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

・featureブランチの作成

git checkout -b feature/20001_kiga
git checkout -b feature/20011_tsuku
git checkout -b feature/20103_towa
git checkout -b feature/20021_tashi
git checkout -b feature/20101_haba
git checkout -b feature/20401_ido

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

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

git checkout -b pre_releases/20051221

masterの下にできています。

・作業完了しpre_releasesにマージ

git checkout pre_releases/20051221
git merge feature/20020_nina
git merge feature/21200_tsute
git merge feature/20302_ita
git push
git branch -d feature/20020_nina
git branch -d feature/21200_tsute
git branch -d feature/20302_ita

・リリース作業

git checkout master
git merge pre_releases/20051221
git push
git branch -d pre_releases/20051221

git checkout release
git merge master
git push

マスターにマージして

リリースにマージします