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

Question

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

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

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

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

我们的想法是:

1)樱桃挑选从'refactorX'分支到我们的特征分支的变化.继续开发并让git(希望)弄清楚当我们合并回来开发它已经从重构分支的变化.

2)将'refactorX'分支合并到我们的功能分支中并继续开发.(注意:'refactorX'的分支开发可能是在开发历史的后期,所以我们认为这可能有问题)

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

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

有什么建议？

Answer 1

看来您正在尝试避免将开发分支合并回功能分支。避免此步骤是有益的，但有时这是必要的，尤其是在这种情况下。

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

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

典型的移动过程可能如下所示

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

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