Any junior developer getting started might have heard of Git. But if you feel weary whenever you are required to work with git, this article might be of help to you. I have tried to cover most of the commonly used basic git commands that will help you get started.
So, without further ado, let’s get started…
What is Git?
Git is a free and open-source distributed version control system designed for speedy and efficient source code management.
In fact, git can be used to track changes on any file, so hypothetically, we can even track changes, and create versions of any document.
Some of the benefits of using Git are:
- Gives us the ability to track history of changes made since we started working on the project.
- Git supports non-linear development, which means that we can start working on several different versions of the project simultaneously without worrying about the changes interfering with each other.
Here is the link to the official git website…
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion…git-scm.com
Wait, then what is GitHub?
Git is a version control system that lets us manage and keep track of our source code history locally on our local storage.
But, GitHub is a cloud-based service that lets us manage our git repositories (projects). Via GitHub, we can store our local git projects on the cloud.
Let’s talk about some of the basic, and fundamental git concepts and commands. You will be using these commands almost every time you use git.
Initializing a Git Repository
To use git on a project, we need to first define the project as a git repository. This is known as initializing a git repository. To initialize:
- We will first move to the project folder in the terminal.
- Type the command “git init” to initialize the project as a git repository.
Let’s create a project folder. As shown in the screenshot above, we created a folder named Temp. Then we move inside the project folder, and we type in the git init command. We receive a message which says Initialized empty git repository in /home/skuchibhotla/Projects/SMT/Temp/.git/. This indicates that our project folder Temp is now a git repository.
By performing this operation, we see that git adds several hidden folders. The history will now be saved in the .git folder. Any change made in this folder, like adding a file, updating a file, or deleting a file, will be tracked by git.
Now let’s try to make changes in our project and see how git handles these changes.
Working with changes — Adding changes
Currently, our project is empty. Let’s add a file called cars_makers.txt, and to this file let’s add some text.
To see a list of all the files we have made changes in, git has a command: git status. By typing in this command in the terminal, we see cars_makers.txt file of ours is marked as modified.
Untracked files are files that have not been staged. In other words, these are the files that are new and are not present in the latest version of the project that git has.
To save, or maintain our changes, we have to first prepare these changes. Just because a file is modified, it does not mean that it will automatically be saved by git. We have to let git know specifically which changes to save. This is done by adding a change to the “Staging” area. This process is known as ‘Staging the changes”. To do this, we use the git command: git add.
The period . after git add indicates that we are adding all the changes to the staging area. To add individual files to the staging area, we can type the name of the file instead. git add <file_name>. Like this:
git add cars_makers.txt
Now, if we type the git status command to see the changes, we see the cars_makers.txt file is now staged as it is marked under the Changes to be committed section.
git restore command is used to remove the latest changes.
To remove all untracked files: git restore .
To remove a specific untracked file: git restore <file_name>
To remove all staged files: git restore –staged .
To remove a specific staged file: git restore –staged <file_name>
By specifying –staged, we are letting git know to look only for staged changes.
To remove and delete all untracked files that were created as part of the changes: git clean -fd .
To remove and delete a specific untracked file: git clean -fd <file_name>
Here are some examples of how these commands can be used:
Creating a commit
So far, we have seen how changes, and untracked changes are tracked and marked by git, and we have seen how to add them to the staged area before they can be saved. Let’s now look at how we can save these staged changes to git.
The act of saving the staged changes to the project version is known as “Committing the changes”. The command “git commit” captures a snapshot of the project’s currently staged changes. Committed snapshots are saved by git, and will not be deleted unless we specifically ask git to do so.
To create a commit, we can type in the git commit command in the following way:
git commit -m “<message_text>”
We can type in a short message_text to describe the changes that we are currently saving as part of this commit. An example of this is shown in the following screenshot:
Viewing commit history
Changes made to a project are saved like a stack, where the latest changes are saved on top of the most recent changes made to the project.
We can view a log of all the changes (commits) made so far to the project by using the command “git log”.
In the above screenshot, the top-most commit is the latest commit that has been made to the project, and the commits are arranged in descending order chronologically with the first/initial commit at the bottom of the list.
Each commit is uniquely identified by a unique id called hash (since it is generated by running the changes through a pseudo-random number generator called a hash function).
Removing a commit
To remove a commit, we use the “git reset” command. This command resets the HEAD to a specific state.
HEAD in git is a pointer to the last commit that was checked-out.
There are 3 variants of git reset, –soft, –mixed, and –hard. The difference is mainly if the index is modified during the reset operation, or not.
index in git is a critical data structure. It serves as the “staging area” between the files we have on our filesystem, and our commit history. When we run the git add command, the files from our working directory are hashed and stored as objects in the index, leading them to be “staged changes”.
git reset –soft <commit_hash> resets the project to the given commit_hash, but the index still has changes from the commit HEAD was pointing to earlier. The changes will be in a staged state.
git reset –mixed <commit_hash> resets the project to the given commit_hash, but the index is also modified during the process. The changes will be in an untracked state.
git reset –hard <commit_hash> resets the project to the given <commit_hash>, however the changes that were added are permanently deleted.
Here is a screenshot that shows the difference between these 3 variants clearly:
“git revert” is another git command that helps us undo changes made under a commit. It technically does not undo, or remove a commit, but it makes a new commit, with the changes that were made removed. It is a safer method of undoing changes compared to git reset in regards to losing work.
git revert <commit_hash> will add a new commit with the changes made under commit with hash <commit_hash>. Here is an example:
In the above screenshot, we see that git added a new commit “Revert “Removing Ferrari from cars_makers.txt”” upon running git revert on the latest commit I had on my project.
Stashing a commit
We can use the “git stash” command when we want to record the current state of the working directory and the index, but want to go back to a clean state of the working directory.
This command usually comes in handy when we want to temporarily save what we have done so far on the working directory, but not lose those changes permanently since we want to access/use them later.
The command “git stash” saves our local changes and reverts the working directory to match the HEAD commit.
To stash the changes, we use the command: git stash.
To get the stashed changes back, we use the command “git stash pop”.
git stash works like a stack data structure, and stores, or stashes the changes on top of the other changes that might have been stashed earlier.
To clear the stash, we use the command “git stash clear”.
What are Branches?
A branch in git is a new and separate version of the repository where we can make our changes, which will not interfere with the master branch until they are merged.
The branches are effectively a pointer to a snapshot of our changes. When we want to add a new feature or fix a bug, we spawn a new branch to create the changes.
This new branch will contain all the new changes that we make as part of this new feature or bug-fix, and keep them separate from the other branches until we decide to add these changes to them. In this way, we will be able to run and test these new changes without worrying about breaking the actual code on the master branch.
To create a new branch,
git checkout -b <branch_name>
And to navigate to this newly created branch,
git checkout <branch_name>
To view all the branches we have created locally so far, we can type in the following command:
The * in front of a branch indicates the branch that we have currently checked-out.
Working with branches
To understand how branches work in git, let’s look at the following screenshot:
In the above screenshot,
- We started off with commit C0. The commits C0, C1, C2, and C3 were made on the main branch.
- At commit C3, we created and checked-out a new branch called feature.
- We made commits C4 and C5 on the feature branch, and we see that as of now, these commits are not on the main branch.
- Meanwhile, commits C6 and C7 were made on the main branch.
- At this point, we merge our changes with the main branch.
These were some of the basic git commands that will help any developer get started with git. There are a lot more commands such as git blame, git cherry-pick, and git rebase that are a bit more advanced which usually help us a lot when we are working with existing repositories.
We truly feel the power of git when we use a cloud-based service like GitHub where we can store, manage, and track changes on existing projects that might belong to others.