使用 Git 来版本 Microsoft Dynamics NAV？
我是一名 .NET 开发人员，但在我们的组织中也有一些 Microsoft Dynamics NAV 开发人员。目前他们没有使用任何源代码控制。我对 NAV 知之甚少，但据我了解，您可以从 NAV 中编写对象并从脚本中导入回来。
既然如此，有人将 Git 与 NAV 一起使用吗？你一路上遇到过任何陷阱吗？我想知道这是否是一个向他们建议的好解决方案，以及它的管理是否比使用 Git 和 .NET 更复杂（我发现这相当容易）。
I'm a .NET developer, but in our organization we also have a couple of Microsoft Dynamics NAV developers. Currently they're not using any source control. I know very little about NAV, but as I understand it, you can script out objects from NAV and import back in from the scripts.
That being the case, is anyone using Git with NAV? Have you run into any gotchas along the way? I'm wondering if this is a good solution to suggest to them, and whether it's any more complicated to manage than using Git with .NET (which I've found reasonably easy).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，我们将 Git 与 Dynamics NAV 结合使用并取得了巨大成功！
不好的是，所有对象都必须导出到 txt，Git 才赋予意义。我们希望 Microsoft 能够创建一种更简单的方法来将对象导出到 txt。我们正在使用这个模型。创建一个包含通用主控的 Git 存储库，并为我们更改的每个对象创建一个分支。所有源文件必须与分支顶部文件具有相同的名称，以使 Git 跟踪差异。以这种方式使用 Git，我们永远不会将任何内容合并到 master 中。开始使用 Git 后，处理共享对象并跟踪其他 NSC 对代码所做的操作变得更加容易。 IT-Revision 很高兴，因为所有代码都有详细的文档记录，并且任何回退的方法都容易得多。我完全赞同将 Git 与 Dynamics NAV 结合使用。
Navision 石油和天然气行业顾问能源行业
Yes we are using Git together with Dynamics NAV with great success!
The bad thing is that all objects must be exported to txt before Git gives meaning. Let's hope that Microsoft will create an easier approach to exporting objects to txt. We are using this model. Create a Git repository with a general master, and a branch for each object we change. All source files must have the same name as the branch top file to make Git track differences. Using Git in this way, we never merge anything into master. After starting using Git it's much easier to work on shared objects and track what other NSC's have done with the code. And IT-Revision is happy because all code is well documented and the way to any fallback is much easier. I'll give my full endorsement to use Git with Dynamics NAV.
Navision Consultant, in Oil & Energy Industry
我正在使用 Dynamics NAV 和 Git，但不同时使用。让我解释一下原因。
Git 本身很酷（有了 GitHub 它会变得更好），但 Windows 端口很差，除非你不这样做喜欢坚持使用类似 UNIX 的命令行，因为这是设置 msysGit 的推荐方法。不幸的是，Windows 上的 GUI 工具并不好用。
对我来说，很难让我的老板理解为什么使用分布式版本控制比通常的 TFS 更好。对于以业务为导向的人来说，一个大型中央存储库感觉更安全（因为这是我自己付费的服务器，我控制访问）并且更强大（我聘请了一名将运行维护程序的系统管理员）。
我决定不违背这个意愿。我们使用分布式版本控制作为暂存区。所有不稳定的更改都存储在该区域中，我们在团队内进行测试。完成稳定后，对象将合并到中央存储库中。每个人看起来都很高兴。
关于 Git：最近我切换到另一个分布式版本控制 - fossil 由于以下原因：
关于我们的 NAV 解决方案。它有超过 1000 个对象，大小超过 20 MB。
编辑：经过半年多的编码后进行了一些更新。
我们切换回 git。因为它的自动合并很棒。为了赢得赌注，我在 4 小时内将解决方案（修改的标准对象和新对象）从 NAV7CTP3 移动到 NAV7CTP5。而由四名开发人员组成的团队需要近三周的日常工作才能获得相同的结果。
Git 确实有所作为。我相信其他分布式版本控制系统也可能获得相同的结果。
原因是：Git 和其他分布式系统在提交期间比 TFS 和 SVN 保存了更多的信息。在常规开发过程中这并不那么重要，但在合并时，来自 Git 的所有这些“冗余”信息就会产生影响。
在合并过程中，Git 会找到启动分支的公共修订版，然后逐步将两个分支的更改应用到解决方案中的所有文件（与开发人员更改代码的方式相同）。
如果两个分支中的同一行都发生了更改，则会显示冲突。如果没有，它只是将文件保存到工作文件夹中以准备提交。
这里有一些统计数据：
I'm using Dynamics NAV and Git, however not at the same time. Let me explain why.
The Git itself is cool (with GitHub it gets even better), but the Windows port is poor, unless you don't like to stick to unix-like command line, since it's the recommended way to setup msysGit. The GUI tools on Windows are no good, unfortunately.
For me it was hard to make my boss understand, why using distributed version control is better than the usual TFS. For business-oriented guys one big central repository feels more secure (because it's my own server I pay for, I control access to) and more robust (I hired a system administrator who will run maintenance procedures).
I decided not to fight against this will. We're using distributed version control as a staging area. All unstable changes are stored in this area and we do testing within our team. After finishing stabilization, objects are merged into the central repository. Everybody looks happy.
Regarding Git: Recently I switched to another distributed version control — fossil due to following reasons:
Regarding our NAV solution. It's more than 1000 objects, size over 20 MB.
EDIT: Some updates after more than half year of coding.
We switched back to git. Since its automatic merge is AWESOME. Just to win the bet I've moved a solution (modified standard objects and new ones) from NAV7CTP3 to NAV7CTP5 in 4 hours. While a team of four developers achieved the same result needing almost three weeks of everyday work.
Git really makes a difference. I believe the same results are possible with other distributed version control systems.
The reason is: Git and other distributed systems save a lot more information during a commit than i.e. TFS and SVN. It is not so important during regular development, but when it comes to merging, all this 'redundant' information from Git makes the difference.
During the merge Git finds the common revision which started a branch and then applies changes from both branches step by step - in the same way as the developer changed the code - to all files in solution.
If the same line was changed in both branches it shows the conflict. If not it just saves the files into the working folder ready for commit.
Here some statistics:
我们将 git 与 Dynamics NAV 结合使用，取得了巨大成功。
但我不得不说，这并不容易。 Dynamics NAV（我们使用版本 2013）未针对 git 或基于文件的开发进行优化。开发通常直接在开发环境（经典客户端）中完成，将源代码直接保存到数据库中。
因此，我们为支持 git 所做的事情是：我们构建了许多有用的 PowerShell 命令，帮助开发人员将 NAV DB 与本地 git 文件夹同步。 Fe 我们有一个命令，可以将带有修改标志的所有对象导出到本地 git 文件夹中 - 或者一个命令，可以导入 git 提交之间的所有对象。我们甚至使用它在开发机器上通过 git Push 来自动更新我们的测试数据库。
但这就是说：开发所有这些过程和构建脚本并不容易。
因此，我建议您在决定将 git 与 Dynamics NAV 一起使用时三思而后行。该软件不是为与 git 一起使用而构建的，因此您必须做大量工作 - 问题是您的老板是否愿意给您时间来构建必要的工具以顺利工作。
另请参阅高级对象管理器。这是我们之前使用过的一个工具。我曾经看过 idyn （公司）的预览，他们用 Visual Studio 取代了经典的开发环境客户端！
我们从高级对象管理器转向 git 作为主要开发工具，因为它不适合我们的业务案例。但我们仍然将它用于 使用地点 功能，巫婆太棒了！ （电影来自旧的 NAV 版本，抱歉）
We are using git with Dynamics NAV with great success.
But I have to say, it was not easy. Dynamics NAV (we use version 2013) is not optimized for git or file-based development. The developing is usually done directly in the development environment (classic client) that saves the source code directly into the database.
So what we did to support git is: We build a lot of useful PowerShell commands that are helping developers to synchronize a NAV DB with a local git folder. F.e. we have a command that exports all objects with a modified flag into the local git folder - or a command that imports all objects between to git commits. We even use that to automatically update our test database with a
git pushon the development machine.But that's to saying: It wasn't easy to develop all these procedures and build scripts.
So I would recommend you to think twice about the decision of using git with Dynamics NAV. The software is not build to work with git, so you will have to do a lot of work - and the question is if your boss is willing to give you the time to build the necessary tools to work smoothly.
Take a look also at Object Manager Advanced. That is a tool that we used before. I saw once a preview from idyn (Company) where they replaced the classic development environment client with visual studio!
We switched from Object Manager Advanced to git as main development tool because it was not fitting for our business cases. But we are still using it f.e. for the Where Used function witch is great! (Movie is from an old NAV version, sorry)
我已经使用 Git 和 Navision 2009（及更早版本）很长时间了，它非常值得。
由于没有本机 Git 支持，我将 ID 号区域中的 Navision 代码导出，我们可以将其编程到一个大文本文件中。 （选择.txt格式导出）。或者对我按日期更改的所有模块设置分隔符并将其导出。
我编写了一个 Python 脚本，该脚本获取此文本文件并将其拆分为每个对象（表单、表、代码单元）的单个文件，就像您手动保存所有内容一样。它将它们保存到我在 Git 控制下的网络文件夹中。
虽然该过程需要几天时间才能完全运行，但现在整个过程每次更新只需要几分钟。这样做的唯一缺点是 Navision 本身不会导出谁做了更改，因此 Git 不会反映这一点。
不过，我可以完全控制 Navision 源代码中的更改，这真是太好了。此外，如果您在文档缺乏的 Navision 环境中工作，那么以表单形式提供可以搜索的完整代码可以节省大量时间。除了 grep 代码库来查找错误消息文本之外，另一个优点是您可以编写一个脚本，它会告诉您允许哪些代码修改特定的表。这样，如果您重构一个表，您将立即知道需要检查哪些代码...
对于 Git 本身，我使用一些基本的命令行命令。为了检查更改，我使用当前 Git 版本本身支持的可视化 P4MERGE 工具。
I've been using Git and and Navision 2009 (and older) for a long time and it's so worth it.
As there's no native Git support, I export Navision code in the ID Number area that we're allowed to program in into a big text file. (select .txt format for export). Or set a delimitation on all the modules I changed by date and export this.
I wrote a Python script that takes this text file and splits it into a single file per Object (Form, Table, Codeunit), just like if you would save everything manually. It saves them to a network folder I have under Git control.
While it took a few days to get the process working fully, now the whole process only takes a few minutes per update. The only disadvantage of this is that Navision itself doesn't export who did changes, so the Git will not reflect that.
Still it's great that I can control what has been changing in our Navision source code fully. Also, if you are working in a poorly documented Navision environment, having the complete code in a form, that you can search, is a huge timer saver. Apart from grepping the codebase to locate error message texts, another advantage is that you can then write a script, that will tell you what code is allowed to modify a specific table. So that if you refactor a table, you will instantly know what code needs checking...
For Git itself, I use a few basic command line commands. To examine changes, I use the visual P4MERGE tool that is natively supported by current Git version.