Question

我们刚开始使用git作为我们的生产代码，我们在工作流程中遇到了一个小问题。我们需要弄清楚如何处理在处理功能时出现的一般代码改进/技术债务修复。

我们采用的工作流程是使用'develop'作为主要的集成分支，并在'develop'之外的功能分支上开发所有功能。当一个功能完成后，开发人员会创建一个拉取请求，每个人都会检查它以在合并回到开发之前提供注释。这看起来效果很好。

我们遇到的问题是，在功能的例行开发期间，开发人员最终可能希望修改/重构一些通用代码以改进系统或清理一些技术债务。此更改很有价值，但与开发中的功能没有直接关系。

根据我们的工作流程，它应该在不同的分支上完成，在开发之前通过它自己的pull请求和代码审查。如果我们让他们这样做，那么他们如何在他们等待完整的代码审查发生并将代码合并到开发中的同时将更改恢复到他们的功能分支上。

我们的想法是：

1）樱桃挑选从'refactorX'分支到我们的特征分支的变化。继续开发并让git（希望）在我们合并回去时发现它已经从重构分支发生变化。

2）将'refactorX'分支合并到我们的功能分支中并继续开发。（注意：为'refactorX'开发的分支可能在开发历史的后期，所以我们认为这可能有问题）

3）我们还不知道其他一些更聪明的选择。：）

我们正在寻找的是关于如何处理这部分工作流程的最佳实践指南。在谈论它之后，我们知道它会经常出现，我们希望在我们的工作流程中找到一种平稳有效的方法来处理它。

有什么建议吗？

Answer 1

第三个选项是开发人员将所有功能分支重新绑定到已经重构的分支上（因此重构更改将包含在他们的所有工作中）。然后确保首先检查重构分支并将其合并回开发分支。然后所有的功能分支都将基于开发，你可以像往常一样合并它们（即合并一个，将其他分支重新定义到开发，重复）。

在ASCII艺术中，在审核重构之前：

--- development
               \
                --- refactoring
                               \
                                --- feature1
                                --- feature2

之后：

------ development|refactoring
                              \
                               --- feature1
                               --- feature2

然后，如果你完成了feature1并将其合并到：

------ refactoring --- development|feature1
                  \
                   --- feature2

您再次将feature2重新定义为开发：

------ refactoring --- development|feature1
                                           \
                                            --- feature2

然后您可以像往常一样合并feature2：

------ refactoring --- feature1 --- development|feature2

Answer 2

您似乎正在尝试避免将开发分支合并回功能分支。避免这一步骤是有益的，但有时候这是必要的，特别是在这种情况下。

我们开始使用的技术还有git rebase --onto。可以将功能分支移动到开发分支的末尾，以获取新功能，而不是将开发分支合并到功能分支中。

当您使用中央存储库时，创建新功能分支名称可能最有用。例如，我们将-v2附加到新的分支名称上。

典型的移动过程可能看起来像

git checkout feature
git branch -m feature-v2
git rebase --onto develop develop
git push -u origin feature-v2

现在您的功能分支中有新代码，但尚未将开发分支合并到功能分支中。

Git功能分支和次要代码改进

2 个答案: