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

Question

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

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

我的主要问题是：

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

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

每个开发者仓库、中心仓库和舞台仓库都有这些分支：移动、重新设计、大师。 Live repo 有一个分支：master

快速修复：开发人员对其主分支进行更改，推送到集线器。然后在现场，从集线器中提取更改（如果他们需要事先在那里进行测试，则先上阶段）。

最后阶段和发布“重新设计”里程碑：开发人员将重新设计分支推送到集线器并在阶段拉取更改。客户测试和批准。在中心，开发人员将重新设计合并到 master 中（我认为在这里创建一个标签），然后在 live 中拉取 master。或者开发人员将其副本中的分支合并，然后将他的 master 推送到 hub 会更好。此外，如果创建了标签，是否最好只在现场拉标签（如果可能）而不是拉主分支？标签是否应该只驻留在中心仓库中？

Answer 1

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

我总是在任何合并之前先进行变基：开发人员将他的工作变基在主分支之上，以便在本地解决任何冲突（就像我在“rebase vs. merge”中描述的第一个场景）。
这将使任何后续合并（在初始变基之后）成为快进合并。

(Jefromi 在评论中提到变基并不总是可能的。
诚然，只要某些工作已经被推/拉到其他地方，重新定位相同的工作是危险的。）

至于在现场拉取标签或主控，我宁愿只部署标签，而不是分支的HEAD。 这意味着我会在实时推送一个裸仓库，它会设置一个post-receive 挂钩来更新带有标签的非裸仓库（实际的实时站点），前提是所述标签位于HEAD 的master分支（git describe 可以轻松检查）

Answer 2

在我看来，您的工作流程是 75%。以下是我的做法：

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

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

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

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