git-flowの改善点ついて

Question

git-flowについて学習をしていた際、こちらのQiitaの記事を目にしました。
Qiitaの記事では、「feature/1」が未検証であり、「feature/2」が検証済みであった場合、通常のgit-flowの手順では、「feature/1」も検証済みでないと、masterにはマージ出来ないといった内容が記載されているかと見受けられました。
ですが、疑問としまして、「feature/1」が未検証であれば、そこは後に回し、「featrure/2」のみをmasterにマージし、「featrue/1」は後に検証し、OKだった場合、masterにマージすれば良いのではないかと思いました。⇦こちらの方法は難しいのでしょうか？
未だgitについて、あやふやな点があります為、ご助言頂けましたら幸いです。

Answer 1

この記事の「他のfeatureの検証が終わってないとリリースできなくて困る」という部分に書いてあるのですが、
検証がNGで修正が必要なfeature/1のcommitまで一緒にリリースされてしまうためだ。
図でも表してあるように、「featrure/2」は「feature/1」のNG内容がcommitされたあとに切られています。
「featrure/2」にはNG内容が含まれている状態なので、そのままリリースする事ができないということだと思います。

Comments

[aae_11]

ご回答ありがとうございます。
図では良く分からなかったのですが、理解することが出来ました。
度々すみません。
また少々疑問が出てきてしまったのですが、それであれば、「feature/1」を検証した後に、「feature/2」のブランチを切るようにすれば良いのではないかと思ったのですが、そういう訳にはいかなかったりするのでしょうか...?

[退会済みユーザー]

それも記事に書いてあって、
それができれば良いけれど、下記の様な理由でできない場合があるということです。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
すぐにfeature/1を修正・検証すればいいじゃないかと思うかもしれないが、プロジェクトの諸々の理由で簡単にできないことがある。
(例えば検証してみたら仕様変更が必要になったとか、担当者が次に作業できるのが3営業日後ですとか。修正がすぐにできたとしても、社内検証段階で最終チェックしてもらわないといけない偉い人がなかなか捕まらないとか。)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[aae_11]

あ、そこの部分は記事内で読ませて頂いたのですが、少々勘違いしてしまっていた部分があったみたいです...
>すぐにfeature/1を修正・検証すればいいじゃないかと思うかもしれないが
こちら「feature/1」の問題点などを取り除くなどすることにfeature/2の開発をする分のリソースを当てれば良いのではないかなと思っていたのですが、状況によりそういうわけにいかないこともありますよね...
度々すみませんでした。

[退会済みユーザー]

いえいえ、gitの開発フローに関しては人や会社によっても様々ですし、
gitは習うより慣れろと言われたりしますが、頭で考えてもスッと理解できない部分も多いと思います。