トランクベース開発とデプロイ - Mitsuyuki.Shiiba

前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする

[bufferings]

書いたのだ。ブログに書くことで自分の勉強になるというやつ。書いてよかった。

[yarumato]

“トランクベース開発はtrunk（木の幹）にみんなが小さな変更を加えていくブランチモデル。mainブランチを常にビルドが通る状態にしておいて、そこからリリース。マージつらくない。Googleも採用。GitHubFlowも結局これ”

[at_yasu]

プルリクが3日目過ぎたあたりから、作業細度がおかしいって思うようにしてる。そしてそれに今なってる…

[snjx]

これはいい整理

[ghostbass]

常にリリース可能って言うのが肝なので、中途半端な変更がテストもされずにメインブランチに紛れ込むと詰む。

[yigarashi]

自分のところはGitLabフロー + git-pr-releaseかな。ツールがだいぶ便利なことで他のフローを試す発想が出ない傾向がある気はしてて、もうちょっと柔軟に色々考えても良いかもなぁ

[Chisei]

長期開発ブランチ、いちチームだけがそれを管理しているならまあ良いけど複数チームで複数長期開発ブランチ持つとある時マージできなくなって詰む。

[ledsun]

“寿命の短い（長くても2日くらいの）フィーチャーブランチを作ってプルリクエストを出してマージする。一番シンプルな形だと、フィーチャーブランチも作らずに main に直接コミットするみたい。”

[remonoil]

リリーススタイルに合わせて取捨選択するだけ。独立して決めるものではない

[Wafer]

それsubversionでやれたんでないの？subversionのいいところはリビジョンが誰にでもわかる10進数で、ブランチも含めコミット順に数字が増えていくから開発陣以外にも「バージョンの数字が大きいほど新しい」とわかりやすい

[clubman023]

最近はほとんどこれ採用してる