如果我们的组织要从类似颠覆的中央服务器VCS切换到像git这样的分布式VCS，我如何确保我的所有代码都不会出现硬件故障？

使用中央服务器VCS，我只需要每天备份存储库。如果我们使用的是DVCS，则所有开发人员机器上都会有大量的代码分支，并且如果该硬件出现故障(或者开发人员丢失了他的笔记本电脑或者被盗了)，那么我们将没有任何备份。 。

请注意，我认为"让开发人员将分支推送到服务器"不是一个好选择，因为这很乏味，并且开发人员最终将不这样做。

有解决此问题的常用方法吗？

一些澄清：

使用本机-中央服务器VCS，则所有内容都必须在中央服务器上，开发人员的最新更改除外。因此，例如，如果开发人员决定分支进行错误修复，则该分支位于中央服务器上，并且可立即用于备份。

如果我们使用的是DVCS，则开发人员可以执行本地分支(实际上很多本地分支)。在开发人员认为"哦，我应该将其推送到中央服务器"之前，这些分支都没有在中央服务器上并且可用于备份。

因此，我所看到的区别(如果我错了，请纠正我！)：如果使用的是DVCS，但使用的是普通的VCS，半实现的功能和错误修正可能无法在中央服务器上备份。如何确保该代码安全？

解决方案

在DVCS中使用"中央"服务器作为授权并不罕见，这也为我们提供了进行备份的地方。

我们可以让开发人员主目录通过本地网络挂载远程设备。然后，我们只需要担心使网络存储安全即可。或者，也许我们可​​以使用DropBox之类的东西将本地仓库无缝地复制到其他地方。

我认为使用分布式VCS必然意味着我们必须以完全分布式的方式使用它是一个谬论。建立一个通用的git仓库并告诉所有人该仓库是官方的仓库是完全有效的。对于正常的开发工作流程，开发人员将从通用存储库中提取更改并更新自己的存储库。仅在两个开发人员积极协作特定功能的情况下，他们才需要彼此直接进行更改。

由于有多个开发人员在从事一个项目，因此必须记住要从其他所有人那里进行更改会非常繁琐。如果没有中央存储库，我们将怎么办？

在工作中，我们有一个备份解决方案，该解决方案每天备份每个人的工作目录，并每周将全部内容写入DVD。因此，尽管我们有一个中央存储库，但是每个单独的存储库也都得到了备份。

我认为我们会发现，在实践中，开发人员宁愿使用中央存储库，也不愿在彼此的本地存储库之间进行推送和拉取。克隆中央存储库后，在处理任何跟踪分支时，获取和推送都是简单的命令。在我们所有同事的本地存储库中添加六个远程服务器是一件很痛苦的事情，这些存储库可能并非始终可以访问(关闭，在带回家的笔记本电脑上等)。

在某些时候，如果我们都在同一个项目上，那么所有工作都需要集成。这意味着我们需要一个集成分支，其中所有更改都汇集在一起​​。自然，所有开发人员都必须可以访问此位置，例如，它不属于主要开发人员的笔记本电脑。

设置中央存储库后，我们可以使用cvs / svn样式的工作流程来签入和更新。如果我们进行本地更改，则cvs更新将变为git fetch并重新设置基准，如果没有，则变为git pull。 cvs commit变为git commit和git push。

通过此设置，我们在完全集中的VCS系统中所处的位置类似。开发人员提交所做的更改(git push)后，便需要将这些更改显示给团队的其他成员，然后将它们保存在中央服务器上，并将对其进行备份。

两种情况都需要纪律，这是防止开发人员将长时间运行的更改保留在中央存储库之外。我们大多数人可能是在一个开发人员正在开发功能" x"的情况下工作的，而该功能需要对某些核心代码进行根本性的更改。更改将导致其他所有人都需要完全重建，但是该功能尚未准备好用于主流，因此他只是将其签出，直到合适的时间点为止。

