GitHub Flow 及 Git Flow 流程使用時機

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

用 Docker 改善團隊合作模式

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

Git Flow 與團隊合作

branching-illustration@2x 本月最後一篇投影片來介紹 Git Flow 流程該如何導入團隊,之前寫過一篇 Git branch model 文章,裡面提到該如何正確使用 branch,但是現在回想起來要導入團隊內真的是有點麻煩,也遇到蠻多問題的,後來最後只採用 Github Flow,簡單又容易理解,如果開發者很常在 Github 活動,相信對於此方法並不會很陌生。 Continue reading “Git Flow 與團隊合作”

Git tips: 更改 commit log 作者

github

Github 上面看到這 git-blame-someone-else 專案,用來隨時修改 commit log 作者,也就是可以任意改 commit id 內的 Author 欄位資訊,作者也相當幽默,直接拿此 commit id 改成 Linux 作者 Linus Torvalds

Continue reading “Git tips: 更改 commit log 作者”

在 Debian 7.8 安裝 Gitlab 筆記

gitlab_logo

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

Continue reading “在 Debian 7.8 安裝 Gitlab 筆記”

Git tips 請不要 commit 已經註解的程式碼

github-logo

上週看到一篇國外作者寫的 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;
};
Continue reading “Git tips 請不要 commit 已經註解的程式碼”

該如何寫好 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 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 時就會非常清楚。

Continue reading “git tips 找尋遺失的 commit 紀錄”