How to use Git and Dropbox together? [closed]

Question

Is it possible to use Git and Dropbox together?

Unnecessary

See also Bradley Wright's tutorial. – Anglophile

If you are just a small team (up to 5 I think), then BitBucket provides free hosting for private repositories. Ironically I then have my local repo on DropBox, just in case I move between computers when I'm working on something. – Alcoran

I'm not sure that your versioning redundancy is ironic, but it is probably quite useful – Tisbe

His writing style was not very clear. Also I believe how he updates the working dir of the remote repo is left undefined. Either that, or I did not find that part of the article. – Icing

This question is unclear. What does it mean to use these tools together "effectively"? It's also too broad, and likely to generate opinionated answers. – Cubic

If you prefer Google drive check https://mcmap.net/q/22355/-can-i-push-pull-directly-from-my-google-drive-online – Lorca

The question is also somewhat ambiguous... Are you trying to avoid having a github/bitbucket account and instead having dropbox as origin? Or are you trying to keep the repos you have checked out at work and home in sync? I am actually looking for the latter. Does anyone know if its safe to keep the checked-out repositories under dropbox? – Moorehead

brianbuccola.com/how-to-use-git-and-dropbox-together – Consternate

And have you all heard of GitHub? They now have unlimited free private repositories. Or maybe I'm just from the future since this feature was included in 2018 :p – Showplace

This question is being discussed on meta: meta.#402424 – Mitrewort

Answer 1

I think that Git on Dropbox is great. I use it all the time. I have multiple computers (two at home and one at work) on which 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 in the background (very doing so quickly).

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 that ~/Dropbox/git/project.git directory (regardless of whether it belongs to your Dropbox account or is shared across multiple accounts) and do all the normal Git operations—they will be synchronized to all your other machines automatically.

I wrote a blog post “On Version Control” in which I cover the reasoning behind my environment setup. It’s based on my Ruby on Rails development experience, but it can be applied to anything, really.

Judejudea

@Dan McNevin: thank you for your interesting answer! Do you see any problems with having your repo in Dropbox and nowhere else? I don't want to pull and push always. All I want Dropbox for, is having a backup solution and being able to work from multiple computers. Help appreciated. Max – Tatro

This is coming from a Rails perspective, so it might be different depending on what you're developing in.. The problem with working directly in Dropbox is that there will be constant changes to the files there, logs, tmp files, sqlite database changes, etc.. that you might not want to always be synced up with your other machines that share the same Dropbox. I like to use Dropbox as more of a central repo.. I do all of my work in the "local" (ie not in the Dropbox folder) cloned repo, and then push the changes up to Dropbox at a good stopping point. – Judejudea

I wonder what'll happen if you push to the dropbox bare repo from two machines at the same time. If it'll cause a modification in one of git's internal files, dropbox will show you there's a conflict -- but what do you do then? Just pick one of the versions, and then push again from both machines (one by one)? – Greengrocer

@dubek: You'll probably end up corrupting the shared bare repo. This approach is only suitable for a small team (two in my case) where people can just shout over their cubicle walls: "Hey! Nobody push! I'm pushing now!". – Unconcerned

@Ates: At least git is decentralized, so if you manage to corrupt things you can restore it from someone's local copy. If you have a big team, chances are that there's enough cash for a hosted repo somewhere. – Rosina

@rdey: True. You can always create local tags and revert if something gets screwed up. That's the power of git! – Unconcerned

I used cvs (shudder) inside Dropbox and lost data for exactly the reasons listed by Ates Goral. Even if you verbally tell nobody to push, sometimes dropbox takes a few minutes to sync, during which you can silently corrupt your repo. Git is better due to local copies, but you should still be careful. Due to the way Dropbox's conflict resolution works you will get no warning. – Lodi

It might work in most cases, but take a look at my answer to #2200137 – Carduaceous

@Ates, I would suspect you'd get a dropbox-level conflict on the ref files and/or reflog. Nothing that won't be fixable with a quick rename and/or merge. The actual content files (the object store) won't conflict, as all filenames there (both packs and free objects) are based on content hashing. However you may get errors if you try to pull before the sync finishes, of course :) – Oleary

Git is clever that is uses hashes for its internal data files so it will be very rare that you will conflict it's internal state. It's like having multiple people access a git location that uses ssh, there are no conflicts. It was designed that way. So you will be fine with 2 people pushing to a repository at the same time on dropbox. We've done this. – Brogan

I'm pretty sure as well that this is unsafe. Git through SSH is safe of course, but Dropbox doesn't make any kind of guarantees about concurrency and locking, so you might lose data. Since you're only using it as a hub to push and pull from you should be fine (I think) -- when things break you just delete it and reinit. But then again, what's wrong with simply using an SSH server to host your hub repos? – Multicolor

