本文共 1998 字，大约阅读时间需要 6 分钟。

什么是 Issue？

• n. 发行，问题， 后果，流出，出口，争端
• vi. 发行，流出，造成……结果，传下
• vt. 使流出，放出，发行，发布，发给

在其它同类系统中，以 bug 为对应物进行追踪时， GitHub 使用了 Issue， 可见，有独特的软件工程思想包含在其中。

怎么整 任务/记要/追踪/…… ？

~

官方说明是能用来追踪:

• 想法
• 改进
• 任务
• 问题

而实际上远远不止……

因为 Issue 已经变成了 GitHub 中可能最复杂的单一功能：

• 参考：
• 每则 Issue 已经可以绑定不同维度上的描述：
  • Assignees -> 人力资源
  • Labels -> 分类标签
  • Projects -> 项目游道 -> Kanban
  • Milestone -> 里程碑 -> 时限
• 除此之外：
  • 正文/回复又支持相同的加强版 GFM，可以维基式的快速指向其它资源
  • 以及 Pick 扩展的 fb 情绪表述
  • 任何人都可以用最短的时间， 完成对应信息的态度表述
  • 是的， 相同的功能原先是出现在 commit-comment 中
  • 后来才追加到 Issue 中

使用 Issue 时，可能发现，这同时又是一个专题 Dashboard

• 不同于 https://github.com/orgs/[组织名]/dashboard
• 将一个组织中所有仓库相关的所有行为播放出来
• Issue 是将当前 Issue 相关的所有行为以严格的时间线进行了播报
• 包含：
  • 关闭
  • 重开
  • 引用
  • 引用 Issue 的关闭/重开
  • 引用 Issue 的任务进展
  • 指派/指派的变更
  • 绑定标签/标签的变更
  • 项目绑定/项目的变更
  • 里程碑/里程碑变更
  • 版本/版本变化
  • ……
• 简直将开发过程中所有有效活动都在一个界面中包含并追踪了

Issue 和谁用？

那问题就来了，Issue 这么强力的功能，应该在什么场景中用？

当然是尽可能的和任何人都能用起来：

• 用良好的事先约定， 将开发团队内部的 Issue 尽可能的规范化起来
  • 标准化的区分不同事务
  • 用不同模板来撰写和追踪 Issue
  • 以便推动项目的有效前进
• 用友好的约定， 开放合理仓库的 Issue 接收用户的反馈
  • 运用 BBS 时代版主的管理经验
  • 热情/及时/有力的管理 Issue 有效的记述/追踪/完成
• 基于私人规约， 在封闭仓库中：
  • 精细的记述一切
  • 一事一提案
  • 尽可能规范化 Issue 所有要素的使用
  • 以便通过 接口，可以自动化分析统计 Issue 代表的工程进展或是其它指标

简单的说：

• Issue 功能已经傻瓜化到任何人在任何场景都可以方便的用起来
  • 基于在手机端
  • 对的， 大家可能没有注意到技术强大如 GitHub 团队
  • 却从来没有推出过官方的移动版 GitHub app，为毛？
  • 实在是因为 web 页面本身就已经是完备的 GitHub app 了！
  • 用手机打开 GitHub 页面获得的排版和桌面从一开始就不相同
  • 就已经是响应式的，完全移动友好的界面和操作了……
• 所以， Issue 是否能有力的支持项目的推进
  • 从一开始就将压力转嫁给了主持团队一方
  • 可以说项目团队每个人都有 BBS 管理员一样的致高权限
  • 可以直接修改/删除每个 Issue 的正文以及回复
  • 所以，每个成员是平等的又都是事先要求有清晰的项目理解和管理思路的
• 同时，和 git 的分支成本一样
  • Issue 的开辟/增补/回复/关闭/寻回……
  • 等等操作也是那么的轻松
  • 以至根本不用太着意 Issue 本身
  • 随时可以打开一个 Issue 尝试表述
  • 感觉不对关闭就好

其它姿势？

~ 当然，随着使用者的增长，GitHub 的各种元素总是被挖掘出出乎意料的用途来，Issue 也一样

• 图书：
  • 不用仓库
  • 而是同样 md 友好的 Issue 进行技术图书的撰写
  • 自然的，每个 Issue 一个章节
  • 那么大家在 Issue 后的回复，也就变成了评注
  • 一个简化的 gitbook 系统就 run 起来了
• 菜谱：
  • 同上， 只是多多利用 GitHub 的图片功能
  • 多图杀猫的年代之后
  • 包含大量图片的菜谱用 Issue 来撰写和发布
  • 也是自然而然的了……
• 小说：
  • 连载小说的形式简直和 Issue 的形式天然契合的哪……
  • 通过 标签/项目/里程碑 的标定来区分：
    • 章
    • 卷
    • 部
    • 篇外
    • ……
    • 也是异常的方便
  • 而且，想整体下载又是那么的困难
  • 实在太吻合连载了……
• BBS：
  • 社区要是习惯 BBS 的交流方式
  • 那直接用 Issue 来进行
  • 也没有任何违和的体验呢……
• ……

提问

~ 是的，GitQ 不是单向灌输，双向交流才真诚

• GitHub-Issue 包含的功能中哪个你最喜欢？为什么？
• GitHub-Issue 的形式，还能拿来作什么？
• 如果你来增强 GitHub-Issue ，最想要的那个功能是什么？

欢迎大家来我的读者圈评论作答或提问交流 ~

转载地址：https://blog.csdn.net/zoomquiet/article/details/108729664 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！