代码之家 › 专栏 › 技术社区 › blockhead

在每次使用DVC保存之后提交是否有意义?

dvcs mercurial git

2

blockhead · 技术社区 · 14 年前

我知道这个问题已经被问过了,多长时间使用一次DVC。所有答案都有一个共同点——尽可能多。但它们通常是这样的:在完成一个想法之后,一个用户故事,获取编译的代码,或者通过测试。我在想,既然一个dvcs给了你自己的存储库,而且提交成本很低,那么在每次更改一个文件之后提交是不是有意义?毕竟,这就是在NetBeans中发生的事情,你可以得到一个很好的免费“时间机器”,甚至不需要它。如果不是每次更改,那么至少每次保存或编译。

这有道理吗,还是我对dvc有错误的想法?我觉得这不是大多数人使用DVC的工作流程。

5 回复 | 直到 14 年前

1

4

Jakub NarÄbski adamtaub 14 年前

当然,你应该尽量避免输入不起作用的代码,甚至可能不编译(我想即使你用hisory清除了它 git rebase --interactive 在推送/发布代码之前)。其他值 git bisect 发现错误会大大减少。

你可以使用 git commit + git commit --amend (或例如 stg refresh 如果你使用 StGIT 补丁管理界面 ^一 )在不引入使用非工作核心的提交的情况下快照代码。

经验法则是提交应该做到 一件事 做得好,做得好 完全地 .

脚注

^1。或其他补丁管理接口的等效产品,如 Guilt 对于Git,或 Mercurial Queues (mq)扩展以反复无常的方式分布,这是罪恶感的灵感。

2

5

Daniel Stutzbach Edward Leno 14 年前

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

它可以让Met轻松地回顾我以前的保存,但不会将常规分支与非工作提交混淆。两全其美。

3

Community Neeleshkumar S 7 年前

只有当你以前清理过自己的历史,这才有意义:

把它推到任何其他回购
或者甚至将其合并/重新组合到本地回购中的任何其他分支。

为此,您需要一个带有描述当前活动的公共前缀的提交消息。
使用Git,您可以轻松地将所有中间提交压缩为一个提交。
见“ Trimming GIT Checkins/Squashing GIT History “为了更多。

4

2

Tesserex 14 年前

每次救人之后我都不会承诺,除非你很少救人。每次换车后我都会存钱。提交它们中的每一个都是毫无意义的,因为这样提交将是不完整的补丁和中断的或不可构建的功能。

我的理念是在每一次功能性或风格的一致性改变之后承诺。一个主要的特性可以是多个提交,但是每个提交都应该独立存在——您应该能够将该补丁移动到另一个repo,并且在不破坏任何内容的情况下仍然受到欢迎。如果您必须违反此规则进行提交,例如要更改分支(并且不想存储),那么对于正在进行的工作,您应该在提交消息前面加上“WIP”前缀。

一个简短的说法是:如果每次储蓄后承诺的想法听起来不像是在浪费时间,那么你就没有经常储蓄。

5

1

lprsd 14 年前

标准的Reflex程序员之一是按下ctrl+s(或:w)。如果最终你的团队中有他们,你的回购协议将会有大量的承诺。嘿,Git哈希甚至不能直接告诉你有多少。

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

也就是说,从技术角度来说,没有什么可以阻止您这样做。Git只向blob添加更多的提交对象和指针,其中大部分已经存在。

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