VBA and Git the Sequel: This Time it’s Integrated

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?

Uncommitted changes

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.

      <RemoteLocation />

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.

, , , , , ,

  1. #1 by Christopher J. McClellan on June 29, 2015 - 1:52 pm

    Reblogged this on Rubberduck News and commented:

    There’s some information about the new beta Source Control Integration feature over at my blog.


  2. #2 by rubberduckvba on June 29, 2015 - 1:57 pm

    Note that Rubberduck 1.4 Code Inspections will catch the “default project name” and a quickfix for that “issue” is a one-click refactor/rename of the project, so you can rename the project without breaking any code that’s referencing it by name.

    Liked by 1 person

  1. ShibbyGit! A Git Utility for VBA – optimalmadness

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: