将$ HOME放入git而不是符号链接点文件有陷阱吗？

我已经将整个$HOME目录签入Subversion 多年了。其中包括我的所有dotfile和应用程序配置文件，许多脚本，工具和黑客工具，我偏爱的基本主目录结构，一些怪异项目以及大量随机数据仓库。这是一件好事。虽然持续了。

但这已经失控了。在许多系统上，基本的结帐方法是相同的，但并不是所有的东西都适合我的所有机器。在不同的发行版中，它甚至都不能很好地发挥作用。

我正在清理房子-将数据分离出来，将一些脚本拆分为单独的项目，修复一些应该自动化的东西中的损坏链接，等等。

我的意图是将替换为，subversion以git进行的顶级检出$HOME，但我想将其简化为我想在所有系统上拥有的东西，包括点文件，一些目录和一些基本的自定义脚本。

在线阅读时，很多人似乎正在使用symlink方法进行此操作：克隆到子目录中，然后从$HOME存储库中创建符号链接。在$HOME完全版本控制下的十多年中，我不喜欢这种方法的想法，而且我无法弄清为什么人们似乎不喜欢直接签出方法。我需要了解特定于git顶级结帐的陷阱$HOME吗？

_{PS部分是作为良好编码的练习，我还计划在github上公开我的root checkout。令人震惊的是，我允许在不经考虑就共享的文件中收集了多少安全敏感信息！WiFi密码，未口令的RSA密钥等。}

是的，在考虑git管理无关的主目录时，至少有一个主要陷阱subversion。

默认情况下，Git既贪婪又递归。

Subversion会天真地忽略它不知道的任何内容，并且当结帐到达不知道的（或属于另一个存储库的）文件夹时，它会停止处理您签出的文件夹。另一方面，由于名称空间问题，Git会继续递归到所有子目录中，从而使嵌套检出变得非常复杂。由于您的主目录也可能是您签出并使用其他各种git存储库的地方，因此将主目录包含在git中几乎肯定会使您的生活变得一团糟。

事实证明，这是人们将他们的dotfile检出到隔离文件夹中，然后符号链接到其中的主要原因。在您的.NET的任何子目录中执行其他任何操作时，它都能避免git干扰$HOME。虽然这纯粹是一个优先考虑的问题，如果要检查您的房屋是否被颠覆，那么如果使用git则成为必需的问题。

但是，还有另一种解决方案。Git允许使用所谓的“假根”，其中所有存储库机器都隐藏在备用文件夹中，该文件夹可以与结帐工作目录物理隔离。结果是git工具包不会混淆：它甚至不会看到您的存储库，而只会看到工作副本。通过设置几个环境变量，您可以在管理主目录的那一刻提示git在哪里找到商品。没有设置环境变量，没有人会更明智，您的家看起来就像是经典的文件型自我。

为了使此技巧流程更流畅，这里有一些很棒的工具。该VCS家庭的邮件列表似乎是事实上的地方开始，和关于页面有一个方便的收官HOWTO和人的经验的。一路上有一些漂亮的小工具，例如vcsh，mr。如果要将主目录直接保存在git中，vcsh几乎是必备工具。如果最终将您的主目录拆分为多个后台存储，请vcsh与结合使用，mr以快速且不太脏的方式一次管理所有目录。

我不希望我的整个主目录都被检入版本控制，因为这意味着我进入的每个子目录都将具有主目录的版本控制上下文。git checkout在这种情况下，像这样的命令会采取实际行动，如果我不小心从错误的目录运行了某些内容，无论是git其本身还是调用git的脚本，都会引起问题。

它还使您更有可能在仓库中添加不需要的东西，当您将所有内容都签入时，这本来不是问题，但现在变成了问题。如果您不小心添加了一个私钥文件（也许是出于习惯）并将其推送到github，该怎么办？

话虽如此，我认为主要的缺点并不是真正的技术性问题，只是想让我自己摆脱困境。

至于符号链接：您可以将您的存储库克隆到一个子目录中，并具有一个脚本来更新需要更新的符号链接。但是，此脚本所需的维护量可能根本超过了拥有它的好处。符号链接可能会减少工作量。

使用符号链接，您还可以轻松地进行发行版特定（甚至主机特定）的添加，并将其添加到git中。您的symlink-update脚本将忽略旨在用于不兼容平台或不同主机的文件，而仅更新适当的文件。

就像是：

HOMEREPO=$HOME/homerepo
HOST=$(hostname)
UNAME=$(uname)

