使用Git版本Microsoft Dynamics NAV？

Question

我是.NET开发人员，但在我们的组织中，我们还有几个Microsoft Dynamics NAV开发人员。目前他们没有使用任何源代码控制。我对NAV知之甚少，但据我了解，你可以编写NAV中的对象并从脚本中导入。

既然如此，是否有人使用Git与NAV？你有没遇到任何陷阱？我想知道这是否是一个很好的解决方案，建议他们，以及管理是否比使用Git with .NET（我发现相当容易）更复杂。

Answer 1

是的，我们将Git与Dynamics NAV一起使用取得了巨大的成功！

糟糕的是，在Git赋予意义之前，必须将所有对象导出到txt。让我们希望微软能够创建一种更简单的方法来将对象导出到txt。我们正在使用这个模型。使用通用主服务器创建Git存储库，并为我们更改的每个对象创建一个分支。所有源文件必须与分支顶级文件具有相同的名称，才能使Git跟踪差异。以这种方式使用Git，我们永远不会将任何东西合并到master中。在开始使用Git之后，更容易处理共享对象并跟踪其他NSC对代码所做的事情。 IT-Revision很高兴，因为所有代码都有详细记录，并且任何后备的方式都更容易。我完全赞同使用Git和Dynamics NAV。

Navision Consultant，in Oil＆amp;能源工业

Answer 2

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

Git本身很酷（GitHub它变得更好），但Windows端口很差，除非你不喜欢坚持使用类似unix的命令行，因为它是建议的设置方式msysGit。不幸的是，Windows上的GUI工具并不好。

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

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

关于Git：最近我切换到另一个分布式版本控件 - fossil，原因如下：

• 它可以做Git所能做的一切;
• 它在Windows上的外观，感觉和行为;
• 它有一个Web界面内置，我可以轻松地将其作为本机Windows服务运行;
• 它集成了问题跟踪功能，因此我不再需要第三方工具;
• 存储库是一个单独的文件，所以我可以随身携带笔在我想要的任何地方;

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

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

我们换回了git。由于其自动合并是非常好。为了赢得赌注，我已经在4小时内将解决方案（修改过的标准对象和新标准对象）从NAV7CTP3移动到NAV7CTP5。虽然由四名开发人员组成的团队取得了相同的结果，但需要将近三周的日常工作。

Git确实有所作为。我相信其他分布式版本控制系统也可以获得相同的结果。

原因是：Git和其他分布式系统在提交期间比TFS和SVN保存了更多信息。它在常规开发过程中并不那么重要，但在合并时，Git的所有这些“冗余”信息都会产生差异。

在合并期间，Git找到启动分支的通用修订版，然后逐步应用来自两个分支的更改 - 与开发人员更改代码的方式相同 - 应用于解决方案中的所有文件。

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

这里有一些统计数据：

• CTP3和CTP3代码库中处理的文件总数大约为四千个;
• 合并解决方案对象的总数为1170;
• 冲突文件总数为140;
• 成功自动合并的比率约为88％（1170 - 140）/ 1170 * 100 = 88％;
• 大多数冲突都是对象版本的变化 - 琐碎;
• 大约20个文件中的重要冲突;
• 对所有合并对象进行了简单的查找和替换（修复RunFormOnRec - ＆gt; RunPageOnRec等）;
• 结果是一组完全可导入的基于CTP5的最新解决方案对象;
• 导入后的编译错误数约为50;
• 这些错误大多与从CTP3到CTP5完成的标准对象的变化有关;
• 断层物的比率约为4％（50/1170 * 100％= 4％）;

Answer 3

我们正在使用动态资产净值的git取得巨大成功。

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

所以我们支持git的方法是：我们构建了许多有用的PowerShell命令，帮助开发人员将NAV DB与本地git文件夹同步。 F.E.我们有一个命令可以将带有修改标志的所有对象导出到本地git文件夹中 - 或者是一个导入git提交之间所有对象的命令。我们甚至使用它在开发机器上用git push自动更新我们的测试数据库。

但是要说：开发所有这些程序和构建脚本并不容易。

所以我建议你三思而后行使用git和Dynamics NAV的决定。该软件不能与git一起使用，所以你必须做很多工作 - 问题是你的老板是否愿意给你时间来建立必要的工具来顺利工作。

另见Object Manager Advanced。这是我们以前使用过的工具。我曾经看过 idyn （公司）的预览，他们用visual studio取代了经典的开发环境客户端！ 我们从Object Manager Advanced切换到git作为主要开发工具，因为它不适合我们的业务案例。但我们仍在使用它。对于Where Used函数，女巫很棒！ （电影来自旧的资产净值版本，对不起）

Answer 4

我使用Git和Navision 2009（及更早版本）已经很长时间了，它非常值得。

由于没有本机Git支持，因此我将ID区域中的Navision代码导出到允许我们编程的大文本文件中。 （选择.txt格式进行导出）。或在我按日期更改的所有模块上设置定界，然后导出。

我编写了一个 Python 脚本，该脚本将获取此文本文件并将其按对象（表单，表，代码单元）拆分为单个文件，就像您手动保存所有内容一样。它将它们保存到我在Git控制下的网络文件夹中。

虽然整个过程花了几天时间，但每次更新整个过程仅需几分钟。这样做的唯一缺点是Navision本身不会导出更改的对象，因此Git不会反映出来。

仍然很高兴，我可以完全控制Navision源代码中发生的变化。另外，如果您在Navision文档记录不佳的环境中工作，那么可以搜索的完整代码格式可以节省大量的计时器。除了grepping代码库以查找错误消息文本外，另一个优点是您可以编写一个脚本，该脚本将告诉您允许使用什么代码修改特定表。这样，如果您重构表，您将立即知道需要检查哪些代码...

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