- Pause automatic Git actions in both apps and preserve unsynced notes.
- Check whether Git has actually started a merge or rebase. A stopped fast-forward pull is a different state.
- Review each conflicting file in GitSync.md’s Conflict Center and save the intended result.
- Finish the merge or continue the rebase, then verify the commit before pushing.
This guide describes GitSync.md’s native conflict tools on iPhone and iPad. Obsidian Git has its own mobile Git implementation and commands. Do not run both clients against the same working copy at once. For a stuck or unfamiliar state, preserve the files and finish recovery on desktop.
Is it a conflict, or did the pull stop before merging?
GitSync.md’s automatic pull only accepts a clean fast-forward. It stops when local edits need attention or local and remote history have diverged. That message does not necessarily mean a merge has started or that conflict markers have been written.
Open the repository in GitSync.md and review its status. If no merge or rebase is active, first decide how to preserve local edits and reconcile the commits using the manual Git workflow. If a merge or rebase is already active, use that operation’s conflict controls rather than starting another pull.
If the error is authentication, a missing branch, or a missing repository, use the general troubleshooting guide instead.
Preserve the versions before choosing one
Pause Obsidian Git timers and GitSync.md’s automatic actions. Keep a separate copy of unsynced notes before resolving or aborting. Do not delete the vault, remove .git, or force-push to make the warning disappear.
A conflict usually means Git needs your decision about competing edits. For example, both devices might have changed the same line in Plan.md. Choosing a complete side can discard useful content from the other side.
Git’s merge documentation explains conflict states and the difference between resolving files and completing the operation. The steps below use GitSync.md’s interface.
Resolve the files in Conflict Center
- Open the repository’s Git controls and find Conflict Center. Check whether it identifies a merge or a rebase.
- Open an unresolved text file and inspect both sides. Compare the actual text before selecting Ours or Theirs.
- For a combined result, edit the Result content. Use Ours and Use Theirs copy a side into that result; they are not a substitute for reviewing it.
- Choose Resolve and confirm saving the result. Repeat for every unresolved path.
In a normal merge, Ours refers to the current branch’s side and Theirs to the incoming side. Rebase changes the context of these labels. Do not assume Ours always means the newest phone note; read the contents.
A small text example
This is an illustrative note, not a recorded app test. Suppose one side says:
## Planning call
Start: 10:00
Bring the budget draft.
The other says:
## Planning call
Start: 11:00
Bring the agenda.
If 11:00 is the correct time and both documents are needed, write the combined result explicitly:
## Planning call
Start: 11:00
Bring the budget draft and the agenda.
Review the entire note, including lines outside the edited paragraph. If you manually edited conflict markers, confirm that marker lines are gone and that the intended text remains.
Attachments, renamed files, and deletions
Binary attachments cannot be merged as text in GitSync.md’s editor. Conflict Center lets you select Ours or Theirs at the file level. If you need both versions, preserve independent copies before picking one.
For a rename/rename conflict, the editor asks which path to keep. Review both names and contents. A delete/modify conflict requires a deliberate choice about whether the file should remain. Do not apply one blanket choice to the whole vault just because most conflicts look similar.
Finish the operation, then verify
- Merge: after every conflict is resolved, enter the merge commit message and use the completion control. GitSync.md labels this Complete or Complete Merge depending on the surface.
- Rebase: use Continue Rebase. Another commit may produce another conflict; repeat the review until the operation finishes.
Resolving one file does not itself push a commit. Check repository status, read the resulting note in Obsidian, and inspect the history before pushing. Verify the exact note and commit on the remote, then pull on the other device.
GitSync.md also exposes Abort Merge and Abort Rebase. These cancel the active operation; they are not a replacement for keeping a separate copy of local work first. Move recovery to desktop if you are unsure which edits would remain.
Reduce the next conflict
For repeated workspace-setting conflicts, review your Obsidian .gitignore policy after resolving the current operation.
- Pull before starting to write on a device.
- Commit and push before switching devices, and verify that the push finished.
- Use one Git automation path for a working copy while you establish a reliable routine.
- Keep device-specific settings out of shared commits when they create repeated noise.
Automatic syncing cannot infer the meaning of conflicting sentences. Read the background-sync guide for the states that stop automatic work. If you prefer integrated syncing instead of managing Git history, compare Obsidian Sync and Git.
