如何評價用 Github issue 寫博客？

01-02

吶。玉伯、拔赤都這樣。

兩年前的一些思考：博客是什麼 · Issue #123 · lifesinger/lifesinger.github.com · GitHub

博客是什麼

我最初的博客，是在天涯上，後來歷經 WordPress、自主建站、Evernote、新浪博客等，直到去年，發現 GitHub 天然是個博客系統，於是安定了下來。

用 GitHub 的 Issues 來當博客，不是為了標新立異，而是因為懶，以及需求不多。

博客是什麼？對我來說， 博客的本質是記錄，是與自己、他人的內心對話。其他都是圍繞著記錄和對話展開。

記錄由來已久。傳統的紙筆，是記錄，是與自己的對話。有了電腦，TextEditor、Office 等軟體，WordPress 等 Web 應用，很大一部分功能都是幫助用戶記錄。GitHub Issues 天然支持程序員最愛的 Markdown 格式，用來記錄，很舒服。記錄的方式會越來越便捷，比如 Evernote，致力於成為人類第二大腦，除了文本，還能比較方便的記錄音頻、視頻、圖片等格式。所有這一切，都圍繞著記錄在前行。說不定哪一天，會有一款像 Google Glass 一樣的 XXX Hat，往頭上一戴，想寫博客時，冥想下就行。

對話是記錄的延伸。Facebook、微博能火起來，是因為人都有交流的基本需求。人是社群動物，內心都渴求著互動。通過博客，能把個人記錄公開給所有人，來訪者可以閱讀到作者的心。無論是線下、還是 IRC、WordPress、微博、QQ 等等，都是各種對話。GitHub 的評論功能，也是對話。對程序員來說，GitHub Issues 恰巧能很方便地進行代碼交流，對於如此懶的我來說，最是喜歡。

有了記錄，未必能產生對話。 產生對話，需要傳播，需要消息機制。傳統紙筆，對話很難產生。有了互聯網，通過 RSS 技術，讓傳播變得簡單。Google Reader 的背後，有著多少渴望交流的心。但是，當越來越多的用戶，通過 Facebook、微博等平台直接傳播和被傳播時，RSS 就沒什麼必要了。最近 Google Reader 的下線計劃，是必然，只是有點突然，讓很多用戶在感情上難以接受。

對於傳播，個人覺得，目前 Facebook、微博等形態，也很可能遲早像 RSS 一樣成為歷史或小眾。微信的核心是 I/O 系統，把控住的是傳播環節。可以搬個小凳子，坐下來靜觀互聯網的風雲變幻。對於傳播，微信也未必代表未來，可敬的是探索嘗試。

回到博客，GitHub 可以 Watch，還可以針對單條 Issue 進行 Watch / Unwatch. 這功能在很多成熟的博客系統里都還沒有呢。如果你是 GitHub 重度用戶，就會感受到 Watch 的方便和靈活性，至少不比 RSS 差。

對我來說， 博客就三個關鍵詞：記錄、傳播、對話。能滿足這三個需求的系統，就是博客。

GitHub 在這三點上做得很不錯，特別是對程序員來說。因此我拿它開博了，你不妨也來試試。

小結

一個產品是什麼，不取決於產出方的預設，而取決於使用者的用法。 比如微博可以是背單詞軟體、Facebook 則可以是遊戲中心…… 互聯網只是剪刀、石頭、布，想出什麼，由心定。

（完）

有這麼幾個原因，簡單分享一下，僅供參考，不具有普遍性：

1. 入行之後折騰是一個過程，從最開始折騰皮膚，折騰布局，各種換皮膚，一天換一套看著不舒服，

最後才明白，內容是王道，so，issues恰好是一個這樣的地方。

2. 國內的博客太不看好，說不定那天就掛了，博客園沒記錯，首頁貌似三四年沒換過了吧，csdn改過一次版，但貌似也沒抓住爆點，51cto等的過於小眾，issues就是做個備份，另外GitBook 路 Write Publish Books也不錯，可以試試，就是速度略慢，Cmd Markdown 編輯閱讀器，國內的這個產品還是不錯的。現在基本的流程是在cmd上寫，然後到處發，保持內容的多平台發布，真不容易。這是曾經的一篇文章：2015年閱讀書籍分享[上]

