关于 git 项目拆分的精度问题

[JCZ2MkKb5S8ZX9pq]

• 我有一个小工具目录 utilities，里面有一些自用的小工具。
• 现在我想共享其中部分，考虑两种方法，一种是把 utilities 一分为二，把要共享的和不要共享的分两个目录。然后 git 的记录也过滤一下。这部分倒是还好。
• 另一个困扰我的问题是，该不该把 utilities 下的工具细分为单独的项目。其中几乎都是一个文件一个功能，分的话每个项目下就只有一个文件而已。
• 好处是以后 commit 啥的都比较清晰，万一别人要用到搜索啥的也方便点。
• 但管理起来的缺点也挺明显，多了一堆仓库，里面都是屁大点小功能。而且本地目录层级也要多一层。
• 这个问题可能比较偏个人习惯，不知道大家怎么处理这类情况，听听大家看法。

[vanton]

用 .gitignore

[JCZ2MkKb5S8ZX9pq]

@vanton ignore 的话不合适。不想共享不等于不想 git，log 我还是要的。

[orzorzorzorz]

项目公有一个，私有一个，公共部分第三个。

[xuanbg]

项目公共的一个，私有的一个，私有的引用公共的。

[JCZ2MkKb5S8ZX9pq]

@orzorzorzorz
@xuanbg

没太明白，打个比方啊。
共有的叫 utilities_share，私有的就是 utilities。
然后本地的话，utilities 做 git，同时把 share 的那个 clone 为 utilities 的子目录，是这样吗？

[orzorzorzorz]

私有 utilities_private，共有 utilities_public，两者公共部分 utilities_common，三个 git。

[networm]

将现有工具目录中的脚本按照功能分别放在自己的子目录中，统一管理。
然后将要分享的脚本所在的目录提取为仓库，与他人共享。
以后的所有提交先在统一的仓库里提交，然后再在共享的仓库中提交。
具体的做法有几种，我偏好嵌套 Git 仓库这种方式，这样永远只有一份代码，不冗余。简单说就是进入统一 Git 仓库中的要共享的脚本所在子目录，执行 git init 再建一个仓库，这个仓库用于分享。实测在 Git 2.20.1 中子目录的改动既可以在统一仓库中提交，也可以在子目录中的仓库提交。我使用这种方法管理博客的 Hugo 主题。
另一种方法就是拷贝文件来同步，不管是手动拷贝还是 rsync，将子目录中的文件拷贝到另一个仓库中提交即可。

[JCZ2MkKb5S8ZX9pq]

@orzorzorzorz 这样本地管理有点重复吧？

[JCZ2MkKb5S8ZX9pq]

@networm
我在子目录碰到过一次问题，比如我有一个 tool_A，已经单独作为项目 git 过。
然后把这个 tool_A 移入 utilities 作为子目录，utilities 好像会自动 ignore 这个 tool_A 目录。

[JCZ2MkKb5S8ZX9pq]

@networm
另外作为子目录提交，我有点纠结的一点就是单个文件就要分一个目录并且 git，看上去有点蛋疼。
以前我也嵌套 git 仓库，前一阵刚剥离了不少。嵌套的话 commit 记录不是会有重复嘛？虽然说根目录我基本只做备份用，但感觉有点累赘，所以前一阵分了一下目录，分了几个大块单独 git，然后从根目录 ignore 出去了。

[janus77]

git sub module

[networm]

@JCZ2MkKb5S8ZX9pq 必须保证父目录已经是 Git 仓库后才能把其他 Git 仓库拖动到子目录中，否则在 git init 时会忽略。
Git 必须要以目录为单位来管理，这个没办法，只能单文件也得放在一个目录里。
Commit 记录不重复，逻辑上是属于不同仓库的 Commit，另外，你不一定要两个仓库保持一起提交，完全可以按照不同频率提交，包含的文件改动会有多有少。
根目录最大的作用不是备份，而是将不同的功能脚本整合为统一的整体，实现聚合的功能，发挥 1+1>2 的效果。

[JCZ2MkKb5S8ZX9pq]

@networm
脚本整合，我基本都通过 sys path 来搞了。
虽然还是有不少项目都直接引用了自己的工具包，好处是更新直接起作用。但有利有弊，现在越来越发现工具包改动经常影响到旧项目。所以最近调整习惯，都把工具单拆一份放到项目里了。

[JCZ2MkKb5S8ZX9pq]

@janus77 这个倒第一次看到，有点意思。

[JCZ2MkKb5S8ZX9pq]

@networm
你看看楼上兄弟提的那个 submodule，比较类似嵌套的 git。

然后我提到的那个问题，想到另一个问题。其实类似一个版本管理的问题。
比如一个工具模块 A，有若干版本 A1.0，A2.0。
要向下兼容又很麻烦或者多余，总之各种理由吧，版本向下不兼容了。

旧项目 old1/old2/old3 使用的是 A1.0，新项目 new1/2/3 用的是 A2.0。

这时候其实面对几个需求。
一个是 A1.0 发现了 bug 修改好了，怎么同步赋予 old1/2/3。
另一个需求是如果这个 bug 在 A1.0 和 2.0 都存在，都要改。那如果 A 版本很多，这里怎么简化。

[networm]

@ JCZ2MkKb5S8ZX9pq 我用过子模块 git submodule，我觉得很不好用。
至于为什么都放在一个仓库里，建议阅读深入《持续交付》，这里面实际上存在太多坑了。这里的关键是集成，最终所有东西在一起完成功能，应该尽可能的将所有东西放在一个仓库中。

至于你说的这个版本维护问题，你可以参考 Python 2 3，使用两个长期发布分支维护 Bug 修改，在一个分支上改完了 Bug 同步到另一个分支。
我建议尽可能只维护一个版本，可以把老版本升级到新版本，所有人统一在一个版本，问题较少。具体实践可以参考 Google Piper。

[networm]

@JCZ2MkKb5S8ZX9pq 整合我指的是所有东西结合在一起使用有加成的效果，不单指 Python 路径引用。

[secondwtq]

楼主的工具之间应该是没啥依赖关系的，用 monorepo 必要性不大
不过全拆了太麻烦，所以可能只能 monorepo …

[JCZ2MkKb5S8ZX9pq]

@networm
ok 我再试试看

[jackleeforce3615]

git submodule

[shepherdlazy]

我之前也有过类似的纠结，我的最终解决办法是用两个分支，共有分支和私有分支
公共分支只管理可公开的文件
私有分支管理私有的文件
主分支会合并私有分支和公共分支
我之前尝试过用 submodule 不能解决我的问题