嘿，这个问题我之前练手小项目的时候也琢磨过！既然都是你自己写的C代码仓库，而且纯为了学习实验，那有几种常用的方法，每种都有适合的场景，我给你唠唠：

1. Git子模块（Git Submodules） #

这算是Git官方推荐的跨仓库依赖管理方式，刚好适配你这种想保留两个仓库独立提交历史，但又要在KVS项目里直接引用哈希表代码的需求。

操作起来也不复杂：

• 进到你的KVS仓库根目录，执行 git submodule add <你的哈希表仓库URL> hash-table，这样KVS里会多出一个hash-table目录，里面就是哈希表的全部代码，同时Git会专门记录这个子模块的当前版本。
• 之后在KVS的Makefile（或者你用的构建脚本）里，把hash-table下的源文件加进编译流程就行。比如哈希表有hash.c和hash.h，那编译命令可以改成 gcc -o kvs main.c hash-table/hash.c，或者在Makefile里指定源文件的路径。
• 注意哦：以后别人克隆你带了子模块的KVS仓库时，要加--recurse-submodules参数，或者克隆完执行git submodule update --init，不然hash-table目录是空的。

这种方法的好处是两个仓库的提交历史完全独立，你在哈希表仓库改完代码推送到远程后，KVS仓库可以随时更新子模块的版本，两边改动互不干扰，特别适合保持代码的模块化。

2. 直接复制代码（快速实验首选） #

如果只是想快速把哈希表集成到KVS里试试水，不想搞复杂的Git配置，直接把哈希表的.c和.h文件复制到KVS仓库的对应目录（比如src/hash/）完全没问题。

这种方法零配置，复制完直接在KVS代码里写#include "hash/hash.h"就能用，完美匹配你现在的学习实验需求——毕竟你就是想快速验证GET/PUT和哈希表的结合效果。

但缺点也很直白：以后哈希表代码有更新，你得手动再复制一次，没法自动同步，所以只适合短期实验，不适合长期维护。

3. Git子树（Git Subtree） #

这是介于子模块和直接复制之间的折中方案，能把子模块的代码合并到KVS仓库的某个目录下，同时还能和原哈希表仓库保持关联，方便同步更新。

操作步骤大概是这样：

• 进入KVS仓库，执行 git subtree add --prefix=hash-table <哈希表仓库URL> main（这里的main是哈希表仓库的主分支名），执行完哈希表的代码就会合并到KVS的hash-table目录里，Git也会记录这个合并的来源。
• 之后如果哈希表仓库有更新，你可以用 git subtree pull --prefix=hash-table <哈希表仓库URL> main 拉取最新代码；要是你在KVS里改了哈希表的代码，也能用 git subtree push --prefix=hash-table <哈希表仓库URL> main 推回原仓库。

这种方法比子模块简单，不用处理麻烦的子模块初始化，别人克隆你的KVS仓库时直接就能拿到所有代码，适合不想折腾复杂Git配置，但又想保持代码同步能力的情况。

4. 编译为静态库（模拟真实项目构建） #

要是想顺便练习真实C项目的依赖管理流程，可以把哈希表仓库编译成静态库（.a文件），然后在KVS项目里链接这个库来用。

具体可以这么做：

• 在哈希表仓库里写个简单的Makefile，编译出libhash.a，比如：

  all: libhash.a
  
  libhash.a: hash.o
      ar rcs $@ $^
  
  hash.o: hash.c hash.h
      gcc -c -o $@ $<
  

• 之后在KVS仓库里，要么把libhash.a和hash.h复制过来，要么编译时指定搜索路径：比如 gcc -o kvs main.c -L../hash-table -lhash -I../hash-table（假设哈希表仓库和KVS在同一级目录下）。
• 要是你想更规范点，还能把哈希表的库文件安装到系统的/usr/local/lib，头文件放到/usr/local/include，这样KVS编译时直接用 gcc -o kvs main.c -lhash 就行——不过这种方法更适合你觉得哈希表代码已经比较稳定，想当成通用库来用的情况。

最后给你个小总结 #

如果是短期学习实验，直接复制代码或者Git子树最省心；如果想练习Git的依赖管理能力，Git子模块是标准做法；要是想学习C项目的构建流程，编译静态库是非常好的实践方向。

内容来源于stack exchange