for dotfile in $HOMEREPO/shared/* $HOMEREPO/host-$HOST/* $HOMEREPO/uname-$UNAME/*
do
    target=$HOME/$(basename $dotfile)
    [ ! -r $target ] && ln -s $dotfile $target
done

就个人而言：我使用符号链接，但不使用符号链接目录。仅其中的文件。这给了我一些灵活性，可以在这些目录中进行站点本地更改（即添加/删除文件）。在新系统上设置帐户非常繁琐，因为我必须手工重新创建所有符号链接。

换个角度来看：自从某个时候以来，我在git下有$ HOME，并且没有发现任何缺点。我显然不将此git repo同步到github; 我使用的是带有私人存储库的服务。我也不将任何媒体文件，下载或程序包置于git控制之下。

• git status 是一种“要做的，要清理的”清单。

• 我有一个~/tmp临时的东西，这是忽略不计的。

• 我喜欢看到git status最近安装的软件敢于添加到我的$ HOME中的任何内容，并且经常删除这些文件，甚至卸载罪魁祸首。

• 我将真正有用的本地文件和目录手动添加到中.gitignore，它具有“知道安装时的操作”的好处。

• 如果我构建新的VM或安装新的PC，则只需将远程主目录克隆到$ HOME，并立即获得所需的一切。

• 不再需要像vundle这样的vim插件。

我不喜欢复杂性。当我调整任何rcfile时，我都会执行，提交并推送。然后，作为反射，我隔两天git in $ HOME，并始终具有最新的配置。就这么简单。

当前使用此方案的计算机：家用笔记本电脑，工作PC，工作VM，以及3或4个远程服务器。

我已经尝试过这两种方法，最后都倾向于使用symlink方法：

• 签到任何地方
• make install
• 注销并再次登录以加载X设置

缺点：

• 在添加文件之前必须将文件移动到仓库
• 必须维护Makefile 中的符号链接列表

好处：

• 不需要大量文件.gitignore（~我谦虚的Ubuntu盒子中有133个点文件）
• 能否保持维护脚本和其他~产权相关的东西（如Makefile和cleanup.sh）的方式进行
• 可以分别控制个人和公共设置的版本

限制条件：

• 与@mrb不同，我仅在中创建符号链接~。这样可以使符号链接保持简单，并使得例如~/.vim以很少的.gitignore维护为代价来注意新文件变得不容易。

最后的两个优势使我的工作规模大打折扣-我不想使主目录杂乱无章，而且我想使私有和公开内容明确分开。

我知道的唯一在处理符号链接方面有（或至少有）问题的应用程序是Pidgin-它不断用普通文件覆盖我的符号链接。

这是一个：如果您尝试执行此操作，git rebase -i --root并且已在.gitconfig存储库中的第一次提交中签入，则git将暂时删除该.gitconfig文件，这又将使其无法完成变基操作，因为它需要您的姓名和电子邮件才能执行该文件存储在该文件中。

您可以再次配置它们并执行操作git rebase --continue，但是在完成并完成了变基操作之后，我的git存储库获得了一个空的提交，而之前没有提交消息，而该提交以前是存储库中的第一次提交，我不知道如何摆脱。

我不知道如果您改git rebase -i <commit>而会发生什么情况，并且.gitconfig在之后进行任何提交都会被检入<commit>。

也许最简单的解决方案是避免添加.gitconfig到存储库中，而是将其列出.gitignore。

这是我的方法：

1. 安装一个干净的Linux（不是必需的，但是在第4步中使生活更愉快）
2. 安装etckeeper
3. git init在家里跑
4. 创建.gitignore并添加所有您不感兴趣或可能会发生很大变化的内容。一定要添加的东西一样*.cache，*.lock等我不建议加/*因为当您在家里添加新物品时，不会自动收到通知。这是黑名单方法与白名单方法，在这里我基本上要保留所有软件的配置，除了易失性内容和一些我不在乎的软件。以后合并，迁移或比较系统时，能够区分所有内容非常方便。与仅存储.bashrc和其他一些dotfiles相比，您可以更快地设置新系统。这样，您将保留可能通过GUI进行设置的配置，并且不知道哪些点文件存储设置。（如果事实证明您已经提交了易失性文件，则仍然可以告诉git假定未更改）
5. 跑 etckeeper init -d /home/username
6. 跑 git commit -d /home/username
7. 在您的shell中设置别名以使命令行更好，例如 homekeeper checkout

使用etckeeper的原因是它将存储诸如文件许可权之类的元数据（对于某些事物（如ssh密钥）尤为重要）。现在，您应该有一个预提交挂钩，它将自动保存元数据。我不确定结帐后的服务。您可能应该使用，etckeeper checkout xxx -d /home/user我将对其进行更多研究并详细说明此答案。

我在主目录上使用Git的主要问题是Git不存储文件属性，例如文件许可权和时间戳。对我来说，重要的是要知道何时创建某些文件，这对您而言可能是，也可能不是。此外，丢失对文件和目录的权限.ssh是有问题的。我了解您计划.ssh不使用Git，但在其他地方，权限可能很重要（例如未压缩的网站备份）。

如果您需要将文件部署到其他计算机上，则基于git的解决方案特别有用，如果您拥有所有计算机都通用的部分以及某些计算机特定的部分，则基于git的解决方案尤其有用。您可以制作多个存储库，并使用诸如multigit或vcsh之类的工具将它们克隆到同一目录（在本例中为您的主目录）。