版本控制的最佳实践

这是您可以对工作流程进行的最简单改进，但却是一些开发者最难以做到的。在使用其他项目管理工具时，您可能已经将工作分解为小而可管理的任务。提交应以完全相同的方式对待。

单个提交应仅与一个任务或工单相关，除非一行代码神奇地修复了多个错误。如果您正在处理一个较大的功能，请将其分解为更小的任务，并为每个任务进行提交。

使用较小提交的最大优势在于，如果出现问题，您可以更轻松地检测和撤销不希望的更改。

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

在使用像Jira或GitLab这样的任务工单系统时，在提交中包含工单编号更好。许多系统可以设置为与智能提交一起工作，这样您实际上可以在提交消息中引用工单并更改其状态。

例如，提交消息为“JRA-123 #close #comment 任务完成”的提交将把Jira工单JRA-123设置为关闭，并在工单上留下评论“任务完成”。

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

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

提交应仅包括与您提交到仓库的更改相关的文件。在处理Unity项目时，您应特别小心，因为某些更改可能会导致多个文件被标记为已更改，例如场景、预制件或精灵图集，即使您并不打算对它们进行任何更改。

例如，如果您意外地提交了对某个其他人正在处理的场景的更改，这可能会给他们带来麻烦，因为他们在提交更改时会看到需要先合并您的更改。

这是新手在版本控制中最常犯的错误之一。重要的是要理解，您只应提交自己的更改到项目中。要了解更多信息，请查看这篇博客文章，了解如何加快您的工作流程。

在合理的情况下，从仓库中拉取最新更改到您的工作副本。在孤立中工作并不是一个好主意，因为这只会增加合并冲突的可能性。请参阅上表以了解每个系统的典型日常工作流程。

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

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

考虑以下示例：

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

无论您的团队选择使用哪种 VCS，请确保每个人都能舒适地使用它，并理解他们可以使用的工具。

如果您正在使用 Git，并不是每个人都需要使用相同的 GUI 客户端。但请优先确保每个人都对 commit > pull > push 工作流程感到舒适。换句话说，他们应该知道只提交他们需要的文件。

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

在一个长期项目中，具有多个发布周期时，功能分支对您的工作流程非常有利。通常，团队在同一个存储库的分支上工作，通常称为主干、主分支或主分支。

当您这样做时，整个项目沿着相同的时间线推进。然而，将工作分成几个分支以更有效地协作是有用的。

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

因此，如果开发人员在一个隔离的分支中开始工作一个新功能，完成后将合并回主分支。与此同时，另一位团队成员可以对之前的发布进行热修复，或修复一个错误，并安全地发布一个新版本，而不包括任何仍在开发中的功能。

Plastic SCM 还具有 任务分支。对于此模式，您为每个跟踪的任务创建一个新分支。在 Git Flow 中，我们使用功能分支来开发完整的，有时是大型的功能。Plastic SCM 中的任务分支旨在短期存在。如果一个任务需要超过几次提交来实现，那么它很可能可以拆分成更小的任务。

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

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

一旦您完成了功能分支的工作，使用拉取请求将更改合并回仓库的主流是一个好习惯。拉取请求由功能或任务的开发人员创建。通常，审查更改的责任在于高级开发人员或 DevOps，在接受更改进入主线之前。

Plastic SCM 和 Perforce 都有自动化工具来帮助管理将分支合并回主线。Plastic SCM 借助Mergebot来实现这一点，该工具在分支经过审查并通过验证后会自动合并仓库的分支。Perforce 还有一个额外的平台Helix Swarm，用于管理代码审查，也可以与自动化测试一起设置。

即使您在进行单人项目，组织和版本控制的原则也非常有用。

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

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