11

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

我们采用的工作流程是使用“开发”作为主要集成分支，并在“开发”的功能分支上开发所有功能。当一个功能完成后，开发人员会创建一个拉取请求，每个人都会对其进行审核以提供评论，然后再将其合并回开发中。这似乎工作得很好。

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

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

我们的想法是：

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

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

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

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

有什么建议吗？

4

2 回答 2

4

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

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

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

之后：

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

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

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

您再次将 feature2 重新定位到开发中：

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

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

------ refactoring --- feature1 --- development|feature2
于 2011-12-22T16:43:35.750 回答
2

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

我们开始使用的一种技术也是git rebase --onto. 无需将开发分支合并到特性分支中，特性分支可以移动到开发分支的末尾以获取新特性。

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

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

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

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

于 2011-12-22T17:11:38.793 回答