Gitbugs
Gitbug 是你在完成作业（实验、家庭作业、项目）时获取调试帮助的方式。提交 Gitbug 很简单，只需在 Ed 上创建一个私密帖子，按照指定模板填写内容，然后等待回复即可。提交 Gitbug 后，所有工作人员都能看到，我们会克隆你的 GitHub 仓库到自己的电脑上，查找 bug，并提示/解释你应该检查的地方。我们会尽量在 24 小时内回复。但在截止日期临近时，由于请求量巨大，请大家耐心等待。
什么情况下应该提交 Gitbug
Gitbug 应该是你的最后手段。前提是你已经尝试过调试代码，但仍然没有找到 bug。例如，如果你在完成项目中的某个方法时，未能通过提供的测试或评分测试，请不要立即提交 Gitbug！培养调试技能是本课程的重要组成部分，所以我们希望你能自己解决遇到的 bug。另一方面，我们也不希望你被一个 bug 卡住太久，所以才有了 Gitbug 这种方式来帮你解决问题。我们相信你能判断自己是否已经尽力寻找 bug。但请注意，如果明显看出你没有尝试调试代码，我们将拒绝你的 Gitbug 请求。
如何提交 Gitbug
为了方便我们更好地组织和处理你的请求，并确保你的 Gitbug 不会被拒绝，请务必按照以下步骤操作：
- 选择左上角的大蓝色“New Thread”按钮
- 选择“Question”作为你的帖子类型
- 为你的 Gitbug 帖子提供一个有用的标题，例如：“Project 1: Array upsizing works, but downsizing throws ArrayIndexOutOfBoundException errors”
- 选择 'Gitbug' 作为 Category，并选择对应作业的名称作为 Subcategory
- 在 Ed 上选择 'Gitbug' 类别后，应该会出现一个问题模板，其中会询问一些重要信息，以便我们更好地调试你的代码。如果你没有看到模板，那说明你可能没有正确执行第 2 步。它应该看起来像下面的屏幕截图。
- 请用完整的句子回答问题。如果问题要求你执行某些操作，请务必完成（例如，确保你已经将代码上传到 GitHub）。对于解释不清楚的 Gitbug，我们将直接拒绝。
- 确保你的帖子是私有的
- 发布你的 Gitbug！
请务必准确填写 Gitbug 模板，并认真对待。否则，我们将无法获取足够的信息来帮助你解决问题。对于质量不高的 Gitbug，我们将不予处理，直接拒绝。 建议你花 5-10 分钟来创建 Gitbug，以保证其质量。你的 Gitbug 质量越高，我们就能越快地帮你解决问题，并给出更精准的解答，因为我们能从中了解到你犯了哪些错误或存在哪些误解。 截图基本不可能让你的 Gitbug 变得更好，所以除非你真的觉得有用，否则就别加截图了。 记住，我们拉取你的 GitHub 仓库就能看到你的代码，所以没必要截 IntelliJ 之类的东西截图。 如果你觉得某个错误信息对定位bug很重要，请把它复制粘贴到帖子里面，方便我们搜索。
最重要的是，你要清楚地描述 bug 是什么，以及你目前为止都尝试了哪些方法来解决它。 这是一个 Omar 做得不好的例子：
注意看，Omar 根本没好好回答问题。 他应该在他的回复里写清楚哪个测试没通过（比如测试编号），最好也附上错误信息。 而且很明显，Omar 根本没尝试调试，因为他说他只是看了看代码。 也可能他尝试过调试，但是没写出来。就算他觉得调试没啥用，也应该写上，因为这些信息能帮助我们更好地理解情况，也能节省助教很多时间。 Omar 抱歉了，这个 Gitbug 只能被拒了。
现在我们来看看一个好的 Gitbug 应该是什么样的：
Omar 在这里做得很好！ 有一个明确的测试表明他失败了，他甚至为我们提供了错误消息。 而且有充分的证据表明他尝试调试过代码，甚至还写出了自己的假设以及尝试过的方法。 Omar 还提供了他设置断点的具体代码行，以及调试时观察到的现象。 这样既节省了助教的时间，Omar 也能得到非常明确的 bug 反馈，因为他的问题问得很具体。 干得好，Omar！
提交 Gitbug 之后，耐心等待就好，同时可以继续做其他的事情。
另外，如果你提交了 Gitbug，但在我们回复之前自己解决了，请在帖子下面留言说明 bug 已经解决。 如果我们 clone 你的代码，发现你已经解决了 bug 但没有更新 Gitbug 帖子，那么你以后的 Gitbug 我们就不处理了。
一旦你的 Gitbug 得到了解答，就不要再回复了。 我们不会在 Gitbug 上进行来回讨论。 如果你还有其他 bug，请提交一个新的 Gitbug。 除非你想说“谢谢”之类的，否则就不要回复了 :)