版本控制是否参与视频制作工作流程？

我是软件开发人员，并且对摄影（四年）和视频制作（仅几个月）也很感兴趣。

■在软件开发中，每个开发人员在每个项目上都要遵循一条重要规则：所有内容都应受版本控制：源代码，配置文件，数据库架构，文档-所有使您能够从头开始构建项目的内容。这有两个令人愉快的结果：

1. 如果发生灾难，当您失去除版本控制存储库之外的所有内容时，您应该能够继续进行，就好像什么都没发生一样。

2. 如果发生一些愚蠢的更改而对项目产生负面影响，则开发人员可以返回较早的版本。

■在摄影中，我对照片所做的任何更改都将永久存储在Lightroom目录中，从而可以随时恢复到以前的状态。借助虚拟副本功能，Lightroom还可以执行版本控制中的分支：测试不同内容的能力，并保留两个结果或以后删除其中一个。

目录本身并不存储RAW照片，但是无论如何它们都不会改变。

■在视频制作中，情况似乎有所不同。我使用Premiere Pro，After Effects和Soundbooth。

• 似乎没有一个可以永久存储历史记录：如果我误操作并仅在第二天注意到它，就无法恢复以前的版本。

• Soundbooth还会直接更改WAV文件，这需要付出额外的努力才能将原始录音与修改后的录音分开。

• 很少提及版本控制，而且我还没有找到任何人告诉他如何在工作流程中实际使用版本控制。而且，没有人提及应该使用哪个版本控制，并且由于大多数版本控制系统针对文本文件而不是二进制文件进行了优化，因此这带来了另一个挑战。

• Video.SE没有版本控制或修订标签。

因此，我有两个问题：

1. 版本控制是否参与视频制作人员的工作流程？如何整合？

2. 迁移到Adobe Creative Cloud会有所帮助吗？在Creative Cloud中，是否有特定功能可以跟踪Premiere Pro或After Effects项目的后续修订？

备注：为避免偏离主题的答案，我强调指出，我的问题与备份无关，并且特别是关于存储工作的连续修订版本，而没有数据的现场/非现场备份。

在视频世界中，从Git的角度来看，版本控制不是很实用。您将需要为每个音频和视频工具制作一个特定的版本控制工具，因为所有工具都可以使用它们自己的项目格式。但是能够读取这些格式只是一回事，那么您还需要该工具的渲染引擎来显示差异。

尽管所有这些工具都可以以非破坏性的方式工作，除非您预先渲染了一些东西（将其与编译一部分代码的dll / lib进行比较，然后从现在开始使用），因此您通常可以返回通过执行ctrl + z或在某些程序中使用历史记录工具将其升级到旧版本。

虽然保存子版本通常是可行的方法。就像他的答案中所述的刺针或手动完成。

我喜欢做的并且与每个软件都能很好地工作的事情是将我的项目文件（没有源代码）放入Dropbox。如果您的上传速度较快（〜1 Mbit / s），而您的项目文件不是100MB +，则可以在保存下一次之前上传您的项目。Premiere / AE / FCP项目的平均大小约为10-20MB，因此您最近保存的文件将在1-2分钟内上传。如果您有更多的上传带宽，则速度更快。

然后，如果必须返回，则可以访问Dropbox的文件历史记录，然后下载或还原到该修订版。Dropbox将文件修订版永久保存在付费帐户中*（*至少在他们具有Pack Rat选项时，现在是我认为是一年），并在免费帐户中保存30天。我确信还有其他提供类似功能的云托管服务商。这有点像使用git的超级有限版本，该版本可以很好地处理二进制文件，并且不会让人头痛。这样的好处是您不会使文件夹中的文件杂乱无章，并且不会同时进行备份。

大多数云托管者还提供团队成员资格，因此您可以与多个编辑者一起工作。或者您与其他团队成员共享项目文件夹。

只是添加到以前的答复中：尽管在视频世界中没有什么比Git更好的了，但还是有一些数字资产管理/媒体资产管理工具可以或多或少地做同样的事情-版本控制和权限/用户管理（它们也可以（因为它们实际上是作为您的媒体库构建的）。多年以来，我一直使用Apple的Final Cut Server应用程序（现已过时），该应用程序在一个小型邮政机构中与Final Cut Suite（Final Cut Pro 7，Soundtrack Pro等）集成在一起。

我们将其用于版本控制和项目文件的分支，这使多个编辑器可以相对无缝地处理单个项目。由于这是Apple产品，因此可以与Final Cut Pro一起使用，因此可以非常轻松地读取和使用FCP项目文件。即使这样，Final Cut Server的版本控制也依赖于保存整个项目文件的先前版本，它不使用差异。我不知道有任何DAM会这样做，原因是先前的答案已经指出了-专有格式太多了（尽管具有讽刺意味的是，许多专有格式现在都依赖XML作为那些项目文件格式的基础） ）。

