Skip to content
Daniel Kehoe edited this page Jun 8, 2012 · 24 revisions

GitHub and Rails · RailsApps

by Daniel Kehoe

Last updated 8 June 2012

Using GitHub with Rails. Git provides a source control repository. Use git to roll back code changes as needed, when you are collaborating with others, and when you create an app for deployment into production with a service such as Heroku.

If you are building a throw-away app for your own education, you may decide not to use git, but sooner or later you will need to learn to use git to participate in the open source community.

This is a guide for developers using the example apps from the Rails Apps repository. Others may find it helpful as well.

New to Git?

If you arew new to git, you can read a free online version of the book Pro Git by Scott Chacon.

Check that git is installed on your computer:

$ git version

If you need to install git, refer to the section Installing Git from Scott Chacon’s book. Also see First-Time Git Setup from the book.

Michael Hartl’s Rails Tutorial book also covers Version Control with Git.

Git Config

Check your git configuration parameters:

$ git config -l --global
user.name=Daniel Kehoe
user.email=daniel@danielkehoe.com

The email address will identify you to any services that use your git repo, such as GitHub and Heroku.

Ignore Files

When you use the rails new command, Rails creates a .gitignore file for you in your application root directory. You may want to modify it:

.bundle
db/*.sqlite3
log/*.log
tmp/
.DS_Store

The RailsApps project has a more extensive example .gitignore file you might want to examine.

Initialize Git For Your Rails Application

You’ll need to do this if you have created a new Rails application. If you’ve created a Rails application using an application template from the Rails Apps project, the application template will have done this for you already.

Be sure you are in your application’s root directory.

Initialize git and check in your first commit:

$ git init
$ git add .
$ git commit -m 'initial commit'

You can check your commit status at any time with:

$ git status

Get a GitHub Account

Use a GitHub repository if you want an offsite copy of your work or you plan to share your work with others.

Get a free GitHub account if you don’t already have one. It’s advisable to register using the email address that you’ve used to configure git locally (see “Git Config” above).

Check that your GitHub account is set up properly:

$ ssh -T -p 443 git@ssh.github.com

If your account is set up correctly, you’ll see a message:

Hi ...! You've successfully authenticated, but GitHub does not provide shell access.

The first time you connect, you will be warned (by ssh) that you have not previously connected with the host at ssh.github.com:

The authenticity of host '[ssh.github.com]:443 ...' can't be established.
Are you sure you want to continue connecting (yes/no)?

Unless you are the victim of a particularly insidious and unlikely exploit, you can safely answer “yes.”

If you see an error message such as Host key verification failed, review GitHub’s document setting up Git and SSH keys or the guide troubleshoot common SSH Problems.

Save it to GitHub

Go to GitHub and create a new empty repository (http://github.com/repositories/new) into which you can push your local git repo.

Add GitHub as a remote repository for your project and push your local project to the remote repository:

$ git remote add origin git@github.com:YOUR_GITHUB_ACCOUNT/YOUR_PROJECT_NAME.git
$ git push origin master

At each stage of completion, you should check your code into your local repository:

$ git commit -m "some helpful comment"

and then push it to the remote repository:

$ git push origin master

Git Workflow

When you are using git for version control, you can commit every time you save a file, even for the tiniest typo fixes. If only you will ever see your git commits, no one will care. But if you are working on a team, either commercially or as part of an open source project, you will drive your fellow programmers crazy if they try to follow your work and see such “granular” commits. Instead, get in the habit of creating a git branch each time you begin work to implement a feature. When your new feature is complete, merge the branch and “squash” the commits so your comrades see just one commit for the entire feature.

Here’s how to create a new git branch for a feature named “login”:

$ git checkout -b login

The command creates a new branch named “login” and switches to it, analogous to copying all your files to a new directory and moving to work in the new directory (though that is not really what happens with git).

When the new feature is complete, merge the working branch to “master” and squash the commits so you have just one commit for the entire feature:

$ git checkout master
$ git merge --squash login
$ git commit -am "implement 'login' feature"

You can delete the working branch when you’re done:

$ git branch -D login

Experienced git user? Have a recommendation? Leave a comment below.

Clone this wiki locally