版本控制是软件开发必不可少的工具，它可以使用户可靠而干净地退回到X完全正确完成工作的最后一次，或者查看从那时到现在的变化-通常在试图找出原因时使用X不再完全正确。
但是，我所知的所有工具仅适用于纯文本文件。工具箱（标准工具箱，而不是10.1中引入的python工具箱）及其模型都是二进制的。有谁有可行的方法来进行版本控制？
注意：版本控制与backup不同。有任意数量的简单方法来创建文件的快照特定日期/时间- Windows备份，以前的版本中，xcopy /s d:\foobar\ x:\foobar_%date%，zip stuff_%date%.zip stuff\*，等等。
将git，化石，mercurial，subversion或...之类的工具应用于二进制文件比使用xcopy或zip更好，因为可以添加提交消息，“ Model foobar％date％现在将覆盖以前的版本仅在Baz不存在的情况下才会产生结果”，但与该工具集可应用于文本文件的结果相比仍然贫乏：例如，向我确切说明去年和今天之间的更改。
Answers:
每个主流版本控制软件，例如SVN的中央中央版本控制或Git，Mercurial，Bazaar等分布式解决方案，都可以存储二进制文件。它们在性能方面和占用空间方面都非常有效。
当然，检查文件的修订/版本之间的差异是不同的情况。当您想比较ArcGIS模型（实际上是二进制）时，您无能为力。我不知道用于模型的任何差异工具，我怀疑是否会有任何差异，因为大多数人不需要此特定功能。
当前，我有ArcCatalog的工作流程：打开工具箱>选择模型>编辑>文件>导出>到python，切换到SCM工具>刷新更改>提交更改（输入日志注释）。
它很麻烦，所以我没有做太多，因此失去了版本控制的许多好处。
如果表明此推文，则ModelBuilder较旧，笨拙，并且无法通过ArcGIS Pro进行任何重大更新。我从来就不是它的忠实粉丝（尽管不情愿还是使用它时，我有），所以你可能会认为这个答案的问题偏离主航道，并推荐看的替代品。
FME可以说是最明显的ModelBuilder替代品，因为它具有相似的流程图UI。一个相关的优势是它的文档为纯文本格式，因此它们可以进行区分（尽管通常您必须学会忽略很多无意义的自动生成的碎片）。但是，它是商业软件，因此某些产品的成本可能无法承受。
我不太熟悉的其他工具包括Orfeo工具箱，Whitebox地理空间分析工具和QGIS的图形建模器（基于SEXTANTE）。这些都是带有GUI的开源建模环境。
近年来，我在GIS和开放数据会议上观察到的一大推动力是朝着“可重复研究”的想法，即可以轻松与他人共享和复制的数据和过程。这通常意味着使用开放数据格式，开放源代码软件和共享存储库。Python和R为此非常受欢迎。
我认为今年早些时候Dharhas Pothina 在Python和GIS上的演讲对此提出了很好的论据。我非常坚决同意，过度依赖GUI会损害可重复性。使用代码，只要您熟悉该语言，就可以快速浏览它并弄清楚发生了什么，而使用GUI，则必须单击并滚动浏览很多不同的窗口，这些窗口通常相互嵌套在一起，以获取值和设置。
当然，这里需要权衡取舍，但是我认为，任何从事认真工作（科学研究，政策制定等）的人都应使用有助于再现性的工具。
抱歉，这不能直接回答您的问题（尽管我不相信有一个简单的答案）。
在ArcGIS 10.1 for Desktop中引入Python工具箱会使您使用了四年的声明全部失效：
工具箱及其模型都是二进制的。
标准工具箱是二进制文件，而Python工具箱（* .pyt）是文本文件。
因此，我认为如果源代码的版本控制胜过建立模型GUI的要求，则应考虑使用Python工具箱。
您从“ 为什么要通过Python脚本工具学习/使用Python工具箱”的答案中意识到这一点。但是我认为我应该在此处作为答案，以便将来使用本问答的读者不会忽略使用Python工具箱（以便轻松访问版本控制）而不是使用标准工具箱的选项。
从很多方面来说，我真的很高兴 ESRI在过渡到ArcGIS Pro时没有全面检查整个Geoprocessing Framework和Modelbuilder。有许多（研究）组织投入大量资金来构建庞大的自定义模型，如果ESRI的兼容性遭到破坏，无疑将需要进行彻底的改革。
与从Arc / Info AML宏的背景过渡到Python /地理处理一样，这无疑意味着巨大的影响和许多人无所适从。即使在首次发布ArcGIS的5到8年后，仍然有研究人员和政府组织偶尔在诸如此类的论坛上提到AML模型，由于时间，金钱或原因，他们尚未能够转换为Python。其他限制。这仅说明了这种过渡的潜在影响，这无疑将是巨大的。
我同意，如果您不太了解ModelBuilder，有时它可能会“笨拙”，但是自从我真正开始学习Python并开始了解Tool Validation编程以来，http：//resources.arcgis.com/en/help/main /10.2/index.html#//00150000000v000000），大部分“痛苦”已被释放。现在，我可以更好地了解工具验证可能引发的一些“隐秘”错误消息，并使您对模型的哪一部分损坏不知所措，现在，我可以通过编写适当的工具验证代码来更有效地修复它们或防止它们。当将非Python工具箱/模型与Python脚本“集成”时，这特别有价值。
尽管我仍然有一个愿望，那将使ModelBuilder的生活变得更加美好更简单的是，如果自动工具验证实际上突出显示了工具并自动打开了模型，从而导致与变量相关的警告或错误。或者，至少在无效模型上单击“确定”后弹出的错误和警告列表应包括确切的工具名称以及该工具所在的模型名称无效。如果您有许多嵌套模型，则查找导致特定验证错误的工具有时会很乏味，仅列出一列不包括工具或（子）模型名称而仅包含无效变量名称的错误。关于ESRI为什么不在清单中包含工具和模型名称的问题，我实际上是茫然无措的，这似乎很容易解决此问题。
同样，一种“搜索”功能可以方便地按模型中定义的名称查找工具。