バージョン管理システムでTeam開発を始める

データにはバイナリファイルとプレーンテキストが存在する

プレーンテキストは差分の管理がしやすい

ファイルの「変更内容」「作成変更日時」を時系列で保存

過去の状態に戻せる

変更内容を時系列で追える

最近のものは「複数人がバージョン管理する」ことにも対応

本来は「複数人で同時に使う」ことは対応していない

Aが更新したことに気づかず、Bが以前のverに上書きしちゃう

Aの更新とBの更新に競合（コンフリクト）が発生した場合削除が難しい

バージョン管理システムでは「データベース」が存在する

データベースをレポジトリという

データベースには時系列にファイルの差分Dataが保存されている

1→2→3→4とデータ変更があった時

1,2,3,4時点での「ファイル」そのままを保存しているわけじゃない

1, (2と1の差分), (3と2の差分), (4と3の差分)を保存している

差分保存なので、「バージョンが増えるたびに指数的にData量が増える」ことを防いでいる

有名なところはgit。これだけ覚えていればいいくらい

Gitが他と違うのは「分散型」であるところ

開発者全員のPC内にレポジトリが存在する

ネットワークに繋がっていなくてもバージョン管理（つまり開発）が可能

巨大Codeである「Linux Kernel」の開発に満足いくものとして生み出された

変更点の抽出、repository操作が高速で行えるように

ノンリニアな開発styleを今日うりょくにsupportした

ノンリニア…つまり「複数人が違う機能開発をした後に…合流する」ことを可能としている

リーナスが元にしたgitの原則

CVSを「悪い見本」とする。設計上のことで確信が持てない場合は、CVSと逆の決断をする。リーナスは冗談めかして以下のように語っている。

分散型の、BitKeeperのようなワークフローをサポートする。

データ破壊に対する強力な抑止機能。データ破壊は、偶然によるものと意図的なものの両方を想定している。

非常に高い処理速度。

https://gyazo.com/5aae7861156d7c4596da5828b139fd7b

ブランチモデル

開発文化/開発対象の性質によってbranchのruleを変えている