Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi

GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’

[a666666]

ここでいうブランチは topic branch (+ pull request) のことではない、んだよね？ / 巨大になればなるほど trunk/master と乖離した枝のメンテはきつくなる（だから避ける）、というのは納得感ある。

[nekoruri]

ブランチは個人で使うもの、チームで使うべきはフラグというのが最近の潮流だと思う。

[moomindani]

サービス屋だからこそなせる技。ソフトウェア屋はどうしても複数バージョン開発せざるをえないし。

[ymm1x]

2013

[kgrock]

Tue, 30 Jul Google の巨大レポジトリとブランチ無し運用

[todesking]

2013年の記事。Googleのバージョン管理って今もPerforceなのかな

[koriym]

"依存しているライブラリのバージョン固定や、レポジトリのブランチで得られる安定性は、借金なのだ。"

[tyru]

「ライブラリの作者が、自分のライブラリを使っている世界中の全てのソースコードを直すのは不可能だ。でも、企業の中なら、呼び出し側を一気に変更することも、ある程度は可能なんじゃないだろうか」

[kshimizu1226]

リポジトリ関連

[mikage014]

そういう考え方もあるのか／「Everything runs at head」

[sakuragaoka]

やー、ちょっと極端なんじゃないの？天才の考えることはよくわからん。

[sonots]

途中のコードでもとりあえずコミットしておきたい派だから、ブランチないとやれる気がしない

[beakmark]

エクストリームだけど、いいたいことはわかる。／

[trashtoy]

単体テスト・自動テストがきっちり書けている文化であれば、このアプローチは結構アリかも、と思った

[jiskay]

フレームワークの実装や開発者個々人の力量が問われたり自動テストが必須だったりすると思うけどもマージ作業に苦しめられている現状から開放されるのであればブランチ無し運用を試してみたい

[tgk]

「巨大レポジトリにはいろいろメリットがあるが、一番大きいのは「呼び出し側のコードをまとめて変更できる」ことだと思う」

[tarchan]

＞ブランチ vs. フラグ

[honeybe]

へぇ。

[teppeis]

ブランチ vs. フラグの話、Chankoとかと通ずる話。「ブランチは個人で使うもの、チームで使うべきはフラグというのが最近の潮流」

[hotoku]

勉強になった。利点は納得的なので、苦労する点と回避の為のノウハウを知りたい。

[hiroomi]

「様々な機能ごとのモジュールがあるが、全部同じレポジトリにコミットしている。」

[tak4hir0]

Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi

[wyukawa]

ふうむ

[Dryad]

なるほどなぁ。／OSSと違って企業内ソフトウェアで多様性が求められる局面は少ない、ということなのかな。が、逆を言えば、という考え方もできそう（企業というのは生来モノカルチャーだというのはともかく）。

[mabots]

ブランチ無し開発

[yojik]

超興味深い。

[lesamoureuses]

へぇー！何だかすごいと思ってしまう。共通モジュールみたいなものの管理はどうなってるんだろう

[materia-x64]

Google の巨大レポジトリとブランチ無し運用

[oppara]

Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi

[t-wada]

興味深い