故事：周五最后，M希望将wbs和satellite合并，zy则认为保持分离相宜。我提出，将immy框架提出为一个单独git库（确切的叫法应为：repo，下面将用此叫法），供两个“应用”级repo共用。这个想法，从复用的“理念”上是没有问题的，但具体到这里，是跨repo的复用，就不如代码层面上的复用来的那么方便、直接。周六花了大半天时间研究git对此方式的支持，感觉此方式实施起来也没有想象的那么理想，现将考察的情况及所考虑的问题呈现出来，供大家思考。
跨git repo复用代码
基本思路：将一个repo A，引入到另外的repo B、C中，如果A有更改，B、C中更新就可以了。
1. submodule
这是git原本的支持方案。只可惜，它仅适用于引入“不需要修改”的repo（如第三方的）。而我们要共用的immy现在还属于（并且将来仍是）需要经常改变的阶段，并不适宜。
2. subtree
此方式比较适用于我们的场景：A和B、C都经常改变。做了一个demo，试用了一番，觉得用起来比较繁琐：（A被引入到B、C中，作为一个单独的目录）如我在B中修改了A，需要：
- push到repo B
- push到repo A（subtree）
- 在C中pull下A的更新，再push到repo C
总之，实际上是有3份A的实例（A自身，B、C中各有一份），虽然三份都是一样的。这对于维护A的同学来说，无疑是有些繁琐（每次push都得执行3次），其他同学倒是可以完全“感知”不到A是一个单独的repo，只需按惯常的操作进行即可。
那，可不可以将这3次用一个脚本封装一下？或许是可以，但感觉就有些笨重了，不直观。如果我们哪天又要做一个xx站，那按现在的思路，就得再建一个repo D，同样引入A，那么将变成4次。
demo
// 共用的repo
git clone https://github.com/notecode/xlib.git
// 下面2个repo已经引入xlib
git clone https://github.com/notecode/www.git
git clone https://github.com/notecode/m.git
https://hpc.uni.lu/blog/2014/understanding-git-subtree/
http://yutin.logdown.com/posts/188306-git-subtree-total-addendum-library
https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
再思考
引入subtree，对查看log、切换分支等工作（在一个repo时比较容易的工作）来说，现在将变得复杂许多。毕竟，subtree并不是业界的主流（google有个git-repo工具，用于管理多个repo的依赖，尚未研究），不能像在一个repo那样灵活。
再加上每次push都要3次，这些不便合起来，让我对此方案的“性价比”产生了质疑：值当吗？
然后我又折回去想M提出“将两个repo合并”的想法，是否更划算一些？那样，我们可以用一个repo，使用最纯的git（不至于害怕碰到什么坑），要面对的问题：多个站的目录组织、发布等。至于说代码放在一起，多了之后会不会clone一次很慢。我觉得这个顾虑倒是不太紧要，就我们这几个人，一年才能写多少代码呢。
另外，从概念上说，如果我们因使用同一个“库”而选择在同一个repo中，似乎有些牵强；但我们因使用同一个“框架”而选择在同一个repo中，则合理。“框架”是无所不在的，“库”则只完成特定功能。
结语：
综上，两种方案（合并 vs. 分开），各有利弊，请大家思量。
网友评论