自己推行 Drone CI/CD 開源平台已經多年，很多人都會問我說，Drone 真的可以免費使用嗎？用在開源上面，或者是導入進公司內部團隊，這費用該怎麼計算呢？好的，本篇就帶大家了解 Drone 用在開源上或是公司內部團隊上需要注意的地方，官方其實有寫了一整頁 FAQ 非常詳細，底下是我整理幾點給大家知道。
[Read More]GitHub Flow 及 Git Flow 流程使用時機
2022.03.26 Updated: 現在主流分支名稱為 main
在 Facebook 上面看到這篇『git flow 實戰經驗談』，想說來寫一下對於團隊內該導入 GitHub Flow 還是 Git Flow，寫下自己的想法給大家參考看看。當你加入團隊，第一件事情就是嘗試了解目前團隊是走哪一種 Git 流程，但是在團隊內可能使用 GitHub 流程或者是傳統 Git 流程，在開始進入開發流程時，請務必先了解團隊整個 Release 流程。後者流程在筆者幾年前有發表一篇『branch model 分支模組基本介紹』，如果大家有興趣可以先看看，而我自己在團隊內使用這兩種流程，嘗試過幾個團隊，得到底下結論:
底下來探討為什麼我會有這些想法。首先先來看看公司團隊內部如果是走 Git 流程會有哪些缺陷。
[Read More]用 Docker 改善團隊合作模式
今年第一次參加 iThome 舉辦的 DevOps Summit 研討會，這次舉辦在台北文創大樓，就是在大巨蛋隔壁，很高興今年第一次投稿就錄取，題目是『用 Dokcer 改善團隊合作模式』，主題偏向如何用 Docker 改善個人或團隊的開發狀況，尤其是在 IC 或系統廠如何導入 Docker。研討會上沒有提到很深入的 Docker 應用，在投影片內強調的是，如何將 Git 及 Docker 帶入團隊內不同角色，包含 QA 及 PM，讓大家在團隊合作上能夠各自獨立，不會互相影響。底下就是我今年的投影片:
[Read More]Git Flow 與團隊合作
本月最後一篇投影片來介紹 Git Flow 流程該如何導入團隊，之前寫過一篇 Git branch model 文章，裡面提到該如何正確使用 branch，但是現在回想起來要導入團隊內真的是有點麻煩，也遇到蠻多問題的，後來最後只採用 Github Flow，簡單又容易理解，如果開發者很常在 Github 活動，相信對於此方法並不會很陌生。
[Read More]Git tips: 更改 commit log 作者
在 Github 上面看到這 git-blame-someone-else 專案，用來隨時修改 commit log 作者，也就是可以任意改 commit id 內的 `Author` 欄位資訊，作者也相當幽默，直接拿此 commit id 改成 Linux 作者 Linus Torvalds。
使用時機 大家會問到什麼時候才會用到需要修改 commit 作者，以我自己的狀況為例，在團隊內開發新功能會直接開新的 Branch 來開發，完成後會進行 code review，此時原開發者目前正在忙其他專案，其他團隊成員就必須幫忙修改原先 commit 內容，通常我是直接建議透過 `git reset –soft HEAD^` 來更動原本 commit，而不是產生新的 commit，修改後作者就會變成自己，此時後這功能就派上用場了。
安裝方式 根據源專案是透過 root 權限，將執行檔丟到 `/usr/loca/bin` 目錄底下，但是我個人不建議用這方式，因為還需要 root 權限，要打密碼有點麻煩，我建議透過在家目錄建立 `bin` 目錄，並將此目錄加到 `$PATH` 變數內即可。
1 2 3 $ mkdir ~/bin $ wget https://raw.githubusercontent.com/jayphelps/git-blame-someone-else/master/git-blame-someone-else -O ~/bin/git-blame-someone-else $ chmod 755 ~/bin/git-blame-someone-else 修改 .bashrc，加入底下程式碼
1 2 3 4 # add bin folder to $PATH.
[Read More]
在 Debian 7.8 安裝 Gitlab 筆記
之前寫過一篇 GitLab 快速安裝筆記，但是這次在 Debian 7.8 上安裝起來遇到蠻多問題，故寫此篇來記錄安裝遇到的問題，也會寫到如何搭配 Nginx 設定。GitLab 分兩種版本，一種是 Community Edition packages 另一種是 Enterprise Edition packages，本篇是記錄 Community 版本安裝步驟，可以到下載頁面選擇您的作業系統，就可以看到安裝方式
[Read More]Git tips 請不要 commit 已經註解的程式碼
上週看到一篇國外作者寫的 Please, don’t commit commented out code，裡面內文真的不得不按讚啊，對於每天都要 review code 的開發者來說，最不喜歡看到的就是類似下面的程式碼
this.test = function(req, res, next) {
// if (foo) {
// return ‘1’;
// } else if (bar) {
// return ‘2’;
// }
return 3;
};
該如何寫好 git commit message
Git 已經是每天必用的工具，也是團隊間互相合作的重要角色。要寫好 Git commit message，讓團隊成員可以知道每一個 Commit 代表什麼意思，這是非常重要的。網路上看到一篇教您如何寫好 Git commit message，好的 Commit Log 可以讓其他同事快速知道這個 Pull Request 包含了哪些異動，該作者寫了七點，分別如下
- 將標題與內容中間多一行空白
- 標題限制 50 字元
- 標題第一個字必須為大寫
- 標題最後不要帶上句號
- 標題內容可以使用強烈的語氣
- 內容請用 72 字元來斷行
- 內容可以解釋 what and why vs. how
要強制大家有共通的 commit format 其實很難，所以團隊內會使用 issue track 系統，大家把 issue 或 feature 都開好，在標題列裡面就要強制將 issue number 寫入，然後在 issue 那邊把內容及作法詳細寫清楚，方便追蹤，這樣也是可以的。
PS. 該是強迫自己把 commit log 寫好會比較好，通常在追問題，也時候也會發現自己寫的 Log 不是很清楚。
git tips 找尋遺失的 commit 紀錄
個人每天常用的常用的三大 Git 指令分別是 git reset, git pull, git rebase，但是呢有時候手殘，常常把 git reset --soft 打成 git reset --hard 造成不可預期的錯誤，朋友圈內也有人常常問我該如何救不見的 commit，其實很容易，git 對於每隔操作後產生的 commit 都會存放在 Local 端，所以基本上不用擔心 commit 記錄會不見，有一種狀況會永遠消失，那就是假設尚未 commit 目前修正過的檔案，然後下 git reset --hard HEAD，這樣的話我想誰都無法幫忙把已修正過的檔案找回來了，原因是連 git 都不知道你改了什麼啊。所以為了避免這情況方生，個人建議開發者，只要開發到一定的階段，務必要下一個 commit 當作記錄，但是你會說，這樣功能開發完後，就會有很多個 commit 非常不好看，這時候可以嘗試 git rebase 將整個功能合併成一個 commit，這樣其他開發者 review 時就會非常清楚。
現在的問題是如果開發者不小心下了 git reset --hard HEAD^，上一個 commit 就會消失了，這時候該如何救回來呢？答案可以使用 git reflog 指令然觀看開發者全部 git 的操作記錄，裡面詳細記載你曾經下過的 git 指令
| |
上面可以看到之前 commit 的記錄，接著可以透過 git reset --hard xxxxx，或者是用 git cherry-pick xxxxx 將上一個 commit ID 記錄抓回來即可。
Git Flow and JavaScript Coding Style
Git 已經是每日必備使用的指令，在平常工作上常常使用到 git rebase 或 git merge，發現很多工程師不知道什麼時候該用 rebase 什麼時候該用 merge，所以做了底下投影片來清楚描述 git rebase 及 merge 的優缺點及使用時機。
[Read More]