[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fYQMese3TyLM0KoNWHvS6932l72_dM5c59g2HpYLmngU":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":25,"hasDownload":26,"fileName":27,"youtubeId":28,"domainCrumb":29,"clusterCrumb":32},"356","3D3EE259-33B5-B24F-8A7A-3E3046756E07","8F2761C8-348C-C649-BC16-18822CE2D198","C55A9339-9E81-E64E-845A-DC9342ED468A","article","how-to-introduce-version-control-into-a-low-code-project","How to introduce version control into a low-code project","A practical guide to adding version control to FileMaker and other low-code projects — without slowing your team down or breaking client trust.","Your developer just overwrote a working layout with a change nobody signed off on. Or worse: the version on the client's server has three fixes that never made it back into your master file, and now nobody knows which copy is \"real.\" If this sounds familiar, you're not dealing with a people problem — you're dealing with a missing process problem. Low-code platforms like FileMaker were built for speed, not for tracking who changed what and why, which means most teams only discover they need version control the day something breaks. This article walks through how to actually introduce it, step by step, without grinding development to a halt.\n\n## Why is version control so much harder in a low-code tool than in traditional code?\n\nIn a classic coding environment, your source is text files. Git can diff two versions line by line and merge changes automatically most of the time. In FileMaker, and in most low-code platforms, your \"source\" is a binary file (or a database schema plus scripts, layouts, and value lists bundled together). You can't meaningfully diff two `.fmp12` files with standard Git tooling — a single layout tweak can change bytes throughout the entire file.\n\nThat's the real reason so many low-code shops skip version control entirely: the standard tool for the job doesn't work out of the box. But that's not a reason to skip it — it's a reason to build a process suited to the platform.\n\n## What actually goes wrong without version control?\n\nA few scenarios we see constantly in FileMaker projects that never adopted any discipline:\n\n- Two developers each fix the same bug independently, in two different copies of the file. One fix gets deployed; the other is lost, and the bug resurfaces three months later.\n- A developer tests an experimental script change directly in the file a client is actively using, and a support call comes in mid-test.\n- Nobody can answer \"what did we deploy to this client in March?\" when a bug report references behavior that no longer matches the current build.\n- A junior developer needs to roll back a change from last week, but the only backup available is from six weeks ago.\n\nNone of these are rare edge cases — they are the default outcome of running any active low-code project without a defined process for change and release.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F217?w=700&f=webp\" alt=\"timeline showing multiple file versions merging into one release\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## What does version control actually mean for a tool like FileMaker?\n\nSince you can't rely purely on line-by-line diffing, version control in a low-code context means combining several practices:\n\n1. **A single source of truth.** One master copy of the solution lives in a defined location (a dev server, or a version-controlled repository of exported metadata), and nobody edits a random local copy \"just to test something.\"\n2. **Structured export of schema and scripts.** Tools like the FileMaker Data Migration Tool, or third-party utilities (BaseElements, ScriptMaster-based exporters, or FmBetterForms-style layout tooling), let you export scripts, layouts, and schema as readable text\u002FXML. That text can then live in an actual Git repository, giving you real diffs and history for the parts of the file that matter most.\n2. **Naming and numbering conventions.** Every build gets a version number (e.g. `v3.4.1`) baked into a system table or custom function, visible in the file itself, not just in a filename.\n4. **Change logs.** A simple table or document recording what changed, who changed it, and why — tied to the version number, not to memory.\n5. **Separate development, test, and production environments.** Changes move through a pipeline (dev → test → production) rather than being made live in the file a client uses daily.\n\n## How do you set this up step by step?\n\nHere's a realistic rollout plan for a team that currently has none of this in place.\n\n**Step 1: Freeze and label the current production file.**\nBefore anything else, take the file currently in production, make a clean backup, and label it `v1.0` (or whatever baseline number makes sense). This becomes your known-good reference point.\n\n**Step 2: Set up a real Git repository — even if FileMaker isn't \"in\" it directly.**\nCreate a repository for the project. Even if the binary `.fmp12` file itself can't be diffed usefully, you can still commit exported scripts, custom functions, and layout XML on every release. Some teams also commit the binary file itself purely as an artifact store (so you have every historical build available), while relying on the exported text for actual change tracking.\n\n**Step 3: Introduce a version number inside the solution.**\nAdd a custom function or a record in an admin table that stores the current version. Show it somewhere visible — a login screen, an about box — so anyone (including a client on a support call) can tell you exactly which build they're looking at.\n\n**Step 4: Separate your environments.**\nSet up at minimum a development copy and a production copy. Ideally add a test\u002Fstaging copy that mirrors production data structure without live client data. Changes are only ever made first in dev, verified in test, then deployed to production — never the reverse.\n\n**Step 5: Define a release checklist.**\nBefore any file goes to production, run through the same short list every time: schema changes documented, scripts tested against sample data, version number incremented, changelog entry written, backup of current production taken before deployment.\n\n**Step 6: Migrate data, don't just copy the file.**\nUse the Data Migration Tool (or equivalent) to move production data into the new schema version rather than manually copying and pasting — this preserves data integrity and avoids the classic \"we lost three records during the update\" incident.\n\n**Step 7: Automate what you can.**\nSome teams use tools like Klai or custom AI-assisted scripts inside FileMaker to help flag which scripts or layouts changed between exports, speeding up code review even without full diff tooling. This isn't a replacement for discipline, but it removes a lot of manual comparison work.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F218?w=700&f=webp\" alt=\"developer checklist gate between development test and production environments\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## What about client-facing solutions — do they need this too?\n\nYes, arguably more than internal tools. A client running your solution as their order system, inventory tracker, or CRM has a business depending on that file being stable. If you can't tell them exactly what version they're on, what changed since their last update, and how to roll back if something breaks, you're carrying risk you don't need to carry. A simple version log emailed with every release (\"v3.4.1 — fixed invoice rounding error, added new customer export field\") builds trust and gives you a paper trail if a dispute ever arises about what was delivered when.\n\n## What's the minimum viable version control setup if you're short on time?\n\nIf a full pipeline feels like too much to start with, begin with just these three things:\n\n- A version number visible inside the solution.\n- A dated backup taken before every single deployment, kept for at least the last 10 releases.\n- A one-line changelog entry per release, stored in a shared document or table.\n\nThis alone eliminates the worst failure mode — not knowing what's running where, and not being able to undo a bad change quickly.\n\n## FAQ\n\n**Can I use Git directly with FileMaker files?**\nNot meaningfully for the binary file itself. You can and should use Git for exported scripts, custom functions, and layout definitions in text\u002FXML form, and for any surrounding web app or API connector code.\n\n**Does this slow development down?**\nInitially, yes, slightly — a release checklist takes minutes. But it saves far more time than it costs the first time you need to roll back a bad deployment or explain to a client exactly what changed.\n\n**What's the biggest mistake teams make when starting this?**\nTrying to build a perfect, fully automated pipeline on day one. Start with the minimum viable setup above, then add structure as the project grows.\n\n**Does this matter for small, single-developer projects too?**\nYes — solo developers lose just as much time re-discovering what changed in a file six months ago as teams do. Version discipline pays off even without a second person involved.\n\n## Checklist: version control basics for any low-code project\n\n- [ ] One clearly defined production file, with no ad-hoc local copies in circulation\n- [ ] Version number visible inside the solution\n- [ ] Separate dev\u002Ftest\u002Fproduction environments\n- [ ] Exported scripts and layouts tracked in a real Git repository\n- [ ] Backup taken before every deployment\n- [ ] Changelog entry written for every release\n- [ ] Data migrated with a proper tool, not copy-paste\n\nGetting version control right is really one part of a bigger question: how do you make custom business software reliable and transferable over time, so it doesn't depend on one person's memory or one machine's hard drive? That's a theme we go into in more depth in our [guide on making custom business software reliable and transferable](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-make-custom-business-software-reliable-and-transferable).\n\nIf your FileMaker system, ERP, or connected set of business tools has grown past the point where \"just be careful\" is a workable strategy, it's worth mapping out a proper release process before the next incident forces the issue. Loggix builds and maintains custom FileMaker solutions, web applications, and API integrations with exactly this kind of structure in mind, and can help you design a version control and deployment pipeline — including AI-assisted tooling where it genuinely saves time — that fits the size and pace of your team.","\u003Cp>Your developer just overwrote a working layout with a change nobody signed off on. Or worse: the version on the client's server has three fixes that never made it back into your master file, and now nobody knows which copy is "real." If this sounds familiar, you're not dealing with a people problem — you're dealing with a missing process problem. Low-code platforms like FileMaker were built for speed, not for tracking who changed what and why, which means most teams only discover they need version control the day something breaks. This article walks through how to actually introduce it, step by step, without grinding development to a halt.\u003C\u002Fp>\n\u003Ch2>Why is version control so much harder in a low-code tool than in traditional code?\u003C\u002Fh2>\n\u003Cp>In a classic coding environment, your source is text files. Git can diff two versions line by line and merge changes automatically most of the time. In FileMaker, and in most low-code platforms, your "source" is a binary file (or a database schema plus scripts, layouts, and value lists bundled together). You can't meaningfully diff two \u003Ccode>.fmp12\u003C\u002Fcode> files with standard Git tooling — a single layout tweak can change bytes throughout the entire file.\u003C\u002Fp>\n\u003Cp>That's the real reason so many low-code shops skip version control entirely: the standard tool for the job doesn't work out of the box. But that's not a reason to skip it — it's a reason to build a process suited to the platform.\u003C\u002Fp>\n\u003Ch2>What actually goes wrong without version control?\u003C\u002Fh2>\n\u003Cp>A few scenarios we see constantly in FileMaker projects that never adopted any discipline:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Two developers each fix the same bug independently, in two different copies of the file. One fix gets deployed; the other is lost, and the bug resurfaces three months later.\u003C\u002Fli>\n\u003Cli>A developer tests an experimental script change directly in the file a client is actively using, and a support call comes in mid-test.\u003C\u002Fli>\n\u003Cli>Nobody can answer "what did we deploy to this client in March?" when a bug report references behavior that no longer matches the current build.\u003C\u002Fli>\n\u003Cli>A junior developer needs to roll back a change from last week, but the only backup available is from six weeks ago.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of these are rare edge cases — they are the default outcome of running any active low-code project without a defined process for change and release.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F217?w=700&f=webp\" alt=\"timeline showing multiple file versions merging into one release\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>What does version control actually mean for a tool like FileMaker?\u003C\u002Fh2>\n\u003Cp>Since you can't rely purely on line-by-line diffing, version control in a low-code context means combining several practices:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>A single source of truth.\u003C\u002Fstrong> One master copy of the solution lives in a defined location (a dev server, or a version-controlled repository of exported metadata), and nobody edits a random local copy "just to test something."\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Structured export of schema and scripts.\u003C\u002Fstrong> Tools like the FileMaker Data Migration Tool, or third-party utilities (BaseElements, ScriptMaster-based exporters, or FmBetterForms-style layout tooling), let you export scripts, layouts, and schema as readable text\u002FXML. That text can then live in an actual Git repository, giving you real diffs and history for the parts of the file that matter most.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Naming and numbering conventions.\u003C\u002Fstrong> Every build gets a version number (e.g. \u003Ccode>v3.4.1\u003C\u002Fcode>) baked into a system table or custom function, visible in the file itself, not just in a filename.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Change logs.\u003C\u002Fstrong> A simple table or document recording what changed, who changed it, and why — tied to the version number, not to memory.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Separate development, test, and production environments.\u003C\u002Fstrong> Changes move through a pipeline (dev → test → production) rather than being made live in the file a client uses daily.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>How do you set this up step by step?\u003C\u002Fh2>\n\u003Cp>Here's a realistic rollout plan for a team that currently has none of this in place.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 1: Freeze and label the current production file.\u003C\u002Fstrong>\nBefore anything else, take the file currently in production, make a clean backup, and label it \u003Ccode>v1.0\u003C\u002Fcode> (or whatever baseline number makes sense). This becomes your known-good reference point.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 2: Set up a real Git repository — even if FileMaker isn't "in" it directly.\u003C\u002Fstrong>\nCreate a repository for the project. Even if the binary \u003Ccode>.fmp12\u003C\u002Fcode> file itself can't be diffed usefully, you can still commit exported scripts, custom functions, and layout XML on every release. Some teams also commit the binary file itself purely as an artifact store (so you have every historical build available), while relying on the exported text for actual change tracking.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 3: Introduce a version number inside the solution.\u003C\u002Fstrong>\nAdd a custom function or a record in an admin table that stores the current version. Show it somewhere visible — a login screen, an about box — so anyone (including a client on a support call) can tell you exactly which build they're looking at.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 4: Separate your environments.\u003C\u002Fstrong>\nSet up at minimum a development copy and a production copy. Ideally add a test\u002Fstaging copy that mirrors production data structure without live client data. Changes are only ever made first in dev, verified in test, then deployed to production — never the reverse.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 5: Define a release checklist.\u003C\u002Fstrong>\nBefore any file goes to production, run through the same short list every time: schema changes documented, scripts tested against sample data, version number incremented, changelog entry written, backup of current production taken before deployment.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 6: Migrate data, don't just copy the file.\u003C\u002Fstrong>\nUse the Data Migration Tool (or equivalent) to move production data into the new schema version rather than manually copying and pasting — this preserves data integrity and avoids the classic "we lost three records during the update" incident.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 7: Automate what you can.\u003C\u002Fstrong>\nSome teams use tools like Klai or custom AI-assisted scripts inside FileMaker to help flag which scripts or layouts changed between exports, speeding up code review even without full diff tooling. This isn't a replacement for discipline, but it removes a lot of manual comparison work.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F218?w=700&f=webp\" alt=\"developer checklist gate between development test and production environments\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>What about client-facing solutions — do they need this too?\u003C\u002Fh2>\n\u003Cp>Yes, arguably more than internal tools. A client running your solution as their order system, inventory tracker, or CRM has a business depending on that file being stable. If you can't tell them exactly what version they're on, what changed since their last update, and how to roll back if something breaks, you're carrying risk you don't need to carry. A simple version log emailed with every release ("v3.4.1 — fixed invoice rounding error, added new customer export field") builds trust and gives you a paper trail if a dispute ever arises about what was delivered when.\u003C\u002Fp>\n\u003Ch2>What's the minimum viable version control setup if you're short on time?\u003C\u002Fh2>\n\u003Cp>If a full pipeline feels like too much to start with, begin with just these three things:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A version number visible inside the solution.\u003C\u002Fli>\n\u003Cli>A dated backup taken before every single deployment, kept for at least the last 10 releases.\u003C\u002Fli>\n\u003Cli>A one-line changelog entry per release, stored in a shared document or table.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This alone eliminates the worst failure mode — not knowing what's running where, and not being able to undo a bad change quickly.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Can I use Git directly with FileMaker files?\u003C\u002Fstrong>\nNot meaningfully for the binary file itself. You can and should use Git for exported scripts, custom functions, and layout definitions in text\u002FXML form, and for any surrounding web app or API connector code.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Does this slow development down?\u003C\u002Fstrong>\nInitially, yes, slightly — a release checklist takes minutes. But it saves far more time than it costs the first time you need to roll back a bad deployment or explain to a client exactly what changed.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What's the biggest mistake teams make when starting this?\u003C\u002Fstrong>\nTrying to build a perfect, fully automated pipeline on day one. Start with the minimum viable setup above, then add structure as the project grows.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Does this matter for small, single-developer projects too?\u003C\u002Fstrong>\nYes — solo developers lose just as much time re-discovering what changed in a file six months ago as teams do. Version discipline pays off even without a second person involved.\u003C\u002Fp>\n\u003Ch2>Checklist: version control basics for any low-code project\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> One clearly defined production file, with no ad-hoc local copies in circulation\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Version number visible inside the solution\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Separate dev\u002Ftest\u002Fproduction environments\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Exported scripts and layouts tracked in a real Git repository\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Backup taken before every deployment\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Changelog entry written for every release\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Data migrated with a proper tool, not copy-paste\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Getting version control right is really one part of a bigger question: how do you make custom business software reliable and transferable over time, so it doesn't depend on one person's memory or one machine's hard drive? That's a theme we go into in more depth in our \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-make-custom-business-software-reliable-and-transferable\">guide on making custom business software reliable and transferable\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>If your FileMaker system, ERP, or connected set of business tools has grown past the point where "just be careful" is a workable strategy, it's worth mapping out a proper release process before the next incident forces the issue. Loggix builds and maintains custom FileMaker solutions, web applications, and API integrations with exactly this kind of structure in mind, and can help you design a version control and deployment pipeline — including AI-assisted tooling where it genuinely saves time — that fits the size and pace of your team.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901676000,[19,20,21,22,23,24],"version control","low-code development","FileMaker development","software release management","change management","deployment pipeline","\u002Fapi\u002Fknowledge\u002Fimage\u002F356\u002F?v=9925e4e08e19",false,"",null,{"title":30,"slug":31},"Modern Software Development","modern-software-development",{"title":33,"slug":34},"How to make custom business software reliable and transferable","how-to-make-custom-business-software-reliable-and-transferable"]