Plasticx Blog

Capable of being shaped or formed

git workflow using remote repositories to maintain my version of Rails Typo blog

Posted by Mike 08/23/2011 at 12:48PM

This blog is using Rails based Typo (https://github.com/fdv/typo) as its framework. The Typo project is very active and just went through a major release and upgrade to Rails 3. I maintain the source code for the blog in a private repository; when I upgrade the latest Typo changes into my version, I do so using fdv's repository as a remote source repository. I then merge in the external changes, refine my configuration if needed, and redeploy the blog.

Here is the workflow that I use for these purposes. Starting from the absolute beginning would be to clone the repository, or ensure my master was checked out and its latest changes are pulled in.

# get a pristine copy of my own source, after cloning
# I will be at the HEAD of the master branch
git clone git://private/plasticx.git

# OR

# checkout master and ensure we are at the HEAD of
# master's history of our own source
git checkout master
git pull

Next, I make a remote branch of my repository to isolate my work within it. If for some reason my upgrade has complications while merging that are beyond my expertise I can simply throw that branch away and try again.

# create a remote branch called rails3
git push origin origin:refs/heads/rails3

# track and check out the rails three branch locally
git checkout --track -b  rails3 origin/rails3

The next step is to add fdv's repository as a remote repository and fetch its objects and references. We then merge in fdv's work using one of the release tags he has cut rather promiscuously pulling in the HEAD of his master branch.

# add fdv's typo as a remote repository
git remote add fdv http://github.com/fdv/typo.git

# fetch fdv's commits and merge in his 6.0.8 release
git fetch fdv
git merge release_6_0_8

At this point there was a number of merge conflicts to be dealt with. For instance, I had to update the local gem environment installing the gems specified by the project's new Bundler Gemfile. I resolved these issues and then set the branch in my Capistrano's deploy.rb to use the "rails3" branch I created to isolate the work I'm doing for this upgrade.

# if using Capistrano for deployment, we can set the
# branch we are deploying by setting the branch cap
# will check out for deployment in config/deploy.rb
set :branch, 'rails3'

I like to look at the diff of changes I'm about to commit so I use the -v flag when git is invoked to do so; the diff will be displayed below the commit message prompt in my editor.

# fix merge conflicts, change Capistrano branch, etc.
git commit -a -v
git push
cap deploy

I didn't get a perfect deployment the first time I did this. I had to do a number of iterations getting my blog's configuration set correctly for the shared hosting environment where its hosted at. One of the extra configuration items I had to add was to set the shell PATH for the environment Capistrano runs in on the server. This enabled me to use gems that I had installed locally since I didn't have control of the system gems in that environment. I also set the rake command that Capistrano uses to be invoked via Bundler's exec command.

set :default_environment, {
  'PATH' => "/home/mikemondragon/.gems/bin:$PATH"
}
set :rake, "RAILS_ENV=#{rails_env} bundle exec rake"

Happy Blogging!

Posted in , |


Web Statistics