使用Git对Microsoft Dynamics NAV进行版本控制？

Question

我是一名.NET开发人员，但在我们的组织中也有几名Microsoft Dynamics NAV开发人员。目前他们没有使用任何源代码控制工具。我对NAV知之甚少，但据我所知，您可以从NAV脚本中导出对象并重新导入。

既然如此，是否有人在NAV中使用Git？在使用过程中有遇到任何问题吗？我想知道这是否是一个好的解决方案，并且它是否比使用Git与.NET更加复杂（我发现使用Git与.NET相当容易）。

- Ryan Lundy

Answer 1

是的，我们很成功地将Git与Dynamics NAV一起使用！

不好的是，在Git有意义之前，所有对象都必须被导出为txt。希望微软能够创建一个更容易的方法来将对象导出为txt。我们正在使用这种模型。创建一个带有通用主分支和每个更改对象的分支的Git存储库。所有源文件都必须与分支顶部文件具有相同的名称，以使Git跟踪差异。以这种方式使用Git，我们从不将任何内容合并到主分支中。开始使用Git后，共享对象的工作变得更加容易，并且可以跟踪其他NSC对代码所做的更改。IT-Revision很高兴，因为所有代码都有很好的文档记录，回退的方式也更加简单。我完全支持在Dynamics NAV中使用Git。

石油能源行业Navision顾问

- Benjamin

---

只是想知道，你有没有成功找到一个工具，可以自动将 NAV IDE 中的内容导出/导入到本地 git 存储库中？我对此非常感兴趣 - 否则我很乐意开始尝试构建它（或其基本版本）。 - Charleh

Answer 2

我正在使用Dynamics NAV和Git，但并不是同时使用。让我解释一下原因。

Git本身很酷（与GitHub一起使用效果更好），但Windows版本很差，除非你不喜欢使用类Unix命令行，因为这是设置msysGit的推荐方式。在Windows上的GUI工具不好用，不幸的是。

对于我来说，让老板明白为什么使用分布式版本控制比通常的TFS更好是很困难的。对于以业务为导向的人来说，一个大型中央存储库更加安全（因为它是我自己支付的服务器，我控制访问权限）和更加健壮（我雇了一个系统管理员来运行维护程序）。

我决定不去反对这个意愿。我们使用分布式版本控制作为暂存区。所有不稳定的更改都存储在此区域内，我们在团队内进行测试。完成稳定后，对象合并到中央存储库中。每个人看起来都很开心。

关于Git：最近，由于以下原因，我转而使用另一种分布式版本控制——fossil：

• 它可以做到Git所能做的一切；
• 在Windows上，它看起来、感觉和操作都像本地应用程序；
• 它内置了Web界面，我可以轻松地将其运行为本地Windows服务；
• 它集成了问题跟踪，因此我不再需要第三方工具；
• 仓库是一个单一的文件，因此我可以随时携带它在U盘上。

关于我们的NAV解决方案。它有1000多个对象，大小超过20MB。

编辑：编码半年后的一些更新。

我们又回到了Git。因为它的自动合并功能真是太棒了。只为赢得赌局，我在4个小时内将一个解决方案（修改的标准对象和新对象）从NAV7CTP3移植到NAV7CTP5。而四名开发人员团队需要近三周的每天工作才能取得同样的结果。

Git确实有很大的优势。我相信其他分布式版本控制系统也可以达到同样的效果。

原因是：Git和其他分布式系统在提交时保存的信息比如TFS和SVN更多。在常规开发过程中，这并不是很重要，但当涉及合并时，Git中所有这些“冗余”信息都会产生巨大的影响。

在合并期间，Git找到了开始分支的公共修订版本，然后逐步应用来自两个分支的更改——以与开发人员更改代码的方式相同——到解决方案中的所有文件中。

如果相同行在两个分支中都被更改，则显示冲突。否则，它只是将文件保存到工作文件夹中，准备提交。

以下是一些统计数据：

• 在CTP3和CTP3代码库中处理的文件总数约为每个四千个;
• 合并的解决方案对象总数为1170;
• 冲突文件的总数为140;
• 成功自动合并的比率约为88% (1170 - 140) / 1170 * 100 = 88%;
• 大多数冲突是对象版本的更改 - 微不足道的;
• 大约有20个文件存在非微不足道的冲突;
• 所有合并的对象都进行了微不足道的查找和替换（以修复RunFormOnRec -> RunPageOnRec等）;
• 结果是一个基于CTP5的完全可导入的最新解决方案对象集;
• 导入后的编译错误数量约为50个;
• 这些错误中大多数与从CTP3到CTP5对标准对象的更改有关;
• 故障对象的比率约为4％（50/1170 * 100％= 4％）;

