我正在使用Node.js构建后端，我在一个多人的团队中使用Bitbucket的Jira中的sprint board。有时我们有任务，这些任务之间有一些依赖关系。
例如，我们有任务1，任务2和任务3。任务2是任务1的延续，任务3是任务2的延续。一旦任何任务完成，审查和合并到主分支都有延迟。
请在Scrum方法中分配这些任务时提出最佳实践，考虑到每个任务都有一个单独的分支和拉取请求。
接下来我们从master中获取Task 1分支，一旦Task 1完成，我们就为Task 1提升PR。然后我们从Task 1中获取Task 2的分支，一旦完成，就将PR提升到Task 1本身。然后对Task 3做同样的事情。但是这有一个问题，我们必须首先合并Task 3的分支，然后是Task 2，然后是Task 1。
分支流程：
合并流：
如果这种技术是好的，那么bitbucket中是否有任何方法来限制合并任务1的拉取请求，直到合并任务2的拉取请求。与任务3和任务2相同。
1条答案
按热度按时间g6ll5ycj1#
理想的工作流是等待合并Task 1分支，然后开始处理Task 2，Task 2也将从master分支创建一个分支。
我相信，既然你不想等待任务1代码审查完成，你想开始工作任务2.在这种情况下，从任务1创建任务2分支是一个很好的做法，但你不应该合并任务2分支在任务1分支，因为，当你合并任务2分支到任务1分支，任务1分支将开始包含任务1和任务2的代码;虽然任务1和任务2是相关的，但它们的代码应该在不同的分支中。
所以，我遵循以下过程：
1.从master分支创建Task 1分支
1.当任务1编码完成后，创建从任务1分支到主分支的PR
1.从Task 1分支创建Task 2分支
1.任务2编码完成后，等待任务1请购单合并。
任务1请购单合并时;
1.从master分支中重组/合并Task 2分支
1.创建从Task 2分支到master分支的PR
您也可以按照此路径执行任务3和其他即将执行的相关任务。