logo标签列表

移动开发的Git工作流程

gitworkflowgit-flowmobile-development
3
因此，我们开始在服务器端和移动开发中使用 gitflow 工作流。对于服务器端代码来说，它非常有效，因为有测试覆盖率和构建自动化，功能分支一旦被测试 OK 就会合并到开发分支中。与移动开发不同的是，由于更改立即生效（除了构建和测试之外没有部署时间），您可以快速测试是否存在推送的代码中的任何错误并快速进行更改。因此，这种工作流非常适用于服务器端开发。然而，在移动开发中我们使用这种工作流存在问题。
使用 gitflow 工作流，我们有三个持久分支，即 development、staging 和 master。master 分支上的代码会推送到我们的 Play 商店应用程序中，我们在 staging 中拥有另一个 Google Play 商店应用程序，该应用程序仅向团队成员提供，并且我们使用 Crashlytics Beta 仅向我们团队的开发人员分发最新的开发分支代码。每当有人开始着手新功能时，该人就会创建从 master 派生的 feature branch（以前我们是从 development 派生），一旦功能准备好，就会将其作为 pull request 合并到 development 中。每天，我们都要审查 pull requests 并将通过审查的请求合并到 development 中。
现在，我们使用这种工作流面临两个主要问题。其一是：假设我们将某个功能合并到了 development 中，后来发现其中存在许多错误。现在无法再推送任何修改，整个开发周期就会被卡住，因为该代码已经与 development 合并。这就是我们开始从 master 派生 feature branches 而不是从 development 派生的原因，至少每个功能分支都将拥有完全可工作的代码。一种方法是将每个功能单独分发给团队成员进行测试，然后再合并到 development 中，但这非常繁琐。是否能使用不同的工作流解决这个问题呢？
另一个问题是代码中的冲突。由于每个功能分支的基础代码来自 master 分支，并且必须与 development 合并，现在经常出现很多冲突。以前当我们从 development 派生时，我们经常将 development 分支与人们正在开发的 feature branches 合并，因此没有冲突，但现在不能这样做了。现在解决冲突的方法是从 feature branch 创建另一个临时分支，将 dev 代码合并到其中，解决冲突，然后将其作为 pull request 提交，这也稍微有点繁琐。
所有这些看起来像是 gitflow 工作流不适用于移动开发。是否有更好的移动开发工作流或实践可遵循来解决这些问题？
我不明白这些与“移动开发”有什么关系。是什么让“移动开发”与“非移动开发”在根本上有所不同？ - Chris
1
主要与将代码部署到生产环境所需的时间有关。这种延迟会导致我在问题描述中提到的问题，而这些问题在服务器端开发中并不会出现。 - pratsJ
https://www.reddit.com/r/AskProgramming/comments/45qftw/git_workflow_for_mobile_development_xpost_rgit/?ref=share&ref_source=link - pratsJ
https://news.ycombinator.com/item?id=11098036 - Jonathan.Brink
@Jonathan.Brink 我只是发布了那个。 - pratsJ
1个回答
0

SpitFlow

我曾与测试工程师交谈，他们对此有不同的看法。你的情况可能会有所不同。

当适当时，开发人员可以分叉整个代码库，在自己的分支上开发其功能。

准备好后，他们将合并到自己的开发分支中，触发针对该用户开发分支的CI盒子上的新构建。是的，每个用户每个开发分支都有一个单独的构建。过夜的特性构建将交给（特性）测试人员，而不会被代码审查拖累。

优点

  • 您仍然可以完全按照Gitflow的方式进行操作 - 而不需要引入另一个“alpha”分支或“BUT”（测试分支） Gitflow和测试/部署

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

  • 功能可以进入（功能）测试人员手中，而无需经过代码审查委员会的多人审核。
  • 测试人员的反馈可能会消除有缺陷的功能（而无需打扰其他开发人员）
  • 分叉的repo / feature可以成为开发人员展示自己的机会，因为构建可以到达利益相关者手中，他们可能喜欢未经dev /产品团队委员会批准的功能。
  • 绕过繁文缛节，使酷炫的新功能浮现出来，而不需要“批准”。

缺点

  • 可能会与产品负责人产生冲突：“谁批准了这个？”
  • 当代码被功能测试人员“确认无误”后，仍需要进行PR回到origin/develop + 代码审查，然后再进入QA进行更多的测试。
  • 需要额外的devops带宽来配置脚本以生成新的构建。
  • 开发人员需要保持他们的dev分支与origin/develop head同步/更新。
  • 在长时间独立工作时，可能会出现更大的合并冲突。
  • 培养竞争（不总是坏事）。
  • 其他问题？

如果缺点超过优点，则不适合您。考虑这可能是一个特定功能的临时票，然后您可以“恢复”回到gitflow。

建议2

让开发人员将功能构建到测试人员的手机上，而不需要跳过太多的gitflow步骤。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接