4

前言

我是 git 新手，几个月来一直在项目中使用它，并决定在 Github 上提供它。我刚刚发现我的备份脚本几乎可以正常工作，所以我已经备份了所有内容，但它很草率。呼……但我希望是 B 计划。

问题

我意识到一些 netCDF 数据文件基本上在版本控制（= 巨大的.git存储库）中被复制，所以我试图通过首先将这些文件扩展名（和一些测试/数据目录）添加到.gitignore根目录中的文件来排除这些文件。这似乎只忽略了这些文件的版本控制，但仍将它们包含在.git存储库中。然后我将它们添加到.git/info/exclude，我相信它会完全从存储库中忽略它们。

对于每一个发现，我首先做了一个

git pull [my_repo] master

然后一个

git push [my_repo] master

在第二次迭代之后（当我认为我只在 .gitignore 中添加了一些东西时），我收到一条错误消息，指出我在需要合并的文件方面遇到了一些问题。我首先.gitignore在 gitHub 上创建了不同的版本，我认为这是问题所在并开始合并。

在第三次迭代中（向.git/info/exclude文件中添加了一些东西），一切都很顺利，但我看到只有我想要 EXCLUDED 的目录出现在 gitHub 上。回到我的磁盘上，其他所有内容都消失了，包括 netCDF 数据文件......

我试过git reset --hard master了，重置后一切都一样。

任何人都可以阐明这一点吗？可能的解决方案？

我似乎找不到类似的问题；不过，我想我不可能是第一个这样做的人。

4

3 回答 3

5

编辑：TL；DR 版本：

如果你在 repo 中找到一个你想要被 git 忽略的文件：

  1. 仅从 git 存储库中删除它

    git rm --cached filesToIgnore

  2. 将文件或通配符规则（例如*.swp）放入.gitignore文件中。然后保存存储库git commit

好的，我没有将它们完全拼凑在一起，但让我们分解一下出了什么问题：

第一个。两者之间没有区别.gitignore，.git/info/exclude除了前者被检入存储库并且用于忽略项目特定文件，而后者用于环境特定文件，例如.swp与 vim 临时文件有关的文件。

考虑到这一点，将文件放入.git/info/exclude文件只会忽略新文件，而不是已经在存储库之外的文件（我假设 netCDF 文件是）

第二。使用git pull，它首先git fetch对远程存储库执行 a ，然后尝试合并远程存储库和本地存储库。为什么这是相关的？因为如果您有任何本地未检查的文件，它会抱怨。这是我猜你看到的错误。

第三。由于您强制合并，您可能最终丢弃了任何未签入的文件。这些都没了。由于它们从未被检入 git，因此 git 不知道它们。

编辑：但是，正如 cHao 指出的那样，git 提交中的任何先前文件仍然存在。使用 .查看您的存储库，git log并使用 . 临时签出其中的任何一个git checkout <checksumNumber>。用于git reset --hard <checksumNumber>将存储库永久重置为该提交。

第四。当您在 git 存储库中找到您想要忽略的文件时，您需要做的是正确的过程是

git rm --cached filesToIgnore

这会将它们从 git repo 中删除，但不会从工作目录中删除。

然后将它们添加到 .gitignore 文件中，提交更改，您应该一切顺利。

于 2013-03-08T17:19:23.450 回答
1

首先……把你的东西拿回来。 master现在是您在工作副本、删除和所有内容中看到的内容。您需要恢复或重置，具体取决于您是否有其他人从该回购中撤出。（如果你不这样做，任何一个都可以工作。不过，重置会给你一个更清晰的更改日志。）

请注意，如果其他人从您的回购中提取了错误的合并，我这样做的方式是一个坏主意。但如果你是唯一一个使用它的人，或者他们还没有注意到......

  • 删除或移动exclude文件。这里显然有些古怪，您必须处理的变量越少越好。
  • git log --summary. 查找删除文件的提交。我将abcd1234在这个例子中使用。）
  • git reset --hard abcd1234~1去提交就在它之前。（您不必将整个 SHA 放入；足以消除歧义。）

你的东西现在应该回来了。如果你是唯一一个使用你的 repo 的人，你可以安全git push --force origin master地覆盖旧的（无效的）头。

如果其他人从 repo 中撤出，则恢复提交不会引起问题。你可以让他们完成你刚刚所做的重置，这会奏效……但如果你不知道谁在拉动，那么这是 Github 上的默认情况。:P

要恢复，而不是git reset上面的，只需说git revert abcd1234. 这将撤消该提交的更改。如果文件在多次提交中以某种方式被删除，请一次指定它们以通过一次提交恢复所有内容。无论哪种方式，您都不再需要--forcewith push 了，因为您的本地负责人仍然是 origin 的后代。

至于是什么导致了这一切……已经在 repo 中的文件不应该只是消失，句号。 .gitignore并且exclude不影响 repo 中已经存在的文件。发生了一些古怪的事情，而且没有完整的历史，几乎不可能准确地拼凑出发生了什么

于 2013-03-08T17:25:18.460 回答
0

我的建议是完全停止使用 git 或 github 并返回使用老式文件夹，并将文件夹的副本保存在云中，并在 USB 上保存另一个副本。

我知道 git 有利于协作，但对于简单的个人项目，我认为它是矫枉过正的。另外，我认为新来的孩子把事情弄得很复杂。.NET CORE、MVVM、MVM、NPM、VUE、REACT、NODE.JS、箭头函数等...

我记得在 2000 年代初期，我是一名 Microsoft 软件工程师，他照本宣科，按照 Microsoft 最佳实践编写所有代码，然后，一切都变得复杂起来，Microsoft 发布了新方法来做同样的旧事情，例如 LINQ to访问数据，当我曾经使用久经考验的企业数据访问应用程序块时。然后他们用模型视图控制器废话而不是 Web 窗体将 ASP.NET 更改为奇怪的东西。然后他们甚至添加了其他前端框架。我理解变化。我知道 IT 是一个不断变化的环境，但我认为为了改变而改变并不是改变的理由。顺便说一句，你知道你今天仍然可以在 UNIX 上运行一个 30 年前的 UNIX 命令，而且它仍然可以工作！我的问题是这样的 当 6 个月后发布“新”的东西来做同样的事情，旧的遗留应用程序可以完美地完成 20 年时，拥有大量投入巨资的遗留应用程序的大型企业如何能够超越水面。我认为 IT 就像没有头的鸡一样到处乱跑，只要考虑到从终端接收输入的 40 年历史的旧大型机类似于现代 JavaScript 应用程序今天使用的 API 调用。40 年前的终端也有“单页应用程序”，虽然并不花哨，但它们仍然是基于后端遗留应用程序“部分刷新”的一页。我认为 IT 就像没有头的鸡一样到处乱跑，只要考虑到从终端接收输入的 40 年历史的旧大型机类似于现代 JavaScript 应用程序今天使用的 API 调用。40 年前的终端也有“单页应用程序”，虽然并不花哨，但它们仍然是基于后端遗留应用程序“部分刷新”的一页。我认为 IT 就像没有头的鸡一样到处乱跑，只要考虑到从终端接收输入的 40 年历史的旧大型机类似于现代 JavaScript 应用程序今天使用的 API 调用。40 年前的终端也有“单页应用程序”，虽然并不花哨，但它们仍然是基于后端遗留应用程序“部分刷新”的一页。

只是我滑稽而真实的 2 美分

于 2021-02-04T02:03:18.453 回答