我有一个SVN回购，除了标准的Trunk和Branches文件夹之外，还有其他文件夹，如Documents，POCs，Archives等，在同一级别的Trunk中。
这些基本上是＆＃34;非代码＆＃34;我们不希望被版本化的文件/文件夹（它们不是主干或任何分支的一部分）。
我们正在从SVN转向GIT。 GIT中是否有任何约定将这些文件保存在存储库中而不跟踪它们（不使用忽略）？
我正在使用命令git svn clone --trunk=/Trunk --branches=/Branches http://blah.com/svn/repo repo将svn存储库克隆到git存储库中。
答案 0 :(得分：0)
GIT中是否有任何约定将这些文件保存在存储库中而不跟踪它们（不使用忽略）？
没有
从根本上说，Git＆＃34;喜欢＆＃34;每当您签出提交时，使工作树与提交匹配。也就是说，假设您在存储库中提交了badf00d，cafedad和ac0ffee（可能第一个是分支master的提示，第二个是提示分支develop，您只需通过哈希ID查看第三个，暂时查看它。当你告诉Git结账ac0ffee时，Git会查看你的当前提交 - 让我们说badf00d - 和你的新目标提交ac0ffee并说：嗯，根据我的记录，badf00d有文件snort但ac0ffee没有，所以我＆＃39 ;现在只需删除 snort。然后，如果您从ac0ffee返回badf00d或cafedad，两者都有文件snort的版本，则会将其恢复原状。
这意味着如果您选择在＆＃34; side branch＆＃34;中提交Documents/个文件。未在主分支中使用，然后签出侧分支，Documents/文件将全部显示。 （太棒了！）但是一旦你将切换回到主（主或开发）分支，Git将删除所有Documents/个文件。这些文件位于存储库中，因此当您转到拥有它们或缺少它们的提交时，Git知道在工作树中添加和删除它们。
Git的索引最好被描述为，您可以在其中构建下一个提交的提交。当您在Git中工作时，您可以修改工作树中的文件，与任何版本控制系统中的文件相同。但在进行 next 提交之前，必须git add工作树版本将它们从工作树复制到索引中。在那之前，索引中的内容是当前的提交 - 实际上只是运行git diff显示了现在的索引与工作之间的差异 - 树。在git add所有文件的所有当前版本，以便索引与工作树匹配后，git diff将显示 nothing （但git diff --cached或{{ 1}}将显示所有更改：此命令将当前提交与索引进行比较，而不是将索引与工作树进行比较。）
在Git中跟踪文件当且仅当它在索引中时。换句话说，仅当文件 F 将在您进行的 next 提交中时才会被跟踪。您可以通过从索引中删除将文件从已跟踪更改为未跟踪。您可以通过git diff --staged更改未跟踪的文件（存在于工作目录中，但不在索引中）。
以上所有意味着，如果您在工作树中有一个git add目录但在索引中没有，那么它将会围绕着＃34;未跟踪＆＃34;。 Git会抱怨你 未跟踪，因此您可能希望将Documents/添加到Documents/以取消投诉。这不会使文件无法跟踪！它只会关闭投诉，还会阻止.gitignore意外将文件添加到索引。
但是，您如何才能将这些git add文件放到工作树中？
有很多可能性。但是，如果您不希望它们被跟踪（并因此包含在每次提交中），您必须确保它们不会进入您的索引。 Documents/文件在这里会有所帮助，但如果您以任何方式将文件放入索引中，它们将被跟踪。那么，假设您将它们放在存储库中，在一个与当前分支完全无关的特殊侧分支（可能称为.gitignore）中。如果您documentation该分支，文件将显示在您的工作树中，但它们现在将在您的索引中。此外，在该特殊侧分支中不的所有其他跟踪的工作树文件将消失！只要您git checkout主分支处理事情，所有git checkout文件都将从索引（好）和工作树（坏）中消失，您将不再可以看到您的文档。这样有点尴尬。
您可以使用新的Documentation/功能将单独的工作树保存在单独的目录中，以检出git worktree分支。然后，您将拥有documentation而不是./Documentation。现在，您的文档和源可以在同一个存储库中共存，但在独立的分支中。
或者，您可以将所有../alt-work-tree/Documentation个文件放入不同的存储库。然后，您可以使用常规源将主存储库克隆到主目录，将Documentation存储库克隆到主存储库中的Documentation。由于./Documentation子树是它自己的独立存储库，因此您所做的任何事情都不会影响主存储库，反之亦然。
如果需要，您甚至可以将这些子存储库放入＆＃34;子模块＆＃34;。我不喜欢子模块，并试图自己避免使用它，但它们可能对这个特定用途有用。
请注意，如果文档确实没有版本（这似乎不太可能和错误），那么您就不需要版本控制系统了。如果它们是由文档系统（似乎很可能）版本化的，也许你可以让它进行版本控制，而不是将它们保存在Git中。从高层次的角度来看，这是相同的，因为将它们保存在一个单独的Git存储库中 - 唯一真正的区别是你不能将它们标记为子模块，因为Git的子模块是Git库。