Sitecore内容变化的跟踪显着偏离既定规范。了解Sitecore中版本控制和工作流程的细节，该产品是对这些发布工具的回答。
在出版界，实时跟踪内容变化很常见，可能是由于Microsoft Word自身的跟踪功能普遍存在。传统上，文档被版本化并从一个人传递到下一个用于批准和编辑，每个编辑被跟踪并识别进行更改的内容作者。
在Sitecore中，版本并不像上面概述的那样深入。Sitecore版本确实存在，您可以将项目的一个版本与另一个版本进行比较，但Sitecore中不存在通常在发布世界中看到的更改跟踪级别。这不一定是坏事，但应该与您的内容作者沟通，以保持使用Sitecore的工作流程和版本的期望。
在Sitecore中，版本与工作流程密切相关。它们共同确保内容在获得批准之前永远不会存在。让我们使用一个具有三种状态的简单工作流来演示一个Sitecore示例：创建/编辑状态，批准状态和已发布状态。
在Sitecore中创建/编辑状态
版本1
- Bob创建了一个新页面ContentPageA。
- Bob添加了他的内容并将页面移动到Approve状态
在Sitecore中批准国家
版本1
- Sue将ContentPageA视为Approve状态，并开始审阅内容。
- 苏看到了一些轻微的拼写错误，她更新了
- Sue看到了文本的一个主要问题，并将更新的页面（修复了拼写错误）发送回创建/编辑状态以进行返工
- Bob更新文本并将其发送回Approve状态。
在Sitecore中发布状态
版本1
- Sue检查更新，确认内容，并将项目移动到已发布状态。这是版本1的生命周期结束（即：版本1现已上线）
完成该过程后，将只存在一个版本的页面。Bob和Sue所做的所有更改都是针对相同版本的页面。虽然Sitecore确实跟踪上次编辑内容的人，但它并不能识别个人所做的更改。
现在，让我们来看看我们刚创建和发布的项目的编辑。与之前一样，初始工作流状态是创建/编辑状态。
通过Sitecore来创建/编辑状态
版本2：版本2已创建，但版本1仍是该站点的实时版本
- Bob现在对ContentPageA中的内容进行了更新。他将ContentPageA从已发布状态移动到创建/编辑状态。
通过Sitecore来批准国家
版本2：正在编辑版本2，但版本1仍然是网站的实时版本
- Bob通过Sitecore工作流引擎将内容状态移至Approve。
- Sue评论ContentPageA并做了一个小的语法更新
利用Sitecore功能发布状态 - 版本2现已上线
- Sue通过Sitecore将项目移动到已发布状态。
在这些步骤中，您会注意到当Bob和Sue在版本2中更新页面上的内容时，版本1仍然存在。这就是Sitecore确保内容可以在后台编辑（版本2）而不影响内容的实时版本（版本1）的方式。
如果您使用Sitecore的版本比较工具，它将显示版本1和2之间的内容中存在的所有差异，但是，它不会显示谁进行了个别更改。