我们的设计师为新设计创建图形模型，创建初始 html、css 和图像精灵并维护这些文件。在最初的交接之后，我们的开发人员将所有内容都放入 .Net 代码、模板等中。
问题：当我们的设计师接到设计或调整功能的任务时，他们无法从最初的模型 html 开始工作。他们可以访问实时（或测试版）站点并查看源代码，将 html 从浏览器中保存出来，但这很乏味，容易出错，而且很快就会过时。
是否有一种简单的方法可以在构建时或在.Net 中创建的站点的按钮推送（批量操作）上自动创建 html？
难度：一些页面（交易、账户）是 https 的，需要用户名/密码的传递。由于这一切都在测试版网站上，因此以明文形式传递的安全问题相对较少。
你的过程被破坏了。在进行初始转换时，您需要尽可能多地将表示与行为分开，然后设计人员需要能够使用您的模板并访问开发系统。
我只是碰巧现在正在处理同样的问题。首先，让设计人员在开发服务器上编辑实际的 .aspx 文件。让他们在 HTML 上查看源代码并进行编辑，这只会在尝试将其重新集成到代码中时给您带来各种问题（处理用户控件、母版页、动态部件/消息，这些并不总是显示在页等）
至于如何合并更改，这是我们使用的过程：
与设计人员沟通并每天留出时间，您可以将他们的更改合并回您的代码中。在此期间，除了进行合并的人之外，没有人在开发服务器上进行任何更改。
假设您使用的是 Visual Studio 和 TFS - 签入所有更改，使用来自开发服务器的设计器更改覆盖本地工作区中的 .aspx/ascx 和 .css 文件。
使用 TFS 电动工具中的“tfpt”工具撤消对任何实际未更改的内容的签出。或者，您可以只复制实际更改的开发服务器中的文件，但有时说起来容易做起来难。
对于确实有更改的文件，将您的本地版本与 TFS 中的最新版本进行比较，以确定需要合并/更正的内容。
合并所有内容后，将其签入并重新部署到开发服务器。
每天重复。
正如 m.bagattini 提到的，如果您使用的是 ASP.NET MVC，它真的很有帮助。这样，您的大多数 .aspx 文件将是标准 HTML，其中包含一些代码块，而不是您的设计人员可能不知道如何编辑的一堆服务器控件。
如果您避免任何内联样式并坚持严格使用样式表，这也会有所帮助。这样，设计人员通常只会编辑样式表，而不必担心弄乱 .aspx 文件中的代码。
如果调整很少，并且您不希望设计人员出于某种原因访问版本控制系统，则可以让他们编辑其原始文件（同时保留原始文件的副本），并生成一个diff. 开发人员采用diff并手动应用它。
这个过程非常糟糕，我仍然会建议（像其他人一样）你的设计师和开发人员使用相同的版本控制系统，我建议的只是一个快速的解决方法，而每个人都进入新的过程。
I think you should take a look to Asp.NET MVC http://www.asp.net/mvc/ which offers clear separation between code and layout. And probably your designers should use Visual Studio to create HTML and work within the same environment used by programmers.
你在使用版本控制吗？我的设计师可以通过 subversion 访问模板和 css（以及其他所有内容），她可以在需要时进行更改。我们遇到的唯一障碍是合并，我们发现让开发人员进行合并更容易。
我曾与那些对引入的额外步骤版本控制犹豫不决的设计师合作过。注意过去时“工作”的使用。接受这个过程的设计师最终会更了解产品的代码和所有权。
我最近参加了一个会议，其中一个会议是由设计师和程序员共同教授的。他们“配对编程”他们的接口。虽然您可能无法让设计人员和程序员密切合作，但我认为您遇到的问题是更根本的问题。
而不是问，“我可以使用什么工具来为设计人员提供实施时的设计？” 你应该考虑问：
在大多数公司中，都有一堵墙可以移交工作，一旦移交发生，设计师就会对项目洗手并继续前进。
同时，程序员甚至在设计接近完成后才开始查看项目。
程序员应该在设计者开始时就开始，并且在设计过程中，当某种技术或技术可用或不可用时，应该进行管道传输。设计人员应在设计获得批准后继续进行，以便在需要进行更改时（如果有的话）进行更改，因此他们始终拥有最新的设计文件。
整个项目的紧密协作通常会比推墙式方法产生更好的站点，此外，您可能会发现项目完成得更快，因为没有冗长的交接过程，而且来回更少。