当 *.css 文件是从 *.scss 生成时,您是否应该将它们放入 git 中?

发布于 2024-10-31 10:05:36 字数 174 浏览 0 评论 0原文

我开始使用 sass scss 样式表。它们从 *.scss 文件生成 *.css 文件。我的问题是,您将哪些文件签入版本控制?现在,我检查了 main.scss 和生成的 main.css。我想知道是否有一种方法可以仅签入 *.scss 文件并确保在部署时生成 *.css 文件。

I started using sass scss stylesheets. These generate *.css files from *.scss files. My question is, which files do you check into version control? Right now I check in both main.scss and the generated main.css. I wonder though if there is a way to just check in the *.scss file and to ensure that the *.css files get generated on deployment.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

触ぅ动初心 2024-11-07 10:05:36

一般来说,您通常不需要将生成的文件签入源代码管理。只要您的代码生成工作一致,并且您一致地使用它来更新目标 .css 文件,我认为您不需要将它们放入源代码管理中。

也就是说,不将生成的文件放入源代码管理的建议通常更多地针对二进制文件(即从构建生成的库或可执行文件)。这样做的主要原因是二进制文件无法轻松区分/合并,因此如果多个人尝试签入对同一二进制文件的更改,最终可能会遇到无法轻松解决的合并问题。由于您正在处理纯文本 css 文件,因此我认为将它们放入源代码管理中也没什么大不了的,这样您就可以备份实际的目标文件。

In general, you usually don't need to check generated files into source control. As long as your code generation works consistently, and you use it consistently to update your target .css files, I don't think you would need to put them in source control.

That said, the suggestion to not put generated files into source control is usually intended more for binary files (i.e. libs or executables generated from a build). The main reason for this is that binary files cannot be easily diffed/merged, so if multiple people try to checkin changes to the same binary, you may end up with merging issues that cannot be easily resolved. Since you're dealing with plain text css files, I don't think it's that big of a deal to just put them in source control too, just so you have a backup of the actual target file.

白昼 2024-11-07 10:05:36

我更喜欢签入它们。我们从 git 部署到暂存和生产环境,并且在部署到生产时我不喜欢依赖另一个工具/编译。这样,被推出的内容就一目了然了。

I prefer to check them in. We deploy to our staging and production environments from git and I prefer not to rely on yet another tool/compilation when deploying to production. This way, its absolutely clear what is being pushed out.

人事已非 2024-11-07 10:05:36

我喜欢借鉴服务器端开发人员在处理 sass 等已编译前端代码时使用的约定。我将所有源代码与编译代码分开。我是这样设置的:

将源代码放在 src 目录中,在 main/language-name 下,在本例中:

/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss

然后将测试放在相同的测试目录中(不过,您不应该需要任何 sass 测试:

/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever

然后将您的将已编译的代码放在可发布的目录中,如下所示:

/path-to-my-app/publish/css/my-syntactically-awesome-file.css

然后提交整个 shebang (!)

您可以确保始终将 css 放在正确的位置,如下所示:

$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/

现在您是一位出色的程序员了,宝贝!

I like to borrow from the conventions used by server side developers when handling compiled front-end code like sass. I keep all of my source separate from compiled code. Here's how I set it up:

Put your source in a src directory, under main/language-name, in this case:

/path-to-my-app/src/main/sass/my-syntactically-awesome-file.scss

Then put tests in an identical test directory (you shouldn't need any tests for sass, though:

/path-to-my-app/src/test/sass/my-syntactically-awesome-test.whatever

Then put your compiled code in a publish-ready directory, like so:

/path-to-my-app/publish/css/my-syntactically-awesome-file.css

Then commit the whole shebang (!)

You can make sure you are always putting your css in the right place like so:

$ cd /path-to-my-app
$ sass --watch src/main/sass/*.scss:publish/css/

Now you're a mother effing programmer, baby!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文