Git conflicts and stale files

"Git conflict" covers two very different problems, and mixing them up wastes time. One happens on the server at deploy time — a file that should be gone is still there, or a change you made vanished. The other happens on your own machine — Git can't merge two sets of edits and leaves markers in the file. This guide separates them, because the Falix deploy model makes the first kind predictable and keeps the second kind off the server entirely.

How a Falix deploy touches files

Get this model in your head and most deploy-time confusion disappears. A deploy copies the repo's files into /home/container, overwriting any file with the same name. It never deletes files that aren't in the repo. That one rule explains every surprise below.

⚠️ Heads up: Deploys copy and overwrite; they never delete. It's the same behaviour that keeps your .env and databases safe — but it cuts both ways.

Stale files: "I deleted it from the repo, it's still here"

You removed a file from the repository, deployed, and it's still on the server. That's the "never delete" rule working as designed: a deploy adds and overwrites, but doesn't remove anything the repo dropped. The file will sit there — and keep being loaded — until you delete it in the File Manager.

The same goes for renames: renaming old.js to new.js in the repo deploys new.js and leaves the orphaned old.js behind. Delete the old one by hand.

Overwrites: "my change on the server got wiped"

You edited a file directly on the server, then a deploy reset it to the repo's version. Also the rule working: if the repo contains a file with that name, the deploy overwrites your server-side edit. For anything the repo manages, treat the repo as the source of truth — make the change there and deploy it, don't edit it live.

Two files you don't want overwritten need protecting:

Exclude paths are the deliberate tool here: they keep specific files from being overwritten even when they exist in the repo. Keeping secrets out of the repo in the first place is the cleaner habit — see Keep secrets out of Git.

🎯 Good to know: A deploy can look "successful" and still leave you on old behaviour if a stale file is being loaded, or if the app didn't restart. The companion guide When a Git deploy fails walks the "green but nothing changed" cases.

Merge conflicts: a local-Git thing, not a server thing

The other "conflict" is a real Git merge conflict, and it does not happen on Falix — the deploy pulls the finished result of your repository, it doesn't try to merge into whatever is on your server. Conflicts happen where you actually run git merge or git pull: on your own machine.

You get one when two branches changed the same lines and Git can't decide which to keep. It marks the spot right in the file:

<<<<<<< HEAD
const prefix = "!";
=======
const prefix = "?";
>>>>>>> feature-branch

Resolving it is manual and mechanical:

1. Open the file and find the <<<<<<< / ======= / >>>>>>> block.
2. Edit it into the single version you want to keep.
3. Delete all three marker lines.
4. Stage the file and commit — that completes the merge.
5. Push, then deploy. Falix pulls the clean, resolved result; the conflict never reaches the server.

⚠️ Heads up: Never let a file with <<<<<<< markers get committed and deployed — the markers aren't valid code and your app will crash on them (often as a SyntaxError at startup). Resolve locally first.

Merge conflicts are core Git, and there's more nuance than a troubleshooting page should cover — aborting a bad merge, conflict styles, merge tools. The official documentation at git-scm.com is the place to go deeper.

Next steps

• When a Git deploy fails
• Deploy from Git
• Keep secrets out of Git