Git

git submodule 与 subtree 的异同

前几天有小伙伴在整理某个代码仓库的时候，希望把仓库里的代码和数据分离以便于管理。 由于他使用的是 git，所以很快大语言模型便引导他用上了包括 filter-repo 在内的一系列禁术， 其间就有了一段关于是应该使用 git submodule 还是 git subtree 的讨论。

先说我的结论，对于绝大多数人，特别是已经动了重写历史这种念头的人来说， 理想的选择是 git submodule。

本地 git 的 partial clone

partial clone 是 git 的一项旨在减少空间和网络带宽占用的特性。 它会跳过下载那些可能不会用到的 git 对象，而是仅仅在需要时才去下载。对于网络延迟较低且带宽不愁的用户来说， 这样做往往会节省掉不少不必要的磁盘空间占用，而代价是可能失去离线访问的能力。除此之外，有些操作， 例如 git blame 或者 git log -p 很可能会需要与服务器交互，从而会变得略慢一些。

比较有用的场景是在使用某些历史比较久，或是对文件整体替换较多，而大部分情况下只关注最新版本的代码库。 与较早的 --depth 1 相比，partial clone的优点在于想要访问历史时仍然可以像正常的clone一样访问。

FreeBSD终于换了git

FreeBSD 最近终于完成了从 subversion 到 git 的转换（其实还没算彻底完成，不过 src/ 和 doc/ 都已经完成了）。

我个人用 git 用了蛮久了，最早开始严肃地用 git 大概是2012年年底 Illumos 从 hg 换成 git 的时候的事情，当时 FreeNAS 的开发也从 subversion 迁移到了 git，后来，我们也把 FreeNAS 内嵌的 FreeBSD 的开发搬到了 git 上面。

作弊条：几个不太常用的git库管操作

配合 svn 使用 git 时可能会遇到许多问题，例如两个人分别做了 git svn clone，然后希望合并到同一个 git 库中。如何做合并呢？假定两个库分别是 old, new，将这两个库对应的分支和对应的源分支 (svn/*) 通过 .git/config 分别复制到不同的分支名字下面，例如 svn/releng/8.2 和 old-svn/releng/8.2。假定需要合并的分支是 old/my8.2，则做以下操作：

作弊条：用git做中心式代码库

在开始创建 git 代码库的时候，应使用 --bare 参数。举例：

git init --bare [repo_path]

或者，如果多人开发的话：

git init --bare --shared [repo_path]

将现有代码库转换为中心式代码库：

作弊条：git配合svn的一些使用方法

在一个git库中跟踪不同的svn branch

首次创建git库：git svn clone [svn代码库到HEAD分支的URL] [git代码库名]

例如，对于 FreeBSD，对应的URL为 http://svn.freebsd.org/base/head/

一般来说，从远程svn库复制需要的时间会比较长，也可以考虑首先在本地建立一份镜像，然后直接用 file:/// 去指定。