我有一个项目，其中部分代码是公开的，而其他部分则不是。
我在我的企业中的文件夹 E 中拥有完整的项目版本，以及一个放置公共(public)部分的特定文件夹 P。 我认为将硬链接(hard link)放在文件夹 E 中公共(public)文件的文件夹 P 中是个好主意。
因此，通常的工作流程应该是在企业版本文件夹 E 上工作，并偶尔转到文件夹 P 提交公共(public)文件。 (请注意，如果我“单独”工作，效果会很好)
问题是，当我对文件夹 E 中的文件进行一些合并/拉动/ rebase 时，它会替换文件 -> 从而更改其 inode -> 因此文件夹 P 中硬链接(hard link)的文件不会更新!
所以我的问题是: 是否有版本控制系统授权在合并/拉取/ rebase 时不更改文件 inode 的选项？
我使用 git(或 git-svn)，但我同意切换到这个方便的选项。
谢谢
路易斯
PS:我见过这个问题( Git and hard links )，但在这里我想利用硬链接(hard link)来更有效地工作。
最佳答案
我的建议是使用符号链接(symbolic link)；它们不依赖于 inode，而且我知道它们可以在 Subversion 中进行版本控制(我希望使用 git)。对硬链接(hard link)进行版本控制将非常困难，因为工作副本的一部分可能会跨越文件系统边界，这似乎是一个非常糟糕的主意。
关于linux - 从另一个存储库合并/拉取时强制版本控制不破坏硬链接(hard link)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6192634/