近2周多的闲余时间，都用来阅读GitHub的官网文档，发现它的功能确实太全了，包含了从项目的组织搭建、代码编写、团队合作、项目测试、运行监测、以及后期的构建维护、项目迭代，并且每一步都可以看作当下的最优实践。配合详尽全面的文档，无愧"Build and ship software on a single, collaborative platform"的口号。下面是对阅读中的一些收获的记录。
1 md 的写作
markdown 格式是目前最方便写作和最方便阅读的文档格式，自己也已经使用多年，可是对于常用功能的理解并未深入，比如标题的不同级别代表什么？为什么个别文字使用``修饰、有的段落使用>修饰？如何快速设置字体的加粗和倾斜？对于一些较少使用的功能，总是临时通过搜索去解决，比如如何插入一个表格？如何插入脚注？如何插入图片？在思路被打断后，感觉很不舒服。
以上的问题，GitHub文档中的如何写作章节，进行了详细地讲解。我理解了``的作用是用于代码文字，>是段落引用，先选中文字，然后通过ctrl+b可以快速设置文字为粗体。再遇到不会使用的表格和脚注语法时，就直接去文档页面查找，效率就大大提升。
markdown的语法基本是通用的，可是对其的展示，不同的网站又有了一些特别的定制，比如不同等级的标题，使用不同的颜色。GitHub中也有不少特别的定制显示，比如 #0969DA 的#HEX形式可以展示对应的颜色，还有 ':shipit:' 可以显示对应的emoji表情。
2 git 的使用
git 是一个版本控制工具，能够很方便地记录和管理代码的变动，是程序开发者最基本的技能点之一。经常使用的界面工具如sourcetree和vscode等，隔离了日常对git 的直接操作。按照口口相传的规定，前面的开发管理，也跌跌撞撞地走了过来。当阅读分支管理相关的文章时，偶尔会遇到和自我实践的不同，心中一直有一个疑惑，哪种形式更符合项目的长期演进？
GitHubDoc的git使用章节，解答了我的疑惑。它以对开源项目的贡献代码的工作流为例，介绍了fork、branch、pull request、fetch、merge等的概念。让我看到一个开源项目中全世界不同各地的开发者是如何协作，共同推进项目长期演进的。而且对日常经常使用的几个命令，它还贴心的制作了git cheatsheet清单，方便日常的查找使用。多次使用下来，感到命令行很好使用，尤其是在远端服务器上面，这样统一的使用习惯，有效降低了跨端的成本。
3 codespaces的概念、配置和使用
codespaces是github为某个repository开放的沙盒环境，能够实现整个项目在远端的运行、调试，相当于github为个人在远端设置了一个专门运行该项目的服务器，个人可以实现网页在线编程。这种方式，很好地解决了我本地电脑内存不足的问题。它为每个人提供了15G的存储空间，对单独的项目来说，完全够用了。
代码空间，实现了前人把代码集中在远端管理，个人使用一个输入设备（键盘）和输出设备（显示器）就可以实现日常工作的设想。这得益于云技术的不断发展。技术进步的迭代，总是在某个时刻，以一个新产品的出现，让人感觉新时代已经来临，代码空间就是给了我这种感受。
4 command pallette 的设置
github内容众多，为了提高使用效率，它提供了快捷键的功能，方便用户快速打开某个功能。在按照文档设置快捷键时，一度找不到入口，最后发现它属于一个实验室(Feature preview)的功能，需要先打开该功能，才可以设置快捷键。
5 github的考试
阅读到最后，发现还有一个github的认证考试，参加需要缴费，然后通过后会自动将费用退回。这让我想到了阿里云的认证考试，原来专业的服务，可以做到如此程度。
还有很多其他零碎的细节，比如账户的配置、repository的模块配置、gist的使用、公共仓库archive的周期等，都是我原来忽略的细节。以前的使用都是左点点、右点点，然后就认为会用了。可多次使用后，会发现只有那简单的几个功能。而想要进一步了解时，却一直没有好的进步方法。现在我发现深入了解某个功能(技术)的方法就是公开的，那就是官方文档。耐心阅读一遍，远远胜过其他书籍和文章的介绍。
想想以前自己的很多经历，都是依靠原来的低级搜索的方式去查找，实在是太过低效。更难以接受的是低效下自己的心绪一直处于上升和落下的过山车状态。整个人的外在和内在都很差劲，自己竟然在这样的环境下生活如此之久，还一度好像适应了这样的生活。真是应了那句话，“最好按照自己想要的方式去活着，否则就会按照自己活着的方式去想着”。
去坚持使用基本的进步方法吧，长期主义地积累下，相信会越来越从容。