我不认为使用Git和Dropbox是正确的选择……想想两者的特点:

Git:

允许您拥有一个中央存储库 允许您使用自己的更改拥有自己的存储库 允许您从中央存储库发送和接收更改 允许多人更改相同的文件，他们合并他们或要求你合并他们，如果它不能这样做 web和桌面客户端是否允许访问中央存储库

Dropbox:

将所有内容保存在中央存储库中 允许您在服务器中拥有自己的文件版本 强制您从中央存储库发送和接收更改 如果多人更改相同的文件，第一个提交的文件将被稍后提交的文件所取代，并且不会发生合并，这很麻烦(这肯定是它最大的缺点) 具有web和桌面客户端以允许访问中央存储库。

如果你担心泄露你的文件，为什么不加密呢?然后你就可以得到Dropbox to Git的最大优势，那就是拥有公共和私人文件……

在不使用第三方集成工具的情况下，我可以稍微改善一下条件，并使用DropBox和其他类似的云磁盘服务，如带Git的SpiderOak。

我们的目标是避免在这些文件修改的中间同步，因为它可以上传一个部分状态，然后下载回来，完全破坏你的git状态。

为了避免这个问题，我做了:

使用git Bundle create my_repo将我的git索引捆绑在一个文件中。git——所有。 为文件监控设置一个延迟，例如5分钟，而不是瞬间。这降低了DropBox在更改过程中同步部分状态的机会。它在动态修改云磁盘上的文件时也有很大帮助(比如即时保存笔记应用程序)。

它并不完美，因为不能保证它不会再次弄乱git状态，但它有帮助，目前我没有遇到任何问题。

还有一个开源项目(一个跨平台[Linux, Mac, Win]脚本的集合)，它用少量(3-4)命令完成存储库管理的所有细节。

https://github.com/karalabe/gitbox/wiki

示例用法如下:

$ gitbox create myapp
Creating empty repository...
Initializing new repository...
Repository successfully created.

$ gitbox clone myapp
Cloning repository...
Repository successfully cloned.

之后正常的git使用:

$ echo “Some change” > somefile.txt
$ git add somefile.txt
$ git commit –m “Created some file”
$ git push

查看项目wiki和手册以获得完整的命令参考和教程。

我喜欢丹·麦克内文投票最多的回答。我最后做了太多次git命令序列，决定做一个脚本。就是这样:

#!/bin/bash

# Usage
usage() {
    echo "Usage: ${0} -m [ master-branch-directory ] -r [ remote-branch-directory ] [ project-name ]"
    exit 1
}

# Defaults
defaults() {
    masterdir="${HOME}/Dropbox/git"
    remotedir="${PWD}"
    gitignorefile="# OS generated files #\n\n.DS_Store\n.DS_Store?\n.Spotlight-V100\n.Trashes\nehthumbs.db\nThumbs.db"
}

# Check if no arguments
if [ ${#} -eq 0 ] ; then
    echo "Error: No arguments specified"
    usage
fi

#Set defaults
defaults

# Parse arguments
while [ ${#} -ge 1 ]; do
    case "${1}" in
        '-h' | '--help' ) usage ;;
        '-m' )
            shift
            masterdir="${1}"
            ;;
        '-r' )
            shift
            remotedir="${1}"
            ;;
        * )
            projectname="${1##*/}"
            projectname="${projectname%.git}.git"
            ;;
    esac
    shift
done

# check if specified directories and project name exists
if [ -z "${projectname}" ]; then
    echo "Error: Project name not specified"
    usage
fi

if [ ! -d "${remotedir}" ]; then
    echo "Error: Remote directory ${remotedir} does not exist"
    usage
fi

if [ ! -d "${masterdir}" ]; then
    echo "Error: Master directory ${masterdir} does not exist"
    usage
fi

#absolute paths
remotedir="`( cd \"${remotedir}\" && pwd )`"
masterdir="`( cd \"${masterdir}\" && pwd )`"

#Make master git repository
cd "${masterdir}"
git init --bare "${projectname}"

#make local repository and push to master
cd "${remotedir}"
echo -e "${gitignorefile}" > .gitignore # default .gitignore file
git init
git add .
git commit -m "first commit"
git remote add origin "${masterdir}/${projectname}"
git push -u origin master

#done
echo "----- Locations -----"
echo "Remote branch location: ${remotedir}"
echo "Master branch location: ${masterdir}"
echo "Project Name: ${projectname}"

该脚本只需要一个项目名称。它将在~/Dropbox/git/中生成一个指定名称下的git存储库，并将当前目录的全部内容推送到新创建的origin主分支。如果给出了多个项目名称，则将使用最右边的项目名称参数。

可选地，-r命令参数指定将推送到源主机的远程分支。项目起源主节点的位置也可以用-m参数指定。一个默认的.gitignore文件也放置在远程分支目录中。目录和.gitignore文件默认值在脚本中指定。

我使用Mercurial(或Git) + TrueCrypt + Dropbox进行加密远程备份。

最酷的是，如果你修改了一小部分代码，Dropbox不会同步整个TrueCrypt容器。同步时间大致与更改量成比例。即使它是加密的，TrueCrypt + Dropbox的组合也很好地利用了块密码+块级同步。

其次，单片加密容器不仅增加了安全性，还减少了存储库损坏的可能性。

警告:但是你必须非常小心，不要在Dropbox运行时挂载容器。如果两个不同的客户端将不同的版本签入到容器中，解决冲突也会很麻烦。因此，它只适用于个人备份，而不适用于团队。

设置:

创建一个Truecrypt容器(多个gb就可以了) 在Truecrypt首选项下，取消选中保留修改时间戳*。 创建一个由Dan上面提到的回购(https://stackoverflow.com/a/1961515/781695)

用法:

Dropbox辞职 挂载容器，推送更改，卸载 dropbox运行

附注:取消选中保留修改时间戳告诉dropbox文件已被修改，它应该同步。注意，即使不更改容器中的任何文件，装入容器也会修改时间戳。如果不希望发生这种情况，只需将卷挂载为只读

正确的方法是使用git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

在Dropbox中创建自己的裸回购会导致很多问题。Anish(库的创造者)解释得很好:

The root cause of these problems is that the Dropbox desktop client is designed for syncing files, not Git repositories. Without special handling for Git repositories, it doesn’t maintain the same guarantees as Git. Operations on the remote repository are no longer atomic, and concurrent operations or unlucky timing with synchronization can result in a corrupted repository. Traditional Git remotes run code on the server side to make this work properly, but we can’t do that. Solution: It is possible to solve this properly. It is possible to use Git with Dropbox and have the same safety and consistency guarantees as a traditional Git remote, even when there are multiple users and concurrent operations! For a user, it’s as simple as using git-remote-dropbox, a Git remote helper that acts as a transparent bidirectional bridge between Git and Dropbox and maintains all the guarantees of a traditional Git remote. It’s even safe to use with shared folders, so it can be used for collaboration (yay unlimited private repos with unlimited collaborators!). With the remote helper, it’s possible to use Dropbox as a Git remote and continue using all the regular Git commands like git clone, git pull, and git push, and everything will just work as expected.