What is Git?
Git is a version control tool that is used to maintain a continuous set of copies of file(s), with each of these copies having different content built on top of previous content.
In the above diagram, we see a file who’s content keeps changing as time progresses, thereby creating different versions of a file from 1 to 4.
Why do we use Git?
If we were working on such a file on our computer, and we are creating its content for the first time, chances are we will write some content, think for a bit and then decide to back and edit some previous content again, get back and continue and so on.
As a result, what we normally tend to do is to keep saving the file at different point in time with different names, there by ending with a set of files that looks like this:
Do you see a problem here?!
Git or any version control for that matter is used to avoid exactly this problem!
Getting started with Git
Git is a version control tool created by Linus Torvalds, the creator of open source operating system Linux. He had initially created this tool as a way to do version controlling specifically for Linux Kernel files, but as the tool grew in popularity – mainly for its simplicity and distributed nature, it was soon adapted by all software engineering domains at large.
What do you mean by Git being a distributed system?
Yes, Git is a distributed version control system. What we mean by it is that the entire set of copies of different versions of files and directories are not stored in a single central server but is made available to everyone of its git users as a local copy saved onto their own laptops/computers. So this way, even if you lose one system from working due to any technical issues, you will not loose the entire Git repo (as it could happen in case of a central server) as it will still be available by all of its Git users who will have a copy of it!
Alright enough discussion on the theory of Git, let us go for some hands-on exercises to better understand how Git works and how you could use in your everyday coding activities.
Hands On With Git – Just Tell Me What To Do!
The first thing that needs to be done to getting started with Git is to install the tool itself. Depending on the type of OS you are running on your system, you need to install Git using appropriate executable file from the GitHub Official Page.
Once you have installed your Git tool, you will be able to run Git commands. To ensure its installed correctly, issue the following command that checks the installed Git tool’s version:
If it responded back with a string as shown below, you are all good:
git version 2.7.4
We can now start using our Git tool and start working on a real Git repository. For this tutorial, we will make use of a Git Repo that I have created in Github.com. Github.com is a popular public Git repo hosting website where users can create unlimited number of Git repositories.
First step is to clone the Git repository I have on Github called Hands-On-Git.
What is Git Cloning?
Git cloning is a process of pulling a copy of Git repository from a hosted Git server onto your local computer. This is done by using the command Git Clone
In our example, issue the following Git clone command:
git clone https://github.com/digitallyamar/Hands-On-Git.git
Wait a second, how did we get that url? Well it so happens that for every repo stored on Github, Github website provides the url of the Git repo that is to be used to clone the repo. This is demonstrated in the GIF below:
After issuing the above git clone command, you should see an output resembling this:
With this, you now have an exact clone of Hands-On-Git repository as available on my Github repo.
What is Git branch?
Every file that you push or pull from git repo will be stored under a specific branch called Git branch. By default, all files are stored under a branch called the “master” branch. However, if you want to work on a separate feature of your code base and not sure if it will break anything that is already working currently, you can continue developing that feature on a separate branch.
Only after completing the development of said feature and ensuring all tests are passing, you can “merge” back this feature to the master branch.
This way, all others who are working with the same Git repository are not impacted by your code changes until you have finished developing and validating it. And after that, you can send the Git maintainer a “Pull Request” to pull your changes to the “master” branch.
Let us demonstrate each of these steps now. First, check and ensure you are currently in the master branch. You can do so by issuing the following command:
cd Hands-On-Git git branch
You should see Git replying back with the name of the branch – “*master” in this case as show below:
The * before the reply “master” indicates the current branch you are on. As there is only one branch, you will see *master. But if there are more than one branch as will be demonstrated further, it will list all available branches and the branch which has * in front of it indicates the branch you are currently on.
How to create a new Git branch?
In order to create a new git branch, all you have to do is to issue the following command:
git branch MyCoolBranch
This should now have created a new branch called “MyCoolBranch”. But how do you verify it? You once again, issue “git branch” command:
This should now list you all available branches, which, in this case happens to be 2 – master branch and MyCoolBranch.
As you can see from the above GIF, we have successfully created a new Git branch “MyCoolBranch”. However, did you notice that we are still in master branch (asterisk * is still pointing to master)? That is because we have just created a new branch but not “branched” or “checked out” to that branch.
How to switch to another Git branch?
In order to switch to a new Git branch, we need to issue another command called “git checkout <branchName>“. So in our case, in order to checkout to “MyCoolBranch”, we need to issue the following Git command:
git checkout MyCoolBranch
This should now switch us over to the newly created MyCoolBranch. We can verify it, again, using the command:
This time, we can see that the asterisk * has moved to our newly created branch MyCoolBranch, confirming that we are now in our new branch.
Now that we are in our newly created branch, we can do whatever changes we want to do without affecting anyone else’s code.
Let us now edit the file present in our git repo – the README file. I will just add my name to this file using my favorite text editor and save it.
Once we have edited the file, our Git repo is no more clean as it has some changes that is yet to be tracked by our Git repo. So we need to add and commit the changes done to this file for the Git repo to go back to clean state. In other words, we need to update our Git repo to include the changes we have done.
What is Git Staging and Git Commit?
Adding changes to Git repo happens in two different stages which Git conveniently calls them as Git Staging and Git Commit.
In a Git staging process, we first need to add the file to the Git repo’s staging level and then do a commit on all the staged files with an appropriate Git commit message explaining what these changes are doing to the repo code base.
Git staging is achieved using the command:
git add <Filename>
If no file name is specified in the above command, all files that have been changed will be staged by the Git tool.
In the below GIF, we can see how we did the first step of the two steps process – Git staging:
Now that the file has been Git staged, it is time to commit the file to our Git repository. This is achieved using the command:
git commit -m <Message explaining the commited changes>
Following GIF shows the Git commit process. It also introduces a new command:
Git log is a command that is used by Git users to read all the commit messages that each of the git commit carries. This way, we know who did what changes to the Git repository!
What is Git Push command?
So now we have our changes committed to Git repository. However we still have one more thing to do. All our changes and commits were done locally on our laptop’s Git repo. But we want these changes to be made available to all. To do that, we need to push our changes back to Github’s repository. We can do so using another git command:
However, since we have now created a new branch “MyCoolBranch” where we had created all our changes, we cannot simply use the “git push” command. That is because we do not have this branch in the Original Github repository. So, we need to add some additional parameters to the above git push command:
git push origin MyGitBranch
Here we notice two new parameters – origin and MyGitBranch. While we understand that MyGitBranch was the name of the branch from which we are pushing our changes, what does origin stand for?
Well, it so happens that origin is the term used to represent the remote Github’s repository! So with this, we can now push the changes to our Github remote repository as shown in the GIF below:
Now that we have successfully pushed our local changes to Github remote repository, we should see the push reflected on our Github repository page as well:
What is a Git Pull Request?
Now that we have pushed our changes to Github remote repository, it appears in Github page as shown in the GIF above.
We can now create a Git Pull Request to the maintainer of the Git repository.
Git Pull Request is a request made to the maintainer of a Git repository to merge our changes to the original repository’s master branch.
After raising such a request, a notification is automatically sent to the Git Repo maintainer to perform a “merge” of the Pull request.
Now, the maintainer of the Git repository can merge the Pull request if he is satisfied with your Pull Request changes!
That is it! You have successfully performed an entire flow of git operations starting from Git clone, Git branch, edit file, Git Add (to stage the changes), Git commit, Git push and finally raise a Pull Request for the Github maintainer to merge your Git Pull Request (PR).
Hope this article was useful to you in understanding how Git works.
You can replicate these steps and submit your PRs to the same example Repo (Hands-On-Git) above and I will be happy to merge your requests. 🙂
If you have any queries regarding this article or get stuck anywhere, do not hesitate to ask me about it in the comment section below.
Until next time, so long and happy coding! 🙂