每一個可以努力的日子，都是一份厚禮。
軟件工程
Git tips: 合併 commit 保持分支幹凈整潔
2015 12月 25th
本文的讀者需要已經了解 基本的 Git 操作和開發流程。
在我們開發完分支後，一般分支上會有很多 commit —— 少不了諸如 “fix typo”， “sth wrong in the previous commit” 之類的 commit。在合併到主幹的時候，往往這類 commit 顯得臃腫多餘。為了方便別人做 code review，我們希望合併一些不必要的 commit 使我們的分支顯得乾淨一目了然，也方便管理。有 3 種方式可以做到。
將代碼庫從 SVN 遷移至 Git 並保留所有 commit 記錄
2014 5月 15th
公司內部原本使用 SVN 進行版本控制，但隨着 Github 的流行我個人的代碼管理習慣逐漸轉變。雖然公司項目並非開源，SVN 所具有的標準 trunk / branches / tags 結構完全夠用，使用 Git 仍然有如下優勢：
- 類似 GitHub 的 GitLab 免費管理工具。將代碼託管在自己內部服務器上的同時，提供了優美的 web 界面，圖形化分支結構，更直觀的代碼審查，統計、issue 系統、wiki 等功能全面集成。
- 更方便主程做 code review，控制代碼質量。創建主倉庫，多人開發時使用 fork 模式，每個人擁有自己獨立的 repo，獨立的 trunk / branches，最後發送 pull request 進行代碼合併。
- commit 和 push 更快。體現在 push 到遠程倉庫時 Git 會先對所有需要上傳的文件進行 zip 打包壓縮，然後一次性傳輸，在遠程服務器解壓，全部自動完成。而 SVN 則是一個一個文件地上傳，代碼是純文本，總體積並不大，但是大量零碎的小文件頻繁建立網絡連接造成延遲。這在升級第三方的庫或者框架時，成千上萬的文件更新更加讓人難以忍受。
- hook 可以更方便做自動化部署。當然這個 SVN 也有。
權衡後我決定花時間進行代碼倉庫的遷移。代碼遷移並非簡單地創建 Git repo 把當前項目代碼一次性 commit 過去就夠了，因為 SVN 中存有長年累月的 commit 歷史記錄，丟失歷史記錄將對今後追溯 debug 造成非常大的麻煩，所以如何保留 commit 記錄就是遷移的關鍵。
作風問題
2013 3月 26th
