オラオラ式 git-flow
一昨年くらいから、gitを導入して運用方法等を考えていました。
git-flowであったり、Github-flowだったり色々運用法はいっぱいあると思うんですけど、やっぱり今いる会社では、git-flow、Github-flowを取り入れて運用するのは難しい
git-flow
予想される問題点
- 新規開発が多く、納品完了後の運用がすくないから、ブランチを多く分ける必要性がそんなに無い
- シンプルなフローにしないと全員に浸透せず、ミスが起こる
良さそうな点
- フェーズ分け公開案件時には良さそう
Github Flow
予想される問題点
- １つの作業が終わったら、そのブランチ最後に消す（自社は、新規案件多めなので、１つ作業が完了するまでに長い時間がかかる。）
- masterしか存在しないため、誰かが間違ってmasterにpushしかねない
良さそうな点
- ブランチの数も考え方もシンプル
っていう、（自社の）問題が多かったので、実際にはどっちも使わず、独自のフローを構築してやっていってるのが現状。
特に「シンプルなフローにしないと全員に浸透せず、ミスが起こる」と「masterしか存在しないため、誰かが間違ってmasterにpushしかねない」って部分は矛盾しているんだけどね
どっちつかずなオラオラ式運用を自社では行っています。
オラオラ (自社)式 git-flow 概要
主なブランチ
- masterブランチ（常時デプロイ可能）
- dev_masterブランチ（開発サーバ用ブランチ）
- preview_masterブランチ（クライアント公開サーバ用ブランチ）
- ○○_workブランチ（個人作業ブランチ）
運用法
- 何か作業が発生するなら、masterをクローン後、○○_workブランチを作成
- 移行自分の作業があるなら、全て○○_workブランチを使用する
- 他の人のコミットが欲しい時は、○○_workブランチでマージを行う
- アップして確認に出したいときは、dev_masterブランチ、previewブランチにマージ
- 確認が取れたら、masterにマージ
- ○○_workブランチは削除せず、そのまま保持
良い点
- 個人作業ブランチがあるので、間違ってmasterにpushが無い
- デフォルトで用意するブランチ数も多くなくてシンプル
- git使っていなかった時の作業フローとたいして変わらない
問題点
- お互いの個人作業ブランチをマージするので、コンフリクトしやすい
- マージする回数が増える
- マージし忘れが起こりやすい
- 誰かがやらかしたコード書くと、マージするのが怖くなる
- デプロイ系が手動なので、とりまとめが大変
現状としては、まだまだ問題はあるものの、安定して開発を進められています。