我目前对git的使用可以被描述为“早期和经常提交”。我当然试图使每个提交成为一个逻辑单元（如good commit criteria中所述）。但是，我经常迭代设计并希望保存每个阶段。如果我想出一些丑陋而又实用的东西，我想在清理之前提交检查点。
您对此事的体验是什么 - 它是否会给您的团队带来问题？超越丑陋的代码 - 只要你不修复直到修复错误，本地提交破坏的代码是否可以接受？
答案 0 :(得分：7)
最常见的惯例是使用存储在您的存储库中的功能分支（或一组分支） - 也许可以在某个地方在线，如GitHub或Gitorious。
您可以在合理的有罪不罚的情况下重新定义和重写该功能分支，直到您最终准备好以任何项目特定的方式提交上游。这使您可以构建和共享正在进行中的代码，而不会过于头痛。
一路上，构建一系列提交，然后使用交互式rebase（或其他重写工具）将这些提交转换为另一组干净的逻辑提交，这是从检查点及时移动到检查点的好方法 - 如果你经常犯下并且在非常小的部分中，那么效果最好。
答案 1 :(得分：0)
是否会给你的团队带来问题？
不适合我/我的团队。只要你没有推送破坏的代码，它就不会影响你的队友 - 至少，直到你去寻找过去的提交。
只要你不推，直到错误得到解决，本地提交损坏的代码是否可以接受？
我是这么认为的，但我也认为你会发现这个问题的答案是非常主观的。
如果您真的担心推送可能包含中间损坏提交的提交，Squash my last X commits together using Git
你可以在git commit frequency找到更多的建议/意见，其中一些比我自己更严格，但并非没有价值：
- Git项目本身的准则是每个＆＃34;逻辑上单独的变更集一个提交。＆＃34;
（Scott Chacon）- 此外，您还希望每个评分版本都能正常工作（这有助于找到错误的二分法）（Jakub Narębski）
- 如果您拥有该项目，请随时提交。如果您正在编辑其他人的项目，请在修补程序完成时提交 （Tyler Gillies）
列表继续......
答案 2 :(得分：0)