Pull Requests

Propose, review, and merge code changes with structured feedback.

What Are Pull Requests?

A pull request is a proposal to merge changes from one branch into another. It serves as a collaboration point where the author presents their changes, reviewers provide feedback, automated checks run, and the team decides whether the changes are ready to be integrated. Pull requests are the primary mechanism for getting code into protected branches.

Every pull request has a source branch (where the changes live) and a target branch (where the changes should be merged into). The pull request shows the diff between the two branches, making it easy for reviewers to see exactly what will change.

Creating a Pull Request

To create a pull request, you need at least two branches: the source branch containing your changes and the target branch you want to merge into (typically the repository's default branch). When creating the PR, you provide:

Source branch — The branch with your changes.
Target branch — The branch you want to merge into.
Title — A concise summary of what the PR does.
Description — A detailed explanation of the changes, motivation, and any context reviewers need.

You can also assign reviewers, add labels, and link the PR to Work Ops tasks at creation time or at any point afterward.

Write PR titles that describe the outcome, not the activity. Instead of "Working on login page," use "Add password reset flow to login page." This makes the PR list scannable and the merge history meaningful.

Draft Pull Requests

Sometimes you want to open a pull request before the work is finished — to get early feedback, show your approach, or just to have a visible place to track in-progress work. Draft pull requests serve this purpose.

A draft PR behaves like a regular PR in most ways: reviewers can see the diff, leave comments, and discuss the approach. However, a draft PR cannot be merged. This prevents accidental merges of incomplete work. When the changes are ready, the author marks the PR as ready for review, which transitions it from draft to open status.

Pull Request Lifecycle

Every pull request moves through a defined set of states:

State	Meaning
Draft	Work in progress. Visible to the team for early feedback, but cannot be merged. The author transitions it to Open when ready.
Open	Ready for review and eligible for merging (once all requirements are met). This is the active review state.
Merged	The changes have been successfully integrated into the target branch. This is a terminal state — a merged PR cannot be reopened.
Closed	The PR was closed without merging. This can happen when the approach is abandoned, superseded by another PR, or no longer needed. Closed PRs can be reopened.

Code Review

Code review is the process of examining proposed changes before they are merged. Reviewers read the diff, evaluate the approach, and provide feedback. In Bosca Git, reviews are structured around verdicts and inline comments.

Review Verdicts

When submitting a review, the reviewer chooses one of three verdicts:

Approved. The reviewer is satisfied with the changes and considers them ready to merge. Approvals count toward the minimum approval requirement set by branch protection rules.
Changes Requested. The reviewer has identified issues that should be addressed before merging. This signals to the author and the team that the PR needs more work.
Comment Only. The reviewer has feedback or questions but is not blocking the merge or formally approving. This is useful for advisory reviews, questions about approach, or feedback from team members who are not designated reviewers.

Inline Comments

Reviewers can leave comments on specific lines of the diff, making feedback precise and contextual. Instead of saying "there is an issue in the validation logic," a reviewer can point to the exact line and explain the concern. Inline comments are attached to the diff, so they stay relevant even as the conversation evolves.

Review Dismissal

In some cases, a review needs to be dismissed — perhaps the reviewer is unavailable, their feedback has been addressed through a different approach, or the review was submitted against an outdated version of the code. Authorized users can dismiss a review with a reason, which clears the verdict without deleting the review comments. This is particularly important when branch protection requires approvals and a stale "Changes Requested" verdict is blocking a merge.

When branch protection is configured to dismiss stale reviews, pushing new commits to the PR automatically invalidates previous approvals. This ensures reviewers evaluate the latest version of the code, not an earlier snapshot.

Merge Strategies

When a pull request is ready to merge, the person merging it chooses from the merge strategies that the repository administrator has enabled. Each strategy produces a different commit history shape:

Strategy	Result	When to Use
Merge Commit	A new merge commit is created that has two parents — the tip of the target branch and the tip of the source branch. The full branch history is preserved.	When you want to see exactly when and where branches were integrated. Good for long-lived feature branches where the individual commits tell a story.
Squash	All commits from the source branch are combined into a single new commit on the target branch. The individual commits disappear from the target's history.	When the source branch has many small, incremental, or work-in-progress commits and you want a single clean entry in the main branch history.
Rebase	Each commit from the source branch is replayed on top of the target branch, creating new commits with the same changes but new hashes. No merge commit is created.	When you want a linear history that preserves individual commit granularity. Each commit remains a separate entry but they appear as if they were written on top of the target branch.
Fast-Forward	The target branch pointer is moved forward to the tip of the source branch. No new commits are created. Only possible when the target has not diverged from the source.	Strictly linear workflows where the source branch is always rebased onto the target before merging. Produces the cleanest possible history.

Most teams find that enabling Squash and Merge Commit covers the majority of use cases. Squash for routine feature work, Merge Commit for larger efforts where individual commits matter.

Cross-Fork Pull Requests

When a repository has been forked, contributors can open pull requests from a branch in their fork targeting a branch in the parent repository. This is the standard contribution model for projects where external contributors do not have push access to the upstream repository.

Cross-fork PRs work exactly like same-repository PRs — they go through the same review process, are subject to the same branch protection rules, and can be merged using any enabled merge strategy. The only difference is that the source branch lives in a different repository.

Work Ops Auto-Linking

Bosca Git automatically scans commit messages, pull request titles, pull request descriptions, and branch names for Work Ops task keys. When a task key is detected, the platform creates a bidirectional link between the pull request and the task.

This means your team does not need to manually link PRs to tasks — the connection happens automatically as long as the task key appears in the right places. The linked tasks are visible on the pull request page, and the linked pull requests are visible on the task page, giving both developers and project managers a complete picture of how work items connect to code changes.

Include the task key in your branch name (for example, naming a branch after the task) and every PR from that branch will auto-link.
Mention the task key in your commit messages and those commits will be linked to the task.
Reference the task key in the PR title or description for an explicit, visible connection.

Auto-linking works with any Work Ops task key format recognized by the platform. The detection is automatic — no special syntax or prefixes are required beyond the task key itself.