时间戳

首页 > 解决方案 > Git 分支实践与未来和即将到来的代码混合

git - Git 分支实践与未来和即将到来的代码混合

问题描述

我的团队正在使用具有典型开发 - 发布 - 主分支设置的 GIT。所有功能分支都是在开发之外创建的，而发布分支是在开发之外创建的。

但是，他们不想将功能分支合并回开发，而是希望首先将其提交到所有代码所在的未来代码分支 - 用于下一个产品版本和其他所有内容的东西。

这会产生一个问题，因为有时在将内容推送到未来代码时会出现合并冲突；当发生这种情况时，您必须与未来代码的提示合并以解决它，然后您的分支中就会有未来的东西。

他们想出了几种方法来防止原始分支被未来的东西污染。但我相信任何方式（保留原始副本、跟踪对樱桃采摘的提交等）都不是一个优雅的解决方案。

我相信不应该有未来的代码分支，如果你想及早展示 QA，那么你运行一个功能分支的构建 - 没有未来的代码分支。

是否还有其他人们成功使用的方法不会将 GIT 扭成一个结？

感谢您提供任何有用的提示。

标签： git

解决方案

您直接从分支中面临的问题develop是您增加了人们添加提交的复杂性，而 QA 可能不希望在构建中添加这些提交。此外，如果 QA 带回一个 bug 让您检查分支并使用它（因为开发人员每天提交很多），也没有可靠的流程或方法。

如果您从开发人员本地功能分支提供构建，事情就会开始重复，并且 QA 无法处理他们获得的构建数量。我们倾向于每周提供包含许多功能的构建。

我倾向于坚持坚实的结构

ReleaseCandidate - this is where live code is
BetaCandidate - this is where 'future' code lives
DeveloperMaster - this is where every developer puts there code in

这给你的是：

  • DeveloperMaster 只能合并到 BetaCandidate
  • BetaCandidate 只能合并到 ReleaseCandidate
  • 开发人员在 DeveloperMaster 中完成所有提交

当需要构建时，专门的开发人员会将所有功能合并到 BetaCandidate 中，并将构建提供给 QA。QA 回来了，50 个新功能中有 3 个失败了，您现在从 BetaCandidate 中挑选并删除这些提交，并将 BetaCandidate 合并到 ReleaseCandidate 并发布它。

然后，开发人员仍然在 DeveloperMaster 中进行旧更改，并且可以解决该错误，并且此功能将进入下一个 beta 版本。

如果需要在发布之前修复该功能，开发人员会在 DeveloperMaster 中进行更改，并选择提交到 BetaCandidate 中。

你有这个可靠的 git 流，它只允许向前移动。

推荐阅读