が素晴らしかった。
個人で開発する分には過剰な部分もあるかもしれないけど、feature branchからdevelop branchへ書き戻す場合に必ず--no-ffにするのは重要だと思った。ffでマージされると後でわけ分からなくなるもんね。
それとリンク先のWhy Git is Better Than Xがウケた。てかperforceの良いとこ全然なくてワラタ。
個人的にperforceが良いところは部分チェックアウトができる上でアクセス権の管理ができることだと思う。gitにはアクセス権を管理する機構がない。だから、アクセス権ごとにレポジトリを分けて他のシステムによって管理しなくてはいけない。これは面倒だし、レポジトリを分けた時点でatomic性は保てないという致命的な問題がある。
けど、それくらいだな。topic branchやremote branchの概念を覚えてしまったら、最早どうあってもcvs/svnのようなシステムには戻れない。
ちなみに自分が初めてgitに触った時分は、数人程度なら分散型である必要はなくsvnで良いんじゃね？と思ってた。しかし実際にはgitのbranchの可用性の高さは開発人数に関係なく有用であり、開発人数に関係なくsvnを使う理由が見当たらないと弾言できるね！ってGoogleIMEはこんな恥ずかしい単語まで変換してくれるのか。素敵やん。
ところでgitも使っていると不便だなと思うことは幾つかある。例えばdevelopやrelease branchが複数あり、develop-a,bやrelease-a,bに同時に投入すべきbugfixが幾つも出る状況。このときのmerge合戦は人手頼みだし、大量のmerge commitあるいはmergeできずcherry-pickされたcommitが湧いてcommit treeの可読性が落ちる。じゃあどんなシステムにしたらうまくいくのかと問われると、commit treeだけではなく、commit set, branch setのような概念 *0 が要るんじゃないかと思うのだけど、うーん考えただけで実現への課題は山積みか。
*0 : treeのような依存性を前提とした関係性だけでbranchを作るのではなく、branch-a,b,cを集めてrelease-aとして、branch-a,b,c,dを集めてrelease-bと定義できれば、branch-aを修正するだけでrelease-a,bが修正される、というアイディア。実際には依存性があるわけで両方で異なるcollisionが起きたときにどう管理するんだっていう話等が出てきてシンプルなシステムに落とすのは難しそうだ。この場合ならglue commitのような概念を入れれば良いかもしれないが
・複数のファイルをComponentと呼ぶ単位でまとめ、その単位でバージョン付、タグ付ができるようになっています。
・さらに、複数のComponentは、Streamと呼ばれるコンテナに格納されます。（Streamは一般的なSCMシステムではブランチに相当します。）
・同じComponentが、異なるStreamに格納可能です。そして、任意のStream間でComponentを流すこと(Flowと言います。つまりマージ)ができます。
・Stream自体にも、ある時点の状態でタグ付することができます。
RTCには、もっと、色んな特徴があるけど、SCMのブランチ戦略に関係する部分だけを簡単にいうと、とこんな感じになると思います。非常に高価な商用ソフトですけどね。