我需要一些帮助来规划工作流程如何用于最近转换为Git的特定站点开发环境（来自SVN）。
我在客户端服务器上有4个开发人员，实时和临时站点，以及一个托管“hub”（裸仓库）以及2个开发人员回购站的开发服务器。我们有几个里程碑的变化要处理，具有未知的完成顺序并由多个开发人员处理。此外，实时网站需要动态完成许多快速修复。
我的主要问题是：
我的大脑开始循环，试图找出最佳的工作流程。作为这篇文章的参考，让我们说我有两个里程碑的变化：移动和重新设计。这是我到目前为止所提出的：
每个开发者仓库，集线器仓库和阶段仓库都有这些分支：移动，重新设计，掌握。 现场回购有一个分支：主人
快速修复：开发人员对其主分支进行更改，然后推送到集线器。然后在现场，从中心拉出更改（如果他们需要事先在那里测试，则先进行阶段）。
最终阶段和发布“重新设计”MILESTONE：开发人员将重新设计分支推送到集线器并在阶段拉动变化。客户端测试和批准。在中心，开发人员将重新设计合并到主人（并且我认为在这里创建一个标签），然后在现场拉主人。或者开发人员在他的副本中合并分支，然后将他的主人推送到集线器会更好。另外，如果创建了一个标签，最好是在现场拉标签（如果可能）而不是拉动主分支？标签应该只驻留在集线器仓库吗？
答案 0 :(得分：2)
除“合并”部分外，工作流程似乎很合理。
我总是先在任何与rebase的合并之前：开发人员在主分支之上重新定义他的工作，以便在本地解决任何冲突（就像我在“rebase vs. merge”中描述的第一个场景）。登记/> 这将使任何后续合并（在最初的rebase之后）成为快进的。
（Jefromi在评论中提到，并不总是可以使用基础 的确，每当某些工作已被推到/拉到其他地方时，重新安排同样的工作是危险的。）
至于在现场拉动标签或主人，我宁愿只部署标签，而不是HEAD分支。
这意味着我会在现场推送一个裸仓库，只有当所述标签位于post-receive时才会有一个HEAD挂钩设置来更新非裸仓库（实际的实际站点）。 master分支（git describe可以轻松检查）
答案 1 :(得分：1)
在我看来，你的工作流程是75％好的。我将如何做到这一点：
基本概念是每个分支代表网站的状态。主分支是当前正在进行的工作，基本上就是您在临时站点上看到的内容。您创建一个代表实际实时网站的“实时”分支。然后，您可以根据需要为其他任务分配尽可能多的分支。
您的开发人员将他们的更改推送到集线器存储库，每个存储库都有其分支。准备好功能后，将更改合并/重新绑定到主分支并将其推送到集线器。然后，您将这些更改同步（推或拉）到暂存站点。您这样做直到您对更改感到满意为止。 （在您的开发PC上）然后从主分支重新绑定实时分支。将其推送到集线器，然后同步（推/拉）到更新网站的实时服务器。
这里真正重要的是你有一个单独的分支为实时网站。这使您的开发人员可以获取实时分支并快速更改站点。
最后要注意的是，除了本地开发人员分支外，所有分支都在所有存储库中重复。这使每个人都能看到不同的工作阶段。