我目前正在使用git来管理多个项目，但是，最近有一个问题困扰我：对主分支和辅助分支进行修改的好基调是什么？应该是“在编译时提交”，“在工作时提交”还是其他什么？感谢。
答案 0 :(得分：6)
首先：忽略源于这种心态的颠覆策略和策略。保存更改和发布更改之间存在差异。
提交正在保存更改。虽然我不建议提交计时器，但我建议您将其视为保存文件而不是发布版本。当你害怕你可能需要回来时这样做，但是担心否则你很难回到原来的位置。
但是，在发布之前重写提交（例如git rebase -i origin / master＃）。找到你所做的混乱的意义，并创建一组易于理解和干净的提交与良好的提交消息，并确保每个通过你可能有的任何质量检查。然后发布它。
答案 1 :(得分：3)
这真的取决于，这是您的个人回购，还是许多开发商共享的回购？你进入这个项目有多远？
当我完成一个方面并且所有内容都编译时，我个人承诺我的subversion存储库。它不必是完整的，只是没有打破。我宁愿不要把事情搞得一团糟。
一半编写的代码可以签入，但仅限于我的个人分支机构，通常会记录我当时正在做什么以及还需要完成什么。由于我使用的是Subversion，这是我个人的回购，我主要是为了能够离开我的桌面，然后回到笔记本电脑上我离开的地方。
通常每次提交的一个错误/问题/功能很好，但可能不适合您的开发风格。如果这是一个更完整的项目，它可能会解决，因为提交意味着您正在某个地方从列表中穿过项目，这意味着还有一个项目现已完成。
需要考虑的其他事项，它保证检查的变更有什么重要意义？例如，我昨晚检查了代码，它显着改变了内部API，这意味着我必须记录提交消息和文档中的更改。与此同时，我也改变了一些评论来修复拼写错误。这会在提交消息上得到一个小的子注释，但这不是我认为足以让它自己承诺的问题。
答案 2 :(得分：2)
一些基本的东西：
答案 3 :(得分：1)
如果您正在使用故障单管理系统，我会说在修复任务时提交。
答案 4 :(得分：1)
我选择'早点提交，经常提交'，我自己。如果你有一个自动结账和继续进行，这显然是行不通的。
答案 5 :(得分：1)
一次只提交一次类型更改。
每个项目的“类型”意味着什么不同，但一些流行的例子包括“外观变化”与“功能变化”和“重构”与“添加新”。这使得在查看日志时更容易遵循更改，并且更容易恢复到修订。
答案 6 :(得分：0)
为了退后一步，我尝试研究可以在短时间内完成的问题/错误/功能。如果需要一天以上才能达到一个好的停止点，那么任务就太大了。
也就是说，我认为最好的做法是在代码编译并经过充分测试后提交您的更改（理想情况下，使用代码更改提交的单元或集成测试）。
如果正确编译+函数+经过充分测试=='在工作时提交'那么这似乎是合适的规则。
答案 7 :(得分：0)
在工作时提交 。在我的情况下，这意味着： 自动化冒烟测试，运行并提交 。
注意：它只是我在提交之前自动执行/运行的冒烟测试。回归测试留待持续集成。
答案 8 :(得分：0)
提交您不想再写的任何代码：）