用于移动开发的Git工作流程

Question

因此，我们开始在服务器端以及移动开发中使用gitflow工作流。 它可以很好地与服务器端代码一起工作，因为它具有测试覆盖范围和构建自动化功能，一旦功能正常，功能分支就合并到开发分支中。 与移动开发不同，由于更改可以立即生效（除了构建和测试之外，没有时间进行部署），因此您可以快速测试所推送的代码中是否存在任何错误，并快速进行更改。 因此，此工作流程非常适合服务器端开发。 但是，通过此工作流程，我们面临着移动开发方面的问题。

借助gitflow工作流，我们具有三个持久分支，即开发，登台和掌握。 master分支上的代码将转到我们的Play商店应用，我们还有另一个封闭的Beta版Google Play商店应用供暂存，仅适用于我们的团队成员，并且我们使用crashlytics beta将最新的开发分支代码仅分发给我们团队中的开发人员。 每当有人开始处理新功能时，该人就会创建一个由master派生的功能分支（以前我们曾将其从开发中派生出来），一旦功能就绪，就会向开发中创建拉取请求。 每天，我们都会审查请求请求，可以将请求合并到开发中。

现在，此工作流程面临两个主要问题。 一种是假设我们将某些功能合并到开发中，后来又发现其中存在许多错误。 现在无法将其进一步推进，整个开发周期陷入了困境，因为该代码已经与开发合并。 这就是我们开始从master而非开发分支分支功能的原因，因为至少单个功能分支将具有完整的代码。 一种方法是，可以将每个功能分别分发给团队成员进行测试，然后再将其合并到开发中，但这非常麻烦。 那么可以通过其他工作流程解决此问题吗？

另一个问题是代码冲突。 由于每个功能分支的基础代码都来自主分支，并且必须与开发合并，因此当今存在许多冲突。 以前，当我们从开发中分叉时，我们曾经定期将开发分支与人们正在处理的功能分支合并，这样就不会出现冲突，但是现在不能这样做了。 因此，现在要解决冲突，我们从功能分支中创建另一个临时分支，通过该分支我们可以合并开发代码，修复冲突并将其作为请求请求，这又不再麻烦。

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

Answer 1

SpitFlow

我与测试工程师的交谈中对此有相反的想法。 你的旅费可能会改变。

考虑什么时候合适的开发人员可以分叉整个代码库，并在自己的分叉中处理其功能。

准备就绪后，它们合并到自己的开发分支中，从而触发特定于该用户开发分支的CI框上的新构建。 是的，每个用户在每个develop分支的构建都是独立的。 过夜的功能构建将由（功能）测试人员掌握，而不会陷入代码审查的困境。

优点

• 您仍然可以跟随gitflow到T-无需引入另一个'alpha'分支或'BUT'（正在测试的分支） Gitflow和测试/部署

• 它是干净且隔离的（代码不会与稳定的develop分支混淆）

• 该功能可以进入（功能）测试人员手中，而无需经过进行代码审查的人员委员会。
• 测试人员的反馈意见可能会淘汰错误的功能（而不会打扰其他开发人员）
• 分叉的回购/功能可能是开发人员的亮点，因为该版本可能会到达利益相关者的手中，他们可能喜欢开发/产品团队委员会未认可的功能。
• 绕过繁文tape节以冒充炫酷的新功能，而无需“批准”。

缺点

• 能否与“谁批准了此规定”的产品所有者发生冲突？
• 当功能测试人员对代码进行“确认”后，仍然需要PR来回溯到源代码/开发+代码审查，然后再进行质量检查。
• 配置脚本以吐出新构建所需的额外devops带宽。
• 开发人员需要保持其开发分支与原始/开发负责人保持同步/最新。
• 当单独工作更长的时间时，可能会发生更大的合并冲突。
• 促进竞争（并非总是一件坏事）。
• 其他？

如果缺点超过了优点，那么这不适合您。 考虑到它可能是特定功能的临时票据，那么您可以“还原”回gitflow。

建议2

让开发人员将功能构建到测试人员的手机上，而不必经历很多gitflow难题。