First and foremost the full disclosure: I’m new to Git. Although I’d used Github for a few of my errant thoughts/projects, it was for the most part just copying commands without a deep understanding of the benefits of distributed source control.

Today a light clicked on when I was finally able to set up a Dropbox repository and share it out with some collaborators. First, here are the steps I followed, adapted from an old post by Roger Stringer.

Setting Up Your Remote Repository On DropBox

1. Get Dropbox, create your folder. (If you don’t have a Dropbox account, please use this affiliate link which will give me more space).

2. Create a “bare” repository there:

git init –-bare

Setting Up Your Local Repository, Pushing To Dropbox

Now that you have your DropBox folder set up to be a remote repository, you can set up your working folder. I already have a Visual Studio project with some files in it so I just started a Git Bash in that folder.

1. Double check that you’ve got a .gitignore file that is configured for Visual Studio or whatever project files you’d like to ignore.

2. Create the local git repository with the following:

git init .

3. Now add all your files to be tracked by the local repository with the following:

git add --all

4. Commit the changes you made by adding all those files:

git commit –m “Added initial files for git tracking”

5. Now set up your remote repository as the previously created “bare” repository in DropBox. Here is the small divergence from the original article since Windows is the file system:

git remote add origin /c/users/curufin/dropbox/gitbox

In the above:

6. Push your files to the remote dropbox repository:

git push origin master

Collaborators and Others Wishing to Connect to Your Repository

The point behind using Dropbox is to have a synced space for your remote repository but without hosting and some of the other frictions or sharing elsewhere. Here are the steps to get your collaborators onboard:

1. Share your Dropbox folder with them. They will need Dropbox accounts, of course.

2. Once the folder is shared and propagated, they will need to make an empty repository in the folder from which they plan to work. The command, reiterated from above is:

git init .

3. The next step is to point to the remote repository. The “remote” repository is really the synced Dropbox folder and the idea is that Dropbox will do the heavy lifting in terms of keeping the folders synced.

git clone /c/users/celebrimbor/dropbox/gitbox

In the above:

4. The next step is to do a pull from the remote repository.

git pull origin

5. At this point they should be able to inspect the project files in their local folder and work on them using git to manage their versions.

The Future Is Distributed

I opened the article by admitting I am new to Git. In terms of serious projects, I would only consider the last month or so as legitimate experience. I’ve also struggled, as a person relatively experienced with Subversion, with the gestalt of Git.

However what the above shows is how useful it is to generate repositories that live in local or remote file systems and how much flexibility there is in being able to take advantage of existing protocols and structures that do the sharing on our behalf. Not only is that remote repository so easily accessible, it’s logically separate from my local repository to which I can make changes and commit to my heart’s content. There are probably other niceties but the last positive I noticed was that Git was tracking my changes with my default user/email configuration. There is a way to reset this but it makes it easy to differentiate my changes from any collaborators. If you add on the ability to do in place branching this is quite a powerful environment.

One final note: of course the above is probably not a great idea for a full fledged project (or is it? maybe someone with experience can comment… ). The project I work on is taking advantage of Github and especially after using their tools to hunt down (blame button!) some issues I fully appreciate their business model. One other plug is for my personal project hosting provider, ProjectLocker. They host Git repositories and after 2+ years with them as a primarily Subversion customer, I’m happy. I’ve started my first Git repository and the process is straightforward.