尽管存在一些实际差异，但两种情况的情况非常相似。使用git，因为我们可以执行本地提交并可以管理本地历史记录，所以对于单个开发人员来说，推送到中央存储库的需求可能不会像使用cvs之类的感觉那么多。

另一方面，可以将使用本地提交作为优势。将所有本地提交推送到中央存储库中的安全位置应该不是很困难。本地分支可以存储在开发人员特定的标记名称空间中。

例如，对于Joe Bloggs，可以在其本地存储库中创建一个别名，以响应(例如)git mybackup来执行以下操作。

git push origin +refs/heads/*:refs/jbloggs/*

这是一个命令，可以在任何时候(例如一天结束)使用它，以确保安全地备份他的所有本地更改。

这有助于应对各种灾难。乔的机器崩溃了，他可以使用另一台机器，并且取回已保存的提交并从他停止的地方继续进行。乔病了？弗雷德(Fred)可以拿乔(Joe)的分支来抢购他昨天所做的"必须"修复，但没有机会与师父进行测试。

回到原来的问题。 dVCS和集中式VCS是否需要有所区别？我们说在dVCS情况下，半实现的功能和错误修正不会最终出现在中央存储库中，但是我认为这没有什么区别。

我已经看到许多情况，当使用集中式VCS时，一半实现的功能保留在一个开发人员的工作箱中。它或者采用允许将一半书面功能签入主流的策略，或者必须做出创建中央分支的决定。

在dVCS中，可能会发生相同的事情，但是应该做出相同的决定。如果有重要但不完整的工作，则需要集中保存。 git的优点是创建这个中央分支几乎是微不足道的。

我们团队中的所有开发人员也可以在服务器上拥有自己的分支机构(可以按票证或者按开发人员等)。这样，他们不会破坏master分支中的构建，但是仍然可以将正在进行的工作推送到要备份的服务器上。

对于这种类型的工作流程，我自己的git_remote_branch工具可能会派上用场(请注意，它需要Ruby)。它有助于操纵远程分支。

顺便提一下，谈论回购安全性，我们可以在服务器上设置一个提交后钩子，该钩子执行简单的git clone或者git push到另一台机器...每次提交后都可获得最新的备份！

我们使用rsync将单个开发人员.git目录备份到服务器上的目录。这是使用围绕git clone和后提交等钩子的包装脚本设置的。

由于它是在post- *挂钩中完成的，因此开发人员无需记住手动进行操作。并且由于我们将rsync与超时一起使用，因此，如果服务器关闭或者用户正在远程工作，他们仍然可以工作。

我觉得这个问题有些奇怪。假设我们使用的是非分布式版本控制系统(例如CVS)，那么我们将在中央服务器上拥有一个存储库，并在开发人员的服务器上进行中。我们如何备份存储库？我们如何备份开发人员的工作？这些问题的答案正是我们处理问题所要做的。

使用分布式版本控制，开发人员服务器上的存储库仍在进行中。我们要备份吗？然后备份！就这么简单。

我们有一个自动备份系统，该系统可以从我们指定的机器上获取所有目录，因此，我将计算机上的所有存储库和工作副本添加到最后一个机器上，包括git和CVS存储库。

顺便说一句，如果我们在发布产品的公司中使用分布式版本控制，那么我们将拥有一个中央存储库。这是我们从中释放的那个。它可能不在特殊的服务器上。它可能在某些开发人员的硬盘上。但是我们从中发布的存储库是中央存储库。 (我想如果我们还没有发布，那么我们可能还没有发布。)我觉得所有项目都有一个或者多个中央存储库。 (实际上，如果他们有多个项目，那就是两个项目，一个是分支。)这也适用于开源。

即使我们没有中央存储库，解决方案也相同：在开发人员的计算机上备份工作。无论如何，我们应该一直在这样做。正在进行的工作位于分布式存储库中，而不是CVS工作副本或者直接的非版本目录中，这一事实并不重要。