我目前正在使用 git 管理多个项目，但是，最近有一个问题一直困扰着我：向主分支和辅助分支提交修改的好基调是什么？应该是“编译时提交”、“工作时提交”还是其他什么？谢谢。
Jaffar Rumith
问问题
468 次
9 回答
6
第一：忽略颠覆策略和源于这种心态的策略。保存更改和发布更改是有区别的。
提交就是保存更改。虽然我不建议提交计时器，但我建议您将其视为保存文件而不是发布版本。当你担心你可能需要回来，但又害怕否则很难回到你所在的地方时，请这样做。
但是，在发布之前重写提交（例如 git rebase -i origin/master #）。在你弄得一团糟中找到意义，并创建一组具有良好提交消息的可理解和干净的提交，并确保每个提交都通过了你可能进行的任何质量检查。然后发布它。
于 2009-03-28T08:12:41.680 回答
3
这真的取决于，这是您的个人仓库还是许多开发人员共享的仓库？你对这个项目有多远？
就我个人而言，当我完成一个方面并且一切都编译时，我会提交我的 subversion 存储库。它不必是完整的，只是不要被破坏。我宁愿一开始就不会把事情弄坏。
可以签入一半编写的代码，但只能在我的个人分支中签入，通常会附有关于我当时正在做什么以及还需要完成什么的注释。由于我使用 Subversion 并且这是我的个人存储库，因此我主要使用它来离开我的桌面并从我离开笔记本电脑的地方重新开始。
通常，每次提交一个错误/问题/功能很好，但可能不适合您的开发风格。如果这是一个更完整的项目，它可能会成功，因为提交意味着您正在某个地方从列表中划掉项目，这意味着现在又完成了一个项目。
其他需要考虑的事情，对于需要签入的更改有什么重要意义？例如，我昨晚签入了显着更改内部 API 的代码，这意味着我必须记录提交消息和文档中的更改。同时我也修改了一些评论来修正错别字。这会在提交消息上得到一个小的子注释，但我认为这不是一个足够大的问题来单独提交。
于 2009-03-28T06:55:01.617 回答
2
一些基本的东西：
- 努力提交每个“逻辑更改”；错误修复，重构，功能，...
- 在提交代码之前运行单元测试；确保你没有破坏任何明显的东西（你确实有单元测试，不是吗）。
- 如果在多开发人员环境中；从 repo 更新并再次运行单元测试，以确保没有冲突的更改破坏了某人的代码（您的或他们的）。
- 根据需要修复并从 3 开始重复，直到没有任何损坏。
- 立即提交并交叉手指。
- 依靠您的持续集成测试来告诉您是否有其他问题。
于 2009-03-28T08:40:39.240 回答
1
如果您使用的是工单管理系统，我会说当任务修复时提交。
于 2009-03-28T06:49:51.987 回答
1
我自己选择“尽早提交，经常提交”。如果你有一个自动结帐并继续构建，这显然是行不通的。
于 2009-03-28T06:50:02.423 回答
1
一次只提交一种类型的更改。
每个项目的“类型”意味着不同，但一些流行的例子包括“外观变化”与“功能变化”和“重构”与“添加新”。这使得在查看日志时更容易跟踪更改，也更容易恢复到修订。
于 2009-03-28T08:18:31.010 回答
0
退后一步，我尝试处理可以在短时间内完成的问题/错误/功能。如果要花一天以上的时间才能到达一个好的停止点，那么任务就太大了。
也就是说，我认为最佳实践是在代码编译并经过充分测试时提交您的更改（理想情况下，使用随着代码更改提交的单元或集成测试）。
如果编译 + 功能正确 + 经过良好测试 == 'commit when it works' 那么这似乎是适当的规则。
于 2009-03-28T06:48:46.590 回答
0
当它起作用时提交。在我的情况下，这意味着：自动化冒烟测试，运行它并提交。
注意：它只是我在提交之前自动化/运行的冒烟测试。回归测试留给持续集成。
于 2009-03-28T06:52:23.917 回答
0
提交您不想再次编写的任何代码:)
于 2009-03-28T08:41:40.097 回答