Git is a powerful version control system. It was first cooked up by Linus Torvalds (of Linux fame) for managing the very fragmented development of the Linux kernel. The Linux kernel has a unique situation of both being very large (in terms of the number of modules and drivers that are part of the source code) and number of developers all over the world. This is not something that traditional source code management software was able to cope with, and integrating patches from these developers became a full-time job. Git is more of a distributed source code control system, this is useful for a few reasons. First, there's no server needed, this makes it very simple to use as an individual. Second, it's built to be able to split and merge individual parts with a minimum of conflicts.
Git is very, very compatible with the Ruby and agile mindset. The ability to just fire up your command line or Git client and editor and just get to work without having to worry too much about what the other developers are doing is freeing. You can very easily make branches, and if what you were trying was a total failure, just delete the branch. And to say that Git is not server-centric doesn't mean that it's isolated. Git servers, such a Github, are all over the place, and this makes collaboration extremely simple.
Using Git with Ruby
- Installing Git on Windows - You can't do much with Git without installing it first. Windows is not the most popular platform for developers out there, so in the past installing Git on Windows used to be a bit of a pain, but modern installers have cured this. Installing Git on Windows is a snap these days, and it can even be bundled with a Bash prompt to make those for Linux or OS X a bit more at home.
- Installing Git on Linux - Installing Git on Linux is usually very easy. On Ubuntu, it's just a simple apt-get command away.
- Creating a new Repository - Before you can start tracking changes to your source code, you need to create a new repository. On server-centric source code control, this meant authenticating and creating new things and submitting across the network, but with git it takes just a single command and lived inside a directory in your project folder.
- Adding Files to a Repository - Before you can start tracking changes, you need to add files to the repository. This is referred to as "staging files," and all files are ignored unless staged.
- Committing Changes - Once you have files staged and changes made to these files (or the files newly added), it's time to commit your changes. Committing changes determines what lines in the files have changed and stores these changes away in an archive. You can then step back through these changes in case something goes wrong.
- Git Status - The git status command is very useful. It'll tell you which files have changed, which files are new but have not been staged, etc. If you're ever unsure of the state of your git repository, run the git status command.
- Getting a Diff - A "diff" is a list of changes to a file. This is useful to both summarize your changes to a file (which lines were added or changed, which were removed) or to send a patch to someone else. By sending someone this diff, they can then recreate the changes to these files whether they use git or not.
- Tagging Releases - Tagging releases are a way to label certain revisions with a name. By tagging a revision with something like "v1.0", you can easily retrieve the state of the software at release 1.0, without having to have branches for each of the releases.
- Retrieving a Tagged Release - It's often useful to see the state of a project in two different stages, especially for testing or tracking when a bug first appeared. To do this, you can clone the repository and switch to an earlier branch, without touching your working copy.