3

这是我们的开发工作流程：

  1. 开发人员在新主题分支中处理问题。
  2. 完成后，他将分支向上推以进行审查。
  3. 我将分支合并到一个开发分支中，并将其推送到登台服务器上的上游。
  4. 客户审查更改并批准/拒绝它。

我的问题出现在第 3 步和第 4 步。客户端只能访问临时服务器，因此为了让他看到更改，我必须将主题分支合并到开发分支并将其推送到临时服务器，我通常不这样做不要只合并 1 个分支，而是平均 3 - 4 个。

如果客户拒绝更改并且他需要进一步修改，那么开发人员会在同一主题分支中修复问题，我必须重新合并到开发中。

通过多次将主题分支重新合并到开发中，我在历史上失去了对该问题的跟踪。（有时也会导致冲突）

这是一个“健康”的开发工作流程吗？您有什么建议、改进？

4

2 回答 2

2

如果客户拒绝更改并且他需要进一步修改，那么开发人员会在同一主题分支中修复问题，我必须重新合并到开发中。

我宁愿恢复（如git revert）开发分支中被拒绝的更改，并等待开发人员的修复。
通过使用 git revert，我只添加新的提交，而不是更改历史记录（使用 rebase 或 a git reset）

这样，下一次提交（相同功能）应该很容易在开发分支中再次合并。

于 2013-01-21T11:19:53.210 回答
1

只需引入一个暂存分支，它是脏的，不允许任何人分支它。

  • 确保您的暂存部署过程处理历史记录重写。如果您的登台服务器从中央存储库中提取，请将拉取替换为 afetch和 areset --hard origin/branch
  • 每当您希望客户审核更改时，只需使用之前的流程 - 将其合并，如果需要更改，请重新合并。
  • 偶尔合并develop一次，以确保您拥有所有的变化。如果您当前没有任何评论（=staging应该与 同步develop），请重置staging为develop( git checkout staging; git reset --hard develop)
  • git reset --hard HEAD~4由于staging 应该是肮脏的，你总是可以进行疯狂的重写，比如只要返回几步（
  • 只有在客户批准后才将您的更改合并到开发中。

这样，您就不必担心在您并不真正关心历史（向客户显示内容）的过程中生成一个很好的历史，并且您的develop分支会获得非常干净的历史。

如果您担心必须多次解决合并冲突，请查看git 的 rerere 功能

于 2013-01-21T13:45:58.843 回答