您如何在版本控制下处理开发人员的个人文件？
Posted
技术标签:
【中文标题】您如何在版本控制下处理开发人员的个人文件？【英文标题】：How do you handle developer individual files under version control? 【发布时间】：2010-09-12 02:00:44 【问题描述】：我们存储库中的某些文件对每个开发人员都是独立的。例如，一些开发人员使用本地数据库，该数据库在项目的属性文件中进行配置。所以每个开发者都有不同的设置。当一位开发人员提交时，他总是必须注意不要提交他单独配置的文件。
你是怎么处理的？
【问题讨论】：
【参考方案1】：我们的属性文件位于“properties”目录下。每个开发人员都有自己的“username.properties”文件，他们可以覆盖环境特定文件中的属性，例如“dev.properties”或“test.properties”。这利用了 ANT 的不可变属性（包括个人优先，然后环境属性）。
【讨论】：
【参考方案2】：在源代码管理中保留一组默认值，然后：
让每个开发人员都有一组他们自己管理的可选配置（例如，不保存在源代码管理中）或
让每个开发人员在某种标识方案下将自己的配置保存在源代码管理中（@Dustin 使用的用户名.属性）
将开发人员的特定配置保留在源代码控制中的优势在于可以轻松地从一台计算机迁移到另一台计算机（例如，在硬件故障或升级的情况下）。它是一个简单的 svn co [repos] 和 ant
【讨论】：
【参考方案3】：使用 SVN:Ignore（或其等效项）确保它们没有被检入到您的主干分支中。
【讨论】：
【参考方案4】：我们使用 ant 构建或应用程序，并且我们的 ant 构建文件引用了这样的文件名：
$env.COMPUTERNAME-.properties
此文件中的所有属性都将覆盖主构建文件中的属性（如果存在）。因此开发人员可以创建一个以他们的机器名称命名的覆盖文件，以覆盖他们喜欢的任何属性，例如数据库名称和或 jdbc url。然后可以将此文件签入版本控制
【讨论】：
【参考方案5】：我们只是在开发人员之间保持一个标准。每个人都使用相同的目录、数据库名称和用户，因此我们无需担心这些事情。
亲切的问候
【讨论】：
【参考方案6】：好的，但是例如一个 db-config-file 应该保持在版本控制之下并且不能被忽略。
【讨论】：
用户特定的设置永远不应该保留在源代码管理中（请参阅达斯汀的回答，了解似乎是一个很好的解决方案）。【参考方案7】：如果他们必须在同一个存储库中，请创建一个“dev”文件夹或其他东西，然后为每个开发人员创建一个子文件夹以签入他们的用户文件。
或者有一个单独的用户文件存储库。
或者让开发人员自行决定如何处理自己的文件。
【讨论】：
【参考方案8】：这在之前的帖子中得到了解答。虽然这个问题更针对 WebApps，但实际问题正是您现在面临的问题。
How do you maintain java webapps in different staging environments?
【讨论】：
【参考方案9】：我们的项目的设置与其他项目类似，其中您拥有开发人员独有的某种属性文件，但我认为不应该将特定于单个开发人员的文件签入源代码管理。
我们有一个文件personal.properties 已加载并覆盖任何项目默认值。该文件位于用户主目录中。对于任何特定于用户的值，默认值设置如下：
database_user_name = DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE
开发人员从不编辑该文件，因此不会将用户特定信息检入源代码管理，如果开发人员忘记在其 personal.properties 文件中设置值，您会收到如下明显错误：
Unable to login to database with username: "DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE"
【讨论】：
【参考方案10】：使用模板，你不要将db-config添加到源代码控制（实际上你在他身上使用SVN：IGNORE），并添加db-config.tmpl或db-config.template或db-config.tmp或其他东西这清楚地告诉你它是一个模板。
此文件具有基本配置，旨在复制到“db-config”中（复制后将模板留在那里以接收更新）供每个开发人员自定义。
【讨论】：
【参考方案11】：使用 git 或其他去中心化版本控制系统。然后每个开发人员可以将他的私有更改保留在自己的私有分支中，在该分支上工作，然后从该分支中挑选已完成的功能回到开发的主干中。
【讨论】：
【参考方案12】：它们应该绝对保持在版本控制之下。您可以使用用户环境中的环境变量来检测开发人员特定的属性。以 ant 为例：
<property environment="env" />
<property file="$basedir/online/$env.LOGNAME.build.properties" />
<property file="$basedir/online/$env.USERNAME.build.properties" />
<property file="$basedir/online/default.properties" />
如果您将LOGNAME 设置为“davec”并且存在davec.build.properties，它将覆盖default.properties 中的任何值。
这也有助于检查您的同事配置以开始或诊断问题。
【讨论】：
【参考方案13】：不要将它们置于版本控制之下，并使用工具的忽略功能来防止它们被意外签入。相反，对生成它们的脚本进行版本控制，该脚本可以使用版本控制的数据和本地的非版本-受控数据。这样可以使它们保持最新，同时进行任何适当的本地修改，而不会有这些修改滑回存储库的危险。
编辑：某些文件格式可以选择使用本地覆盖。这些可以签入，但一般来说，许多人不够聪明，无法做到这一点。因此，这种解决方法。
【讨论】：
以上是关于您如何在版本控制下处理开发人员的个人文件？的主要内容，如果未能解决你的问题，请参考以下文章