Github

除了在公司團隊內負責審核各專案 PR 之外，也在 GitHub 上面提交多個 PR，並且與全世界各地開發者一起共同維護大型專案，一個好的 PR 可以加速專案的進行，且省下多數 Reviewr 寶貴的時間，故我自己整理底下幾點，來確保團隊同事之前有個共同的標準外，也大大降低 Review 時間，提升專案品質。

之前寫過一篇『用 10 分鐘安裝好 Drone 搭配 GitLab』。團隊內還沒導入自動化 CI/CD 測試部署環境的朋友們，可以來嘗試看看用 Go 語言打造的 Drone CI/CD 開源專案，不用五分鐘的時間就可以在您的電腦上安裝好 CI/CD 的流程，真的是簡單到不行，只要一個 docker-compose 檔案就可以完成架設了。

新課程上架:『Docker 容器實用實戰』目前特價 $800 TWD，優惠代碼『20200222』，也可以直接匯款（價格再減 100），如果想搭配另外兩門課程合購可以透過 FB 聯絡我

GitHub 提供一個非常方便的功能，就是可以將靜態檔案部署在 GitHub 上，基本上開發者不用負擔任何 Host 費用，就可以使用靜態檔案來做 Demo 介紹，或者是文件系統。而本篇將教您如何用 Drone 來自動化部署靜態檔案到 GitHub 上。作者直接用 Vue.js 來介紹整個流程。

GitHub Actions 也推出一陣子了，相信有不少雷，也是有很多優勢，未來在 GitHub 上面串接任何開源專案，都可以免費使用，過幾年可以看看 GitHub Actions 對 Travis 的影響是多少？本篇要來介紹如何透過 GitHub Actions 來部署 Go 語言服務，會用一個簡單 httpd 範例教大家如何透過 Docker 方式來更新。使用 Go 語言基本服務流程大致上會是『測試 -> 編譯 -> 上傳 -> 啟動』，透過這四個步驟來學習 GitHub Actions 該如何設定。

• 測試: Unit Testing 多一層保護
• 編譯: 透過 go build 編譯出 Binary 檔案
• 上傳: 寫 Dockerfile 將 Binary 包進容器內
• 啟動: 透過 docker-compose 方式來更新服務

今年很高興又去 Cloud Summit 研討會給一場議程『初探 GitHub 自動化流程工具 Actions』，這場議程沒有講很多如何使用 GitHub Actions，反倒是講了很多設計上的缺陷，以及為什麼我現在不推薦使用。GitHub Actions 在去年推出來，在這麼多 CI/CD 的免費服務，GitHub 自家出來做很正常，我還在想到底什麼時候才會推出，beta 版出來馬上就申請來試用，但是使用下來體驗非常的不好，有蠻多不方便的地方，底下我們就來聊聊 GitHub Acitons 有哪些缺陷以及該改進的地方。

2022.03.26 Updated: 現在主流分支名稱為 main

在 Facebook 上面看到這篇『git flow 實戰經驗談』，想說來寫一下對於團隊內該導入 GitHub Flow 還是 Git Flow，寫下自己的想法給大家參考看看。當你加入團隊，第一件事情就是嘗試了解目前團隊是走哪一種 Git 流程，但是在團隊內可能使用 GitHub 流程或者是傳統 Git 流程，在開始進入開發流程時，請務必先了解團隊整個 Release 流程。後者流程在筆者幾年前有發表一篇『branch model 分支模組基本介紹』，如果大家有興趣可以先看看，而我自己在團隊內使用這兩種流程，嘗試過幾個團隊，得到底下結論:

• 公司內部請使用 GitHub 流程
• 開源專案請使用 GitHub 流程 + Git 流程

底下來探討為什麼我會有這些想法。首先先來看看公司團隊內部如果是走 Git 流程會有哪些缺陷。

現在 Git 服務最有名的就是 Github，如果是開放原始碼，我很推薦 Github。如果是想要放大量私有專案或企業內及個人使用，想必大家會推薦 Gitlab，在這裡就不多介紹 Gitlab 了，可以從 Google 找到許多相關資料，本篇會介紹另類的 Git 自架服務選擇 Gitea，在介紹之前可以先參考我在 2014 年寫了一篇用 Go 語言開發的 Git 服務叫做 Gogs。

Travis 是在 Github 上常用的整合測試服務，支援了各種程式語言 Golang, PHP, Node.js ..等測試及部署，也同時支援了一些常用 Service，像是 Docker, Redis 或 Database。這次來聊聊在 Travis 如何使用 Docker，在 Travis 內建的 Docker 跟 docker-compose 版本都是非常舊，所以使用預設的 docker-compose 指令常常會出現 (詳細 build log 可以參考這裡)

代碼覆蓋率 (code coverage) 是開發流程蠻重要的一環，用來評估專案內測試的覆蓋率，也代表了自己寫的程式，至少要測試過一次。在 Github 上面最常用的一套就是 Coveralls 相信大家對於此服務並不陌生，一個好的 Open Source 專案一定會在 Readme 上附上 Coveralls badge，證明自己寫的專案都有經過測試，請安心使用。在導入 Coveralls 服務到專案內時，安裝步驟有點小複雜，雖然不難，但是還是需要安裝一些 Tool 才能完成，底下用 Golang 為例。

在 IDE 編輯器我們可以用內建的 go to definition 直接跳到該函式，但是身為工程師，每天接觸最多的就是觀看 Github 程式碼，有沒有什麼方式可以透過 Web 介面直接搜尋專案內 Golang 所有函式，讓 Golang 開發者快速跳到該函式，這時就要來安裝 Sourcegraph Chrome extension for GitHub 啦。