Harry Seldon's blog

Fractals, Chaos, and Control Systems on Rails


Git and Rails: A detailed tutorial including plugins, submodules, development and production

Posted by Harry Seldon on January 14, 2009

I had started talking about setting up a development and production environment with git for Typo in this post. Because of this new version of Typo, I have finally had a very good reason to change the set up of this blog and to migrate to git. Installing Typo from its git repository, I have had the opportunity to use the git submodules. That is why in this post I will use the Typo blog engine to make a case study for the use of git with:

  • Several repos for development, production and deployment
  • Several repos for open source development
  • Use of submodules for plugin management and development

Indeed, my own aims for this new setup are to:

  • Have a test environment and a production environment for this blog
  • Be able to update the blog engine from its main repository
  • Be able to contribute to this open source blog engine
  • Manage properly rails plugins
  • Be able to contribute to these plugins

The final setup is as following, represented on the figure below:

  • I have a repository where I develop and test Typo. This repo is first created by cloning Typo’s repo. From my point of view this is the main repo. Indeed I can pull from Typo’s repo or push to it. in the same way I can push to the production repo, to deploy. Deployment can be managed easily by Capistrano in this configuration. Notice that several branches can be contained in the repo (public branch pushed to the main repo, private production branch, etc.)
  • Production repo. The actual production code is a checkout from this repo.
  • My public dev repo. It contains the changes I can propose to Typo’s dev team through a ‘pull request’.
  • Main repo. Currently it is Fred’s repo but thanks to git architecture it could be as well the public repo of who you want.
  • Fred’s private repo. He may have several dev repos, with plenty of branches, on several computers .
  • Cyril’s public repo.
  • Cyril’s private repo

git image
For each repo, the plugins are put in subrepo and managed through git submodules. That is, each plugin has its own repo and is not included in Typo’s repo. However, the beauty of the submodules is that you can really easily develop and update your plugins.

Now let’s go for a detailed tutorial to set this up.
This setup is for people willing to have a full development environment. However, if you just want to install Typo, you simply need to skip the first step, the creation of the public repo. And in this case you can consider that your public user name is ‘fdv’ but you will not be able to push to the repos.

Create your public repo
Fork Typo on github using your account. As you are doing that, also fork the plugins that interest you, for instance Recent comments, Recent posts and Related posts.

Create your dev repo
Then, clone the Typo repo from your public repo. Type this command in the local directory of your choice. Replace the user name harryseldon by your name.

git clone git://github.com/harryseldon/typo.git

To be able to update your dev repo with the latest changes, add the address of the main repo:

git remote add main_typo git://github.com/fdv/typo.git

Then to update your copy, you simply need to pull the changes:

git pull main_typo master

NB. The repo you clone from will be called ‘origin’ in your local copy. If you prefer you can initially clone from the main repo and then add the address of your github repo.

In order to run, like every Rails app, Typo requires some plugins. They are managed through the git submodules. So you just need to run:
[EDIT 3/8/2009] Typo plugins are now managed using gems, check this post.

git submodule update --init

With this command the plugins will be pulled from the addresses written in the .gitmodules file which looks like this:

[submodule "vendor/rails"]
  path = vendor/rails
  url = git://github.com/rails/rails
[submodule "vendor/actionwebservice"]
  path = vendor/actionwebservice
  url = git://github.com/datanoise/actionwebservice.git
[submodule "vendor/plugins/rspec"]
  path = vendor/plugins/rspec
  url = git://github.com/dchelimsky/rspec.git
[submodule "vendor/plugins/rspec-rails"]
  path = vendor/plugins/rspec-rails
  url = git://github.com/dchelimsky/rspec-rails.git
[submodule "vendor/plugins/will_paginate"]
  path = vendor/plugins/will_paginate
  url = git://github.com/mislav/will_paginate.git

If you have your dev version of one of these plugins, do not hesitate to change the address to point to your public repo.

Then you may want to install your preferred Typo plugins. The ones you have just forked on github.

git submodule add git://github.com/harryseldon/typo_related_posts.git vendor/plugins/typo_related_posts
git submodule add git://github.com/harryseldon/recentposts_sidebar.git vendor/plugins/recentposts_sidebar
git submodule add git://github.com/harryseldon/recent_comments_sidebar.git vendor/plugins/recent_comments_sidebar

and again

git submodule update --init

To use Typo in your dev environment, you finally need to configure your database. Use your usual settings and run the migrations. Typo will work like any other Rails app.

Like any other git repo, feel free to create as many branches as you like. For instance you can create a production branch:

git branch typo_production

You would typically set the environment to production in environment.rb.

Create your production repo
Assuming an ssh connection, you create the repo on your host in a ~/git/Typo directory.

git init

You add the address of this repo to your dev repo:

