Answers:
我的解决方案与jstam类似，但在可能的情况下，我避免对源文件进行更改。鉴于引导程序的更改将很频繁，因此我希望能够通过将我的修改保存在单独的文件中来获取最新的源代码并进行最小的更改。当然，这并不是完全防弹的方法。
将bootstrap.less和variables.less复制到父目录。将bootstrap.less重命名为theme.less或任何您想要的名称。您的目录目录结构应如下所示：
/Website
theme.less
variables.less
/Bootstrap
...更新theme.less中的所有引用以指向bootstrap子目录。确保从父目录而不是从引导目录引用您的variables.less，如下所示：
...
// CSS Reset
@import "bootstrap/reset.less";
// Core variables and mixins
@import "variables.less"; // Modify this for custom colors, font-sizes, etc
@import "bootstrap/mixins.less";
// Grid system and page structure
@import "bootstrap/scaffolding.less";
@import "bootstrap/grid.less";
@import "bootstrap/layouts.less";...
将CSS覆盖添加到theme.less文件中之后。
...
// Components: Nav
@import "bootstrap/navs.less";
@import "bootstrap/navbar.less";
// overrides
.navbar-fixed-top .navbar-inner, .navbar-fixed-bottom .navbar-inner {
border-radius: 0 0 0 0;
padding: 10px;
}
.nav-tabs, .nav-pills {
text-transform: uppercase;
}
.navbar .nav > li > a {
text-shadow: none;
}
...在您的HTML页面中链接到theme.less而不是bootstrap.less。
每当发布新版本时，您的更改都应该是安全的。每当有新版本发布时，您还应该在自定义引导文件之间进行区分。变量和导入可能会更改。
这也是我一直在努力的事情。一方面，我想使用自己的颜色和设置高度自定义variables.less文件。另一方面，我想尽可能地更改Bootstrap文件以简化升级过程。
我的解决方案（现在）是创建一个附加的LESS文件，bootstrap.less并在导入变量和mixins之后将其插入文件。所以像这样：
...
// CSS Reset
@import "reset.less";
// Core variables and mixins
@import "variables.less"; // Modify this for custom colors, font-sizes, etc
@import "mixins.less";
// Custom Addons
@import "addon-file.less"; // <--- My custom LESS addon
// Grid system and page structure
@import "scaffolding.less";
...这样，如果我想重设Bootstrap颜色，字体或添加其他Mixin，我可以。我的代码是单独的，但将在其余的Bootstrap导入中进行编译。这并不完美，但这对我来说是权宜之计。
bootstrap.less获取我们的自定义文件VS，如果核心较少的文件名发生更改，则可能会更改很多行，等等。此解决方案，使用grunt重新编译了缩小的JS，一切都很好！定制工作无需任何不友好的!important声明！
从我的角度来看，我只是有一个theme.less带有导入名称的文件boostrap.less，并且在我下面覆盖（即使使用LESS似乎不好，但很容易维护）我不想更新的变量值。
这对于在 variables.less
之后，我编译我的theme.less文件而不是关闭bootstrap.less
范例theme.less：
@import "path/to/my/bootstrap.less";
@linkColor: #MyAwesomeColor; 更好的（IMHO）方法是从名为swatchmaker的Bootswatch github项目中借鉴。该项目是专门为构建和管理网站上的数十个Bootstrap主题而量身定制的。
该Makefile项目建立swatchmaker.less（你可以将其重命名为类似customizations.less）。该文件包含大量导入：
@import "bootstrap/less/bootstrap.less";
@import "swatch/variables.less";
@import "swatch/bootswatch.less";
@import "bootstrap/less/utilities.less";您可以将swatch文件夹和bootswatch.less文件重命名为合适的名称。
这很有意义，因为您可以升级Bootstrap而不影响自己的文件。实际上，Makefile还包含用于获取最新版本的Bootstrap的命令。有关更多信息，请参见项目页面上的自述文件。
另外，自述文件还建议您安装watchrgem，当.less文件更改时，gem会自动生成项目。
如果（并且仅在有条件的情况下）您有时间可以像我一样做。我保留了自己的框架的修改版本，并且在框架的每次更新时都阅读了文档并检查了修改源。
乍看起来，此解决方案听起来不太理想，但我有这样做的理由。我不使用一个，而是使用许多框架，最佳实践，重置/规范化样式表等的组合，并且我始终确保不会有任何更新会以我未曾想到的任何方式更改现有项目。
由于以下原因，我正在使用自己的自定义框架。
我得到了与乔尔相同的解决方案：
自定义更少文件
就像上面描述的那样：我为我正在定制的所有Less文件创建本地副本：例如：“ variables-custom.less”，“ alerts-custom.less”，“ buttons-custom.less”。因此，我可以使用一些标准并有自己的补充。缺点是：当要更新Bootstrap时，确实很难迁移。
但是还有其他事情：
替代样式
当四处寻找工作流程时，我经常看到人们建议简单地覆盖样式。因此，您首先要导入标准的Less文件，然后在底部添加自定义声明。这里的好处是：更新到新版本更容易。缺点是：编译后的CSS文件包含所有替代。一些CSS选择器定义了两次。因此，浏览器需要做一些工作以找出实际适用的内容。那不是很干净。
我想知道为什么预处理器不够聪明，无法解决这种双重声明？我在这里缺少更好的工作流程吗？