多个单元测试套件上下文中的 Git 工作流程

标签 git

我很好奇人们在 git 中使用什么来进行单元测试和内存测试标签。

例如,我定期通过 valgrind、drd 和 helgrind 运行我的 C++ 代码。

如果它们通过了,我将使用 mem_okdrd_okhelgrind_ok强制标记

当然,缺点是,我会丢失所有历史标签。

我想另一种方法是给它们编号(而不是使用武力),例如 mem_ok_1mem_ok_2mem_ok_3 等...。 ..也许我应该编写一个脚本来对我的标签进行编号?

开发人员目前如何在 git 中实现此类功能?

潜在的解决方案[使用分支而不是标签]

假设我有以下分支:

  • ma​​ster 提交必须通过 google-test、valgrind、drd、helgrind
  • 不稳定提交必须通过 Google 测试

我正在考虑这种工作流程(M 代表ma​​ster,U 代表不稳定)

M1 -> U1 (branch off M1)
      U2 
      U3 
M2 <- U4 [merge]
      U5 
M3 <- U6 [merge]

在 U2、U3 和 U5 中,提交刚刚通过 google-test:我没有时间 valgrind、drd、helgrind。 在验证所有测试(包括 valgrind、drd、helgrind)通过后,我将 U4 和 U6 merge 到 M2 和 M3 中。

我感到困惑的部分是,当我将 U4 merge 到 M2 时,我是否必须再次分支,或者我可以继续 U4 的工作来提交 U5、U6 等...?

换句话说,我只需要在这个工作流程开始时从主分支分支到开发一次,对吗?

最佳答案

Git 标签并不是真正设计用于像这样进行大量提交的。相反,我建议将 valgrind 等测试集成到您的工作流程中,而不是集成到您的分支中。如果您确信您的提交能够顺利编译,您可以自动运行测试,如果通过,则从 development 中提取。至passed-unit-test - cron 作业或类似作业(如果运行测试所需的时间是一个问题)。

您可以使用 git hook 来禁止推送到 passed-unit-test除非单元测试通过,否则分支。

然后您将拥有一个仅包含已通过测试的代码的分支。这是一个比增量标记或根本标记更简洁的解决方案。


编辑:

In other words, I only need to branch from master to development once in the beginning with this workflow, correct?

是的。 development滚入 master , master 被 push development开始(如果适用,如果有错误修复 - 但这可能与您无关)。

更长的解释和推理:我会使用很大程度上基于Nvie Git Flow的工作流程。工作流程。 (关联的脚本位于 here )。这是reasonably well used ,并且有很多关于此工作流程的内容,例如 this (jeffkreefmeijer.com) 和 this (vimeo.com),如果您想深入了解工作流程背后的方法和推理。这种类型的工作流程可以立即为您带来一些明显的好处:

  • 您有一个明显的“发布”分支(即 master )。这解决了您对 merge 策略的犹豫。
  • 整个工作流程都是基于获取 features merge master ,通过release candidate分支 - 相关测试的插入在概念上很容易。

所以:

The part I am confused about is, when I merge U4 into M2, do I have to branch again or can I just continue working of U4 to commit U5, U6, etc...?

假设您正在使用类似于 Nvie Git Flow 的“双分支”模型,则类似以下的内容可以工作:

M    
| \
|  U // Branch Unstable off Master to begin with. 
|  |
|  U1 // Finish commit series between U and U1; commit to Master
| /|
M1 |
|  U2 // Finish commit series between U1 and U2; commit to Master
| /|
M2 |

-etc-

你的开发分支,我称之为 unstable跟随问题,分支 master (因为您对已发布的代码进行了进一步开发;您已发布的代码,即“好的”代码,位于 master 中)。

之后,master不会回滚到 development 。原因很简单; master是你的“好”代码所在的地方。您不应该直接编辑此代码。 (顺便说一句,master 是一个很好的标记位置)。

异常(exception)情况是错误修复;这取决于您对 Git Flow 模型的遵循程度。但是,如果错误修复很紧急,您可能希望在提交 x 时进行错误修复。 (坏掉的),不提交x+nD ,其中D是开发 promise 。不过,一旦修复了代码,您确实希望将错误修复放回到 development 上。代码;否则你只会产生重新损坏的代码。
然而,错误修复等可能与您无关;一个两分支模型(例如您所绘制的模型)对于您的项目来说可能就足够了。 :)

关于多个单元测试套件上下文中的 Git 工作流程,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9552598/

相关文章:

node.js - 由于文件名太长,Git Extensions 正在崩溃。我该如何解决这个问题?

git - 修改后的文件出现在 Git 中但没有更新的问题?

git - 如何从别人的 repo 中 pull 出远程分支

git - Gerrit - 当前分支和远程分支存在分歧

gitk 给出 "argument list too long"错误

git - 我可以在 git 中 merge 文件吗?

linux - "git push"即使设置了本地用户名,也使用全局用户名更新远程

git - 如何处理共享代码中的密码

只有在成功 stash 之前,Git才会藏起来

git - 当你是 git 的原始仓库时,你如何进行本地 pull ?