0

我有一个看起来像这样的项目：

src
build
  | - build.xml
  | - build.properties

build.properties 文件在每台开发人员机器上都会有所不同。

通常，我们的团队方法是永远不要提交 build.properties 文件，除非已向其中添加了新属性。

这种解决方案并不理想。这意味着每个开发人员的属性文件都没有版本控制，除非他们做了一些棘手的事情。

在 Git 中有处理这种事情的标准方法吗？

同样的问题适用于：

  • 属性文件
  • 项目设置（eclipse中的特殊性）
  • 其他应该保留和版本化但永远不会推送到其他开发者机器的更改

谢谢！

编辑：如果文件没有出现在这里也会很甜蜜：

# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   .settings/org.eclipse.wst.common.component
#   modified:   .settings/org.eclipse.wst.common.project.facet.core.xml
#   ...many more
4

2 回答 2

0

如果您在 Linux 上，开发人员可以将这些文件存储在单独的本地存储库中，然后将它们符号链接到开发存储库中的正确位置，并将它们添加到那里的 .gitignore 文件中。但是，这将使开发人员有责任前往他们的设置存储库提交更改，因为开发存储库不会提醒他们设置文件已更改。

如果这些可以捆绑到一个文件夹中，它们可以在本地成为一个子模块。然后至少会有一些通知，设置子模块中有“更改”。这样做的好处是您可以让构建和其他设置与代码保持同步。我不知道这有多相关，但您可能会更改代码以要求更改例如编译设置，这将使这些在每个开发人员的基础上通过历史联系在一起。

于 2013-06-10T21:44:08.127 回答
0

我最终做的是提交分支上的所有文件devEnv-Jake。然后，当我想把它们拉进来时，我运行jake-mergeDevEnv-git它的别名：

alias jake-mergeDevEnv-git='git merge --no-ff --no-commit devEnv-Jake ; git reset'

缺点是您必须小心不要将这些文件提交到您正在处理的分支。

于 2014-04-23T21:22:28.260 回答