Skip to main content
  1. Learn
  2. Software Development
  3. Guides
  4. Git tutorial
  5. Git collaboration
  6. Reviewing changes
  7. Pull request workflow
GuidesSoftware DevelopmentBacklog
Git

Project and code management together.

Pull request workflow

Having a structured code review process using pull requests leads to higher-quality source code and provides greater context for future discussions.

Here is a simple development workflow with pull requests your team can follow:

  1. [Developer] Clone or pull the source of the work target.
  2. [Developer] Create a branch for the work.
  3. [Developer] Perform development work such as adding and modifying functions.
  4. [Developer] Push the completed task.
  5. [Developer] Create a pull request, specifying which branch merges into which branch.
  6. [Reviewer] Check the changes from the notified pull request and review.
  7. [Reviewer] Judge the work and send feedback to the developer, if necessary.
  8. [Reviewer] Merge if there are no problems during the review.
  9. [Reviewer] Close if the pull request becomes unnecessary due to the review.

Repeat steps 3 through 7 as often as needed to improve the quality of the source code.

Example of a pull request workflow
Example of a pull request workflow.

Best practices for pull request workflow

When using a pull request (PR) workflow in Git, following best practices ensures smooth collaboration, effective code review, and efficient integration of changes into the codebase. Consider the following best practices for pull request workflows:

  • Open pull requests early: Open pull requests early in the development process to foster collaboration and gather feedback at an early stage. This allows team members to review and provide input throughout the development process, leading to better code quality and fewer significant changes later on.
  • Clear and descriptive pull request titles and descriptions: Provide informative and concise titles and descriptions for pull requests. Clearly state the goal of the changes, the problem being addressed, and any relevant context that reviewers should be aware of. This helps reviewers understand the purpose and scope of the pull request.
  • Small, focused pull requests: Keep pull requests small and focused. Each pull request should address a specific, well-defined issue or feature. This makes the code changes easier to review, test, and understand.
  • Regularly commit and push changes: Commit and push changes to the branch associated with the pull request frequently. Small, incremental commits with descriptive messages make it easier to track changes and understand the development process.
  • Respond promptly to feedback: Actively engage with reviewers and respond promptly to their feedback and comments. Encourage constructive discussions and consider alternative viewpoints. Address concerns, questions, and suggestions in a timely manner.
  • Leverage automated checks: Utilize automated checks, such as continuous integration (CI) systems, to run tests, code quality checks, and other validations as part of the pull request process. These automated checks can catch issues early and ensure that the proposed changes meet the project's quality standards.
  • Engage multiple reviewers: Seek feedback from multiple reviewers with different perspectives. Multiple sets of eyes can catch issues, suggest improvements, and promote valuable discussions. Encourage reviewers to review the code, documentation, and other aspects of the changes.
  • Consider documentation and changelogs: Document the changes made in pull requests, especially for significant features, bug fixes, or breaking changes. This helps maintain a clear history of project changes, assists with future reference, and supports project documentation and release notes.
  • Merge with care: Before merging a pull request, ensure that all discussions have been addressed, automated checks have passed, and the changes have received appropriate approvals. Follow the team's agreed-upon merge process, which may include specific criteria or rules for merging.
  • Close and cleanup resolved pull requests: Once a pull request is merged, close and clean up the associated branches, if no longer needed. This helps maintain a clean and understandable repository history while reducing clutter.

By adopting these best practices, you can maximize the benefits of the pull request workflow, encourage collaboration, and facilitate effective code reviews and integration of changes into the codebase.

Subscribe to our newsletter

Learn with Nulab to bring your best ideas to life