每次使用 DVCS 保存后进行提交是否有意义？
我知道这个问题之前已经有人问过多久进行一次 DVCS。所有答案都有一个共同点——尽可能频繁地回答。但它们通常是在完成一个想法、一个用户故事、获得可编译的代码或通过测试之后。 我在想，考虑到 DVCS 为您提供了自己的存储库，并且提交非常便宜，那么在每次对文件进行更改后提交是否有意义？毕竟，这就是 NetBeans 中发生的情况，您无需提出要求即可获得一台不错的免费“时间机器”。如果不是每次更改，那么至少每次保存或编译。
这是有道理的，还是我对 DVCS 的看法有误？我的感觉是，这不是大多数人使用 DVCS 的工作流程。
I know the question has been asked before how often to commit with a DVCS. All answers have one thing in common--as often as possible. But they're usually something like, after finishing a thought, a user story, getting code that compiles, or passing tests.
I was thinking, given that a DVCS gives you you're own repository, with very cheap commits, doesn't it make sense, to commit after every change to a file? After all, this is what happens in NetBeans, and you get a nice free "time machine" without even asking for it. If not every change, then at least every save, or compile.
Does this make sense, or do I have the wrong idea about DVCS. My feeling is that this not the workflow most people have with DVCS.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我为
git和 <代码>emacs。每次我保存时它都会进行提交，但它会在侧分支中进行提交。自动提交不会成为主分支上历史记录的一部分，因此通常不会传播到其他存储库。它可以让我轻松地回顾我以前的保存，但不会因为非工作提交而扰乱我的常规分支。两全其美。
I use the awesome git-wip tool for users of
gitandemacs. It makes a commit each time I save, but it makes the commit in a side branch. The automatic commits don't become a part of the history on the main branch and consequently are normally not propagated to other repositories.It lets met look back through my previous saves easily, but without cluttering my regular branch with non-working commits. Best of both worlds.
您当然应该尽量避免提交不起作用的代码，甚至可能无法编译的代码（我认为即使您在推送/发布代码之前使用 git rebase --interactive 清理历史记录）。否则
git bisect来查找错误将大大减少。您可以使用
git commit+git commit --amend（或例如stg刷新（如果您使用StGIT 补丁管理界面1）来快照您的代码，而无需引入非工作核心的提交。经验法则是，提交应该做一件事，做得好，并且完全。
脚注
1. 或其他补丁管理界面的同等内容，例如 Guilt for Git，或 Mercurial Queues (mq) 扩展随 Mercurial 一起分发，这是 Guilt 的灵感来源。
You should certainly try to avoid comitting code which does not work, and perhaps even does not compile (I think even if you clean up hisory with
git rebase --interactivebefore pushing / publishing code). Otherwise value ofgit bisectto find bugs would get greatly diminished.You can use
git commit+git commit --amend(or e.g.stg refreshif you use StGIT patch management interface1) to snapshot your code without introducing commits with non-working core.The rule of thumb is that commit should do one thing, do it well, and do it completely.
Footnotes
1. Or equivalent for other patch management interfaces, like Guilt for Git, or Mercurial Queues (mq) extension distributed with Mercurial, which was inspiration for Guilt.
仅当您之前清理历史记录时，这才有意义：
为此，您需要一条带有描述您当前活动的通用前缀的提交消息。
使用 Git，您可以轻松地将所有这些中间提交压缩为一个。
有关更多信息，请参阅“修剪 GIT 签入/压缩 GIT 历史记录” 。
That would make sense only if you clean your history before:
For that, you need a commit message with a common prefix describing your current activity.
With Git, you can then easily squash all those intermediate commits into one.
See "Trimming GIT Checkins/Squashing GIT History" for more.
我不会在每次保存后都提交，除非你不经常保存。有时我会在每次更改 LOC 后进行保存。提交它们中的每一个当然没有意义，因为提交的补丁将是不完整的补丁以及损坏或无法构建的功能。
我的理念是在功能或风格的每一次有凝聚力的改变之后做出承诺。一个主要功能可以是多个提交，但每个提交都应该独立 - 您应该能够将该补丁移至另一个存储库，并且仍然在不破坏任何内容的情况下受到欢迎。如果您必须违反此规则进行提交，例如更改分支（并且您不想隐藏），那么您应该在提交消息前加上“wip”作为正在进行的工作的前缀。
更简短的说法是：如果每次保存后提交的想法对您来说听起来不是一种巨大的时间浪费，那么您保存得不够频繁。
I would not commit after every save, unless you save infrequently. I sometimes save after every LOC that I change. It certainly wouldn't make sense to commit each of them, because then the commits would be incomplete patches and broken or un-buildable functionality.
My philosophy is to commit after every cohesive change to functionality or style. A major feature can be several commits, but each one should stand on its own - you should be able to move that patch to another repo and still be welcome there without breaking anything. If you have to commit in violation of this rule, for example to change branches (and you don't want to stash) then you should prefix your commit message with "wip" for work in progress.
A shorter way to put it: if the idea of committing after every save doesn't sound like a huge waste of time to you, then you aren't saving often enough.
程序员的标准反射之一是按 Ctrl+S（或 :w）。如果你最终让他们加入你的团队，你的存储库将有大量的提交。哎呀，git 哈希值甚至没有直接告诉你有多少个。
从管理的角度来看，你真的不应该这样做。如果我必须恢复到今天早上的另一个版本，那么您实际上不必从数百个提交中进行选择。
也就是说，从技术角度来看，没有什么可以阻止您这样做。 Git 只会添加更多提交对象和指向 blob 的指针，其中大部分已经存在。
如果您继续这样做，您应该在合并时将提交从该分支压缩到另一个分支，以便您或其他存储库用户可以理解提交消息和单独的提交。
One of the standard reflex programmers have is to press Ctrl+S (Or :w). If you end up having them in your team, your repo is going to have a huge number of commits. Heck, git hashes doesn't even directly tell you how many there are.
You shouldn't really do it, from the managerial perspective. You shouldn't really have to choose from hundreds of commits, if I have to revert to another version I had this morning.
That said, there is nothing that prevents you to do so from a technical standpoint. Git only adds more commit objects and pointers to the blobs, most of which already exist.
If you go ahead and do so, you should squash the commits from this branch into another branch on merge, so that you, or the other repo users, can make sense of the commit messages and individual commits.