自从我从svn切换到git后，我每次重新编译时都开始做更多的提交，我的测试通过了我的工作。最后我最终按功能提交功能。
我还使用像emacs，wordpress等git跟踪一些其他项目。我看到他们不经常提交。所以我想知道你怎么承诺？
Git项目本身（以及Linux项目，AFAIK）的指南是每个“逻辑上独立的变更集”的一个提交。
这有点模棱两可，但如果你经常在一个项目上工作，你可能不想每隔几天就做一次，并且你可能不希望在每次更改函数后都提交 - 如果你已经编辑了几个函数几个不同的文件，如果可以的话，您希望将所有相关功能提交到一起，并提供有用的提交消息。每次提交中修改的所有代码都应该是相关的，但它可以（并且可能应该）跨越多个文件。
您可能需要记住的是代码审查。如果有人试图决定他们是否应该合并你的工作，那么如果每个提交都在逻辑上包含并相互分离，那么他们就更容易处理所引入的工作。这让你（或其他人）可以有效地选择工作 - 如果你有三个提交，其中一个功能被修改，但是它们都以某种方式耦合 - 你不能在不破坏代码库的情况下应用一个没有其他两个 - 那么它们应该可能被压扁到一个提交。
1-应该经常提交;应该经常将代码提交到远程存储库（不仅仅是本地），以便在代码丢失的情况下备份代码;这种情况发生的频率比您预期的要高，因此必须在一天结束时推送您的更改，以避免潜在的返工并确保远程存储库始终保持最新状态。
2-提交应该是精细的，因此不应包含对代码库的太多更改。具有太多更改的提交更难以还原，并且不能从“历史”角度用作引用，因为提交消息必须太长才能覆盖整个范围。
3-提交应具有适当的标题;标题应以大写字母开头，不应在一段时间内结束。一般来说，标题应该简短而重要。
4-提交描述是可选的，但很高兴。
我相距甚远。 git并不是要“备份”你的代码，你应该使用tarball或dropbox或其他东西来确保你不会丢失代码。
如果你不经常提交，你可以更好地告诉你应该在什么提交中做什么，它会给你一个比50次提交更平滑的历史记录。
“哎呀”，“该死的”，“忘了那个档案”
你可以改变，但如果你从来没有上过/提交，就没有必要撤销你的工作
我还使用像emacs，wordpress等git跟踪一些其他项目。我看到他们不经常提交。
关于git的一个好处是你可以随意提交，然后当你想做一个上游提交时，你可以使用git-rebase将几个相关的提交压缩成一个很好的干净提交。
最后我最终按功能提交功能
不要忘记你可以通过函数“git add”函数，只进行一次提交：
然后，提交的数量可以与分支的目的相关：
简而言之，“发布注意事项”可以在DVCS（如“分布式”）中指导您以正确的理由进行正确的提交数量。
您提交的越多，就越容易找到git bisect的错误
测试通过后，或添加/删除/修改功能单元时。
这真的取决于。
我所做的就是经常在当地做，因为它听起来像你在做，但是当我积累了几个有影响力的时候，我只会推动我的改变。
这可以确保我保存我的工作，但它也不会使其他用户的repo混乱。
我们的业务需求让我们在程序编译时承诺不稳定的分支，并在通过单元测试时提交稳定分支并且已经由客户审查（当它在不稳定的分支下时）。
我添加或更改功能并进行成功测试后提交。或者当我要从我的桌面切换到笔记本电脑并想要下载代码时，我会提交并推送。
你在做什么听起来对我说得对。任何时候你有一个工作设置，你想要能够回去，如果你搞砸了是一个很好的时间提交。如果你有一个很好的设置，运行回归测试是快速和简单的，我可以看到相当频繁。对我来说，我很幸运能够每周制作一个。