How GitNotēs Handles Conflicts

Why Conflicts Happen

GitNotēs stores your notes as plain text files in a local Git repository on your device. When you save, changes are written to the local working tree. During sync, GitNotēs stages those changes, commits them, and pushes to your remote — GitHub, GitLab, Gitea, or Forgejo.

Git is designed for distributed teams. Multiple people can edit the same file independently, then merge their changes together. Most of the time, Git handles this automatically: if you edited the top of a note while someone else edited the bottom, Git weaves the changes together without any drama.

But if two people edit the same line of the same note at the same time, Git cannot decide which version to keep. This is called a merge conflict. GitNotēs does not guess — it stops and asks you to choose.

What GitNotēs Does When a Conflict Appears

When you push, GitNotēs checks whether the remote has diverged from your local state. If it has, GitNotēs attempts to integrate your local changes — rebasing them on top of the remote changes. If a conflict is detected during this integration, GitNotēs surfaces it immediately and shows you exactly which note has the problem.

GitNotēs does not silently merge conflicting changes or discard either version. The conflict is shown to you clearly, with both versions visible, until you decide what to keep.

Learn how Git-backed notes work in more detail →

The Four Resolution Choices

GitNotēs gives you four explicit options when a conflict appears. Choose the one that matches your intent:

Accept Ours

Keep your local version exactly as it is and discard the remote change. Choose this when you know your local edits are the correct version — for example, you just finished updating a note and someone else's older version is clobbering it.

Accept Theirs

Discard your local version and take the remote change instead. Choose this when the remote has the right answer — perhaps a collaborator fixed an error while you were offline.

Accept Both

Both versions are kept together in the file, with the local content followed by the remote content. Choose this when you want to review both changes manually and decide later, or when both edits add value and should be retained.

Full Edit

Open the note directly and resolve every conflict by hand. You see the raw conflict markers (<<<<<<<, =======,>>>>>>>) and edit them out yourself, keeping exactly what you want from each side. Choose this for complex conflicts where no automated strategy fits.

After You Resolve

Once you pick a resolution, GitNotēs stages the resolved file, creates a new commit with the resolution, and pushes the result to your remote. Your remote is back in sync, and the conflict is resolved in your Git history — every resolution is traceable as a commit.

If you made changes offline while a conflict was pending, GitNotēs queues them and applies them after the conflict is resolved, so nothing is lost.

Preventing Conflicts

Most conflicts are rare in personal note-taking. A few habits help avoid them:

• Sync before starting a long editing session. Pull the latest changes before you begin writing to minimize divergence from the remote.
• Use one device at a time when possible. Editing on your phone and desktop without syncing in between increases the chance of divergence.
• Use Git branching for large rewrites. If you are doing a major restructure of your notes, consider creating a branch so your changes don't conflict with ongoing edits from other devices.

Conflicts Are Not Failures

In most note apps, simultaneous edits on two devices either get silently overwritten or require a manual copy-paste recovery. GitNotēs treats conflicts as first-class events: they are surfaced, they are legible, and they are resolved on your terms.

Because every resolution becomes a Git commit, you also have a full audit trail of what was resolved and why — useful if you change your mind months later.

See why developers choose Git-backed notes for collaboration →