使用DVCS进行每次保存后提交是否有意义？

Question

我知道在提交DVCS的频率之前已经问过这个问题。所有答案都有一个共同点 - 尽可能经常。但它们通常是在完成一个思想，一个用户故事，获得编译代码或通过测试之后。 我在想，鉴于DVCS为您提供了自己的存储库，提交非常便宜，在每次更改文件后提交都没有意义吗？毕竟，这就是NetBeans中发生的事情，你得到一个很好的免费“时间机器”，甚至没有要求它。如果不是每次改变，那么至少每次保存或编译。

这是否有意义，或者我对DVCS有错误的想法。我的感觉是，这不是大多数人使用DVCS的工作流程。

Answer 1

我为git和emacs的用户使用了真棒git-wip工具。它每次保存时都会进行提交，但它会在侧分支中进行提交。自动提交不会成为主分支上的历史记录的一部分，因此通常不会传播到其他存储库。

让我们很容易回顾过去以前的保存，但不会因为非工作提交而使我的常规分支混乱。两全其美。

Answer 2

你当然应该尽量避免编写不起作用的代码，甚至可能不编译（我想即使你在推送/发布代码之前用git rebase --interactive清理组织索引）。否则git bisect找到错误的值会大大减少。

如果您使用stg refresh补丁管理界面 ¹ ），您可以使用git commit + git commit --amend（例如StGIT来快照您的代码引入具有非工作核心的提交。

经验法则是提交应该一件事，做得好，并且完全。

---

脚注

^1。或其他补丁管理界面的等价物，例如Git的Guilt或Mercurial分发的Mercurial Queues（mq）扩展，这是Guilt的灵感。< / p>

Answer 3

只有在您之前清理历史记录时才有意义：

• 将其推送到任何其他回购
• 甚至将其合并/重新定位到本地仓库中的任何其他分支。

为此，您需要一个带有描述当前活动的公共前缀的提交消息 使用Git，您可以轻松地将所有这些中间提交压缩为一个 有关详情，请参阅“Trimming GIT Checkins/Squashing GIT History”。

Answer 4

除非你不经常保存，否则我不会在每次保存后提交。在我改变的每一个LOC之后，我有时会保存。提交它们当然没有意义，因为提交将是不完整的补丁和破坏或不可构建的功能。

我的理念是在功能或风格的每一次有变化之后都要做出承诺。一个主要功能可以是几个提交，但每个应该独立 - 你应该能够将该补丁移动到另一个回购，并且仍然可以在那里受到欢迎而不会破坏任何东西。如果您必须违反此规则进行提交，例如更改分支（并且您不想隐藏），那么您应该在提交消息前加上“wip”作为正在进行的工作。

更简单的说法：如果每次保存后提交的想法听起来不是浪费你的时间，那么你就不会经常保存。

Answer 5

标准反射程序员之一就是按Ctrl + S（或：w）。如果你最终在你的团队中拥有它们，那么你的repo将会有大量的提交。哎呀，git哈希甚至没有直接告诉你有多少。

从管理角度来看，你不应该真的这样做。如果我必须恢复到今天早上的另一个版本，你不应该真的必须从数百个提交中进行选择。

尽管如此，从技术角度来看，没有什么可以阻止你这样做。 Git只添加了更多的提交对象和指向blob的指针，其中大部分已经存在。

如果您继续这样做，您应该在合并时将提交从此分支压缩到另一个分支，以便您或其他repo用户可以理解提交消息和单个提交。