Is Using GitHub to Version Control Your CADD Drawings a Good Idea?

Git’s greatest strength is also its greatest weakness for CADD and design professionals

If you’re a software developer/programmer, the open-source distributed version control system called Git can be a lifesaver. How many times have you worked on some code, made changes, then broken things, and couldn’t undo your mistake? That’s a nightmare for developers, especially if the code is in production.

Originally developed by Linus Torvalds (of Linux fame), it was designed by software developers for software developers. It can review the code changes line by line, and if you use GitHub or GitLab, you can easily see those changes, approve/discard them, and push them into production using a CI/CD system.

Many Cloud providers already provide this capability, and I’ve used GitHub with Hugo on AWS Amplify to create a CI/CD workflow. It works like a charm; I make changes in my local repository, commit them, create a pull request, and then approve them. AWS Amplify is notified that the repository has changed and that the Hugo-powered website has been rebuilt. It’s all very efficient and pleasant.

Since I use this nearly every day in my professional life at H2O, I started to wonder what else I can use Git and GitHub for. Over the holidays, I bumped into an old engineering colleague, and we went out to lunch. We talked about the latest flooding in New Jersey and a range of other civil engineering topics.

He mentioned that his office was moving even more towards digital. Granted, all the site design and surveying work was already digital, in CADD format using AutoCAD. Still, more and more the documents for septic designs and reports were either in PDF or Word Doc format, or being scanned in.

The problem he was having was how to version control everything. At first, a simple file renaming strategy worked, like below:

2023-06-01-filname1.docx OR 2023-06-01-filename1.dwg

After a while, he’d have all kinds of files with the same file extension and different dates cluttering up his server:

2023-06-01-filename1.dwg
2023-06-05-filename1.dwg
2023-06-06-filename1.dwg
2023-08-13-filename1.dwg

Was there a possible solution to handle all this? My first thoughts went straight to Git and GitHub.

Using modern and not-so-modern versioning tools

When one gets the final document or CADD file, it’s assumed that all the changes have been incorporated. The way we worked back in those days to make sure all the changes were incorporated was using a check set, a red pen, and yellow & blue highlighters.

A designer would print out a design plan for review and give it to the engineer to mark up. The engineer would review the planset and use a red pen to “markup” any changes, deletions, or additions. Once completed, this planset would be returned to the designer, who would implement the changes.

Once the changes were ready, the designer would print a revised planset and return it to the engineer along with the previously marked-up set. The engineer would use a yellow highlighter to cover their red markups to confirm that the changes were completed.

This process would repeat many times over the life of a project and consume a lot of paper. In today’s world, that much paper consumption should be an anathema, but it’s not, and it drives me crazy.

If the final check plan has been redlined, changed, and yellow-highlighted, it would go to the final quality control group. That group would review the redlines and the yellow-highlighted areas and verify that it was indeed complete. If it were completed, they would go over the yellow-highlighted areas with a blue highlighter. This would turn the marked-up area green, signifying that it was “good to go.”

While this method is a good process, it doesn’t address the digital aspect of all these files. For example, the designer probably has versions 1, 2, and 3 of CADD files or other binaries for each step of the review process. On top of that, their desk and the rest of the office become awash with paper.

So is Git the right solution here?

The answer is: maybe.

Maybe it’s just easier to use a red pen, highlighters, and a lot of printer paper?

Git and GitHub versioning control strategy

I’m willing to bet that any reader from the civil engineering industry has at least one “junk.dwg” file. I know I’ve had dozens in file directories locally and on the network. Every CADD manager at an established firm will use a method to keep their files organized. They would religiously back up the files on “tape,” and if a digital file got destroyed, they’d have to find it on the backup tape and restore it.

That process was cumbersome, but it worked.

I thought there had to be a better way, so I started looking online to see whether engineering companies were using a better version control system. It turns out that at least 9 years ago, the conversation about using Git for file versioning was underway.

While many of the commenters on Reddit liked the general idea of Git, they didn’t like that it couldn’t show differences between CADD file versions, much like it does for source code. That, of course, was and is a perceived weakness in using a software development tool for something other than its intended use.

However, I believe Git has value to offer. With proper commit messages and branches, you can control documents and CADD files as a whole. Yet this process is also its biggest weakness: it’s a very linear flow for version control of binary files, not code.

For example, you might have version 1 of a proposal that gets committed as a DOCX file, but then make updates to the original file under a different branch that’s named “new wage rates.”

Sounds great until you realize that the binary file you updated gets added to the commit history. If your binary was 1 GB in size, and you changed it and updated the repository, you have two 1 GB binaries: the original and the updated one. This can lead to large repositories, and you’ll need much more storage. Of course, GitHub now offers ample file storage (LFS), but is committing large binary blobs the right way to think about this problem?

I don’t think so.

So what’s the solution? I’m not sure there is a perfect one. Perhaps the answer is, “it depends.” Maybe it’s a hybrid approach?

Is a hybrid approach the right way?

Without adding another layer of process, a hybrid approach is tantalizing to think about. This approach would use a combination of cloud backups throughout the project and Git to archive the final version. For the most part, designers and developers work on multiple versions and iterations of their code or drawings. Why not create project working directories that automatically back up all your work during the day?

There are tons of free and paid services, like Dropbox and OneDrive, that let you back up in the background and can save your butt if something bad happens to your network or computer. Once the project is final and needs to be archived, you can push it to Git with all the binary blobs.

But that adds just another layer of process. What if we streamlined this even further and dropped Git altogether?

Dropping Git altogether for cloud backup

I started this article to determine whether GitHub is the right way to handle version control for CADD drawings and project-related files. Git works well for source code, but it was never designed for binary blobs like *.DWG files. You couldn’t see what was changed in the binary file, so what good is it?

In my search for a versioning tool, was I trying to cram a metaphorical square peg into a round hole? Was I adding another process layer that wasn’t needed at all? Was using cloud backups in near real-time a better option?

Yes. Yes to all those questions.

The answer is as simple as using a cloud backup storage system that syncs your project ct directory throughout the day as you work. Enforcing a naming (and/or date) convention for versioning control of binary objects will be highly effective and keep things organized. Then, deleting “junk.dwg” and other CADD drawing versions will need to be done annually to free up storage and keep things organized.

In summary, you could use GitHub and Git for your CADD files, but it adds another layer of complexity that can be easily handled with cloud backup and naming.

After all, why complicate things when you don’t need to?