Git Basics Made Simple: Essential Commands Every Developer Should Know

Hello readers, Welcome back

In the previous blog, I shared the story related to the problems developers face without Git — the well-known pendrive problem. You understood why Git is important and how it helps us make our developer journey smooth.

If you are new, then you can checkout my first of this git series:
Blog 1 : Why git exist: the pendrive problem

In this blog, I’m going to teach you the basics of Git and Git commands with stories and in depth.

Blog Contents

1. What is Git?
2. Why Git is Used
3. Git Basics and Terminologies
4. Basic Commands of Git
   • git init
   • git add
   • git commit
   • git status
   • git log
   • git diff
   • git revert
   • git reset
     • git reset --hard
     • git reset --soft
5. Conclusion
6. What’s Next

What is git?

Git is a version control system that helps developers track their code. It keeps track of code changes in your project along with the author information of who made those changes.

It was developed by Linus Torvalds (the developer of Linux) in 2005. It was created to handle the complexity of the Linux project.

Why git is used?

• To Time Travel: Yes, if you want to time travel, then use Git. Git keeps track of all your changes, and if you have made a mistake in the past, it allows you to go back to that code and fix it.
• Smooth collaborations: Git helps you easily collaborate with your fellow developers, review their code changes, and work with the team without conflicts.
• Rapid Development: Git allows developers to work on multiple independent features simultaneously using features like branching and merging.

Git Basics and Terminologies

Here are some core terminologies you should know before jumping into the commands:

• Repositery: It is your project folder where all your code files exist.
• Add: It means you have started tracking your file.
• Commits: It means making your changes permanent.
• Head: HEAD is a pointer to your latest commit.
• Branch: A branch means separating different features from your main code.
• Pull: Pulling code from a remote repository (GitHub, Bitbucket) and merging it into your local repository.
• Fetch: Fetching code from a remote repository without merging it into your existing code.

Basic commands of Git

To use Git, first you need Git installed on your computer. You can install it from the Git website: https://git-scm.com/install/windows

To check whether Git is available on your computer or not, run this command:

To track your repository’s code changes, you have to initialize Git in your project. Here is our first command:

• git init: Initializes an empty Git repository in your project.

Now, your code files are ready to be tracked by Git. Whenever you create a new file in your project, it will be marked as untracked (U), which means Git is not tracking that file.

To track the file, you have to run:

• 2. git add <file_name>: Adds the file to the staging area of Git. It means your file changes are under the surveillance of Git. The staging area is like a lobby where all the files that are being tracked by Git are placed.

If you have too many files to track or stage, then you can use git add . This will add all your untracked or modified files to the staging area.

Now, Git has started tracking your changes, and when you have finished making changes or reached a specific point, you need to make those changes permanent so that you don’t lose them. To do this, here is another command:

• 3. git commit -m <commit_message>: This command makes your changes permanent and removes your file from the staging area to the local Git repository.

Each time you make a commit, it creates a unique hash, and each commit has the address of its previous commit. As a new commit hash is created, HEAD moves to that commit.

The commit message is important; it should be precise about the changes you are committing. In this command, -m means message. If you don’t add a message, this command will open a file where you need to enter your message and then close that file.

To get the status of files in your project, such as modified or untracked, use this command:

• 4. git status: It gives the status of your files.

To see all the commit details, you can use this command:

• 5. git log: It shows the commit ID, author information, date, and time. It also shows which commit HEAD is pointing to.

You can also use git log --oneline to get a short summary. This will only include the short commit hash and the commit message.

• 6. git diff: This command shows the difference between two commits. It takes the commit hash as input.

In case no commit hash is provided, it will show the overall recent changes.

Until now, you are working smoothly and developing your features, but suddenly you encounter a bug in a commit. Now you need to revert that commit to run your project. To do this, there are multiple commands. One of them is:

• 7. git revert: It takes a commit ID and reverts the changes by adding a new commit. In this new commit, the buggy part added in the given commit is removed. HEAD is also moved to this new commit.

The advantage of this command is that you retain the history of the code fault and its resolution.

Another way is to move HEAD before the bug commit instead of adding a new commit. This will also remove the bug, but it will remove the history that the bug was introduced. For this, use the following command:

• 8. git reset:
  
  git reset has multiple options—either you move HEAD while deleting all the changes (--hard), or you keep the changes in the staging area to be committed again (--soft).

  • a. git reset — hard HEAD~1: This command moves HEAD one commit back and permanently deletes the changes along with the history. Use it at your own risk. Only use it when you know what you are doing.
  • b. git reset — soft HEAD~1: This command moves HEAD one commit back and moves the changes to the staging area instead of deleting them. Now you can modify the files and fix the bug. After completing the fixes, commit again. This is safer than --hard.

conclusion

This brings us to the end of the Git basics and essential commands. By now, you should have a clear understanding of how Git tracks your code, manages changes, and helps you recover from mistakes confidently.

what's next

In the next blog, we’ll go deeper into Git’s file structure and explore what happens under the hood when you run these commands. Understanding this will make Git feel less magical and more logical.

If you found this blog helpful, do share it with others and feel free to drop your feedback. Your feedback helps me improve and write better content for you.