If youre not already using some type of version control on your project, you should definitely start now. Whether youre a single developer or part of a bigger team, version control provides numerous benefits to any project, big or small.
If youre not familiar with what version control is, it is a system used to capture and record changes in files within your project. It provides you with a visual history of these changes, giving you the ability to go back and see who made the changes, what they changedboth files and the changed contents, when they made the change, and, by reading their commit message, why it was changed. In addition, it provides you with a mechanism to segregate changes in your code, called branches (more on that later).
There are a number of version control systems available, some free and open source, others proprietary and requiring licensing. For the purposes of this chapter, well be focusing on the free and open source Git. Git was first developed by Linus Torvalds for the Linux Kernel project. Git is a distributed version control system (DVCS) that allows you to distribute many copies (mirrors) of your repository to other members of your team so as to be able to track changes. This means that each person with a clone of the repository has an entire working copy of the system at the time of the clone. Git was built to be simple, fast, and fully distributable.
This chapter is meant to give you an overview of Git, covering enough information to get you started using it every day in your projects. Since I only have one chapter in which to cover this, Ill only touch on the surface of Gits most commonly used functionality. However, this should be more than enough to get you comfortable with using it. For a more complete, in-depth look at Git, check out Pro Git by Scott Chacon and Ben Straub, available from Apress.
Using Git
To start using Git , you first need to install it on your system. Binaries for Mac OS X, Windows, Linux, and Solaris are available by visiting http://git-scm.com and downloading the appropriate binary install for your OS. In addition to this, Git is also available for RedHat/CentOS systems using the yum package manager or apt-get on Debian/Ubuntu. On Mac OS X, you can get it by installing the Xcode command line tools. In this manuscript, we will use a Linux version of Git.
Git Configuration
Now that Git is installed, lets do a minimum amount of configuration by setting your name and email address in the Git configuration tool so that this information will be shown for commits that you make (a commit being the act of placing a new version of your code in the repository). We can do this using the git config tool:
$ git config --global user.name "Chad Russell"
$ git config --global user.email chad@intuitivereason.com
We can verify that these settings took by using the git config tool again, this time using the property key as the setting we want to check:
$ git config user.name
Chad Russell
$ git config user.email
chad@intuitivereason.com
Notice that you will run the same configuration commands in both Windows and Unix environments.
Initializing Your Repository
To create your first Git repository , you will simply use the git init command. This will initialize an empty Git repository in your source code directory. Once you initialize, you can then perform your first commit to your new repository. For this example, we have an empty directory that well initialize in, then we will add a README file, and finally well add and commit the file to our new repository .
Remember that Git will initiate based on the directory in which the Git command will be called. For instance, if you are in
C:\Program Files (x86)\Git
then the result will be
Initialized empty Git repository in C:/Program Files (x86)/Git/bin/.git/
Well use the following repository and directory as the book progresses to track various code examples that well use:
$ git init
Initialized empty Git repository in /Apress/source/.git/
Initial Commit
Now that we have initialized our empty repository, well add a very basic README file to it and then perform our initial commit :
$ echo "This is our README." > README.md
Now, if we look at the current status of our repository using git status well see that we now have one untracked file, meaning one file that isnt yet added to our repository or being tracked for changes by Git. You can use git status any time youd like to view the status of the working branch of your repository:
$ git status
On branch master
Initial commit
Untracked files:
(use "git add ..." to include in what will be committed)
README.md
Now, well add the file to our repository using git add :
$ git add README.md
If we view the git status again, well see our file has been added, but not yet committed (saved) to the repository:
$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: README.md
Lastly, well commit our change, and our new README will now be in our repository and be tracked for changes going forward:
$ git commit -m "Initial commit. Added our README"
[master (root-commit) e504d64] Initial commit. Added our README
1 file changed, 1 insertion(+)
create mode 100644 README.md
We can see from the message we received back from git commit that our commit was saved. Now, if we check the git status one more time well see we currently have nothing else to commit:
$ git status
On branch master
nothing to commit, working directory clean
Staging Changes
We have our initial tracked file in our repository and have seen how to add a new file to Git to be tracked. Lets now change the README and then stage and commit this change.
Ive added a change to the README.md file, altering the initial text we added to something slightly more informative. Lets run git status again and see what it shows:
$ 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.md
It shows that our README was modified, but that its not staged for commit yet. We do this by using the git add command. Well add it and check the status one more time:
$ git add README.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: README.md
Lastly, well make this new commit, which will wrap up the change to the file we made:
$ git commit -m "Updated README"
[master ca476b6] Updated README
1 file changed, 1 insertion(+), 1 deletion(-)
Note
The staging changes may be configured a bit differently in a Windows environment.
Viewing History
With all of the changes weve just made, it is helpful to be able to go back and view the history of our repository. One of the easiest ways to do this is to use the git log command. When no arguments are passed to it, git log will show you all of the commits in your repository, starting with your most recent changes and descending chronologically from there:
