2017/08/07 17:07:15
laiso
よくやるオススメ。メインの作業をしつつパッチ袋から1つ進捗を取り出して投げるような感覚。ネイティブappの場合よりフロント側で隠すのに苦労した。
2017/08/07 17:13:21
papix
ちょうど新機能リリースブランチパターンでウッとなっていたので, 早速真似して細かくやっていくことを試みています............
2017/08/07 17:15:20
shiba_yu36
社内勉強会発表内容を公開しました！
2017/08/07 17:24:59
tak4hir0
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました
2017/08/07 18:21:12
hush_puppy
FacebookやGoogleもトランクベース開発だっけ？ http://postd.cc/agility-requires-safety/ 大きなブランチのマージに対してはマーチン・ファウラーも恐れているらしい。 http://bliki-ja.github.io/FeatureBranch/
2017/08/07 18:44:23
Sixeight
よくマージできずにプルリクが連なっていって先頭の方で修正が入ることで死亡する
2017/08/07 18:54:00
teppeis
巨大ブランチを一気にマージではなく、フラグなどを使って少しずつ隠しながらマージしてリリースする5つのパターン
2017/08/07 19:04:24
progrhyme
なるほどー
2017/08/07 20:49:36
adwd118
こういうのやりたい
2017/08/07 20:51:17
hisaichi5518
結構似たような感じでやってる気がする
2017/08/07 21:10:56
lbtmplz
名前付けて
2017/08/07 21:14:32
seiunsky
ブランチが離れれば離れるほど怖いし使われなくてもプロダクションで動いてる安心感は段違いなので自然とこんな感じでやってるなぁ
2017/08/07 21:18:37
razokulover
言語化してなかったけど実際似たようなことめっちゃしてる気がする
2017/08/07 21:19:01
mackee_w
やっていきてえ
2017/08/07 21:47:45
escape_artist
いわゆるフィーチャートグルですね
2017/08/07 21:59:08
katoukaitou
わかる
2017/08/07 22:05:25
ka2hik0
わかりすぎてヘドバンしてたら首が痛い
2017/08/07 22:18:31
hinaloe
うーーーーん
2017/08/07 22:22:08
Magicant
何か新しい開発スタイルの話をしてる風に見えるかもしれないけど要するにこれ continuous integration と continuous delivery の話だよね
2017/08/07 22:27:30
yuutetu
メリットは、「大規模コンフリクトを防ぐ」「リリース時に既存機能が壊れない安心感がある」なのかな。「仕様の迷走や見えなくするコードが負債として溜まる」デメリットがでかい気がして素直に頷けない。。。
2017/08/07 22:49:19
udzura
とても共感がある
2017/08/07 22:53:05
rakusai
間違いなくよい
2017/08/07 23:00:33
matsumanahate
参考になる
2017/08/07 23:01:07
garage-kid
160
2017/08/07 23:12:00
bayashi_net
レビューの粒度が小さくなるのが良さげ
2017/08/07 23:19:31
xlc
そもそもなぜそんなにコンフリクトするのか考えた方がいいんじゃないの。①設計が悪く機能がきれいに分かれていない、②1つのシステムに関わる人数が多すぎる
2017/08/07 23:31:31
proverb
すげー分かる
2017/08/07 23:48:08
eos2323
超コンフリクト
2017/08/07 23:53:37
koogawa
# TODO でマークしていく感じなのね
2017/08/08 01:04:59
tettekete37564
イマイチメリットがハッキリしない。どれも原因は「超コンフリクト」と言っているが「細かくマージする」は運用でカバーする方法にしか聞こえないので根本的な設計(コード・分業の両方)に正しい解決方法がありそう
2017/08/08 01:35:01
PEEE
masterを適宜featureにmergeするんじゃダメなんだろうか。
2017/08/08 02:01:51
ghostbass
ちょっと試してみたいけど、リリースをうまくコントロールしないとフラグだらけになるかな、って。
2017/08/08 02:09:58
kenmaz
「ユーザーに見えない部分から作る」はよくやるな。機能Aの追加 <= の下準備B <= の下準備C <= .... って感じで逆から小出しに実装＆本番リリース、最後はfeatureフラグで表への出し分け
2017/08/08 02:35:28
ksyundo
？
2017/08/08 03:17:45
chinpokomon_master
なんでそんなコンフリクトするんだよ
2017/08/08 04:10:17
wonodas
#defineつかえばいいのに…
2017/08/08 05:30:50
kibitaki
バカヤロウこれは戦術だ！とミリオタが多いSIerでは怒鳴られるな。
2017/08/08 05:36:00
keijak
「ユーザーに見えないように」に関して、クライアントのバイナリを解析されて開発中の新機能がバレることがビジネス上のリスクになることがあり、真面目に対策するのはそれなりに面倒という観点は持っておくとよい。
2017/08/08 06:54:07
donkeyhole
大昔のやり方だよね。"蓋をする"って呼んでた
2017/08/08 07:26:07
hiroponz
良いと思う。
2017/08/08 07:42:02
vanbraam
そもそもmasterからbranchしたものをmergeする際にconflictする理由が不明.masterにhotfix等の更新が入ったのなら,都度masterをdevelopにmergeすれば良いだけ;あと多分featureが大きすぎる.複数feature並列開発も避けた方がいい
2017/08/08 07:46:48
uturi
でかい機能をドカンとぶち込むのはSVNでやるもんだと思ってた
2017/08/08 07:48:16
otihateten3510
PR多すぎ問題も皆気にしてほしい。PRは合議の場ではない
2017/08/08 07:49:36
solidstatesociety
"どんどん開発ブランチにmergeしていく" 本番では？ Facebookではそれを一部ユーザーだけに見えるようにしたりして、ユーザーテストする。
2017/08/08 08:02:51
d0i
やっぱりいらないやってなったときどうやって捨てるのかな。
2017/08/08 08:35:20
hase_done
良いと思ったけどそのチケットをやめたい・戻したい時大変そうだと感じたのだけどどうなんだろう
2017/08/08 08:55:41
bps_tomoya
機能単位 PR にならないのでレビューや Merge 時のコード量、コンフリクトが小さく押さえられる一方、後で「この機能の PR はどれだっけ？」というときに見づらかったり、revert がやや手間がかかる問題がある、かな。
2017/08/08 09:15:57
takogawa
巨大PRパターン、新機能リリースブランチパターン、身に染みて感じます
2017/08/08 09:19:35
suzan2go
思ったより反対の人が多いのにビビった
2017/08/08 09:21:58
tyru
わかりみが深い
2017/08/08 09:24:36
Nkzn
今年から似たような方針にシフトしたのでめっちゃ共感できる
2017/08/08 09:30:12
karikari1255
"他の機能で必要になったメソッドをcherry-pickしまくる"がさっぱり理解できない。依存関係が生まれているなら、素直にf2ブランチを(master経由するしないの議論はあるけど)f1にmergeすれば済む話なのでは
2017/08/08 09:35:45
mitsugogo
んなもん適当なタイミングでfeatureブランチをmasterでrebaseかけりゃ解決するんじゃないの？
2017/08/08 09:49:09
infobloga
罪悪感感じながら近いことをやっていたけど、この記事を読んで自信を持てた
2017/08/08 09:56:05
moyabi
Web だと入れた機能削る時 revert すること稀 (改良の PR マージしていくので revert が効きにくくなっていく) なので細かく merge する戦略取りやすいし, いままでその戦略取っていない会社に会ったことがない. 他業界はしらない
2017/08/08 10:02:03
h5y1m141
リリースする機能の粒度が揃わず似た悩みずっと経験してるから自分はこれ納得感あるなぁ。Railsだけど過去の負債返しつつ一部機能リニューアルでRailsEngine化の時にユーザーに見せないパターン使ってた
2017/08/08 10:04:12
tofu-kun
早めのパブロンみたいに早めのマージ
2017/08/08 10:07:38
luccafort
例えばA機能を実装しようとしたときに先にB機能を実装したことでA機能の意味がほぼなくなってしまってissue自体をCloseされたら場合各実装をrevertしていくのだろうか？あと入れ替えミスとかが怖い。
2017/08/08 10:24:16
dowhile
フロント側バック側を変えるような大きな改変がやりにくそう
2017/08/08 10:27:15
yamitzky
ブコメ見ると否定は多くて不思議
2017/08/08 10:29:22
wkubota
ブランチ戦略のアプローチ方法として参考になった。選択肢の一つにさせてもらおう。
2017/08/08 10:33:47
Pasta-K
似た感じでやってる
2017/08/08 10:36:29
takuji31
基本的にこのやり方でよくって、はてなブックマークのアプリでもこの手法でやってる。 唯一使えないのは大きめのリファクタリングを行う時で、そういう場合はやむを得ず集約branch作ったりする。
2017/08/08 10:44:14
holyshared
こういうのだいたいリリースまじかになってフラグ消し忘れがあるんだよなぁ。ネイティブアプリのサーバーの場合、複数バージョン意識しないと行けないから消せない場合あるし
2017/08/08 10:56:08
gomayumax
社内ツールぐらいだったらすぐに試せそう(・∀・)やりたい
2017/08/08 10:58:16
hasegawatomoki
「設計が悪い」のはあるかもしれないけど、完璧な設計など世の中には無いし、それを受け入れた上でどうやって前進するか、という話だね。
2017/08/08 11:03:43
naga_sawa
新バージョンリリース後は旧機能の掃除コミットが続く感じになるんだろうか
2017/08/08 11:17:36
satohu20xx
見えないとはいえ新しいコードが含まれるとそれはバグを生むものなので、できれば動くはずがないコードは入れたくないよね。
2017/08/08 11:29:35
uskey
作業分担とか実装順序の依存関係とか設計がきちんとしてたら必要なさそうだけど、そんなことない現実の開発環境だと有効な手の１つだと思う。細かくマージする以上細かくレビュー出来るのもメリットか。
2017/08/08 11:50:38
june29
わかりすぎる…。
2017/08/08 13:58:20
Dai_Kamijo
大規模マージのつらさに対する代替選択肢としてはありかも知れない。『「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました』 — Takuma SHIRAISHI (@ts7i) August 8, 2017 from Twitter https://twit
2017/08/08 14:06:29
tiki0108
とりあえず超コンフリクトは怖いので頻繁に開発ブランチからfeatureブランチにはマージしている。
2017/08/08 14:09:26
peller
featureブランチに携わるメンバーに一時手を止めてもらってrebaseする派。mergeするとcommitの流れが汚くなっちゃうのでね。
2017/08/08 14:22:13
mas-higa
ここは通らないからOK ... これを許してくれるプロジェクトならどんなに楽か。
2017/08/08 18:06:16
terazzo
共通メソッドの話は下のレイヤーから機能別にcommitすれば回避できそう
2017/08/08 23:14:30
mactkg
すばやくどしどしやっていくぞみたいな方向だと落としどころとして良さそうに思った！ 割と同じブランチでだらだら作業しがち…
2017/08/09 11:56:21
konisimple
これはアリだな。少人数なのでコンフリクトはしっかりmasterから mergeしてれば割と大丈夫だけど、PRが煮詰まってきたときに小さな修正が増えて、レビュアーが辛い問題が解消できそう
2017/08/09 17:18:54
nilab
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
2017/08/09 18:34:35
futeshi
masterを適宜featureにmergeするだと、リリース後に他の人が大量にコンフリクトするのが問題になりそうだと思いました
2017/08/10 10:23:41
efcl
Gitのfeature branchのマージ戦略について
2017/08/10 13:11:47
k-holy
分かるし、やってる。特にDBへのカラムの追加を伴う場合は既存機能に影響出ない形で先行してやる。1人開発だけど。
2017/08/10 14:19:56
aaa1234567
内容にケチをつけるつもりは全くないのだけれど、なぜこの記事にこんなにスターがつくのかはとても謎・・・