通常は圧縮されたファイルの「非圧縮」バージョンを何らかの方法でリポジトリに保存することは意味がありますか?
もしそうなら、これを実装する標準的な方法はありますか? (おそらく、そのような各ファイルを特別な名前のフォルダーに圧縮解除する標準の pre-commit フックと、そのような特別な名前のフォルダーを、LibreOffice が読み書きできる圧縮ファイルに圧縮する post-checkout フック? プロセスのようなもの? 「アーカイブする前にzipを解凍する必要がありますか？」で説明されていますか？）（おそらく、バージョン管理ソフトウェアのコードをハッキングして、古いバージョンと新しいバージョンを自動的に解凍し、解凍されたファイル間の差分を保存します。大幅な改善を提供するには、元のファイル間の直接差分を保存する元のシステムにフォールバックするか、単にファイルを直接保存しますか?)
頻繁に編集される OpenOffice / LibreOffice ファイルのコレクションがあります。「Should images be stored in a git repository?」で推奨されているように、バージョン管理リポジトリにそれらを保存しています。. たまたま、git ではなく、TortoiseHg または SourceTree を使用してリポジトリにアクセスしています。
Open Office ファイルは、実際には zip 圧縮されたコンテナーであり、内部にいくつかの XML ファイルがあることをたまたま知っています。(他の多くの一般的なアプリケーション「バイナリ ファイル形式」も、何らかの形式の zip 圧縮ファイルであると聞いています)。
私の理解では、そのような「バイナリ」ファイルへの最小の変更でさえ、リポジトリに格納された新しいファイル全体につながるということです。「テキスト」ファイルの小さな変更とは対照的に、変更のみが保存および送信されます。
理論的には、次の利点があります。
- 変更がほんの数単語である場合、変更ログの「差分」ビューで変更された正確な単語を確認できました。（有益ではない「バイナリファイルが変更されました」というメッセージではなく）。
- 何人かの異なる人がファイルのバージョン 14 を個別に編集する場合、すべての改良点をバージョン 16 のファイルに回帰することなくマージする方がはるかに簡単です。
- リモート リポジトリとの同期が高速化されます。(圧縮された) ファイル全体ではなく、短い「変更」のみを送信する必要があります。
- ディスクスペースの観点から、おそらく小さいリポジトリ-数百の変更の後、これらのファイルの数百の完全なコピーを含む比較的大きなリポジトリではなく、数百の小さな変更のみを含む比較的小さなリポジトリを期待しています。(この利点は最後にリストします。なぜなら、最近の安価なディスク容量にはほとんど関係がないからです)。