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?

  • 1
    Pull requests are branch -> branch, the idea of having multiple pull requests from one branch to another doesn't make sense. Why isn't the code reviewed in the first PR, from the feature branch to the sprint branch? What's the point of that branch and PR (other than delaying integrating, which isn't a good thing)? And why does it need reviewing again after it's merged in to develop? – jonrsharpe Apr 6 at 7:57
  • Sprint branch has chnages done by mutiple scrum teams working with differnnt modules. Code reveiw is done for evrey PR to sprint branch. PR to develop will be tracked with release perspective. Hope you understand the question. – Eby Louis Apr 6 at 8:14
  • Not sure I fully understand. Is this bitbucket specific? Can you do an example timeline showing the PRs, which ones you approve and which are auto approved? – Ewan Apr 6 at 13:59
  • 2
    Can you explain more about the purpose of the sprint branch? It sounds like your sprint branches are actually trying to serve the role of the develop branch, and the develop branch is serving the role of a release branch. This workflow seems like it would delay cross-team merge conflicts until the sprint branches go into develop, rather than allowing the developer to fix the conflict before it even goes into the sprint (de-facto develop) branch. – Kyle McVay Apr 6 at 21:56
  • The only reason could be keeping track of work items. We can easily find which sprint completed the feature. – Eby Louis Apr 7 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.