Pull Requests and Merge
Purpose: Open the merge proposal from the session branch, refresh status from the git host, and complete the merge to finish the work item.
Create Pull Request
Once at least one commit exists on the session branch and no PR is yet linked, Create pull request appears in the work-item header beside the ⋮ menu. Pressing it opens the merge proposal from the session branch into main on the connected version-control system — the same PR a developer would open by hand, with title and description pre-filled from the work item.
The button does not merge anything by itself; it just creates the proposal so the team's normal review, CI, and approval flow can run. From this point onwards Swifter and your git host are in sync — work that lands in the PR description (template, checklist, related links) is visible on both sides.
Check Pull Request Status
After the PR has been opened, Check pull request status replaces Create pull request in the header. Pressing it pulls the latest review and CI state from the git host into Swifter so the team can see PR state without leaving the work item view. The status surfaces in the header and updates the available actions — once the provider reports the PR as ready to merge, Complete becomes enabled.
This is also the right action to press after a fresh CI run or a new approval — Swifter does not poll the provider continuously, so a refresh is explicit. The intent is to keep the team in one place rather than constantly tab-switching to the git host.
Complete the Merge
Complete is the final action and is enabled only when Swifter reports the linked PR as ready to merge. Pressing it completes the merge in the git host (where the provider allows server-side merge) and moves the work item to Done in the same step. The session is closed out and the work item view shifts into its read-only post-completion state.
In day-to-day use Complete is the only merge action you need — the merge strategy, commit message, and branch deletion behaviour follow the project's git-host settings, not separate controls in Swifter. Teams that prefer to merge through the provider directly can still do that, then return to Swifter for status refresh; Swifter will pick up the merged state and move the work item to Done on the next Check pull request status.
Force Merge Path
If a conflict appears when you press Complete, Swifter shows a dialog with Force Merge as the path to override. Force Merge is offered only when the provider supports it and only in conflict scenarios — it is not a fallback for normal disagreements between reviewers, and the project's branch-protection rules still apply.
Use Force Merge in line with your team's policy — most teams reserve it for trivial conflicts that have already been resolved on the branch but not picked up by the provider, or for the kinds of cross-cutting changes (config bumps, dependency rolls) where the merge order is what matters. For anything else, Update from Main on the work session, push the resolved branch, and retry Complete is the cleaner path.
After Completion
After Complete the work item moves to Done, the session is sealed, and the backlog tree reflects the new status — the parent feature shows the finished child under its Children section, and the project overview reflects the shipped item. Returning to Home shows the same project card with one more closed loop behind it.
From here the typical next move is one of: pick up the next work item under the same parent, sync the tracker to bring in newly-created items, or move to a sibling that already has a session waiting. The point of completion is the same as the point of start — back to the Reqs tab, with the backlog as the source of truth for what comes next.