logo标签列表

如何确保我的Git代码仓库是安全的？

gitbackupdvcs
7
如果我们的组织从像subversion这样的集中式服务器版本控制系统切换到像git这样的分布式版本控制系统，我该如何确保我的所有代码都不受硬件故障的影响？
使用集中式服务器版本控制系统，我只需要每天备份存储库。如果我们使用分布式版本控制系统，那么所有开发人员的机器上都会有大量的代码分支，如果这些硬件出现故障（或者开发人员丢失笔记本电脑或被盗），那么我们就没有任何备份。
请注意，我不认为“让开发人员将分支推送到服务器”是一个好的选择——那太繁琐了，开发人员最终不会这样做。
有没有常见的解决这个问题的方法？
一些澄清：
对于本地中心服务器版本控制系统，除了开发人员最近的更改之外，所有内容都必须在中心服务器上。因此，例如，如果开发人员决定创建分支来修复错误，则该分支位于中心服务器上，并可立即进行备份。
如果我们使用的是分布式版本控制系统（DVCS），那么开发人员可以创建本地分支（实际上可以创建多个本地分支）。这些分支都不在中央服务器上，也无法备份，直到开发人员想到“哦，对了，我应该将其推送到中央服务器”为止。
因此，我看到的区别是（如果我错了，请纠正！）：如果我们使用DVCS，则半实现的功能和错误修复可能不会在中央服务器上备份，但在普通的VCS上则有。如何确保该代码的安全性？
7个回答
12
我认为你会发现，在实践中，开发人员更倾向于使用集中式仓库而不是在彼此之间推送和拉取本地仓库。一旦你克隆了中央仓库，在任何跟踪分支上工作时，获取和推送都是微不足道的命令。给所有同事的本地仓库添加半打远程仓库很麻烦，而且这些仓库可能并不总是可用的（关闭，放在家里的笔记本电脑上等）。
在某个时刻，如果你们都在同一个项目上工作，所有的工作都需要集成。这意味着你需要一个集成分支，所有的更改都会汇聚到这个分支上。这自然需要在所有开发人员都可以访问的地方，例如它不应该在主要开发人员的笔记本电脑上。
一旦你设置了一个中央仓库，你就可以使用类似cvs/svn的工作流来检入和更新。cvs update变成了git fetch和rebase（如果你有本地更改），或者只是git pull（如果没有）。cvs commit 变成了git commit和git push。
有了这个设置，你就可以像完全集中式的版本控制系统一样工作。一旦开发人员提交了他们的更改（git push），他们就在中央服务器上，并且会备份。
在两种情况下都需要遵守的规则是防止开发人员将长时间运行的更改留在中央仓库之外。我们中的大多数人可能曾经在这样的情况下工作过，其中一名开发人员正在开发功能“x”，需要在某些核心代码中进行基本更改。这个更改将导致所有其他人都需要完全重建，但是该功能还没有准备好进入主流，因此他只是将其保留在检出状态，直到适当的时间点。
两种情况非常相似，尽管存在一些实际上的差异。使用Git，因为你可以执行本地提交并管理本地历史记录，所以个人开发者可能不像使用cvs那样感到需要推送到中央仓库。
另一方面，使用本地提交的优点是可以作为优势。将所有本地提交推送到中央仓库的安全位置应该不会很困难。本地分支可以存储在开发人员特定的标签命名空间中。
例如，对于Joe Bloggs，可以在他的本地仓库中创建一个别名来响应（例如）git mybackup，并执行以下操作。
git push origin +refs/heads/*:refs/jbloggs/*

这是一个单一命令，可在任何时间点（例如一天结束时）使用，以确保所有本地更改得到安全备份。

这对各种灾难都有帮助。Joe的机器坏了，他可以使用另一台机器并获取保存的提交，并从离开的地方继续工作。Joe病了？Fred可以获取Joe的分支，抓取他昨天做的“必须”的修复，但没有机会与主干进行测试。

回到最初的问题。dVCS和集中式VCS之间需要有区别吗？你说在dVCS情况下，半实现的特性和错误修复将不会出现在中央存储库中，但我认为并不需要有区别。

我见过很多情况，在使用集中式VCS时，半实现的特性留在一个开发者的工作电脑上。要么需要制定允许检查半写特性的策略，要么就必须决定创建一个中央分支。

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

4
我认为使用分布式版本控制系统并不一定意味着必须完全分布式地使用它，这是一个谬论。可以完全合理地设置一个共同的git仓库，并告诉所有人该仓库是官方的。对于正常的开发工作流程，开发人员会从共同仓库中拉取更改并更新自己的仓库。只有在两个开发者积极协作完成特定功能时，他们才需要直接从彼此那里拉取更改。
如果有多个开发者在项目上工作，那么记住从其他人那里拉取更改将会非常繁琐。如果没有中央仓库怎么办？
在我们工作中，我们有一个备份解决方案，每天备份每个人的工作目录，并每周将整个备份写入DVD。因此，尽管我们有一个中央仓库，但每个个人的仓库也得到了备份。
格雷格 - 我澄清了问题，强调我谈论的是半实现功能/错误分支。无论是VCS还是DVCS，都需要一个中央服务器用于发布等等。 - Stewart Johnson
1

在分布式版本控制系统中，使用“中央”服务器作为权威机构并不罕见，这也为您提供了备份的位置。

1

我觉得这个问题有点奇怪。假设你使用的是非分布式版本控制系统，比如CVS，你会在中央服务器上拥有一个仓库和开发者服务器上的工作进展。你如何备份仓库？如何备份开发者的工作进展？这些问题的答案正是你处理这个问题所必须做的。

使用分布式版本控制，开发者服务器上的仓库只是工作进展。你想要备份它吗？那就备份它！就这么简单。

我们有一个自动备份系统，可以抓取我们指定的任何目录，因此我将我的机器上的任何仓库和工作副本都添加到了最后，包括git和CVS仓库。

顺便说一下，如果你在公司发布产品时使用分布式版本控制，那么你将会有一个中央仓库。这是你发布的仓库。它可能不在特殊的服务器上，可能在某个开发者的硬盘上。但是你发布的仓库就是中央仓库。（我想如果你还没有发布，你可能还没有一个中央仓库。）我觉得所有项目都有一个或多个中央仓库。（如果有多个，那就是两个项目，其中一个是分支。）这也适用于开源项目。

即使你没有中央仓库，解决方案也是相同的：备份开发者机器上的工作。你本来就应该这样做。正在进行的工作在分布式仓库中而不是CVS工作副本或直接非版本化目录中的事实并不重要。

我们不备份开发人员的工作站（如果你有数百个工作站，这是很昂贵的），并鼓励他们每天提交几次。然后我们只需要备份服务器。但这在Git中不是一个选项。 - Stewart Johnson
你仍然处于完全相同的境地，问着完全相同的问题：是否备份开发人员正在进行的工作？你选择不备份。分布式版本控制并没有使这种情况变得更糟或更好。 - skiphoppy
1
需要认识到的是，分布式版本控制并不会将您的代码分布在许多计算机上。分布在许多计算机上的只有正在进行中的工作，而这些工作已经没有备份了。您发布的仓库或仓库所在的位置需要备份。 - skiphoppy
0

你可以让开发者的主目录挂载本地网络上的远程设备。这样，你只需要担心如何保证网络存储的安全性。或者你也可以使用类似DropBox的工具，将你的本地代码库无缝地复制到其他地方。

家目录挂载本地网络上的远程设备。 我们以前尝试过这样做，通常因为网络延迟而导致灾难。还有，这意味着备份磁带要存更多的东西。 - Stewart Johnson
0

你的团队中的所有开发人员也可以在服务器上拥有自己的分支（可以按票据或按开发者等方式）。这样，他们就不会破坏主分支中的构建，但仍然可以将其正在进行的工作推送到得到备份的服务器。

我自己的git_remote_branch 工具可能对这种工作流程很有用（请注意，它需要Ruby）。它有助于操作远程分支。

顺便说一句，谈到存储库安全性，在您的服务器上，您可以设置一个 post-commit 钩子，执行简单的 git clone 或 git push 到另一台机器... 每次提交后都会得到最新的备份！

0
我们使用rsync将各个开发人员的.git目录备份到服务器上的一个目录中。这是通过在git clone周围设置包装脚本以及post-commit等钩子来完成的。
由于它是在post-*钩子中完成的，因此开发人员无需记住手动执行它。而且，由于我们使用带有超时的rsync，如果服务器崩溃或用户远程工作，他们仍然可以继续工作。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接