我一直在使用Git来管理自己的个人项目。我没想到我是如何使用它的。每当有一个没有真正想到的里程碑时，我通常会提交所有更改。
但在阅读blog post提到你应该如何改正提交信息后，我意识到我真的不知道如何正确使用SCM。
所以我想知道您是否有关于以下内容的任何提示：
谢谢！
答案 0 :(得分：5)
由于您使用的是git，以下是我可能会或可能不适合您的一些做法：
听起来很复杂，但练习真的很愉快（至少对我而言），因为git非常快，并且在完成所有这些步骤时感觉非常正确。
答案 1 :(得分：3)
我知道有两种可防御且通常使用的权力用于提交：
精细提交，你提前提交，经常提交，并以小块提交。每次提交时系统可能都处于良好状态。这种做法的主要好处是，您可以清楚地了解已更改的内容以及何时更改，并使用darcs之类的系统或git-rebase这样的命令，您有机会“挑选”提交您感兴趣的内容。
可靠提交，只有在系统处于固定状态时才提交，例如，它不仅可以构建，还可以通过回归测试。
在一个大型团队项目中，某种可靠的方案是必要的，尽管您仍然可以在本地进行细粒度提交，并且只有在处于固态时才会公开。
多年以后，我一直观察到大多数学生和其他初学者都害怕犯错并且不经常犯错。对于我自己的项目，我倾向于使用细粒度方法，对于较大的项目，我通常至少携带两个分支，对一个进行固体系统提交，对其他进行细粒度提交。
答案 2 :(得分：3)
其他答案适用于使用多人使用的中央存储库。当我使用git时，我通常拥有自己的私有分支来处理我正在处理的东西，而且我倾向于做很多小的提交。在开发时我发现这很有用，因为当我意识到我应该做一些不同的事情时我可以快速回溯，而且我也有一个相对详细的记录我所做的事情。
然后，当我准备好向上游推送（即测试，记录等）时，我推送作为单个提交，避免中央仓库中的混乱。两全其美。
答案 3 :(得分：2)
从Eric Sink查看Source Control HOWTO。我最后一次经历它，它主要集中在集中式VCS上，但仍然有很多好东西。
答案 4 :(得分：2)
答案 5 :(得分：1)
我通常在添加新功能后，或者在记录完错误修复完成后提交。基本上，一次一件事。这样可以更轻松地回滚更改。
对于提交消息，我将列出新功能的附加功能。对于错误修复，我从错误数据库中包含错误的ID。
答案 6 :(得分：1)
在处理一个小型的个人项目时，它可能更少，因为你知道你的代码，你记得你做了什么，大概是什么时候 - 至少我做了。
但对于拥有众多开发人员的大型项目来说，
非常重要查看已更改文件的历史记录，并且您正在尝试查找特定问题何时出现，良好的评论将帮助您更快地找到正确的提交。
通过保持提交次数，还可以更轻松地检查与新功能相关的更改，还原“功能”或将其合并到另一个树中。
/ B
答案 7 :(得分：0)
当您提交更改时，请确保代码构建并基本上正常运行。提交破坏构建的代码是不好的形式。如果您在团队环境中工作，那么没有什么比查看最新代码以查找它破坏应用程序或甚至不编译更糟糕的事情。
关于评论，请粗略描述代码的作用，理想情况是为什么要这样做。这使您可以在不必阅读代码的情况下找出签入的内容
答案 8 :(得分：0)
对于个人项目，我倾向于尽可能经常地提交提交，这可能是每小时几次，因为当我意识到我遇到了错误时，这可以让我及时回到之前的“快照”路由。
对于多用户项目，它将取决于规则，在达到这些目标之前，您无法提交某些内容。就个人而言，当我可以按照“修复此票证”或“实现此功能”的方式撰写评论时，我倾向于提交。
至于评论，我提供了更改摘要或故障单或维基参考。应该记录代码和差异，以便提供详细信息。