この記事は最終更新日から1年以上が経過しています。
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 |
マスターにマージして
リリースにマージします
この記事を書いた人
- 和服とvapeとСистемаと醗酵とたまごふわふわとカッティングシェイプスとジャージークラブとjuke/fwkに傾倒する人です
最近書いた記事
- 2019.10.17ES2019で追加されたあれこれを使ってみる
- 2019.09.20JavaScript で安全に扱える最大整数
- 2019.07.24Gitでハッシュ値指定が重複したらどうなるのか
- 2019.07.09ハッシュは何に使えるのか