One of the thornier problems in our workflow is knowing when assets are delivered from the designer and keeping them in sync with our application as they change. We used to use e-mail, Skype or sticky notes. The trouble is that the designer’s file naming and directory structure were never quite the same as the application’s /public/images directory, so direct comparisons were impossible and we ended with a lot bookkeeping to make sure that we didn’t lose any changes. Our solution is to clone the project’s git repository into a folder inside a shared Dropbox folder.
Dropbox is cheap, if not free, available on all platforms, and synchronizes easily across most network connections. git is, well, awesome version control. We already had a Dropbox account set up for the project, and all team members had accepted invitations to join the share. We then made a git clone of our application source code in the Dropbox folder;
cd ~/Dropbox/MyProject
git clone https://github.com/myproject/myapp git-repository
We took a minute or 2 to show the designer how to find the images directory, and our basic rationale behind naming and directory structure. That became her “new” assets folder. We did not show the designer how to use git, nor do we need to. As far as she is concerned, it is just another folder. /public/images is even a familiar place for designers.
Here’s where the fun starts: We add the Dropbox/git-repository as a remote to our main project repository.
cd ~/myapp
git remote add dropbox file:///Users/me/Dropbox/MyProject/git-repository
Now, as far as our main project is concerned, the Dropbox folder is another remote, just like github.
During our daily workflow, whenever we need a new asset, or to look for a changed one, we cd over to the Dropbox folder with the git repository, change into the /public/images directory and look for what we need. We then use git add to stage and commit only those assets that we need. Back in our main project, we then
git pull dropbox master
from the Dropbox remote and voila! New images! Later, if the designer makes changes, we can simply run git status to see what’s changed, re-run git add, commit and pull. The only really gotcha is training our fingers not to type git commit -am '...'
We have found this to be a very fast, lightweight, way of integrating new assets into the project and keeping track of old ones. The designer is no longer worried about getting out of sync with our project, nor are we worried about missing design changes. As a bonus, there’s a history in the git logs, so we can review changes and even revert if necessary. All this without the designer ever learning a single git command, nor us worrying about our project directory getting accidentally clobbered.
[This is actually a very old trick that I've been using since the late 90's, but back then it was using CVS and NFS mounted shares!]
There are other benefits, too. Sometimes we’ll make minor fixes to the images delivered to us. By adding a remote to the Dropbox git repos, we can pull from our application master and then the designer gets our fixes.
cd ~/Dropbox/git-repository
git remote add myapp file:///Users/me/my app
Remember, it’s just a git repos! You can alway revert or reset to previous versions. In the most terrible worst case, you delete the whole Dropbox directory and start “over,” that is, at the HEAD of the repository master on github (or whereever).
This will be even better once Dropbox handles connecting to more than one account’s folders.
April 7, 2011 at 10:53 pm
You can connect two folders in different accounts already. You have to use the “sharing” feature.
http://www.dropbox.com/help/19
April 8, 2011 at 5:34 am
This is a sharp, out of the box way for this common problem. Good thinking! I’ll use this once I can afford a designer :D
April 8, 2011 at 5:37 am
I’ve been using this way since 2008 but if you’ve +100 git based projecty in your “dropboxed” projects folder it really slows down synchronizing. Each git action triggers a lot of indexing activity and even on my 8GB mid-2010 MBP with a SSD it consumes a lot of CPU resources.
So I would recommend to keep the small files out of dropbox, e.g. if a project became stale tar/zip it or put in a virtual filesystem image file.
April 8, 2011 at 5:47 am
We do the same thing, but we also cron’d a task that commits any changes automatically and pushes them to a shared repository.
April 8, 2011 at 6:24 am
When picking only certain files to stage for a commit use `git add -i`to add files in interactive mode. Such a timesaver!
April 8, 2011 at 6:46 am
This does not seem like a safe setup.
If two developers push into the codebase that happens to be on Dropbox, one of the changes will be lost.
April 8, 2011 at 7:45 am
Good stuff. I’m curious – why do you add the add the Dropbox git repo as a remote and pull from it, as opposed to just pushing from it after you commit the assets?
April 8, 2011 at 7:50 am
This isn’t working for me. I do the above and I get the following message: fatal: ‘file:///Users/me/Dropbox/Projects/Social-Linking’ is not a valid remote name
April 8, 2011 at 10:20 am
Miguel,
It’s safe in the sense that devs are not pushing into the dropbox folder under normal circumstances. The only editing that goes on should be by the designers on assets which is a safe proposition as far as git repo consistency goes. I did a variant of this for a project with 3 other developers where we shared a folder and all had copies of our bare git repos in there and had the convention of only pulling from each others repo and never to push to someones dropbox repo. It worked well in practice and was a good way to work for small projects.
April 8, 2011 at 10:32 am
Mmm, it seems better for me to just have the images in the Dropbox folder, and the hard-link that folder from your project outside of the Dropbox folder.
Images are still synchronized between everyone (only one copy) and, well, there is no need to duplicate anything, and it seems equally secure (the git data is safe outside the Dropbox folder). Any small change to the images, though, would be automatically shared. On the one hand, it would be difficult to try something locally without sharing it with anybody (but possible, just disabling Dropbox for a moment). On the other hand image changes are noticed by everyone without having to check two repositories.
April 8, 2011 at 11:36 am
Thanks for sharing your setup.
Small typo:
git pull drobox master
should be:
git pull dropbox master
April 8, 2011 at 11:38 am
Sparkleshare (www.sparkleshare.org) is designed to act as a Dropbox+Git tool, specifically for designers. It’s still in beta but is being actively developed and used. Give it a look!
April 8, 2011 at 11:54 am
Hi,
I find that adding the whole repo can add a lot of crud to dropbox when you have 15+ repos in there. Starts to slow down indexing on linux based systems. I usually just do a symlink from the dropbox to the images repo so that we can see immediately when new files are updated and just commit them without cd-ing into another dir.
-Mario
April 8, 2011 at 12:31 pm
Bah it’s a band-aid. Just teach them git. If your designers can’t work on the app, then who’s designing the app?
April 9, 2011 at 3:50 am
`git remote add file:///Users/me/Dropbox/MyProject/git-repository dropbox` should be `git remote add dropbox file:///Users/me/Dropbox/MyProject/git-repository`
April 11, 2011 at 9:26 pm