Git for SAS Programmers

Picture a submission package that shipped six weeks ago, and a quality auditor points at one table asking which program version produced it and what changed since the previous run. The study folder answers with a pile of files: t_14_1_1.sas, t_14_1_1_final.sas, t_14_1_1_final_v2.sas, and t_14_1_1_final_v2_JC.sas. Nobody can honestly say which copy actually ran. The only truthful answer lives in a log file that nobody kept. That is the trap: filename versioning is what many clinical teams treat as an audit trail, and it is not one. So today we cover the minimum Git vocabulary, branch-per-output mapped to quality control, and how to keep data out of version control.

On this slide, we look at why piling up filename suffixes becomes a real liability. First, there is no diff: comparing _v1 to _v2 means opening both files and comparing by eye, so changes often ship unreviewed. Second, silent forking happens when two programmers fix two issues from the same base copy, both save final versions, and one overwrites the other or the files diverge. Third, provenance becomes hearsay, because no archived log reliably ties a file to the output it produced. Fourth, final always lies: every experienced programmer knows _final means final until Friday. The root cause is that the version suffix carries no enforced metadata; it is just a label typed by a tired human at 6 p.m., with no author, no timestamp, and no link to the output.

Imagine an auditor asks which program version produced a table. With filename versioning, the suffix is something a person remembers to type. It gives you no author, no timestamp, no link to the output it produced, and later edits stay silent. An audit trail has to be system-maintained, so it records the author, records the timestamp, links the output, and detects later edits. That is the difference: a version suffix has none of those four properties. Git answers those questions by construction — never by the filename. It tells you who changed what, when, and starting from what. So filename versioning fails as an audit trail. Next question: what is the minimum Git vocabulary a clinical programmer actually needs?

You already know these five habits: copying the study folder to your machine is clone — but now you also get the full change history. Saving a new version of the file is commit — a timestamped record with author, diff, and message. Working on a copy without breaking shared state is branch — an isolated line of work you can merge later. Emailing the folder for review is a pull request — a proposed merge where the diff is visible, commentable, and approvable. And asking who changed this line is review, git log, or git blame — the answer, for every line, permanently. That's the whole vocabulary, and it's deliberately small — enough for modern Statistical Computing Environment, or SCE, work.

This next piece is a hands-on exercise, so you'll do it on the website at jaimeyan.com/learn rather than in the video. In it you practise the five-word vocabulary by matching each shared-drive habit to the Git word that replaces it: copy folder to clone, save a new version to commit, work on a copy to branch, email folder for review to pull request, and ask who changed this line to review, git log, or git blame. Pause the video here and give it a try, because pairing each habit with its Git word is the fastest way to make the vocabulary stick.

This checkpoint is the audit-trail case, where you apply Git vocabulary to concrete version-control choices. Two programmers start from the same base file and both save final.sas, and the clearest failure mode is B: one save can overwrite or orphan the other programmer's changes, and the identically named files carry no system-maintained record of which version was used. For a descriptive suffix such as program_final_v2.sas, the correct choices are A, C, and D: the suffix is only a user-typed label, it does not show who changed the file or when or what content changed, and it does not link the file to a version-control event for comparison with the previous version. When a programmer must show that a program version was saved with its author, timestamp, change message, and diff, the single Git word is B, commit. A commit is the timestamped change record, while a clone copies a repository, a branch is a movable line of development, and a pull request, or PR, is a review-and-merge proposal built from commits.

Now let's walk the daily loop, one output at a time. You begin with one branch per deliverable: git switch -c tlf/t_14_1_1. Then edit programs/tlf/t_14_1_1.sas with $EDITOR, git add that same file, and commit with the message t_14_1_1 colon denominator to SAF, the safety analysis set, per spec v3. Push it with git push -u origin tlf/t_14_1_1, then open a pull request, a PR, with gh pr create or the Statistical Computing Environment, the SCE, interface. The header now carries no suffix, because history lives in Git, and change control is git log -- programs/tlf/t_14_1_1.sas, followed by %include setup.sas. The repository owns the version story, so the _final pile is gone, and every commit carries an author, a timestamp, a diff, and a message.

This one is a hands-on exercise you do on the website at jaimeyan.com/learn, where you click through the branch-per-output flow and watch where each piece of quality control (QC) evidence lands. It practices the skill of mapping the two halves of double programming onto Git roles and artifacts, so you can see the production programmer open a pull request (PR) and the independent QC programmer review that PR with the spec open. Try it right after the video, while the ideas are still fresh.

An approved pull request, or PR, is your quality control, or QC, record. The diff shows exactly what changed, the approval shows who reviewed it, and the timestamps show when. The PR description ties the work to a specific spec version, and the results recorded on the PR are your QC evidence. Compare that to a shared drive, where you get an email chain, a tracked-changes file, and hope. For reviewer independence, the PR approver must not be the branch author, exactly like double programming. And with branch-per-output, merge conflicts are rare because two people rarely edit the same deliverable at once.

In this scene, the rule is simple: data never enters Git. The repository boundary is source, not data, so commit code, specs, shells, and documentation. Never commit data, whether patient-level or derived, because datasets are large, access-controlled elsewhere, and Git copies quietly defeat that access model. The example study's .gitignore makes this mechanical with five lines: *.sas7bdat, *.xpt, *.csv, logs/, and output/. Data reaches your session through the Statistical Computing Environment (SCE) and its governed connections, and programs reference datasets by path or snapshot identifier. Run records tie each execution to the exact data snapshot it read, so access is scoped and logged instead of granted by drive letter.

This is the final checkpoint on working with Git in regulated good-practice environments (GxP). For the auditor asking which program version generated a shipped output, the definitive artifact is A, the commit hash that the run record stamps when the output was created. That hash identifies the exact program version used to produce the output, while a review event, a timestamp, or a branch name does not uniquely pin down the run. In a GxP environment, the controls that make Git history acceptable to auditors are A, protected branches that prevent direct pushes, B, recorded approvals on pull requests (PRs) before merge, and C, access controls that restrict who can rewrite history. Together these prevent casual or unauthorized changes to history, which is what makes a Git log trustworthy for an audit. In a regulated Statistical Computing Environment (SCE), datasets stay out of Git because they are often too large, are governed by separate access controls, and may require data-masking or security protections a code repository is not designed to handle, while the audit link is preserved through governed data connections so the dataset version is known via a snapshot or data-management record and the run record stamps the version used for the output.

Let's pull the lesson together, because the repository is the record and this pairs with the source article. Filename versioning is not an audit trail; there is no diff, no provenance, silent forking, and final is a label a tired human typed. Five Git words cover our clinical workflow: clone, commit, branch, pull request (PR), and review, mapped one-to-one from shared-drive habits. Branch per output, with the independent quality control (QC) programmer as the PR reviewer, turns double programming into an exportable record. Data never enters Git; the Statistical Computing Environment (SCE) connections carry it, and .gitignore makes that rule mechanical. Finally, the L3 agentic way is volatile, as of 2026-08-30: agents can draft the change, the commit message, and the PR description, but a human approves on QC evidence, not prose, so re-verify tool specifics before relying on them.