Git Web开发工作流：同时发布紧急修复和多个里程碑

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

我在客户机服务器上有4个开发人员、实时站点和临时站点，还有一个dev服务器，它托管“hub”（裸repo）和2个开发人员repo。我们有几个里程碑式的变更要处理，完成顺序未知，并且由多个开发人员处理。此外，实时站点还需要大量即时快速修复

我的主要问题是：

• 如何解决紧急修复
• 发布一个里程碑式的更改应该如何进行

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

每个开发者回购、集线器回购和舞台回购都有以下分支：移动、重新设计、主。 实时回购有一个分支：master

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

---

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

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

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

（在评论中提到，并非总是可以重新设定基准。
诚然，当某些工作已经被推/拉到其他地方时，重新调整该工作的基期是危险的。）

至于在live上拉标签或主标签，我宁愿只部署标签，而不是分支的

头
。
这意味着我将在live上推送一个裸回购，它将设置一个
post receive
钩子，只有当所述标签位于
master
分支（git description
可以轻松检查）的
头部时，才使用标签更新一个非裸回购（实际的live站点）。
我认为您的工作流程是75%正常的。我会这样做：

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

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

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

最后需要注意的是，除了本地开发人员分支，所有分支在所有存储库中都是重复的。这使每个人都可以看到工作的不同阶段。
当然，您不能总是重新设置基础，特别是使用修补程序-您可能希望将它们合并到维护分支和当前版本中。您仍然可以让开发人员通过在本地执行合并来确保它是公共回购中的快进合并。太好了，感谢您深入解释了重定基础以及何时执行。关于钩子，你是说每当我在master上创建一个标记时，它都会自动将该标记推到live？不确定我是否理解正确。@spadeworkers：想法是让脚本能够检测推送的提交是否是一个标签（这就是
git descripes
的作用）。如果是这样的提交（即带有标记的提交），那么该标记将被推送到非裸回购，并且该非裸回购将与所述标记一起签出（通过相同的
post receive
hook脚本）。在我设置钩子之前，用标记更新live站点的过程是什么？我一直在看文档，似乎不清楚。我认为它使用的是ref名称，所以简单地说（从实时站点）：git pull 1.1.3（其中1.1.3是标记的名称）@spadewrkers：因为这是由裸repo钩子启动的，所以在非裸repo中使用一个简单的
git pull
就足够了（只有在提交有标记时才会发生）。看看这样一个钩子。谢谢，这让事情变得很清楚。我可以设想在我们的工作流程中使用这个模型。然后，在我的开发pc上从master对live进行重定基址后，将创建标记，在推送到hub和其他位置后，也会复制（标记）。是这样吗？