This is a guide to using Git for absolute beginners to version control for development projects, using the GitHub for Windows program and just the basics needed to integrate Git into your everyday workflow. Git is a very powerful system but even the fundamental concepts can be overwhelming at first, especially when your only question is “How do I start using version control with my current workflow?” This series of Beginner’s Guide to Git tutorials will help answer that question.
If you haven’t already, before you get started on this post, you should either create a local repository or clone a remote repository. Either way, once you have a repository, you can follow along with the tutorial in this post.
What’s a Repository Again?
In case you’ve forgotten, a repository is just a special directory that holds all of the files we want Git to ‘version’, or track with version history. It’s ‘special’ because it contains a hidden folder called .git, that holds all of the historical changes.
As we talked about in the previous posts, you do work and make changes inside of a local repository, or a directory on your local computer. This is called your Working Repository. This is different than a Remote Repository, which should always be bare. So I just want to reiterate that we are going to work with the local repository, if you chose to follow the instructions from the previous post.
So here I open up GitHub for Windows, and I’m going to use the repository named ‘SharedRepository’:
Remember, it’s a clone of a remote repository that lives in the network share, which I cloned to my local computer. I added it to my list of local repositories at the very end of the last post. You don’t have to use a cloned repository; you can create a new local repository with no remote (origin) repository.
In Git land, Commit is not only a verb, it’s also a noun. Rather than try to explain what it is, I will demonstrate and show you. Let’s start on the project, which is to make a simple web page. First, I open up the ‘SharedRepository’ folder on my local disk, and create an ‘index.html’ file. It doesn’t really matter what’s in the file – let’s just say it’s got the most basic html tags like <html>, <head>, <body>, and the title tag <h1>, but not much else.
Click on the repository name in GitHub for Windows to open it. The new file is listed under ‘Uncommitted changes’. Git tracks any newly added files, deleted files, and changes made to existing files. The section of ‘Uncommitted changes’ on the right-hand side is called the Stage. You can select and deselect the changes that you want to be included in the next Commit. You can also discard a change (right-click on the file in the Stage and click ‘Discard’).
After the completion of a development step, minor feature, or significant modification to the code, you should Commit all the changes. If you’ve ever worked with database transactions, you may be familiar with the concept of “Commit” as it relates to data management. The Commit for versioning is similar. All of the changes since the last commit are related together as one unit, and they can be removed as one unit (see Revert in the next post). That’s why it’s important to develop with the concept of atomic changes and commit frequently. (Once again, if you want to know the whys and wherefores, read this great post Commit Early, Commit Often.)
To commit, fill out the ‘Summary’ and ‘Description’ boxes on the left with helpful clues on how to identify this commit, and then click the ‘Commit to master’ button. The repository now reads ‘No uncommitted changes’ and the unit we just committed is listed under ‘Unsynced commits’.
You may be wondering two things:
- Why is the commit listed under ‘Unsynced Commits’ and not under ‘History’? – That will be discussed in another post, Publish & Sync. For now, when you’re only working in a local repository, it doesn’t matter.
- How did my name get there, in the commit list above the commit name? – You can set your name in the Options panel of GitHub for Windows. Also, if you have a GitHub account, you can log in and include your profile picture. This is very handy when you start to do collaboration, and will also be discussed in Publish & Sync.
Now, let’s make more changes. I’ve created a new file, ‘page2.html’, in the SharedRepository folder, as well as opened up the first file ‘index.html’ and made some modifications. When I go back to the GitHub for Windows client and click on ‘Uncommitted changes,’ I can see exactly what I’ve done since the last commit.
I can also click on ‘index.html’ to expand that section, and the modifications that I made to the file are highlighted for me in green, with a + sign on the far left to indicate this line was added.
So now I write a summary and description for this set, and then Commit. Now it’s also listed in chronologically descending order under ‘Unsynced commits’.
Probably by now, you have some idea of what’s going on. Work, commit. Work, commit. The timing of when and how often you commit is up to you, but the more often, the better. You don’t need to commit after every line of code you write, either. Once you understand how Revert and Roll Back work, you may get a better idea of how often you should Commit.
The essential piece to Git is the Commit. Each Commit you perform takes a “snapshot” of your work at a certain point in time, and these snapshots collectively represent your project’s version history. The list of commits forms a timeline view of the life of your project – you can see exactly what you did on a certain day, how much progress you made at each step, etc. just by browsing through the commit history. Spend some time to practice and understand commits before you move on to the more advanced concepts in Git.
Lastly, this tutorial covers how to use the GUI client, which is usually enough for the most basic version control needs of the absolute beginner. It is good to be aware that Commit is a native command in Git and can be executed through the command line. If you’re curious how to use the command line or want more in-depth information on the inner workings of Git, you can read about commits on the official Git Book or check out the excellent Git Basics tutorial from Atlassian (hint: read about both the add and commit commands).
So you’ve got commits down pat. You’ve successfully tracked the completion of a minor feature of your project with commits. You’ve worked out this muscle memory system to commit after every few changes. You dream about the Stage and the little GitHub cat. During the day, too. You’re no longer afraid of commitment. You’re thinking, “Is this all there is to life – I mean, Git?”
Well, like I said earlier, Commits are “snapshots” of your project at certain points in time. When you commit several changes and then realize one of those changes broke what was previously working code, don’t you wish you had some kind of “Undo” button? Enter Revert and Roll Back, the “Undo” buttons of Git.