Using Git and Dropbox together effectively?

Question

How do I use Git and Dropbox together effectively?

Answer 1

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 Bash script 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.

#!/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

Answer 2

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.

Answer 3

With regards to small teams using Dropbox:

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

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

Answer 4

Another approach:

All the answers so far, including @Dan answer which is the most popular, address the idea of using Dropbox to centralize a shared repository instead of using a service focused on git like github, bitbucket, etc.

But, as the original question does not specify what using "Git and Dropbox together effectively" really means, let's work on another approach: "Using Dropbox to sync only the worktree."

The how-to has these steps:

1. inside the project directory, one creates an empty .git directory (e.g. mkdir -p myproject/.git)

2. un-sync the .git directory in Dropbox. If using the Dropbox App: go to Preferences, Sync, and "choose folders to sync", where the .git directory needs to get unmarked. This will remove the .git directory.

3. run git init in the project directory

It also works if the .git already exists, then only do the step 2. Dropbox will keep a copy of the git files in the website though.

Step 2 will cause Dropbox not to sync the git system structure, which is the desired outcome for this approach.

Why one would use this approach?

• The not-yet-pushed changes will have a Dropbox backup, and they would be synced across devices.

• In case Dropbox screws something up when syncing between devices, git status and git diff will be handy to sort things out.

• It saves space in the Dropbox account (the whole history will not be stored there)

• It avoids the concerns raised by @dubek and @Ates in the comments on @Dan's answer, and the concerns by @clu in another answer.

The existence of a remote somewhere else (github, etc.) will work fine with this approach.

Working on different branches brings some issues, that need to be taken care of:

• One potential problem is having Dropbox (unnecessarily?) syncing potentially many files when one checks out different branches.

• If two or more Dropbox synced devices have different branches checked out, non committed changes to both devices can be lost,

One way around these issues is to use git worktree to keep branch checkouts in separate directories.

Answer 5

Now in 2014, I have been using Git and Dropbox for about one year and a half without problem. Some points though:

• All my machines using Dropbox are on Windows, different versions (7 to 8) + 1 mac.
• I do not share the repository with someone else, so I am the only one to modify it.
• git push pushes to a remote repository, so that if it ever gets corrupted, I can easily recover it.
• I had to create aliases in C:\Users with mklink /D link target because some libraries were pointed to absolute locations.

Answer 6

We use this method (creating a bare repository in Dropbox) on a share folder.

A small group of developers can pull from that bare synced repository and create a local clone. Once the unit of work is done, we push back to origin.

One thing I'm missing is a good way to have an e-mail sent with the change-set information once a push to origin occurs. We are using Google Wave to manually keep track of changes.