有效地结合使用 Git 和 Dropbox？

Using Git and Dropbox together effectively?

提问by n1kh1lp

How do I use Gitand Dropboxtogether effectively?

如何有效地结合使用Git和Dropbox？

回答by Dan McNevin

I think that Git on Dropbox is great. I use it all of the time. I have multiple computers (two at home and one at work) that I use Dropbox as a central bare repository. Since I don't want to host it on a public service, and I don't have access to a server that I can always ssh to, Dropbox takes care of this by syncing (very quickly) in the background.

我认为 Dropbox 上的 Git 很棒。我一直在使用它。我有多台计算机（两台在家里，一台在工作），我将 Dropbox 用作中央裸存储库。由于我不想将它托管在公共服务上，而且我无法访问我总是可以通过 ssh 连接到的服务器，Dropbox 通过在后台同步（非常快）来处理这个问题。

Setup is something like this:

设置是这样的：

~/project $ git init
~/project $ git add .
~/project $ git commit -m "first commit"
~/project $ cd ~/Dropbox/git

~/Dropbox/git $ git init --bare project.git
~/Dropbox/git $ cd ~/project

~/project $ git remote add origin ~/Dropbox/git/project.git
~/project $ git push -u origin master

From there, you can just clone ~/Dropbox/git/project.gitthat you have associated with your Dropbox account (or have shared this directory with people), you can do all the normal Git operations and they will be synchronised to all your other machines automatically.

从那里，您可以克隆~/Dropbox/git/project.git与您的 Dropbox 帐户相关联的（或已与人共享此目录），您可以执行所有正常的 Git 操作，它们将自动同步到您的所有其他机器。

I wrote a blog post, On Version Control, (old link^dead) on my reasoning and how I set up my environment, it's based on my Ruby on Railsdevelopment experience, but it can be applied to anything, really.

我写了一篇关于版本控制的博客文章，（旧链接已^失效）关于我的推理以及我如何设置我的环境，它基于我的Ruby on Rails开发经验，但它可以应用于任何事情，真的。

回答by clu

The right way to do this is use git-remote-dropbox: https://github.com/anishathalye/git-remote-dropbox

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

Creating your own bare repo in Dropbox causes a lot of problems. Anish (the creator of the library) explains it best:

在 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.

这些问题的根本原因是 Dropbox 桌面客户端是为同步文件而设计的，而不是 Git 存储库。如果没有对 Git 存储库进行特殊处理，它就不会保持与 Git 相同的保证。远程存储库上的操作不再是原子性的，并发操作或不吉利的同步时间都可能导致存储库损坏。

传统的 Git 远程在服务器端运行代码以使其正常工作，但我们不能这样做。

解决方法：可以正确解决这个问题。可以将 Git 与 Dropbox 一起使用，并具有与传统 Git 远程相同的安全性和一致性保证，即使有多个用户和并发操作！

对于用户来说，就像使用 git-remote-dropbox 一样简单，这是一个 Git 远程助手，充当 Git 和 Dropbox 之间的透明双向桥梁，并维护传统 Git 远程的所有保证。与共享文件夹一起使用甚至是安全的，因此它可以用于协作（是的，无限的私人存储库与无限的协作者！）。

使用远程助手，可以将 Dropbox 用作 Git 远程并继续使用所有常规 Git 命令，如 git clone、git pull 和 git push，一切都会按预期工作。

回答by Bradjcox

This answer is based on Mercurialexperience, not Git, but this experience says using Dropbox this way is asking for corrupt repositories if there's even a chance that you'll be updating the same Dropbox-based repository from different machines at various times (Mac, Unix, Windows in my case).

这个答案是基于Mercurial 的经验，而不是 Git，但是这个经验表明，如果您有可能在不同时间（Mac、 Unix，在我的情况下是 Windows）。

