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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 1772 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

Utilities

git

共享

21 条回复 • 2020-01-03 13:13:53 +08:00

vanton

2020-01-02 11:26:54 +08:00

用 .gitignore

JCZ2MkKb5S8ZX9pq

2020-01-02 11:32:52 +08:00

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

orzorzorzorz

2020-01-02 11:35:38 +08:00

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

xuanbg

2020-01-02 11:40:14 +08:00

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

JCZ2MkKb5S8ZX9pq

2020-01-02 11:44:41 +08:00

@orzorzorzorz
@xuanbg

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

orzorzorzorz

2020-01-02 12:32:28 +08:00

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

networm

2020-01-02 13:00:27 +08:00 via iPhone

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

JCZ2MkKb5S8ZX9pq

2020-01-02 13:47:07 +08:00

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

JCZ2MkKb5S8ZX9pq

2020-01-02 13:48:49 +08:00

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

JCZ2MkKb5S8ZX9pq

2020-01-02 13:54:32 +08:00

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

janus77

2020-01-02 14:30:25 +08:00

git sub module

networm

2020-01-02 15:13:12 +08:00 via iPhone

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

JCZ2MkKb5S8ZX9pq

2020-01-02 15:17:42 +08:00

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

JCZ2MkKb5S8ZX9pq

2020-01-02 15:20:01 +08:00

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

JCZ2MkKb5S8ZX9pq

2020-01-02 15:36:18 +08:00

@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

2020-01-02 19:47:45 +08:00 via iPhone

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

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

networm

2020-01-02 20:09:19 +08:00 via iPhone

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