工作流程：在Git中使用无锁定的二进制文档格式（从Subversion移出）

我们是一家软件咨询公司，为不同客户提供大量项目。传统上我们使用Subversion，但目前正在考虑迁移到Git。

我们生成的文档中有很大一部分与客户共享（需求，全局设计，测试规范等），我们使用MS Office生成这些文档。在Subversion中，我们可以使用其“锁定”功能来确保没有人同时编辑同一文档。在Git中，您无法执行此操作，因为git具有分布式特性，因此它没有锁。

锁实际上只是一种通信机制，但它是一种非常有效的机制。

当前，我们的代码和面向客户的文档通常位于不同svn存储库的不同子文件夹中。转到git时，您会建议我们做什么？我看到了一组选项：

1. 我们将svn存储库移至git 1-on-1。我们不使用Office文件上的锁，而是执行git人们建议的操作，并以某种方式尝试更改工作流以对其进行修复。这可以在任何文档编辑的分支中进行，然后将其合并到审阅中。这种方法突破了例如包含项目管理信息的Excel工作表；他们很容易被团队成员编辑（我们鼓励这样做），但不受任何正式审查程序的约束

2. 我们将git用于代码，将svn用于文档和项目管理。这样做的缺点是，某些更多具有设计意义的文档不会“靠近”其指定的代码，从而增加了人们忘记更新它们的机会。此外，每个人都必须使用和理解两组工具。就是说，对于非面向客户的设计文档来说，这可能是转向基于文本的文档工具（胶乳，降价，HTML等）的绝佳机会。

3. 与1类似，但我们修改了一个git lock命令，该命令执行svn lock对我们所做的事情（适当地切换了只读标志并通过某种方式与服务器同步）。

我不赞成在DVCS中锁不起作用的说法，因为系统甚至在您完全脱机时也可以工作。SVN锁也可以被覆盖。他们是一种沟通机制。没有某种类型的网络连接，您将无法使计算机进行大量通信。

我们不能成为唯一一个对svn lock我们的工作流程适应性非常满意的商店，对吗？

有什么想法或提示吗？

我找到了/programming/119444/locking-binary-files-using-git-version-control-system，但是讨论的内容是技术性的；我正在寻找解决或避免两个团队成员同时编辑同一二进制文件的实际问题的方法。

我建议您使用SVN以获得MS Office文档，这有两个原因：

1. 它已经存在，并且（我认为）对于保留Office文档更好（请参阅此处）。有更多第三方工具可以执行此操作。
2. 尽管可以在Git中实现锁定，但它不是“ Git的一种处理方式”。如果需要这些功能，请坚持使用可为您提供最佳解决方案的工具。

有句我喜欢的话是这样的：“当您拿着锤子时，一切看起来都像钉子”。仅仅因为您要迁移到Git来保存代码，并不意味着您应该使用它来保存文档。

代码版本控制不是处理Office文件的最佳工具，因为它们是二进制文件，并且这些工具可用于文件级修改。

使用协作工具，例如MediaWiki（免费）或Atlassian Confluence（付费），您可以从中轻松提取Word文档。或使用LaTex生成Office文件。

让我扩展...

如果您需要协作，则必须采用一个模型来突出显示对单元（例如文件）的修改（例如，更改单词，改写或仅更改字体）。

SVN和Git，即使考虑到代码，也都是低级工具，可以按文本内容比较其文件。但是问题在于它们只能在文本文件上使用，因为它们不关心文件的性质/内容来提取高级修改模型。

一个清晰的例子是图像文件。尽管TortoiseMerge是一个工具，可以通过比较图像的真实修改来帮助SVN用户，但是正常的VCSes是由内容补丁运行在文件上的。让我解释。TortoiseMerge之类的工具可以告诉您，图像文件的新版本仅更改了几个像素，如果对两个文件实施了更复杂的HSV分析，则仅更改了亮度。您可以添加水印或更改颜色级别，比较图像文件的工具如果实现了良好的比较算法，则会突出显示差异。但是为了检查客户端中的新文件必须产生一个三角洲。增量是一组删除的行和添加到文件的行。二进制文件没有换行符，如果他们不发生有\r\n，如果你改变一个字符要更换整条生产线，或类似的，在其有效载荷，并在三角洲。

所以这就是问题所在。二进制文件不利于版本控制，因为您可能几乎要为每个修订版本替换整个文件。考虑使用MS Office编写Office文件以及使用OpenOffice编辑协作者的时间。如果它们实现的OpenXML文件压缩算法的版本稍有不同，则即使更改了文档中的单个逗号，您也将最终获得完全不同的文件。

协作软件在内部以基于文本的格式呈现文档，因为文本对您的公司而言确实很有意义，并且可以计算差异或处理冲突。LaTex或Markdown是一种将文档存储为具有高级标记的文本文件的方法，因此与没有字体/格式控制的经典TXT文件不同。

但是很显然，您的客户不愿意打开Markdown文件，对吗？好的，您可以简单地（我真正的意思是简单地）使用我目前对Google太懒的任何软件，以便将源文档转换为PDF，Word或其他格式。

总结

如果您开始将文本文件签入源代码管理中，则可以更好地控制文件历史记录，并且可以轻松管理冲突，尤其是在不使用VCS锁的情况下。

在正式共享文档之前，您需要一个例程将源文本文档导出到Office文件

将两个步骤分开可以使人们为学习曲线感到高兴。

您可以将git用于这些文档，而无需添加锁定。选择一个git工作流，如果不在master上，则阻止推送到master分支。（有几种工作流程可供选择。）这将防止人们覆盖彼此对二进制文档文件的修改。假设两个人修改了相同的二进制文件。第一个将其推送到master的更改被保存。第二个将被阻止，因为其副本位于master分支的后面。他们必须先同步。因此，第二个人确实会同步。它将显示二进制文档的合并冲突。该人将其版本保存在某处，并通过从主服务器（由第一人推送）中获取版本来解决冲突。此时，第二个人的文件与master分支是最新的。他们将更改合并到最新的二进制文件中（手动），然后将包含第一人称和第二人称的更改。然后，将新版本推送到master并成为新的master分支。合并是一种痛苦，但是只有在发生冲突时才会发生。而且，更改不会丢失或覆盖。检测到冲突，用户可以彻底解决冲突。

将前两种解决方案放在一起，就不需要第三种。

如果您将电子表格以CSV格式保存在磁盘上，Excel仍会对其进行编辑，然后git很乐意为您合并它们。

同样，如果文件是HTML或（帮助我们）RTF，则可以在Word中打开，编辑和保存文件。当然，Word会比有用的文本增加更多的膨胀，但仍然是git很高兴为您合并的文本。

当然，这些解决方案假定您没有使用或可能离开MS特定功能，这实际上仅是Excel方面的问题。

当然，除非您还要求将Word安装在系统上才能阅读您的文档，这本身对我来说是一个可怕的前景...