Using Git and Dropbox together effectively?

up vote597down votefavorite 615

Is there a good tutorial where I can learn using Git and Dropbox together effectively? git version-control cloud dropbox share|improve this question edited Jul 5 at 18:37 Half Crazed 3,4051325 asked Dec 25 '09 at 8:41 n1kh1lp 3,47931325

3   There is another useful tutorial in this blog post. –  epotter Feb 17 '11 at 15:25  13   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. –  Mark Adamson Mar 31 '12 at 17:47 3   I'm not sure that your versioning redundancy is ironic, but it is probably quite useful –  silasdavis Apr 29 '12 at 17:26

13 Answers

activeoldestvotes

up vote914down voteaccepted

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. 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.git that 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. 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 Rails development experience, but it can be applied to anything, really. share|improve this answer edited Sep 4 at 8:04 shaun 33736 answered Dec 25 '09 at 17:10 Dan McNevin 13.3k22027

35   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)? –  dubekMay 13 '10 at 11:12 75   @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!". –  Ates Goral Sep 13 '10 at 20:04 31   @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. – rdrey Oct 21 '10 at 5:37 47   I have come back to this page more than five times to use this exact sequence of commands. I'll never memorize them, but thanks for providing them! –  mutewinter Dec 1 '10 at 23:17 17   @Jo: It's not ghetto enough. –  Ates Goral Feb 18 '11 at 5:28 show 20 more comments

up vote37down vote

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. share|improve this answer edited Mar 8 at 17:17 Peter Mortensen 6,68984475 answered May 1 '11 at 20:48 Bradjcox 562516

8   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). –  Egon Jan 24 '12 at 21:36  @Egon Provided you never run git gc, which can happen automatically... –  tc. Mar 9 at 0:48 1   @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. –  Egon Mar 10 at 19:11  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.) – imz -- Ivan Zakharyaschev Apr 1 at 12:11  +1 If you don't want to host your repositories in public, use Bitbucket, private repos are free for teams up to 5 users. –  Christian Specht Sep 25 at 19:47