git remote add production_repo ssh://user@ssh.domain.com/home/user/www/git/typo/.git

Now you can push your code to production. Let us say you created a special production branch,

git push production_repo typo_production

This step could be done using Capistrano and pushing the development branch. Capistrano would be typically in charge of making the changes in environment.rb.

Commit changes
Assuming you made some changes in your dev repo. You commit them:

git commit -a -m "my changes"

Then you can push them to your public repo:

git push 

Accordingly with the previous NB, this is equivalent to:

git push origin master

Then from your github account, you can send a “pull request” to Typo maintainers if you would like to see your changes included in the official Typo code.

As far as the plugins are concerned, the process is similar. You cd to your plugin folder which is under a git version control and you can push, just like for the Typo repo.

Following this tutorial, you have installed a typical environment for a Rails application under git version control.

Feel free to leave comments about the git environment or the Typo installation.

Posted in | 8 comments | Tags , , , , | atom

Migrating to Typo 5.2 and to GIT

Posted by Harry Seldon on January 13, 2009

Typo, this blog engine, underwent a lot of great improvements these last months thanks to Frederic and Cyril (2 blogs in French). So it was time for me to upgrade this blog to the new version: Typo 5.2 Release Candidate named after Helmut Newton. The main improvements are:

  • A lot faster (you should notice it)
  • A new backend: more flexible, simpler, with a clearer dashboard summarizing the last comments, the last posts, the most popular posts
  • A new text editor that facilitates the use of markup languages (I am specially glad of that one as I had complained about the previous text editor)
  • New SEO functions: places to easily enter your meta information: keywords, webmaster tools api, google analytics key etc.
  • Use of Coderay for a better syntax highlighting for many programming languages
  • Easier search (previous one was sexy but surprising when you hit the enter key)

The main thing missing is a live preview but that might be for the next release !

During the migration (to the RC) I had a few small difficulties:

  • I did not find the sidebar settings: they moved to the themes menu and sidebar submenu .
  • The plugins recent comments and recent posts were not compatible with Typo 5.2. I had modified them. But actually they now are compatible as Fred added the backward compatibility.
  • If you use your own theme, you will need to update the index page. Indeed the call to ‘classic pagination’ must be replaced by a call to ‘will paginate’. Simply copy and paste from one of the example themes.

By the way, migrating to git, I was able to update these plugins accordingly with what I had said in this post: Typo plugins for “recent comments” and “related posts”. To get the modifications, right now, you need to use my forks on github:

I had started talking about setting up a development and production environment with git and Typo in this post. Because of this new version of Typo, I have finally had a very good reason to change the set up of this blog and to migrate to git. The migration to git will be the subject of the next post. Installing Typo from its git repository, I had the opportunity to use the git submodules. That is why in this post I will use the Typo blog engine to make a case study for the use of git with :

  • several repos for development, production and deployment
  • several repos for open source development
  • Use of submodules for plugin management and development

To be continued !

Posted in | no comments | Tags , , , , | atom

Grand Gardening with GIT

Posted by Harry Seldon on November 08, 2008

Why is GIT so interesting ?

With git, I have been doing some gardening these days. Indeed I growed trees, cut branches, grafted branches.
I have been using a Version Control System (VCS) only for one year. That is about since I started the Thinkosphere project. I have been using SVN. At first I was like “Hey this is so cool”. SVN is a real time machine or at least a past time machine. You can easily go back in time to get the state of your source code from months ago. Unfortunately you cannot go forward to the future (with GIT you will be somehow able to do that !).

So after the honeymoon with svn, I began to find some limitations. Mainly I was missing an easy way to have two repositories talking to each other. Let’s see why. Here is a concrete example of how a Distributed Version Control System (DVCS) can be useful. This blog is powered by Typo which is open source. I downloaded the source code and I put it into a repository of mine to be able to make some minor changes (for instance these ones). But doing this I lost the connection with the original repo. That means I cannot easily upload my changes to the “main” repo neither can I go forward in time by downloading the last changes on the main repo.
This is exactly the kind of situation which git was designed for. Indeed with git the various repos can easily communicate with each other. So I can merge the latest updates from the main repo to my own local repo.


Let us see the setup of such a configuration in details. I will not use the example of this blog because it is still theoretical as I have not migrated it to git yet. Instead, I will use the exact configuration I am using to contribute to Open Flash Chart plugin and its test app.
Notice the setup is well explained in the excellent GIT User’s Manual at this chapter from which I am taking the following graph:

                      you push
your personal repo ------------------> your public repo
      ^                                     |
      |                                     |
      | you pull                            | they pull
      |                                     |
      |                                     |
      |               they push             V
their public repo <------------------- their repo

