是否可以使用 Dropbox 托管一个裸 Git 存储库来共享代码？
我意识到有类似的问题，但我的问题略有不同：我想知道是否通过多台计算机上的同步 Dropbox 文件夹共享裸存储库是否可以通过 Git共享代码？
换句话说：通过 Dropbox 共享 Git 存储库与从一个集中位置（例如通过 SSH 或 HTTP）共享 Git 存储库相同吗？
存储库是否会在每个人的本地驱动器上更新？这与通过共享网络驱动器共享 Git 存储库相同吗？
注意：这不是一个经验问题：它似乎工作得很好。我想问 Git 存储库的结构方式是否与这种共享方式兼容。
编辑为了澄清/重复，我正在讨论将 Dropbox 上的 Git 存储库作为裸存储库。我并不是在谈论将受源代码控制的实际文件保留在 Dropbox 中。
I realize that there are similar questions, but my question is slightly different: I'm wondering whether sharing a bare repository via a synchronized Dropbox folder on multiple computers would work for sharing code via 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?
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?
Note: This is not an 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.
EDIT To 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我不明白为什么它会丢失数据——Git 的存储库结构很强大，并且在存储库存储本身中，具有相同名称的文件将始终具有相同的内容（这不适用于分支名称）。
但这不会很有效率。 Git 的传输协议意味着它通常只会传输一次更改。使用 Dropbox，如果两个人打包的存储库略有不同，则生成的包可能包含重要的公共数据，但并不完全相同，因此 DropBox 会同步两个包，这是低效的。
您还可能会发现，尽管数据都在那里，但由于两个副本同时更新了相同的分支，您最终会遇到未跟踪的更改。这可以通过确保从每个副本推送到不同的分支来解决，但这会很痛苦。
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).
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.
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.
我很确定这是不安全的。 Git 存储库中有一堆移动部件，Dropbox 可以轻松破坏其中一个。例如，您可能会在
refs目录中得到不正确的分支提示（master 等），或者如果objects/info/packs文件内容错误。 Git 存储库相当简单且强大，但它们不仅仅是愚蠢且牢不可破的存储。通过 SSH、git 或 HTTP，甚至在本地网络文件系统上访问远程存储库是安全的，因为存储库只能通过 git 进程访问，这确保了所有内容都已移动到位正确的顺序。但 Dropbox 不对订购做出任何形式的保证，因此您可能会丢失数据。
只需使用 Git 服务器（或任何 SSH 服务器）即可 - 如果您没有，GitHub， Bitbucket 或 GitLab 浮现在我的脑海中。它会为您省去很多麻烦，而且使用起来并不比通过 Dropbox 共享的本地存储库难（您只需使用 SSH URL 而不是本地路径）。
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 theobjects/info/packsfile has the wrong contents. Git repos are fairly simple and robust, but they are not just dumb unbreakable storage.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.Just use a Git server (or any SSH server) instead -- if you don't have one, GitHub, Bitbucket or GitLab come 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).
如果两个用户断开连接，执行一些操作，推送到裸存储库的本地副本，然后上线，会发生什么？在这种情况下，当 Dropbox 尝试同步时，您会遇到问题 - 打包文件和分支提示将不同，而 Dropbox 无法修复该问题。这是我能看到的唯一问题。我认为即使两个用户都已连接，如果他们碰巧同时推送到本地裸存储库，同样的事情也可能发生。
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 与 Git 和 Mercurial 时遇到问题。存储库文件经常会损坏，可能是由于 Dropbox 的同步不完美造成的，尤其是在从多个位置进行更改时。此外，Dropbox 在后台运行，因此在同步操作过程中很容易意外尝试使用存储库（或重新启动计算机）。
我喜欢 Dropbox，但它并不是共享驱动器或“真正的”远程 Git 存储库的良好替代品。
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.
I love Dropbox, but it is not a good replacement for a shared drive or a "real" remote Git repository.
我曾经使用 MobileMe 执行此操作，但计算机总是不同步。每台计算机都会有一个与云中的存储库不同的存储库，并且由于 MobileMe 中没有“合并”的概念（我认为 DropBox 也是如此，对吧？）我最终只需要选择一个版本保留和丢失一些编辑，或者复制编辑并重新应用它们。自从我改用中央 Git 存储库后，生活变得轻松多了。
如果到目前为止它对你有用，那就太好了。不过，我想如果两个开发人员同时推送到他们本地的裸仓库，你会感到很痛苦。 DropBox 如何知道哪个是正确的？
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.
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 在某些情况下搞砸了我的 Git，我会矛盾地回答你的问题吗？
至少以我的经验来看，这种情况已经发生过五次以上了，而且有很多人有同样的经历。
但现在我不相信 Dropbox 与 Git 真的那么重要，真的。实际上，您可以设置远程分支（Github、Gitorious、Bitbucket），它们可以取代 Dropbox 共享和修订历史记录功能（这不就是 Dropbox 的全部吗？），并为您提供更多功能。
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.
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 的一个问题与其处理历史备份的方式有关。虽然您可以回滚单个文件（在过去 30 天内，如果您有 PackRat，则可以永远回滚），但您无法回滚整个目录。这意味着，如果您的存储库因任何原因被搞砸了，那么拥有历史备份的惊人服务基本上毫无用处，因为您必须单击数千个文件才能将它们恢复到早期版本。
如果你愿意的话，还有大多数其他答案提到的竞争条件问题。
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.
And then there are the problems with race conditions, if you will, mentioned by most of the other answers.
我只是将我的存储库作为私有存储库托管在 github.com 上。是的，您必须支付微型计划（每个计划 7 美元），但您知道您在外部有代码备份，因此您拥有安全性。
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.