问题报告

作为 Tuist 的用户，你可能会遇到 bug 或意外行为。如果遇到，我们鼓励你报告它们，以便我们能够修复。

GitHub issues 是我们的工单平台

问题应该在 GitHub 上作为 GitHub issues 报告，而不是在 Slack 或其他平台上。GitHub 更适合追踪和管理问题，更接近代码库，并允许我们追踪问题的进度。此外，它鼓励对问题进行长篇描述，迫使报告者思考问题并提供更多上下文。

上下文至关重要

没有足够上下文的问题将被视为不完整，作者将被要求提供额外的上下文。如果未提供，问题将被关闭。这样想：你提供的上下文越多，我们就越容易理解问题并修复它。所以如果你想让你的问题得到修复，请提供尽可能多的上下文。尝试回答以下问题：

• 你尝试做什么？
• 你的图谱是什么样的？
• 你使用的是哪个版本的 Tuist？
• 这是否阻塞了你？

我们还要求你提供一个最小的可复现项目。

可复现项目

什么是可复现项目？

可复现项目是一个用于演示问题的小型 Tuist 项目——通常这个问题是由 Tuist 中的 bug 引起的。你的可复现项目应该只包含清楚演示 bug 所需的最少功能。

为什么你应该创建可复现测试用例？

可复现项目让我们隔离问题的原因，这是修复问题的第一步！任何 bug 报告中最重要的部分是描述复现 bug 所需的确切步骤。

可复现项目是分享导致 bug 的特定环境的好方法。你的可复现项目是帮助想要帮助你的人的最好方式。

创建可复现项目的步骤

• 创建一个新的 git 仓库。
• 在仓库目录中使用 tuist init 初始化一个项目。
• 添加重新创建你看到的错误所需的代码。
• 发布代码（你的 GitHub 账户是发布的好地方），然后在创建 issue 时链接到它。

可复现项目的好处

• 更小的攻击面： 通过移除错误以外的所有内容，你不需要挖掘来找到 bug。
• 无需发布秘密代码： 你可能无法发布你的主站点（出于很多原因）。将其一小部分重新制作为可复现测试用例允许你公开演示问题而不暴露任何秘密代码。
• Bug 的证明： 有时 bug 是由你机器上某些设置组合引起的。可复现测试用例允许贡献者拉取你的构建并在他们自己的机器上测试。这有助于验证和缩小问题的原因。
• 帮助修复你的 bug： 如果其他人能复现你的问题，他们通常有很好的机会修复问题。如果不能首先复现 bug，几乎不可能修复它。