是否可以使用 Dropbox 托管裸 Git 存储库以共享代码？

Is it possible to host a bare Git repository using Dropbox, to share code?

提问by Dan Rosenstark

I realize that there are similar questions, but my question is slightly different: I'm wondering whether sharing a bare repositoryvia a synchronized Dropbox folder on multiple computers would work for sharing codevia Git?

我意识到有类似的问题，但我的问题略有不同：我想知道通过多台计算机上的同步 Dropbox 文件夹共享裸存储库是否适用于通过 Git共享代码？

In other words: is sharing a Git repo via Dropbox the same as sharing it from one centralized location, for example, via SSH or HTTP?

换句话说：通过 Dropbox 共享 Git 存储库与从一个集中位置共享它是否相同，例如，通过 SSH 或 HTTP？

Does the repo get updated on each person's local drive? Is this the same as sharing a Git repo via a shared network drive?

回购是否在每个人的本地驱动器上更新？这与通过共享网络驱动器共享 Git 存储库相同吗？

Note:This is notan empirical question: it seems to work fine. I'm asking whether the way a Git repo is structured is compatible with this way of sharing.

注意：这不是一个经验问题：它似乎工作正常。我在问 Git 存储库的结构方式是否与这种共享方式兼容。

EDITTo clarify/repeat, I'm talking about keeping the Git repository on Dropbox as a bare repository. I'm not talking about keeping the actual files that are under source control in Dropbox.

编辑为了澄清/重复，我说的是将 Dropbox 上的 Git 存储库作为裸存储库保留。我不是在谈论在 Dropbox 中保留受源代码控制的实际文件。

采纳答案by Jo Liss

I'm pretty sure that this is unsafe. There's a bunch of moving parts in a Git repository, and Dropbox could easily wreck one of them. For example, you might end up with incorrect branch tips (master, etc.) in the refsdirectory, or your object store might stop working if the objects/info/packsfile has the wrong contents. Git repos are fairly simple and robust, but they are not just dumb unbreakable storage.

我很确定这是不安全的。Git 存储库中有许多活动部件，Dropbox 可以轻松破坏其中一个。例如，您可能会在refs目录中得到不正确的分支提示（master 等），或者如果objects/info/packs文件内容错误，您的对象存储可能会停止工作。Git 存储库相当简单和健壮，但它们不仅仅是牢不可破的愚蠢存储。

Accessing remote repositories through SSH, git, or HTTP, or even locally on a network file system, is safe because the repository is only accessed through a gitprocess, which makes sure that everything is moved into place in the right order. But Dropbox doesn't make any kind of guarantees about ordering, so you might lose data.

通过 SSH、git 或 HTTP，甚至在本地网络文件系统上访问远程存储库是安全的，因为存储库只能通过一个git进程访问，这确保所有内容都以正确的顺序移动到位。但 Dropbox 不对订购做出任何保证，因此您可能会丢失数据。

Just use a Git server (or any SSH server) instead -- if you don't have one, GitHub, Bitbucketor GitLabcome to mind. It'll save you a lot of trouble, and it's no harder to use than a local repository shared through Dropbox (you just have SSH URLs instead of local paths).

只需使用 Git 服务器（或任何 SSH 服务器）——如果您没有，请想到GitHub、Bitbucket或GitLab。它会为您省去很多麻烦，而且使用起来并不比通过 Dropbox 共享的本地存储库难（您只有 SSH URL 而不是本地路径）。

回答by Andrew Aylett

I see no reason why it would lose data -- Git's repository structure is robust, and in the repository store itself, files with the same name will always have the same content (this doesn't apply to branch names).

我看不出它会丢失数据的原因——Git 的存储库结构是健壮的，并且在存储库存储本身中，具有相同名称的文件将始终具有相同的内容（这不适用于分支名称）。

It's not going to be efficient, though. Git's transfer protocol means that it will usually only transfer a change once. With Dropbox, if two people pack slightly different repositories, the packs generated may contain significant common data while not being identical, so DropBox would sync both packs, which is inefficient.

不过，这不会有效率。Git 的传输协议意味着它通常只会传输一次更改。使用 Dropbox，如果两个人打包稍微不同的存储库，生成的包可能包含重要的公共数据但不完全相同，因此 DropBox 会同步两个包，这是低效的。

You may also find that, although the data is all there, you wind up with un-tracked changes due to two copies both having the same branch updated at the same time. This can be worked around by ensuring that you push to different branches from each copy, but it'd be a pain.

您可能还会发现，尽管数据都在那里，但由于两个副本同时更新了相同的分支，因此最终会出现未跟踪的更改。这可以通过确保从每个副本推送到不同的分支来解决，但这会很痛苦。

回答by Pat Notz

