開源專案 Drone CI/CD 平台真的免費嗎?

cover

自己推行 Drone CI/CD 開源平台已經多年,很多人都會問我說,Drone 真的可以免費使用嗎?用在開源上面,或者是導入進公司內部團隊,這費用該怎麼計算呢?好的,本篇就帶大家了解 Drone 用在開源上或是公司內部團隊上需要注意的地方,官方其實有寫了一整頁 FAQ 非常詳細,底下是我整理幾點給大家知道。

[Read More]

GitHub Flow 及 Git Flow 流程使用時機

Screen Shot 2017-12-20 at 11.45.04 AM

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

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

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

[Read More]

用 Docker 改善團隊合作模式

docker

今年第一次參加 iThome 舉辦的 DevOps Summit 研討會,這次舉辦在台北文創大樓,就是在大巨蛋隔壁,很高興今年第一次投稿就錄取,題目是『用 Dokcer 改善團隊合作模式』,主題偏向如何用 Docker 改善個人或團隊的開發狀況,尤其是在 IC 或系統廠如何導入 Docker。研討會上沒有提到很深入的 Docker 應用,在投影片內強調的是,如何將 GitDocker 帶入團隊內不同角色,包含 QA 及 PM,讓大家在團隊合作上能夠各自獨立,不會互相影響。底下就是我今年的投影片:

[Read More]

Git Flow 與團隊合作

branching-illustration@2x

本月最後一篇投影片來介紹 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_logo

之前寫過一篇 GitLab 快速安裝筆記,但是這次在 Debian 7.8 上安裝起來遇到蠻多問題,故寫此篇來記錄安裝遇到的問題,也會寫到如何搭配 Nginx 設定。GitLab 分兩種版本,一種是 Community Edition packages 另一種是 Enterprise Edition packages,本篇是記錄 Community 版本安裝步驟,可以到下載頁面選擇您的作業系統,就可以看到安裝方式

[Read More]

該如何寫好 git commit message

github-logo

Git 已經是每天必用的工具,也是團隊間互相合作的重要角色。要寫好 Git commit message,讓團隊成員可以知道每一個 Commit 代表什麼意思,這是非常重要的。網路上看到一篇教您如何寫好 Git commit message,好的 Commit Log 可以讓其他同事快速知道這個 Pull Request 包含了哪些異動,該作者寫了七點,分別如下

  1. 將標題與內容中間多一行空白
  2. 標題限制 50 字元
  3. 標題第一個字必須為大寫
  4. 標題最後不要帶上句號
  5. 標題內容可以使用強烈的語氣
  6. 內容請用 72 字元來斷行
  7. 內容可以解釋 what and why vs. how

要強制大家有共通的 commit format 其實很難,所以團隊內會使用 issue track 系統,大家把 issue 或 feature 都開好,在標題列裡面就要強制將 issue number 寫入,然後在 issue 那邊把內容及作法詳細寫清楚,方便追蹤,這樣也是可以的。

PS. 該是強迫自己把 commit log 寫好會比較好,通常在追問題,也時候也會發現自己寫的 Log 不是很清楚。

git 

git tips 找尋遺失的 commit 紀錄

github-logo

個人每天常用的常用的三大 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 指令

1
2
3
4
5
6
7
8
$ git reflog
794be8b HEAD@{0}: reset: moving to HEAD^
5e2be6f HEAD@{1}: commit (amend): update
bfa593c HEAD@{2}: cherry-pick: update
794be8b HEAD@{3}: reset: moving to 649c658
794be8b HEAD@{4}: reset: moving to HEAD^
649c658 HEAD@{5}: commit: update
794be8b HEAD@{6}: commit (initial): addd

上面可以看到之前 commit 的記錄,接著可以透過 git reset --hard xxxxx,或者是用 git cherry-pick xxxxx 將上一個 commit ID 記錄抓回來即可。