我很好奇人们在git中用于单元测试和内存测试标签的内容。
例如，我通过valgrind，drd和helgrind定期运行我的C ++代码。
我会强制标记 mem_ok ， drd_ok ， helgrind_ok 如果它们通过。
当然，缺点是，我将丢失所有历史标签。
我认为另一种方法是对它们进行编号（而不是使用强力），例如 mem_ok_1 ， mem_ok_2 ， mem_ok_3 等等。 ..也许我应该写一个脚本来编号我的标签？
开发人员目前在git中实现此类功能的目的是什么？
假设我有以下分支：
我正在考虑这种工作流程（M代表大师，U代表不稳定）
M1 -> U1 (branch off M1)
U2
U3
M2 <- U4 [merge]
U5
M3 <- U6 [merge]
在U2，U3和U5中，提交只是通过谷歌测试：我没有时间去valgrind，drd，helgrind。 在我确认所有测试（包括valgrind，drd，helgrind）通过后，我将U4和U6合并为M2和M3。
我感到困惑的部分是，当我将U4合并到M2时，我是否必须再次分支，或者我可以继续使用U4来提交U5，U6等......
换句话说，我只需要在这个工作流程的开头从硕士分支到开发一次，对吗？
答案 0 :(得分：2)
Git标签实际上并不是设计用于大量的提交。相反，我建议将valgrind等测试集成到您的工作流程中，而不是集成到您的分支中。如果您确信您的提交会愉快地编译，您可以自动运行您的测试，如果它们通过，请从development拉到passed-unit-test - 一个cron作业或类似的，如果时间运行测试是一个问题。
除非单元测试通过，否则您可以使用git hook禁止推送到passed-unit-test分支。
然后你有一个只包含已通过测试的代码的分支。这是一个更简洁的解决方案，然后逐步标记或标记。
编辑：
换句话说，我只需要在开始时使用此工作流从主服务器分支开发一次，对吗？
是。 development将转到 master，master仅 在开头被推入development >（如果适用，如果有错误修正 - 这可能与您无关）。
更长的解释和推理：我会使用基于Nvie Git Flow工作流程的工作流程。 （相关脚本位于here）。它是reasonably well used，并且有很多关于此工作流程的内容，例如this（jeffkreefmeijer.com）和this（vimeo.com），如果你想获得一个可靠的理解工作流程背后的方法和推理。这种类型的工作流程可以立即为您带来几个明显的好处：
master）。这解决了你对合并策略的犹豫。 features分支机构将master合并到 release candidate，并在相关测试中进行插入在概念上很容易。 所以：
我感到困惑的部分是，当我将U4合并到M2时，我是否必须再次分支，或者我可以继续使用U4来提交U5，U6等......？
假设你正在使用类似于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是您的“好”代码所在的位置。您不应该直接编辑此代码。 （另外，x是用于标记的伟大的位置）。
这个例外是错误修正;这取决于你遵循Git Flow模型的程度。但是，如果错误修复是紧急的，您可能希望在提交x+nD（已损坏的）上执行错误修复，而不是提交D，其中development是开发提交。但是，一旦修复了代码，就可以将错误修复程序放回到{{1}}代码中;否则你只会产生重新破解的代码
但是，错误修正等可能与您无关;一个双分支模型，比如你已经绘制出来的模型，对你的项目来说可能已经足够了。 ：）
答案 1 :(得分：0)
我的2美分：不应该使用标签，并且使用渐进式数字，你最终会弄得一团糟。
对于我们这里的问题，我只是使用一个钩子来强制执行测试，并且如果它们没有通过则拒绝在master（或者是你工作流中的任何东西）上合并。 （对我来说）这是一个相当公平的逻辑。