Let's lay this out what's going on. Models/source code are just "files". Files are loaded by applications. If an application has the files loaded and you change/add anything outside the application, that application has to be restarted, or somehow triggered to "refresh".
So, Visual Studio has a "Refresh Models" option because it loads files on startup, and if you change anything outside of VS then you need to tell VS to reload everything (or you can restart VS).
Then there's the added complication of binaries (DLLs) which are loaded and locked in memory when they're being "run". For example, batch and AOS server load X++ binaries to run - and those files are locked as long as batch and AOS are running.
In your case, you are likely reaching the AOS to trigger the data import. So first, before you compile do you shut down batch and AOS? Because those would lock any files you're trying to recompile (i.e. your compile doesn't result in anything because it can't overwrite the DLLs). And then of course, you would need to startup the AOS again to reach the URL to trigger the import.
I like the idea of automating. However, from a source control perspective what you're doing is far from ideal as your source control can't keep track of what version of the files you actually have on your box. Instead of importing models, consider doing "Get latest" from command line instead -so that Visual Studio KNOWS what version of the code you put on the box.