-
1:ID:HuTqAr · 3週間前

#git GITフローの運用について皆さんのご意見を教えてください。
以下のブランチの履歴があります。

1.ブランチ a の作成(MASTAR -> a)
2.a の開発と push(a -> MASTER)
3.ブランチ b の作成(MASTAR -> b)
4.b の開発を開始
5.a の機能でバグが発覚
 b の開発は a のコードを参照しているため、b の開発は停止
6.ブランチ a2 の作成(バグ対応)(MASTAR -> a2)
7.a2 の開発と push(a2 -> MASTER)

8.b の開発を再開
ここで、どうするべきなのでしょうか。
b の開発はかなり進んだ状態であるとします。

案1 b2 ブランチを切って、b2 に b をマージするとして、bのブランチはそのまま
 ->履歴上なぜ bがそのままなのか不明になるはず
 ->bのようなブランチが大量にあると履歴がかなり汚れる
 ->マージ作業は手作業なのでできれば避けたい

案2 b2 を切らずに、b にMASTERから変更分の a のコードをフェッチして b での開発を再開
 ->こちらが正しい感じがするが・・
 ->変更分のコードを選択するのは人間の判断になる問題がある
  (変更分のコードを選択するのは手作業でのマージに近い)

案3 その他の方法(思いつかない)

今回は b ブランチが1つですが、b のようなブランチが複数あると影響がでかいです。
a のバグ対応中は、b の開発は停止すると思いますが、これも時間的損失です。

要するに依存関係がある場合は並行開発はできない、依存元のバグが発覚した場合、
依存先のブランチはどう対処すべきか、という問題です。

皆さんはどう考えますか

9 件の回答

2:ID:RCJObW · 3週間前

ここにいる奴らはgitなんぞ使ってない

3:ID:Z3R5qT · 3週間前

bにもa2をマージするんじゃダメなの?

6:ID:x25bKN · 3週間前

a, b の開発が「最初から存在する」とわかっている場合、
・工程 2. は悪手。b の開発が a のテストにも繋がるのだから MASTER に push してはならない。
・工程 3. については、 a から ブランチ b を切る。
・ブランチ a のバグはどうせブランチ b の開発上で見つかるパターンなのだろうから、ブランチ a かブランチ b のいずれかで修正したものをプルリクだすなり cherry-pick するなりして a のバグを修正する。
・最終的に工程が完了した段階で MASTER に push すること。
こんなもんじゃね?

7:ID:Z3R5qT · 3週間前

Re:3
そもそもだけどGitフローの運用的にはリリース出来ないものをMasterに入れる事自体NGだと思うけど

8:ID:XMCg5T · 3週間前

developブランチを最初に作っておく。
bugfixはmasterから切り、masterにマージして運用する。
featureはdevelopから切るが、developは定期的に本番で発生したbugfixを吸収しておく。
もちろんdevelop派生のfeatureもbugfixはdevelop経由で受け取る。
現場によって運用は違うけど、主導権があるなら一般的なgit flowでいいよ。

9:ID: · 3週間前

Re:8
主です。MASTARからブランチを切るというのは間違いでした。
実際には、developブランチがあり、そこから個別のfeatureブランチが作られます。
以下の運用が正でしょうか。
1.内部的に依存関係があるブランチa、bがある(a が b に参照されている依存関係)
2.aが開発終了してdevelopへのマージ後にbブランチを作成
3.bで開発中にaでバグが見つかる(bの開発停止)
4.a2ブランチを作成して修正後にdevelopにマージ
5.a2のマージ分をdevelopからbにマージ
6.bの開発を再開
ただこの場合、aのブランチ担当がbの担当にバグ対応の情報を連携しないと開発フローが破たんします。
bの開発でaのブランチのバグが見つかるというケースではない場合も当然あります。
実際には、bの担当が常にバグ情報を監視して、依存関係にあるバグかどうかを見極めることになると思います。
この見極めに失敗すると、やはり開発フローが破たんします。
その場合、aの担当者ではなく、bの担当者の責任になる可能性が濃厚です。
aの担当はバグ対応の情報を周知するだけの運用になるはずです。
しかしながら、大きなプロジェクトだと、b担当は全てのバグ情報の依存関係有無を把握できない可能性もあります。
結果的に、bのマージ後の総合試験でバグが発覚する流れになると予想します。
この問題はbの担当が頑張って対処するしかないのでしょうか?
皆さんはどう考えますか?

10:ID:Z3R5qT · 3週間前

Re:9
gitの問題じゃなくなってる気もするけど
たびたびその問題が発生するなら総合テストだけじゃなく、ユニットテストもしたほうがいいんじゃないかな 大きなプロジェクトならなおさら
bの開発をどうしてもとめたくないなら、関数呼んだら仕様通りの値をハードコーディングで返すだけのダミーのものを用意するとか
もっとタスクを細分化してチケット制にするとか別の対応が必要なんじゃない

2 件の回答が除外されました。[詳細]
コメントの受付は終了しました。

一緒に読まれている質問

ページ上部に戻る