2

我是一名研究生，我的主要研究领域是软件模拟。我有一些用于生成结果的 C++ 代码，但我最大的问题是，为了争取可重复性，我想在我的二进制文件中保存足够的元数据，以便我可以返回生成该二进制文件的确切源代码（主要是看看我发现的某些错误是否使我之前生成的某些结果无效）。

换句话说，当我生成一组输出文件时，我希望二进制文件同时转储当前版本的 git commit 以及任何未完成的更改。这将允许我（理论上）检查该提交，应用保存的补丁，并返回创建二进制文件的确切源代码。

我知道我可以通过手动保存信息或其他东西来做到这一点，但为了确保完全一致，我想直接将信息烘焙到二进制文件中，这样每个二进制文件都可以追溯到它的确切来源。

我熟悉在 makefile 中设置 #define 标志以存储诸如 git commit SHA1 之类的操作，但我认为我需要某种更聪明的方法将整个 git diff 作为字符串存储在二进制文件中。

所以我有几个问题：

  1. 这是一个可怕的想法吗？是否有更好的方法可以将二进制文件追溯到源代码？
  2. 实现这一目标的最佳方法是什么？

谢谢。

编辑：我想我没有明确说明我要保存差异的原因是为了捕获当前 HEAD 之上的任何未提交的更改。我可以存储哈希，但如果我错误地使用了包含一些未提交内容的二进制文件，那么我将无法取回正确的源。

4

4 回答 4

3

在代码中保存 git “id” 编号（哈希）并不是一个坏主意。保存差异是毫无意义的，因为哈希（以及它来自哪个分支）应该允许您返回原始代码。

只需确保您的构建和测试系统已设置，这样您就不能使用尚未提交的东西，这样您就不能在构建中进行一些未提交的随机更改。

编辑：在您的机器上进行测试，在项目的本地副本中进行测试，与使用检查所有内容的测试套件进行测试之间存在差异 - 这是您用来确认一切正常的方法，对吧？请注意，在其他人获得该代码的副本之前，您测试什么并不重要 - 在提交之前不要让其他人看到您的代码，并且不要允许保存测试的完整测试套件如果您尚未提交所有内容，则发布说明等的结果将运行 [或者更好的是，有一个单独的目录/机器，它只能从中央存储库获取新代码 - 如果您这样做，那么您不可能使用未提交的代码。

我曾参与过几个以这种方式工作的项目——您可以使用未提交的代码在本地目录中构建，但所有“官方构建”都是在不同的机器上完成的，代码总是直接来自 repo，没有本地更改。

如果您没有两台机器，可能有一个“充当独立机器”的虚拟机，或者仅使用用于“官方测试”的第二个目录[或不同的用户？]。

实际上，您可以简单地检查是否有一些差异，然后与您的“这是哈希”一起，如果有任何差异，请添加额外的“-with-uncommitted-changes”或类似的东西。您可以使用git diff --exit-code为“无更改”或“更改”为您提供 0 或 1 退出代码。

于 2013-08-08T17:02:27.797 回答
2

我认为最好的答案是“不要那样做”。如果您想要可重复的构建，请仅针对已提交的更改进行构建，而不是使用肮脏的工作目录。如果你需要，在一个分支上提交实验性的东西，如果它不起作用，你可以扔掉，或者可能把它留在你的存储库中（例如，对于你重复构建的用例），但是放弃那个分支并工作在另一个新分支上。如果您只有特定点想要返回到构建，请考虑在这些特定提交上放置适当的标签。

于 2013-08-08T22:05:45.367 回答
2
  1. 你描述了两个想法：只有一个是可怕的。只需保存哈希即可。您可以从中恢复所有其他元数据，包括差异
  2. 只需存储哈希（参见1） - 您声明已经知道如何执行此操作
于 2013-08-08T17:06:51.177 回答
2

从技术角度来看，存储 git SHA1 id 对于您想要实现的目标来说是公平的。

未提交的更改？如果存在，请将您的构建过程设置为失败。
如果构建工程太难/太多工作，只需表现出更多的纪律。:)

编辑：
通过 shellscript 构建。在构建更改之前检查，git diff --exit-code可能会有所帮助。

编辑2：如果您必须调试许多代码修订版，
git help bisect可以派上用场。

于 2013-08-08T20:36:28.153 回答