将更改提交到存储库的良好标准是什么？答案

【问题标题】：What are the good criteria for committing changes to repository?将更改提交到存储库的良好标准是什么？
【发布时间】：2009-04-07 00:21:52
【问题描述】：

我目前正在使用 git 来管理多个项目，但是，最近有一个问题一直困扰着我：将修改提交到主分支和辅助分支的好基调是什么？它应该是“编译时提交”、“工作时提交”还是其他什么？谢谢。

【问题讨论】：

【解决方案1】：

第一：忽略颠覆策略和源于这种心态的策略。保存更改和发布更改是有区别的。

提交就是保存更改。虽然我不建议提交计时器，但我建议您将其视为保存文件而不是发布版本。当您担心自己可能需要回来，但又害怕很难回到原来的位置时，请这样做。

但是，在发布之前重写提交（例如 git rebase -i origin/master #）。在你弄得一团糟中找到意义，并创建一组具有良好提交消息的可理解和干净的提交，并确保每个提交都通过你可能进行的任何质量检查。然后发布它。

【讨论】：

【解决方案2】：

这真的取决于，这是您的个人存储库还是许多开发人员共享的存储库？你对这个项目有多远？

当我完成一个方面并且一切都编译时，我个人会提交我的颠覆存储库。它不必是完整的，只是不要被破坏。我宁愿一开始就不会把事情弄坏。

可以签入写了一半的代码，但只能在我的个人分支中签入，通常会附上关于我当时正在做什么以及还需要完成什么的注释。由于我使用 Subversion 并且这是我的个人存储库，因此我使用它主要是为了能够离开我的桌面并从我离开笔记本电脑的地方继续。

通常每次提交一个错误/问题/功能很好，但可能不适合您的开发风格。如果这是一个更完整的项目，它可能会成功，因为提交意味着您正在某个地方从列表中划掉项目，这意味着现在又完成了一个项目。

需要考虑的其他事项，对于需要签入的更改有什么重要意义？例如，我昨晚签入了显着更改内部 API 的代码，这意味着我必须记录提交消息和文档中的更改。同时，我还更改了一些 cmets 来修复错字。这会在提交消息上得到一个小的子注释，但我认为这不是一个足够大的问题来单独提交。

【讨论】：

【解决方案3】：

一些基本的东西：

【讨论】：

【解决方案4】：

如果您使用的是工单管理系统，我会说当任务修复时提交。

【讨论】：

【解决方案5】：

我自己选择“尽早提交，经常提交”。如果您有自动结帐并继续构建，这显然行不通。

【讨论】：

【解决方案6】：

一次只提交一种类型的更改。

每个项目的“类型”含义不同，但一些流行的示例包括“外观更改”与“功能更改”以及“重构”与“添加新”。这使得在查看日志时更容易跟踪更改，也更容易恢复到修订。

【讨论】：

【解决方案7】：

为了退后一步，我尝试解决可以在短时间内完成的问题/错误/功能。如果要花一天以上的时间才能到达一个好的停止点，那么任务就太大了。

也就是说，我认为最佳做法是在代码编译并经过充分测试时提交您的更改（理想情况下，通过代码更改提交的单元或集成测试）。

如果编译 + 功能正确 + 经过良好测试 == 'commit when it works' 那么这似乎是适当的规则。

【讨论】：

【解决方案8】：

工作时提交。在我的例子中，这意味着：自动化冒烟测试，运行它并提交。

注意：它只是我在提交之前自动化/运行的冒烟测试。回归测试留给持续集成。

【讨论】：

【解决方案9】：

提交您不想再次编写的任何代码:)

【讨论】：