Branches & Pull Requests

Publishing straight to your main branch is fine for a personal blog. For anything with review, staging, or more than one editor, work on a branch and merge through a pull request — all from inside Sitepins.

Switching Branches

The branch switcher sits in the project header. Click it to see every branch in the repository, with the default branch marked. There’s a search box for repositories with a lot of them.

Pick a branch and the whole project switches to it — content, media, configs, and code all reflect that branch. Everything you publish goes to it until you switch again.

Creating a Branch

1. Open the branch switcher
2. Click Create New Branch
3. Name it — staging, redesign, client-review
4. Confirm

The branch is created from the one you’re currently on, and Sitepins switches you to it.

You can also change a project’s branch permanently at Project Settings → Git → Branch Management. That sets the branch the project defaults to for everyone, as opposed to switching your own view.

Opening a Pull Request

When your branch has changes that aren’t on the base branch, Sitepins shows a Changes detected notice on the project page.

1. Click Create GitHub Request (or Create GitLab Request)
2. Enter a Title
3. Optionally add a Description
4. Submit

Sitepins opens a real pull request on GitHub or a merge request on GitLab. Reviewers can comment on it in the usual place, with the usual tools — it’s an ordinary PR.

Merging

Once the request is approved, click Merge in Sitepins to merge it into the base branch. Your host builds from the base branch and the change goes live.

View Request opens it on GitHub or GitLab if you’d rather merge there, or need to resolve conflicts.

Permissions

The GitHub App needs Pull requests: Write to create and merge PRs. If it’s missing, Sitepins says so explicitly:

Your GitHub App needs ‘Pull requests: Write’ permission

Fix it by updating the app’s permissions on GitHub and approving the change. See Git Repository Settings.

A Review Workflow

A pattern that works well for agencies and content teams:

1. Create a staging branch and connect your host to deploy it to a preview URL
2. Set the project’s branch to staging in Project Settings → Git
3. Editors publish to staging as usual — nothing about their workflow changes
4. When the batch is ready, open a pull request to main
5. Review the diff, merge, and production builds

Editors never see a branch decision. They just publish, and someone with the right role decides when work goes live.

Combine this with the Editor role and you have review without asking non-technical people to learn Git.

Live Preview on a Branch

Live preview runs against your current branch, so you can see a branch rendering before merging it — no deploy preview required.

Conflicts

Sitepins doesn’t resolve merge conflicts. If a merge conflicts, use View Request to open it on GitHub or GitLab and resolve it there. Once it’s resolved, Sitepins reflects the result.