【问题标题】:How to test a git flow feature in another feature如何在另一个功能中测试 git flow 功能
【发布时间】:2019-01-22 04:44:42
【问题描述】:

所以目前我在一个功能分支上(比如说f1),develop 分支领先于f1
另一位开发人员正在开发新功能f2 并提交到develop 分支。现在develop 分支具有f2 功能以及f1 中没有的其他功能。
现在我只想测试功能f2,而不测试develop 上但不在我的分支f1 中的所有其他功能。我怎样才能做到这一点?

重要提示:完成测试后,我希望 f2 退出我的 f1 分支。

现在我正在通过以下方式执行此操作:

  1. 存储我所有未更改的更改 (git stash),因为我不确定是否要提交它们
  2. cherry 选择f2 (git cherry-pick f2) 中的提交
  3. unstash (git stash pop)
  4. 测试
  5. 存储我所有未更改的更改 (git stash)
  6. f1 上恢复精选提交
  7. unstash 未提交的更改
  8. 如果所有更改都正常,请提交f1

有没有更好的方法来做到这一点?

【问题讨论】:

  • 我有点困惑。起初,您问“我怎样才能将来自f2 的提交提交到我的分支?”它有一个简单的答案,即挑选提交。然后你描述你所采取的步骤远不止这些:你检查你的分支f1加上你的分支上未提交的更改加上樱桃挑选的提交来自f2 通过未进一步指定的测试,如果是这样,您再次清理您的分支并提交您的更改......这些是完全不同的事情。但是,如果这是您想要做的,那么这些步骤就可以了。但不要还原,而是通过 rebase 删除提交。
  • 我从来没有说过我想要在我的f1 分支中来自f2 的提交,我只是想在f1 分支上测试f2。将f2 分支文件想象为f1 中的未暂存文件。这些步骤是我现在正在做的(并不意味着它们是要遵循的正确步骤),但我正在寻找更好/更快且不易出错的解决方案。未暂存的文件在那里,因为我不确定是否需要进行此更改,只有在测试之后我才会知道,因此我在挑选樱桃之前提交它们没有任何意义。
  • 我认为没有更简单的解决方案。我唯一能想到的是将您的更改提交到新分支f1-test 和cherry-pick f2 到该分支。这样您就不必一直存储/取消存储。但这使得之后将先前未提交的更改返回到f1 变得更加困难。所以你实际上一无所获。
  • 我想也许 git-flow 有一个功能可以处理这个问题,或者在 git 中有比我的更简单的方法。
  • 据我所知,但也许这里的其他人可以想到一个更简单的解决方案。如果您习惯了 git,那么您的方式不太容易出错 ;-) 如果您曾经破坏某些东西(例如丢失所做的更改),请查看 git reflog。

标签: git git-flow


【解决方案1】:

我注意到两件事:

  1. 您似乎认为 F1 只是您添加到分支的那些提交
  2. 因此,您正试图通过积极阻止您未为该功能创建的任何代码成为 F1 分支的一部分来保持 F1 分支“干净”

这造成困难的原因是你实际上在某种程度上反对 git 模型和 git flow 的工作方式。

为了解决第一个问题,分支(在 git 的大脑中)只是一个指向提交的标签,并且分支包含该提交、其父级及其父级的父级等。回到初始提交的方式。所以你的分支不是“我的代码”而是“项目历史,加上我的代码”。

当使用 git flow 时,develop 成为开发团队事实上的 master 分支。所以本质上,一旦某些东西被合并到开发中,它就是项目的“官方”代码,即使它还没有发布。

因此,如果 F2 F3F7 已全部合并到 develop 中,那么仅使用 F2 测试 F1 将永远无法让您全面了解您的代码将如何集成到主线代码。

继续我们的推理,在您的情况下,您的分支不是包含“项目历史记录,加上我的代码”,而是包含“项目历史记录的一些过时版本,加上我的代码”。用一个有点有缺陷的类比,您正在为 2018 年的野马设计一个车罩,将 2018 年的挡泥板固定在 1977 年的野马上,并希望获得最好的结果。

防止您的功能过时的推荐机制是定期将开发合并到您的功能分支中,或者将您的功能分支重新定位到新的开发负责人(取决于您是否共享了您的代码和您团队的工作流程偏好)。功能分支的开发人员始终负责解决冲突并确保已合并到开发的功能的完整性。


附录

正如您所说,保持分支清洁是团队的要求,rebase 是您最好的新朋友。

$ git checkout F1
$ git fetch
$ git rebase origin/develop

这将满足团队的要求,即从历史的角度保持您的提交和分支“干净”,同时允许您针对创建分支后添加到开发的所有代码进行测试。所有这些都不需要跳舞,也不需要回滚。

【讨论】:

  • 这很好,很花哨,但我在一个大项目上工作,我不同意你的观点。一些功能与我的“部分”无关,项目的其他一些部分可能尚未准备好(尚未开发中),因此与其与其他功能的一些代码抗争,可能配置尚未提交或上帝知道那里发生了什么,我将尝试保持项目按原样运行,并保持功能分支“干净”,而不是将它们之间的功能或与 dev 合并,这样您就可以清楚地了解一个功能究竟包含什么.另外,这是项目规则。
  • 我可能不清楚,但我不是在谈论尝试与尚未添加到开发中的任何东西集成。参与的开发人员越多,每天集成的功能越多,保持最新状态就越重要。现在我已经获得了有关您团队工作流程的更多信息,我已经用更具体的处方更新了我的答案。
  • 实际上我想我在这里找到了答案:stackoverflow.com/questions/32333383/… 我可以做一个git cherry-pick -n,然后我不需要变基或做任何其他事情。
  • @Edwin 我担心的是,由于您的方法是针对模型的,因此如果您在其逻辑模型中工作,您将自己手动做很多 git 自动处理的事情。仅举一个例子,无提交樱桃选择会将F2 中的代码混合到您工作目录中已经存在的F1 更改中。然后,您需要手动分离盐和胡椒,这比仅使用 git 专门提供的用于将已批准的代码集成到未批准的分支中的本机工具之一要做的工作要多得多。话虽这么说,试一试,它可以完美地为你工作。
  • 确保合并可能出错等等,但这就是我先存储我的东西然后进行挑选然后我可以使用存储功能来集成我未跟踪的文件的原因。对于我的情况,您所做的还不够,但也许在其他情况下,这就是解决方案。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-03-31
  • 2014-10-04
  • 1970-01-01
  • 2012-11-07
  • 1970-01-01
  • 1970-01-01
  • 2017-07-04
相关资源
最近更新 更多