54

自从我从 svn 切换到 git 后，我​​开始在每次重新编译并且我的测试通过时进行更多的提交，我提交了我的工作。最后，我最终逐个提交功能。

我还使用 git 跟踪其他一些项目，如 emacs、wordpress 等。我发现他们不经常提交。所以我想知道你多久提交一次？

4

11 回答 11

64

Git 项目本身（以及 Linux 项目 AFAIK）的指导方针是每个“逻辑上独立的变更集”提交一次。

这有点模棱两可，但是如果您经常从事一个项目，您可能不想每隔几天提交一次，并且您可能不想在每次功能更改后提交 - 如果您在几个不同的文件，如果可以的话，您希望将所有相关功能一起提交，并提供有用的提交消息。每次提交中修改的所有代码都应该是相关的，但它肯定可以（并且可能应该）跨多个文件。

您可能要记住的是代码审查。如果有人试图决定他们是否应该合并您的工作，如果您的每个提交在逻辑上包含并彼此分开，那么他们处理引入的工作会容易得多。这可以让你（或其他人）有效地挑选工作——如果你有三个提交，每个提交修改了一个函数，但它们都以某种方式耦合——你不能在不破坏代码库的情况下应用一个而没有另外两个——那么它们可能应该被压缩到一个提交。

于 2009-06-25T03:29:12.810 回答
26

我还使用 git 跟踪其他一些项目，如 emacs、wordpress 等。我发现他们不经常提交。

git 的优点之一是您可以随意提交，然后当您想要进行上游提交时，您可以使用git-rebase.

于 2009-06-24T17:42:05.370 回答
14

最后我最终按功能提交功能

不要忘记，您宁愿“git add逐个函数地执行”，只提交一次：

  • 一旦为给定任务编写或修复了所有功能
  • 或者一旦您意识到当前函数太大/太复杂而不能很快成为提交的一部分：然后您可以提交当前“在舞台上”（“git added”）的内容，这不会包括您当前在工作中的修改目录。

然后，提交的数量可以与分支的目的相关：

  • 本地分支：发疯，随时提交
  • “公共”分支（您将推送的分支）：
    • 对于本地存储库（对于选定的一组人）：您至少可以重新组合非常小的“中间”提交
    • 对于公共存储库（供所有开发人员或其他项目查看）：您可以进行交互式变基，以便通过“活动”或“任务”重新组合您的提交，以使它们更具可读性。

简而言之，在D VCS（如“分布式”中）中，“发布注意事项”可以指导您出于正确的原因进行适当数量的提交。

于 2009-06-24T19:38:12.870 回答
10

你提交的越多，使用git bisect找到错误就越容易

于 2009-06-25T03:50:47.203 回答
7

一旦测试通过，或者当一个功能单元被添加/删除/修改时。

于 2009-06-24T17:41:04.217 回答
3

It really depends.

What I do is I commit locally often, as it sounds like you're doing, but I only push my changes when I've accrued several influential ones.

This ensures that I save my work, but it also doesn't clutter the repo for other users.

于 2009-06-24T17:42:22.263 回答
3

Our business needs have us commit to the unstable branch when the program compiles, and commit to the stable branch when it passes unit testing and has been reviewed by the customer (while it was under the unstable branch).

于 2009-06-24T17:44:57.707 回答
2

我在添加或更改功能并成功测试后提交。或者，当我要从台式机切换到笔记本电脑并想要下载代码时，我会提交并推送。

于 2013-05-27T12:40:58.677 回答
1

你正在做的事情对我来说是正确的。任何时候你有一个工作设置，如果你把事情搞砸了，你希望能够回到这个位置，这是一个提交的好时机。如果您有一个很好的设置，可以快速轻松地运行回归测试，我可以看到这种情况相当频繁。对我来说，我很幸运每周能做一个。

于 2009-06-24T17:55:30.077 回答
0

1- 提交应该是频繁的；应经常将代码提交到远程存储库（不仅仅是本地），以便备份代码以防万一丢失；这种情况发生的频率比您预期的要高，因此必须在一天结束前推送您的更改，以避免潜在的返工并确保远程存储库始终是最新的。

2- 提交应该是细粒度的，因此不应包括对代码库的太多更改。具有太多更改的提交更难恢复，并且不能从“历史”角度用作参考，因为提交消息必须太长才能涵盖全部范围。

3-提交应该有一个适当的标题；标题应以大写字母开头，不应以句点结尾。一般来说，标题应该简短而切题。

4- 提交描述是可选的，但很高兴拥有。

于 2019-03-21T13:12:40.463 回答
-5

我承诺相距甚远。git 并不是要“备份”您的代码，您应该使用 tarball 或 Dropbox 或其他东西来确保您不会丢失代码。

如果您不经常提交，您可以更好地准确判断应该在什么提交中进行，并且它为您提供比 50 次提交更流畅的历史记录

“哎呀”，“该死”，“忘记了那个文件”

你可以变基，但如果你从不暂存/提交，就没有必要撤消你的工作

于 2011-07-29T09:50:12.283 回答