使用源代码管理时处理敏感数据的最佳方法是什么？
最近，我开始使用 codeplex.com 来托管我正在做的一个项目，我想与人们分享这个项目。我是使用源代码控制和开源处理的新手。
我的应用程序处理 Twitter，当然我必须使用 Twitter API 密钥。
我使用 Visual Studio 2010 和 TortoiseHg 作为源代码管理。
所以我的问题是：如何在不共享 API Key 等敏感数据的情况下推送代码？ 我不应该分享这些密钥，对吗？ Twitter API 密钥、TwitPic API 密钥、Plixi API 密钥...
每次推送代码之前都必须清理敏感数据吗？
另外，您能否告诉我在哪里可以学习使用源代码管理的最佳实践？
Recently I started using codeplex.com for hosting a project I'm doing which I want to share with people. I'm new to using Source Control and Open Source treatment.
My application deals with Twitter, and of course I have to use Twitter API keys.
I'm using Visual Studio 2010 and TortoiseHg for the source control.
So my question is: How can I push the code without sharing the sensitive data such as the API Key?
I'm supposed not to share these key, right? Twitter API keys, TwitPic API Key, Plixi API key...
Do I have to clean the sensitive data every time before pushing my code?
Also, could you please tell me where can I learn best practices for using source control?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您应该将所有敏感信息外部化到专用属性文件中。该文件应从源代码管理中排除。大多数（如果不是全部）源代码控制系统将允许您将文件标记为不进行版本控制。我不太了解 Hg，但 .hgignore 似乎就是这个地方。
当涉及到从存储库中删除信息时，所有源代码控制系统都特别烦人。我们几乎可以认为它们是为了记录项目的完整历史而创建的；-) 因此，一旦错误提交，请准备好更改您的 API 密钥（我从来没有做过这样的事情）。
编辑，因为我似乎不够清楚：
最重要的部分是将敏感信息与标准信息明确分开。您应该拥有一个包含敏感信息且仅包含敏感信息的文件。然后将此文件标记为“未版本化”。如果您不这样做，您最终将不可避免地提交您的敏感信息。而一旦他们出来了，就几乎没有办法让他们消失。
另一种方法是加密敏感数据，提交加密数据，并使解密密钥仅存在于服务器上（或位于远离版本控制系统的其他一些精心控制的位置）。我们实际上在我工作的私人银行中使用了这个解决方案，这样开发人员就无法访问生产系统的密码。
You should externalize all sensitive information into a dedicated property file. This file should be excluded from source control. Most (if not all) source control systems will allow you to mark a file as not to be versionned. I dont know specifically about Hg, but .hgignore seems to be the place.
All source control systems are particularly annoying when it comes to removing informations from the repository. We could almost think that they were created to record the full history of a project ;-) So be ready to change your API key once it gets commited by mistake (not that I have ever done something like this).
Edit as it seems I wasnt clear enough :
The most important part is to clearly separate the sensitive information from the standard informations. You should have one file that contains sensitive and only sensitive information. Then tag this file as "not versioned". If you dont, you will invariably end up commiting your sensitive informations. And once they are out, there is almost no way to make them disapear.
One other way is to encrypt sensitive data, commit the encrypted data and have the decryption key only present on the server (or on some other carefully controlled location, far from your version control system). We actually use this solution in the private bank where I work, so that the developers dont have access to the passwords of the production systems.