Git Web 开发工作流程：兼顾紧急修复的发布和多个里程碑

Question

我需要一些帮助来规划最近转换为 Git（从 SVN）的特定站点开发环境的工作流程。

我有 4 个开发人员，客户端服务器上有实时站点和暂存站点，还有一个托管“集线器”（裸存储库）和 2 个开发人员存储库的开发服务器。我们有几个里程碑式的变更需要处理，完成顺序未知，并且由多个开发人员处理。此外，实时站点需要大量快速修复。

我的主要问题是：

• 应该如何解决紧急修复问题
• 应该如何发布里程碑式的变更

我的大脑开始陷入循环，试图找出最佳的工作流程。作为本文的参考，假设我有两个里程碑式的变化：移动和重新设计。这是我到目前为止所想到的：

每个开发人员存储库、中心存储库和阶段存储库都有这些分支：移动、重新设计、主控。 Live repo 有一个分支：master

快速修复：开发人员对其 master 分支进行更改，推送到中心。然后在现场，从集线器中提取更改（如果需要事先在舞台上进行测试，则首先从舞台中提取更改）。

最后阶段并发布“重新设计”里程碑：开发人员将重新设计分支推送到中心并在阶段拉取更改。客户测试并批准。在中心，开发人员将重新设计合并到主控中（我认为在这里创建一个标签），然后实时拉动主控。或者，对于开发人员来说，合并其副本中的分支，然后将其主控推送到中心会更好吗？另外，如果创建了标签，是否最好直接拉动标签（如果可能）而不是拉动主分支？标签应该只驻留在集线器存储库上吗？

Answer 1

在我看来，你的工作流程是 75% 没问题。我的做法如下：

基本概念是每个分支代表网站的一种状态。主分支是当前正在进行的工作，这基本上就是您在临时站点上看到的内容。您创建一个代表实际实时站点的“实时”分支。然后，您就可以拥有执行其他任务所需的任意数量的分支。

您的开发人员将他们的更改推送到中心存储库中，每个存储库都有自己的分支。当您准备好某个功能时，您可以将更改合并/变基到主分支并将其推送到中心。然后，您将这些更改同步（推送或拉取）到暂存站点。您可以这样做，直到您对更改感到满意为止。 （在您的开发 PC 上）然后从 master 分支重新建立 live 分支。将其推送到中心，然后同步（推/拉）到实时服务器，从而更新网站。

这里真正重要的是你有一个单独的实时站点分支。这使您的开发人员能够获取实时分支并对站点进行快速更改。

最后需要注意的是，除了本地开发人员分支之外，所有分支在所有存储库中都是重复的。这使每个人都能看到工作的不同阶段。

Answer 2

除了“合并”部分之外，工作流程似乎很合理。

我总是会在任何合并之前先进行变基：开发人员在主分支之上对其工作进行变基，以便在本地解决任何冲突（就像我在“rebase 与合并")。
这将使任何后续合并（在初始变基之后）成为快进合并。

（Jefromi 在评论中提到变基并不总是可能的。
确实，每当某些工作已经被推/拉到其他地方时，重新调整相同的工作是危险的。）

至于实时拉动标签或主控，我宁愿只部署标签，而不是分支的 HEAD 。
这意味着我会在实时推送一个裸存储库，它会设置一个 post-receive 钩子，以仅当所述标签位于 < master 分支的 code>HEAD （gitdescribe 可以轻松检查）