Lookup Tables are covered by the Source Control hooks in the management portal so they will automatically be added to your uncommitted queue upon check-out so you can include it in a future ItemSet upload.  

See slides 12-14 of ftp://ftp.intersystems.com/isc/customers/ccrtraining/ICC530(Presentation)%20CCR%20Tier%201%20-%20Interoperability%20Components.pdf 

@Ron Sweeney  - this is really great, thank you!

My team at InterSystems is actually working on a project to move diff-based code changes between environments using GitLab.  My question for you is whether you have a suggestion for a strategy for only importing the changed files in the target environment?  As you know, applications can get large and complex and build-times can get pretty long.  If only a handful of files have changed, reimporting the entire application (or in the case of your example, 3 applications) would cause excess and unnecessary downtime for users.  What we have been doing with CCR around the world at HealthShare and TrakCare sites for over a decade is executing targeted imports which only reload changed code.  Is there a Git-based strategy that you can recommend for building out the foundation of doing something similar?   I.e. isolating the files impacted by the merge and only pulling those in?

Thanks for any thoughts on this.

(note: @Timothy Leavitt )

@Stephen Ali - thanks for asking the question (and welcome to the Developer Community!).

Typically detailed questions like this on TrakCare products are worked out directly with InterSystems Support.  Globally we have TrakCare product tuned to regional requirements so it's important to connect with you product specialists from your specific region.  

I suggest you go to https://www.intersystems.com/support-learning/support/ to see how to contact Support and they can help you get this question sorted out.

Just curious - where are you seeing this?  Could you please include a URL?

The InterSystems SSO account is what controls your access to open as well as restricted applications provided by InterSystems to help customers and prospects get stuff done.  If you go to Login.InterSystems.com you can see the various apps available to you (after you sign in).  This would include things like D.C., OEX, Learning, Download, etc for Prospects, and supported customers would also get access to WRC, iService, HS Docs, CCR, etc (depending on what products they have).

Hope that helps - let me know if any additional clarification is needed.

I completely agree with @Timothy Leavitt here.  Besides the speed of the DB, the core value of Caché (now IRIS) for the past 2 decades that I have used it has been the ability to create just about anything I needed within an application without needing to bolt on additional tools, additional layers, additional languages, or additional dependencies.  Directly access business logic on the server from the web page, directly instantiate and work against objects anywhere in your code - there is no 'throwing things over the wall' to the DB guy, or to the microservice guy, you just code what you need in ObjectScript and be done with it.  
To @Robert Cemper 's point below, I really don't think it takes an Artist to be able to write and support this kind of code, just a talented developer with some good OO skills.  I do think you need to be able to find Artists to support the legacy M applications which are still floating around, but it is pretty straight-forward to get the full power of the stack for new applications while avoiding modes of use which would require a "Priest" to be able to interpret it in the future.  
Having recently been involved in another initiative for several months that was not DB-centric development, and having witnessed how much harder it seemed to be and more time intensive to piece together the different disparate technologies at different levels of the stack in order to make a full solution, it reminded me of why I fell in love with Caché in the first place and made me excited to get back to full stack dev in on a single integrated platform :)