Top 5 Git concepts important for interview

Every developer must have this one essential skill. Can you guess? That’s Git. Git is a crucial skill to understand regardless of our development area.

Git is a version control system (VCS) developed by Linus Torvalds, the same person who created the Linux Kernel. It got released in 2005 as open-source software. Git keeps track of the changes or modifications we make to files so we can see the history of the changes or alterations and roll back to earlier versions if needed. Git also facilitates cooperation by merging several contributors’ changes into a single repository.

Today we’ll go through the TOP 5 Git/GitHub fundamentals that are the most helpful and can significantly increase your productivity and aid you in interviews. Before we proceed, we want you to be comfortable with the fundamentals of Git, such as staging changes and creating commits, etc.

Updating the last commit

Sometimes, we may forget to stage all the fills or use the incorrect commit message in our most recent commit. Also, in some situations, we want to incorporate more changes after committing. A simple solution that most people use to solve issues like not staging all the files or adding extra changes after committing is to create a new commit with the necessary adjustments. However, this approach can still not correct the latest commit’s incorrect commit message.

A better approach to address these issues would be to use the --amend flag. We use the --amend flag while creating a new commit. The --amend flag updates the latest commit with the latest changes. Using the flag, we can also change the commit message of the most recent commit.

Consider the demo project having a single file index.js having the following contents:

function x() {
  console.log('x');
}

function y() {
  console.log('y');
}Code language: JavaScript (javascript)

It is initialized as a Git repository and contains two commits.

Let’s add another function named ‘z’ and commit the changes.

function z() {
  console.log('z');
}Code language: JavaScript (javascript)

# stage all the changes
git add .

# create a commit
git commit -m "added function w"Code language: Bash (bash)

We have created a commit. To verify, we can log all the commits.

Oh wait! we made an error with the commit message. Not to worry, we can fix it by using the amend flag. We will update the commit message using the amend flag by writing the following command to update the previous commit.

git commit --amend -m "added function z"Code language: Bash (bash)

We will see the updated commit message if we log the commits again.

We can do the same for updating the latest commit with some additional modifications.

Reset to the previous state

Let’s say that the code we wrote earlier contains some mistakes causing it not to function properly. We also know that the code was working correctly before, which means the problem was raised in the most recent commit. We must delete the problematic code from the file to fix the error. Since we don’t know what part of the code is causing the issue, we only have a solution, i.e., to roll back to the previous commit. In this situation, we use the git reset command. We can restore some earlier versions of our project using git reset.

There are three types of resetting modes:

1. Soft mode
2. Mixed mode
3. Hard mode

Let us look at them one by one.

Soft mode

Soft mode rollbacks to the specified commit. Also, it won’t change the staging area (or the index) and the files we were working on (or the working tree).

We may understand this with the help of a diagram.

If we run git status, we see some staged changes that are ready to be committed. It is happening because our files and the staging area were not affected.

To perform a soft reset, we use the following command.

git reset --soft <commit-hash>Code language: Bash (bash)

If we log the commit history, we see three commits.

Let us roll back to the second commit by using the following command.

git reset --soft d372675Code language: Bash (bash)

Logging the commit history, we see that there are only two commits. That means we have successfully performed a soft reset. However, we have preserved our files, uncommitted, and staged changes using the soft mode reset.

Mixed mode

Mixed mode rollbacks to the specified commit. Also, it won’t change the files we were working on. But it changes the staging area. It means Git rollbacks to the specified commit and will un-stage all the staged changes.

We may understand this with the help of a diagram.

If we run git status, we see some unstaged changes. It happened because Git didn’t change our files, but all the changes were unstaged.

Let’s roll back to the second commit using the mixed mode reset again. We will use the following command.

git reset --mixed d372675Code language: Bash (bash)

Logging the commit history, we see that there are only two commits. That means we have successfully performed a mixed reset. Changes that were there in the second commit will be unstaged. However, we have preserved our files and the uncommitted changes using the mixed mode reset.

Hard mode

One of the riskiest actions we can do with Git is hard mode reset. It will roll back to the specified commit but alters both the staging area and our files.

We may understand this with the help of a diagram.

If we run git status, we see that everything is up to date. It happens because Git unstaged all the changes and modify all the files.

Let’s use the hard reset to roll back to the second commit again. We will use the following command.

git reset --hard d372675Code language: Bash (bash)

