Git神秘地删除东西（编辑：实际上是django-storages）答案

【问题标题】：Git deleting things mysteriously (edit: actually django-storages)Git神秘地删除东西（编辑：实际上是django-storages）
【发布时间】：2012-02-27 20:26:55
【问题描述】：

问题：有时，但不是每次，Git 都会删除存储库的 static 目录。我们不确定是什么触发了它，但它似乎发生在分支之间合并或有时甚至只是检出分支时。它会在不询问的情况下执行此操作，并吃掉跟踪的文件。

背景：

我有一个（私人）项目，它有几个分支、“发布”、“开发”、多个功能线。
我们两个人（我和@stevejalim）正在处理这个repo。这个问题发生在我们俩身上。
我在 git 命令中纯粹使用命令行； Steve 混合使用了命令行和 Git Tower。
这是一个带有static 目录的Django 项目。我们可能在过去某个时间点将git rmed 到static 目录，或者将其放入.gitignore，但不是最近。并且我们的开发分支的负责人在.gitignore 中没有static，并且在static 中有文件被跟踪。
这种情况很少发生，以至于我们不确定这是我们正在做的事情，还是间歇性问题、Git 的错误或损坏的树
可能仅在将另一个分支合并回 develop 时发生。但是分支总是从develop 分支并返回到develop。但我们不确定。
我们正在使用 git-flow，但在使用非 git-flow 命令时也会出现问题。
作为这种情况何时发生的示例：

1) Steve 有一个干净的（没有对提交或阶段进行更改）且稳定的开发分支。他用git flow release start|finish 剪切了一个新版本，在这个过程中（可能是从master 到develop 的反向合并），整个/static/ 树被删除了。

2) Steve 通过放弃更改来修复删除（实质上是取消删除文件）。但是随后，Steve 简单地从 master 切换回了 development，并且 /static/ 目录再次被删除（这是使用 Git Tower）

3) 有时只是从功能分支合并到作为临时合并进行开发就可以触发它。不过，在删减新版本时似乎确实经常发生这种情况

这可能与我们如何修复 /static/ 目录的 zapping 有关吗？批量取消删除已删除内容的最佳方法是什么？丢弃本地更改或硬重置 HEAD 似乎都无法解决问题。变基可能对我们有帮助吗？

更新我们刚刚通过git add . 再次体验了这一点 - 没有更改分支，没有合并。这对诊断有帮助吗？

这是 Steve 的 .git/config 的内容：

[core]
   repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = git@github.com:foobarbazbam/bar.git
[branch "master"]
    remote = origin
    merge = refs/heads/master
[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 
[difftool "tower"]
    cmd = \"/Applications/Tower.app/Contents/Resources/CompareScripts/kaleidoscope.sh\" \"$LOCAL\" \"$REMOTE\"

这里是.gitignore的内容：

.DS_Store
*.pyc
*.log
*.log.*
*.bak
*~
settings_local.py
/build/
/static_collected/*
/static/uploads/*
/static/theme_files/*
/static/picture/*
pip-log.txt
*.tmproj
*.dot
*.db
*.sublime-project
*.sublime-workspace
/docs/_*

【问题讨论】：

@sehe 这只是一条路过的评论！我会将额外信息合并到问题中。抱歉，这不是公开回购。
@stevejalim @Joe - ok 遗憾的是，您无法链接到有问题的存储库。我会仔细阅读find .git/ -print0 | xargs -0 grep -w static 和git log -- static/，特别是要确保该目录在技术上永远不会为空。 git 不跟踪空目录。另外，我会考虑稀疏结帐或子模块在您的脑海中玩花样。
顺便说一句，您可以通过git filter-branch 删除您不想公开的内容来“提炼”实际问题。如果您可以将其打包在一个小型共享存储库中，它将极大地帮助您获得答案。（见progit.org/book/ch9-7.html#removing_objects）
谢谢sehe - 稍后我会看看你建议的两件事。恐怕我们无法将当前的回购公开，我怀疑我们是否可以在一个小的共享回购中复制它 - 你是否建议从主回购中分叉并大量删除，只留下几个文件？
如果目录在一个分支中被删除，而在另一个分支中没有修改，则在合并时将被删除。会不会是这个原因？

标签： django git amazon-s3 git-branch django-storage

【解决方案1】：

好的女士们，先生们，我要公开道歉。 Git 不应该受到责备。我将把这个问题留在这里作为其他可能通过相同方式的人的教训。

我们使用了 django-storages 后端（一个“插件”，使 Django 能够透明地在 Amazon S3 上存储文件）。这有一个名为HashPathStorageTest 的测试。此测试的拆解删除了设置为./static 的settings.MEDIA_ROOT。这是错误的，在我看来。它没有它没有创建的业务一揽子删除文件。

在签入之前，我们像好公民一样运行我们的测试。大部分时间我们只为我们的代码运行测试，但偶尔我们为整个项目（包括 3rd 方插件）运行测试。这正在产生问题中的行为。因为我们同时运行 test 和 git 东西，所以很难确定哪个命令正在执行删除（并且删除的文件只有在我们运行 git status 时才会出现）。

所以问题解决了。再次，很抱歉诽谤了 Git 的好名声！

【讨论】：

您是否为 django-storages 提交了错误报告？你绝对应该！

【解决方案2】：

这似乎是 git 决定合并到 A) 已删除文件夹 B) 它认为比您要合并到的分支更新的分支。可能有一台具有美国日期类型的机器和一台具有欧洲日期类型的机器吗？或者您的任何测试是否涉及重置机器日期时间？

我愿意

a) 检查您的开发中包含的所有机器的区域。 b) 在您的开发中选择一个固定点，将文件复制出来并创建一个新的存储库，然后从那里开始。

【讨论】：

非常有趣。我们只在两台机器上办理登机手续，它们都是英国时间。时间从不乱。但也许 git 日志已经以某种方式损坏了，还有一个未来的日期？如果问题变得太大，我们正在考虑在某个时候重新建立（如果这是正确的话）存储库。
git 不关心历史上的作者日期或提交日期，它只关心提交的亲子关系。错误的日期不会导致 git 以不同的方式执行合并。
@CharlesBailey - 那么有什么建议吗？我难住了。（FWIW 日志中没有未来日期）
@Joe：如果无法访问您的存储库和完整的测试用例，这是不可能的。
是的，很遗憾可能就是这样。没有测试用例，因为它发生得太断断续续，无法提出假设。希望得到一些验证建议。

【解决方案3】：

好的，这刚刚发生 - 我将它添加为一个单独的答案，因为它太愚蠢了。我们的 SQL 脚本有一个存储库，一位新开发人员不小心编辑了 .gitignore 以包含 *.sql - 不用说更改已停止在该分支上传播 - 幸运的是，它在开发时间的任何重大损失之前被捕获。然而，这可能会产生上述问题并不是不可想象的——那么你检查过你的 git 指令文件了吗？如果文件夹被忽略（并且 .gitignore 也在其中 - 即被忽略），它可能会消失并几乎通过魔法重新出现。

【讨论】：