Google社内でのソースコード管理には「ブランチ」は使わない 33
ストーリー by hylom
Googleの樹の下で 部門より
Googleの樹の下で 部門より
あるAnonymous Coward 曰く、
Googleが開催している開発車向けイベントGoogle Test Automation Conference（GTAC）にて、Google社内での開発手法について発表されていたとのこと（発表資料、発表動画、Google の巨大レポジトリとブランチ無し運用 — Kato Kazuyoshi）。
これによると、Googleでは40以上のオフィス、1万5000人以上の開発社、5000以上のプロジェクトが存在するそうなのだが、これらプロジェクトで開発されるコードはソースコード管理システム内の単一のツリーに格納されており、どのプロジェクトも同一のリポジトリを利用する形になっているらしい。さらに、ソースコード管理システムのブランチ機能は利用せず、コミットはすべて最新バージョン（head）に対して行われるルールになっているそうだ。
これにより、プロジェクト間での使用するライブラリのバージョンが統一できる点がメリットになっている模様。ただ、こういった開発スタイルはGoogleだからこそできるわけで、さまざまな関係者が入り乱れ、そのスキルレベルも異なる日本の開発会社ではなかなか導入は難しいような気がする。
ユニットテスト・ユニットテスト・ユニットテスト (スコア:4, 参考になる)
スキルレベルが一定であることと、余計なブランチ作って管理を複雑にすることはない、みたいな当たり前の一般論と、何の関係があるのだろう・・・。
もともと、元の発表資料の主題はテストエンジニアリング、自動テストに関するトピックが大半で、ブランチがうんぬんの話とはあんまり関係ない。
Chrome 28 beta 作ってる間に、Chrome 26 のリリース準備してるとか、（バギーなものをリリースしてしまうと影響が大きいので当然ですが）分けるべきところは分けて、慎重にやってるようにも見えます。
この動画と発表資料から学ぶべきことは、まさにテストのことであり、ソースコード管理などはそれに比べれば些細な話。
googleの開発者はスキルレベルが統一されているの? (スコア:2, すばらしい洞察)
1万5千人以上いてスキルレベルが皆同じぐらいというのはちょっと信じがたいのですが。
Re:googleの開発者はスキルレベルが統一されているの? (スコア:1)
「皆同じ」じゃなくて「低い奴はクビになる／低い奴にはコードを書かせない」じゃね？
日本は低い奴に書かせて、高い奴に尻ぬぐいさせるから……
＃そして一番低い奴らがマネージャーになる。
Re: (スコア:0)
同じ事を思った。
なんか｢Googleだからこそできるわけで｣っていう神話で誤魔化してるよね。
Re: (スコア:0)
必要になったら新しいプロジェクトを立ち上げるのです。
Re: (スコア:0)
全世界から広域募集したなかから上澄み採用しているのだから
これに満たない要因は足きりされて採用していないってことだよ。
だからもんだない。
ところが日本だと・・・。
Re: (スコア:0)
そもそもレベルが統一されてるって日本語がおかしいだろ。
Re: (スコア:0)
レベル50：戦士
レベル50：勇者
レベル50：僧侶
レベル50：おまえら
あれ？統一されてね？それとも僕が日本人じゃない？
Ｗｅｂアプリ (スコア:2, すばらしい洞察)
常に最新バージョンをサーバーに置くことのできるＷｅｂアプリだからということは
最低限必要な条件だと思う。
出荷済みの複数のバージョンのアプリがあって、それぞれにバグフィックスを
していけば、自然とブランチが増えていく。
とはいえ、Webアプリでもブランチ使ってる所は多そうだけどな。
Re:Ｗｅｂアプリ (スコア:1)
そういう意味では, 顧客が1つしかない社内向けシステムでブランチが無いのは自然ですね.
# 事業部が違えば別会社も同然なんてとこもあるけど
Re:Ｗｅｂアプリ (スコア:1)
全然自然じゃない。
現行版の保守ブランチと次期版のブランチとって感じでやっぱり使う場合は使う。
Re:Ｗｅｂアプリ (スコア:2)
保守ブランチは必要になったときに作ればいいから、都度作る必要はないです。
次期版はHEADで行うとして、次期版の開発期間が十分短い、かつ何度も更新を繰り返すなら、自然とHEAD一本になるかと。
Re: (スコア:0)
> 次期版のブランチ
これは幹(HEAD)じゃないの？
Re:Ｗｅｂアプリ (スコア:1)
次期版の内容が盛りだくさんだと、スケジュール通りにならない場合もあるので、分けたほうがよいです。
まぁ別コメにもらったように内容次第ではHEAD一本で十分なので、そのほうが面倒がなくてよいですが。
要は「顧客が1つしかない社内向けシステム」だからブランチがないのが自然ではなくて、「これか何をするか」でブランチを作ったり作らなかったりするのが自然かと。
Re: (スコア:0)
Webアプリ。現在branch 2本。
コミット履歴に記入して、その後リリース申請書を書いて申請書チェックツールを噛まして、さらにチェックリストおよび修正前後のエビデンス等々を格納し…。
ちなみに本番稼動前。
Re: (スコア:0)
パッケージソフトウェアでバグフィックスにブランチ切る必要をなくす魔法の言葉
ブランチ (スコア:2)
あれ？そもそも (スコア:1)
googleって、プロジェクトへの修正や実装は「全てパッチでやりとりして」プロジェクトリーダーのコードレビュー通すんじゃありませんでしたっけ？ (要は、pull-reqquest方式)
だから１日に何十ものパッチのやりとりが行われるって、昔何かで見た覚えがあるんですが。
# google. コロコロやり方変えるから。今でもそーなのか知らないけど。その話見た時からブランチ使ってないって、書いてあったんだよなぁ。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re: (スコア:0)
レビューがあってレビューが通らなければコミットできないとすれば、同時にコミットして枝分かれって起きないよね。
さらに言えばgitつかっているならfast-forwardかrebase使えば1本になってしまうと思うし。
諸事情により (スコア:0)
スキルレベルはあまり関係ないですね。
むしろこういった手法を取り入れるのに困った場合、ルールを徹底出来ない「諸事情」のほうが問題なのでは。
＃上がGOせず、取り入れようともしないというところが大半かもしれませんが
Re:諸事情により (スコア:2)
＞＃上がGOせず、取り入れようともしないというところが大半かもしれませんが
Google だったら優秀な人材がたくさん（Ken Thompson とか）いて、簡単に Go できるでしょうが、
うちなんかはそもそも Go できる人材が皆無に近いです。
Re: (スコア:0)
一読しても しばらく、気がつかなかった。
この木なんの木仕様の木 (スコア:0)
お客様の枝の剪定が大変です。
Re: (スコア:0)
# 君らはなんでそんなに互いに衝突するような機能を作るのか。
ただ、こういった開発スタイルはGoogleだからこそできるわけで (スコア:0)
の説明（根拠）がどこにもないｗ
Re:ただ、こういった開発スタイルはGoogleだからこそできるわけで (スコア:1)
なければググればいいじゃないかな
Re: (スコア:0)
根拠も何もGoogleが実際にやってるしかも成功してるようだってことでしょ。
そしてこの開発スタイルはいわゆるベストプラクティスでないどころか、
どちらかというとやってはいけないことになってるわけです。
あなたは知らないかもしれませんがソースコード管理ではほぼ共通認識です。
それもあってこのような開発スタイルとをってるという例を他に見たことがない。
ということで「ただ、こういった開発スタイルはGoogleだからこそできるわけで」
というのは十分説得力があります。あなたは知識が足りないようですからそうは
思わなかったようですがね。
プログラマが多くいるサイトだしあなたに配慮する必要もないし。
Re: (スコア:0)
ブランチを使わないという点については、FacebookやFlickrもそうですね。
http://gihyo.jp/dev/serial/01/comparators/0003 [gihyo.jp]
http://martinfowler.com/bliki/FeatureToggle.html [martinfowler.com]
typo (スコア:0)
>開発車向けイベント
…ですよね?
Re: (スコア:0)
「車(くるま)」でも「社(やしろ)」でもなく「者(もの)」
…ではないかと思われますが，いかがでしょうか?
Re: (スコア:0)
マジレスすんなよ・・・
Re: (スコア:0)
>1万5000人以上の開発社
ブランチなんて開発効率を落とすだけ (スコア:0)
ブランチなんて問題の先送りにしかならない。
単品の開発なら最後にデバッグ期間を儲ければいいが、
常にバージョンアップを繰り返すサービスでは無理。
レベルが統一されてない、信頼出来ないからこそ、ブランチは不要。