I’ve talked before about using Git with VBA and also about the importance of using source control and other tools for our work. Truthfully though, using source control with VBA is still hard. This is mostly because getting the code modules into and out of the VB Project is hard, and harder to do right. Well, you may have heard that there’s a new duck in town. It’s taken me about 6 months of spare time, but Rubberduck v1.4 not only has a source control COM library that you can use right in VBA to work with Git VBA repositories, but you can also now branch, commit, pull, push, and merge right from inside of the editor.
First off, I want to stress that I consider this particular feature of Rubberduck to be a “beta” still. There are issues with it. The first one being there is the notable lack of the ability to directly clone a remote repository. So, for the foreseeable future at least, I highly recommend getting yourself a Git Windows client. I’ve used GitHub for Windows and SourceTree in the past. They’re both great tools and you’ll need one of them because Rubberduck doesn’t support more advanced operations like rewriting history with reset or rebase. More likely though, you’ll need one of these tools when you get yourself in a position where you have to resolve a merge conflict. Anyway, I’m sure you’d like to actually see this magical new tool window, right?
How cool is that? I’ll never forget how great that very first commit from this window felt. It does more than just commits though…
That’s right. We can create, merge, and delete branches too.
Last, but certainly not least, we can sync with a remote repository without ever leaving the IDE.
Now, there are some “gotchyas” with how this all works. As you probably know, the code module files are actually part of the host document. So, just how does this work? Git needs the files in the file system to store them in a repository! Yes, that’s absolutely 100% correct. Git does need the code files in the actual file system. So, what happens here when you click “Commit” is Rubberduck exports the code module into a pre-configured directory, and then performs the actual commit. Basically everything works this way. Rubberduck syncs the file system with the project and then performs whatever Git action we’re asking it to perform.
So, what’s the “gotchya” here? Well, it has to do with how I internally implemented the configuration. You see, RD needs to know what file system location to use for a given VBProject. Each repository gets an entry in an XML configuration file that maps it to this location. It looks something like this.
<Repositories> <Repository> <Name>SourceControlTest</Name> <LocalLocation>C:\Users\Christopher\Documents\SourceControlTest</LocalLocation> <RemoteLocation>https://github.com/ckuhn203/SourceControlTest.git</RemoteLocation> </Repository> <Repository> <Name>VBAProject</Name> <LocalLocation>C:\Users\Christopher\Documents\TestProject</LocalLocation> <RemoteLocation /> </Repository> </Repositories>
You see that “Name” field right there? That’s the name of the VBProject.
That’s the key field. When RD launches the source control integration window, it checks the configuration file for a matching repository. This means that in order to use this tool, all of your projects must have a unique name. Unspeakably bad things will happen if you put more than one project with identical names in there. Considering that every new VBProject has a default name of “VBAProject”, this is definitely an issue, but it was the best I could do at the moment. I’ll definitely be looking for a better way to do this in the future. If anyone has a better idea of how to key each project to a file system directory, please reach out to me. In the meantime, be wary of using the default project name.
Anyway, I suppose there’s not really all that much to say about this. It’s rough around the edges, but definitely workable at this point, so enjoy the new feature. I’ll be working on improving it as I have time, so please feel free to submit any issues or feature requests you have over at our GitHub repository.