时间戳

首页 > 解决方案 > 从其他机器上删除以前的 .gitignored 文件的最佳方法是什么？

git - 从其他机器上删除以前的 .gitignored 文件的最佳方法是什么？

问题描述

我有一个项目，它在启动时将三个文件 A、B、C 之一从一个地方复制到另一个地方（取决于项目配置）。这个复制的文件 X 是 .gitignored 并且始终具有相同的名称，并且只有原始文件 A、B、C 被提交给 git。我现在正在删除这个复制逻辑，并且需要确保这个 .gitignored 文件 X 被从其他人的机器上删除。最好的方法是什么？

到目前为止，我有几个想法：

  1. 保留.gitignore，不要删除文件 （乱七八糟，我不想这样做）
  2. 更新项目启动逻辑以始终删除文件（如果存在），然后在它在大多数开发人员机器上运行几周后删除该逻辑，并发送消息告诉其他人如果看到它就删除它 （有点奇怪，但这首先匹配文件在所有其他机器上的创建方式。但必须发送消息并不理想）
  3. 提交文件，然后删除文件 （这可以工作，但感觉很奇怪。1）我不知道这将如何在所有开发人员机器上工作，因为我们正在添加然后删除一个已经被忽略的文件，2）不同的机器有这个文件的不同版本，我不想弄乱历史）。

有没有其他人遇到过这类问题并知道是否有明显的最佳答案？我正在寻找最简单的部署机器（文件实际上已删除）和我们所有的开发机器（人们不必处理一些刚刚弹出的新的未跟踪文件）。

标签： gitgitignore

解决方案

在您列出的三个想法中，#2 是唯一实现目标的想法。

特别是，提交文件，然后提交删除，确实在一种特定条件下工作：其他人检查文件存在的提交，然后检查文件不存在的任何提交。第一步——可能需要他们绕过 Git 关于破坏未跟踪文件的反对意见——将提取的文件放入 Git 的索引中。随后切换到文件不存在的提交是 Git删除文件的原因：它在他们的工作树中，并且与索引副本匹配，切换到另一个提交表示删除文件，所以 Git 删除与索引副本匹配的文件，同时它也在删除索引副本。

如果此存储库克隆的其他用户直接从缺少文件的提交a123456（或任何可能的哈希 ID）跳过b789abc到继续缺少文件的最新提交（即使中间提交deadbeef提交文件），他们的 Git 将继续将其工作树中的跟踪文件视为其工作树中的未跟踪文件。如果文件不再列在.gitignore（在 commit 中b789abc），他们的 Git 随后会抱怨未跟踪的文件，但不会删除它。

（顺便说一句，这更多地证明了 Git 不是部署系统。部署系统将提供创建、删除和/或存档此文件 X 的方法。）

推荐阅读