如何解决功能分支中的切向重构代码

Question

在功能分支中工作时，我发现应该重构的代码与该分支无关，除了它与我正在使用的文件相同。

我应该创建一个新的用户故事吗？

另外你如何写一个重构代码的用户故事？

在小修复的情况下，是否有理由创建PBI和分支来修复？

尝试和寻找最接近的相关用户故事并在任务中实施一项任务难道不好吗？

交叉贴：https://softwareengineering.stackexchange.com/questions/342503/how-to-address-tangential-refactorable-code-in-a-feature-branch

Answer 1

答案取决于球队如何使用用户故事和任务，以及他们的重构方法。

关联的工作项目，以提交

如果他们有，迫使你的提交工作项关联任意的政策，那么你要么需要重写政策或相关联。通常这种关联对于某种发布报告是必需的，以便可以看到发布中的所有更改。 也许团队正在使用关联来跟踪任务的时间？如果是这样，请创建一个任务以将提交关联到。
因此，答案取决于团队如何使用关联。 过去，我使用用户故事“改进组件X”将重构关联到。这个用户故事仍然是一个追踪改进的地方。 我的一般建议是避免不必要的努力（例如，在任务没有实际使用时创建任务）并尽可能做到最简单的事情。你想尽可能简单地进行重构。

分支

是否重构需要进入主线在不同的时间比功能？如果是这样，你需要一个单独的分支。 如果重构可以与特征同时进入，请保持简单并重构特征分支中的内容。我至少会使用一个单独的提交重构。