如何在不共享敏感信息的情况下从github推拉？污渍和清洁？

当我从github拉入服务器存储库时，我希望避免覆盖某些文件中的本地化敏感信息，例如config.php

注意：它不是一个开源类型的回购；我完全控制了存储库，我是唯一的用户，它是私有的，但关键是，它基于一个开源框架，可能会改变配置文件的结构。我只是希望能够从它拉到测试、登台和生产，而不是意外地让生产的配置在测试中结束，等等。但是我不能重新编码配置文件以从其他地方拉数据，如果框架得到更新，那么在以后会出现困难的合并情况

理想情况下，我希望能够告诉Git，在从REPO_URI获取时，在拉取时，始终丢弃可能会更改当前在文件路径第24行上找到的信息的任何大块。然而，如果我错了，我想这是不可能纠正我的

但是，除非有人能提供一种方法来实现上述目标，否则请阅读下面的解决方案，并让我知道这是否是实现这一目标的理想方法：

我会使用关键字扩展。下面我将描述我将如何做到这一点，然后在底部问一些关于这种方法的问题

方法说明

首先，我将编写两个脚本，sensitive_values_inserter和sensitive_values_remover，它们将github repo master中的某些伪关键字与特定的敏感信息（如密码、用户名、数据库路径等）交换：

#! /bin/sh -f
sed -e 's/@USERNAME@/dummyvalue/' -e 's/@PASSWORD@/dummyvalue/' $1

等等

其次，我将为这个脚本制作三个版本，每个环境一个：测试/登台/生产。每个版本将包含与其所属环境相关的特定密码、用户名和数据库路径，而不是伪值。我会将这些脚本中的每一个放置在相对于这些代码存储库的路径中，如下所示：

/live/filters/sensitive_values_inserter
/live/filters/sensitive_values_remover
/live/repo/{LIVE}
/test/filters/sensitive_values_inserter
/test/filters/sensitive_values_remover
/test/repo/{TEST}
/stag/filters/sensitive_values_inserter
/stag/filters/sensitive_values_remover
/stag/repo/{STAG}

每个过滤器都有相关设置的特定值

然后，整个回购协议的配置将被修改为：

$ git config filter.infosafe.smudge '../filters/sensitive_values_inserter'
$ git config filter.infosafe.clean '../filters/sensitive_values_remover'

最后，在服务器存储库中执行以下操作：

$ echo 'config.php filter=infosafe' >> .gitattributes

这样，每当从主服务器拉取时，如果我理解正确，这些过滤器将用我想要使用的值替换虚拟值

注意：如中所述，要使其正常工作，在按上述方式设置所有内容后，您必须：

cd /path/to/your/repo
git stash save
git checkout HEAD -- "$(git rev-parse --show-toplevel)"
git stash pop

在签出和隐藏之间，我必须将所有更改提交到执行清理操作的文件中。别担心，在提交它们之后，工作目录中的那些会被弄脏。这有点违反直觉，但它是有效的

我能够成功地推送到github，并且只显示干净的值

有一种更高级的替代技术，涉及到每个分支使用一个.gitignore，每个分支使用两个驱动程序和两个过滤器。这允许在切换到测试分支时清除活动密码，反之亦然。诀窍是在每个分支的.gitignore中调用两个分支的清理器，但只调用作为.gitignore的主分支的涂抹器，因此它会恢复自身的密码。在这种情况下，当推送到github时，所有敏感信息都会被清除，这很好。如果有人感兴趣的话，我可以详细介绍一下

关于此方法和备选方案的问题

我测试了这个，它是有效的。但是

使用git有更好的方法吗？我可能会补充说，忽略包含敏感信息的文件不是一个选项，在合并时忽略对这些文件的更改也不是一个选项，因为我希望能够在保留某些配置值的同时对这些文件进行更改。这就是为什么我不想简单地使用git更新索引——假设文件名不变，就永久性地忽略未来对整个文件的本地修改

---

谢谢。

不管怎样，通常的做法或至少我通常的做法是不把信息放在第一位。例如，用户名和密码来自~/.netrc。如果我将用户名和密码放在~/.netrc中，那么软件将不再有它们。是的，这是一般的想法，如果它们不在软件中，它们就不能进行任何提交。软件可以从用户提供的外部文件中检索它们。只有当软件被编程为这样做时，软件才能检索它们，而对于我所说的软件来说，它不是。对其进行编程以检索值肯定是一种可能的解决方案，但它需要硬编码一条路径，该路径需要根据它是在测试服务器中还是在live上进行更改，并且有这样的变化需要每个分支都有不同的分支，我建议的方法可以避免这种情况。注意，我删除了