我的Django项目的团队希望将设计师的CSS放在一个中心位置，最好是在生产服务器上（这样对于当前的设计有一个“真相”，他声称他过去曾与之合作过的模型）。假设这甚至是一个很好的做法，那就意味着设置Git以将CSS以连续集成（CI）方式部署到生产中。
但是，我想以某种方式限制Git为设计师，以便他不会意外更新除CSS或HTML之外的任何文件。 Python和Django文件将由开发人员更新，他们将以更传统的方式进行部署：在他们自己的分支机构中工作，只有一个人工构建管理器 在测试和准备好时将所有内容合并到主人。
我们希望设计人员能够将CSS部署到服务器的部分原因是避免在他的笔记本电脑上本地设置Django站点（他在CSS，HTML和Git之外并不那么技术）。 / p>
答案 0 :(得分：0)
这个设置是不是一个好主意？如果没有，那么适当的替代方案是什么？
我有一些保留意见。听起来你的设计师将成为唯一一个没有任何关键推动生产变革的人：没有代码审查，没有测试等。持续集成是伟大的，但一个理智的过程包括防止不良部署的安全。由于团队的其他成员正在遵循不同的流程，因此您最终将管理两个不同的管道。这是浪费精力，不可避免地其中一个（可能是设计师）由于缺乏关注而崩溃。
替代方案是让每个人都在同一个过程中。教导设计人员如何在本地运行应用程序，或者构建一个使其更容易的工具。除非你的网站完全是静态的，否则他们怎么能看到他们的变化看起来没有那个呢？也许是培训他们的更多工作，但这是个人成长的绝佳机会。
假设我们设置了主分支的CI配置，并允许将CSS推送到主分区，我是否可以限制设计者修改和检查非CSS / HTML文件的能力？如果是这样，怎么样？
如果你走这条路，你可以使用Git hooks来限制允许设计者提交的内容。您可以在其客户端上放置pre-commit挂钩，或者，如果您控制服务器，则只能为设计人员的用户运行pre-receive挂钩。任何人都可以查看提交的文件并阻止提交/推送（如果有的话不是CSS或HTML）。有一个名为Overcommit的pre-commit框架可能对您有所帮助。如果您正在使用代码审核工具，那么大多数人都可以在机器人中挂钩以留下评论或阻止合并，因为他们修改了他们不应该拥有的文件。
这里的另一个选择是信任你的同事。据推测，他们被聘用是因为他们有效且有用，所以如果相反，每个人都清楚他们应该做什么，并且通常不会做什么，那么你可以节省很多努力来建立限制。拧紧它。