如何构建相关的拉取请求

Question

我正在开发一个 Web 应用程序的很大一部分，并分配给我几张 jira 票来逐步完成它：例如

• 任务 1：创建显示项目列表的部分的主页
• 任务 2：创建包含详细项目描述的页面
• 任务 3：在详细页面添加创建/编辑/删除按钮以执行 CRUD 操作
• ...

所以就 jira 票证而言，一切都很清楚，但是如果每个任务都依赖于前一个任务，我应该如何使用 github 拉取请求 (PR) 系统来组织工作？

例如我为任务 1 创建了一个新分支，完成了它并创建了一个 PR。然后开始处理任务 2：基于任务 1 分支创建了一个新分支，完成了工作，现在我必须创建另一个 PR，但是目标分支应该是什么？如果我选择 dev，PR 将包括 Task 1 的内容（这使得审查变得困难并且看起来不正确）。也许我应该等待第一个 PR 被合并，然后才开始处理任务 2（但所有工作都会停止，直到任务 1 被合并）？

我遇到的另一个问题情况：假设在 sprint 管理结束时决定我们不再需要应用程序中的列表页面（任务 1），详细页面就足够了（任务 2 及更高版本）。这两个 PR 仍在代码审查中，任务 2 基于任务 1 分支。在这种情况下我该怎么办？

Answer 1

这是我的个人方式来处理这个问题：你一个接一个地堆叠一个分支，你将真正的目标分支设置为目标分支，而不是每张票开始的分支。当您创建 PR 时，由于您有更多的票，一张在另一张上，因此更难看到每张票的内容。你可能将目标分支设置为你开始工作的分支但是你必须小心在这些分支开始合并时更改目标分支，以便当你合并子分支时，它们最终不会被合并到另一个 PRs 分支然后丢失。

现在，这是可以管理的，但就移动分支而言，它并不是微不足道的。假设你在ticket1上工作，从master开始......你已经完成了......然后你从ticket1开始......你已经完成了......现在你从ticket 2开始......你已经完成了.

然后你意识到你需要在ticket2上做一些事情，你如何进行？您可以更改ticket2 ... 那么ticket3 会发生什么？特别是如果您想将票据 2 的更改更改为票据 3。然后你可以在ticket2之上重新设置ticket3，它应该是它。

如果ticket1需要更改怎么办？同样，您需要将更改拉入ticket2和ticket3。你如何进行？最简单的路线？在 ticket1 上 rebase ticket3，然后找到 ticket2 的位置并将分支放在那里。

这很简单，因为您正在同步移动分支，但是如果基础分支属于其他人，则可能会更加棘手......如果该人重新设置分支会发生什么？你会要求变基吗？你不能只是这样做，因为你不负责你开始工作的分支的修订......事实上，如果你重新设置它，你最终可能会带来一些东西在您没有注意到的情况下完全从基础分支中删除。看？它易于管理，但并非微不足道。

Answer 2

有各种选项可以回答这个问题...

我从develop-branch 创建所有分支，在拉取请求后我将所有分支合并回开发，这个develop-branch 是main-branch！

例如基于开发分支为任务 1 分支 A 创建。在此分支中进行需要进行的更改，将其推送到 github 并在那里创建一个拉取请求。现在，当您想继续工作时，请创建分支 2，例如任务 2，基于分支 1。所以不要结帐到开发分支。分支 A 正在等待批准。如果分支A批准并合并回develop-branch，则分支B基于develop-branch，不再位于分支A，因为这已合并回develop分支。

因此，您可以创建拉取请求并进一步创建新分支，而不会丢失任何代码，因为每个分支都基于前一个分支。