One minor tweak, make it git push -u origin master; the -u sets it so that git push and git pull will work without the "origin master" bit next time. – Eidetic

This only works from command line. It fails to find the repository inside XCode – Kaiserdom

So why not just keep the code in Dropbox/google-drive/ubuntu-one(/whatever)? Why create an origin at all? Just keep the code local and committed - it will sync on all your computers as well. And if you have several team members, you don't want the risk two pushing at the same time and you'll probably have some money for a real git server. – Nuclide

@kilaka: I was wondering the same thing. It seems completely unnecessary to incorporate pushing into the workflow when you could just be coding and committing without a remote. And with Dropbox the added bonus is transparent versioning, like this: cl.ly/image/0b2X3P1p0G1M -- Of course, if you're working with multiple people, you'll need a remote. – Tantivy

@kilaka: Using a bare repo, only Git metadata gets synced. If you put your local repo directly into your DropBox folder then you get a lot more DropBox traffic every time you checkout a different branch as all your code files vanish / appear / change. It's not necessarily an issue but it does increase the risk that you turn off your machine before a (now potentially much longer) sync is complete, thereby causing you corruption issues. Also, a bare repo takes up less space, which is significant given DropBox is only free up to 2GB (at time of writing). – Gladdie

I think that the code-sharing scenario with no central repo (descibed in an answer below) would save one from possible corruptions because of concurrent updates to directory in dropbox. If one needs a central repo, it could be managed separately (and outsied of dropbox); dropbox would hold personal working repos (which is also convenient because you could update/pull from time to time from the someone else's source repo in your team which you based work on). (I'm actually contemplating using darcs in such a setting.) – Mycenae

i follow the steps and i got : error: src refspec master does not match any. error: failed to push some refs to '/home/andresrtm/Dropbox/git/project.git', any advice ? – Berlinda

I'm not sure this is really all that complicated. My team doesn't even need to be involved with my dropbox setup. The setup I've used for about two years is simple... 2 home computers and 2 work computers... all on dropbox, local git repo in dropbox. Work on one machine, dropbox syncs on others. As far as git goes; all three are for all intents and purposes the same dev machine. As far as sync time... local net syncs are super fast and by the time I drive home my work system has synced home and vice versa. Works quite well. – Mathildemathis

for a headless git access bitTorent Sync could be a solution. – Pollen

About small business with less than 5 people, bitbucket is always there for free. I'm considering use git + Dropbox so that things are sync-ed even when I forget to push in the day time though. – Rimmer

I highly, highly, HIGHLY recommend switching over to using git-remote-dropbox: github.com/anishathalye/git-remote-dropbox This allows you to use Dropbox as your remote repo, without having issues with Dropbox Sync. – Carabin

I use dropbox for personal backup only. So this technique works perfectly for me. It's safer than putting the working directory itself under dropbox – Kirbee

This might not always work. I have experienced time conflict between index file created by Git for a commit and Dropbox's attempt to sync that file at the time I push. – Periosteum

what should be mentioned: it was already said that this only works well for a small team (or a single dev that wants to sync the local repo across multiple machines) since simultanious access to the git file will likely corrupt it. However: if this ever happens to you remember that dropbox has a time-back machine (history) build in if you pay for it. In my case I can go back to any file version 1 year from now. Thus it's possible to roll back the corrupted local repo to a working state. – Implausibility

Re: putting your working git repo on Dropbox: this is dangerous - the dropbox client will pause for days syncing more than a million files for small changes. Dropbox is generally not very reliable at scale and having a working git repo on Dropbox is a good example of pushing it's limits. – Loewi

I have used Dropbox along with git. Dropbox will mess up the git repo. It will wrongly sync git internal files, but we may not be able to notice it. Git will work afterwards, after certain time only we will realize that many commit have been lost. – Stagnant

Git and Dropbox use different orders to sync files. Pretty sure this method is broken and will result in a bunch of conflicts. – Lettuce

Tip: If you're using Dropbox + Git, I recommend pausing Dropbox sync just before you're about to change branches. I've run into situations where sometimes Dropbox will lock a file unexpectedly and it will appear in a branch it does not belong. – Arresting

Answer 2

The right way to do this is use 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:

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.

Carabin

I'm happy to see that someone posted about git-remote-dropbox on this StackOverflow question. I wonder if there's any way to get this response closer to the top. The method recommended by the current accepted answer is pretty dangerous and can result in repository corruption. – Flutterboard

that's really cool. i will definitely check it out. but when i move from one dev box to another, and want to keep working on a sync'ed repo, this method will only work if i always commit my work when i leave machine A, and want to pick up where i left off on machine B. am i right? if so, this is not ideal, as it would lead to a flurry of "interim" commits, which one could argu will pollute the commit history of the repo. maybe i just can't have my cake and eat it too! – Cause

