[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

427users がブックマーク コメント 51

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

特別な理由なしにgit-flowを新規採用するべきではない - Qiita

427 users qiita.com/ktateish

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント51件

  • 注目コメント
  • 新着コメント
gfx
git-flowはもともとウェブアプリ向きではないよね。パッケージを作ってリリースするアプリ(モバイルアプリなど)はgit-flowがフィットすると思うよ。

その他
o108minmin
「存在意義のないmasterブランチ」説に同意。masterじゃなくてタグで良い

その他
iselegant
タイトルに圧を感じるけど、「全てのケースに100%フィットするようなワークフローは存在しない」というのは経験上、同意。

その他
txjp
featureブランチの開発工程の合間にdevelopをマージするコミットが挟まれていると開発過程が追いにくいので僕は嫌い。コミット間のdiffにdevelopの変更が紛れてしまう。rebaseしてほしい。

その他
touka_tt
featureの開発が完了してdevelopにマージしたときにコンフリクトが発生するわけだけど、頻繁にソースコードをマージして問題を早期に発見し、差分が小さいうちに解消するというCIの考えに逆行してるのが問題だと思ってる

その他
tettekete37564
全体として何をそんなに怒っているのか分からん。hotfix は master へマージして dev へ ff マージでいいのでは?rebase はローカルで行うモノだだから出てこないのは当然では?ツリーの効率よりメンバが分かりやすいのが一番

その他
raimon49
A successful Git branching modelを書いた当人も後からgit-flow使うのやめていたのに、最初の図だけが日本語で紹介されたのが不幸だったように思う。git-flowみたいなGitの使い方じゃSubversionと変わらない。

その他
teppeis
最初にgit flow使ったときmasterって意味あるの?ってなって誰もmaster更新しなくなった -> 事実上のgithub flow化

その他
n314
結構丁寧な説明だった。webじゃなくて複数バージョンを維持する必要がある場合は、最大の成功例というかそもそもgitの目的だったlinuxを参考にすればいいと思うんだけど、何か不都合があるのかな。

その他
Error401
「私個人としては、その重厚なやり方が肌に合わなかったので採用したことはありませんが」使用経験ないんですか・・・

その他
santhiagoman
git cicd

その他
e_denker
git-flowの考え方だけ頭の片隅に入れておいて、github-flowで開発を始めて、困ったら足していくくらいで良い気がする。もちろん規模感とか何の開発するかとかにもよるけど、git-flowはスタート地点としてはちょっと複雑すぎ。

その他
gactocat
"自転車置き場の議論"

その他
yutaro1985
個人的にも初めてgit-flowを知ったときからこのやり方は過剰だなと感じていたからやはりそうなんだろうなという感想。実際にはGitHub flowがベースにブランチの命名ルールをgit-flowに倣ってやる、くらいのケースが多いような

その他
doscoy_t
> 私個人としては、その重厚なやり方が肌に合わなかったので採用したことはありません 使ったことないのに論じるだけの素人にみんな踊らされすぎ

その他
koogawa
話題になっているのはこれかー / スマホアプリにはフィットすると思ってる

その他
Magicant
そもそも今時流行りの「マージコミットを作らずに rebase や squash を駆使して履歴を簡素化するスタイル」と全然合はない

その他
kimata24
"「A successful Git branching model」というブログポスト"

その他
natural90000
"存在意義のないmasterブランチ"

その他
KentarouTakeda
複数環境で受け入れテスト進行しつつ機能開発も並行稼働、みたいな状況だと意図せずgit-flowとほぼ同じツリーになってたりする。つまり状況によっては役立つのだと思う。この手のは目的を理解し適度に使うべきで要はry

その他
queeuq
サービスに合わせてかなりカスタマイズしたgit-flow使ってた。masterが空気はそう。

その他
teppeis
teppeis 最初にgit flow使ったときmasterって意味あるの?ってなって誰もmaster更新しなくなった -> 事実上のgithub flow化

2022年07月11日 リンク

その他
umai_bow
github-flowでいいよね。足の長い変更はどのみちfeature flagでやったほうがよい

その他
hylom
リリースサイクルが決まっていて(月1とか隔週とか)、次リリースでのbugfixとその次のリリースでの新機能と将来リリース予定の機能を並列で開発するみたいなシーンだとgit-flowはフィットする感じ

その他
bouzuya
個人的な観測範囲だと master と topic と tag で十分なことがほとんどだ。

その他
xKxAxKx
"全てのケースに100%フィットするようなワークフローは存在しない"まあ、これに尽きるし、なんとやくそれっぽいゆるふわな感じでも問題なく運用できてるんならそれでいいんじゃね、って思う。

その他
Error401
Error401 「私個人としては、その重厚なやり方が肌に合わなかったので採用したことはありませんが」使用経験ないんですか・・・

2022年07月11日 リンク

その他
NOV1975
「比較的大きな変更を伴うリリースをする開発スタイルは〜細かい変更を高頻度にリリースするWebアプリの開発スタイルとは乖離」から「つまり、2022年現在ではほとんど誰も git-flow を必要としていない」は飛躍だろ

その他
ghostbass
次回リリース分がちゃんとテストされてるならブランチいらない

その他
pwatermark
「実装着手はするけどリリースするかはわからない」機能はどうハンドリングすればいいんだろうね、とかいろんなケースがあるんで、結局ケースバイケースで最適化せざるを得ない 採用するかどうかも含めてね

その他
Makeneko
なるほど、これが炎上狙いの宣伝か。

その他
ken39arg
まあ、書いてあるけどケースバイケース。webアプリでシングルリポジトリならgithub flow、リリースを伴うアプリはgit flow風、リリースを伴うアプリのバックエンドwebアプリはミックス。 まあ、臨機応変ですね

その他
iww
なんでもかんでもmasterにぶっこめばいいんだよ!

その他
otihateten3510
この話何回目?

その他
xlc
私がGit-flowを使っているのはSourceTreeにUIがあったから。まあでも満足してるよ。npm パッケージを開発するには十分だ。何かを批判するならその問題点と解決方法を示さなきゃただのFUDだね。

その他
kobito19
github flow出たとき既に言及されていたかと

その他
hayashikousun
git-flowを否定している割には,その根拠である「git-flow の要改善点」の章は大雑把に済ませるんだ。

その他
new3
Waterfall/Agileと同じで万能薬・銀の弾丸はないのと一緒で適材適所で効く薬・弾丸を過剰に咎めたりタイトル主語デカで煽るのはどうかと思う。Webアプリにgit-flowが向かないのは概ね同意。

その他
ducktoon
masterだけでOK

その他
cowbee
git-flowがだめなのはわかったけど、じゃあどういうやり方が良いのかを例示してほしい。ありそうな運用事例をいくつかpicしてさ。フレームワーク的なのgit−flowとgithub-flowしかしらん

その他

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

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

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

関連記事

usersに達しました!

さんが1番目にブックマークした記事「特別な理由なしにg...」が注目されています。

気持ちをシェアしよう

ツイートする

特別な理由なしにgit-flowを新規採用するべきではない - Qiita

Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発... Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた(のチーム)が判断すべき さて、 git-flow は 2010年1月「A successful Git branching model」というブログポストによってバズり、以来多くの人が参考にしてき

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

  • blueroom5552025年09月16日 blueroom555
  • y-teraoka2025年08月04日 y-teraoka
  • santhiagoman2024年12月13日 santhiagoman
  • imyutaro2024年10月28日 imyutaro
  • delegate2024年09月05日 delegate
  • nabetk2024年09月02日 nabetk
  • yuuki55552024年01月08日 yuuki5555
  • asyst2023年09月26日 asyst
  • rummelonp2023年09月07日 rummelonp
  • tito12012023年08月31日 tito1201
  • emmeleia2023年03月13日 emmeleia
  • techtech05212023年03月09日 techtech0521
  • zima03142022年11月01日 zima0314
  • anachrome2022年09月20日 anachrome
  • animist2022年08月22日 animist
  • kwy2022年08月04日 kwy
  • sanko04082022年07月23日 sanko0408
  • e_denker2022年07月20日 e_denker
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

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

いま人気の記事

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

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

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

新着記事 - テクノロジー

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

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

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /