区分软件包依赖和版本控制，Git历史修剪“核武器”小试

我的89jian项目依赖于LubanLock，LubanLock又依赖于CodeIgniter，所以我就想当然的把Codeigniter配置成了LubanLock的一个remote，又把LubanLock配置成了89jian的一个remote，被依赖的库有更新了，依赖它的库就git pull LubanLock一下。

我首先发现，这样我每在LubanLock中的一个提交，会重复出现在依赖它的项目中（这当然不是问题），Github在统计个人贡献的时候，会重复计算这些提交。开始我认为是Github的bug，还发了邮件给人家support。人家弱弱的回了一段，说你项目之间的依赖没做好，才会这样的。

然后我就慢慢懂了，包依赖管理，和版本控制，原来是两回事呢！对于一个项目来说，需要自动安装，不直接改动代码，甚至不提交入库的包称之为依赖，这些代码的版本控制其实并不关心，只要确定当前依赖的版本和来源就可以了。而版本控制则记录了每一个贡献者的每一次代码提交，应该仅针对当前项目。如果动不动就把依赖的那些项目的版本管理也纳入，那你的库该有多热闹（我之前看似数百人参与的那些LubanLock的分支就是那么回事）。

不过对于包管理，有一些前提：被依赖的包在项目中可以轻松设置路径，比如composer的就是vendor，一般是不应该去改它的。那么对于我而言，LubanLock对于89jian，是框架，硬要做成依赖扔到一个目录里太伤，不如就像其他几个WordPress项目一样，对于WP的更新不去pull，直接提交更新后的整个代码。把框架纳入仓库，还是出于可能会对框架进行一些项目范围内的局部改动，方便跟踪更改。

于是我现在，CodeIgniter仍然是LubanLock的remote，89jian等项目中的LubanLock代码直接cp，而且纳入前者的版本控制中。

附使用Git剪枝的两端脚本

git filter-branch --commit-filter '
 if [ "$GIT_AUTHOR_EMAIL" = "uicestone@gmail.com" ];
 then
 skip_commit "$@";
 else
 git commit-tree "$@";
 fi' HEAD

还有段好不容易调试成的用grep按照提交hash逐条比较判断是否排除提交的脚本弄丢了，算了，估计这辈子难弄第二回。

未来把框架做到单独的子目录，做成依赖管理，应该是迟早的事，人家node.js的express在npm里不就直接一行install装在/vendors/里嘛。如果我用的框架不能适应这些项目管理方式，只能说明，他们老了。

而如果有一天我没有心情研究新的项目管理方式了，说明我也老了。

更新：自从使用了Composer和Laravel，世界清静了。包管理大一统时代即将到来，代码风格大一统时代即将到来。