有了 git hooks 其實已經解決了大部分的工作

這幾天一直在想，其實 hexo 已經超級方便了，反正可以開心的寫作，也可以輕鬆地維護控管版本

但是，總是覺得不是這麼順手，畢竟，好像每次寫完文章後，就讓他自動 deploy 到遠端服務上，當然是件很簡單的事情。不過，大部分時候，就是因為這麼簡單，所以根本忘記要 commit 甚至 push 上去

所以就開始胡思亂想啦，是不是應該用 CI continues integration 的方式，甚至可以 CD continues delivery 當然，有沒有達成這麼完美的目的倒是未必，更重要的概念，是可以盡量畢其功於一役

所以，可以考慮執行的方式有以下幾點：

• 寫個 script，在 deploy 之前，先 commit code

$ ./bin/deploy.sh

#... 要先做一大堆事情，如 git add 等等一大堆

$ git commit

• 先 commit code，然後再 deploy 相關的 code

# ... 先做一大堆事情

$ git commit

$ ./bin/deploy.sh

• 乾脆把這些事情丟到 jenkins 上面幫忙

以上幾點來看，第三點算是真的殺雞用牛刀了，不但要有一個 jenkins 的服務，還要寫一些 script，甚至想說從 A git repository 到 B (github.io ?) 這種動作，真的有違常理。所以用 jenkins 真的不太直覺方便

再來，先 commit 再 deploy，這部分來說，其實對於 hexo 來說，deploy 其實是包括了 generate -> deploy ，所以萬一 generate code 時，有發生任何錯誤，那也就是改壞了、有 bug 了。這樣的 commit 似乎也不好

所以，比較好的概念應該是類似於第一種。先 generate code，如果沒問題的話，就 commit，如果有問題，那就該啊～～

因此，應該考慮使用第一種方式，就是先 generate code，再 commit code 吧。不過（世上就是這麼多，不過…）這樣還是有點麻煩，畢竟正如同前面所提到的，如果要我打這麼多 command，那麼就一點也不符合懶的原則了

經過幾個小時偷玩 Jenkins 後，順便 Google 了一下，其實是可以考慮使用 [git hooks] 的功能

原本還以為是什麼外掛呢，原來他早就已經存在於 .git 的資料夾中，這要簡單的修改就可以使用了，而且是最簡單的 shell script 而已，只要吧 *.sample 後面的 sample 副檔名，就可以直接使用啦

先說一下我的想法和做法吧：

• commit 前，就先讓 hexo generate html 吧，順便看看有沒有問題
• commit code
• commit 後，就直接把剛才 generate 出來的 html，deploy 到指定的目的地吧

既然概念這麼簡單，就直接說要怎麼做了

• 修改一下 ./git/hooks/pre-commit.sample

#!/bin/sh

exec ./bin/generate.sh

• 重新修改檔名，把後面的 .sample 拿掉，就會變成 pre-commit 這個檔名。待會 commit code 之前，就會自動執行剛才所執行的 generate.sh 這個 script 啦
• 另一部分，也可以有 post-commit 這個檔案，就是 commit 完成後要執行的動作，如果沒有這個檔案，那就手動生一個吧
• 其他還有不同的功能和處罰時機不同的功能

如此一來，我就可以在 commit code 完成後，不但產生了目的的 html ，又可以在 commit 完成後，直接 deploy html 頁面到目標的地方

這麼說來，除了需要在檢視是否功能有誤時，無法直接操作外，其他的部分，就可以全自動把 code commit，又可以達成 deploy 的目標。真的算是一舉數得啊！！

相關 git hooks 資料，可以看看 這裡