覆盖的协同场景介绍

对于不同的项目，协作项目组的网络情况会有很大的不同，因而可能会出现无法协同访问、 访问速度慢等问题。这里给出一些现有推进中的解决方案做参考，如有无法覆盖到的场景， 或者其它特殊的需求，欢迎联系工蜂团队。

场景一、统一使用 Git 或 SVN 版本工具进行协同

对于使用同一种版本工具、团队间无网络连通性问题及内容存放无特殊要求的场景，可以根据情况统一使用工蜂提供的内网及合作版 Git、SVN 服务。

场景主要特点

• 工具统一：使用同一种版本控制工具（Git 或 SVN）
• 网络互通：相关协作团队间无网络障碍
• 内容存放无特殊要求：资源可以放在内外部任意的合规环境（如内网版、合作版等）

相关场景

• 内部团队统一使用 Git 或 SVN 进行协作

配套服务及工具

代码管理服务

• 与内网的协作可以统一使用内部提供的服务
  • 工蜂内网版 Git、SVN（适合国内团队主导的项目）
  • 工蜂海外版 Git（适合海外团队主导以及有区域合规管制问题的项目）
• 与外部合作商的协作可使用工蜂合作版

客户端

• 对于 Git 工具
  • 美术、策划等角色使用 UGit 客户端
  • 研发类人员可以使用 UGit 客户端，也可以使用其它 Git 相关的命令行或图形化工具
• 对于 SVN 工具
  • 美术、策划等角色可以使用编辑器内置插件，或者使用 TortoiseSVN 图形界面
  • 研发类人员可以使用命令行，也可以使用IDE内置插件或者 TortoiseSVN 等图形界面

代码加速

如果使用合作版 Git，可以使用 LFSCache 进行资源加速

考虑到职场以及外部合作商的带宽问题，如果资源变更频繁并且需要多人复用，可以在职场搭建 LFSCache 进行加速，能够有效的提升 LFS 资源的下载速度。

注：如果同步的资源无法复用原始文件，比如进行烘焙、构建之类的操作，目的是使用处理过的产物，那么搭建 LFSCache 的意义就不大了。

场景二、内外部团队使用 Git/SVN 工具进行项目的部分协同

内外部协同办公是目前内部比较常见的场景，游戏工作室存在大量的资源需求， 一般都会有一些外部合作商，这些外部合作商的基本上都是以美术资源为主 ，在协同上有大量的资源文件和二进制文件需要同步。

场景主要特点

• 网络不通：外部合作商无法访问内部平台，只能访问公网服务
• 协同工具同为 Git 或 SVN：统一使用 Git 或者 SVN 进行游戏研发管理版本工具
• 内容存放有要求：项目主体内容只允许放在内网，外部只是模型、效果等资源的协同

相关场景

• 与外部合作商使用 Git 或 SVN 进行部分内容的协同（国内外离岸职场、二方公司及高校）

配套服务及工具

代码管理服务

• 内网使用工蜂内网版进行协作（如果主要主导团队在海外，可使用海外版）
• 外部合作商使用工蜂合作版进行协作

客户端

• 美术、策划等角色使用 UGit 客户端或 Git/SVN 相关的图形化工具
• 研发角色可以使用 UGit 客户端，也可以使用其它 Git/SVN 相关的命令行

代码加速

考虑到职场以及外部合作商的带宽问题，如果资源变更频繁并且需要多人复用，可以在职场搭建 LFSCache 进行加速，能够有效的提升 LFS 资源的下载速度。 不过如果同步的资源无法复用原始文件，比如进行烘焙、构建之类的操作，目的是使用处理过的产物，那么搭建 LFSCache 的意义就不大了。

代码同步策略

对于与外部合作商协同的内容

如果不涉及安全合规的内容（如只能放在内网工蜂），则可以统一使用合作版的仓库进行协作，参见详见场景一

对于一些需要自动化同步的内容

如内部通过流水线构建了一些 DLL或者用于验证资源的二进制文件，需要及时的同步给外部合作商验证资源使用， 这种情况可以使用 UGit 同步工具（RepoSync）把内网存放制品的仓库同步到合作版（也可以只同步仓库的部分目录或者文件，按需配置即可）

对于一些敏感型的仓库，只能同步部分内容的

一些内部引擎库或者资源，我们需要只同步其中的一些 Editor 目录源码或者特定资源给到外部合作商进行协作使用，不能同步所有的内容， 可以采取如下方式：

1. 使用 Git Submodule 进行特定目录的拆分，将需要同步的目录拆分为子仓库，但这种方式不适用于目录过多的情况， 而且 Git Submodule 有一定的学习成本，需要考虑团队的认知成本
2. 使用 UGit 同步工具（RepoSync）选择仓库中的某一目录进行同步，将这些目录的文件定时同步到合作版的某一仓库，通过仓库进行授权， 需要注意的是这种方式无法完全保留原有历史，而且如果两边同时修改，容易出现冲突，需要人工干预解决

