Git is the most popular version control system for use with Ruby on Rails. There are others, but Git is probably the easiest, certainly capable, and most Rails developers know and use Git. Plus, you can share your code on the very popular Github site (among others).
Git is a distributed version control system. This means there's no central server, even when working in a group you don't continually need to check in your changes, and if you're just working on your own it means you don't have to run a separate server program. When working in a group Git can push your changes to a "remote," so and you can pull changes made by others from it. Git was originally written by Linus Torvalds (of Linux fame) in 2005 to manage the very decentralized Linux kernel development. Since then it's been taken over by the community and the preferred version control by many programmers, probably owing to its simplicity. But, in the end, it's a version control system. It tracks the changes that you make in your code, gives you a summary of what you changed and lets you roll them back if necessary.
Installing Git is not very hard. It should be included if you used the Rails Installer for OS X or Windows, there is msysgit for Windows, Homebrew can install it on OS X and on Linux it should be available via apt-get or whatever else your distro provides.
Git can do a lot of things, but the very minimum you need to do is create repositories, add files to it, create branches, merge branches and undo your changes. All of this can be done from the command line with a few simple commands.
Imagine you've just generated a new Rails project. One of the first things you should do is initialize a new git repository. So change to the project directory and run the git init command. This will create a new empty repository, stored in the .git hidden directory.
$ cd some_rails_project $ git init Initialized empty Git repository in /Users/user/rails_projects/test_project/.git/
OK, now you have a new empty repository, let's add all the files. Strictly speaking you won't be adding all the files, there is a .gitignore file generated by Rails that tells Git to ignore a few files, such as the log directory and the databases. To add all the files in the project, add the current directory and Git will recursively add all the files from the project. This is done with git add .. Adding files you intend to commit is referred to as "staging."
$ git add .
OK, the files are added. There will be no output, but they're added, but they're not committed yet. Every time you make a change, you need to commit the changes to save them to the repository. And every time you commit, you need to provide a commit message. Since this is the first commit, we'll just use the message "initial commit." Future messages might read something like "fixed the login screen," or reference to an ID in the bug tracking software. This is done with git commit -m "Initial commit".
The typical workflow for git is to make a change and if the change was successful, to commit the change. So let's change a file. We'll edit README.rdoc and commit the change. To get the status of the git repository, use the git status command. It will tell you that you modified README.rdoc, but that the changes won't be committed. That's because the changed file is not staged. Staged files are files that you wish to commit changes to. You have two choices when you want to commit, you can git add the files you wish to stage (we could run git add README.rdoc to stage it), or use git commit -a to commit changes to all files. Since the only file changed is the file we wish to commit, we'll use git commit -a here. And remember you'll also need a message.
$ vim README.rdoc $ git status # On branch master # Changes not staged for commit: # (use "git add
..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: README.rdoc # no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m "Worked on README"
OK, let's make another change. We'll edit config/database.yml, but we'll do it wrong. We don't know what we did wrong, and we just want the old version of the file back. So first edit the file (make any change, just enter a blank line somewhere in the file) and run git status to see that it has been changed. Then, we'll roll back the change by "checking out" the file from the repository using git checkout config/database.yml and git status to confirm it.
$ vim config/database.yml $ git status # On branch master # Changes not staged for commit: # (use "git add
..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: config/database.yml # no changes added to commit (use "git add" and/or "git commit -a") $ git checkout config/database.yml $ git status # On branch master nothing to commit (working directory clean)
If this is all you know about Git, you can effectively use it. You won't have to worry about making changes, you can easily undo them. But there's another feature you should probably be using: branches.