git git提交频率

git commit frequency

提问by Hamza Yerlikaya

Since i switched to git from svn i started make more commits every time i recompile and my tests pass i commit my work. In the end i end up committing function by function.

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

I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often. So i am wondering how ofthen do you commit?

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

回答by Scott Chacon

The guideline for the Git project itself (and the Linux project, AFAIK) is one commit per "logically separate changeset".

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

This is a little ambiguous, but you probably don't want to commit every few days if you're working on a project constantly, and you probablydon't want to commit after every function change - if you've edited several functions in several different files, you want to commit all of the related functionality together if you can and provide a useful commit message with it. All of the code modified in each commit should be related, but it can (and probably should) certainly be across several files.

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

What you probably want to keep in mind is in code reviews. If someone is trying to decide if they should merge your work in, it's much easier for them to process the work being introduced if you have each commit logically contained and separate from each other. That lets you (or others) cherry pick work effectively - if you have three commits with one function modified in each but they're all coupled somehow - you can't apply one without the other two without breaking the codebase - then they should probably be squashed down to one commit.

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

回答by kwatford

I also track some other projects using git like emacs,wordpress etc. I see that they do not commit that often.

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

One of the nice things about git is that you can commit as often as you like, and then when you want to do an upstream commit you can squash several related commits together into one nice clean commit using git-rebase.

git 的好处之一是你可以随心所欲地提交，然后当你想做一个上游提交时，你可以使用git-rebase.

回答by VonC

In the end i end up committing function by function

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

Do not forget you could rather "git add" function by function, making only one commit:

不要忘记你可以git add一个函数一个函数，只做一次提交：

• once all the functions are written or fixed for a given task
• or once you realize the current function is too large/complicated to be part of a commit any time soon: you can then commit what is currently "on stage" ("git added"), which would not include your current modifications in the working directory.

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

Then, the number of commits can be related to the purpose of the branch:

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

• local branch: go crazy, commit anytime you want
• "public" branch (one that you will push):
  • for a local repository (for selected group of people): you could regroup at least the very small "intermediate" commits
  • for a public repository (for all developers, or other projects to see): you can make an interactive rebase in order to regroup your commit by "activity" or "task" in order to make those more readable.

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

In short, "publicationconsiderations" can, in a DVCS (as in "Distributed"), guide you as to make the proper number of commits for the right reasons.

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

回答by baudtack

The more you commit the easier it is to find bugs with git bisect

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

回答by Alan Haggai Alavi

As soon as tests pass, or when a unit of functionality is added/deleted/modified.

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

回答by samoz

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.

这可以确保我保存我的工作，但它也不会为其他用户的存储库造成混乱。

回答by Andrew Sledge

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).

我们的业务需要让我们在程序编译时提交到unstable 分支，在通过单元测试并经过客户审核后提交到stable 分支（当时是在unstable 分支下）。

回答by Andrew Sledge

I commit after I add or change functionality and have a successful test. Or when I'm going to be switching from my desktop to laptop and want to pull down the code, I'll commit and push.

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

回答by T.E.D.

What you are doing sounds about right to me. Any time you have a workingsetup that you want to be able to go back to if you mess something up is a good time to commit. If you have a nice setup where running regression tests is quick and easy, I could see that being fairly often. For me, I'd be lucky to make one a week.

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

回答by Alaa Moneam

1- Commits should be frequent; committing code to the remote repository (not just locally) should be done frequently so that the code is backed up just in case it is somehow lost; this happens more frequently than you'd expect so, pushing your changes by end of day is a must to avoid potential rework and to ensure the remote repository is always up to date.

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

2- Commits should be granular and therefore should not include too many changes to the code base. Commits with too many changes are harder to revert and cannot be used as a reference from a "history" perspective as commit messages would have to be too long in order to cover the full scope.

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

3- Commits should have a proper title; title should start with a capital letter and should not end in a period. Generally, titles should be short and to the point.

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

4- Commit descriptions are optional but are nice to have.

4- 提交描述是可选的，但很好。