git - 如何在 NFS 分区中拥有 git 存储库，在本地分区中拥有工作树？

Question

我的主目录位于文件服务器上远程安装的 NFS 分区中，并定期进行备份。我希望我的项目的 git 存储库位于我的主目录下(以便对其进行备份)，但我希望我的工作树位于我工作站的本地磁盘分区中(以便快速构建)。本地磁盘分区未备份。

关于如何做到这一点有什么想法吗？我知道我可以克隆 NFS 存储库并推送到它，但这似乎是不必要的矫枉过正。

是否可以像在本地分区中创建一个指向远程 NFS 分区中的 .git 目录的 .git 符号链接(symbolic link)一样简单？

Answer 1

您可以使用以下方法创建 Git 存储库:

• 工作树是本地磁盘分区上的当前路径
• 但是 .git dir用 --git-dir=<path> 指定或 $GIT_DIR环境变量并引用您(备份的)主目录中的路径。

git init 命令考虑了 $GIT_DIR环境变量:

If the $GIT_DIR environment variable is set then it specifies a path to use instead of ./.git for the base of the repository.

---

或者，您可以在您的主目录中创建您的存储库，但添加以下 git config :

core.worktree

Set the path to the root of the work tree.
This can be overridden by the GIT_WORK_TREE environment variable and the --work-tree command line option.
It can be an absolute path or a relative path to the .git directory, either specified by --git-dir or GIT_DIR, or automatically discovered.
If --git-dir or GIT_DIR are specified but none of --work-tree, GIT_WORK_TREE and core.worktree is specified, the current working directory is regarded as the root of the work tree.

Note that this variable is honored even when set in a configuration file in a ".git" subdirectory of a directory, and its value differs from the latter directory (e.g. "/path/to/.git/config" has core.worktree set to "/different/path"), which is most likely a misconfiguration.
Running git commands in "/path/to" directory will still use "/different/path" as the root of the work tree and can cause great confusion to the users.

---

OP 添加:

Could it be as simple as creating a .git symbolic link in the local partition to the .git directory in the remote NFS partition?

至少，通过设置(如 git-dir 或 core.worktree )，可以在不依赖操作系统特定功能的情况下实现相同的效果，例如符号链接(symbolic link)(这在每个操作系统)

---

2018 年更新(8 年后):Tom Russell添加 in the comments :

It appears that the --separate-git-dir flag is now used to point to .git/ on the NFS server when initializing the repository on the local workstation (NFS client).
Subsequent behavior is odd, though: Changes committed on the NFS client don't automatically propagate to the server, requiring a git checkout -- <file> on the server.

I subsequently figured out that a git reset --hard in the server repo after a commit in the client repo (or vice-versa) is the easiest way to bring a working directory up to date.