I don't have a complete list of the things that can go wrong, but here's a specific example that bit me. Each machine has its own notion of line-ending characters and how upper/lower case characters are handled in file names. Dropbox and Git/Mercurial handle this slightly differently (I don't recall the exact differences). If Dropbox updates the repository behind Git/Mercurial's back, presto, broken repository. This happens immediately and invisibly, so you don't even know your repository is broken until you try to recover something from it.

我没有可能出错的完整列表，但这里有一个让我感到恼火的具体例子。每台机器都有自己的行尾字符概念，以及如何在文件名中处理大写/小写字符。Dropbox 和 Git/Mercurial 处理这个略有不同（我不记得确切的区别）。如果 Dropbox 更新 Git/Mercurial 背后的存储库，则很快，损坏的存储库。这会立即且不可见地发生，因此您甚至不知道您的存储库已损坏，直到您尝试从中恢复某些内容。

After digging out from one mess doing things this way, I've been using the following recipe with great success and no sign of problems. Simply move your repository out of Dropbox. Use Dropbox for everything else; documentation, JAR files, anything you please. And use GitHub(Git) or Bitbucket(Mercurial) to manage the repository itself. Both are free so this adds nothing to the costs, and each tool now plays to its strengths.

在以这种方式从一团糟中挖掘出来之后，我一直在使用以下配方并取得了巨大的成功并且没有任何问题的迹象。只需将您的存储库移出 Dropbox。将 Dropbox 用于其他一切；文档，JAR 文件，任何你喜欢的东西。并使用GitHub(Git) 或Bitbucket(Mercurial) 来管理存储库本身。两者都是免费的，所以这不会增加成本，而且现在每个工具都发挥了自己的优势。

Running Git/Mercurial on top of Dropbox adds nothing except risk. Don't do it.

在 Dropbox 上运行 Git/Mercurial 只会增加风险。不要这样做。

回答by Eli

I didn't want to put all my projects under one Git repository, nor did I want to go in and run this code for every single project, so I made a Bashscript that will automate the process. You can use it on one or multiple directories - so it can do the code in this post for you or it can do it on multiple projects at once.

我不想将我的所有项目都放在一个 Git 存储库中，也不想进入并为每个项目运行此代码，因此我制作了一个Bash脚本来自动化该过程。您可以在一个或多个目录上使用它 - 因此它可以为您执行本文中的代码，也可以一次在多个项目上执行此操作。

#!/bin/sh
# Script by Eli Delventhal
# Creates Git projects for file folders by making the origin Dropbox. You will need to install Dropbox for this to work.

# Not enough parameters, show help.
if [ $# -lt 1 ] ; then

cat<<HELP
projects_to_git.sh -- Takes a project folder and creates a Git repository for it on Dropbox

USAGE:
    ./projects_to_git.sh file1 file2 ..

EXAMPLES:
    ./projects_to_git.sh path/to/MyProjectDir
        Creates a git project called MyProjectDir on Dropbox

    ./projects_to_git.sh path/to/workspace/*
        Creates a git project on Dropbox for every folder contained within the workspace directory, where the project name matches the folder name

HELP
    exit 0
fi

# We have enough parameters, so let's actually do this thing.

START_DIR=$(pwd)

# Make sure we have a connection to Dropbox
cd ~
if [ -s 'Dropbox' ] ; then
    echo "Found Dropbox directory."
    cd Dropbox
    if [ -s 'git' ] ; then
        echo "    Dropbox Git directory found."
    else
        echo "    Dropbox Git directory created."
        mkdir git
    fi
else
    echo "You do not have a Dropbox folder at ~/Dropbox! Install Dropbox. Aborting..."
    exit 0
fi

# Process all directories matching the passed parameters.
echo "Starting processing for all files..."
for PROJ in $*
do
    if [ -d $PROJ ] ; then
        PROJNAME=$(basename $PROJ)
        echo "  Processing $PROJNAME..."

        # Enable Git with this project.
        cd $PROJ
        if [ -s '.git' ] ; then
            echo "    $PROJNAME is already a Git repository, ignoring..."
        else
            echo "    Initializing Git for $PROJNAME..."
            git init -q
            git add .
            git commit -m "Initial creation of project." -q

            # Make the origin Dropbox.

            cd ~/Dropbox/git
            if [ -s $PROJNAME ] ; then
                echo "    Warning! $PROJNAME already exists in Git! Ignoring..."
            else
                echo "    Putting $PROJNAME project on Dropbox..."
                mkdir $PROJNAME
                cd $PROJNAME
                git init -q --bare
            fi

            # Link the project to the origin
            echo "    Copying local $PROJNAME to Dropbox..."
            cd $PROJ
            git remote add origin "~/Dropbox/git/$PROJNAME"
            git push -q origin master
            git branch --set-upstream master origin/master
        fi
    fi
done

echo "Done processing all files."
cd $START_DIR

回答by teh_senaus

With regards to small teams using Dropbox:

关于使用 Dropbox 的小团队：

If each developer has their own writable bare repository on Dropbox, which is pull onlyto other developers, then this facilitates code sharing with no risk of corruption!

如果每个开发人员在 Dropbox 上都有自己的可写裸存储库，并且只拉给其他开发人员，那么这有助于代码共享，而没有损坏的风险！

Then if you want a centralized 'mainline', you can have one developer manage all the pushes to it from their own repo.

然后，如果你想要一个集中的“主线”，你可以让一个开发人员从他们自己的仓库管理所有推送。

回答by merlin2011

It is now 2015, and as of three days ago, a new toolbased on Dropbox API v2has been created to safely use git on Dropbox. It works against the API rather than using the desktop client, and correctly handles multiple simultaneous pushes to a repository hosted in a shared folder.

现在是 2015 年，三天前，已经创建了一个基于Dropbox API v2的新工具来安全地在 Dropbox 上使用 git。它针对 API 而不是使用桌面客户​​端，并正确处理多个同时推送到共享文件夹中托管的存储库。

Once configured, it allows one to set up a git remote exactly like any other git remote.

配置完成后，它允许您像设置任何其他 git remote 一样设置 git remote。

git clone "dropbox::/path/to/repo"
git remote add origin "dropbox::/path/to/repo"

回答by Coyote21

I don't think that using Git and Dropbox is the way to go... Just think about the features of both:

我不认为使用 Git 和 Dropbox 是要走的路......想想两者的特点：

Git:

吉特：

• Allows you to have a central repository
• Allows you to have your own repository with your own changes
• Allows you to send and receive changes from the central repository
• Allows multiple persons to change the same files and them merges them or asks you to merge them if it can't do it
• Has web and desktop clients to allow access to the central repository

• 允许您拥有一个中央存储库
• 允许您拥有自己的存储库和您自己的更改
• 允许您从中央存储库发送和接收更改
• 允许多人更改相同的文件，他们合并它们，或者如果不能合并则要求您合并它们
• 具有 Web 和桌面客户端以允许访问中央存储库

Dropbox:

保管箱：

• Keeps everything in a central repository
• Allows you to have your own versions of the files in the server
• Forces you to send and receive changes from the central repository
• If multiple persons change the same files, the first file committed is replaced with later commits, and no merge occurs which is troublesome (and definitely its biggest disadvantage)
• Has web and desktop clients to allow access to the central repository.

• 将所有内容保存在中央存储库中
• 允许您在服务器中拥有自己的文件版本
• 强制您从中央存储库发送和接收更改
• 如果多人修改同一个文件，第一个提交的文件会被后面的提交替换，而且不会发生合并，这很麻烦（绝对是它最大的缺点）
• 具有 Web 和桌面客户端以允许访问中央存储库。

And if you're worried with sharing some of your files, why not cipher them? And then you could get the biggest advantage of Dropbox to Git, that is, to have public and private files...

如果您担心共享某些文件，为什么不加密它们呢？然后你就可以得到 Dropbox 对 Git 的最大优势，即拥有公共和私人文件......

回答by user

I use Mercurial (or Git) + TrueCrypt + Dropbox for encryptedremote backups.

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

The coolest thing is that Dropbox does NOT sync the entire TrueCrypt container if you modify a small portion of your code. The sync time is roughly proportional to the amount of changes. Even though it's encrypted, the combination of TrueCrypt + Dropbox makes excellent usage of block cipher + block level sync.

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

Secondly, a monolithic encrypted container not just adds security, it also reduces chances of repository corruption.

其次，整体加密容器不仅增加了安全性，还减少了存储库损坏的机会。

Caution:However you have to be very careful about not having the container mounted while Dropbox is running. It can also be a pain to resolve conflicts if 2 different clients check-in different versions to the container. So, it's practical only for a single person using it for backups, not for a team.

注意：但是您必须非常小心，不要在 Dropbox 运行时安装容器。如果 2 个不同的客户端将不同的版本签入到容器中，那么解决冲突也会很痛苦。因此，它仅适用于将其用于备份的单个人，而不适用于团队。

Setup:

设置：

• Create a Truecrypt container (multiple Gigabyte is fine)
• Under Truecrypt preferences, uncheck preserve modification timestamp*.
• Create a repo as mentioned above by Dan ( https://stackoverflow.com/a/1961515/781695)

• 创建一个 Truecrypt 容器（多个 Gigabyte 就可以了）
• 在 Truecrypt 首选项下，取消选中preserve modification timestamp*。
• 创建如上所述由 Dan ( https://stackoverflow.com/a/1961515/781695)

Usage:

用法：

• Quit Dropbox
• Mount the container, push your changes, unmount
• Run dropbox

• 退出 Dropbox
• 挂载容器，推送您的更改，卸载
• 运行保管箱

P.S. Unchecking the preserve modification timestamptells dropbox that the file has been modified and it should be sync'd. Note that mounting the container modifies the timestamp even if you don't change any file in it. If you don't want that to happen, simply mount the volume as read-only

PS取消选中preserve modification timestamp告诉保管箱文件已被修改，应该同步。请注意，即使您没有更改其中的任何文件，挂载容器也会修改时间戳。如果您不希望发生这种情况，只需将卷安装为read-only

回答by Michiel de Mare

I love the answer by Dan McNevin! I'm using Git and Dropbox together too now, and I'm using several aliases in my .bash_profileso my workflow looks like this:

我喜欢 Dan McNevin 的回答！我现在也同时使用 Git 和 Dropbox，并且在我的.bash_profile 中使用了几个别名，因此我的工作流程如下所示：

~/project $ git init
~/project $ git add .
~/project $ gcam "first commit"
~/project $ git-dropbox

These are my aliases:

这些是我的别名：

alias gcam='git commit -a -m'
alias gpom='git push origin master'
alias gra='git remote add origin'
alias git-dropbox='TMPGP=~/Dropbox/git/$(pwd | awk -F/ '\''{print $NF}'\'').git;mkdir -p $TMPGP && (cd $TMPGP; git init --bare) && gra $TMPGP && gpom'

回答by Brad Cox

I've been using Mercurial in the recommended manner and urge that you be cautious, especially if any of the machines differ. The Dropbox fora are full of complaints of mysterious filename case problems turning up spontaneously. Hg (and I presume Git) won't notice or complain during routine checkins and you'll only hear about the corruption when it complains of a corrupt repo when you try to use it for real. Bad news. Wish I could be more specific about the problem and its workarounds; I'm still trying to dig out from this mess myself.

我一直在以推荐的方式使用 Mercurial，并敦促您谨慎行事，尤其是在任何机器不同的情况下。Dropbox 论坛充满了对自发出现的神秘文件名问题的抱怨。Hg（我认为 Git）在例行签入期间不会注意到或抱怨，并且只有当您尝试真正使用它时它抱怨损坏的存储库时，您才会听到损坏。坏消息。希望我能更具体地了解这个问题及其解决方法；我仍然试图自己从这个烂摊子中挖掘出来。