Reviewing and Merging Pull Requests

This guide explains how to review GitStart pull requests, provide effective feedback, and handle the merging process.

Accessing Pull Requests

Finding Your PRs

GitStart creates pull requests in the repository you configured during setup:

• Dashboard-Created Tickets: PRs are automatically opened when the ticket is assigned
• Imported Tickets: PRs are created when internal development is complete and code is ready for review
• PR Links: Direct links to PRs are available in the ticket details on your GitStart dashboard

Understanding PR States

GitStart uses draft PRs (or Merge Requests in GitLab) to indicate work status:

• Draft/WIP: Development is still in progress
• Ready for Review: Code is complete and ready for your review
• Changes Requested: Awaiting developer updates based on your feedback
• Approved: Ready to merge at your convenience

The Review Process

Review Timeline

We recommend reviewing PRs within 1-2 business days of receiving the “Ready for Review” notification. Timely reviews help:

• Maintain development momentum
• Avoid PR pile-up and merge conflicts
• Reduce context-switching for developers
• Ensure faster delivery of your requirements

Providing Effective Feedback

When reviewing PRs, you can:

1. Comment on specific lines of code
2. Request changes for necessary modifications
3. Approve the PR when you’re satisfied with the implementation

Our developers typically respond to comments and change requests within one business day, allowing for an efficient review cycle.

Review Cycles and Iterations

There is no limit to review cycles, but we recommend:

• Consolidating all change requests within 2-3 review cycles
• Being specific and comprehensive in your feedback
• Distinguishing between critical issues and minor preferences

All iterations, bug fixes, and minor adjustments requested during the review process are included at no additional cost.

Handling Scope Changes During Review

If your review identifies requirements that weren’t in the original ticket:

• Minor Changes: Small adjustments can often be incorporated in the current PR
• Significant Changes: Create a new ticket to avoid disrupting the current development flow

For more details on managing scope changes, see our Managing Work in Progress guide.

Merging Process

When to Merge

Once you’re satisfied with the implementation and have no further comments:

1. Approve the PR in your repository
2. Merge the PR using your preferred method (standard merge, squash, rebase)
3. The PR will be automatically marked as “finished” in the GitStart system

Post-Merge Actions

After merging:

• GitStart developers will finalize the cost of the PR
• The cost will be reflected in your Usage page and subsequent invoice
• The ticket status will update to “Finished” in your dashboard

Declining to Merge

If you decide not to merge a PR:

1. Provide clear feedback about why the implementation doesn’t meet requirements
2. Our developers will address your concerns or suggest alternative approaches
3. If agreement cannot be reached, contact your Technical Project Manager to discuss options

Best Practices for Efficient Reviews

• Designate a dedicated reviewer familiar with the codebase
• Set aside regular review time to maintain development momentum
• Be specific in feedback to minimize back-and-forth
• Test the implementation against the acceptance criteria in the original ticket
• Communicate proactively if you need more time for complex reviews

Need Help?

If you have questions about the review or merging process, contact our support team at support@gitstart.com.