Logging the commit history, we see that there are only two commits. That means we have successfully performed a hard reset. Also, the staging area and files are now changed.

Reverting a change

One of the significant drawbacks of using git reset is that we may unknowingly lose some essential parts of our code. Rolling back to a previous version is an irreversible action. That means we cannot recover any commits we lose while using git reset.

As an alternative to git reset, we have git revert command. It takes a commit that we specify, undoes all the changes made in it, and then creates a new one. Newly generated commits won’t have the changes in the chosen commit.

To revert a commit, we use the following command.

git revert <commit-hash>Code language: Bash (bash)

Initially, there were three commits, the last of which had some incorrect code. We used git reset to go back to an earlier version because we couldn’t find which part of the code was causing the problem. We performed a hard mode reset which removed all the changes entirely. Let’s now use git revert to examine how it maintains the commit history while undoing the modifications made in a specific commit (or erroneous commit).

We’ll use the following command to undo the changes from the second commit.

git revert d372675Code language: Bash (bash)

When we type this command, an editor will pop up (most probably Vim) where you may modify the commit message to use for the new commit.

After entering the commit message, save the file, then close the editor. Git will undo the modifications in the chosen commit and create a new one.

4. Stashing

Imagine a situation where you are working on a feature for your application. It’s not that urgent for now, but you have made significant progress. Suddenly, you get informed about a bug in the application. Since you have progressed quite far with the feature, you don’t want to lose its code. Even though it’s not that urgent right now, it might be helpful later.

One straightforward option is to manually copy all the modifications to a safe place. But manually copying every update is highly time-consuming, especially when there are several changes across multiple files. It is incredibly prone to errors.

On the other side, we can do this process with only one command if we use stashing. It is convenient and saves a lot more time.

git stash Collects all of our uncommitted staged changes and stores them. It then undoes all those modifications from the files.

There were three functions in our index.js file. Let’s add a new function named w.

function w() {
  console.log('w');
}Code language: JavaScript (javascript)

We wish to store this function for a future time even if we don’t now require it. We’ll stage all our modifications to accomplish this and make a new stash.

# stage all the changes
git add .

# create a new stash
git stashCode language: Bash (bash)

Git will take the modifications out of our files and store them in a new stash.

We can create multiple such stashes using the git stash command. We use the following command to view the list of all the stashes we have made.

git stash listCode language: Bash (bash)

There is an index associated with each stash. We have one stash here, indexed 0. Using this index, we are able to identify the appropriate stash for our files.

We will use the following command to apply a stash to our files.

git stash apply <index>Code language: Bash (bash)

The stash index we just created is 0, so we will write.

git stash apply 0Code language: Bash (bash)

All the changes in the stash are now applied to individual files in our repository.

Quick Tip

Even after applying the stash, we can see it in the list. We must manually remove it. We use the following command to delete the stash from the stash list.

git stash drop <index>Code language: Bash (bash)

5. Squashing

Squashing is the process of combining two or more commits into a single commit. It has several advantages, a few of which are listed below,

1. It maintains a clean Git history sequence.
2. It eliminates any commits indicating Work In Progress.

There are numerous techniques for squashing, but the most simple is to utilize interactive rebase. We can use Git interactive rebase to change individual commits, squash commits together, drop commits, arrange commits, etc., by presenting the available list of commits and operations.

To squash commits, we’ll run the following command based on the commit hash of the commit up until which rebase is needed:

git rebase -i <commit-hash>Code language: Bash (bash)

Let’s combine the first and second commits into a single one. We will utilize the commit hash of the third commit to execute interactive rebase on the first and second commits.

git rebase -i f8dcdf5Code language: Bash (bash)

When we run this command, Git will launch an interactive rebase session with the actions available to us:

We can see that pick is written in front of the commit hashes. We will update this operation with the keyword of the required operation. Since we want to commit two commits into a single one, we will substitute s or squash in place of pick in the last commit. In this method, we’ll instruct Git to merge the last commit into the prior commit.

Now save the file and close the editor. Git will now open another editor to edit the commit message. Delete all the contents and write the commit message in the editor. Then save the file and close the editor.

Git will now squash the two commits. To confirm, we can look at the commit history and observe that there are just two commits. The most recent commit we see is the squashed commit.

Conclusion

In this article, we looked at some of the most critical git principles you’ll need to excel in interviews as a developer. Git, however, offers much more than can be covered in one article. It would be a good idea for you to explore other such topics as well.

Thank you so much for reading ?