A Simple Introduction to Git.

It’s a common misconception that Git is only meant to be used by programmers, but the truth is that it is a versatile tool that can be utilized by people from all walks of life. In this post I shall give you an insight as to why Git is essential, why it can be confusing, and most importantly, as to how you can leverage it.

But before we begin using Git, let us understand why we might need to use it in the first place. Sure, it as an essential tool in a developer’s toolkit, but the reasoning behind the usage of Git has to be more than just that it’s a popular tool, right?

An analogy that helped me understand the need for Git was that of snapshots. Imagine that you have started building a personal project. It is something that you have wanted to build since a long time. Eventually you notice that there is more than one way to implement a feature in your project. So you choose one of these ways and trudge along. A week into the development process, you realize that certain decisions in the project’s past are hampering some new features. So you just go back to the problematic section of the project and fix it! A few more days pass by, and your project is nearing its completion. Alas, you run into some more design bugs! This time you notice that there isn’t a simple fix, because this bug is a culmination of a series of flaws in the project.

You start contemplating your options. Do you go back and re-design every problematic aspect of the project, meanwhile risking some unnoticed side-effects? Do you ask for help online? Do you scrap the project? Can you just ctrl+z your way to the point where you wrote the buggy line?

This can seem like a contrived example, but it is a scenario that every developer has faced at some point! In fact, Linus Torvalds has even said that he created Git just to maintain the slightly bigger project he happened to be working on.

This is where you realize the importance of a version control software like Git. As the name suggests, it is something that helps you keep track of the different versions of your project. This is where the analogy of snapshots comes in. Using Git is like maintaining an album filled with snapshots of your work. It makes it easier to pinpoint bugs, because it has a recorded history of all the work that you put in while building the project.

Git has features which also helps a team of people collaborate. If you want to imagine a scenario wherein Git can actually save your life, then revisit the example I gave a little while ago. But instead of you being the only one who is stuck with buggy code, it is an entire team of 10/100/1000 with all of them working on different parts of the project! Calling this situation a nightmare would be an understatement!

---

Now that we know Git can save us from mental breakdowns, let’s get started with the workflow involved!

The acronym to remember is ISAC. Let me explain.

In order to get started it’s important that you have a working knowledge of a command line interpreter or a CLI. If not, then read the following paragraph to get started with a CLI of your choice. In case you have never used a CLI before, it is just an interface for you to give some commands/instructions to your computer.

On a MAC machine, search for the program named Terminal.
On an Ubuntu machine, press Ctrl+Alt+T.
Once you open the Terminal, you will need to install git from here.
On a Windows machine, I would suggest that you go here and download a CLI called the git bash.

Verify the git installation by typing git --version in your CLI. It should return a number indicating the version of git.

---

Once you have opened a CLI, navigate to the folder where you want to save your project files, using the cd command as required. Once you are in the root (main) directory of your project (which is yet to be started), you can start with the git workflow using the acronym I mentioned earlier.

In order to allow Git to store snapshots of your code, you need to create an empty, local repository. Think of it like creating an empty backup folder. You do this by typing git init . You should see the text (master) alongside your file pathname, once you execute this command.

If you type ls -a you should see a file called .git, which will now act as you local repo — short for repository.

Now, you can go ahead and create all the files that you need to build your project. Note that the development procedure you follow to build a project is unaffected by the addition of Git to the picture. Once you have created some files in the folder that the git repo was initialized in, go ahead and type git status in your CLI.

You should see statements similar to the one below:

Example for message returned after typing ‘git status’

This message indicates that there are untracked files in our git repository. This just means that the files are not ready to be added to our local git repository yet. In order to continue with our git workflow, we will need to use another git command.

This is where things can get a little tricky to understand, because Git doesn’t directly store our files in a local repository. Instead, it allows the user to add these files to a staging area. “Why?” , you may ask. It is because we might have some local files, that we do not want to store in the local git repository, another reason might be to allow us to split our commits into logical sections rather than it being a block of unrelated changes. If you found this difficult to understand, then refer the first answer to this query on stackoverflow.

In short, when you see that you have untracked files, you need to type the following command to add those files to the staging area
git add <path/filename> or if you want to add all the files at once, type git add .

If you type git status again, you will see a different message!

git status after adding our files to the staging area

Note that if you make changes to any of your files, after you add them to the staging area, then it will have to be added again, because the version of the file in the staging area is no longer the same file in our local environment.

The next step is to transfer the files from the staging area to the local repository. In order to do that, type the following command
git commit <path/filename> -m "a message regarding this commit"
This is where we meet a new Git feature called Commit Messages(Note the -m). They are succinct messages which convey information regarding the files that are being committed.

To understand the importance of these messages, imagine that a year has passed since the time you have finished a project. You decide to go back to it and see the code for the project. Or, more realistically, suppose a team member has to get familiarized with your codebase. In these cases, in order to make sense of why certain changes were made in the files, you will rely on these commit messages, because you no longer have the context for the code you had written.

If you want to commit all the files in the staging area at once, then type the following command
git commit -m "<commit message>"

Since commit messages are so crucial for code maintenance, here are some tips for writing good commit messages:

• Type it in present tense, for example Make foo do something , rather than in past tense like Made foo do something

• Be concise. Add style to the form is better than Add style to make the form look better and also added a new background color to the submit button

---

This is what the most basic Git workflow looks like. It’s that simple! Just remember the following commands: Init, Status, Add, Commit.
In order to have a rough overview of the various aspects in Git, see the following image

The workflow that I have mentioned up until now, is the most basic workflow one can follow in order to use Git. But when Git is to be used for collaboration purposes, it is often the case then we need to merge branches, send/accept pull requests, fetch files from another Git repo, checkout a previous version of the project, push our files to a remote repo provided by Github(alternatives include Gitlab, Bitbucket), pull files from the remote repo, clone another user’s remote repo, and so on. But since all these commands are easier to grasp once you have an understanding about the basics of Git, I shall provide resources for you to learn these topics once you feel like you have grasped what Git does.

These are some of the best resources I found:

If you feel like a video tutorial would help you better understand these concepts then checkout this playlist

Lastly, another reason to start using Git is that you can contribute to open source. One of the main reasons why Git is as popular as it is, is the fact that it has allowed hundreds and thousands of developers to collaborate. Hence it is not too much of a stretch to claim that Git is the foundation for all Open Source Software.