5

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?

Improve this question
5
  • 2
    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, 2019 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, 2019 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, 2019 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, 2019 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, 2019 at 9:16

1 Answer 1

Reset to default
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.