问题
将此文件树视为我的开发存储库。
- foo/ - .git/ - [...] - bar/ - backupclient.py - supersecretstoragecredentials.ini
对于开发,supersecretstoragecredentials.ini
需要使用有效的凭据填写 - 而我仍然需要在存储库中保留它的干净版本,以便其他用户可以轻松设置其凭据。
可能的解决方案
.gitignore
supersecretstoragecredentials.ini
并创建supersecretstoragecredentials.ini-example
,
supersecretstoragecredentials.ini-example
复制到supersecretstoragecredentials.ini
。backup.py
中添加覆盖配置文件位置,该位置被git忽略,例如 supersecretstoragecredentials_local.ini
。正如kan所指出的那样,这两种解决方案在工作流程方面相似但并不完全相同。
还有其他选择吗? git
是否拥有某种功能来帮助解决此类问题?
答案 0 :(得分:11)
使用一些占位符值检入supersecretstoragecredentials.ini文件,然后
git update-index --assume-unchanged supersecretstoragecredentials.ini
Git不会跟踪此文件的未来更改。
您可以使用
重置此项git update-index --no-assume-unchanged supersecretstoragecredentials.ini
答案 1 :(得分:5)
您在选项1中描述的内容基本上由内容filter driver的smudge
步骤涵盖。
“How to work on a drop-in library?”问题中提供了两个选项。
涂抹脚本将使用supersecretstoragecredentials.ini-example
(版本化),将其复制为supersecretstoragecredentials.ini
(不版本化,被Git忽略),并从其他来源填充其值
但是除了你将如何实施你的政策的技术方面,主要的措施是确保你的秘密值根本不存储在Git仓库中,而是来自另一个参考。
答案 2 :(得分:3)
我使用你的解决方案(你的两个解决方案是相同的,只有文件名不同)。你有任何问题吗?你期望什么样的功能?
此外,还有一个更有趣的解决方案
git update-index --assume-unchanged supersecretstoragecredentials.ini
希望这就是你想要的。但是,如果上游更改文件并且您正在进行更改(不完全确定是好还是坏),它将会失败。
答案 3 :(得分:1)
根据我的经验,在尝试了问题和答案中列出的所有选项后,您的#2选项已被证明是最简单和最干净的。它以最少的魔力可靠地解决问题,并且最容易理解。这是最好的方式。
答案 4 :(得分:0)
我现在正在试验的东西是git-secrets。
https://github.com/awslabs/git-secrets
它挂钩到git commit进程并检查看起来像不应该签入的凭据的模式。
您必须确保它安装在每个开发人员的系统上并为每个git存储库配置。如果将检查集成到构建过程中,这可以很容易地实现。