Git integration & version control | ATX AnalyticsTable Handbook

Git integration & version controlThe project is already a folder of readable files. Git turns that into a history. Every other chapter describes something that ends up as a small JSON or SQL file in the project folder — a pipeline, a schedule, a filter, an export definition, a saved query. This chapter is about the consequence: because the project is text, version control is not an integration bolted onto the product, it is the product's natural storage picking up a history. A Git panel sits in the sidebar beside Tables and Queries, the repository root is the project folder itself, and the whole feature is optional — nothing is initialised behind your back. What it deliberately is not is a Git client. There is no per-file staging, no branch management and no merge tooling, because the people this panel is for want a dated, attributable history of a reporting project, not a place to resolve a rebase.

What it does

Initialise a repository on the project folder in one click, with the branch named main and a managed .gitignore written for you
A change list in plain language — new, edited, deleted, renamed, conflict — with the raw porcelain code kept in the tooltip for when you need it
Commit everything with a message, then push and pull against a configured remote
Provider settings for GitHub, GitLab and Bitbucket, with the API base URL, the repository reference and a token that is validated before you rely on it
A token stored in the encrypted vault and never written into a command line, a URL or a log file
Version history for the schedules file, with a coloured diff per revision and a restore that writes an earlier version back for you to review
Status refreshed on a timer, so the panel reflects what the folder actually looks like rather than what it looked like when you opened it

How it works

The repository root is the project folder — the .git directory sits beside queries/, GRID/, PIPELINES/, SCHEDULES/ and the project file itself. Git is pointed at that directory explicitly so it cannot wander up into an enclosing checkout.
Initialising writes a managed block into .gitignore covering the project database and its write-ahead and journal files. This is not housekeeping: the database is held open and exclusively locked while the application runs, so without those lines the very first commit fails with a permission error rather than merely bloating the repository.
The managed block only ever adds what is missing. Your own lines are never removed or reordered, and the block is healed on every commit so a project created before the feature existed picks it up.
Commit stages everything and commits it with your message. A file that another program is holding open returns a specific, actionable message naming the file rather than a generic failure, and a clean tree reports that nothing needed committing instead of erroring.
Push and pull use the stored token, injected as an HTTP authorisation header through Git's own configuration rather than embedded in the remote URL — a token in a URL ends up in the process table for every other program on the machine to read.
Missing prerequisites are explained rather than passed through: no remote yet, or nothing committed yet, each get a sentence saying what to do, in place of Git's own wording.
Restore is scoped to one file at a given revision and never rewrites history — it writes the old version back into the working tree so you can look at it and commit it if you want it.

Practices that keep it reliable

Initialise on day one, before the project is interesting; the audit value compounds and costs nothing to start
Commit after a change you would want to explain later — a new schedule, an edited export, a reworked query — rather than on a timer
Configure the remote and test the token in Settings before the first push, so a failing push is about the push
Leave the managed .gitignore block alone; it is the reason commits succeed on a machine with the project open

In a regulated environment

Git is invoked with arguments handed directly to the process, never pasted into a shell command line — a remote URL arriving over the local API cannot close the quoting and run something else.
Credentials never become command-line arguments and never reach a log. Authorisation headers and any user:password in a URL are rewritten before anything is written to the log file, which is kept for generations and would otherwise hold a personal access token in plaintext.
Commit hashes are validated against a strict pattern, paths containing .. are refused, and the commit log is parsed with record separators so a commit subject containing commas or newlines cannot corrupt it.
Git integration and history browsing are two separate licence components, so an installation can have commits without granting revision browsing. On an invalid licence every mutating Git operation is refused while reading status and history still works.
Because the whole project is text, the history answers the question an audit actually asks — who changed this report, when, and to what — from the customer's own repository rather than from a vendor's system.

Screens

The Git panel — the branch, what changed in plain language, a message box, and Push and Pull beneath it.
Settings, Git — provider, API base URL, repository and a token that lives in the vault and is tested before you trust it.
Version history for the schedules file — a commit list, a coloured diff, and a restore that never rewrites history.

ATX Institute — home

Products

Company

Resources

Guides

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.