这是迄今为止您可以对工作流程进行的最简单的改进，但却是一些开发人员最难解决的改进。当使用其他项目管理工具时，您可能已经将工作分解为小的、可管理的任务。提交应该以完全相同的方式处理。

单次提交应该只与一项任务或票据相关，除非一行代码神奇地修复了几个错误。如果您正在开发较大的功能，请将其分解为较小的任务，并为每个任务进行提交。

使用较小的提交的最大优点是，如果出现问题，您可以更轻松地检测并恢复不良更改。

提交信息描述了您的项目的历史。毕竟，如果提交消息显示“已将高分表添加到菜单”，而不是“打赌你无法在这些新表上打败我的分数！”，那么找到为你的游戏添加高分表的更改要容易得多。

使用 Jira 或 GitLab 等任务票证系统时，最好在提交中包含票号。许多系统可以设置为与智能提交协同工作，以便您实际可以引用票证并从提交消息中更改其状态。

例如，提交内容为“JRA-123 #close #comment task done”会将 Jira 票证 JRA-123 设置为关闭，并在票证上留下注释“任务完成”。

有关设置此工作流程的更多信息，请参阅 Jira 中的文档 或 GitLab 中的 Pivotal Tracker 服务。

唯一需要使用“commit -a”（Git 中表示“提交所有更改”的命令）或其任何对应命令的情况是第一次提交项目时。通常，这是当项目中唯一的文件是 README.md 的时候。

提交应该只包含与您提交到 repo 的更改相关的文件。在使用 Unity 项目时应特别小心，因为某些更改可能会导致多个文件被标记为已更改，例如场景、预制件或 Sprite Atlases，即使您无意对它们进行任何更改。

例如，如果你不小心将更改提交到了其他人正在处理的场景中，那么当他们提交更改并发现需要先合并你的更改时，这可能会给他们带来麻烦。

这是刚接触版本控制的人最常犯的错误之一。重要的是要明白，你应该只将你自己的更改提交到项目中。要了解更多信息，请查看 此博客文章 ，了解如何加快工作流程。

只要有意义，就将仓库中的最新更改拉入到您的工作副本中。孤立地开展工作并不是一个好主意，因为这只会增加合并冲突的可能性。请参阅上表以了解每个系统的典型日常工作流程。

Plastic SCM 工作流程略有不同，因为您可以在集中式、分布式或多站点配置中工作。

多站点配置可以相当独特，每个用户都可以在集中式或分布式工作流程中工作。

请考虑以下示例：

• 两支球队
• 每个团队都有一个现场服务器
• 团队成员在本地或分布在每个站点进行签到，但可受益于近距离现场服务器的速度
• 服务器之间相互推送和拉取信息，以保持完全或部分同步

无论您的团队选择使用哪种 VCS，请确保每个人都能轻松使用它并了解他们所使用的工具。

如果您使用 Git，则不是每个人都需要使用相同的 GUI 客户端。但要优先确保每个人都对 提交 > 拉取 > 推送的 工作流程感到满意。换句话说，他们应该具备仅提交他们需要的文件的知识。

如果您正在使用 Plastic SCM，请鼓励您团队中的艺术家习惯使用 Gluon，这是一个用户友好的 GUI，可以简化他们的工作流程。Gluon 让您决定要处理的文件，无需下载和管理整个项目。它还使您能够锁定文件，以防止其他人对其进行处理。完成后，将文件提交回存储库并根据需要再次解锁。

当处理具有多个发布周期的长期项目时，功能分支对您的工作流程非常有益。通常，团队在同一个 repo 分支上工作，这个分支可能称为 trunk、master 或 main。

当你这样做时，你的整个项目就会沿着相同的时间线移动。然而，将工作分成几个分支会很有用，这样团队才能更有效地合作。

在 Git 中，一个名为 Git Flow 的特定工作流程专注于使用不同的分支来实现功能、错误修复和发布。

因此，如果开发人员开始在独立分支内开发新功能，则完成后它将合并回主分支。同时，另一位队友可以对之前的版本进行修补，或者修复错误，并安全地发布新版本，而不包括任何仍在开发中的功能。

Plastic SCM 还具有 任务分支功能。对于这种模式，您可以为跟踪的每个任务创建一个新分支。而在 Git Flow 中，我们使用功能分支来开发完整的、有时甚至是很大的功能。Plastic SCM 中的任务分支是短暂的。如果一项任务需要多次提交才能完成，那么很可能可以将其分解为更小的任务。

Perforce Helix Core 使用名为 Streams 的系统来促进这种工作流程。当创建一个要工作的仓库时，您需要将其设置为 流仓库类型。然后，您可以使用 Stream Graph 视图 来创建新的流。每个流（主线流除外）都需要有一个父流，以便可以将更改复制回上游。

存在用于不同目的的不同类型的流。当您在本地工作站上的流之间切换或将更改复制回上游时，只有已更改文件的元数据会被合并，从而使上下文更改更快。

一旦完成了功能分支的工作，最好使用拉取请求将更改重新放回到仓库的主流中。拉取请求由功能或任务的开发人员创建。在将更改接受到主线之前，高级开发人员或DevOps通常会负责审查更改。

Plastic SCM 和 Perforce 都具有自动化工具来帮助管理将分支合并回主线。Plastic SCM 在 Mergebot的帮助下实现了这一点，Mergebot 会在审查并通过验证后自动合并 repo 的分支。Perforce 有一个附加平台 Helix Swarm，用于管理代码审查，也可以设置自动化测试。

即使您正在从事单独的项目，组织和版本控制的原则也非常有用。

与团队合作时，清晰的沟通至关重要。作为一个团队，你们需要就指导方针达成一致：如何构建你的项目，使用哪个版本控制系统，以及你在该系统中的工作流程应该是什么样的。

这样，当您开始集成其他工具（如 Jira、GitLab、构建工具或自动化测试）时，您已经完成的构建项目和工作流程的工作将发挥作用。