パッチベースのワークフロー

オープンソースではパッチベースのワークフローがあるという記事をメモ。

【元ネタ】
gitster's journal - 入門Gitの目次はというと

入門Git - idesaku blog

2009-10-11 - 未来のいつか/hyoshiokの日記

gitster's journal - 入門Gitの目次はというとで、下記の文章が目を引いた。

第十章ではじめて、オープンソースの世界で多用されるパッチ・べースのワークフローを登場させた。
会社で仕事に使うだけ、というユーザには馴染みのないワークフローと考え方だと思うので、パッチ・べースのワークフローを使わない向きは飛ばして貰っても、本の他の部分を読むのには全く問題がない。
そのかわり、ボクがこれまでLinus君と一緒に仕事をしてきて学んだ、オープンソースコミュニティで生きてゆく際のコツ、といったものを「オープンな開発プロセス」という一節としてこの章に加えることにした。
ボクの経験が、少しでもオープンソースに関わる人たちに役に立ってくれると良いな、という考えからだ。

入門Gitは今予約中で読んでいないので、以下想像した事をメモする。
＃間違っていたら後で直す。

上記の言うパッチベースのワークフローは下記の意味だろう。
オープンソースコミュニティできちんと管理されているシステムのソースコードは、必ずコミッタが厳重に管理している。
ユーザが機能追加やバグ修正したソースを反映させたい時、パッチを作ってコミッタに送る。
コミッタはそのパッチをレビューして、フィードバックし、OKならコミットする。

このワークフローは実は、ReviewBoardやRietveldなどのコードレビューシステムと同じだ。
つまり、パッチベースのワークフローの目的は、コードレビューによる品質チェック、開発者同士の暗黙知の共有を指すと思われる。

普通のSIでは、上記のようなワークフローを持ったコードレビューは持っていないのではないか？
実は、オープンソースの方がはるかに高品質な開発プロセスを持っているのではないか？

また、パッチベースのワークフローをGitやMercuiralのような分散バージョン管理が補完している特徴も見逃せない。
マスタリポジトリはコミッタしか変更できないが、開発者は自分の好きな場所でリポジトリをコピーできてハックできる。しかも、マスタリポジトリから即座に最新ソースをマージして、常に最新バージョンにできる。
この分散バージョン管理におけるトピックブランチの仕組みが、パッチベースのワークフローを簡単にさせているのだろう。

GitもTortoiseGitがかなり機能改善されたので、TortoiseHgと比較しながら使ってみたい。