在使用 DVCS 近两年后，似乎一个固有的“缺陷”是意外的数据丢失：我丢失了未推送的代码，而且我知道其他人也有。
我可以看到一些原因：异地数据复制（即“提交必须转到远程主机”）没有内置，存储库与代码位于同一目录中以及“hack”的概念直到你有东西要发布”是普遍的......但这不是重点。
我很想知道：您是否经历过与 DVCS 相关的数据丢失？或者您一直在使用 DVCS 时没有遇到任何问题？而且，相关的，除了“记得经常推送”之外，还有什么可以做的来最小化风险吗？
问问题
226 次
3 回答
3
我从 DVCS 中丢失了数据，这既是因为删除了树以及存储库（不记得它有重要信息），也是因为使用 DVCS 命令行（git，在特定情况下）时出错：一些操作是旨在恢复我所做的更改实际上从存储库中删除了许多已经提交的修订。
于 2009-07-24T15:18:30.360 回答
2
由于在集中式 VCS 中破坏未提交的更改，然后决定我真正想要它们，我丢失了更多的数据，而不是我使用 DVCS 所做的任何事情。部分原因是我使用 CVS 将近十年，而使用 git 不到一年，所以我有更多机会在集中式模型上遇到麻烦，但是两者之间的工作流属性存在差异两种模型也是主要的促成因素。
有趣的是，这种情况的大部分原因归结为“因为丢弃数据更容易，我更有可能保留它，直到我确定我不想要它”。（丢弃数据和丢失数据的唯一区别是您打算丢弃它。）最大的影响因素可能是我的工作流程习惯的怪癖 - 当我使用 DVCS 时，我的“工作副本”通常是几个不同的副本分布在多台计算机上，因此单个存储库中的损坏或丢失甚至我一直在使用的计算机上的灾难性数据丢失不太可能破坏数据的唯一副本。（能够做到这一点是分布式模型相对于集中式模型的一大胜利——当每个提交都成为存储库的永久部分时，
就风险最小化而言，可以养成将风险最小化的习惯，但您必须养成这些习惯。那里有两个一般原则：
- 数据只有在不同的地方有多个副本时才会存在。有些工作流程习惯会免费为您提供多份副本 - 例如，如果您在两个不同的地方工作，您将有理由在每个工作会话结束时推送到一个公共位置，即使它还没有准备好发布。
- 不要试图做任何聪明、愚蠢或超出你舒适区的事情，只参考你可能想要保留的提交。创建一个可以恢复到的临时标签，或者创建一个临时分支来执行操作。（git 的 reflog 可让您在事后恢复旧的引用；如果其他 DVCS 具有类似的功能，我不会感到惊讶。因此可能不需要手动标记，但无论如何它通常更方便。）
于 2009-07-25T02:04:28.600 回答
0
在分发和确保所有内容都“保存”之间存在固有的张力（基本假设是保存意味着在其他地方备份）。
IMO，如果您在同一工作线上同时在多台计算机上工作，这只是一个真正的问题（或者更确切地说是几个存储库：例如，我经常需要在同一台计算机上的多个 VM 之间共享更改）。在这种情况下，“集中式”工作流将是理想的：您将设置一个临时服务器，并在某些给定的分支上使用集中式工作流。我所知道的当前 DVCS（git/bzr/hg）都没有很好地支持这一点。不过，这将是一个很好的功能。
于 2009-07-25T02:28:59.640 回答