Git分支与合并工作流问题。你是怎么做到的？

Question

这是我们的开发流程：

1. 开发人员在一个新的主题分支中处理一个问题。
2. 一旦他做完了，他就把这个分支推上来接受审查。
3. 我将分支合并成一个开发分支，并将其推到暂存服务器上的上游。
4. 客户端检查更改并批准/拒绝更改。

我的问题是在第3& 4步。客户机只能访问暂存服务器，因此为了让他看到更改，我必须将主题分支合并为一个开发分支并将其推送到暂存服务器，我通常不合并一个分支，而是平均合并3-4个分支。

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

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

这是一个“健康”的发展流程吗？你有什么建议，改进？

Answer 1

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

我宁愿恢复(如git revert)开发分支中被拒绝的更改，然后等待开发人员的修复。

通过使用git还原，我只添加新的提交，而不是更改历史记录(使用重基或git reset)。

这样，下一次提交(具有相同特性)应该很容易地在开发分支中合并。

Answer 2

只需引入一个阶段分支，这是肮脏的，任何人都不允许它的分支。

• 确保您的暂存部署过程处理历史记录重写。如果您的暂存服务器从中央回购系统中提取，则将其替换为fetch和reset --hard origin/branch。
• 每当您希望客户端检查更改时，只需使用之前的流程--将其合并到其中，如果需要更改，则重新合并。
• 偶尔在develop中合并，以确保您的所有更改。如果您当前没有任何评论(=staging应该与develop同步)，则将staging重置为develop (git checkout staging；git reset --hard develop)
• 因为分期应该是脏的，所以您总是可以进行疯狂的重写，就像返回几个步骤(git reset --hard HEAD~4)，如果更改破坏了什么等等，就不会产生任何后果。
• 只有在客户批准后才能将您的更改合并到开发中。

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

如果您担心必须多次解决合并冲突，请查看git‘s重传