从开发到主控的拉取请求，如何保持分支“均匀/同步”

Question

我使用 git-flow 并根据 Github 保护规则我有分支master和develop受保护，两者都带有选项Require linear history。

一切正常，但现在我想不只是从develop到合并master，而是开始使用“拉取请求”( develop -- PR --> master) 我想知道是否可以在保持历史线性的同时保持分支均匀/同步，而不需要对develop树枝施加力。

目前，如果我PR从developto创建一个拉取请求master，并且因为Require linear history选中了该选项，我无法合并，但只是squash and merge因为rebase and merge这样，如果我修改develop分支并进行另一次提交，它会提前 N 倍，但永远不会是“偶数” 。

我发现报复的唯一develop方法master就是

git pull origin master --rebase

但这随后意味着强制推动：

git push -f

不使用时PR，我只需将开发合并到master（FastForward）并保持历史线性，我可以合并拉取请求并通过禁用来防止强制推送Require linear history，但历史不会是线性的。（我认为 PR 没有使用 FastForward 合并）

我使用 git-flow 的原因是该develop分支由 CI/CD 使用并部署到暂存和master生产，我知道这可以部分地通过使用来解决tags，以便合并到master没有标签的所有内容都可以部署到“暂存”并且仅标记为“生产”，但目前存在分支限制master，以及develop保持分支尽可能同步的最佳方法是什么？

Answer 1

tl;dr：如果您希望拥有线性历史记录，那么您不能使用 Git Flow。话虽如此，无论您是否将其称为“Git Flow”，如果您从命令行执行此操作，都可以通过快进合并来完成 GitHub Pull 请求。

细节：

与最流行的 Git SCM 工具相比，GitHub 是一个异常值，正如您所指出的，即使是“变基和合并”策略也使用rebase -f强制重写提交，即使它已经与目标分支保持同步。不幸的是，这不适合您。GitHub 根本不支持使用其 UI 进行快进合并，但您可以通过从命令行执行develop合并并在 PR 打开时推送它来实现所需的结果，而无需在分支上重写提交。这里的关键是它仍然可以与分支保护一起使用。

这应该可以实现您的目标，但我确实认为重要的是要指出您可能不应该在您的场景中使用 Git Flow。当然，如果您愿意，您可以这样称呼它，但是线性历史与 Git Flow 不兼容的原因有多种：

1. 也许最明显的原因是 Git Flow 建议（或者可以说是要求）您将所有分支与--no-ff. 根据定义，如果您遵循此建议，您将不会拥有线性历史。我个人偏好是使用半线性合并（又名“rebase then merge with no-ff”）策略将功能分支合并到共享分支，例如develop和release。生成的图表仍然“漂亮”，但包含提交的小线性气泡，而不是纯粹的直线提交。注意我只建议重新调整个人功能分支的基础。您不应该对共享分支进行变基，例如develop或master那样，这会导致痛苦和痛苦。（看来你知道这一点，这就是你问这个问题的原因。）此外，我总是--no-ff按照 Git Flow 的建议使用共享分支相互合并，即使它可能是快进合并。
2. 即使您在不需要时不强制合并提交，使用 Git Flow（甚至一般的 Git）的主要原因之一是允许不同的人同时进行同步开发。develop在 Git Flow 中，当您在等待部署时强化某个版本时，新的工作可以继续进行。如果您有同步开发，那么当需要将 a 上所做的更改合并到release或master返回到时develop，您将不需要强制合并提交，因为这是必要的 - 您别无选择。正如您所注意到的，在这种情况下进行合并提交的唯一替代方法是对共享分支进行变基，但由于痛苦和痛苦问题，我们无法这样做。
3. 为了便于讨论，我们假设您永远不会进行同步开发，并且您决定不强制合并提交。这意味着develop将始终领先master，并且您始终可以通过快进合并develop干净地合并。master如果您能实现这一点，那很好，但是您并没有真正使用 Git Flow 的大部分功能。如果您愿意，您仍然可以将其称为 Git Flow，但在这种情况下，我可能只是重命名develop为main，并将我的功能分支直接合并到 中main，然后在将其发布到生产环境时对其进行标记。顺便说一句，这个策略有很多不同的名称，所以我可能不会将其称为 Git Flow，而是“功能分支工作流”、“GitHub Flow”、“带有命名分支的基于主干的开发”或“GitLab Flow”与 Production 分支”等。我的观点是，你会偏离 Git Flow 太多，以至于你不妨将其称为更接近你正在做的事情的其他名称。