What happens if two users are disconnected, do some work, push to their local copy of the bare repository and then go on line? In this case, when Dropbox tries to synchronize you'll get problems -- pack files and branch tips will be different and Dropbox can't fix that. That's the only problem I could see. I think the same thing could happen even if both users are connected, if they happen to be pushing into their local bare repositories at the same time.

如果两个用户断开连接，做一些工作，推送到他们的裸存储库的本地副本，然后再上线，会发生什么？在这种情况下，当 Dropbox 尝试同步时，您会遇到问题——打包文件和分支提示会有所不同，Dropbox 无法解决这个问题。这是我能看到的唯一问题。我认为即使两个用户都已连接，如果他们碰巧同时推送到他们的本地裸存储库，也会发生同样的事情。

回答by Kristopher Johnson

I've had problems using Dropbox with Git and with Mercurial. Repository files often get corrupted, presumably due to Dropbox's synching not being perfect, particularly when changes are being made from multiple places. Also, Dropbox works in the background, so it is really easy to accidentally try to use the repository (or reboot your machine) while it is in the middle of a sync operation.

我在将 Dropbox 与 Git 和 Mercurial 一起使用时遇到了问题。存储库文件经常被损坏，大概是因为 Dropbox 的同步不完美，特别是当从多个地方进行更改时。此外，Dropbox 在后台运行，因此很容易在同步操作过程中意外尝试使用存储库（或重启您的机器）。

I love Dropbox, but it is not a good replacement for a shared drive or a "real" remote Git repository.

我喜欢 Dropbox，但它不能很好地替代共享驱动器或“真正的”远程 Git 存储库。

回答by kubi

I used to do this with MobileMe, but the computers kept getting out of sync. Each computer would have a repo that was different than the one in the cloud and since there's no concept of "merge" in MobileMe (and I assume, DropBox, too, right?) I'd end up just having to either pick a version to keep and lose some edits, or copy the edits out and re-apply them. Life has gotten a whole lot easier since I switched to a central Git repo.

我以前用 MobileMe 这样做过，但电脑总是不同步。每台计算机都有一个与云中的不同的存储库，并且由于 MobileMe 中没有“合并”的概念（我认为 DropBox 也是如此，对吧？）我最终只需要选择一个版本保留和丢失一些编辑，或复制编辑并重新应用它们。自从我切换到中央 Git 存储库后，生活变得更加轻松。

If it's working for you so far, good. I imagine you're going to have a lot of pain if two devs push to their local bare repos at the same time, though. How's DropBox going to know which is right?

如果到目前为止它对你有用，那很好。不过，我想如果两个开发人员同时推送到他们本地的裸存储库，你会很痛苦。DropBox 如何知道哪个是正确的？

回答by vasilakisfil

If I told you that there are cases in which Dropbox has screwed up my Git would I answer your question by contradiction? At least in my experience, this has happened more than 5 times and there are a lot of people having the same experience out there.

如果我告诉你，在某些情况下 Dropbox 搞砸了我的 Git，我会反驳你的问题吗？至少以我的经验，这种情况已经发生了 5 次以上，并且有很多人有同样的经历。

But nowadays I don't believe that Dropbox is really that essential with Git, really. Actually you can set remote branches (Github, Gitorious, Bitbucket) which can replace Dropbox sharing and revision history features (isn't all that about Dropbox?) and offer you even more.

但是现在我不相信 Dropbox 对 Git 来说真的那么重要，真的。实际上，您可以设置远程分支（Github、Gitorious、Bitbucket），它可以取代 Dropbox 共享和修订历史功能（不就是 Dropbox 的全部功能吗？）并为您提供更多。

回答by Dan Rosenstark

One problem with DropBox has to do with how they handle historical backups. While you can roll back an individual file (within the last 30 days, or forever if you have PackRat), you cannot roll back entire directories. This means that if your repo gets screwed up for any reason, the amazing service of having a historical backup is essentially useless, since you would have to click on thousands of files to bring them back to an earlier version.

DropBox 的一个问题与它们如何处理历史备份有关。虽然您可以回滚单个文件（在过去 30 天内，或者如果您有 PackRat，则可以永远回滚），但您不能回滚整个目录。这意味着，如果您的存储库因任何原因被搞砸，拥有历史备份的惊人服务基本上是无用的，因为您必须单击数千个文件才能将它们恢复到早期版本。

And then there are the problems with race conditions, if you will, mentioned by most of the other answers.

然后还有竞争条件的问题，如果你愿意的话，大多数其他答案都提到了。

回答by Quy Le

I just host my repository on github.com as a private repository. Yes, you have to pay for a Micro plan ($7/plan) but you have the security knowing you have a backup of your code externally.

我只是将我的存储库作为私有存储库托管在 github.com 上。是的，您必须为 Micro 计划付费（7 美元/计划），但您知道您在外部有代码备份，因此您有安全感。