気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント71件
- 注目コメント
- 新着コメント
tofy
“develop と master の乖離については、 develop を時々(リリース直後とか) master に reset --hard することで解決します。 すでに「常にfeatureブランチをmasterブランチから切ること」という運用をされているので、develop が forced push さ
ono_matope
モチベーションは理解できたが、developとmasterがまるで別物になってしまうのが良くない。任意のfeatureブランチを検証環境にデプロイする仕組みを整えた方が建設的ではないか。
gabuchan
feature/1が検証NGなのにdevelopにマージするのが問題。feature/1が検証OKになってからマージすればdevelopを健全な状態に保てるので追加のfeatureは開発しやすいし、developが健全ならmasterへのマージと本番デプロイも安心。
caffephilia
新しい方、たまにdevelopとmasterくっつけないと怖いな。検証サーバが参照するブランチ（例えばcanary）を別に流して、検証に通り、リリースも決定したタイミングでf>developにマージする運用にすれば元のでも行ける気がする
orenonihongogayabai
これ、「開発用サーバーが各自のマシン上で用意出来ない」という前提がある気がする。「検証機（という名の開発機）が一台しかないから一旦developにpushしない限りサーバー上での動作を見れない」んじゃない？
lalupin4
ブランチ戦略がコンフリクトしとる。/ 検証用サーバーが一つしかないなら develop にマージすんな / マージ待ちの feature が複数あるなら検証用サーバーを用意しろ / 1台が良いという判断になっているなら git-flow をやめろ
shiopon01
GitFlowは決まり事が多い分、パッと見でブランチが何をやっているか分かりやすいくらいしか利点が見当たらなかった(めんどくさいし)。GitFlowもGitHub Flow両方やった感想で言うと、成果物の品質に違いはあんまりない印象
Dai_Kamijo
GitFlowをやめて本番リリースが楽になった話 — 上條 大 (@Dai_Kamijo) May 14, 2018 from Twitter https://twitter.com/Dai_Kamijo May 14, 2018 at 11:39AM via IFTTT
vanbraam
id:snowcrush氏と同意見.Release operation的にはGitHub flowとの違いが不明.developブランチは検証=test operationの話;重厚長大なGitFlowをやめて,極めて単純なGitHub flowに変えたらリリースが"楽"になるのは当然
marmot1123
featureの時点で検証せずdevelopにmergeするのがおかしいのでは……他の人も言ってるが。あるいはdevelopでNGが出た瞬間にdevelopをrevertするとか……
hdampty7
各featureはdevelopのbranchにする。各featureをdevelopにマージする際にプルリクを利用してレビューする。developにマージ後検証環境で動作確認。masterへマージ＆リリース。のようにすればOKかな。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
【GitFeatureFlow】GitFlowをやめて本番リリースが楽になった話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure y... Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
2018/05/13 リンク