版本控制

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

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

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 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 記錄抓回來即可。

Git 已經是每日必備使用的指令，在平常工作上常常使用到 git rebase 或 git merge，發現很多工程師不知道什麼時候該用 rebase 什麼時候該用 merge，所以做了底下投影片來清楚描述 git rebase 及 merge 的優缺點及使用時機。

這篇會筆記如何將 Github 上專案內的 Pull Request 拉到 Local 端電腦，雖然現在大部分的 Open Source 都會寫 Unit Test 並且搭配免費的 Travis CI 自動化測試，但是有時候也是需要把別人的 Pull Request 拉下來測試後再進行 Merge，而 Github 官方有提供一篇說明文件 Checking out pull requests locally，底下紀錄操作步驟。

Git 版本控制不管在嵌入式或 Web 領域都是很受歡迎的工具，尤其是不會遇到像 svn 搞爛 source tree，然後又要 Google 一堆解法。一般公司入門大概就是買 Github 服務，一個月才五美金，可以提供五個 Private Project，當然你也可以不付錢，而去使用 Bitbucket，好處就是無限的 Private Project，唯一的限制就是開發者數量，只能在五個以內，設定超過五個，就不給 push 或 pull 了，完成版本控制後，接著就是專案的自動測試，在 github 上面，推的就是 travis-ci，這也是全部 open source 專案的喜好，你會發現大部分的專案都會放上 .travis.yml，來告訴 travis 需要的測試步驟，測試步驟完成後，就要將 source code deploy 到 Amazone 或其他雲端服務，到這個服務基本上都要收費了，所以上一篇有介紹 Drone.io 服務，可以自動測試加上 Deploy 到遠端機器，不過缺點就是不支援 Private Project，要的話就是要收費。

每天打開電腦，第一件事情就是將專案程式碼更新的最新，以便整合同事新開發的功能，免的跟自己寫的功能衝突，所以最常用用的就是 git pull --rebase origin master，此命令使用 rebase 來取代 merge 程式碼，也可以避免在 log 清單內出現 merge branch master into master 等字樣，但是如果在開發一半進度時，想同時將同事的程式碼先 merge 進來，會發現無法 merge，git 會請你先將 local 修改過的檔案 commit，才可以讓您更新，所以這時候我們可以用 git stash 方式來解決

如果你在 master 分支上，並且想 pull 最新的 commit，可以透過底下指令步驟

1
2
3

git stash --include-untracked
git pull --rebase origin master
git stash pop