- shytikov

---

你有关于NAV5或NAV6和Git的任何经验吗？你使用什么样的接口？是手动将文件导出为文本，然后在git中进行版本控制吗？还是你有某种（半）自动化接口可以直接在Navision中执行版本控制？ - lanoxx

嗨@lanoxx，我正在使用裸命令行——它不会隐藏Git的功能。如果您对漂亮的Git UI感兴趣，可以尝试[SmartGit]（http://www.syntevo.com/smartgithg/index.html）——它似乎是市场上唯一一个功能齐全的GUI解决方案。但是我使用裸命令行——原因是速度和我的特殊[快捷方式]（https://github.com/shytikov/git-nav）——从git中拆分和组合NAV对象的命令。 - shytikov

我之所以问是因为在NAV5和NAV6中，对象以二进制数据的形式存储在数据库中，因此要对它们进行版本控制，必须将其显式导出为文本文件。在NAV7中是否仍然如此？每次进行更改时都必须导出对象吗？ - lanoxx

是的，我之前是手动将它们导出为 *.txt 文件。我知道有一些方法可以通过涉及 ROT（如果我没记错的话是运行时对象表）直接从 C/SIDE 导出它们，但需要进行额外的开发工作。 - shytikov

Answer 3

我们在使用git与Dynamics NAV时取得了巨大的成功。但我不得不说，这并不容易。Dynamics NAV（我们使用2013版本）并没有针对git或基于文件的开发进行优化。通常情况下，开发是直接在开发环境（经典客户端）中完成的，该环境将源代码直接保存到数据库中。

因此，为了支持git，我们构建了许多有用的PowerShell命令，帮助开发人员将NAV DB与本地git文件夹同步。例如，我们有一个命令，可以将所有带有修改标志的对象导出到本地git文件夹中，或者一个命令，可以在两个git提交之间导入所有对象。我们甚至使用它来自动更新我们的测试数据库，只需在开发机器上执行"git push"命令即可。

但这并不意味着：开发所有这些程序和构建脚本并不容易。

因此，我建议您三思而后行，考虑是否要在Dynamics NAV中使用git。该软件并不是为了与git配合工作而构建的，因此您将不得不做很多工作-问题是您的老板是否愿意给您时间来构建必要的工具以实现平稳工作。

请查看对象管理高级。那是我们以前使用的工具。我曾经看到过来自idyn（公司）的预览，他们用Visual Studio代替了经典的开发环境客户端！我们从对象管理高级切换到git作为主要开发工具，因为它不适合我们的业务案例。但我们仍然在使用它，例如使用位置功能非常好！（电影来自旧版NAV，抱歉）

- ice1e0

Answer 4

我已经长时间使用Git和Navision 2009（以及早期版本），这真的很值得。

由于没有本地Git支持，我将Navision代码导出到我们允许编程的ID号区域中，形成一个大型文本文件（选择.txt格式进行导出）。或者按日期对我更改的所有模块设置分隔符并导出它们。

我编写了一个Python脚本，将此文本文件拆分为每个对象（表单、表格、代码单元）的单独文件，就像您手动保存一样。它们保存在我受Git控制的网络文件夹下。

虽然需要几天时间才能完全使该过程正常运行，但现在整个过程每次更新只需要几分钟。唯一的缺点是Navision本身不会导出谁做了更改，因此Git将无法反映这一点。

仍然很好，我可以完全控制我们 Navision 源代码中发生的变化。此外，如果您正在一个文件不完整的 Navision 环境中工作，拥有完整的代码表单以供搜索是一个巨大的时间节省器。除了在代码库中搜索错误消息文本之外，另一个优点是您可以编写一个脚本，告诉您允许修改特定表格的代码。因此，如果您重构一个表格，您将立即知道需要检查哪些代码…

对于 Git 本身，我使用一些基本的命令行命令。要检查更改，我使用由当前 Git 版本本地支持的可视化 P4MERGE 工具。

- 576i