Let us go over the steps. Imagine you want to download OFC test app, you want to make your own modifications while being able to regularly download the updates and you also want to upload your changes.
For the configuration resulting from the following tutorial, I can precise this:

  • your personal repo = local repo = repo on your computer = repo in your working copy
  • your public repo = repo on github, mine is here
  • their repo = repo on PullMonkey’s computer
  • their public repo = ‘official’ repo = repo on PullMonkey’s github

Let me precise also some GIT Vocabulary :

  • To upload your changes from a repo to a repo is to push.
  • To download your changes to a repo from a repo is to pull (to be precise pull fetches the changes and merge them to the current branch).
  • To upload your changes from your working copy (or working tree) to your repo is to commit.
  • To download changes from your repo to your working copy is to checkout (checkout command is also a simple command to switch between branches).
  • Downloading a repo to create a repo : clone.

First, your fork the public repo to a public repo of yours: You go there you click on fork. (you will need a github account)
Then you download (clone) your repo to your local repo :

git clone git://github.com/pullmonkey/ofc_test_app.git

(It both creates the repo and checks it out)

Now you make some changes. You commit them:

git commit -a -m "my changes"

You want to upload your changes to your public repo:

git push

You want them to take into account your changes. You send them a pull request through email or github.
They agree to try it, they pull from your repo to their repo. They love it. They push it to their public repo.

They also made some more changes. You want to get them.
The first time you need to add the address of the public repo:

git remote add their_public_repo git@github.com:pullmonkey/ofc_test_app.git

Then, here is the GIT’s beauty, you pushed to a repo but you pull from another repo:

git pull their_public_repo

You can add as many repos as you want. You can see all these repos from a part of the global tree of the application development. Each repo is a tree branch. More than that each repo can contain several branches. Each branch can have a purpose: development, test, release etc. So have a happy gardening and happy time travels with git !

Any mistake, any problem or everything works ? Leave a comment !

Git resources:


As I am a private pilot, all this push/pull stuff made me think about the push/pull aircraft :

Notice it has two propellers aligned with the fuselage one to pull and one to push.

Posted in | 8 comments | Tags , , , , , | atom

Some useful commands in Linux administration when making a website.

Posted by Harry Seldon on September 27, 2008

This is a cheatsheet of useful commands in Linux administration when making a website in Rails. I am using these commands over and over again so I thought it might help someone.


Detailed list of files:

    ls -l 

List the running processes:

    ps -e  

Create a directory:

    mkdir demo 

Kill the use of a specific port (I use it when Aptana/RadRails crashes and do not close the port):

    fuser -k 3005/tcp  

Delete a directory and subdirectories, without confirmation, verbose mode. (BE CAUTIOUS !):

    rm demo/ -r -f -v  

Add a cron jon:

    crontab cron_job.txt 

List cron jobs:

    crontab -l 

Create cron job:

    crontab -e 

Mount a local virtual directory for an actual remote directory:

    sshfs ‘-oworkaround-rename’ username@ssh.domain.com: /home/username/remote/ 


Connect to mysql local server:

    mysql -u username -p 

Connect to mysql remote server:

    mysql -u username -h mysql.domain.com -p 

Create databases (Rails style):

    CREATE DATABASE demo_development; 
    CREATE DATABASE demo_test; 
    CREATE DATABASE demo_production; 


Create a rails app:

    rails demo  

Install a plugin:

    script/plugin install git://github.com/pullmonkey/open_flash_chart.git 

Install a plugin, force reinstall:

    script/plugin install git://github.com/pullmonkey/open_flash_chart.git –force 

Launch server on a specified port:

    script/server -p 3005  

Open a console where you can send ruby commands to your app (Extremely useful!) in dev mode:

    script/console development

Open a console where you can send ruby commands to your app (Extremely useful!) in prod mode (BE CAUTIOUS !):

    script/console production

Migrate the database:

    rake db:migrate 

Migrate the database to a given version:

    rake db:migrate VERSION-22 

Migrate the production database:

    rake db:migrate RAILS_ENV-production 

Install gem:

    gem install RedCloth 

Install a given version of Rails:

    gem install -v-2.0.2 rails  


Checkout a repo (svn meaning):

    git clone git://github.com/pullmonkey/open_flash_chart.git   

Get the differences:

    git diff 

Fetch from and merge with another repository or a local branch:

    git pull 


    git checkout 

Create a branch:

    git branch mybranch 

Configure the user settings:

    git config –global user.name "toto" 
    git config –global user.email "toto@example.com"  

Posted in | 2 comments | Tags , , , , , | atom



Recent Comments

Recent Posts


actuators aircraft atc blog chaos chaos_theory charts control controllers controls crisis economy finance flight fractals git gnc gs guidance linux mandelbrot marketing navigation ns ofc on pilot rails ruby sas scs sensors statistics systems techcrunch thinkosphere tutorial typo ubuntu wifi