脱ブランチファースト - 日々常々

あるいは「プルリクエストをやめてみた」 チーム構成とかにもよるんだろうけど。Gitかつフォークされないプロダクトでの話です。OSSとかは全然話は変わります。 問題とアプローチ (2019-10-25T15:20 追加) 表出している問題と、ここでのアプローチを書いておきます。 ブランチファースト（造語） 「ブランチファースト」はこのエントリでの造語です。コードベースに変更を加える際に「まずブランチを作成する」から始めることを指します。 作業単位でブランチを作成、ブランチでコードを変更してプルリクエスト、レビューを経てメインライン（ master ブランチ）に反映までがブランチファーストのスコープになります。 よくあるスタイルだと思いますし、ブランチだけ作成して変更せずプルリクエストを作成する拡張もありますね。 プルリクエストを挟まずにメインラインにマージするものは含みません。 ……名前微妙

[gfx]

masterに直接pushしていけばいいじゃんという話かしら。問題意識に共感できないのでよくわからないな…。

[minamimonji]

本当は違うところに問題がありそう。

[marshi]

featureと関係ないリファクタリングしづらくなるのはむしろ利点では…？関係ないなら分けてPRするのがいいと思うがやっぱり前提がよくわからない🤔

[ikeike443]

全く同意できないです。ブランチの生存期間が長すぎるのが問題だと思います。フィーチャートグルを使うべき。 | 追記:これはTrunk based devではない。""Trunk based dev at scale is best done with short-lived feature branches"

[june29]

前提としている状況がわからなかった…もうちょっと詳細を知ってみたい。

[Soudai]

弊社はリリースブランチは辞めた。futureブランチの生存期間はとにかく短くしていくこととリリースはPR単位で行っている。そして大規模なリファクタリングのようなコンフリクト怒ったときは作り直す感じだなぁ。

[kagerou_ts]

自分はmaster一本の環境からPRを使うようになって(多人数で作業するには)すげープルリク便利じゃんって思ってるからこれと逆の経緯。

[tune]

否定的なコメントが多いけど「これはtrunk based developmentという手法でGoogleやFacebookでも取り入れられています」と知ったら手の平くるくるする人が出そう。

[popotan3220000]

メンバごとに独立・並列に開発しにくくなるというデメリットがでかすぎるしコンフリクト起きない設計・担当分担をしてやってけばそんなしょっちゅうコンフリクト起きることもないでしょと思った

[mitaro]

だったらSubversionでいいんじゃない？とか言いたくなるくらいに、ソースコードをこんなふうに管理するのを憎んでる。/個人的なやつでも、ブランチバンバン切りたくならない？思いついたコードメモ的に残しときたい時と

[takezaki]

うーん

[akahigeg]

ブランチ使うことでうまく回らなくなるならブランチやめるのも一つってことかな。

[masaru_b_cl]

チームメンバーがひとかたまりのとこに集まってて、masterとorigin/masterを頻繁に同期できる状態ならわかる

[gidooom]

方向性の１つとして、自分は割と肯定派

[heavenshell]

全員がモブプログラミングで全て開発するのならありかもしれない。

[rryu]

無計画にブランチを作って実装してから使うものをマージしていくみたいなことをやるとなるやつ。結局最後は1本の時系列に収束するのだから、最低限のリリース計画的なものを作らないとぐちゃぐちゃになる。

[nunulk]

プロダクトに対するチームメンバーの認知の差をできるだけ小さくしたい、というのは日頃から感じているので、どこかで試してみたい

[HolyGrail]

よく分からなかった。表出している問題が発生しているようなチームでその問題解決のためにプルリクエストをやめる選択をしたらもっと大変なことになるのではという気しかしない。

[koogawa]

ブランチとかそれ以前にチーム間のコミュニケーションに課題がありそう

[gabill]

1人開発ならそうするかも知れないけど、多人数だとブランチの方が便利。仮にレビューしないにしてもプルリクという作業単位はあった方が良い。

[u_tis]

リリース範囲ごとの責任の所在やレビューフローを守ることで人為的な障害を防止したいとか、そういう保険を最小限にしても回る程度の開発しかしない or 個人なら良さそう。組織下でやったら全力で追い出しますけど。

[laiso]

「巨大なプルリクエストを何層かに分解して取り込む」「横断的な変更は集まって一気にやる」という対策していた。ステートフルなアプリケーションは分解が難しくて苦労した

[ono_matope]

「どうせまともにコードレビューされないんだからPRなんかすっ飛ばしていいじゃん」って言っているようにしか。止めはしないけど、ジョインしたチームのテックリードがそんなこと言ってたら嫌だな。

[peketamin]

“それって何をするかわからないメンバーを既にチームに入れてるってことですよね。コードだけ取り繕ってる場合ではないのでは……。”

[kazokmr]

gitの導入にあたって「どういうブランチ戦略が良いかわからない」という話がたまにあり、とりあえずブランチに拘らずに「タスク単位でブランチを切る」とか「svnと同じ運用から始める」とか言うことはあります。

[tkmkg8m]

詳細はわからないから推測でしかないけど、1つのブランチでいろいろやろうとしすぎなんじゃないかな

[lemarc]

svn

[hirata_yasuyuki]

全員が一定以上のスキルを持つ少人数のチームで、最初にある程度形にするまでならアリかなあ。

[tonchix]

んー、これ見ただけだとチームとか他のところに問題ありそう。

[michiomochi]

レビューはしないということ...？　あとみんながmasterにpushしてもコンフリクトする時はするのでは。

[mi_kattun]

必ずしも全ての変更をレビューする必要ないというのはわかる気がする。影響範囲が大きいリファクタリングはみんなで一旦手を止めて、モブプロでmasterにpushしてしまいたいと思うときある。

[nn1021]

最近ふと「イチイチなんでbranch切ってるんだっけ」と思うことが多かったので共感できる話。ただrelease branchは分けたいかなぁ。／理想的なGit運用ができていれば出てきづらい課題のはずなので別に問題があるのかも。

[bouzuya]

リリースブランチは使っていない

[a-know]

んむむ...？

[supaiku2452]

ファーストリリースするまでこんな感じの運用して楽だったと感じる一方で、コミットが個人の裁量になるので、絶賛クソコードがmasterに入った状態になった。

[newnakashima]

壊れたコードがmasterにバシバシ入ってきそう。新人によるforce pushとか。個人的には絶対にやりたくない。。

[hase0510]

朝ごはんや昼ごはんの話かと思って開いたら違った

[katzchang]

作りかけのコミットをすることが多いからなあ。どうすればいいんだろ。リリースブランチは不要ですね。