blocks|key|2047375|text|Git项目本身(以及Linux项目，AFAIK)的指导方针是每个“逻辑上独立的变更集”一个提交。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2047376|这有点模棱两可，但是如果你经常在一个项目上工作，你可能不想每隔几天提交一次，而且你可能不想在每次函数更改后提交-如果你在几个不同的文件中编辑了几个函数，你想尽可能提交所有相关的功能，并提供有用的提交消息。在每次提交中修改的所有代码都应该是相关的，但它肯定可以(并且可能应该)跨多个文件。|2047377|你可能要记住的是在代码评审中。如果有人试图决定他们是否应该合并您的工作，如果您在逻辑上包含每个提交并将每个提交彼此分开，那么他们将更容易处理正在引入的工作。这让你(或其他人)可以有效地工作-如果你有三个提交，每个提交都修改了一个函数，但它们都以某种方式耦合在一起-你不能在没有破坏代码库的情况下应用另两个提交-那么它们可能应该被压缩到一个提交。|2047378|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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

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 probably don'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.

blocks|key|2047393|text|提交的越多，就越容易找到git+bisect的错误|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2047394|entityMap|0|LINK|mutability|MUTABLE|url|http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html^0|C|A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

The more you commit the easier it is to find bugs with <a href="http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html" rel="noreferrer">git bisect</a>

blocks|key|1832951|text|只要测试通过，或者当添加/删除/修改功能单元时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1832952|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|2047167|text|这真的要看情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2047168|我所做的是我经常在本地提交，就像您所做的那样，但只有在我积累了几个有影响力的更改时，我才会推动我的更改。|2047169|这确保了我保存了我的工作，但也不会使其他用户的存储库变得混乱。|2047170|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|1832968|text|我们的业务需要使我们在程序编译时提交到不稳定分支，并在它通过单元测试并经过客户审查时提交到稳定分支(当它在不稳定分支下时)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1832969|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|1833261|text|我在添加或更改功能并成功测试后提交。或者，当我要从台式机切换到笔记本电脑，并且想要下拉代码时，我会提交并推送。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1833262|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|2047228|text|在我看来，你所做的一切都是对的。任何时候，如果你有一个可以正常工作的设置，如果你把事情搞砸了，那就是一个提交的好时机。如果你有一个很好的设置，运行回归测试是快速和容易的，我可以看到这是相当频繁的。对我来说，一周做一个就很幸运了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2047229|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

What you are doing sounds about right to me. Any time you have a working setup 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.

blocks|key|1833344|text|1-提交应该是频繁的；应该频繁地将代码提交到远程存储库(而不仅仅是本地)，以便在代码丢失的情况下备份代码；这种情况发生的频率比您预期的要频繁，因此，必须在一天结束之前推动您的更改，以避免潜在的返工并确保远程存储库始终是最新的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1833345|2-提交应该是细粒度的，因此不应该包含太多对代码库的更改。更改太多的提交更难恢复，并且不能从“历史”的角度用作引用，因为提交消息必须太长才能覆盖整个范围。|1833346|3-提交应该有一个合适的标题；标题应该以大写字母开头，不应该以句点结尾。一般来说，标题应该简短且切中要害。|1833347|4-+Commit描述是可选的，但也很好用。|1833348|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

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.

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.

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

blocks|key|1833234|text|我的承诺相距甚远。git不是用来“备份”你的代码的，你应该使用tarball或者dropbox之类的东西来确保你不会丢失代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1833235|如果你不经常提交，你可以更准确地知道什么应该在什么提交中进行，而且它比50次提交提供了更平滑的历史记录。|1833236|“糟糕”，“该死”，“忘了那个文件”|1833237|你可以改变基址，但是如果你从一开始就没有执行/提交，就没有必要撤销你的工作。|1833238|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I commit pretty far apart. git isn't meant to "backup" your code, you should be using tarballs or dropbox or something to ensure you don't lose code.

If you don't commit very often you can better tell exactly what should go in what commit and it gives you a smoother history than 50 commits with

"oops", "damn", "forgot that file"

you can rebase, but if you never stage/commit in the first place, theres no need to undo your work

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.

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 commit frequency

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

自从我从svn切换到git后，我开始在每次重新编译和测试通过时提交更多的提交，我提交了我的工作。最后，我一个函数一个函数地提交。我也使用git跟踪其他一些项目，比如emacs，wordpress等，我发现他们并不经常提交。所以我想知道你是如何承诺的？

问git提交频率
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问git提交频率EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问git提交频率
EN