For developers
Excel under source control, without the binary-blob problem
You can commit a workbook to Git today. What you can’t do out of the box is read the change. SheetDelta closes that gap: a real diff of formulas, values, structure, and VBA on every commit and pull request — so an .xlsx lives under the same review as your code.
Source control assumes text. Workbooks aren’t.
Everything that makes Git good — diffs, blame, review, merge — is built on lines of text. An .xlsx is a zip of XML, so to Git it’s one opaque blob. You can version it, but a one-cell change shows up as “binary files differ,” blame is useless, and a merge that touches the file will mangle it. The repo holds the workbook; it can’t tell you anything about the change.
The fix isn’t to abandon Git or to rebuild the model in code. It’s to keep committing the workbook and add a diff that understands it — so the parts of source control you actually rely on start working for spreadsheets too.
The workflow: commit, diff, review, gate
Four steps that fit the Git you already run — nothing exotic, no separate system for spreadsheets.
Commit the workbook as-is
No exporting to CSV, no rebuilding the model in code. The .xlsx goes into the repo like any other file. Mark it binary in .gitattributes so Git stops trying to line-merge it.
Get a readable diff on the change
Instead of “binary files differ,” you see which cells, formulas, sheets, and VBA modules changed between the two commits — the part Git can’t show on its own.
Review it on the pull request
A sticky PR comment lists each changed cell with before/after values and formulas, so a workbook change gets read and approved like a code change — by a person, on the PR.
Gate the merge if it matters
Turn on fail-on-change so a workbook can’t merge until a human has reviewed the diff. The control file stays under the same checks as the rest of the repo.
Tell Git how to treat the file
A few lines of .gitattributes keep Git from trying to line-merge a workbook,
route large files to Git LFS if you use it, and register the Excel diff so the change is
readable. This is the whole setup on the repo side:
# .gitattributes
# Store workbooks as binary and (optionally) hand them to Git LFS.
*.xlsx binary filter=lfs diff=sheetdelta
*.xlsm binary filter=lfs diff=sheetdelta
*.xlsb binary filter=lfs diff=sheetdelta
You don’t have to add the diff=sheetdelta line
by hand — sheetdelta git install writes it for
you. That, and the GitHub Action that posts the PR comment, are covered in the
Git diff for Excel walkthrough — this page is about the
workflow around them.
The realities to know going in
A few things that trip people up when they first put workbooks in a repo.
Git LFS is for size, not readability
LFS keeps big binaries from bloating your history, which is worth doing for workbooks. It does not make them diffable — an LFS-tracked .xlsx still shows up as an opaque blob. You need a real Excel diff on top either way.
No tool safely merges a binary workbook
A three-way merge of an .xlsx corrupts the file. If a vendor claims automatic Excel merge, open a PR and watch what happens. SheetDelta makes the change reviewable so a person decides — it never silently merges.
Unzipping to XML isn’t a diff
An .xlsx is zipped XML, so you can technically crack it open — but you’d be reading reordered shared strings and shuffled styles, not the numbers. The engine compares the workbook, not the bytes.
Runners don’t need Excel
SheetDelta reads .xlsx/.xlsm/.xlsb/.xls directly, with no Office dependency, so it runs on a plain Linux runner in any pipeline — GitHub, GitLab, Azure DevOps, Jenkins.
Not everyone editing the workbook lives in Git
The Git workflow is right for workbooks that developers own. For the finance and operations models nobody will ever push to a repo, the same engine runs on the hosted platform: it watches the SharePoint or OneDrive library those files already live in and produces the same cell-level diff, review comments, and sign-off there. Engineers review on the pull request; everyone else reviews in SharePoint — one source of truth for what changed.
Frequently asked questions
Can you actually put Excel under source control?
binary in .gitattributes so Git doesn’t try to line-merge it. The catch is that Git alone can’t show what changed inside the file. Pair it with an Excel-aware diff so each commit produces a readable change instead of “binary files differ.” The full code walkthrough is on Git diff for Excel. What about Git LFS — does that solve the diff problem?
Does SheetDelta merge workbooks or resolve conflicts?
Does it diff VBA and macros too?
Our finance team isn’t in Git. Can they get the same thing?
Keep reading
The CLI, the GitHub Action, and the PR comment, with code.
Module-level comparison of macro code across versions.
The hosted team review layer for non-developers.
Link a Git repo or watch SharePoint and OneDrive.
See macro and formula changes in macro-enabled workbooks.
Provable who-changed-what-when for critical models.
Bring spreadsheets under the same review as your code
Add the diff to one repo and watch the next workbook commit produce a change you can actually read.