如果我们的组织要从像subversion这样的中央服务器VCS切换到像git这样的分布式VCS，我该如何确保我的所有代码都免受硬件故障的影响？
使用中央服务器VCS，我只需要每天备份存储库。如果我们使用的是DVCS，那么所有开发者机器上都会有大量的代码分支，如果硬件失败（或者开发人员丢失了他的笔记本电脑或者它被盗），那么我们就没有任何备份
请注意，我不认为“让开发人员将分支机构推送到服务器”这是一个不错的选择 - 那是tedious而开发人员最终没有这样做。
这个问题有一个共同的方法吗？
一些澄清：
使用本机中央服务器VCS，除了开发人员的最新更改之外，所有必须位于中央服务器上。因此，例如，如果开发人员决定进行分支以执行错误修正，则该分支位于中央服务器上并可立即备份。
如果我们使用DVCS，那么开发人员可以进行本地分支（实际上是许多本地分支）。在开发人员认为“哦，是的，我应该将其推送到中央服务器”之前，这些分支都不在中央服务器上并且可用于备份。
所以我看到的差异（如果我错了，请纠正我！）：如果我们使用的是DVCS，那么半实现的功能和错误修正可能无法在中央服务器上进行备份，但是正常VCS。如何保证代码安全？
答案 0 :(得分：12)
我认为您会发现在实践中，开发人员更愿意使用中央存储库，而不是在彼此的本地存储库之间推送和拉动。一旦克隆了中央存储库，在处理任何跟踪分支时，获取和推送都是微不足道的命令。将六个遥控器添加到所有同事的本地存储库是一件痛苦的事情，这些存储库可能并不总是可以访问（关闭，带回家的笔记本电脑等）。
在某些时候，如果你们都在同一个项目上工作，那么所有工作都需要整合。这意味着您需要一个集成分支，其中所有更改都汇集在一起。这自然需要所有开发人员都可以访问，例如，它不属于首席开发人员的笔记本电脑。
一旦设置了中央存储库，就可以使用cvs / svn样式工作流来签入和更新。如果你有本地更改，cvs update会变成git fetch和rebase，如果你没有，就会变成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/*
这是一个可以在任何时候（例如一天结束时）使用的命令，以确保安全备份所有本地更改。
这有助于各种灾难。 Joe的机器爆炸，他可以使用另一台机器，并且获取保存提交并从他离开的地方继续。乔病了吗？弗雷德可以取得乔的分支来抓住他昨天所做的“必须”修复，但没有机会对主人进行测试。
回到原来的问题。是否需要在dVCS和集中式VCS之间存在差异？你说半实现的功能和错误修正不会最终出现在dVCS案例的中央存储库中，但我认为没有区别。
我见过很多情况，当使用集中式VCS时，一个半实现的功能停留在一个开发人员工作盒上。它要么采取允许将半写功能签入主流的策略，要么必须做出决定来创建中心分支。
在dVCS中可能会发生同样的事情，但应该做出同样的决定。如果有重要但不完整的工作，则需要集中保存。 git的优点是创建这个中心分支几乎是微不足道的。
答案 1 :(得分：4)
我认为使用分布式VCS必然意味着必须以完全分布式方式使用它，这是一种谬论。设置一个通用的git存储库并告诉每个人存储库是官方存储库是完全有效的。对于正常开发工作流，开发人员将从公共存储库中提取更改并更新其自己的存储库。只有在两个开发人员积极协作处理特定功能的情况下，他们才需要直接相互提取更改。
由于有多个开发人员正在开发一个项目，因此必须记住从其他人那里获取更改是非常繁琐的。如果没有有中央存储库，你会怎么做？
在工作中，我们有一个备份解决方案，每天备份每个人的工作目录，并将每一周写入DVD。因此，虽然我们有一个中央存储库，但每个存储库都会备份。
答案 2 :(得分：1)
使用“中央”服务器作为DVCS的权限并不罕见，它还为您提供备份的地方。
答案 3 :(得分：1)
我发现这个问题有点奇怪。假设您使用的是非分布式版本控制系统，例如CVS，您将在中央服务器上拥有一个存储库，并在开发人员的服务器上进行工作。你如何备份存储库？您如何支持开发人员的工作进度？这些问题的答案正是您处理问题所必须做的。
使用分布式版本控制，开发人员服务器上的存储库正在进行中。你想支持它吗？然后备份它！就这么简单。
我们有一个自动备份系统，可以抓取我们指定的机器上的任何目录，因此我将我的机器上的任何存储库和工作副本添加到最后，包括git和CVS存储库。
顺便说一下，如果您在发布产品的公司中使用分布式版本控制，那么将拥有一个中央存储库。这是你释放的那个。它可能不在特殊的服务器上;它可能出现在一些开发人员的硬盘上。但是您发布的存储库是中央存储库。 （我想如果你还没有发布，但是，你可能还没有。）我觉得所有项目都有一个或多个中央存储库。 （实际上，如果它们有多个，那么它是两个项目，一个是分叉。）这也适用于开源。
即使您没有中央存储库，解决方案也是如此：在开发人员的计算机上备份工作。无论如何你应该这样做。正在进行的工作是在分布式存储库而不是CVS工作副本或直接非版本化目录这一事实并不重要。
答案 4 :(得分：0)
您可以让开发人员主目录通过本地网络安装远程设备。然后，您只需担心使网络存储安全。或者也许您可以使用DropBox之类的东西无缝地将您的本地仓库复制到其他地方。
答案 5 :(得分：0)
您团队中的所有开发人员也可以在服务器上拥有自己的分支（可以是每张票，也可以是每个开发者等）。这样他们就不会破坏master分支中的构建，但他们仍然可以将正在进行的工作推送到备份的服务器。
My own git_remote_branch工具可以为这种工作流程派上用场（注意它需要Ruby）。它有助于操纵远程分支。
作为旁注，谈论repo安全性，在你的服务器上你可以设置一个post-commit钩子，它做一个简单的git clone或git push到另一台机器......你在每次提交后得到一个最新的备份！
答案 6 :(得分：0)
我们使用rsync将各个开发人员.git目录备份到服务器上的目录。这是使用围绕git clone的包装器脚本和post-commit等钩子设置的。
因为它是在post-* hooks中完成的，所以开发人员不需要记住手动执行它。而且因为我们使用带有超时的rsync，如果服务器出现故障或用户正在远程工作，它们仍可以正常工作。