It was during my first project when I came to know about version control system (VCS). Since then, I wanted to utilize it. I wanted to learn git and i wanted to learn it FAST. But unfortunately, the blogs/tutorials I found online were either too lengthy or too concise for me, and eventually my impatience costed me more time. However, during semester break, I could finally learn git and master its basics.
Now, if you are like me — impatient to learn how to utilize most of git in least amount of time, this article should help you. After going through this article, you’ll be able to utilize the most basic and important functionality of git: ‘maintaining version locally’ i.e. you can maintain different version of your project locally in a folder of your computer.
But before we begin..
.. it is important to get a clear picture of how git operates on a project folder.
Usually, we keep all of our project files in a single folder. Let’s address this folder as ‘Working Directory’. Now, let’s say we have an html file in our working directory named ‘page1.html’ and we modify that file. And now, we want to save the current state (or version) of the file. In git, saving a version this way is called ‘commit’. We can commit all our project files whenever we need. And we can switch back to any of our previously saved (or committed) version whenever we need from whatever state our project is in.
However, in git, we can’t commit the modified file directly. It needs to be prepared first. And this step is termed as ‘stage’. You can learn more about staging files here.
So what happens when we commit (save the version) the file? Before we commit, we stage the file and when we do that, git takes a snapshot (not literally) of the changes made. After we commit, git stores the snapshot in a secured folder and also generates a hash code.
Afterwards, git uses this snapshot and hash code to revert the current file back to any of its previously committed versions. Now, all we need to do is enter the right command in right way.
And this two step commit has got some advantages which will be discussed later in this article.
These basics are enough for now but you can browse more here.
Now! Time to get hands dirty..
As we have idea about how git works, we can now confidently dive into it.
First, we need to download and install git. While installing, don’t get intimidated with configuration as you can change them later anytime.
After that, you need to configure the username and email. This step is very important. To do this, open git and in the windows, type $ git config — global user.name ‘your-name’ and $ git config — global user.emailyour.email@example.com. Check the screenshot below:
Both user.name and user.email are variables used by git. To check the value of any such variables, hit ‘$ git config <variable name> like I did in the screenshot.
Also, you can see all the values of config variables using the command ‘$ git config -l’. Learn more about configuration here.
if you are stuck with command line at any step, check this post
Creating a repository
Repository is the place where git stores metadata required for its operations. For the sake of simplicity, we can assume it to be a local folder for now.
Let’s work on a simple html project and use version control on it. I’ve already created a folder named ‘blogpage’ and I want to save all the project files here. After that I’ve created ‘page1.html’ and saved it in this folder.
Now, ‘blogpage’ is unlike any other folder and none of its files is under VCS. To bring the files under version control we need to -
- open git-bash
- set the project-folder’s path as the working directory
- type the command “$ git init”
As we can see, the full path to my project folder is “F:\projects\blogpage”. So, I open git-bash and type $ cd /f/projects/blogpage and hit enter to set this path as the working directory. Then I type $ git init. This creates a repository and we get something like the following:
We can know the current state of the repository using the command $ git status. Let’s try this out!
That’s a lot of data on current status of repository! Let’s go through them!
So, first line — ‘On branch master’
Okay, so what does this mean?
It means that we are currently in a ‘branch’ named ‘master’. ‘Branch’ is an important concept in git. Briefly, it can be referred to as a pointer to commits. A repository can have one or more branches and ‘master’ is the main branch. Since we need only one branch right now, I want to discuss more about branching in later post.
Now, let’s move on to next line — ‘No commits yet’.
It’s obvious! We have just created a repository and made no commit, and hence the message.
Okay, the next line is interesting because we get to know about a new term — ‘untracked files’. So, what does it mean?
By default, git keeps an eye on all files in the working directory, but does not keep any file under version control. So, we need to put the files manually under VCS. And after it is done, git can ‘track’ it. The syntax of command to add a file is simple — ‘$ git add <file name>’.
However, the command $ git add is not only used to put the file under version control, but also to stage the file before we commit.
Adding/Staging file to repository
To add the file, let’s head over to the git-bash console and type $ git add page1.html. After that, let’s check the status of the repository.
As we can see at the bottom of the screenshot, git is recognizing ‘page1.html’ as a new file and through the message ‘Changes to be committed:’ it is letting us know that we are ready to commit the file i.e. the file is not only added but also staged.
Commit
As the file is staged, we are ready to commit (save the version). While committing, we need to add a short commit message. It is a better practice to include summary of the change in one line in the commit message. The syntax of the commit command is: $ git commit -m <commit message>. So, to commit the file, we need to enter the command $ git commit -m ‘initial commit’ . After that we should get something like the following screenshot:
As we can see, after the operation is successful, the console displays information about the commit. After each commit, git will display data like in which branch the commit is done, the commit message, number of changed files, number of new lines, deleted lines, the hash code etc.
More stage and commit
The file ‘page1.html’ currently looks like this —
Let’s bring some modification to the file.
This will bring change to the status of the repository. Let’s check it out using the $ git status command
Whenever we make a change in our project files, we get messages like this. Now, let’s add the file and then make more changes like the following.
The whole point of proceeding this way is to clarify the concept related to staging. Let’s check the status of the repository again.
As we can see, git is telling that ‘page1.html’ is staged and ready to commit. But it is also telling that ‘page1.html’ has not been staged yet. Why so?
Well, after adding ‘Hello World’ we staged page1.html. But before committing, we also added the line ‘Let’s hack NASA using HTML’. And now, if we commit, git will only add the snapshot where ‘Hello World’ was added. But it won’t recognize the addition of ‘Let’s hack NASA using HTML’. And that’s how staging has an influence on commit.
And this gives us advantages! This allows one to control which portion to commit, continue working without breaking the build and many more.
Revert to the previous version
We’ve been doing commits so that if things get messed up, we can undo the changes and return to the version where things worked perfectly. And we can do so using the $ git checkout command. The full syntax of the command is
$ git checkout <hash of the desired commit> <file1 to restore> <file2 to restore>….
Let’s revert ‘page1.html’ to our initial commit where it contained only the basic html tags. And for that we need the hash code of our initial commit. This leads us to get introduced to a new command - $ git log.
[NOTE: in case you struggle with command line, check this post]
Entering this command provides us with list of all the commits done, along with hash code of the commit, person who did the commit, time, and lastly the commit message. Now that we have the hash code, we can use it to enter the checkout command. In my case, it should be — ‘$ git checkout 4be7c8f64248dd5e47014e1ac459fa3a4c6cad96 page1.html’
Great! Now let’s check our file.
Awesome! The file is now back to its initial condition — no ‘Hello World’, no hack NASA and no title! We can now start everything from scratch.
Congratulations!
If you have completed all the previous tasks, you are now able to
- configure git [$ git config]
- create a repository [$ git init]
- add and stage files in repository [$ git add]
- view status of repository [$ git status]
- commit changes [$ git commit]
- view commit history [$ git log]
- switch program files into its previous state [$ git checkout]
However, I haven’t covered other basic and helpful topics in this post. I haven’t discussed about cloning repository, branching, removing files and ignoring files using gitignore. Although you can control versions of simple projects without these now, in later stage you will encounter situations where you’ll be needing these.
And so I recommend the book ‘Pro Git’ by Scott Chacon and Ben Straub which covers all the core topics. Also, git has their own documentation from where you can find the details of a topic or command.
Lastly, I’ll be elated if this article helps you. If you find any portion of this article confusing, feel free to respond.
