git-sync

Run the sync workflow, which fetches origin, fast-forwards the local default branch by ref, then rebases your feature branch onto origin/main. If a rebase is unsafe, it merges instead and resolves conflicts with you one block at a time.

Rebase when your branch is local-only with no merge commits, giving linear history. Merge instead when the branch is pushed with an open PR, already contains merge commits, or when conflicts span multiple commits, since a merge resolves each collision once.

During a rebase, git replays your commits onto the default branch, so ours refers to the default branch and theirs refers to your own commit. This is the opposite of a merge, which is why conflicts should always be labeled by concrete side like your branch versus main.

Yes, but it requires git push --force-with-lease afterward since rebase rewrites commit SHAs. If the branch has an open PR, merging is recommended instead because force-pushing can orphan review comments pinned to old SHAs.

Uncommitted changes are stashed before the sync begins and restored with git stash pop afterward. The stash is never dropped until it applies cleanly or you explicitly confirm, so no work is lost.

Git only detects textual conflicts, not semantic ones like renamed functions or changed signatures introduced by the default branch. The workflow runs the repo's build and test commands after syncing to surface these breakages.