场景：使用git推送到远程仓库。本地和远程是常规git存储库，未加密。将可能的ecryptfs文件系统放在repo中的文件夹中进行推送。
如果：git pre-hook将确保卸载文件夹（umount~ / encrypted_folder /），并回显命令行，例如＆＃34;包含加密的ecrypfs文件系统的文件夹已关闭＆＃34;，然后git会将repo推送到它的远程位置，包括在确保文件夹已卸载后包含加密文件系统的文件夹，因此加密就可以了。到＆＃34; umount＆＃34;没有要求密码。没有观察到常规git功能的技术复杂性。
会产生什么不良后果？
一个很明显：控制加密文件或文件夹的版本将无关紧要。这是可以接受的。
第二：不是git节俭，每次推送都会将整个加密文件夹写入远程，并使远程存储库膨胀吗？
第三：git＆＃34;腐败＆＃34;以任何方式加密文件夹？激励：复制包含加密的ecryptfs文件系统的文件夹是微不足道的，使用rsync或scp也是一个明显的建议，不包括该文件夹在repo中，使用＆＃34; .gitignore＆＃34;还... ...
但出于工作流程原因：git用于备份，忽略包含加密文件系统的文件夹的版本控制，无需求助于其他任何事情并使用户保持琐碎。现在，一个git推送到多个远程位置，可以为每个用户提供所有需要的数据备份。出于工作流原因，每个用户，保持这种方式会很好。
白皮书：一个备份blob，大部分是版本化的，并且能够在repo及其远程克隆中拥有一些加密数据。禁止相关文件夹被打开＆＃34;通过git pre-hook。一次性git操作中的一切。 Ecryptfs包含在数据的加密部分内，以及“打开和关闭”所需的任何内容。密码短语。这将导致高移动性，需要在任何远程位置将远程仓库克隆到任何支持git-ecryptfs的设备，并且可以访问加密数据。