3

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

使用 gitflow 工作流，我们拥有三个持久分支，即开发、暂存和主控。主分支上的代码转到我们的 Play 商店应用程序，我们还有另一个封闭测试版 google play 商店应用程序用于暂存，仅对我们的团队成员可用，我们使用 crashlytics 测试版将最新的开发分支代码仅分发给我们团队的开发人员。每当有人开始开发新功能时，该人都会创建从 master 分叉的功能分支（以前我们曾经从开发中分叉它），一旦功能准备就绪，就会创建一个 pull request 到开发中。每天，我们都会审查拉取请求，并且可以将其合并到开发中。

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

另一个问题是代码冲突。由于每个功能分支的基本代码都来自主分支，并且必须与开发合并，因此现在存在很多冲突。早些时候，当我们从开发中分叉时，我们经常将开发分支与人们正在开发的特性分支合并，因此没有冲突，但不能再这样做了。所以现在为了解决冲突，我们从特性分支创建另一个临时分支，我们将开发代码与它合并，修复冲突并将其作为拉取请求，这又有点麻烦。

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

4

1 回答 1

0

吐流

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

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

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

优点

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

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

  • 该功能可以进入（功能）测试人员手中，而无需通过进行代码审查的人员委员会。
  • 测试人员的反馈可能会淘汰有缺陷的功能（不会打扰其他开发人员）
  • 分叉的回购/功能可能是开发人员大放异彩的机会，因为构建可以到达利益相关者的手中，这些利益相关者可能喜欢开发/产品团队委员会可能未批准的功能。
  • 绕过繁文缛节，在没有“批准”的情况下冒出很酷的新功能。

缺点

  • 是否会与“谁批准这个”的产品所有者产生冲突？
  • 当代码被功能测试人员“确定”时，它仍然需要 PR 回到原始/开发 + 代码审查，然后再回到 QA 进行更多测试。
  • 配置脚本以吐出新版本所需的额外 devops 带宽。
  • 开发人员需要使他们的 dev 分支与 origin/develop 负责人保持同步/最新。
  • 长时间单独工作时可能会出现更大的合并冲突。
  • 促进竞争（并不总是一件坏事）。
  • 其他的？

如果缺点大于优点，那么这不适合您。考虑它可能是特定功能的临时票，然后您可以“恢复”回 gitflow。

建议二

让开发人员为测试人员的手机构建该功能，而无需跳过这么多 gitflow 箍。

于 2016-10-20T18:14:57.030 回答