在推送到服务器之间如何/在哪里备份 DVCS 的本地签出?

发布于 2024-09-11 08:43:54 字数 102 浏览 2 评论 0原文

您(和您的团队)是否在推送之间备份 DVCS(Git、Mercurial)存储库的本地签出?你是如何做到的?如果您的硬盘在编写了一堆尚未稳定(因此尚未推送)的代码后出现故障,您将如何恢复它?

Do you (and your team) back up your local checkouts of your DVCS (Git, Mercurial) repository between pushes? How do you do so? If your hard drive were to fail after writing a bunch of code that was not yet stable (therefore not yet pushed), how would you get it back?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

初见终念 2024-09-18 08:43:54

我很偏执。

除了我们的中央存储库(使用 git init --shared --bare 设置)之外,我还在网络驱动器上设置了另一个镜像存储库:

cd /network/drive
git init --bare
cd /local/repo
git remote add backup --mirror /network/drive
git push backup

我只是偶尔推送到 < code>backup,并且由于它是镜像存储库,因此它本质上只是我的本地存储库的完整克隆。

I'm paranoid.

Besides our central repository (set up with git init --shared --bare), I have another mirror repository set up on a network drive:

cd /network/drive
git init --bare
cd /local/repo
git remote add backup --mirror /network/drive
git push backup

I just occasionally push to backup, and since it is a mirrored repository, it's essentially just a full clone of my local repository.

孤千羽 2024-09-18 08:43:54

是的,您应该在提交之间使用普通的备份系统。

事实上,版本控制与备份无关。我的意思是,你应该为所有员工建立一个备份系统,无论他们是开发人员、秘书、经理还是其他人。无论桌面是否使用版本控制系统,都应该进行备份。

我认为版本控制系统是用于构建软件开发并使许多人能够一起工作的重要工具。当您需要维护多个并行版本或需要调查错误时,它是一个必不可少的工具。您也许可以使用备份系统来确定错误首次引入的时间,但不能使用备份系统来维护多个并行分支。因此,版本控制系统为您提供的不仅仅是备份系统,备份系统通过处理所有未提交的文件来补充版本控制系统。

现在,您当然想要对存储库本身进行备份。使用分布式版本控制,这非常简单——您只需从本地存储库推送到远程备份服务器上的另一个存储库即可。这样,VCS 将负责锁定并确保备份服务器上的状态保持一致。

Yes, you should use a normal backup system in between your commits.

In fact, version control has nothing to do with backups. By this I mean that you should put a backup system in place for all employees, whether they are developers, secretaries, managers, or something else. The desktops should be backed up regardless of whether or not they are using a version control system.

I see a version control system as a crucial tool used to structure software development and to enable many people to work together. It is an essential tool when you need to maintain several parallel releases, or when you need to investigate a bug. You may be able to use a backup system to figure out when a bug was first introduced, but you cannot use a backup system to maintain several parallel branches. So a version control system gives you more than a backup system, and a backup system complements a version control system by taking care of all those uncommitted files.

Now, you will of course want to make backups of the repositories themselves. With distributed version control this is super easy -- you just push from your local repository to another repository on a remote backup server. This way the VCS will take care of locking and ensure that you have a consistent state on the backup server.

怪我入戏太深 2024-09-18 08:43:54

有趣的是,你问这个问题是因为我上周刚刚开了一个会议,我听说有些人在权威存储库上使用不可运行甚至不可编译的代码的提交/推送只是为了保存它! (注:与Mark所说的不同)。在我看来,这非常错误,并且妨碍了持续集成,因此我们决定安装基于 rsync 的备份服务器,以便开发人员意识到版本控制和备份工具是多么互补!

我还没有安装服务器,但是如果你有一台空闲的 Unix 机器,上面运行着 ssh 服务器,一个简单的 crontab 就可以完成这项工作,例如使用 ssh 和 rsync (如果你有一个 NFS 安装的分区,它会甚至更简单):(

$ crontab -l
# m h  dom mon dow   command
0,15,30,45 * * * * if `ping -c 1 machine.domaine.com
> /dev/null 2> /dev/null` ; then export SSH_AGENT_PID=
"`pgrep -l ssh-agent | cut -d' ' -f1`" ; export SSH_AUTH_SOCK=
"`/usr/bin/find /tmp -path '*ssh-*' -type s -user name -group
gname -name '*agent*' 2> /dev/null`" ; /usr/bin/rsync -avz -e ssh
--quiet /home/name/src [email protected]:/home/name/backup/src ; fi

我假设您可以使用 ssh 登录计算机,您有一个 ssh-agent 正在运行并且已经使用了 ssh-add)。

这样,每 15 分钟就会保存正在进行的工作,并且由于 rsync 可以非常快地确定发生了什么变化,因此它不应该使您的工作站太慢。
崩溃,只需登录 machine.domain.com,使用您的备份凭据 :-) 并继续工作...

希望它会有所帮助。

干杯,
克里斯托夫.

= 安全主要是一种迷信。它在自然界中不存在。 ——海伦·凯勒=

Funny that you ask this question because I just had a meeting last week where i heard some people were using commit/push of non-runnable even non-compilable code on the authoritative repository just to save it! (Note: it's different from what Mark says). It appeared so wrong to me and so getting in the way of Continuous Integration that we decided to install an rsync-based backup server so that the developers would realize how complementary version control and backup tools are!

I haven't yet installed the server, but if you have a spare Unix machine with an ssh server running on it, a simple crontab could do the job, e.g. using ssh and rsync (if you have an NFS-mounted partition, it would even be simpler):

$ crontab -l
# m h  dom mon dow   command
0,15,30,45 * * * * if `ping -c 1 machine.domaine.com
> /dev/null 2> /dev/null` ; then export SSH_AGENT_PID=
"`pgrep -l ssh-agent | cut -d' ' -f1`" ; export SSH_AUTH_SOCK=
"`/usr/bin/find /tmp -path '*ssh-*' -type s -user name -group
gname -name '*agent*' 2> /dev/null`" ; /usr/bin/rsync -avz -e ssh
--quiet /home/name/src [email protected]:/home/name/backup/src ; fi

(I assume that you can log in the machine using ssh, that you have an ssh-agent running and have used ssh-add).

This way, every 15 minutes, on-going work is saved, and as rsync is quite fast figuring out what has changed, it shouldn't make your workstation too slow.. In case your disk
crashes, simply log into machine.domain.com, use your backup-ed credentials :-) and continue to work...

Hope it'll help.

Cheers,
Christophe.

= Security is mostly a superstition. It does not exist in nature. -- Helen Keller =

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文