Git Web 开发工作流程 : juggling the publishing of urgent fixes and multiple milestones

Question

我需要一些帮助来规划工作流程如何适用于最近转换为 Git(来自 SVN)的特定站点开发环境。

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

我的主要问题是:

• 应如何解决紧急问题
• 应该如何发布一个里程碑式的变化

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

每个开发人员仓库、中心仓库和阶段仓库都有这些分支:移动、重新设计、大师。Live repo 有一个分支:master

快速修复:开发人员对他们的 master 分支进行更改，然后推送到 hub。然后在现场，从集线器中提取更改(如果他们需要事先在那里进行测试，则首先进行阶段)。

最后阶段并发布“重新设计”里程碑:开发人员将重新设计分支推送到中心并在阶段 pull 更改。客户测试并批准。在 hub，开发人员将重新设计 merge 到 master 中(我想在这里创建一个标签)，然后在 live 中 pull master。还是开发人员将分支 merge 到他的副本中会更好，然后将他的 master 推送到 hub。另外，如果创建了标签，是否最好只在现场 pull 标签(如果可能)而不是 pull master 分支？标签应该只驻留在 hub 存储库中吗？

Answer 1

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

我总是会在任何 merge 之前先进行 rebase :开发人员将他的工作 rebase 到 master 分支之上，以解决本地的任何冲突(就像我在“rebase vs. merge”中描述的第一个场景)。
这将使任何后续 merge (在初始 rebase 之后)成为快进 merge 。

( Jefromi 在评论中提到 rebase 并不总是可行的。
的确，只要某些工作已经被推/pull 到别处，重新设置相同的工作是危险的。)

至于实时 pull 标签或 master，我宁愿只部署标签，而不是 HEAD的分支。意思是我会在现场推送一个裸仓库，它会有一个 post-receive Hook 设置为仅当所述标签位于 HEAD 时才使用标签更新非裸仓库(实际事件站点)的 master分支(git describe 可以轻松检查)