バージョンをGit的な視点で観察してみる
hello.txtでオートセーブやバージョンの仕組みを調べているときに、面白い仕様を発見した。
あるとき、hello.txtをリッチテキストで保存してしまった。(テキストエディットは、command-shift-Tのショートカットで素早くリッチテキストに切り替えられる!)リッチテキストにすると、ファイル名の拡張子がhello.rtfに変化する。その状態で保存すると、Snow Leopardまでは「hello.txt」に加えてもう一つ「hello.rtf」ファイルが新規作成される。当然、Mountain Lionでもそのようにファイルが追加されると考えていた。
ところが、現実は違った...。デスクトップから「hello.txt」は消えてしまった。いや、「hello.txt」のファイル名が変更され「hello.rtf」として保存されたのだ!編集中のファイル名の変更は「別名で保存」されるのではない。今開いているファイルの名前を変更することになるのだ。
では、バージョン履歴はどうなるのだろう?hello.rtfに変更すると、hello.txtのバージョン履歴が見えなくなってしまうのではないか?そんな不安がよぎったが、それは無用な心配だった。ちゃんとhello.txt世代からのファイルを追跡してくれている!(素晴らしい!)そしてこの仕組みは、一貫している。
- ファイル >> 名称変更...でファイル名を変更しても、バージョンブラウザは追跡してくれた。
- 編集中にFinderでファイル名を変更しても大丈夫。バージョンブラウザは追跡してくれた。
同様に、
- ファイル >> 移動...でファイルの位置を変更しても、バージョンブラウザは追跡してくれた。
- 編集中にFinderでファイルを移動しても大丈夫。バージョンブラウザは追跡してくれた。
なるほど!こんな仕組みになっていたのか、という閃きがあった。そして、「ファイル >> 複製」や「optionキー+ファイル >> 別名で保存...」と組み合わせることで、これはもしやGitなどのバージョン管理システムで言うところの「タグ」や「ブランチ」を実現できるのではないか?と思い始めたのであった。ちなみに「複製」と「別名で保存...」の違いや仕組みは以下のようになる。
「複製」と「別名で保存...」の違いや仕組み
- 「複製」= 現在の書類をコピーして、名称未設定な新規書類を作成する。
- 元の「hello_world.rtf」ウィンドウを残しつつ、「名称未設定(hello_world.rtfのコピー)」ウィンドウが開かれる。(2つのウィンドウが表示されている状態)
- まだファイル名を指定せず、保存していない状態である。
- 「別名で保存...」= 現在の書類をコピーして、別のファイル名で保存する。
- 元の「hello_world.rtf」ウィンドウは、別名で指定した名称のウィンドウに置き換わる。(1つのウィンドウが表示されている状態)
- すでにファイル名を指定して、保存している状態である。
- 「複製」や「別名で保存...」で作成された書類は、どちらも元の書類のバージョン履歴には影響を与えない。
- 「複製」や「別名で保存...」された時点から、新たなバージョン履歴が始まる。
タグやコメントを付ける
- もはやバージョンでは、ファイル名がどのように変化しても、決して見失うことなく追跡してくれることが分かった。
- ならば「名称変更...」を大いに活用して、ファイル名にコメントやタグの情報まで含めてしまえば良いのではないかと。
- ファイル名がすべて同じでは、一体どのバージョンに戻ったら良いのか悩んでしまうこと必至である。
- デスクトップに見えるファイル名にタグやコメントが含まれることに抵抗を感じる時は、
- タグやコメントを「名称変更...」で追加してバージョン履歴に追加した後に、
- 再び、タグやコメントを「名称変更...」で削除して純粋なファイル名に戻す。
- 以上のように運用しておけば、最終的にFinderから見えるのは、純粋なファイル名だけにできる。
- また、書類のどこかに何か1文字追加して、すぐ削除すれば、書類は「編集済み」の状態になる。
- 「編集済み」の書類は、内容がまったく同じであっても「ファイル >> 保存(command-S)」することでバージョン履歴に何度でも追加できる。
- 以上の方法で、タグやコメントは、思い立った時にいつでもバージョン履歴に追加できるのだ!
ブランチを作る
- ブランチは「複製」または「別名で保存...」することで実現できる。
- ブランチ名は、タグやコメント同様、ファイル名に含めておく。
- 但し、ブランチはバージョン履歴として継続していくので、タグやコメントとは区別した位置に書き込んだ方が良さそう。
- 例:(コメントのテキスト)ブランチ|hello_world.rtf
- あるいは、ブランチ名のフォルダを作って、そのフォルダに保存するようにしても良いかもしれない。
- フォルダ方式なら、ファイル名に余分なブランチ名を追加しなくてもいい。
- 実際に、バージョン管理システムであるSubversionは、この方式でブランチを作るのだ。
その他のGit的な視点
バージョンでは、作業ファイル・インデックスの明確な区別はできないが...
- ファイルが「編集済み」の状態でオートセーブされるのは、Gitで作業ファイルに保存する感覚に近い。
- そして、ファイルを「確定」状態にするということは、Gitでgit add(インデックスに追加)する感覚に近い。
- 「確定」状態のファイルは次に編集された時に、自動的にgit commit(コミット)される感覚に近い。
- 「ファイル >> 保存」メニューの実行は、git commit -a(インデックスに追加&コミット)する感覚に近い。
- バージョンのバージョン履歴は、Gitでは.gitフォルダ内のリポジトリである。
活用例
タグやコメントの例
- 監査などで指摘があると、ちょっとした修正の財務諸表を複数作る羽目になる。
- ファイルはたくさんあっても、過去のファイルを使うことはほとんどない。
- そのような場合は「タグ」や「コメント」を付けて、1ファイルのバージョン履歴で管理した方がスッキリして良さそうな気がする。
- 契約書などの履歴管理は、「タグ」や「コメント」でバージョン管理しておくと良さそう。
ブランチの例
- 企画書を提出したら、2つのケースに分けた案にして欲しい、と要望されてしまった。
- 2つの案は、その後の会議で何度も修正していく可能性がある。
- 修正が繰り返される可能性があるのなら、「ブランチ」方式で2つのファイルに区別して管理した方が良さそうな気がする。
もし、これ以上の使い方がしたくなったら...
- マージしたい。
- 差分で追跡したい。
- 複数人で作業したい。
その時は、素直にGitなどのバージョン管理システムを使いましょう!