Git is, without a doubt, one of the most important utilities in the modern developer’s toolkit.
Many other version control systems have been used over the years, but none have been adopted as widely as Git. Many attribute its success to public services like Github, and while they are likely right, I like to think that there is a simpler, and equally valid reason: it just works.
Version control systems of the past, ones like Microsoft Visual SourceSafe, CVS, and Subversion stored information about your projects as a list of file-based changes. This works, but Git takes a much more efficient approach. Instead of recording changes to files, Git creates a snapshot of the state of your entire project and only stores information on changes that take place. This difference is huge; particularly once you begin to take advantage of features like branching.
Branching? Yep, branching. It’s fantastic and something we’ll get to in a future post. For now, we’ll go over the basics by creating a repo together.
If you are on a Linux or OS X machine, you’ll likely already have Git on your system. If you don’t, or are on a Windows machine, you can download Git from here. Once installed, open a terminal window/command prompt and navigate to an empty directory.
First things first – let’s go ahead and let Git know who you are:
This command defines your username. Next, we’ll define your email address:
The —global switch stores these values in a .gitconfig file located in your home folder and they’ll be used whenever local values are not available for a repository.
Now that Git is aware of who you are, let’s create a file for Git to track.
OK, here we go! It’s time to initialize a new Git repository with the git init command:
Now that the repository has been created, let’s check its status with the git status command:
Git sees the readme.txt file, but isn’t tracking it yet. In order for git to track the file, we’ll have to tell it to do so by using the git add command:
You can add individual files by specifying their names, but in most cases you’ll want to add all untracked files, so you can use “.” to add all files. Running the git status command a 2nd time shows that the file is now being tracked by Git, but it hasn’t been committed to the repository just yet.
Committing files to Git is just as easy as adding them. We are going to use the git commit command with the -m switch to include a message:
Messages should be fairly short and direct in nature. I tend to write them in the present tense, which makes them easier to read in the future. Running git status for a 3rd time shows that the file has been committed, and the repository is now clean.
Let’s go ahead and make a change to the readme.txt file:
We’ve made an edit and saved the file, so we should run the git add and git commitcommands, as we did before, to make sure that Git is aware of the changes. The only difference this time around is that we’ll append a different message so we’ll understand what work went in to the project leading up to this commit.
Once you’ve committed the changes to Git, run thegit log command:
The git log command will display a list of the commits that were made to the repository including the name of the user who made the commit, the message associated with it, and a hash used to refer to the commit when necessary.
Next time, we’ll cover Git remote repositories and push our test project to Github. Happy committing!
Matt has spent the better part of 2 decades building systems, managing IT departments, and developing websites and applications for the education, publishing, and technical service industries. As an MCSE...
Matthew F. Fox
