[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3jVSLdQkp56uh70mt21s3rFWOEuFvGllGMDiDkPZGGw":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":7,"kindOverride":8,"slug":9,"title":10,"description":11,"bodyMarkdown":12,"bodyHtml":13,"author":14,"date":15,"createdAt":16,"topics":17,"image":25,"hasDownload":26,"fileName":7,"youtubeId":27},"470","7EDF095E-CE89-4E4A-88D4-A2DFB7EF65EF","","article","can-you-finally-use-real-version-control-with-a-filemaker-system","Can you finally use real version control with a FileMaker system?","FileMaker 2026's XML export opens the door to Git-based version control, code review, and CI\u002FCD for custom FileMaker solutions. Here's how it actually works.","If you've ever managed a FileMaker solution with more than one developer, you know the pain. Two developers open the same file, both change the same script, and one of them loses their changes when the file gets saved back. There's no diff, no blame, no pull request — just a binary file that either has your change in it or doesn't. Compare that to a web developer who can open a pull request, see exactly which 4 lines changed in a JavaScript function, get a colleague to review it, and have automated tests run before it merges. FileMaker teams have mostly had to live without any of that.\n\nFileMaker 2026 changes the practical reality here by making it much easier to work with a solution's structure and scripts as plain XML outside of FileMaker itself. That sounds like a small, technical detail. In practice, it's the missing piece that lets FileMaker teams finally plug into the same version control, code review, and CI\u002FCD workflows that every other software team takes for granted.\n\n## Why has version control always been hard in FileMaker?\n\nA FileMaker file (.fmp12) is a binary container. It holds your data, your schema, your layouts, your scripts, and your value lists all in one file. That's great for deployment simplicity — one file, one thing to back up — but it's terrible for tracking changes over time.\n\nGit, Subversion, and every other version control system are built around comparing text files line by line. They can tell you \"this function changed from returning X to returning Y.\" They can't meaningfully diff two binary .fmp12 files. So FileMaker teams historically had two bad options:\n\n- **No real version control** — just naming files `Solution_v12_FINAL_reallyfinal.fmp12` and hoping nobody overwrites the wrong one.\n- **Third-party tools** (like the Data Migration Tool combined with manual change logs, or products like Git-integrations from the FileMaker community) that approximate diffing by exporting scripts as text, but with real friction and partial coverage — layouts and schema were often out of reach.\n\nEither way, code review — a second developer actually reading a proposed change before it goes live — was rare. Most bugs got caught in QA testing (if you were lucky) or by a client reporting something broken in production (if you weren't).\n\n## What does FileMaker 2026 actually change?\n\nFileMaker 2026 makes it substantially easier to export a solution's structure — scripts, layout objects, and related metadata — as XML files that live outside the .fmp12 container. Instead of one opaque binary blob, you get a folder of readable, structured text files that map to the actual objects in your solution.\n\nThat single shift unlocks three things developers building on other platforms have had for years:\n\n1. **Real diffs.** You can see that a script's `If` condition changed from checking `Status = \"Open\"` to `Status ≠ \"Closed\"` — not just that \"the file changed.\"\n2. **Real code review.** A pull request can show exactly what a developer changed, and a reviewer can approve or request changes before it merges into the shared solution.\n3. **Real automation.** Because the XML is just text, it can be checked into Git, scanned by scripts, and used as an input for automated build or test pipelines — the building blocks of CI\u002FCD.\n\n## How would this actually work in a Git workflow?\n\nHere's a realistic pattern a FileMaker team could set up:\n\n1. **Export.** After making changes in FileMaker, a developer exports the affected scripts\u002Flayouts as XML into a designated folder in the project repository.\n2. **Commit.** That XML gets committed to Git with a meaningful message — \"Fix invoice rounding logic in CalculateTotal script\" — just like any other code change.\n3. **Pull request.** The developer opens a pull request. A teammate reviews the actual diff of the XML, spots that a rounding function was changed from `Round` to `Truncate`, and asks about it before approving.\n4. **Merge and re-import.** Once approved, the change is merged into the main branch, and the XML is re-imported (or the underlying `.fmp12` update applied) into the shared development file.\n5. **Automated checks.** A CI pipeline can run lightweight validation on every pull request — checking for naming convention violations, orphaned scripts, or missing comments — before a human reviewer even looks at it.\n\nThat's a genuinely different way of working than \"whoever has the file open right now wins.\"\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F325?w=700&f=webp\" alt=\"FileMaker file splitting into readable XML script and layout files feeding into a Git repository\" 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## Does this mean FileMaker development becomes exactly like web development?\n\nNot entirely, and it's worth being honest about the limits.\n\n- **Data still isn't versioned this way.** This is about structure — scripts, layouts, schema — not your records. Your data still lives in the .fmp12 file (or your separated data source) and needs its own backup and migration discipline.\n- **Merging isn't always trivial.** Two developers editing the same script in parallel still requires care. XML makes conflicts *visible* — it doesn't make them disappear. You still need clear team conventions about who owns which module or script group during active development.\n- **You still need a FileMaker-aware pipeline.** A generic CI runner doesn't know how to \"build\" a FileMaker solution the way it knows how to compile Java. Teams adopting this will need custom tooling — scripts that know how to import\u002Fexport XML consistently — which is exactly the kind of integration work a FileMaker development partner would typically set up once, rather than something every client re-invents.\n\n## What should you actually do about this if you run a FileMaker system today?\n\nYou don't need to overhaul your workflow the day this ships. But it's worth planning for, especially if:\n\n- More than one developer actively works in the same solution.\n- You've had incidents where a change broke something in production and nobody could say exactly what changed or why.\n- You're preparing to bring in outside developers or an agency and want a safer way to review their changes before deployment.\n- You're already using Git for other parts of your stack (a companion web app, an API layer, scripts) and want your FileMaker layer to fit into the same discipline.\n\n**A short checklist to get ready:**\n\n- [ ] Confirm which FileMaker version your team is running, and whether an upgrade path to 2026 is realistic this year.\n- [ ] Identify your highest-risk scripts — the ones that touch invoicing, payroll, or customer data — as the first candidates for structured version control.\n- [ ] Set up a Git repository (even a simple private one) specifically for exported XML, separate from your data file backups.\n- [ ] Agree as a team on a lightweight pull-request habit: no direct changes to shared scripts without a second set of eyes.\n- [ ] Talk to your FileMaker developer or partner about building the export\u002Fimport tooling that ties this together — this is the part that takes real setup, not just enabling a feature.\n\n## FAQ\n\n**Does this replace regular backups of my FileMaker file?**\nNo. XML export\u002Fversion control covers structure — scripts, layouts, schema — not your live data. You still need your normal backup and disaster recovery plan for the .fmp12 file or your data source.\n\n**Can I use GitHub or GitLab directly?**\nYes — once your solution's structure is exported as XML, it's just text files like any other codebase, so standard Git hosting works fine.\n\n**Do I need to rebuild my whole solution to take advantage of this?**\nNo. You can adopt it incrementally, starting with the scripts or modules most prone to conflicts or bugs, and expand from there.\n\n**Is this only useful for large teams?**\nIt helps most where multiple people touch the same solution, but even a solo developer benefits from having a real change history and the ability to roll back a specific script change instead of an entire file version.\n\n## Where does this leave you?\n\nReal version control has been one of the quiet, longstanding gaps in FileMaker development compared to other platforms — not because FileMaker developers didn't care, but because the tooling genuinely wasn't there. FileMaker 2026's XML-based structure export closes a meaningful part of that gap, but turning it into a working CI\u002FCD pipeline still takes deliberate setup: repository structure, export\u002Fimport tooling, and team conventions that fit how your business actually ships changes.\n\nIf you're running a custom FileMaker solution and recognize the \"which version is the real one\" problem, this is a good moment to sit down with a development partner and map out what a Git-based workflow would look like for your specific system — whether that means tightening up an existing FileMaker solution, connecting it to other tools through APIs, or building the supporting scripts that make version control and code review a daily habit instead of a nice idea. Loggix works with FileMaker systems, custom web applications, and the integrations between them, and can help you figure out where structured version control would actually pay off first.","\u003Cp>If you've ever managed a FileMaker solution with more than one developer, you know the pain. Two developers open the same file, both change the same script, and one of them loses their changes when the file gets saved back. There's no diff, no blame, no pull request — just a binary file that either has your change in it or doesn't. Compare that to a web developer who can open a pull request, see exactly which 4 lines changed in a JavaScript function, get a colleague to review it, and have automated tests run before it merges. FileMaker teams have mostly had to live without any of that.\u003C\u002Fp>\n\u003Cp>FileMaker 2026 changes the practical reality here by making it much easier to work with a solution's structure and scripts as plain XML outside of FileMaker itself. That sounds like a small, technical detail. In practice, it's the missing piece that lets FileMaker teams finally plug into the same version control, code review, and CI\u002FCD workflows that every other software team takes for granted.\u003C\u002Fp>\n\u003Ch2>Why has version control always been hard in FileMaker?\u003C\u002Fh2>\n\u003Cp>A FileMaker file (.fmp12) is a binary container. It holds your data, your schema, your layouts, your scripts, and your value lists all in one file. That's great for deployment simplicity — one file, one thing to back up — but it's terrible for tracking changes over time.\u003C\u002Fp>\n\u003Cp>Git, Subversion, and every other version control system are built around comparing text files line by line. They can tell you "this function changed from returning X to returning Y." They can't meaningfully diff two binary .fmp12 files. So FileMaker teams historically had two bad options:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>No real version control\u003C\u002Fstrong> — just naming files \u003Ccode>Solution_v12_FINAL_reallyfinal.fmp12\u003C\u002Fcode> and hoping nobody overwrites the wrong one.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Third-party tools\u003C\u002Fstrong> (like the Data Migration Tool combined with manual change logs, or products like Git-integrations from the FileMaker community) that approximate diffing by exporting scripts as text, but with real friction and partial coverage — layouts and schema were often out of reach.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Either way, code review — a second developer actually reading a proposed change before it goes live — was rare. Most bugs got caught in QA testing (if you were lucky) or by a client reporting something broken in production (if you weren't).\u003C\u002Fp>\n\u003Ch2>What does FileMaker 2026 actually change?\u003C\u002Fh2>\n\u003Cp>FileMaker 2026 makes it substantially easier to export a solution's structure — scripts, layout objects, and related metadata — as XML files that live outside the .fmp12 container. Instead of one opaque binary blob, you get a folder of readable, structured text files that map to the actual objects in your solution.\u003C\u002Fp>\n\u003Cp>That single shift unlocks three things developers building on other platforms have had for years:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Real diffs.\u003C\u002Fstrong> You can see that a script's \u003Ccode>If\u003C\u002Fcode> condition changed from checking \u003Ccode>Status = "Open"\u003C\u002Fcode> to \u003Ccode>Status ≠ "Closed"\u003C\u002Fcode> — not just that "the file changed."\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Real code review.\u003C\u002Fstrong> A pull request can show exactly what a developer changed, and a reviewer can approve or request changes before it merges into the shared solution.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Real automation.\u003C\u002Fstrong> Because the XML is just text, it can be checked into Git, scanned by scripts, and used as an input for automated build or test pipelines — the building blocks of CI\u002FCD.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>How would this actually work in a Git workflow?\u003C\u002Fh2>\n\u003Cp>Here's a realistic pattern a FileMaker team could set up:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Export.\u003C\u002Fstrong> After making changes in FileMaker, a developer exports the affected scripts\u002Flayouts as XML into a designated folder in the project repository.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Commit.\u003C\u002Fstrong> That XML gets committed to Git with a meaningful message — "Fix invoice rounding logic in CalculateTotal script" — just like any other code change.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Pull request.\u003C\u002Fstrong> The developer opens a pull request. A teammate reviews the actual diff of the XML, spots that a rounding function was changed from \u003Ccode>Round\u003C\u002Fcode> to \u003Ccode>Truncate\u003C\u002Fcode>, and asks about it before approving.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Merge and re-import.\u003C\u002Fstrong> Once approved, the change is merged into the main branch, and the XML is re-imported (or the underlying \u003Ccode>.fmp12\u003C\u002Fcode> update applied) into the shared development file.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Automated checks.\u003C\u002Fstrong> A CI pipeline can run lightweight validation on every pull request — checking for naming convention violations, orphaned scripts, or missing comments — before a human reviewer even looks at it.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>That's a genuinely different way of working than "whoever has the file open right now wins."\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F325?w=700&f=webp\" alt=\"FileMaker file splitting into readable XML script and layout files feeding into a Git repository\" 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>Does this mean FileMaker development becomes exactly like web development?\u003C\u002Fh2>\n\u003Cp>Not entirely, and it's worth being honest about the limits.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Data still isn't versioned this way.\u003C\u002Fstrong> This is about structure — scripts, layouts, schema — not your records. Your data still lives in the .fmp12 file (or your separated data source) and needs its own backup and migration discipline.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Merging isn't always trivial.\u003C\u002Fstrong> Two developers editing the same script in parallel still requires care. XML makes conflicts \u003Cem>visible\u003C\u002Fem> — it doesn't make them disappear. You still need clear team conventions about who owns which module or script group during active development.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>You still need a FileMaker-aware pipeline.\u003C\u002Fstrong> A generic CI runner doesn't know how to "build" a FileMaker solution the way it knows how to compile Java. Teams adopting this will need custom tooling — scripts that know how to import\u002Fexport XML consistently — which is exactly the kind of integration work a FileMaker development partner would typically set up once, rather than something every client re-invents.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>What should you actually do about this if you run a FileMaker system today?\u003C\u002Fh2>\n\u003Cp>You don't need to overhaul your workflow the day this ships. But it's worth planning for, especially if:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>More than one developer actively works in the same solution.\u003C\u002Fli>\n\u003Cli>You've had incidents where a change broke something in production and nobody could say exactly what changed or why.\u003C\u002Fli>\n\u003Cli>You're preparing to bring in outside developers or an agency and want a safer way to review their changes before deployment.\u003C\u002Fli>\n\u003Cli>You're already using Git for other parts of your stack (a companion web app, an API layer, scripts) and want your FileMaker layer to fit into the same discipline.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>A short checklist to get ready:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Confirm which FileMaker version your team is running, and whether an upgrade path to 2026 is realistic this year.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Identify your highest-risk scripts — the ones that touch invoicing, payroll, or customer data — as the first candidates for structured version control.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Set up a Git repository (even a simple private one) specifically for exported XML, separate from your data file backups.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Agree as a team on a lightweight pull-request habit: no direct changes to shared scripts without a second set of eyes.\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Talk to your FileMaker developer or partner about building the export\u002Fimport tooling that ties this together — this is the part that takes real setup, not just enabling a feature.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does this replace regular backups of my FileMaker file?\u003C\u002Fstrong>\nNo. XML export\u002Fversion control covers structure — scripts, layouts, schema — not your live data. You still need your normal backup and disaster recovery plan for the .fmp12 file or your data source.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can I use GitHub or GitLab directly?\u003C\u002Fstrong>\nYes — once your solution's structure is exported as XML, it's just text files like any other codebase, so standard Git hosting works fine.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Do I need to rebuild my whole solution to take advantage of this?\u003C\u002Fstrong>\nNo. You can adopt it incrementally, starting with the scripts or modules most prone to conflicts or bugs, and expand from there.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is this only useful for large teams?\u003C\u002Fstrong>\nIt helps most where multiple people touch the same solution, but even a solo developer benefits from having a real change history and the ability to roll back a specific script change instead of an entire file version.\u003C\u002Fp>\n\u003Ch2>Where does this leave you?\u003C\u002Fh2>\n\u003Cp>Real version control has been one of the quiet, longstanding gaps in FileMaker development compared to other platforms — not because FileMaker developers didn't care, but because the tooling genuinely wasn't there. FileMaker 2026's XML-based structure export closes a meaningful part of that gap, but turning it into a working CI\u002FCD pipeline still takes deliberate setup: repository structure, export\u002Fimport tooling, and team conventions that fit how your business actually ships changes.\u003C\u002Fp>\n\u003Cp>If you're running a custom FileMaker solution and recognize the "which version is the real one" problem, this is a good moment to sit down with a development partner and map out what a Git-based workflow would look like for your specific system — whether that means tightening up an existing FileMaker solution, connecting it to other tools through APIs, or building the supporting scripts that make version control and code review a daily habit instead of a nice idea. Loggix works with FileMaker systems, custom web applications, and the integrations between them, and can help you figure out where structured version control would actually pay off first.\u003C\u002Fp>\n","Shantanu","2026-08-20",1787213698000,[18,19,20,21,22,23,24],"FileMaker development","version control","Git","CI\u002FCD","code review","DevOps","custom software maintenance","\u002Fapi\u002Fknowledge\u002Fimage\u002F470\u002F?v=aac336f8b225",false,null]