I have been a big fan of Git source control for a while now. It’s got great momentum, loads of support on various platforms and plenty of tools to help with using it.
For those not aware of Git i suggest taking a read of the Wikipedia article as i am not going to cover the basics of what a source control system is, or in Git’s case a distributed version control system.
I like Git … it is super simple. There is no server and no SQL database etc… Its all just on the file system.
As a Windows user I recommend the Git Extensions tools. It gives you a GUI tool that lets you do almost everything with your Git repository.
If you are working with someone else on some source there are a couple of strategies for using Git as i understand things (please let me know if there are other better options)
- Create Patches and send those to others (say in an email)
- Create a central repository and Push/Pull changes to that repo that everyone has access to.
GitHub.com is an example of 2. above that a lot of people will recognize. Another, less well known option is Microsoft’s Team Foundation Service (TFS) Online. Both allow you to create and interact with repositories remotely. In a reasonably simple manner. You have to pay for private repos on GitHub and TFS is free for up to 5 users currently with more pricing options coming soon.
1. above seems hard to me. Constantly managing patches etc… eeek
However, for two or three person projects I wanted an even simpler option, so i started looking at using Dropbox to host the central repo. The idea is that team members push/pull from a repo that is in a Dropbox folder and that is replicated between machines. This means no additional setup to do with authentication with those services which i think makes life easier.
There is a drawback that you need to be aware of! You really want to avoid people pushing changes to the central repo at the same time. This can lead to Dropbox getting confused and corrupting the repo. However, if you IM people and make sure it’s all clear then you should be good to go. This is really only suitable for a two or three person team. Get a GitHub account if you need something more robust 🙂
Here is how it looks:
The central repo doesn’t have a “working directory” (a copy of the source that you can work on). It’s just the Git repo. You can’t edit files etc… in this location. The Central repo is synced between, in this case, two peoples machines (there is also a copy in the Dropbox cloud).
Each person “clones” the central repo to a local working location on their machine. They do this as a personal repo so that they get a working directory. This will allow them to edit and modify files etc… They can also “commit” (aka checkin) changes to their personal repo.
When they are ready they Push commits from their personal repo to the central repo. This then replicates the changes to others.
This might sound complex, but if you are a Git user and familiar with the tools its pretty easy to set up.
Using Git Extensions you do this as follows:
First create a new Dropbox folder:
Open Git Extensions and create a new central repo like this in your new folder in Dropbox:
Now go and create your personal Local repo by cloneing the central repo … but do it to a local directory (non-Dropbox)
Then you can open your Local repo and work your coding monkey magic in there. Drop in a file for example (note the irony of the filename i am using here and the file extension … i don’t like JS).
Commit that sucker and you have made your first legit change to the code.
At this point your buddy cant see your stuff. You have been working locally. So now you need to Push your commit to the central repo.
Notice that your central repo is already set up as the “origin” remote location. Push to that and you will notice some files start syncing in Dropbox.
Now your central repo is all syncing and dancing your counterpart can join the Dropbox folder and do the same “clone” process you did to create a local repo that they can work in.
I got the idea for using this method a while back from this stackoverflow thread: http://stackoverflow.com/a/1961515/26843 It shows you how to do this same process via the Git command line.
-CJ
Since you showed this to me, I’m loving this option. One thing I screwed up that others will want to take note of is that you definitely want to have local clone outside of Dropbox and not within Dropbox. I made that mistake and noticed (surprised me but it is pretty obvious why) Dropbox was getting real chatty on each build.
So… say you do some work on one machine but you aren’t finished and want to switch to the other machine to continue it. You don’t want to commit the changes to your local branch & push to the central repo. A GIT STASH won’t work (I don’t think) because that will happen on your local branch, not the central repo.
Thoughts?
I use a couple of methods to do this AC,
#1. You should be working in a feature or development branch anyway, so committing and pushing to the central repo shouldn’t interfere with your production code etc…
#2. Make your local repo in another Dropbox folder. When you start working pause Dropbox syncing to stop the constant syncing when you build. When you are done start the syncing again. This way your other machine will get the changes. This is a good option only if you have multiple dev machines that you use.
I personally prefer #2 over #1 because then i am not committing potentially half done code even to my dev branch.
-CJ