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

Question

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

我们采用的工作流程是使用 develop 作为主要集成分支，并开发 develop 的 feature 分支上的所有功能。当一项功能完成时，开发人员会创建一个拉取请求，每个人都会对其进行审查以提供评论，然后再将其合并回开发中。这看起来效果很好。

我们遇到的问题是，在某个功能的日常开发过程中，开发人员可能最终想要修改/重构一些通用代码来改进系统或清理一些技术债务。此更改很有价值，但与正在开发的功能没有直接关系。

根据我们的工作流程，它确实应该在不同的分支上完成，在进入开发之前，该分支要经过自己的拉取请求和代码审查。
如果我们让他们这样做，那么在等待完整的代码审查以及代码合并到开发中的同时，他们如何才能将更改返回到他们的功能分支上。

我们的想法是：

1. 将 refactorX 分支中的更改挑选到我们的功能分支中。继续开发并让 git （希望）弄清楚当我们合并回来开发时它已经具有来自重构分支的更改。

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

3. 我们还不知道其他一些更聪明的选择。 :)

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

有什么推荐吗？

Answer 1

第三种选择是开发人员将所有功能分支重新建立到已重构的分支上（因此重构更改会合并到他们的所有工作中）。然后，您确保首先审查重构分支并将其合并回开发分支。然后，所有功能分支都将基于开发，您可以像平常一样将它们合并（即合并一个，将其他分支重新基于开发，重复）。

在 ASCII 艺术中，在回顾重构之前：

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

然后：

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

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

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

您再次将功能 2 重新定位到开发中：

------ 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

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