Getting Started with Git
Things that you should know before getting started with Git
Have you ever wondered what Git is, what it does, why you should know about it, and how to get started with it? This tutorial will try to clear all such doubts that you have while you are getting started with Git.
What is Git?
From Git’s official website:
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
About Version Control
What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control.
If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
So, imagine you are working in an organisation with 100 people and all the developers have a copy of the project on their local system. Now, if a developer who is also your friend, let’s call him Jim, introduces a change in the codebase and tells you about it because you are his friend, the project with new commits will only be stored in Jim’s local machine and you as a developer will have to copy Jim’s local project to your system through some means. Situation becomes worse when more than one change is introduced by more than one developer at the same time and that is when using a VCS becomes more like a necessity than luxury. If your organisation is using any version control system, and if Jim makes any change to the codebase, you along with other developers will find out instantly. It will be easier to update the project till the latest commit and also revert back to any particular commit.
Getting Started with Git
Step 1: Installing Git
Step 2: Configuring Git
It is important to set up some basic information like name and email before using git, so you always know which change was made by whom.
You can set up your user name by running the following command:
And run the following command to set up your email:
You can check your configuration settings by running the following command and it should return your username and email respectively.
Basic Git Commands
Now that we have basic knowledge of what Git does and we have it installed on our system, let’s start using it.
It initialises Git in any repository on your machine. This includes adding all existing files to the index, setting up the config files, creating a new folder for Git inside the project folder etc. This command can be run inside any repository where Git has not already been set up.
git status inside your project repository will display names of all the files which are staged or not staged for committing and files that are untracked by Git. It does this on the basis of changes made in the files. Running
git status for the first time in our project folder gives us the following output.
git add in your project repository adds file contents to the index. What that means is that the changes made in any of the files will now be staged for the next commit.
git add can also be used to track the untracked files, like in the following example.
In the above example, running
git add “index.html” “events.html” “contacts.html” stages index.html, events.html and contacts.html. Then running
git status shows a summary of staged and untracked files. Alternatively, you can also run
git add . to stage all files at once for the next commit.
A commit is like a checkpoint for any repository. On running
git commit , all changes made in the repository upto that point are recorded. And you could always revert back to a particular commit or see the changes between commits. A commit in Git also asks you for a commit message, as it will help you later understand why you made that commit.
As you can see in the above example, on running
git commit -m “First Commit” , three files namely index.html, events.html and contact.html were committed with a commit message First Commit.
git log inside your project repository will display last few commits that have been made to the repository along with the details of the user who made that commit, the commit message, location in the working tree where the commit was made, when it was made etc.
While you are working on any project, there might be a point say where you want to try adding new features to your already awesome project. Now if you do it in the main project repository, you might introduce new bugs and that might affect the performance of your original project.
So what if you create a copy of your project at some point in a way that your original project doesn’t get affected, and you can still keep experimenting, all within the same directory. That’s exactly what
git branch offers.
We first create a new branch newbranch in our project repository by running
git branch newbranch.
git branch -v displays all the branch associated with the project along with last commit and commit message. As it is visible in the example above when we run
git branch -v for the first time, it displays the same commit for both branches. Then we switch branch by using
git checkout newbranch , make a new commit to the branch and run
git branch -v again, but this time the last commit on the two branches are different.
As it is shown in the example above, we first run
git checkout master to switch to branch master. Then we run
git checkout -b newerbranch to create and switch to a new branch named newerbranch. Since, we branched from master branch, the last commit on our branch newerbranch is same as that on branch master.
What if after you have made a few commits on a new branch, you want to add those changes to your original project as well? That’s where
git merge comes to help.
Here in the example, we first check the last commits on each branch and then switch to branch master. After switching to branch master, we run
git merge newbranch which merges branch newbranch on the top of branch master. On running
git branch -v again, it can be clearly seen that last commit on branch master is same as that on branch newbranch.
When you are working in large teams, most of the times your project is going to be hosted at some remote repository, from where it is going to be accessible to everyone working on the project including you. In such a situation, you will have to work with a copy of the original project on your local machine and push changes on the server. For those situations,
git remote stores the address of the remote repository, to help you push or pull changes faster.
While working with remote repositories, you are not the only one who can make commits to the project. When you are the one who makes a commit and wants to update the remote repository, running
git push does it for you. It compares the difference in commits and then pushes your code to the remote repository.
In the example here, we first display the names of all branches after adding the remote origin. Then we push the branch master of our local project to the remote repository by running
git push origin master. And finally, we display the names of all branches again. We see a new branch added because our GitHub repository was empty initially and after we push changes to GitHub, it creates a new branch master in our GitHub repo and accommodates changes of local branch master into the remote branch master. One thing to note here is that, this is how all remote repositories are treated by Git, that is, in form of branches. It should also be noted that at this point our remote repository has only one branch.
Now let’s consider, that any of your co-worker makes a commit to the project repository, you might have to update the local copy of project with remote repo. Running
git pull in those situations, fetches all new changes from your remote repository and merges them with your local copy of the project. In other words,
git pull performs
git fetch and
git merge simultaneously.
Here in the example, we first display names of all branches along with their last commit. Then we pull changes from branch master from remote origin and merge them with our local branch master. And finally on displaying names of all branches again, we see the new commit (or a series of commits) that was made to our remote repository by some other developer and those changes have now been merged with our local repository.
Here in this tutorial, we created a new empty repository on GitHub and were the first one to make commits to the remote repo. But that might not be the case with most projects. Instead, you might have to download and run projects which already have many developers associated with them. In such a situation, we can run
git clone inside the repository where we want to copy a remote repository on our local machine.
git clone downloads the remote repository till the latest commit, adds remote for the URL and unpacks objects in the same format.
Git is an extremely powerful tool and is used by organisations all around the world. If you have made till the end of the tutorial, I hope you were able to learn enough about why you need Git and basic Git commands that will help you get started instantly. I hope this tutorial serves its purpose.
Please comment below if there’s anything that I wasn’t able to explain clearly or if there’s something you would want to know more about.
Feedback and criticism is more than welcome.
Disclaimer: Git is an extremely powerful tool and is used by all types of software engineers and organisations all around the world. This tutorial has been written as an attempt to make Git a little more accessible and to clear very simple doubts of people those who are absolute beginners with VCS and thus misses out on a lot of other great/cool/magical but complex parts of Git.