Rails vs Whitewater

Whitewater enthusiast by day, Ruby on Rails programmer by night.

Disclaimer: I am a Github newbie, and I am still learning the various concepts. If I misrepresent something in this post, please let me know in the comments!

I recently switched my project over from SVN to Github. My reasons were varied, but a large reason was because I needed to create various branches to accomodate my ADD style of development (work on layouts for a bit, then switch to security, then switch to fine tuning my models). I also need to create a branch for productions servers, as well as a branch for my staging server, which is set up at home. The latter was a bit confusing at first, until I found a great tutorial here.

First, a couple of notes about my setup. I am the sole contributor to my (private) repository. Up until now, I have not had a need for this “forking” business that I see from time to time. In configuring up my multistage setup, I ran into an issue when I tried to use set :branch, "2.0" in my staging deploy.rb file. Even though I had created a branch for “2.0″ like so:
git branch 2.0
I was getting the following error:
`query_revision': Unable to resolve revision for 'invalid' on repository 'git@github.com:*****/******.git'. (RuntimeError)
This confused me for quite some time, until I found out that the set :branch isn’t referring to the branches that I had created locally, but to github forks. To create a fork from the branch, I simply had to do the following:
git checkout 2.0
git push origin 2.0

The origin bit is what does the magic. As soon as I refreshed, I was able to see the newly created fork in the github web UI, and my deploy recipe worked like magic. Brilliant!

Note: I still have to find out how this will affect my git workflow, but since the clone URL is still the same, it seems that I should still be able to continue with my current way of doing things.

Leave a Reply

Powered by WP Hashcash