用于移动开发的Git工作流

因此，我们开始在服务器端和移动开发中使用gitflow工作流。 它在服务器端代码中运行得非常好，因为有测试覆盖率，并且有构建自动化，特性分支在测试正常后就被合并到开发分支中。与移动开发不同，由于更改会在您希望的时候立即生效（除了构建和测试外，没有时间部署），因此您可以快速测试推送的代码中是否存在任何错误，并快速进行更改。因此，这个工作流对于服务器端开发非常有用。然而，我们面临着使用此工作流进行移动开发的问题

使用gitflow工作流，我们有三个持久性分支，即开发、暂存和主。master branch上的代码进入我们的play store应用程序，我们有另一个用于登台的封闭测试版google play store应用程序，仅对我们的团队成员可用，我们使用crashlytics beta将最新的开发分支代码分发给我们团队的开发人员。每当有人开始开发新特性时，这个人就会创建从master派生的特性分支（以前我们用来从开发派生它），一旦特性准备好，就会创建一个拉入开发的请求。每天，我们都会检查pull请求，并将正常的请求合并到开发中

现在，这个工作流面临两个主要问题。一是假设我们将一些特性合并到开发中，然后发现其中有很多bug。现在它不能再推进了，整个开发周期被卡住了，因为代码已经与开发合并了。这就是我们开始从主功能分支而不是开发功能分支的原因，因为至少每个功能分支都有完整的工作代码。一种方法是，每个特性都可以单独分发给团队成员进行测试，只有这样才能合并到开发中，但这非常麻烦。那么这个问题可以用不同的工作流程来解决吗

另一个问题是代码冲突。由于每个特征分支的基本代码都来自主分支，并且必须与开发合并，因此目前存在很多冲突。早些时候，当我们习惯于从开发中分岔时，我们习惯于定期将开发分支与人们正在处理的功能分支合并，这样就没有冲突，但不能再这样做了。所以现在为了修复冲突，我们从FeatureBranch创建了另一个临时分支，我们合并了开发代码，修复了冲突，并将其作为pull请求，这同样很麻烦

---

这一切看起来都像是gitflow工作流的问题，不适合移动开发。人们是否已经采用了更好的移动开发工作流程，甚至可以遵循一些实践来解决这些问题？

SpitFlow

在我与测试工程师的对话中，有一些相反的想法。您的里程可能会有所不同

考虑适当的开发人员何时可以分叉整个代码库，并在他们自己的分叉中处理他们的特性

准备就绪后，它们合并到自己的开发分支中，触发特定于该用户开发分支的新构建CI框。是的，每个开发分支的每个用户都有一个单独的构建。一夜之间的特性构建将掌握在（特性）测试人员手中，而不会陷入代码审查的泥潭

专业人士

• 您仍然可以跟随gitflow到T-而不引入另一个“alpha”分支或“BUT”（测试中的分支）

• 它是干净和隔离的（代码不会干扰稳定的开发） 分支机构）

• 该特性可以进入（特性）测试人员手中，而无需经过代码审查委员会
• 测试人员的反馈可能会消除有缺陷的特性（不会影响其他开发人员）
• 分叉回购/功能可能是开发人员的一个机会，因为构建可能会到达可能喜欢它的利益相关者手中 可能未经开发/产品团队批准的功能 委员会
• 绕过繁文缛节，在未经“批准”的情况下推出酷炫的新功能

缺点

• 可能会与产品负责人“谁批准了此计划？”产生冲突
• 当代码被特性测试人员“确定”后，它仍然需要一个PR返回到源代码/开发+代码审查，然后返回到QA更多测试
• 需要额外的devops带宽来配置脚本以生成新版本
• 开发人员需要使他们的开发分支与源代码/开发负责人保持同步/最新
• 单独工作时间较长时，可能会发生更大的合并冲突
• 促进竞争（并不总是坏事）
• 其他人

如果缺点大于优点，那么这不适合你。 考虑它可能是一个特定特性的时间券，然后你可以“回复”到GITFLUE。< /P> 建议2

---

让开发人员为测试人员的手机构建该功能，而不必经历太多gitflow的麻烦

我不明白这些和“移动发展”有什么关系。是什么使“移动开发”与“非移动开发”有根本的不同？主要与将代码应用到实际环境所需的时间有关。这种滞后造成了我在服务器端开发中没有遇到的问题中描述的问题。@Jonathan.Brink我只是发布了这个问题