在 Beanstalk / Github / Bitbucket 中使用 Git 进行 FileMaker Pro 版本控制？
FileMaker Pro version control with Git in Beanstalk / Github / Bitbucket?
我们目前使用 Subversion 对我们的 FileMaker 开发进行版本控制，但我们开始探索转向 Git。我们听说有人在使用 Git 处理 FileMaker 文件时遇到文件损坏的传言，但我无法追踪到任何真正的来源。
是否有人使用 Git 来控制 FileMaker Pro 文件的版本？除了在提交之前需要完全关闭文件之外，您遇到任何问题吗？
我没有使用 FileMaker 的经验，但是 Git 非常擅长维护您提交的内容的完整性。 （是的，您可能需要退出应用程序以确保在提交之前一切都处于一致状态，但这是 FileMaker 的事情，而不是 Git 的事情。）
但是，如果 FileMaker 文件是 (a) 二进制文件或 (b) 大文件，您可能需要继续查找。 Git 的许多功能都是围绕处理文本文件而设计的，任何类型的大文件都会导致存储库大小和性能受到影响。例如，我不会用它来控制 Access 数据库的版本。
另请注意，托管 Git 提供商通常对文件和存储库具有最大文件大小。
例如，GitHub 当前将配额设置为 100MB per file, 1GB per repository. On that same page they also explicitly recommend against storing database dumps，通常是非常大的文本文件。
Bitbucket 有一个 soft 1GB repository limit and a hard 2GB repository limit。
我使用 Git 和 Subversion 对 FileMaker 文件进行版本控制。 Chris 对大小限制提出了一些很好的观点，但是在使用 git 时有一些方法可以做到最好。
FileMaker 的版本控制文件损坏
我怀疑传闻中的文件损坏并非来自 git 的具体使用，而是来自用户在使用 git 时与文件交互的方式。
当您打开 FileMaker 文件时，FileMaker 客户端直接与二进制文件本身交互。在文件处于活动状态时正在读取和写入数据和结构，因此如果您尝试在该过程中提交文件，您将面临损坏的风险。这种风险对于 Git 和 Subversion 都是一样的。
无论何时使用 FileMaker 文件和版本控制，您都需要确保在提交之前关闭文件。您不一定需要关闭 FileMaker 本身，但需要关闭文件。
此外，请确保文件确实已关闭。您可能认为该文件已关闭并打开了隐藏或屏幕外 window。转到 Window 菜单并确保在提交之前关闭所有 windows。
文件大小
您绝对可以对 FileMaker 文件使用 git，但是如果您要推送到 public 远程托管服务提供商，您将 运行 进入这些大小限制。也就是说，如果您有自己的本地 git 服务器，那么大小可能不是问题。
处理存储库大小的最佳方法是将克隆提交到您的存储库。如果您在 FileMaker Server 上工作，您可以使用启用克隆的备份计划来轻松地将它们吐出。这也解决了打开文件问题，因为您将提交克隆备份，而不是活动文件。
这可能会很痛苦，因为现在您的所有数据都不在文件中，并且 FileMaker 没有很好的内置自动化功能来将数据带回，但是您可以构建一个传输文件 运行s 从您填充的文件（在版本控制之外）导入您的克隆（在版本控制中）。我们几乎为我公司的每个项目都这样做。
归根结底，在版本控制中要跟踪的重要事项是结构，而不是数据本身。存储克隆应该减少文件大小，足以使版本控制系统可行。
您可以将 Filemaker 文件的克隆保存到 Git 存储库中。这将绕过 Git 对除超大数据库以外的所有数据库的限制，并避免将未关闭的文件写入存储库 ("corruption") 的问题。
我们目前使用 Subversion 对我们的 FileMaker 开发进行版本控制，但我们开始探索转向 Git。我们听说有人在使用 Git 处理 FileMaker 文件时遇到文件损坏的传言，但我无法追踪到任何真正的来源。
是否有人使用 Git 来控制 FileMaker Pro 文件的版本？除了在提交之前需要完全关闭文件之外，您遇到任何问题吗？
我没有使用 FileMaker 的经验，但是 Git 非常擅长维护您提交的内容的完整性。 （是的，您可能需要退出应用程序以确保在提交之前一切都处于一致状态，但这是 FileMaker 的事情，而不是 Git 的事情。）
但是，如果 FileMaker 文件是 (a) 二进制文件或 (b) 大文件，您可能需要继续查找。 Git 的许多功能都是围绕处理文本文件而设计的，任何类型的大文件都会导致存储库大小和性能受到影响。例如，我不会用它来控制 Access 数据库的版本。
另请注意，托管 Git 提供商通常对文件和存储库具有最大文件大小。
例如，GitHub 当前将配额设置为 100MB per file, 1GB per repository. On that same page they also explicitly recommend against storing database dumps，通常是非常大的文本文件。
Bitbucket 有一个 soft 1GB repository limit and a hard 2GB repository limit。
我使用 Git 和 Subversion 对 FileMaker 文件进行版本控制。 Chris 对大小限制提出了一些很好的观点，但是在使用 git 时有一些方法可以做到最好。
FileMaker 的版本控制文件损坏
我怀疑传闻中的文件损坏并非来自 git 的具体使用，而是来自用户在使用 git 时与文件交互的方式。
当您打开 FileMaker 文件时，FileMaker 客户端直接与二进制文件本身交互。在文件处于活动状态时正在读取和写入数据和结构，因此如果您尝试在该过程中提交文件，您将面临损坏的风险。这种风险对于 Git 和 Subversion 都是一样的。
无论何时使用 FileMaker 文件和版本控制，您都需要确保在提交之前关闭文件。您不一定需要关闭 FileMaker 本身，但需要关闭文件。
此外，请确保文件确实已关闭。您可能认为该文件已关闭并打开了隐藏或屏幕外 window。转到 Window 菜单并确保在提交之前关闭所有 windows。
文件大小
您绝对可以对 FileMaker 文件使用 git，但是如果您要推送到 public 远程托管服务提供商，您将 运行 进入这些大小限制。也就是说，如果您有自己的本地 git 服务器，那么大小可能不是问题。
处理存储库大小的最佳方法是将克隆提交到您的存储库。如果您在 FileMaker Server 上工作，您可以使用启用克隆的备份计划来轻松地将它们吐出。这也解决了打开文件问题，因为您将提交克隆备份，而不是活动文件。
这可能会很痛苦，因为现在您的所有数据都不在文件中，并且 FileMaker 没有很好的内置自动化功能来将数据带回，但是您可以构建一个传输文件 运行s 从您填充的文件（在版本控制之外）导入您的克隆（在版本控制中）。我们几乎为我公司的每个项目都这样做。
归根结底，在版本控制中要跟踪的重要事项是结构，而不是数据本身。存储克隆应该减少文件大小，足以使版本控制系统可行。
您可以将 Filemaker 文件的克隆保存到 Git 存储库中。这将绕过 Git 对除超大数据库以外的所有数据库的限制，并避免将未关闭的文件写入存储库 ("corruption") 的问题。