3. 就像玉伯大牛說的，方便，懶，皮膚功能太多，折騰時間太久，最後就是一篇文章，技術文章，內容，seo什麼的，都是表象，內容持久的保存才是王道，n年後回味起那些衝動的歲月，淚濕衣衫，感動常在。以前看玉伯大牛wordpress那麼多文章說不見就不見了，可惜啊。現在不怕了，天天看issues夠了。PS：我是看玉伯大牛這樣干，跟風的。準備做未來的博客內容發布。

4. 沒有廣告，沒有多餘的雜質，這才是傳播的最佳途徑，就是不知道以後會不會有。

我的博客貼一下：豪情 - 博客園

issues : Issues · jikeytang/jikeytang.github.io · GitHub

5. 也曾經試過hexo感覺還是流程略複雜，發布文章步驟過於繁瑣，有興趣的可以試試。

6. github做一個帶有版本控制的眾人內容發布渠道挺好，無論是個人內容發布，還是代碼比賽什麼的。正如我在項目裡邊說的：你不在是一個閱讀者，更是一個項目參與者內容創造者，歡迎fork之後pull。

這是我們群內的組織，

JS高級前端開發 · GitHub

總的組織目錄

jsfront/qa · GitHub

群內知識問題代碼比賽等

jsfront/month · GitHub

前端知識月刊

jsfront/src · GitHub

常用公共代碼

src/qq.md at master · jsfront/src · GitHub

我們QQ群規

jsfront/toucher · GitHub

群內管理：小劇客棧_劇中人的個人博客網頁設計師博客前端工程師互動設計學習者輕量的手勢類庫

這樣高質量的群有興趣加一下：327388215，禁止閑聊，禁止發無意義的大表情gif，非喜勿進。

很好啊，很適合程序員：免費，markdown，代碼高亮，標籤系統，評論系統（而且能留言的幾乎一定是程序員，某種程度上自動免垃圾留言）

缺點：沒法自定義樣式、域名、沒法加社交分享按鈕，沒法嵌入自定義 html 內容。對於對設計有追求、喜歡 show demo 的人來說，還是比較受限制的。

其實Github Issues除了blogging 還有一種更好玩的玩法叫AMA(Ask me anything)，是sindresorhus神等開了個好頭，可見如下鏈接：

Issues · sindresorhus/ama · GitHub

其中不乏一些很有趣的回答，諸如：

1. How many cats do you have? · Issue #2 · sindresorhus/ama · GitHub 關於寵物

2. Do you have a day job? · Issue #14 · sindresorhus/ama · GitHub 關於工作

3. What do you think about TypeScript and Flow? · Issue #15 · sindresorhus/ama · GitHub 關於代碼

4. One-line node modules · Issue #10 · sindresorhus/ama · GitHub 這個問題爭論得比較多，很多社區大神也都紛紛留言

5. When would I meet you? · Issue #9 · sindresorhus/ama · GitHub 大神與大神直接在Github上約起面基

6. How much do you sleep? · Issue #52 · sindresorhus/ama · GitHub 關於睡眠

其實簡單地說，就是新建一個倉庫，然後別人可以在issues裡面提問，作者進行選擇性回答，如果其他人有同樣的問題，可以直接搜索到該作者的答案。

關於AMA，其實源自於redit社區的AMA頻道：Ask Me Anything

另外，sindresorhus神收集了一些社區內比較厲害的Github用戶的AMA（也就是AMAs了：sindresorhus/amas · GitHub）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

最後附上我自己的吧：yorkie/ama · GitHub 目前還米有人來提問 666

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

一是偷懶，懶得用github pages，懶得為靜態博客加評論功能。

二是如果github粉絲多的話，這樣流量不錯

想要乾貨的直接看最後。

從大學的時候開始寫一些技術博客，經歷了一系列痛苦的切換：WordPress-&>點點-&>github pages-&>github issues。

一開始用WordPress的時候確實是想要自己折騰一個炫酷的站點，不到越到後面目的越單純：就是為了想要有一個技術圈子裡面都能看到，都能交流的地方方便的分享和記錄自己的想法。

然而繞了一大圈並沒有找到這麼一個地方，之前的WordPress和點點這樣的地方再GoogleReader還存在的時候還行，當時大部分人也都有用GoogleReader訂閱的習慣，這樣要是能夠積累一些訂閱也行。但是GoogleReader消失之後就感覺RSS好像不這麼靠譜了，於是就尋找出路。

