Git 分支和合并工作流问题。如何处理？

Question

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

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

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

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

通过多次将主题分支重新合并到开发分支中，我会失去对该问题的追踪记录。（有时还会导致冲突）

这是否是一种“健康”的开发工作流程？您有什么建议或改进意见吗？

- feketegy

---

暂存服务器是否可以处理多个分支？如果可以，您可以将 develop 和 feature-x 合并为 develop-feature-x，测试一下，如果成功了就进行实际合并。（或者直接将 feature-x 推送到暂存环境。） - Fred Foo

很有趣...我得手动更新暂存服务器，这样做。而且，我不知道这是否会使事情变得更加复杂... - feketegy

我不确定我理解你在最后一句话中的意思。你所说的“你失去了对问题的追踪”，是指哪些冲突可能会导致在原始分支上进行更多的工作？ - Colin Hebert

问题在于将多个分支合并到develop分支。例如，如果dev1在branch1上处理某些文件，并将其合并到develop分支中，而dev2则在branch2上工作。可能会出现写入相同文件的问题等等。 - feketegy

Answer 1

如果客户拒绝更改并需要进一步修改，则开发人员会在同一主题分支中修复问题，然后我必须将其重新合并到develop分支中。

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

这样，同一功能的下一个提交应该很容易再次合并到开发分支中。

- VonC

---

我个人很喜欢这种方法的声音。它以最预期的方式使用git工具，最大程度地减少了不必要的解决分支。 （并不是说它们很昂贵，但是过一段时间后可能会变得混乱和容易出错。） - Victor Zamanian

@feketegy 是的，正如我在我的回答中提到的那样，git revert 确实会添加新的提交。避免变基有助于在仓库之间进行同步（您只需拉取新的提交，而不是重置您的分支，因为上游分支已更改），并且将有助于再次合并（修复后的）功能。 - VonC

是的，但是 git revert 会以这种方式污染历史记录。例如，我看到一个提交，然后我看到一个还原提交，然后再次提交。很难审查提交的文件... - feketegy

@feketegy 污染代码？这只会强调客户拒绝的功能。通过正确命名规范，您可以快速提取要审核的正确提交。 - VonC

@VonC，你的惯例是什么？ :) - feketegy

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分支中。

这样做，您就不必担心在一个您并不真正关心历史记录的过程中（向客户展示东西）制作出漂亮的历史记录，而且您的develop分支会有非常干净的历史记录。

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

- Chronial

---

这是与我的答案相反的方法，而且像你所展示的那样，它也可以起作用。+1 - VonC