在分布式 VCS 中表示“问题”答案

【问题标题】：Representing "issues" in a distributed VCS在分布式 VCS 中表示“问题”
【发布时间】：2015-11-27 18:18:40
【问题描述】：

我厌倦了那些只能在线或通过电子邮件使用的问题跟踪系统，所以我一直在寻找可以复制和合并的数据库中的问题跟踪（这样它就可以离线使用） )。

为了让我的生活更轻松，我想我应该使用这样的数据库重用现有工具，于是我想到了 Git。但要使其正常工作，重要的是“合并”不要产生太多冲突，即明智地使用 Git 内置的合并分支算法。

到目前为止，我认为不应将给定问题中的各种消息保存在文件中（将它们全部保存在单个文件中会导致该文件中的冲突，而将它们保存在单独的文件中会导致困难保持它们有序）但应该存储在提交消息中，因此不会因为这些消息而发生冲突，git log <issue-dir> 自然会以正确的顺序向我显示消息。

但现在的问题是我需要确保提交消息与正确的“问题目录”相关联（我保留其余数据的位置，即主要是问题的状态）。为此，我需要确保提交修改了该目录中的某些文件，但如果新消息不影响问题的状态，则可能没有任何文件需要更改，所以我必须人为地修改文件，这会带来引入冲突的风险。知道如何告诉 Git 一个“空提交”应该与一个特定的子目录相关联吗？

【问题讨论】：

版本控制和问题跟踪通常是两个不同的东西（尽管有一个与 VCS 集成的错误跟踪器并非闻所未闻）。您是否看过像 BitBucket 这样的东西，它同时具有问题跟踪和 VCS，并且很容易将问题分配给提交？
我没有使用 Git 作为版本控制系统，我只是在内部使用它作为“可复制和可合并的数据库引擎”来跟踪问题。 IE。我将问题存储在 Git 中，但这些问题可能与任何事情有关（例如，存储在其他 Git 存储库中的内容，但不一定）。
您可能想要检查化石 scm 中内置的票务：fossil-scm.org/index.html/help?cmd=ticket fossil-scm.org/index.html/doc/trunk/www/bugtheory.wiki。我自己没用过，不过他们好像有一些经验。

标签： git issue-tracking

【解决方案1】：

在您的版本控制中可以使用几个错误跟踪器；到处都是虫子是我想到的。使用 Bugs Everywhere，您可以将错误报告与代码放在同一个存储库中。每个错误报告都是一个单独的文件，通常使用 be 命令行程序进行编辑。这与您已经在存储库中进行的分支非常自然地工作，因为您可以签出分支并查看当时所有错误的状态。

将错误报告存储在提交消息中似乎不太合适。如何更新错误？如果不使后续的每个提交失效，您就无法更新提交消息。

我认为您无法防止与您的设计发生合并冲突；在推送之前，您必须强制检测到合并冲突的人将其更改重新定位到错误。

【讨论】：

我的存储库仅包含错误跟踪信息，没有其他内容。实际上，通过将消息保留为提交消息，我使更新消息成为不可能，但并非不可能更新错误（错误的描述由一系列消息组成，每个消息对应于一个提交）。由于合并冲突仅来自文件操作，因此它们不能来自提交消息中存储的消息。当然，我还是需要存储文件（主要是为了跟踪bug的状态），所以还是有可能发生冲突的。
合并冲突也可能来自非文件操作。如果我克隆了您的存储库，然后我们都向同一个错误添加了评论，那么当我将评论推送回来时，将会出现合并冲突。我想对于 cmets 来说这并不重要，因为您可以代表用户重新设置基准； cmets 的顺序并不重要。另一方面，如果我们都更改了一些关于 bug 的元数据，那么自动变基可能会非常令人惊讶。 BE 通过将所有内容放入文件（包括 cmets）来解决此问题；用户在合并源文件的同时合并。
不，这不是合并冲突，这只是合并：即确实推送会失败，因为它不是“快进”，所以我必须合并其他更改（即较早的评论），但该合并不会产生任何冲突；之后我可以推动。不需要变基。

【解决方案2】：

好的，除了添加一些对我来说太难看的虚拟文件之外，我没有找到一种干净的方法将空提交的消息与特定目录链接。

但我最终解决了一个稍微不同的问题：我没有为每个 bug 设置一个单独的目录，而是将每个 bug 放在自己的分支中。这样，无需执行任何操作来将提交消息与特定错误匹配。此外，这避免了人为地将来自不同 bug 的提交消息交错，并使得git merge bug 成为可能，或者在不同的 bug 数据库之间共享一些 bug 子集。

如果有兴趣，我把我的代码放在https://gitlab.com/monnier/bugit

【讨论】：