How to Create a Pull Request

Updated 1 week ago by Copado Solutions

A pull request is a process that allows you to review the changes that have been pushed to a branch in a repository before this branch gets merged into the master branch.

With Copado, you can create a pull request from different places, such as an individual user story, a promotion or between two different user stories. We will describe these options in more detail below.

Creating a Pull Request from an Individual User Story

When you create a user story and commit changes, Copado creates a feature branch. Once the commits are complete, you can review this feature branch that was created and compare it to the destination branch. In order to do so, follow the steps below:

  1. Open a user user story with Git commits.
  2. In the top right corner of the screen, click on Open Pull Request:

Creating a Pull Request Between Different User Stories

If the same component has been committed in more than one user story and has been tracked by Copado's Overlap Awareness Feature, Copado allows you to create a pull request to compare the user stories’ feature branches. In order to create a pull request to compare different user stories, follow these steps:

  1. Open a user story that has components tracked by Copado's Overlap Awareness feature.
  2. Navigate to the User Story Metadata related list and click on a component:

  1. A list of the user stories which include that component will be displayed. In the Related User Story Metadata section, select the user story you want to create the comparison with and click on Pull Request:

Creating a Pull Request from a Promotion

Copado allows you to create a pull request from a promotion to compare the promotion branch with the destination branch. In order to do this, follow the steps below:

  1. Open the Promotion record whose branch you want to compare.
  2. Under the Deployments related list, click on Pull Request:

What Happens When You Open a Pull Request?

When you open a pull request using any of the options described above, Copado redirects you to the linked Git repository where a pull request will have been generated between your feature branch and the destination branch or between two feature branches, as the case may be. If you have defined any default reviewers in your Git repository setup, these will also be pre-filled:

The reviewer is usually notified via email by the Git provider when there is a new pull request to be reviewed. You can also add a meaningful description and include a link to the user story so that the reviewer can easily navigate from the pull request to the User Story record:

Once you have entered all the information and the pull request is ready to be reviewed click on Create pull request:

When the pull request is created, three different sub-tabs are displayed:

  • Overview: Here you can see the author of the pull request, the reviewer and the description, if a description was added.
  • Commits: This tab shows the commits included in the feature branch but not in the destination branch or in one of the two feature branches selected for comparison.
  • Activity: Here you can see all the interactions which happen in the pull request including comments, changes, approvals and rejections.

The pull request will also show if the feature branch can be merged or if there are conflicts between the feature branch and the destination. This can be extremely useful in catching conflicts before changes are moved to the next environment. Bear in mind that if conflicts are detected, Copado auto-resolves them when the promotion branch is created, unless the file type has been added to the Exclude from auto-resolve field in the Pipeline record.

Pull request reviewers can review the changes in each of the files and leave comments within the context of the changes themselves allowing for better collaboration.

If changes are required, the feature branch can be updated by doing additional commits from Copado. This will also update the pull request in Git. Alternatively, if the entire user story needs to be re-worked, the reviewer can decline the pull request.

If a pull request is approved, you would usually merge it. However, if you have implemented Copado, you should not do that. Pull requests in Copado should be used for information purposes only, as Copado handles the merge for you once the deployment is successfully completed (check out the article Copado Branching Strategy for more information about this).

The activity in Git will also be tracked in Copado. If you have created a pull request from a user story, navigate to the Pull Request related list and check the information. The review action will be set to Approved or Unapproved depending on whether the pull request was approved or not.

How did we do?