每一个可以努力的日子，都是一份厚礼。
软件工程
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
