• はてなブックマーク
  • テクノロジー
  • GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ
  • Twitterでシェア
  • Facebookでシェア

GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ

テクノロジー カテゴリーの変更を依頼 記事元:developers.gnavi.co.jp
適切な情報に変更
278 usersがブックマーク コメント34

    記事へのコメント34件

    • 注目コメント
    • 新着コメント
    love0hate
    love0hate featureブランチのままテスト環境にdeployしてQAしない理由がまだ不明確にみえる(現実的な背景事情があることは伺えるが)。／リリースするfeatureのバグが、リリースしないfeatureで修正されてしまってない保証がなさそう。

    2018/06/06 リンク

    その他
    kathew
    kathew test-envブランチの役割がdevelopブランチに近そうかと思ったけど、リリースを前提としないテスト用ブランチというポジションか（test-env内においてはバグが混入してる可能性も許容）。大規模への対応は×じゃないかなぁ

    2018/06/06 リンク

    その他
    karikari1255
    karikari1255 masterにmergeされるブランチが検証済みであるという保証がないのが気になるかなあ。大規模開発だと動作確認用のtest環境の他にstagingもあると思うけどそことの対応はどうするつもりかな

    2018/06/06 リンク

    その他
    penult
    penult p.32の「マージをやめればいいだけ！」がよく分からなかった。test-envでは2つマージした状態でテストしているのに、片方だけmasterにマージして動作する保証はどこにあるのだろう。stg-envで最終確認するからいいってこと？

    2018/06/06 リンク

    その他
    su_zu_ki_1010
    su_zu_ki_1010 この手のはコメント欄で色々いう人がいるけど、"このフローが原因でのバグは一度も出ていません"という一文の重みを考えた方がいい。組織によってハマるやり方は違うのだから。

    2018/06/06 リンク

    その他
    yug1224
    yug1224 １つの案件のリリース日が変更になった時にテストされている状態とは別の状態でリリースされるのが怖い。リリースされなかったfeatureがあることでテストが正しく なっている可能性があるんじゃないかな。

    2018/06/06 リンク

    その他
    Makeneko
    Makeneko この記事はほぼこれと同じですね。 こちらの方が説明がわかりやすいですし、コメントもあわせると理解しやすい。 [https://qiita.com/koyopro/items/b4569285efc22c6397c6] そこのコメントにあるgit wunderflowという命名も面白い。

    2018/06/07 リンク

    その他
    kazkaz03
    kazkaz03 品質管理チームの検証用ブランチがあるだけで、思想的にはgithub flowと変わらない気がする

    2018/06/06 リンク

    その他
    yamami78651
    yamami78651 コンフリクト解消で他ブランチをマージしない、は重要

    2021/03/09 リンク

    その他
    juve534
    juve534 これ参考にGitFeatureFlowを取り入れてみた

    2020/05/26 リンク

    その他
    TakayukiN627
    TakayukiN627 新たなGitのブランチモデル

    2018/06/15 リンク

    その他
    braitom
    braitom GitHub Flowをだいたい同じだが、テスト環境と同期されているブランチtest-envを用意してそこで動作確認後masterにマージするというモデル。

    2018/06/10 リンク

    その他
    efcl
    efcl GitのFeatureブランチと同期するテスト環境で確認してブランチごとにデプロイしていく

    2018/06/09 リンク

    その他
    ikuwow
    ikuwow 意外と炎上してない

    2018/06/08 リンク

    その他
    tolkine9999h
    tolkine9999h おお、こういう使い方もありだな。

    2018/06/07 リンク

    その他
    t10471
    t10471 環境別にコンフリクト直すのだるいな...プロジェクト体制に最適化してるんで良いんだとは思うけど、そのプロジェクト体制が個人的に好きじゃない気がする...

    2018/06/07 リンク

    その他
    Makeneko
    Makeneko この記事はほぼこれと同じですね。 こちらの方が説明がわかりやすいですし、コメントもあわせると理解しやすい。 [https://qiita.com/koyopro/items/b4569285efc22c6397c6] そこのコメントにあるgit wunderflowという命名も面白い。

    2018/06/07 リンク

    その他
    versatile
    versatile プルリクはするけどろくに test も QA もせずにばらまくのが常態になってる企業がわんさかいるなかでちゃんとしてるなぁって

    2018/06/06 リンク

    その他
    love0hate
    love0hate featureブランチのままテスト環境にdeployしてQAしない理由がまだ不明確にみえる(現実的な背景事情があることは伺えるが)。／リリースするfeatureのバグが、リリースしないfeatureで修正されてしまってない保証がなさそう。

    2018/06/06 リンク

    その他
    penult
    penult p.32の「マージをやめればいいだけ！」がよく分からなかった。test-envでは2つマージした状態でテストしているのに、片方だけmasterにマージして動作する保証はどこにあるのだろう。stg-envで最終確認するからいいってこと？

    2018/06/06 リンク

    その他
    marisatokinoko
    marisatokinoko うちはみんな好き勝手テスト環境にプルしてるから実質こうなってる(適当なタイミングで作り直してリフレッシュ)

    2018/06/06 リンク

    その他
    deokisikun
    deokisikun テストブランチってのがミソっぽい

    2018/06/06 リンク

    その他
    NetPenguin
    NetPenguin 偶然にもこれと全く同じブランチ戦略で開発してた。似たような状況や動機があると同じ解にたどり着くの、なんだか、やったぜ！感ある。

    2018/06/06 リンク

    その他
    ghostbass
    ghostbass featureの切り出しがよほどうまくないとこんな感じに出来ない気がする/が考え方は興味深い/テスト環境ブランチの作り方をもうちょっと詳しく読む

    2018/06/06 リンク

    その他
    kazuau
    kazuau テスト環境と商用環境の同期が取れていることの担保が難しそう。（このフローじゃなければ難しくないという意味ではない）

    2018/06/06 リンク

    その他
    take_she12
    take_she12 test-envに対するリリースマネージャーがいるのかな。git-flowでいうところのrelease branchがtest-envになってるけど、test-envからmasterにはmergeしない点が違うのか。featureごとに環境deployしてQAしてmasterにmergeすればいい気が。

    2018/06/06 リンク

    その他
    Dai_Kamijo
    Dai_Kamijo こういうフローやったことあるけど名前をつけたということが価値だなぁ / “GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ” — すえなみ＠すえなみチャンス (@a

    2018/06/06 リンク

    その他
    sifue
    sifue GitFeatureFlowってのがあるのかー。見てみたらおもったよりも複雑感あった。まあ確かにGitFlowが重めってのはわかるけど、チームによってブランチ戦略 変えていくのが良さそう。

    2018/06/06 リンク

    その他
    tzt
    tzt 普通はGitHubFlowでfeatureごとに動作確認してデプロイすればいいところだが、やんごとなき事情により複数featureを一度にリリースするという謎ムーブをやる必要があるからtest-envが必要になると理解。

    2018/06/06 リンク

    その他
    n314
    n314 Qiitaで話題になったやつか。何の先入観もなくgit使うと必然的にこれになるよね？たぶん7年くらいこれでやってる。書いてもバズらないから何度も再発明しちゃう的な。

    2018/06/06 リンク

    その他
    yug1224
    yug1224 １つの案件のリリース日が変更になった時にテストされている状態とは別の状態でリリースされるのが怖い。リリースされなかったfeatureがあることでテストが正しく なっている可能性があるんじゃないかな。

    2018/06/06 リンク

    その他
    masatomo-m
    masatomo-m リリースマネージャが管理してきれいに運用できているなら問題ないと思う。masterにmergeされたタイミングで未検証なステータスのソースが反映されるように見えるけど、pre-commit hookとかでCI回してるのかな？

    2018/06/06 リンク

    その他
    su_zu_ki_1010
    su_zu_ki_1010 この手のはコメント欄で色々いう人がいるけど、"このフローが原因でのバグは一度も出ていません"という一文の重みを考えた方がいい。組織によってハマるやり方は違うのだから。

    2018/06/06 リンク

    その他
    a_suenami
    a_suenami こういうフローやったことあるけど名前をつけたということが価値だなぁ

    2018/06/06 リンク

    その他
    karikari1255
    karikari1255 masterにmergeされるブランチが検証済みであるという保証がないのが気になるかなあ。大規模開発だと動作確認用のtest環境の他にstagingもあると思うけどそことの対応はどうするつもりかな

    2018/06/06 リンク

    その他
    kazkaz03
    kazkaz03 品質管理チームの検証用ブランチがあるだけで、思想的にはgithub flowと変わらない気がする

    2018/06/06 リンク

    その他
    kathew
    kathew test-envブランチの役割がdevelopブランチに近そうかと思ったけど、リリースを前提としないテスト用ブランチというポジションか（test-env内においてはバグが混入してる可能性も許容）。大規模への対応は×じゃないかなぁ

    2018/06/06 リンク

    その他
    orenonihongogayabai
    orenonihongogayabai 背景にコードレビューがほぼ存在しない、もしくはデザインレベルの微調整ばっかで機能開発ではないとかローカルに動作環境が無い人員が多いとかありそう。もう少し背景が知りたい所

    2018/06/06 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック！
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ

    こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています...

    ブックマークしたユーザー

    • techtech05212024/02/11 techtech0521
    • tito12012023/08/30 tito1201
    • mollifier2023/08/21 mollifier
    • jp-myk2023/06/16 jp-myk
    • hiroki232023/05/31 hiroki23
    • aeiueoao11052023/02/14 aeiueoao1105
    • n0dam12022/09/21 n0dam1
    • shonansurvivors2022/03/17 shonansurvivors
    • sinsoku2022/03/17 sinsoku
    • kaoh_siung2021/12/24 kaoh_siung
    • yamami786512021/03/09 yamami78651
    • noritada2020/12/30 noritada
    • juve5342020/05/26 juve534
    • h_notsu2020/05/15 h_notsu
    • unfini2019/10/28 unfini
    • toshing_42019/07/24 toshing_4
    • shuuuuuny2019/05/17 shuuuuuny
    • shimooka2019/05/14 shimooka
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事

    はてなブックマーク

    公式Twitter

    はてなのサービス

    • App Storeからダウンロード
    • Google Playで手に入れよう
    Copyright © 2005-2024 Hatena. All Rights Reserved.