本文译自GitHub Guide主要为了科普一些GitHub上的基础知识，为和我一样不知道如何上手，不懂概念的人提供一些帮助。（本版本不是最终版，只是大概写了一下）

提问（Issue）是对项目进行任务跟踪、加强和找bug的最好方式。这种方式有一些和Email相似，但是他可以在整个群组中进行分享和讨论。大部分的软件项目都有某种bug追踪器。GitHub的跟踪器叫做Issue，对每个代码仓库（repository）都有单独的Issue。

例如，我们看一下例子Bootstrap’s Issues section：

GitHub的Issue追踪非常特殊，因为我们专注于协作、引用和拥有成熟的交流文本模式。GitHub上一个典型的Issue如下：
· 一个标题和简介来描述Issue的所有相关信息。
· 带颜色的标签（labels）帮助你归类和过滤你的Issue（就像Email的标签一样）
· 里程碑（milestone）就像Issue的容器。对于有特定特征或者项目的不同时期，milestone可以有很好的组织联系功能。
· 一个负责人（assignee）有责任随时处理Issue。
· 评论(Comments)允许任何有权使用代码仓的人提供反馈。

Milestones, Labels, and Assignee

一旦你收集了一定数量的Issue，你也许会发现很难找到你关心的问题。Milestones,labels,assignees是用来过滤和目录化Issue的很好特征。

你可以通过点击他们右侧侧边栏中相对应的齿轮来改变或者增加milestone, an assignee, labels。

如果你没有编辑的按钮，那说明你不被允许去修改这些Issue。你可以去请求repository的拥有者将你添加为协作者。

Milestones

Milestsones是项目、特征或者时间段对应的一组Issues。人们在软件开发的不同时期用不同的方式组织Milestones。一些GitHub上面的milestones例子：
· 测试版本（Beta Launch）——必须要在发布项目的Beta版本之前修复文件中的所有bugs。这是确保你没有遗漏任何事情的很好方法。
· October Sprint【？】——愿意解决的文件Issues要在十月（October【？】）解决。把很多相关的事情集中要做的有利于专注解决问题。
· 重构（redesign）——收集和重构文件相关的Issues。是一个收集下一步工作灵感的好方法。

Labels

Labels是组织各种类型的Issues的有效方法。Issues可以有任意多的labels，你也可以通过一个或者许多labels对Issue一次进行过滤。

Assignees

每一个Issue都有一个assignee——一个负责将问题推进的人。Assignees的选择如同milestones一样，通过每个Issue顶部的灰色条【？】。

Notifications, @mentions, and References

在Issues中使用@提醒或者参考，你可以提醒GitHub的其他用户&组织，实现跨Issues联系。这些方式提供了一个灵活的方式使正确的人有效参与，同时这些方式的学习和使用也非常简单。这种方式在GitHub上面各个领域都在使用——它们是文本格式化语言的一部分GitHub Flavored Markdown。

如果你想了解更多，点击Mastering Markdown。

Notifications

提醒（Notifications）是GitHub中让你随时了解Issues的方式。你可以用它们找到repositories中的新Issues，或者仅仅是了解有人需要你的解决方法来推进他的Issue。

有两种方式接受notifications：通过email或者通过web。你可以在设置确认你接收notifications的方式。如果你计划接收许多notifications，我们建议你同时使用email和web进行参与，用web进行浏览。

在这些设置下，只有在人们提到你的时候你才会收到emails，然后通过基于web的接口来随时浏览你感兴趣的repositories。

你可以进入你的[提醒列表] (https://github.com/notifications)。这个界面对于一次性浏览很多notifications和标记已读或勿扰（muted thread）非常友好。尝试通过键盘快捷键来加速你的工作——在页面中按下“？”来看哪些快捷键可用。

标记了勿扰的通知除非你再次被@不然它就不会再次出现在你的列表。这个策略极大地帮助你应对你不感兴趣的问题（或者你不熟悉的子系统问题）。如果你标记一个Issue为已读，这条Issue就会保持这个状态直到有人评论。

GitHub同步了email已读/未读的通知——如果你在Email端读了通知，那么在基于web的接口也会被记录为已读（如果你喜欢这个功能，确保你的email能够展示图片）。

@mentions

@mentions是我们在GitHub中Issues时引用其他的GitHub用户时使用。在Issue的描述或者评论中，包括另一个GitHub用户的@username，以便向他们发送通知。这个功能和推特的@功能很相似。

我们喜欢使用 /cc（carbon copy的缩写）来包含别人的Issue：

在你知道具体的用户时这个功能非常有用，但是大多数时候我们是跨团队合作的，并不十分确定谁能抱住我们。@同样在GitHub的团队层面有用。如果你创建了一个叫browser-bugs的团队，在@acmeinc组织里，你可以用下面的方式引用这个组织： 这个语句将把提醒分到送到每一个browser-bugs team。

References

通常情况下，Issues依赖于其他Issues，或者他们至少相关，同时你想要将他们联系起来。你可以通过输入标签加上Issue的编号。

如果这个Issue是另外一个repository中的，至于要在编号前加上repository即可，如kneath/example-project#42。

在评论中直接引用Issues是在GitHub中使用Issue的一个有趣的方式。在评论的文本中要包含Issue的编号。

当评论合并到主干（master【？】）时，无论你的前缀是“修复中【fixes？】”、“修复完成【fixed？】”、‘【Fix？】’、“关闭中【closes】”、“关闭【closed】”还是“【close】”，系统都会自动关闭Issue。

引用使得深度联系正在进行的工作与正在被跟踪的bug称为可能，同时是向项目中添加可见性的好方法。

Search

在搜索页顶端是一个搜索栏，允许你通过Issues进行搜索。

你可以用以下方式进行搜索：
· 关键词，比如，all issues mentioning the sidebar
·状态，比如，all issues mentioning the sidebar that are closed
·受托人（Assignee），比如，all issues mentioning the sidebar that were assigned to @mdo
我们在搜索Issue的帮助文档会向你展示一些其他的搜索方法：使用创建/更新日期、标签、作者、评论数、repository拥有者等。

Overviews & Reports

在Issues之外的部分，还有两个方式帮助你总结跨仓库（repository）的Issues的问题。

The Issue Dashboard

如果你在找一个界面可以列出许多项目和你有关的所有Issues，那么 Issues Dashboard是一个很好的工具。这个界面与Issues部分的界面非常相似，但是包含许多Issues：
· 所有你的和你参与协作的仓库（repository）的Issues。
· 提到你的Issues。
· 你创建的Issue。
如果你隶属于组织，那么每个人都有自己的Issues界面，为了分离组织内部的问题。

Pulse

每个仓库（repository）下的部分叫做Pulse——Pulse是过去一周（一天或三个月等）在仓库（repository）中发生的所有事情的快照。

当你离开仓库而不希望在看仓库（repository）时收到granulariy notification时，这是一个catch up仓库（repository）的好方法。

Other Uses for Issues

Issues是一个追踪所有事情的好方法——同样GitHub也是一个容易分享和协同合作解决Issues的好地方。以下是我们一些最爱：
· Bug tracker for your open source projects
· Request for recipes (maybe you have a good gluten-free pizza dough recipe?)

Fin

现在恭喜你自己——以上需要阅读的很多！Issues的管理对于任何一个开发者的处理中都是一个重要的工具。我想现在要做的就只有修复bug了。

·