最後目光移到Github上，Github可以說是全世界程序員的交友網站了，用Markdown的編輯器也很好用。要是Github本身就有類似CSDN這樣的博客功能那倒也是完美，然而並沒有。所以永github pages或者issues來寫，然而這沒有解決一個關鍵性的問題，就是有更新的時候收不到通知（watch可以收到更新通知，但是也會收到很多噪音），也沒有一個搜索或者是集合的頁面。大神們依靠微博或者其他情況下的傳播能力可以擴散他們的新文章，但是對於大部分更新來說是很少有人能夠看到的，所以並無法形成一個交流圈。

所以用Github的Issues來寫文章確實很方便，但是這並不是一個博客社區也沒有RSS這樣的訂閱，使得信息流通不順暢，並不完美。

所以我自己寫了一個小工具自動收集github上的博客，並定期去抓去更新：yutingzhao1991/github-blogs · GitHub 。

沒錯，我其實是來安利的：D

您還在為收不到Github上大神的Issues更新而苦惱嗎？或者你還在為watch博客之後收到的一大堆噪音而煩惱嗎？趕快watch yutingzhao1991/github-blogs · GitHub 吧，一次watch，永遠省心，更新不錯過。

我覺得省心，方便，不怕丟數據。

於是……自己寫了一個github issue blog generator。

GITHUB：cogons/issvue

DEMO：issvue

這個沒什麼問題吧，又不會影響別人。

我還把 git 當網盤用呢。

歡迎使用iBlog：iBlog：基於Gracejs及github issues的全功能博客方案 - 知乎專欄

入行以後，一路使用的技術博客分別是，csdn, cnblogs, jekyll, hexo, github repo, github issue，evernote, onenote, 有道雲筆記，黃易lofter，本地markdown。

至今在用的是github repo(配合代碼寫README.md)。

開始搞也是找各種主題，模板，皮膚。到最後發現，主題，模板，皮膚什麼的都是浪費精力，本來時間就少，把精力放在內容本身才是正道。

不用csdn和cnblogs的原因也是因為國內服務指不定哪天就掛了，這倆難兄難弟好像也沒有提供什麼博客備份服務，寫作也不支持markdown，尤其是code。手動空格排版簡直要瘋，而且不夠國(gao)際(bi)性(ge)。

jekyll和hexo這倆，首先，前期需要把框架搭好，然後，每次發布都要build，折騰了一陣子，對於我這種懶人還是覺得好累，好久沒更新了。

各種雲筆記呢，也是對代碼的高亮和格式化支持的不太好，或許它們本來就不是幹這種事情的，而且也擔心筆記丟失，所見即所得的粘貼並不是我想要的，粘的字體一行大，一行小的，我要統一的排版好伐。

技術型的博客，markdown是首選。內容是王道。內容精彩的，界面再丑都有人看，內容不行，就是套上黃金皮膚也沒人看。天朝需要的是乾貨，不是花瓶和空談。

就像大神說的，gayhub issue, 支持markdown，有社會化評論系統，沒有廣告——，界面簡潔但不簡單，但只能close不能delete，而且無法clone到本地（備份），難道要用github api去拉數據備份么- -

感覺怪怪的

雖然http://github.io不好用

但issues發博文是個什麼鬼？

人家還能做bug report嗎？

我用的是github pages，個人覺得很好。

和issue相比，優點是：

可以本地編寫、保存、發布管理等。
可以定製一些功能。
也可以從搜索引擎獲得流量。
本地也有備份，轉移方便，不怕github出現外星人入侵等問題。

issue的優點是簡單，直接可以用。還有就是在github生態圈內，獲得github裡面的流量吧。

無法限制別人發issue. 像玉伯的博客一樣, 偶爾會有人跑來也發一篇

不支持MathJax，可惜啊

不錯，挺好的。

我覺得不太好，以後轉移會不會有些麻煩，當然大牛們都會自己寫個工具啥的就搞定了，個人有條件還是買個vps，用wp吧，我用的是jekyll 搭建在github上了，以後買了vps，想轉移也是很簡單的，jekyll編譯完就是靜態頁面了