Our current workflow is that we create a Sprint branch and then developers create Feature branches having the user story number. Once the story is complete this Feature branch is merged to Sprint branch by pull request where it undergoes code review. Once code review is complete then we raise another pull request to Develop branch, where on-site code review is done.
The problem is, when multiple teams are creating pull requests from Sprint to Develop branch, pipelined pull request are approved when the latest pull request is approved (is this the expected behavior?)
On-site coordinators use the pull request information from Sprint to Develop branch to track the changes that need to be released to production.
But since my pull requests are automatically approved when another in the pipeline is approved, I am not able to get the status of the pull request which I raised. I have to go to the commit history of Develop branch to find the merge commit of the pull request.
Is there any easy way of tracking my pull request?
Best Answer
Viewing a pull request from a sprint to a release branch is likely to include a lot of changes. These changes have already been reviewed in previous pull requests. Requiring another code review to incorporate the current sprint's changes sounds redundant. Just merge the sprint branch into the develop branch and push it. If you are only doing one merge per sprint for the entire project, the merge should be a fast-forward merge anyhow, which is low risk.
The real problem is the "sprint" branch. In a comment you mentioned that sprint branches are created in order to track which sprint a feature or task was completed in. This is not what Git was designed for — or any version control system for that matter. Work item tracking is not a concern for version control. You need to use another tool for this, like Jira, Azure DevOps, Rational Team Concert and their ilk. Even post-it notes or an Excel spreadsheet can work better than using a branch for a sprint.
Correlating a commit to a sprint should be done using the timestamp associated with that commit. Your sprints should chunk the calendar year into smaller pieces with a well defined begin and end date. If a commit falls within the begin and end date for a sprint, then it was committed in that sprint. Again, though, the status of a work item should be tracked elsewhere, not in version control.