KordGuide
Git for documents
Sooner or later every hardware team with a software neighbor asks the same question: our code has version control, diffs, and review - why is the document set still rev-suffixed filenames in SharePoint? The obvious move is to put the documents in Git. It is worth being precise about why that fails before choosing what to do instead.
Where plain Git stops
Git is magnificent at exactly one kind of content: line-oriented text. Engineering documents are almost never that.
- A .docx is a zip archive. So is .xlsx, .pptx, and .vsdx. Git's diff of two of them is the phrase "binary files differ", which is true and useless. The change you care about - a pressure rating, an acceptance criterion - is invisible.
- Merging is impossible. Two people edit the same workbook on two branches and Git can only offer you one file or the other. For documents, branching without merging is just divergence with extra steps.
- LFS stores, it does not show. Git LFS exists because CAD models and drawing sets bloat a repo. It fixes the storage cost and leaves the diff exactly as blind as before.
- The reviewers do not live in a terminal. The people who must approve a revised P&ID are process engineers, document controllers, and the customer. A workflow that starts with "clone the repo" has already lost them.
- Commit discipline is the real dependency. Git's history is only as good as the commits people make. Documents get saved, mailed, and copied - a system that needs everyone to commit deliberately, with messages, is a system that gets bypassed by Friday.
The mapping that does work
The reason the "git for documents" question keeps coming back is that the workflow underneath Git is exactly right - it is the mechanics that do not transfer. Every Git concept has a document-world counterpart:
| In Git | For documents |
|---|---|
| Commit | A revision, with an author and a reason - not Rev-C-final-2.docx |
| Branch | A fork of the folder for each customer or site deployment |
| Pull request | A review session on the changed files, with comments and verdicts |
| diff | A visual comparison per format: changed cells in a workbook, a redline through a spec, rendered pages of a drawing, a 3D view of a model |
| Tag / release | An issued revision, tied to the transmittal record |
When Git is the right answer anyway
Honestly: if your content is text and your team is technical, use Git. Docs-as-code in Markdown, requirements in plain text, configs in JSON or YAML, tabular data as CSV with daff or git-xl for the diffs - all of that belongs in a repo, and no document platform will beat it there. The line is binary formats and non-technical reviewers. Cross either one and the Git experience starts degrading; cross both and it is gone.
What Kord does about it
Kord is the mapping above, built: version control on engineering document sets, visual diffs per format (Excel cells, Word redlines, rendered PDF drawings, Visio diagrams, STEP models, DXF, images, and Rockwell PLC exports), review sessions with sign-off, and an audit trail tied to what was actually issued. Files stay where they live - SharePoint, Google Drive, Egnyte - and an AI pass flags when a value changed in one document but not in the datasheet that quotes it.
Try the diff half right now
The comparison engine runs free at work.withkord.com/diff - two files, no account, nothing stored. Format-by-format guides: Excel, Word, PDF, STEP, and seven more.
FAQ
The versions of this question we hear most, answered without the sales voice:
Is there a Git for Excel?
Not literally - Git stores an .xlsx fine but cannot diff or merge it, because the file is a zip of XML. For tabular data that can live as CSV in a repo, daff and git-xl get close. For workbooks that have to stay workbooks - BOMs, calc sheets - the practical answer is a system that renders cell-level diffs between revisions, which is what Kord does.
Can Git LFS diff a drawing or a CAD model?
No. LFS solves storage, not understanding: it keeps large binaries out of the repo's object store and hands you back the bytes on checkout. The diff is still 'binary files differ'. Storing revisions was never the hard part - seeing what changed between them is.
Is SharePoint version history enough?
It answers 'what did the file look like on Tuesday', which is genuinely useful. It does not answer 'what changed between Rev C and Rev D', who reviewed the change, or whether the datasheet next door still agrees with it. Versions without diffs or review are a backup, not version control.
Do engineers have to learn Git commands for Kord?
No. Kord borrows the workflow - revisions, forks, review before release - not the interface. Files come in from SharePoint, Drive, or Egnyte, and the review happens in a browser. Nobody rebases a P&ID.