Open zexixing opened 5 years ago
shift
+/
查看快捷键
- 通过 GitHub Issues 收集需求 有什么需求就直接给自己的 repo 建一个 issue 作为 Story Card,了却这个需求的最终形态就是 close 掉这个 Issue;
- issue 和 issue 之间是可以通过 # 相互连接,甚至可以跨仓库;
- 通过 #! 符号是可以在 comments 里面直接新建一个 issue;
- 新建一个 Milestone 来制定计划,也就是决定在一个 Iteration 里面你需要完成哪些 issues;
- 一般我会在月初做计划的时候给自己准备专门的时间来做 Elaboration,把 Backlog 里面的卡拖到 Rethink/Plan 这一列,经过分析和详细输出 TODOs 以及所对应的估点 points 之后便可以将其拖到 Ready For Todo 了,一般我给自己估的点数就是完成这件事情所需要的时间,一小时即对应一个 point。这样你就可以愉快的选择 Filter Issues by Milestone 专注于当前 Iteration,专注于 In Progress 这一列所要做的事情,并且垂涎于 Ready For Todo 里面将要做的事情,每次做完还可以放到 Review/SignOff,在里面写写对这件事情的总结和感想什么的,每次挪卡都充满了敏捷的仪式感;
- GitHub 在 issues 里面直接集成了 Markdown 的 TODO 语法,甚至于可以在渲染过后直接拖动某个 item 进行排序,而且可以在前面的勾选项中直接打勾;
- 在回顾记录的时候也能够进行总结分析,从而在下一次的计划当中更精确地预估时间(点数)
- 可以通过输入井号(#)+issue编号来引用issues。如果你想包含其他仓库的issues,你可以在前面加上仓库的名字,比如像这样:
kneath/example-project#42
- 像撰写论文开题报告这样,需要数小时至数天完成的任务,适合创建单独的 issue。对于长期和庞大的任务,则适合分解成多个部分,为每一块创建 issue 之后,再用后文提及的 project 工具统一管理;
- label 是筛选任务的必备神器,强烈推荐为每个 issue 配置;
- 只有一楼的复选框会以进度条的形式显示在 issue 面板下,所以请记得把所有的检查点都挪到一楼;
- 通常,伴随着任务的新进展,执行记录一层层堆叠在帖子下方;
- project 面板允许我们自由地添加、删除和拖拽“列”,以及列中的 issue,issue 从左到右划过整个流水线,完成它的生命周期,issue 在列中的上下位置代表了其优先级;
- 其中 Blocked 就是用来记录和整理依赖关系的;
- milestone 和 label 一样,在 issue 面板下创建和编辑。每个 milestone 都有固定的期限,半个月或者一个月是合理的长度。我们的目标是,每个标记了 milestone 的任务,都应该在这个期限结束前关闭。
- milestone中的issue清理:尚未开始的任务,也许干脆取消更好。已有进展的任务,要不要考虑中止呢?实在无法割舍的,就不得不转移到下个 milestone 了。重复几次清理的过程,就会对自己的执行力有比较透彻的了解,有助于挖掘生产力的潜能。
- 在 Github 上编辑代码同时创建分支
- 粘贴图像
- 格式化代码
- 使用魔术词在 PR 中关闭 issue
- 链接到 comment
- 链接到代码
- 像使用命令行一样使用 GitHub URL
- 在 issue 中创建 list
- GitHub 上的 project board
- GitHub WiKi
- Github pages
- 把 GitHub 当 CMS 用
改github.com/
为github.githistory.xyz/
直观查看历史修改
typora