因此，我们开始在服务器端和移动开发中使用gitflow工作流程。 它非常适用于服务器端代码，因为有测试覆盖率和构建自动化，一旦测试好，功能分支就会合并到开发分支中。与移动开发不同，由于更改是您希望的（除了构建和测试之外没有时间进行部署），您可以快速测试您推送的代码中是否存在任何错误并快速进行更改。因此，这个工作流程非常适合服务器端开发。但是，我们正面临着使用此工作流程进行移动开发的问题。
使用gitflow工作流，我们有三个持久分支，即开发，分段和主。主分支上的代码转到我们的Play商店应用程序，我们还有另一个封闭的测试版Google Play商店应用程序，仅供我们的团队成员使用，我们使用crashlytics beta仅向我们团队的开发人员分发最新的开发分支代码。每当有人开始处理新功能时，该人员就会创建从master分叉的功能分支（之前我们曾经从开发中分叉），一旦功能准备就绪，就会在开发中创建一个pull请求。每天，我们都会审查拉取请求，并将那些可以合并到开发中的请求。
现在，我们在此工作流程中面临两个主要问题。一个是假设我们将一些功能合并到开发中，后来发现其中存在很多错误。现在它无法进一步推进，整个开发周期被卡住，因为该代码已经与开发合并。这就是我们开始从master而不是开发中分支功能分支的原因，因为至少单个功能分支将具有完全可用的代码。一种方法是每个功能可以单独分发给团队成员进行测试，然后才会合并到开发中，但这非常麻烦。那么这个问题可以通过不同的工作流程解决吗？
另一个问题是代码冲突。由于每个功能分支的基本代码都来自主分支，并且必须与开发合并，因此现在存在很多冲突。早在我们习惯从开发中分叉时，我们经常将开发分支与人们正在处理的功能分支合并，因此没有冲突但不能再这样做了。所以现在为了解决冲突，我们从功能分支创建了另一个临时分支，我们用它来合并dev代码，修复冲突并将其作为pull请求，这又是一件很麻烦的事。
这看起来像gitflow工作流程的问题不适合移动开发。是否有更好的移动开发工作流程，人们已经采用了甚至可以遵循的一些实践来解决这些问题？
答案 0 :(得分：0)
<强> SpitFlow
对于我与测试工程师的对话有不同的想法。你的旅费可能会改变。
考虑适当的开发人员何时可以分叉整个代码库并在他们自己的分支中处理他们的功能。
准备好之后，他们会合并到自己的开发分支中，触发针对用户开发分支的CI框的新构建。是的，每个开发分支的每个用户单独构建。隔夜功能构建将由（功能）测试人员掌握，而不会因代码审查而陷入困境。
<强>赞成
您仍然可以关注gitflow到T - 而不会引入另一个'alpha'分支或'BUT'（正在测试中的分支）Gitflow and testing / deployment
它干净而孤立（代码不会破坏稳定的开发 分支）
<强>缺点
如果缺点超过专业人士那么这不适合你。 考虑它可能是特定功能的临时票据，然后您可以“恢复”回gitflow。
建议2
让开发人员为测试人员手机构建功能，而不会跳过如此多的gitflow箍。