FCS之所以出色，是因为它价格相对合理。Premiere Pro从来没有真正类似的东西。不幸的是，如今，您需要进行大量更改才能获得类似的功能-主要是因为这些工具实际上是为邮局设计的，而不是单个编辑器。他们还需要潜在的重要集成/设置。

这里有一些选择（我与这些公司都没有任何关系，这完全基于我寻找相似解决方案的研究）：

• Cantemo：http : //www.cantemo.com/premiereprocs6.html
• CatDV：http：//www.squarebox.com/

版本控制在视频编辑中实际上没有占据太大的位置，因为它本质上是无损的。作为任何NLE（非线性视频编辑器）的核心，输出实际上是称为编辑决策列表或EDL的东西。这与Lightroom中的历史极为相似，因为历史记录是按顺序应用的所有更改的记录。

NLE从源剪辑开始工作。他们采用这些剪辑的起点和终点将它们放置在时间轴中，然后可以按照给定的顺序将效果应用于这些资产（基于效果的放置），但是这些都是编辑决策，并且会即时应用（或可能渲染为临时预览文件）。最终的输出渲染是将整个EDL应用于源剪辑的结果。

您可以保存项目的版本，以便能够返回到EDL的先前版本，但这通常是不需要的，除非您非常有意地尝试使用另一种方法来编辑序列（在这种情况下，无论如何，通常最好选择该时间表的副本。）

如果在首选项中启用After Effects和Premiere，则将自动对项目文件进行增量保存。

这些增量保存可用于还原到以前的版本，这就像版本控制的一个非常基本的实现（不过，您可能希望将版本数从5增加）。FCP内置了“从以前的版本还原”功能，该功能非常适合处理项目文件时使用。After Effects具有（但没有Premiere拥有）可以增量保存项目的功能。可以这么说，当我对项目进行重大更改时，我一直都在使用它，并且希望能够恢复到主干。

为了增加控制力，您可以想象，使用版本控制软件来管理用于保存项目文件和自动保存的文件夹，以便编辑者可以检出当前的剪切并提交更改，只要可以集中访问或复制所有媒体即可。以相同的相对路径进入每个人的机器。它不会像代码一样让您分叉并合并其他人的编辑-这将是一个有趣的功能（我想说它可以用Adobe的extendscript脚本实现，只要您的技能可以重写Java中的Git或SVN）。

作为一名长期的视频专业人士，我可以证明以下事实：大多数媒体工作流程中都严重缺乏对VCS的轻量，强大，透明和开放形式的需求。然而，问题是多方面的，既是文化上的问题，也是技术上的问题。

传统上，我们一直以类似香肠工厂的方式工作，即项目从脚本变为绿色，然后进入生产，一旦包装完成就进入后期生产，然后将最终输出交付给分销部门，然后分销部门分离设备/平台输出。

如今，这种类似于工厂的方法是一种幻觉，在后期制作和发行之间的交接从未明确。对于不同的语言/市场，剪切/编辑有很多来回关系，例如，不要介意为最新格式重新制作母版。然后，出于营销目的，需要访问最终版本...因此，不仅需要远程方，而且可能永远无法见面的人都需要对他们需要使用的版本进行分类，明确的了解是关键。这不仅适用于母版编码，而且还适用于不同市场的该母版的所有版本，以及用于创建每个母版的资产的版本。

直到现在，媒体技术社区才真正关注一个版本的真正含义，并且由于无数种不同的工作流程和关注，它一直在进行辩论。我将其分解为工作版本和发行版本。我们正在努力通过创建一种可跟踪其内部版本的存档文件格式来纠正分发中的这种情况（以打击存在多个工具，平台等的事实），这称为互操作主格式（IMF），请勿与银行），并通过SMPTE进行引导。这样做的好处是，它正在努力在众多数字资产管理系统（希望支持它的数字资产管理系统）之间提供互操作性-我知道有些工作室拥有数百种资产管理系统-这将在内部帮助他们，更不用说进行外部交接。当然，它还没有在生产环境中使用过，因为它被设计为存档级别的格式（Netflix现在正在使用它）。这也是一个非常庞大的文件，除非您有必要的资金来投资这些工具，否则没有简单的创建方法。Netflix确实发布了一个开放源代码工具集，该工具集提供了不错的阅读能力。它也是一个非常庞大的文件，除非您有必要的资本来投资这些工具，否则没有简单的创建方法。Netflix确实发布了一个开放源代码工具集，该工具集提供了不错的阅读能力。它也是一个非常庞大的文件，除非您有必要的资本来投资这些工具，否则没有简单的创建方法。Netflix确实发布了一个开放源代码工具集，该工具集提供了不错的阅读能力。

