本文译自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的容器。可以将Issue进行很好的归纳整理，包括某些特性、项目声明周期归档等。
· 一个负责人（assignee）有责任随时处理Issue。
· 评论(Comments)允许任何有权使用代码仓的人提供反馈。
Milestones, Labels, and Assignee
一旦你收集了一定数量的Issue，你也许会发现很难找到你关心的问题。通过Milestones,labels,assignees这几个属性可以很好的过滤和聚集Issue。
你可以通过点击他们右侧侧边栏中相对应的齿轮来改变或者增加milestone, an assignee, labels。
如果你没有编辑的按钮，那说明你不被允许去修改这些Issue。你可以去请求repository的拥有者将你添加为协作者。
Milestones
Milestsones是一组Issues，一个milestone对应了该项目的特性或者时间段。人们在软件开发的不同时期用不同的方式组织Milestones。一些GitHub上面的milestones例子：
· 测试版本（Beta Launch）——必须要在发布项目的Beta版本之前修复文件中的所有bugs。这是确保你没有遗漏任何事情的很好方法。
· October Sprint——列出的Issues表示将在十月进行解决。这种方式能够在有很多事情需要忙碌时，集中精力解决一部分事情。
· 重构（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，以便向他们发送通知。这个功能和推特的@功能很相似。
我们喜欢在Issue中使用 /cc（carbon copy的缩写）来包含别人：
在你知道具体应该提醒哪些用户时这个功能非常有用，但是大多数时候我们是跨团队合作的，并不十分确定谁能帮助我们。
@同样在GitHub的团队层面有用。如果你创建了一个叫browser-bugs的团队，在@acmeinc组织里，你可以用下面的方式引用这个组织：
References
通常情况下，Issues本身是依赖于其他Issues，或者他们至少相关，同时你想要将他们联系起来。你可以通过输入标签加上Issue的编号。
如果这个Issue是另外一个repository中的，至于要在编号前加上repository即可，如
kneath/example-project#42。
在提交中直接引用Issues是在GitHub中使用Issue的一个有趣的方式，即在提交的文本中要包含Issue的编号。
当提交合并到主干分支时，无论你的前缀是“修复中【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 section的界面非常相似，但是其对issue的展示方式非常不同：
· 所有你的和你参与协作的仓库（repository）的Issues。
· 提到你的Issues。
· 你创建的Issue。
如果你隶属于组织，那么每个人都有自己的Issues界面，这样可以将组织的所有问题进行分离。
Pulse
每个仓库（repository）下有一部分叫做Pulse——Pulse是过去一周（一天或三个月等）在仓库（repository）中发生的所有事情的快照。
当你离开仓库而不希望在看仓库（repository）时收到granulariy notification时，这是一个跟踪仓库变化的好方法。
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了。
·
