Excel VBA, Reporting & Automation Blog

Once Excel solutions grow beyond a single developer and a single workbook, parallel work becomes unavoidable. Someone needs to fix a production bug while someone else is building a new feature. Another developer may be refactoring shared code while users are waiting on a small enhancement. Without a branching strategy, these streams of work collide, overwrite each other, and reintroduce old problems that were already solved.

Branching is how software teams solve this problem. VBA projects can — and should — do the same, even though the code ultimately lives inside Excel.

This post explains how to apply branching strategies to VBA codebases in a way that respects Excel’s constraints while still delivering the benefits of parallel development, safer releases, and calmer deployments.

Why Branching Matters More in Excel Than You Expect

Excel gives a false sense of simplicity. Because everything is contained in one file, it feels natural to treat that file as the unit of work. In reality, that file is just a container. The real work happens in the code.

Once multiple changes are happening at the same time, copying workbooks becomes actively dangerous. Fixes get lost, features leak into production early, and developers start hoarding “their” version of the file out of fear. Branching removes that fear by making parallel work explicit and controlled.

What a Branch Represents in a VBA Project

In a VBA-based workflow, branches do not represent different Excel files. They represent different versions of the exported source code. The workbook itself is never branched. It is rebuilt.

Each branch corresponds to a version of the src directory containing exported .bas, .cls, and .frm files. Switching branches means switching which version of the source code will be imported into a clean workbook during a build.

Once this is understood, branching becomes natural.

The Main Branch as the Source of Truth

Every VBA codebase needs a single branch that represents production-ready code. This is often called main or master. This branch must always be in a state that can be built and deployed safely. No experimental changes live here. No half-finished features. No “just testing something quickly.” If code is on the main branch, it is eligible for release. This rule is non-negotiable, and it dramatically reduces production risk.

Feature Branches for Isolated Development

When new functionality is introduced, it should happen on a feature branch. This branch is created from the current main branch and exists solely to support that one change.

While the feature is under development, it can be exported, rebuilt, tested, and refined without affecting anyone else. If the work is abandoned, the branch can be discarded without consequence. If it succeeds, it is merged back into main deliberately.

This isolation is especially valuable in VBA, where partially implemented features inside a workbook can confuse users or accidentally ship early.

Hotfix Branches for Production Issues

Production bugs demand speed, but speed without discipline causes regressions. A hotfix branch is created directly from the version of source code that produced the current production release. The fix is applied narrowly, tested, and merged back into main. A patch release is then built and deployed. Crucially, the fix should also be merged into any active feature branches where relevant. This prevents the same bug from reappearing weeks later when a feature branch is finally merged. This practice feels formal at first, but it pays for itself the first time a critical bug is fixed once instead of five times.

Release Branches for Stabilization

In larger Excel systems, there is often a gap between “feature complete” and “ready for users.” During this period, changes should be tightly controlled.

A release branch allows stabilization work to continue without blocking new feature development. Only fixes and refinements are allowed here. New features wait. Once the release is approved, it is built from the release branch, tagged, and deployed. The branch can then be retired.

This pattern is particularly effective when Excel tools are used by large audiences and require confidence before rollout.

Merging VBA Code Without Losing Your Sanity

Merging VBA code works surprisingly well when code is exported consistently. Standard modules and class modules merge cleanly as text. UserForms are noisier, but still manageable with discipline. The key is to avoid unnecessary churn. Reformatting code, renaming controls casually, or exporting forms unnecessarily creates merge noise that obscures real changes. Small, focused commits make merges predictable. Large, sweeping changes make them painful.

Preventing “Workbook Drift”

One of the hidden dangers in VBA projects is workbook drift. This happens when developers continue working in old workbooks that no longer reflect the current source. The solution is simple and strict. Developers do not edit code in arbitrary files. They rebuild their development workbook from the current branch before starting work. Every time. If a workbook cannot be rebuilt cleanly from source, it is not trusted.

Why Branching Changes Team Dynamics

Branching is not just a technical practice. It is a social one. Once developers know they can work independently without stepping on each other, collaboration improves. Code reviews become calmer. Releases become predictable. And production incidents become easier to diagnose because you can always answer the question, “Which branch did this come from?” Excel stops being fragile not because the code is perfect, but because the process is.

Branching as the Foundation for Scale

At this point in the series, Excel is behaving like a real software platform. You have builds, versions, and parallel streams of work. Branching is the mechanism that makes all of that sustainable over time. Without it, growth creates chaos. With it, growth becomes manageable.

Branching Strategies for VBA Codebases