DVCS和数据丢失?

Dav*_*ver 5 version-control dvcs

在使用DVCS近两年之后,似乎一个固有的"缺陷"是意外的数据丢失:我丢失了没有推送的代码,我知道其他人也有.

我可以看到一些原因:非现场数据复制(即"提交必须转到远程主机")没有内置,存储库与代码和"hack"概念存在于同一目录中直到你有一些东西要发布"很普遍...但这不是重点.

我很想知道:您是否经历过与DVCS相关的数据丢失?或者您是否一直在使用DVCS?而且,相关的,除了"记得经常推"之外,还有什么可以做的,以尽量减少风险?

小智 2

与我使用 DVCS 所做的任何事情相比,我因破坏集中式 VCS 中未提交的更改,然后决定我确实需要它们而丢失了更多的数据。其中一部分原因是,我使用 CVS 已经有近十年了,而 git 还不到一年,所以我有很多机会遇到集中式模型的麻烦,但是不同版本之间的工作流属性存在差异。两种模型也是主要影响因素。

有趣的是,大多数原因都归结为“因为丢弃数据更容易,所以我更有可能保留它,直到我确定我不需要它为止”。(丢弃数据和丢失数据之间的唯一区别在于您有意丢弃它。)最大的影响因素可能是我的工作流程习惯的一个怪癖 - 当我使用 DVCS 时,我的“工作副本”通常是分布在多个不同的副本中在多台计算机上,因此单个存储库中的损坏或丢失,甚至我一直在使用的计算机上的灾难性数据丢失不太可能破坏数据的唯一副本。(能够做到这一点是分布式模型相对于集中式模型的一大胜利 - 当每次提交都成为存储库的永久部分时,复制尝试性更改的心理障碍要高得多。)

就最小化风险而言,养成将风险最小化的习惯是可能的,但你必须养成这些习惯。有两个一般原则:

  • 直到数据在不同的地方有多个副本时,数据才存在。有些工作流程习惯会免费为您提供多个副本 - 例如,如果您在两个不同的地方工作,您将有理由在每个工作会话结束时推送到一个公共位置,即使它还没有准备好发布。
  • 不要试图做任何聪明、愚蠢或超出你舒适区的事情,而只是参考你可能想要保留的承诺。创建一个可以恢复到的临时标记,或创建一个临时分支来执行操作。(git 的 reflog 可以让您在事后恢复旧的引用;如果其他 DVCS 具有类似的功能,我不会感到惊讶。因此,手动标记可能不是必需的,但无论如何它通常更方便。)