23.5 Tracking Changes with Source Control

Use Git to preserve APEX export history, compare changes, and support team collaboration.

Even with multiple environments and good team practices, one question remains: how do you keep a history of changes? APEX doesn’t track version history. Once you update an app, the old version is gone unless you exported it. Relying on memory or notes is risky. That’s where source control comes in, and for most teams today, that means Git.

Git is a popular open-source version control system and the de facto standard for development teams worldwide. In simple terms, it manages a repository of your files, such as exported APEX applications and database scripts. This repository acts as a time machine for your project. Each time you make changes, you commit them with a message describing what changed. Git tracks who made each change, when it was made, what was added or removed, and why. Later, you can review the history to answer questions like: When was this bug introduced? Who wrote this code? What changed between versions 1.4 and 1.5?

A typical Git setup uses a remote repository on GitHub, GitLab, Bitbucket, or an internal server. Each team has at least one local copy of the "repo". To keep things simple, many teams nominate one teammate to handle Git on behalf of the group. That person periodically exports the latest version of the APEX app, then commits and pushes those files to the shared repository with a short, descriptive message such as "Week 34 fixes and improvements." Each commit acts as a checkpoint, and over time the repository builds a chronological record of versions. If a page worked two weeks ago but doesn’t now, you can compare exports in Git to see exactly what changed. That is an invaluable aid for debugging and auditing.

Tip:

Working copies hold in-progress changes that aren't yet ready to be part of the main application. A team using working copies typically only exports the main application to Git.

Getting started with Git doesn’t require deep expertise. Create a free private repository on GitHub or GitLab and use it as your central store. Begin with an initial export of your APEX app as the first commit, then make new commits at regular milestones: after key changes, before testing, or on a set schedule. Write short, meaningful messages that describe what changed; over time they tell the story of your project.

Using Git gives you more than backups: it lets you compare versions easily. Git’s diff tools show exactly which lines in APEX application artifact files changed between commits. If an unintended edit slips in, you’ll see it. When someone asks, “What changed in this release?” you can simply point them to the commit history instead of listing every change.

A major advantage of using Git is traceability: the who, what, when, and why behind every change. This information is gold for maintenance. Six months later, when you wonder “Why was this validation logic removed?”, you can check the commit history, see who made the change, and read the message explaining it. For example, it might reference a bug number or business rule update. Without source control, that knowledge is easily lost.

Using Git also opens the door to automation. You might integrate with continuous integration (CI) tools such as Jenkins or GitHub Actions to deploy the latest commit to a test environment and run checks automatically. Even without full CI, a lightweight approach works well: many teams script both directions: exporting from APEX to Git and importing from Git back into an environment for deployment. These scripts, often built with SQLcl and simple shell or batch commands, provide control and transparency without the complexity of larger frameworks. With just a few basic commands you can automate backup and versioning in a way that’s easy to maintain. APEX gives you the flexibility to adopt as much DevOps automation as suits your team’s workflow and pace.