4
Posted February 23, 2011 by Spyros in General Tips & Tricks
 
 

How to Create a Repository For Your Rails (and not only) Projects Using Git

Magpie_on_dead_branch
Magpie_on_dead_branch

For a couple of years, i have been using Subversion to manage my projects. I’ve heard about Git many times in the past and since it’s a Linus Torvalds creation, was pretty much interested in taking a closer look. Moreover, my interest in Ruby on Rails, has given me an extra kick towards that direction. You see, RoR uses Git by default, in order to manage your projects. Of course, you should not be surprised. You already know that Rails makes decisions for you and that is what gives it so much power. It saves you configuration time over conventions.

Rails is so biased towards Git that when you execute ‘rails new project_name’ to create a new project, it automatically adds a .gitignore file to your working rails directory(we will talk about that in more detail later in this post). Luckily, Git is pretty close to subversion syntacticallywise, but there are some important operational differences.

The most important difference between Git, Subversion, and the other non distributed source control systems is that a repository does not have a centralized place. Everybody can have his/her own version of a repository, do the changes that they like and never have to report to a central repository. This may now open up the question : “So, what is the good part of a project that everybody has to have ?”. Well, that is actually a matter of trust. Git works by allowing everybody to have branches. Literally everyone. The idea is that people of a certain expertise in an area should be the ones responsible to judge work and pull the code from others, once this is widely accepted. I have to admit that i kinda like this model. It is pretty flexible; and most importantly, better than a centralized system. Moreover, Git has much better performance than other systems.

How to Create a Git Repository For Your Rails – and not only – Projects

Everything that is described for Rails here applies to any other projects that you want to maintain. Let’s say that we create a new project named ‘test’ :

rails generate test

Creating a git repository (after you install git of course), it’s pretty simple, using :

git init

This command creates a .git folder inside your project and initializes a repository. After you do that, you can now add your files into the repository with :

 git add . 

This one will add the whole document tree under which .git now resides. Once you do that, git adds all these files to a local staging area of all the pending changes that you have made. You can check this area with :

git status

Once you have added your files, you can now commit your changes with :

git commit -m 'your_message'

Now, notice the difference. The commit only applies to your local repository. Once more, no centralized place. In order to commit these results to another repository, a remote one, you would have to use a ‘git push’ command. The good thing is that the commands are pretty simple to remember. To checkout(or better clone) a remote repository, you can execute :

git clone ssh://git_server/path_to_git_repos/

or you can use an internal git daemon and a git:// like syntax. The latter is preferred, but i will not go into much detail in this post. For more on the matter, please take a look here. Now, you may be wondering what a checkout would do. Well, it is the same as it would be in Subversion. It gets the data out of your LOCAL repository. It is also used to manage branches.

The .gitignore file

This file is the one that tells Git what files to ignore from source management. For Rails, files like the ones that reside in the log folder are changing all the time and we absolutely have no need of managing these changes. Thus, we have to exclude these files. This operation is pretty much a pain in Subversion, but Git manages that in this single file. The default Rails .gitignore file is like :


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

Pretty easy right ? Just some wildcards that remove all the files from the necessary places and that is all !

Configuring Git

Some last but pretty important notices are the config options of Git. Upon installing Git, you have a .gitconfig in your home folder. This one stores some configuration options for Git. You can directly edit this file or just specify commands like :

 git config --global user.name "Spyros" 
 git config --global user.email "whatever@whatever.com 

These two commands specify who you are for Git and it’s a good idea to use them in order to introduce yourself to the changes you make. Another interesting config would be setting “git co” to be equal to “git checkout” (yes, i have been using svn a lot :P) :

 git config --global alias.co checkout 

Hope this gives you some first insight on Git. Personally, i think i would definately be using that a lot. Expect a tutorial on branching and some more advanced topics soon :)


Spyros