GitHub Issues 当成轻量需求池时,要先定标签
· 阅读需 2 分钟
GitHub Issues 一开始用起来很简单,谁发现问题谁就开一条,评论、补充截图、贴 commit,都很顺手。可只要项目稍微多一点需求,Issue 一多,列表就会迅速变成一锅粥。到了 2013 年我自己开始比较频繁地用它协作时,最明显的感受就是:Issue 系统如果没有最基础的标签约定,很快就会从“记录问题的地方”变成“堆问题的地方”。
GitHub Issues 一开始用起来很简单,谁发现问题谁就开一条,评论、补充截图、贴 commit,都很顺手。可只要项目稍微多一点需求,Issue 一多,列表就会迅速变成一锅粥。到了 2013 年我自己开始比较频繁地用它协作时,最明显的感受就是:Issue 系统如果没有最基础的标签约定,很快就会从“记录问题的地方”变成“堆问题的地方”。
很多人刚用 GitHub 时,会把它理解成一个线上代码仓库:能 push、能 clone、能看文件。但到 2013 年,越来越多人开始意识到,GitHub 真正方便的地方不只是托管代码,而是围绕项目的协作信息也能被放到一起。
2013 年如果开始认真写代码,GitHub 很容易成为你绕不过去的一个地方。大家从论坛、网盘、压缩包共享代码,慢慢转向更清晰的版本协作方式,Git 的价值也开始越来越明显。