4
工作流程：在Git中使用无锁定的二进制文档格式（从Subversion移出）
我们是一家软件咨询公司，为不同客户提供大量项目。传统上我们使用Subversion，但目前正在考虑迁移到Git。 我们生成的文档中有很大一部分与客户共享（需求，全局设计，测试规范等），我们使用MS Office生成这些文档。在Subversion中，我们可以使用其“锁定”功能来确保没有人同时编辑同一文档。在Git中，您无法执行此操作，因为git具有分布式特性，因此它没有锁。 锁实际上只是一种通信机制，但它是一种非常有效的机制。 当前，我们的代码和面向客户的文档通常位于不同svn存储库的不同子文件夹中。转到git时，您会建议我们做什么？我看到了一组选项： 我们将svn存储库移至git 1-on-1。我们不使用Office文件上的锁，而是执行git人们建议的操作，并以某种方式尝试更改工作流以对其进行修复。这可以在任何文档编辑的分支中进行，然后将其合并到审阅中。这种方法突破了例如包含项目管理信息的Excel工作表；他们很容易被团队成员编辑（我们鼓励这样做），但不受任何正式审查程序的约束 我们将git用于代码，将svn用于文档和项目管理。这样做的缺点是，某些更多具有设计意义的文档不会“靠近”其指定的代码，从而增加了人们忘记更新它们的机会。此外，每个人都必须使用和理解两组工具。就是说，对于非面向客户的设计文档来说，这可能是转向基于文本的文档工具（胶乳，降价，HTML等）的绝佳机会。 与1类似，但我们修改了一个git lock命令，该命令执行svn lock对我们所做的事情（适当地切换了只读标志并通过某种方式与服务器同步）。 我不赞成在DVCS中锁不起作用的说法，因为系统甚至在您完全脱机时也可以工作。SVN锁也可以被覆盖。他们是一种沟通机制。没有某种类型的网络连接，您将无法使计算机进行大量通信。 我们不能成为唯一一个对svn lock我们的工作流程适应性非常满意的商店，对吗？ 有什么想法或提示吗？ 我找到了/programming/119444/locking-binary-files-using-git-version-control-system，但是讨论的内容是技术性的；我正在寻找解决或避免两个团队成员同时编辑同一二进制文件的实际问题的方法。