2

我有一个 git 问题，答案应该在 stackoverflow 上的某个地方，但我找不到。

想象一个团队正在使用 sass 或其他构建文件处理某个项目。多个开发人员构建文件，我们希望对构建的文件进行版本控制，以防非开发人员想要克隆并签出项目而无需先构建。

但是在项目中包含构建的文件总是会产生合并冲突。

我们可以忽略本地更改，只让首席开发人员不时检查他的版本。

忽略可以使用用户定义的 .gitignore 文件或使用：

$ git update-index --assume-unchanged path-to-file.css

但这在拉动时会产生问题。

$ git pull

remote: Counting objects: 30, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 16 (delta 11), reused 16 (delta 11)
Unpacking objects: 100% (16/16), done.
From github.com:User/MyProject
   4e1s389..a231344  development -> origin/master
Updating 63sdf04..a231344
error: Your local changes to 'path-to-file.css' would be overwritten by merge.  
Aborting.
Please, commit your changes or stash them before you can merge.

一种解决方法是始终检查文件，例如使用别名：

git config --global alias.cobuilded 'checkout path-to-file.css'

然后经过一些工作和建设：

git cobuilded
git commit -am "work done"
git pull
git push

但是对于这个问题应该有某种更简单的解决方案，对吧？

git ignore-this-file-and-always-merge-theirs-from-origin path-to-file.css

我已经找到了这个问题和一个可能的解决方案来始终合并他们的问题。但就我而言，合并之前的拉动已经失败......

4

1 回答 1

1

通常这是一个很好的理念： 不要签入生成的文件。

相反，提供一个发布区域或者——更一般地说——一个发布机制来满足你的客户（也就是消费团队）。

一般来说，您正在寻找的是部署系统，而不是版本控制系统。不过，您可以将两者结合起来。git 不是一个部署系统。虽然无可否认它可以走很长的路，但这个方向有一些扩展，我自己有时会出于方便而故意滥用它。

一种方法是使用自动构建系统，每次在某个分支上发生提交（或推送）时都会触发该系统。有可用的“持续集成”工具的开源工具。Git 提供了钩子来触发操作，例如推送到 repo: $GIT_DIR/hooks/post-receive。这是一个自动发送电子邮件的绝佳示例，可以对其进行修改以将发布导出到文件系统区域。之后，您可以在该区域触发构建过程。

或者，您可以修改现有的构建过程以包含最终构建目标。这会将构建目录的副本导出到发布区域。只有在测试通过时，才应手动触发目标。

您的项目可能包含一个版本控制文件，称为“材料清单”（例如“release.bom”），其中列出了在发布发生时应复制到发布区域的所有文件（带有相对路径）。这样，您可以避免不小心将发布区域与那些没人感兴趣的对象或临时文件弄得一团糟。

如果它只是供其他团队内部使用，也许一个简单的rsync，可选的--exclude-from=FILE选项和 git 控制下的排除配置文件就足够了。搜索“rsync 过滤规则”以获取有关其语法的更多信息。

于 2015-12-18T08:21:46.887 回答