I have some friends telling me that Dropbox can be used as a version control tool. I have always used SVN or Git. I was looking around Dropbox and couldn't find anything that tells me about is characteristics as Merging, Fork and other characteristics for a complete VCS.

Can someone point me what I'm missing.

  • 18
    "is a bad idea" is the logical end of the title's sentence fragment.
    – Michael B
    Oct 21, 2012 at 19:40
  • like your comment
    – Goows
    Oct 21, 2012 at 22:20
  • Just as a comment, we used this at a place I worked at once, file corruption, duplicates of files galore. Avoid like the plague. Dec 17, 2012 at 15:43

5 Answers 5


Dropbox is not a suitable replacement for something like Subversion or Git for controlling changes to source code. There is some functionality to revert to old versions of files, but (to the best of my knowledge and consulting with the documentation) there is no support for performing merging, or branching. There are some APIs that expose diffs, but you would need to find a way to integrate these APIs into your tool.

However, for personal projects with few (if any) other developers, it's not unreasonable to use Dropbox to store your repositories and make them more readily available. The backup and global access to your files could help make it easier for you to do your development work. This model breaks down with larger teams working on the project.

  • 1
    If you only have a small number of people committing at once then having your svn/git repo 'locally' on dropbox works well. With bigger teams there are issues with many multiple updates happening at the same time Oct 21, 2012 at 16:40
  • @Thomas: well I think I share your opinion. I just wanted some different opinions and arguments.
    – Goows
    Oct 21, 2012 at 16:51
  • @MartinBeckett That's a good point - I'll edit that paragraph to be more clear. I was thinking of the use case where I was either the only developer or the upstream repository was someplace like Github or Bitbucket and what was in Dropbox was my local repository.
    – Thomas Owens
    Oct 21, 2012 at 17:27
  • 3
    "This model breaks down with larger teams working on the project." If by that you mean "larger than one." Any more than that and you're going to have a really hard time with multiple updates. And worse, nothing will tell you it's going bad.
    – pdr
    Oct 21, 2012 at 17:39
  • @pdf I would argue "larger than zero". git is useful for even a single developer and provides crucial features, for example, log of development history, ability to maintain or discard experimental branches, to revert specific changes, ability to see exactly what has changed since last 'stable state' or last commit, ability to commit only certain changes while stashing others for later (or for other branches). I would never think of starting a new project without a real VCS like git
    – user84207
    Jul 6, 2017 at 8:19

You're not missing anything about Dropbox. It's great for sharing files, and occasionally useful to recover a file that someone has deleted or updated by accident. But it shouldn't ever be relied on as a source control application. Never.

At best, when you're working alone and you want your files available everywhere, it's still not as good as a Git/Mercurial repository, because you can't batch changes and publish them with a single comment (so you can figure out later what you were doing).

What you're missing is BitBucket, where you can have free private Git/Mercurial repositories with up to 5 collaborators. Once you're above that number of developers, you need to think about whether to pay for an IT department or pay for BitBucket's extended service, but by that point you're WAY beyond being able to get away with DropBox.

Setting up your repository is about as complicated as sharing a DropBox folder.

  • "But it shouldn't ever be relied on as a source control application. Never." , I like this... I was answering that SVN was a serious solution and that for me Dropbox was more storage in the cloud.
    – Goows
    Oct 21, 2012 at 22:19

As Thomas pointed out, you would lose some features that are relied on heavily in team environments. If your goal is to have a file share that is super-simple, it would work. If your goal is to avoid a real version control system at all costs, it would work.

You could use them together. Have the functionality of version control that utilizes the file sharing (price and privacy, sharing may cost more?) across multiple devices of DropBox. I've never done it, but here is a link: http://rogerstringer.com/2012/04/16/using-dropbox-as-a-git-repository.


It can be technically used as version control, similar to making a tar.gz/zip file after every change can be used as version control. Which is probably not the best method to go about doing things, even if you include a changelog with every change and zipfile.

It won't include support for things like comparing and diff'ing two different versions, merging different versions, having multiple concurrent branches that you can work on with a simple "git branch" to choose between them, and a list of other features that I am not immediately thinking of. I've done the "zipfile at the end of every feature change" method before and it's clearly better than nothing, but personally I recommend using a proper tool for the job.


I'll go against the trend and argue that it can prove useful in certain cases.

While I fully agree that Dropbox is in no way a substitute for a proper VCS, it can come in handy when it comes to sharing binary files with others on the team.

The most obvious case is images. The guys whose task is to come up with several different designs for, say, a button on a webapp, will want to share a few psd files, which will then be reviewed by the one who's going to make the call.

Now, while committing assets such as images to source control is definitely worthwhile, throwing in all the intermediate versions isn't going to buy you anything, all the while making your repository bloated (which is especially true if you're using a DVCS). Nevertheless, Dropbox having some sort of rudimentary source control capability, you can still see the history of a file.

So yeah, I think that Dropbox (or Google Drive or whatever) can find its place in a team.

Not the answer you're looking for? Browse other questions tagged or ask your own question.