时间戳

首页 > 解决方案 > 如何构建相关的拉取请求

git - 如何构建相关的拉取请求

问题描述

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

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

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

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

标签： gitgithubgithub-codereviews

解决方案

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

现在，这是可以管理的，但在移动分支方面并非易事。假设你在ticket1上工作，从master开始......你已经完成了......然后你从ticket1开始......你已经完成了......现在你从ticket 2开始......你已经完成了.

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

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

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

推荐阅读