☰

总结

tag-icon • tag-icon git ignore sourcetree
总结

我的团队使用 sourcetree 作为我们的 git 客户端。我们的项目中有一个第三方插件。它需要几个配置文件。这些文件无法自动生成。它们存储帐户名称、登录令牌和一些临时选项，这些文件不应共享。但每个人都需要这个文件，否则它会报错。所以现在它们总是停留在我们的“未提交的更改”部分，这很烦人。

我有 2 个选择：

  1. 从 git 存储库中删除这些文件。将它们添加到 .gitignore 中。要求我的所有团队成员使用他们自己的设置将这些文件添加回他们的本地项目。

  2. 看看是否存在“忽略跟踪的文件而不删除它”之类的技巧。

（基本上我觉得如果选项2可行，git应该有一些逻辑，例如“如果本地没有这个文件，则使用远程版本。如果本地有这个文件，则忽略”。这种逻辑感觉很糟糕，容易产生错误。）

答案1

这就是你想要做的事情：

  1. 将要从存储库中删除但保留在本地的所有文件（单独添加或添加到文件夹中）添加到.gitignore。
  2. 执行git rm --cached 放入/此处/你的/文件.ext对于每个文件或git rm --缓存文件夹/\* 如果它们位于文件夹中。（它是 /\* 因为您需要转义 *）
  3. 提交你的更改。
  4. 推至远程。

完成此操作后，你将有效地“忽略跟踪的文件而不删除它们”，将它们从仓库中删除，并将它们全部保留在您的系统中。然后当您的团队提取更改时，他们将提取.gitignore文件及其各自的配置文件不会被存储库中的文件覆盖，因为您已忽略它们并从中删除它们。此外，因为现在新的.gitignore忽略这些文件，每个人都会有自己的版本，而不会显示在“未提交的更改”中。

[编辑]：

重要的提示！

正如@ardila 提到的，请注意，执行此过程将导致所有拉取这些更改的人的文件被删除。为了避免这个问题，只需先备份所有要保留的文件，然后执行将删除文件的拉取，最后恢复备份的文件。现在从现在开始，这些文件将不会被删除或更新为每次拉取时的上游更改（因为它们已经被忽略了）

答案2

似乎找到了一个简单的解决方案这里仅将文件/目录添加到 .gitignore 是不够的，但 git 允许您手动“忽略”对文件/目录的更改：

git update-index --assume-unchanged <file>

如果您想再次开始跟踪更改，可以使用以下命令撤消上一个命令：

git update-index --no-assume-unchanged <file>

要查看已禁用更改跟踪的文件，可以使用（linux/unix）：

git ls-files -v | grep ^[h]

或（Windows）：

git ls-files -v | find "h "

背景：我需要这个来将包含用户数据的配置文件添加到 repo。用户应该拉取该文件并根据自己的系统对其进行编辑，但该文件随后会被 git 忽略并且永远不会提交。

答案3

  1. 从 git 存储库中删除这些文件。将它们添加到 .gitignore 中。要求我的所有团队成员使用他们自己的设置将这些文件添加回他们的本地项目。

如果我正确理解了你的问题，并且所涉及的文件包含身份验证凭据以及特定于站点或开发人员的配置设置等内容，那么这就是可行的方法。

  • 如果有任何如果您的 git repo 有可能被外部或不受信任的实体访问，那么您的身份验证详细信息就不应该包含在其中，因为它们将被泄露给克隆该项目的任何人。即使凭据在未来某个时间点被删除，它们仍可在历史记录中获取。

  • 特定于站点/开发人员的设置不会像身份验证信息那样引发安全问题，但如果涉及多个站点或开发人员，它们仍会引起问题，因为即使你有反对提交/推送对这些文件的更改的策略，也只是时间问题某人提交它们并导致其他人的设置在下次拉取时被更改（或产生虚假冲突）。我对此有亲身经历，这是一个持续的麻烦。在我们的案例中，一些差异是开发与生产设置，以及特定于站点的设置，这给我们的生产系统带来了反复的不利影响。

我见过多个项目使用的一种黑客解决方法是制作已清理的foo.cfg命名副本foo.cfg.default，在 git 中跟踪foo.cfg.default，gitignore foo.cfg，并依靠用户在克隆后复制foo.cfg.default到foo.cfg并自定义它（添加身份验证凭据、个性化设置等）。 在您的例子中，由于配置文件用于第三方插件，因此这可能会起作用，因为它们可能非常稳定。 在foo.cfg.default频繁更改的情况下，这种方法效果较差，因为用户需要注意任何更改并手动将其合并到本地foo.cfg。

答案4

总结

  • 从技术上讲，您的要求是矛盾的。

  • 从更哲学的层面来看，这（似乎）是开源与企业哲学之间的冲突。

  • 无论如何……我会提出一些我想到的事情

技术上

git跟踪或者忽略一个文件。

  • 跟踪非常简单。除了使用 git，什么都不用做！任何文件都可以跟踪。
  • 忽略几乎同样简单 - 只要确保它与 gitignore 文件中的内容匹配即可。
  • 但你不能同时做这两件事！！
  • 主要警告：将文件从跟踪文件移至忽略文件并非易事——简单地将合适的模式添加到 gitignore 中并不能解决问题。相关的

最佳实践

不要在没有创建适当的

  • gitignore
    也相关
  • gitattributes

因此第一个（有点不切实际）

建议 1

  • 开始一个新的 git 项目
  • 制作正确的 gitignore 和 gitattribute 文件
  • 如果需要调试git 检查忽略
  • 复制、添加、提交您的普通文件
  • 复制、添加、状态为不被跟踪的文件。状态应该是干净的

但正如我所说，这似乎不是你想要的，因为你确实想要某种共享但未跟踪的文件。所以你需要

取消跟踪文件

你实际上想要一个 git

克隆后钩子

这是尝试这里

但馊主意正如解释的那样这里

这让我想到

哲学差异

  • 企业雇主有理由控制其员工程序员的工作内容和方式。这需要各种机器控制
  • 位于 GitHub 上的随机开源软件控制着其他随机人员的机器，这是不道德和非法的。

因此，如果你是财富 500 强企业中的大玩家，那么自然的选择就是 fork git 本身，并在 fork 中添加后克隆钩子功能

更合理，也只是稍微不方便

解决方案 2

  • 编写自己的克隆后但可手动调用的脚本
  • …如果不存在则复制，如果存在则保留
  • 并向您的团队添加一个（手动）步骤：（1）克隆（2）调用脚本
  • 别忘了 gitignore！！

如果这个解决方案有意义，那么你可能实际上更喜欢

解决方案 3

反转git 内部脚本到git 内部脚本

例如要求你的团队只下载/复制并运行一个脚本

  • 运行git clone
  • 检查这些其他文件的存在/适当性
  • 如果有必要的话，创建/下载它们（可能来自独立于主存储库的来源）

相关内容