从工作版本或生产级别的角度来看，我觉得有必要提供一个VCS（也许是git的修改形式），无论大小，任何人都可以利用它来促进远程工作。媒体文件当然比交换代码或库大得多，但是对这些文件做出的决定是关键组成部分。我只是想避免通过来回交换的'file_Final_FINAL_MASTER_version3.mxf'命名约定的命名约定来通过git commits远程测试工作。

我有一个同样的问题，也是一名贸易软件工程师，想到了photoshop的工作。

我们可以告诉视频编辑程序“还原到版本2.5”，进行一些编辑，然后告诉它“还原到版本7”，它能够做到吗？

我发现使用Photoshop可以在历史记录中设置命名版本，并且我认为该版本已保存在文件中...？对于未命名的修订（历史列表中的条目），当对先前位置进行编辑（分支）时，节点将从显示中丢失，并且不会暴露任何更新。

Premiere的新版本似乎具有相似的历史记录，我想它正在朝着相同的内部体系结构发展，其中每个更改都是该项目的另一个副本，与以前的版本共享大多数状态。如果历史记录具有已保存的检查点，则非常类似于git存储：每个版本都包含（共享）对细分定义下的基础元素的（共享）引用。由于视频本身不在文件中，因此它很适合在不增加大小的情况下增长越来越多的版本。

我看到了一个研讨会，Photoshop开发团队中的某人解释了该体系结构。看起来您所看到的历史记录条目类似于git版本，例如gitk显示。版本的命名与git标签相同。你可以指着它恢复到任何可见的修订，重新回来了。但是，进行历史记录本身所做的任何更改就像进行完全刷新（shift或ctrl F5）一样—您会丢失当前分支头或命名标签未链接到的所有内容（但我认为诸如克隆源引用之类的东西仍然存在）指向目前看不见的版本）。

但这不是我要写的建议。我将项目所在的NAS卷设置为每3小时制作一次快照。Windows有一个检查点机制，但我认为它是不可配置的。Mac Time Machine做类似的事情。

通常，您可以存档文件的所有保存版本，并且在Premiere中不包含所有导入的（常量）资产，因此即使不使用增量仅保存更改的内容也可以将它们全部保存。

只是重新学习Premiere并在尝试方面变得更具攻击性，我深信如果下次进行此工作时我可以退缩，我后悔自己做过的事情，或者找到了更好的方法并且想再次尝试。那是一个有效的修订版本控制系统。在NAS上执行此操作时，我还可以防止BSOD在保存时破坏整个项目。:)

更新历史记录的时间很短，默认为32个条目。加载项目时为空。但是，自动保存不仅可以像在大多数程序中看到的那样保存相同的文件；而是给它们编号并保留它们。因此，我可以看到文件时间戳并加载较旧的副本，这为我提供了15分钟检查点的版本历史记录。在我的情况下，每个文件是44K，这是没有什么比资产大小-这是76毫秒的音频，或帧的1/7规模10级 SD卡录像。

如果您想保留一个有意义的名称作为检查点，只需将副本另存为。但是，设置为高频率的自动保存可用于重新访问任何状态（到那时粒度），而无需事先计划，而无需付出任何努力。

给那些不熟悉版本控制的非工程师的注释：除了能够以明显的方式回溯您的工作之外，我还经常使用它来检查刚更改的内容，或者与开始当前任务之前的状态进行比较，或与小组共享的最后一个版本进行比较。

由于Premeire现在支持在工作空间中打开多个项目，因此有一个窗口布置工作空间设置来比较两个时间线是可行的。也就是说，更有效地利用具有这些版本，不只是备份。我经常告诉不使用git的程序员如何使其成为通用工具，例如文本编辑器。

我想知道专业的电影摄制者如何处理版本控制（如果仅是临时的）？自动保存设计似乎是有目的的，并且集成的脚本编写组件软件工具确实具有显式的可见修订跟踪。

对视频文件本身进行版本控制是不切实际的，因为首先，它们很大，其次正在移动（您要保留每一帧吗？），其次，它们是不可变的。也就是说，原始文件在编辑时永远不会改变。

但是对项目文件的版本控制非常有意义。目前，每次重大更改后，我都会创建一个新的项目文件，并为其提供一个描述性名称-我做了什么，我添加了什么，删除了什么。本质上，我必须通过文件名手动维护历史记录。将项目文件置于版本控制下是一个好主意，为什么我以前没有想到这一点！