Answers:
我习惯做的一件事就是总是在即将我检入文件之前查看我要检入的每个文件的差异。
您永远不要签入注释掉的代码。如果您有需要在签入之前注释掉的代码，那么您做错了。
至于规则：
建立
3.1修复构建错误
运行测试
4.1修复损坏的测试
转到1（直到没有新内容为止）
仅在所有步骤完成后才能签到。
参见登机舞。
其他良好做法：
rebase -i清理本地历史记录，并根据需要压缩提交，因此主线没有丑陋的正在进行中的提交。
我并不想在这里过分强调，但是这个问题的假设（除了答案之一）全部适用于集中式VCS，例如TFS，SVN，Perforce等。很
公平，这就是事实OP正在使用。
但是，另一方面，在使用DVCS（例如Mercurial和Git）时，通常不必等待签入，答案中提到的大多数内容（例如diff，获取最新内容，合并等）都是不必要的。甚至在签入之后（尽管可能在推送之前，取决于...），诸如代码审查和测试之类的事情也最好做
（到目前为止），我在这里看到的一个例外是与工作项相关联。当然，对签到发表评论也很好...
我在其他答案中没有看到的三件事：
包括新文件
恢复未更改的文件
检查您提交的提交
使用Git时有两件事：
原子提交：
git add --patch如有必要，最多分裂我改变成多个部分。总结时查看差异
git commit --verbose以便在输入提交消息时可以看到更改的差异。（或者我使用修补的git-vim显示差异。）我在团队的服务器上执行的一些“良好实践”很简单。首先，在签入之前，应始终获取最新信息并运行本地构建，以确保没有其他人检查过与代码冲突的内容。此外，请注意本地计算机（而不是服务器）上的任何代码冲突。一旦确认您的代码已下载了最新代码，便可以构建并正常工作，则可以进行下一步了。运行所有自动化测试，然后开始签入，以确保它们仍然可以正常运行。然后，请确保再次获取最新信息。
作为TFS管理员，可以对所有签入强制执行注释。我建议始终为您的工作添加检入注释，无论是否强制执行。如果您可以这样做，请强制执行。确保注释至少是自上次签入代码以来所做更改的一般摘要。这样，如果出现问题，您可以查看签入内容，大致了解一下在签到中进行了更改。它使调试损坏的版本更加容易。
此外，如果您具有TFS管理员权限，则可以在签入中强制进行滚动构建（以确保其他所有人都可以立即知道他们的签入是否有问题），并且可以将服务器设置为执行门控签入（如果签入的代码破坏了构建，则服务器拒绝它），或者您可以简单地让它创建一个错误并将其分配给破坏构建的任何人。
您可以打开或关闭其他一些选项，以使一切井井有条，或者建议您的TFS-Admin开启以保持环境的整洁。
如果您是从Windows检入的，请检查您的代码是否没有那些不可见的^ M字符-UNIX中的编辑器经常会给出错误/警告的原因。
还要尝试并替换制表符-不同的用户最终会看到不同的制表符，其中一些具有4个空格，一些8个空格，不利于代码的可读性。
恕我直言，最好的方法是让一个预定义的脚本根据您组织的编码准则来检查您的代码。源代码控制系统的负载具有此功能。
在这里合并所有答案并给出完整的清单
[签入/签出]您不应该直接签到其他人正在使用的流。您应该有一个流策略：例如，对于每个开发人员，一个流，您可以在其中独立地签入和签出而不会打扰其他人：您的工作将安全，但在您自己的开发流中，所以[仅在您自己的开发流中]。每次签入时，您都将其与变更记录相关联，以使您的变更相对于称为变更集的变更而言是原子的（因此您可以分发单个的RFC /错误等，而无需交付“一切”）。
[然后根据您的团队信息流进行调整]，这意味着您可以从自己的信息流中获得其他人的更改。在该操作过程中，您可以在合并对话框中看到所有“差异”并进行遍历，或者...如果有成千上万个和/或您不使用代码，例如数据模型/ siebel项目等...都依赖非琐碎合并，琐碎自动和琐碎的手动合并，最后一个类别包含困难的合并。请记住，您仍在自己的流中工作。
[完整的基础]如果一切正常，请检入您刚刚从团队信息流中获得的所有更改：您自己的信息流现已更新
[交付]现在将您的工作交付给团队流。如果您不希望提供所有功能，则还可以选择1个特定的RFC，其中包含该文件的特定版本或一组RFC /已解决的缺陷。
[测试交付]应该可以，但是由于有机会同时交付了变更，因此您也可以：您可以测试您的工作是否可以与团队流中的最新变更一起使用。使用相同的合并对话框显示差异。
[完成交付]完成交付，您的工作现在在团队中。
使其更加复杂：由于您交付的工作仍然有可能=好的，但您已经在开发另一个版本，因此应始终在交付后确定基准，并指出其他用户希望从哪个基准中重新确定基准。这样可以确保其他开发人员在流中获得推荐的版本，而不是最新版本（如果您在那种情况下工作）。这也是三次检查，因此即使团队流中的最新版本“很差”，它们仍然不是其他人要改写或查看的版本，并且您的配置管理器可以将先前版本合并到下一版本来撤消您的交货。
在您的示例中，您忘记了注释掉代码。发生错误。围绕它的配置管理系统应该照顾好它。确实可能是，例如，成千上万的更改进入，并且“构建”和“集成”发生在按时间顺序链接和处理的不同服务器上的流的层次结构中。因此，即使您在5个月后将注释掉的代码在集成服务器上进行了测试，因为您的代码需要与其他代码和系统进行集成，仍然应该可以自动删除您的变更集并继续进行。因此，最佳做法或多或少是较高的。配置管理流的总体设计应注意这一点。对于个人开发人员来说，最佳实践当然是验证/单元测试。但是从大局到“
根据您的SCM，以下某些应用比其他应用（或以不同的形式）应用更多，所以在这里：
注意：上面的某些项目似乎很明显，但是您不相信有多少人实际在主分支上工作或先对生产进行更改，然后手动创建增量以直接在主分支上进行版本控制。 ..并带有标签。像发酵的胆汁和未洗过的腋窝汁混合在一起的甜味...是的，就像那样。
有个人检查清单。当您搞砸时，请在入口处将其启动为空。当它成为第二自然属性时，将其从列表中删除。
运行测试。如果他们通过了，则将其检入。如果您搞砸了，并且某些东西无法通过测试，则编写一个测试。
我们做以下...
测试-我们要确保它能正常工作。至少，我们想知道它不会破坏任何东西。
代码审查，或至少是一个伙伴检查-这是确保知识传布并确保人们与时俱进的好方法。它还有助于在检入之前捕获错误。
发送预先通知-签到之前将预先通知发送给该组。目的不仅是让其他人知道正在更改的文件或区域，而且还可以使他们提防（如果他们选择注意的话），以防可能这些更改影响到他们。
发送预先通知的几个小时后，将执行签入，并通过电子邮件通知该小组。小组中的每个人都可以知道何时完成有关错误或功能的特定工作。
签入通知的副本将粘贴到与错误或功能关联的修复记录中。在搜索记录时，我们发现了解修补程序/功能的含义非常方便。
查找您可以作为独立单元进行的部分更改。
通常，当我对代码进行有效的修复或增强时，已经有很多更改。其中一些特定于我要进行的行为更改；其他人则在重构，以使更改更加整洁。
我更喜欢使用其自己的更改描述分别检查每个重构，如下所示：
重新处理：将X重命名为Y
X以前很有意义，因为...但是现在应该是Y。这与问题9的工作有关。
然后，一旦签入每个良好的重构，最终的行为更改通常就变得微不足道了。
另外，某些更改会影响许多行代码，但并不是很有趣，而其他更改则非常本地化，但会产生重要影响。如果一起检查这些更改，则可能很难读取差异。因此，我将它们分开。
后来，当有人阅读变更历史记录时，很明显事情是如何到达当前事务状态的，为什么会这样。撤消我的行为更改也很简单，因为它不会与大量其他编辑纠缠在一起。
退还从某人那里借来的东西时，要做些什么。确保它干净且形状良好。如果您搞砸了，请务必先清理干净，然后再将代码退还给所有者（大多数情况下是您的雇主）。
我为我的工作保留了本地汞回购协议。
我并不是说这些是最好的，但是它们确实为我工作。