@bhuBouevidya No that's not true. You don't need to commit your work for the changes to by synced. As long as the files are saved the files will be synced. Basically if you have a bunch of modified files on one machine, the modifications will sync over to the other because Dropbox just cares about what has been saved to disk. – Carabin

@clu: Yes you must commit your work and push. All that git-remote-dropbox does is act as a git remote helper. Just like other remotes, your local commits will not be pushed to the remote until a push is done. The way to get locally modified files to into the local repository so that they can be pushed is by doing a commit. Dropbox will not know anything about your files not in the repository. – Rowe

Just curious if git-remote-dropbox is cross-platform... I see it uses python, and I know certain other python stuff for Dropbox is not cross-platform, for instance on OS X the command line stuff is not compatible. – Kironde

@Kironde Based on this closed issue I'd say yes. It can't be any more painful than getting a Python syntax highlighter up and running in Jekyll on Windows under Ruby. – Tizes

Answer 3

This answer is based on Mercurial experience, 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).

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.

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.

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

Lounging

I feel that the git repository is robust enough not to corrupt itself. My experience (over a year of usage, mostly single-user, cross-platform, cross-computer, multiple devs), is that git's repo is not easily corrupted. In git, only information is added to the repository, existing files are left alone 99.9% of the time (mutable files are mostly easy to inspect manually). I've sometimes seen cases where a branch pointer was overwritten, but this can be easily seen (i.e. "branch (XXX's conflicted copy)") and removed (no real fixing needed, actually). – Footy

@tc: You are right, during garbage collection, non-reachable information is removed in git. However, I guess that for most practical cases, this doesn't harm robustness: only unreachable information older than 2 weeks is affected (which is ample time for DropBox to synchronize). And at that moment of such a conflict, I suspect most information will be available both in packed and unpacked form. – Footy

I think that the code-sharing scenario with no central repo (descibed in an answer below) would save one from possible corruptions because of concurrent updates to directory in dropbox. If one needs a central repo, it could be managed separately (and outsied of dropbox); dropbox would hold personal working repos (which is also convenient because you could update/pull from time to time from the someone else's source repo in your team which you based work on). (I'm actually contemplating using darcs in such a setting.) – Mycenae

+1 If you don't want to host your repositories in public, use Bitbucket, private repos are free for teams up to 5 users. – Greenfield

One things I've noticed between a Windows machine and an OSX machine is file permissions can cause diff issues. You can turn off permissions in Git using: "git config core.fileMode false" – Basso

Answer 4

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

Angy

Answer 5

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.

Freestanding

Great so much! Also, to protect repo corruption from multiple writes you easily could make MULTIPLE repos and sync only their .git folders! All you need in a moment - is to pull from desired origin! Great P-to-P man! You understand decentralized git's philosophy! – Uncoil

Answer 6

It is now 2015, and as of three days ago, a new tool based on Dropbox API v2 has 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.

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

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

Masefield

Answer 7

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

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

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.

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

Scandent

Dropbox is just a good option for a central repo. If placed in a shared folder it even works for groups. – Kirsti

Yes, but you won't have the same merging features as in git, in fact if someone is editing the same file as yours, and he saves the file after you, your changes are lost, unless you go to the web interface and download the old version (your version). – Scandent

This is wrong. Dropbox doesn't drop conflicts. It mangles the filename of one edit, and uses the other for continuity. You can manually merge them yourself if you like. It's a good compromise, and doesn't lose data. dropbox.com/help/36 – Perspex

Yes but since this is about code, the less time I spend merging files the more code I can produce, and in a normal codebase it can be hundreds of conflicts at one time, depending of the project dimensions, and it would be a nightmare to merge then one by one, even with the help of a merge tool like WinMerge (or something alike). – Scandent

Answer 8

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

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.

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.

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://mcmap.net/q/22354/-how-to-use-git-and-dropbox-together-closed )

Usage:

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

P.S. Unchecking the preserve modification timestamp tells 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

Triplet

Would it be much different if using a macos encrypted .dmg file image, would the sync time be still roughy proportional to the changes? – Azarcon

@Azarcon Sorry, I don't haven't tried it with a .dmg file – Triplet

Answer 9

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.

Uncleanly

Answer 10

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_profile so my workflow looks like this:

~/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'

Fritzie

I would probably not use last thing as an alias, rather a shell script. Otherwise, I like this very much. Extra credit for awk usage. – Measureless

Answer 11

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.

Cherin

git do much more checking for corruptions than others by design. So at least you will know when that happens and can correct the problem. – Paresthesia

Answer 12

There's also an open source project (a collection of cross platform [Linux, Mac, Win] scripts) that does all the nitty-gritty details of the repository management with a handful (3-4) of commands.

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

Sample usage is:

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

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

After which normal git usage:

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

Check the project wiki and the manuals for full command reference and tutorials.

Laminate

Answer 13

