是否有版本控制系统具有“持久的仅本地更改”功能?

您可以在GIT中使用一个主(或“供应商”)分支和本地分支来实现这一点。您的本地提交在本地分支上进行,当它发生更改时,您可以在master上重新设置它。如果不为本地分支指定远程,则无法意外地推送它;如果意外地将要持久化的内容提交到本地分支,则只需选择“主控”并从中推送即可。

可以忽略版本控制中的任何配置文件。这是 .gitignore 文件。

例如,如果要忽略所有日志目录,请向该文件中添加一行:

log/*

要忽略.ds_store文件,请添加一行:

.DS_Store

然后可以在本地更新该文件,在已修改但未提交的文件中永远看不到它。如果你做了一个 git add . ,它不会添加到提交中。

如果您需要将配置文件放到git中,但只保留一个密码或var,我要做的是在配置文件中调用一个远程文件。这个文件包含我的密码。

例如,在rails项目中,我的数据库配置如下:

production:
 database: project_database
 username: database_user
 password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %>

文件“path/to/my/password/file”不在版本控制中。
所以我的配置文件是versionned。但密码取决于我们所在的机器。

它还有一个优点,就是版本控制中的密码不会被任何人读取。

这对visual studio来说可能更具体一些,但我认为大多数ide都会有一些类似的特性。

在我所有的app/web配置中,如果设置针对不同的环境进行了更改,我会将它们拆分为自己的文件,这样我的主配置就如下所示

  <dataConfiguration configSource="Config\Development\dataConfiguration.config" />
  <connectionStrings configSource="Config\Development\connectionStrings.config" />
  <appSettings configSource="Config\Development\appSettings.config"/>

对于每个文件来说

<?xml version="1.0" encoding="utf-8" ?>
<dataConfiguration defaultDatabase="defaultDatabase"/>

之后,我为每个环境DEF/STATED/PROD等创建文件夹,并在每个文件夹中使用不同的子配置文件,这样所有的设置都可以被检查成TFS。我的web部署项目设置为在每个版本配置中拉入适当的文件。稍后,当我配置TFS来管理我的发行版时,只需复制正确的配置就可以很容易地实现。

在这一点上,您可以检查程序的基线,然后当开发人员需要改变自己的事情,只是他们不打算签入,他们可以很容易地使文件不只读和编辑它。

Darcs 提供了这个。您可以将更改的补丁记录到本地存储库中的设置,而不会将其推送到另一个存储库。可悲的是, FAQ states 无法将修补程序标记为仅本地修补程序。

Once可以通过使用第二个存储库来解决这个限制,该存储库只包含对您的存储库唯一的修补程序。

如果可以将多个存储库合并到一个工作树中,则这是可行的。最简单的解决方案是符号链接。

问题(这使得它很难)是VCS想要保留变更集的概念。因此,如果将这样的文件与常规版本控制的文件一起提交,那么这些更改是否属于变更集?在不同的机器上拥有相同的变更集意味着不同的事情,这显然令人困惑。

对于多个存储库,您当然可以在一个或另一个存储库中进行提交。这需要多少本地设置取决于VCS系统。例如,对于svn:externals,您需要使用相同的 file: 存储库在每台计算机上,但它们可以指向不同的文件集。使用symlinks,您可以以任何形式组织它(假设symlink本身没有版本控制)。

我也做过类似的事 monotone ,使用 propagate 命令。

简而言之,我有一个“开发”分支和一个“部署”分支。在部署的分支中,配置有一些不同的设置(一些目录和debug=false)。当我想部署时,我会 mtn propagate 从开发部门到部署部门。然后在服务器上进行拉取和更新,以便工作区从其分支获取最新的更改,其中包括所有新的开发,但要尊重设置差异。

我总是通过努力避免这种情况来解决这个问题。

我尽量使所有的环境彼此相似。唯一不同的通常是登录名,有时是基础设施服务(数据库、消息代理、企业数据服务等)的url。

所有开发人员的开发环境都是完全相同的,并且开发环境的配置被选中,因此开发人员可以从版本控制中检查代码并进行构建,而不需要进一步的摆弄。

检查CI和测试环境的密码和配置,因此构建和部署服务器可以在测试环境中自动生成系统。

生产密码从不签入(这通常是我工作时的法律要求),管理员在生产环境中维护密码文件。

你可以像这样做。

如果从库中签出一个文件并对其进行更改,然后执行“更新”,则会从库中获取该文件的新副本,并对其应用更改。我经常使用这个配置文件。

这与您描述的不太一样,因为每次执行提交时,都必须排除配置文件。我想,如果您忘记在某个时候这样做,您将使用本地更改更新存储库,并给其他人带来一些痛苦。

当您确实需要更改配置文件的“public”部分时,您必须执行单独的签出,以便可以将“public”更改与“local”更改分开。

我也支持克里斯·马里西奇描述的计划。我有几个web应用程序,其中我创建了多个配置文件,程序根据环境动态地决定使用哪一个。

在一种情况下,配置文件包括到外部文件的路径,并且我同时使用Windows服务器和Linux服务器,因此路径名称是不同的。因此,我最终创建了一个“Linux配置”和“Windows配置”,然后根据我正在运行的操作系统进行选择。

在另一种情况下,程序在启动时检查servlet上下文的名称(它是一个jsp/servlet应用程序),然后查找一个名为“WEB-INF/.properties”的文件。如果找不到,则加载默认名称。然后,我使用不同的上下文名称运行开发版本,然后运行生产版本,并且每个版本都自动获取正确的配置文件。

MyMyCar可以将本地文件添加到.ggNebug中,因此被忽略,那么它不会干扰您更改的文件或其他内容。