我意识到有类似的问题，但我的问题略有不同：我想知道通过多台计算机上的同步 Dropbox 文件夹共享裸存储库是否适用于通过 Git共享代码？
换句话说：通过 Dropbox 共享 Git 存储库与从一个集中位置共享它相同，例如通过 SSH 或 HTTP？
repo 是否会在每个人的本地驱动器上更新？这与通过共享网络驱动器共享 Git 存储库相同吗？
注意：这不是一个经验问题：它似乎工作正常。我在问 Git 存储库的结构方式是否与这种共享方式兼容。
编辑为了澄清/重复，我正在谈论将 Dropbox 上的 Git 存储库作为裸存储库。我不是在谈论在 Dropbox 中保留受源代码控制的实际文件。
我看不出它会丢失数据的原因——Git 的存储库结构是健壮的，并且在存储库存储本身中，具有相同名称的文件将始终具有相同的内容（这不适用于分支名称）。
不过，这不会是有效的。Git 的传输协议意味着它通常只会传输一次更改。使用 Dropbox，如果两个人打包略有不同的存储库，则生成的包可能包含重要的公共数据，但并不完全相同，因此 DropBox 会同步两个包，这是低效的。
您可能还会发现，尽管数据都在那里，但由于两个副本同时更新了相同的分支，您最终会得到未跟踪的更改。这可以通过确保您从每个副本推送到不同的分支来解决，但这会很痛苦。
我很确定这是不安全的。Git 存储库中有一堆移动部件，Dropbox 可以轻松破坏其中一个。例如，您可能会在目录中得到不正确的分支提示（master 等） ，或者如果文件的内容错误refs，您的对象存储可能会停止工作。objects/info/packsGit repos 相当简单和健壮，但它们不仅仅是愚蠢的牢不可破的存储。
通过 SSH、git 或 HTTP 访问远程存储库，甚至在网络文件系统上本地访问，都是安全的，因为仅通过git进程访问存储库，这确保所有内容都以正确的顺序移动到位。但 Dropbox 不对订购做出任何形式的保证，因此您可能会丢失数据。
只需使用 Git 服务器（或任何 SSH 服务器）即可——如果您没有，请考虑GitHub、Bitbucket或GitLab。它会为您省去很多麻烦，而且使用起来并不比通过 Dropbox 共享的本地存储库更难使用（您只有 SSH URL，而不是本地路径）。
如果两个用户断开连接，做一些工作，推送到他们本地的裸存储库副本，然后上线，会发生什么？在这种情况下，当 Dropbox 尝试同步时，您会遇到问题——打包文件和分支提示会有所不同，而 Dropbox 无法解决这个问题。这是我能看到的唯一问题。我认为即使两个用户都已连接，如果他们碰巧同时推送到本地裸存储库，也会发生同样的事情。
我在将 Dropbox 与 Git 和 Mercurial 一起使用时遇到了问题。存储库文件经常损坏，可能是由于 Dropbox 的同步不完美，尤其是在从多个位置进行更改时。此外，Dropbox 在后台运行，因此很容易在同步操作过程中意外尝试使用存储库（或重新启动计算机）。
我喜欢 Dropbox，但它不能很好地替代共享驱动器或“真正的”远程 Git 存储库。
我以前用 MobileMe 做这个，但电脑一直不同步。每台计算机都会有一个与云中的不同的存储库，并且由于 MobileMe 中没有“合并”的概念（我假设 DropBox 也是，对吧？）我最终只需要选择一个版本保留和丢失一些编辑，或复制编辑并重新应用它们。自从我切换到中央 Git 存储库后，生活变得轻松多了。
如果到目前为止它对你有用，很好。不过，我想如果两个开发人员同时推送到他们本地的裸仓库，你会很痛苦。DropBox 如何知道哪个是正确的？
如果我告诉你在某些情况下 Dropbox 搞砸了我的 Git，我会用矛盾的方式回答你的问题吗？至少根据我的经验，这种情况已经发生了 5 次以上，而且有很多人有同样的经历。
但现在我不相信 Dropbox 对 Git 来说真的那么重要，真的。实际上，您可以设置远程分支（Github、Gitorious、Bitbucket），这些分支可以取代 Dropbox 共享和修订历史功能（不就是 Dropbox 吗？）并为您提供更多功能。
DropBox 的一个问题与他们如何处理历史备份有关。虽然您可以回滚单个文件（在过去 30 天内，或者如果您有 PackRat，则永远回滚），但您不能回滚整个目录。这意味着，如果您的存储库因任何原因被搞砸了，拥有历史备份的惊人服务基本上是无用的，因为您必须单击数千个文件才能将它们恢复到早期版本。
如果您愿意，大多数其他答案都提到了竞争条件的问题。
我只是将我的存储库作为私有存储库托管在 github.com 上。是的，您必须为微型计划付费（7 美元/计划），但您知道您有外部代码备份，因此您可以放心。