I store my non-Github repo's on Dropbox. One caveat I ran into was syncing after a reinstall. Dropbox will download the smallest files first before moving to the larger ones. Not an issue if you start at night and come back after the weekend :-)

My thread - http://forums.dropbox.com/topic.php?id=29984&replies=6

Revet

Answer 14

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.

Panegyric

Answer 15

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.

Azarcon

As someone who's working on files that it would be nice to version control, but also be editable on an iPad (via Dropbox syncing), this answer covers that use case. – Dogy

Quick followup, current Dropbox behavior is different. Simply removing and telling Dropbox to not sync means the opposite, stays in cloud, removes from local. But there's a superuser answer with a solution. superuser.com/a/1527145/109561 In my case (on Mac) the following flags the file for ignoring, xattr -w com.dropbox.ignored 1 /path/to/somewhere. – Dogy

Answer 16

I like the top-voted answer by Dan McNevin. I ended up doing the sequence of git commands too many times and decided to make a script. So here it is:

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

The script only requires a project name. It will generate a git repository in ~/Dropbox/git/ under the specified name and will push the entire contents of the current directory to the newly created origin master branch. If more than one project name is given, the right-most project name argument will be used.

Optionally, the -r command argument specifies the remote branch that will push to the origin master. The location of the project origin master can also be specified with the -m argument. A default .gitignore file is also placed in the remote branch directory. The directory and .gitignore file defaults are specified in the script.

Compliant

Answer 17

For my 2 cents Dropbox only makes sence for personal use where you don't want to bother getting a central repo host. For any professional development you'll probably create more problems than you'll solve, as have been mentioned several times in the thread already, Dropbox isn't designed for this use case. That said, a perfectly safe method to dump repositories on Dropbox without any third-party plugins or tools is to use bundles. I have the following aliases in my .gitconfig to save typing:

[alias]
        bundle-push = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle create \"$path\" --all && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-fetch = "!cd \"${GIT_PREFIX:-.}\" && if path=\"$(git config remote.\"$1\".url)\" && [ \"${path:0:1}\" = / ]; then git bundle verify \"$path\" && git fetch \"$1\"; else echo \"Not a bundle remote\"; exit 1; fi #"
        bundle-new = "!cd \"${GIT_PREFIX:-.}\" && if [ -z \"${1:-}\" -o -z \"${2:-}\" ]; then echo \"Usage: git bundle-new <file> <remote name>\"; exit 1; elif [ -e \"$2\" ]; then echo \"File exist\"; exit 1; else git bundle create \"$2\" --all && git remote add -f \"$1\" \"$(realpath \"$2\")\"; fi #"

Example:

# Create bundle remote (in local repo)
$ git bundle-new dropbox ~/Dropbox/my-repo.bundle
# Fetch updates from dropbox
$ git bundle-fetch dropbox
# NOTE: writes over previous bundle. Thus, roughly equivalent to push --force --prune --all
$ git bundle-push

Bingen

Answer 18

I have faced a similar issue and have created a small script for the same. The idea is to use Dropbox with Git as simply as possible. Currently, I have quickly implemented Ruby code, and I will soon add more.

The script is accessible at https://github.com/nuttylabs/box-git.

Subaxillary

Answer 19

Without using third-party integration tools, I could enhance the condition a bit and use DropBox and other similar cloud disk services such as SpiderOak with Git.

The goal is to avoid the synchronization in the middle of these files modifications, as it can upload a partial state and will then download it back, completely corrupting your git state.

To avoid this issue, I did:

1. Bundle my git index in one file using git bundle create my_repo.git --all.
2. Set a delay for the file monitoring, eg 5 minutes, instead of instantaneous. This reduces the chances DropBox synchronizes a partial state in the middle of a change. It also helps greatly when modifying files on the cloud disk on-the-fly (such as with instantaneous saving note-taking apps).

It's not perfect as there is no guarantee it won't mess up the git state again, but it helps and for the moment I did not get any issue.

Triform

Answer 20

On MacOS you may also just stop Dropbox, make your changes and then relaunch Dropbox. I am using the following combination and am quite happy with it:

In both (your local git managed project directory and your remote git repository located on Dropbox) run the following command to disable auto-packing (which is the main problem with dropbox syncing)

git config --global gc.auto 0

Then from time to time, compress the repositories with dropbox disabled. For example I do the following in my bash-build-script whenever I make new releases of my apps.

osascript -e "tell application \"Dropbox\" to quit"

# Compress local
git gc --prune=now; git repack -a -d

# Compress remote
REPOS_DIR_REMOTE=`git remote get-url --push origin`
cd "${REPOS_DIR_REMOTE}"
git gc --prune=now; git repack -a -d

osascript -e "tell application \"Dropbox\" to launch"
osascript -e "display notification with title \"Compress Done\""

Bose