我应该使用什么工作流程进行并行功能开发？每个特性都必须单独合并到 master 中

Question

我想知道在这种情况下哪种方法最好：

我有一个从 master 派生的 baseFeature 分支，以及从 baseFeature 派生的多个特征分支。 baseFeature 具有所有新功能分支共有的初始更改。

我现在的流程是将每个功能分支合并回 baseFeature，然后将请求 baseFeature 合并到上游 master。但这会导致多个功能被组合在同一个合并请求中以掌握（例如，一个合并请求中有 10 个功能）。我希望每个功能都作为单独的合并提交出现在大师的历史记录中。

当我尝试从每个功能分支执行单独的合并请求时，我得到

Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing to the same ref

一个解决方案是使用-f。但是它说不允许强制推送

我可以让每个功能都成为 master 的一个分支，并在开始任何工作之前将每个功能包含在 baseFeature 上的提交中。完成后我会把分支推到 master。

哪种方法最好？有什么可能性吗？我所需要的只是对每个功能有不同的合并请求。但我无法将 baseFeature 合并到 master 中，因为尚未审查。

Answer 1

这是您可以采取哪些措施来满足您的两个要求的直观表示：

每个功能分支都应该从基本功能中检出
每个功能分支都应该有自己的主控合并请求

_master___________________________________________________
            \                                  /  /    /
             \___baseFeature__                /  /    /
                              \              /  /    /
                               \_featureA___/  /    /
                                \             /    /
                                 \_featureB__/    /
                                  \              /
                                   \_featureC___/

说明

这里有两个分支要开始：master 和 baseFeature。从您的描述看来，baseFeature 有一些您希望包含在所有功能分支中的提交历史记录。所以从逻辑上讲，你想从那里检查每个功能分支是有意义的 git checkout -b featureA origin/baseFeature。

现在您无需将这些分支合并回 baseFeature，因为它们也具有正确的 master 提交历史记录。因此，他们有资格直接合并到 master 中。

首先要注意：在视觉示例中 featureA，无论哪个功能分支先合并，都会带来 baseFeature.

第二个警告：如果不同的功能分支正在处理相同的文件，则必须解决合并冲突。

Answer 2

既然你的问题已经澄清了，我会更新我的答案。

Updates were rejected because the remote contains work that you do not have locally. This is usually caused by another repository pushing to the same ref

这意味着您正在将新提交推送到与您的分支不同的分支——即有您没有的提交。为了保护您，它会阻止您这样做。想一想：您和其他人（或者可能是您在其他情况下）都对上游分支进行了更改。您不能只 推送本地分支的状态 （因为这就是推送所做的）并覆盖上游（当然可以，使用 "force push" git push -f ，但不要这样做，除非你真的想覆盖上游）。

您没有指定要推送哪个分支会导致此错误。本地主机到上游主机？本地功能分支到远程功能分支？

无论如何，既然你正在使用合并请求，你无论如何都不应该强迫掌握。

根据我对您的工作流程的了解，我认为您应该这样做：

将您的本地主机与上游主机同步。[1]
然后将不在您的功能分支中的 master 上的任何提交获取到您的功能分支中。 我强烈建议您通过变基您的功能分支来做到这一点。[2]
重新测试您的代码。根据需要进行修复。
提交合并请求。

如果您不知道变基，网络或 Whosebug 上有大量文章。 git rebase 是您应该知道的最重要的命令之一。

[1] 你的本地 master 应该总是看起来像上游。您不应该直接对其进行更改。鉴于您基于合并请求的工作流程，更改应始终按以下方式进行（简化）：

feature branch --> upstream master（通过合并请求）
上游主机 --> 本地主机（例如通过 git pull）

[2] 如果对 master 进行了更改，您应该定期执行步骤 1 和 2。否则，您可能正在处理功能分支，而该功能分支将无法与 master 上的最新更改一起使用。

我应该使用什么工作流程进行并行功能开发？每个特性都必须单独合并到 master 中

What workflow should I use for parallel feature development? Each feature must be merged into master on its own

git

gitlab

git-workflow