注意事项

由于合作版需要加入 IP 白名单方可访问，如果外部合作商更换办公地点或者 IP，需要及时申请合作版IP白名单变更，避免无法访问。

场景三、内部使用 Git/SVN/P4 等不同工具的混合协同场景

内部比较常见的一种混合使用场景，主要是由于针对不同的角色，不同的版本管理工具的优劣不同， 常见的情况是研发类的角色如客户端等成员使用 Git，而受限于 Git 的操作和理解成本，美术以及策划更偏向于使用 SVN 或者 P4，核心问题是不同版本工具之间资源同步的问题。

场景主要特点

• 内部协同：涉及到的相关团队都属于内部团队
• 工具不统一：同一个项目使用两个以上的版本管理工具（如引擎源码用 Git、美术策划用 SVN）
• 协作内容不存在交叉：不同的版本管理工具负责管理的内容不存在重度交叉

相关场景

• 项目组的服务端、引擎使用 Git 管理源码，而美术策划使用 SVN 或者 P4 管理美术资源和文档

配套服务及工具

代码管理服务

• Git、SVN 服务可使用工蜂内网版
• P4 服务的使用需要申请 License 并自行维护（建议用工蜂 SVN 替代）

客户端

• 对于 Git 工具
  • 美术、策划等角色使用 UGit 客户端
  • 研发类人员可以使用 UGit 客户端，也可以使用其它 Git 相关的命令行或图形化工具
• 对于 SVN 工具
  • 美术、策划等角色可以使用编辑器内置插件，或者使用 TortoiseSVN 图形界面
  • 研发类人员可以使用命令行，也可以使用IDE内置插件或者 TortoiseSVN 等图形界面

代码同步策略

对于通过流水线构建的一些 DLL以及用于验证资源的二进制文件，或者是需要同步的一些美术资源、数值文件等， 可以使用 UGit 同步工具（RepoSync）进行跨版本的同步

1. 需要注意的是这种方式无法保留原有提交历史，需要避免共同修改，容易出现冲突
2. 尽量减少这种同步，而是通过各个版本工具组装最终构建源码的目录结构，比如使用多仓工具 TMR

场景四、内外部工具混合协同场景（外部工具可公网访问）

在一些场景下，由于一些不可抗力，内外部无法统一工具进行使用，比如内部使用 Git 进行游戏项目研发管理，而离岸外包基地多为美术外包， 对于 SVN 或者 P4 已经有了使用习惯，切换到 Git 进行管理有不小的学习成本，为了保障项目资源的快速推进，选择让离岸外包继续使用 SVN 或 P4 进行管理， 然后通过 UGit 同步工具进行资源的双向同步。

不适用于版本工具间协作内容严重交叉且高频的情况，建议尽可能的按照职能或者目录进行资源的拆分协作

场景主要特点

• 内外协同：涉及到内部团队以及外部合作商，网络环境不通
• 工具不统一：同一个项目使用两个以上的版本管理工具（如内部用 Git、外部合作商用 SVN，或者内部用 SVN，外部合作商用 Git 等）
• 协作内容不存在交叉：不同的版本管理工具负责管理的内容不存在重度交叉

相关场景

• 内部研发使用 Git 管理源码，而外部合作商使用 SVN 或者 P4 管理美术资源和数值文档
• 内部研发使用 SVN 管理源码，而外部合作商使用 Git 或者 P4 管理美术资源和数值文档

  外部合作商包括：国内外离岸职场、二方公司以及高校等

配套服务及工具

代码管理服务

• 内部团队可使用工蜂内网版的 Git、SVN 服务
• 离岸外包基地可以使用外网工蜂合作版或者 SaaS 版的 Git 或 SVN 服务）

客户端

• 对于 Git 工具
  • 美术、策划等角色使用 UGit 客户端
  • 研发类人员可以使用 UGit 客户端，也可以使用其它 Git 相关的命令行或图形化工具
• 对于 SVN 工具
  • 美术、策划等角色可以使用编辑器内置插件，或者使用 TortoiseSVN 图形界面
  • 研发类人员可以使用命令行，也可以使用IDE内置插件或者 TortoiseSVN 等图形界面

代码同步策略

资源的同步主要涉及如下一些场景：

• 外部合作商产出的大量模型、纹理贴图、场景等资源，需要同步到内部项目进行使用
• 内部通过流水线构建了一些 DLL或者用于验证资源的二进制文件，需要及时的同步给外部合作商验证资源使用
• 同一仓库的部分目录需要同步给另一方，又不好进行仓库的拆分的，如一些单独的资源、编辑器目录等

这种情况可以使用 UGit 同步工具（RepoSync）对内外部资源进行同步，可以设置按目录或仓库在不同的版本控制之间进行同步

需要注意的是这种方式无法保留原有提交历史，需要避免共同修改，容易出现冲突