Git、変化を受容することの一側面を支援するソフトウェアとしての・・・
gitというものがあります。
なかなかとっつき悪いです。
ただ、その機能には感服せざるを得ません。
gitなどを「分散型バージョン管理システム」と呼ぶことがあると思いますが、ちょっと誤解を生むかもしれませんね。gitにかぎらずSubversionだってCVSだって、まぎれもないサーバクライアント型の分散システムだからです。
重要なのは、gitなどは「分散型のリポジトリ」をサポートしているという、ということです。
ソースコードが複数個所にある、という状況を扱えるということですね。
でもちょっと待ってください、SubversionでもCVSでも、作業している人それぞれが修正途中のソースコードをコピーして持っているし、マスターと人数分のコピーは分散しているといえませんか。そうなんですよ、結局管理対象のソースコードの分散は避けられないものなんです。
SubversionやCVSは、そういう「不可避的に分散されたコード」を手際よく扱うことができません。Gitはそれが扱えます。
結果として、gitは、現実のソフトウェア開発で起こりうるさまざまなソースコード管理にまつわるワークフローに対応可能であり、Subversionはできない、と言うことです。これが本質です。
その他のgitの特徴として動作が高速ということが挙げられます。ローカルにコミットして、有るタイミングでまとめてサーバにプッシュ、ということができるからです。速度というのは重要で、程度問題がある閾値を越えると質の問題に転化するというか、これによってできなかったことがさまざまにできるようになります。たとえば、ブランチを湯水のように切ったり、スタッシュといって作業中のワークを名前をつけていくつも保存したりしておくことができます。
余談ですが、結局のところ、ソースコードというのは開発過程やライフサイクルを通してみると、まったく静的なものではないのですね。時間の次元を加えて見る必要がある動的なものです。表現として言うと、絵画ではなく、ムービーなんです。
「時間軸を通じて変化するものとしてのコード」としてソフトウェアというものを認識して、それをシステマティックに管理する仕組みの１つが、ソースコード管理システムであり、git（とかの分散型バージョン管理システム）はその観点から新たな地平を切り開いた21世紀のソフトウェア開発のトレンドであるといえましょう。gitがとっつきにくいとするなら、その苦痛は、あつかおうとしているものの本来の複雑さを明らかにしてしまうからかもしれません*1。
余談ですが、「時間軸を通じて変化するものとしてのコード」を認識することは、拡張性や保守性を重視して設計する、ということの背景でもありますね。
OSGiフレームワークなどがもつ、「複数バージョンのモジュールを同時に区別して動作させられる」という機能も、ソフトウェアの時間進化を認識するなら避けがたい機能であり方向です。自動アップデート機能もそうですね。
未来のソフトウェアは、そういう変容をもっと積極的に許容するものになるでしょうね。動作しつつ、機能が変幻し、自己修復していくようなもの。リブートを不要として、変化していくのに、落ちたりバグったりしないもの。そのためには、追加はされるが変化しない、関数型言語のような特徴が重要になってくるかも。
もしそうなら、ソフトウェア開発というもののありかたも、変わっていかざるを得ないでしょう。なんとなれば、ソフトウェアは、その開発した組織の構造を反映するものだからです。
あ、あと補足しときますと、私はgitは単に使ってるだけです。その片鱗を垣間見せてもらってますが、ぜんぜん達人とかではありませんので、あしからず。
