Git Secrets: 5 advanced git commands that will level up your workflow

Git is a powerful version control system that developers around the world widely use. While most people are familiar with the basic Git commands, many lesser-known Git commands can be equally valuable for your workflow.

In this blog post, I will introduce you to five unique git commands to help you work more efficiently and effectively with your repository. The following commands will be valuable additions to your Git toolkit.

Let us begin 🚀

🕐 git bisect

Imagine that you are working on a large codebase, and you notice that a bug has been introduced recently. You suspect that a few recent commits introduced the bug, but you don't know which commit caused the bug.

git bisect is a command useful to save your time and energy by quickly identifying a faulty commit with the help of binary search.

To demonstrate the power of git bisect, l'll give you an example:

1. To illustrate, let me make a series of commits first.

   

2. You can use the command git log --all to log all the commits you have made so far. Why do you require this step, though? 🤨

   To use git bisect, you will need to have a deep understanding of your repository's commit history and be able to determine whether a given commit is "good" or "bad" based on whether it exhibits the bug or not.

   

3. Run git bisect start to begin the bisect process.

   

4. Next, run git bisect bad <COMMIT-HASH> to mark the current commit as "bad," meaning that it exhibits the bug.

   

    const greetUser = (userName) => {
        return `Good morning, ${userName}`
    }
   
    greetUser({ name: "Prerana" })
   

   This is my bad code in the current file. As is obvious, the code has a mistake.

   You can find the COMMIT-HASH of a commit from the previous log command that you would have executed.

   

5. Run git bisect good <COMMIT-HASH> to mark a previous commit as "good," meaning that it does not exhibit the bug. The commit hash should be for a commit that you are confident does not have the bug.

   I have taken the good commit as the initial commit here.

   

6. Git will automatically check out a commit in the middle of the range between the "good" commit and the "bad" commit. You should test the code at this commit to see if it exhibits the bug or not.

   As you can see in the output, Git has automatically checked out to the commit feat: function to greet user.

   

   In this case, i.e., the code in the commit feat: function to greet user ran successfully. There is no error.

   

7. If the code at the current commit exhibits the bug, run git bisect bad. If the code does not exhibit the bug, run git bisect good.

   I'll run the git bisect good command since there is no error in the commit.

   Git has automatically checked out to the next commit fix: change user value from string to object.

   

   You can clearly see that there is a bug in the code. I'll now run the git bisect bad command. Git will continue to check out new commits and ask you to test them until it has identified the commit that introduced the bug.

8. When git bisect has identified the commit that introduced the bug, it will output the commit hash and message. You can then use this information to debug the issue and fix the bug.

   

9. Since you've discovered the problem and the first bad commit. Run git bisect reset to exit the bisect process and return to the original HEAD commit.

   

🕑 git cherry-pick

Consider that you have made a number of commits while working on a feature branch. You realise one of the commits contains a patch that you also require on the main branch. Instead of merging the entire feature branch, you can use the git cherry-pick command to apply the specific commit to the main branch.

The git cherry-pick <commit-id> command allows you to selectively apply specific commits from one branch to another. It can be useful when you want to apply a specific fix from one branch to another, without merging the entire branch.

You'll need to know the commit hash for the commit you wish to apply in order to use git cherry-pick. Utilizing git cherry-pick involves the following steps:

1. Check out the branch that you want to apply the commit to.

2. Run git cherry-pick <COMMIT-HASH>, where <COMMIT-HASH> is the commit hash for the commit that you want to apply.

   

   Git will apply the commit to the current branch. Before you can start the cherry-pick, you must resolve any conflicts that exist.

   

3. Once the cherry-pick is complete, you can commit the changes to the current branch.

💡It is also useful when you want to revert a specific commit, as you can cherry-pick the commit's inverse changes.

🕒 git reflog

git reflog is a tool for tracking changes to references in a Git repository. It is used to recover lost or deleted commits and branches, and to revert changes that have been made to the repository's history.

Restoring lost commits: If you have accidentally deleted a commit or branch, you can use git reflog to find the commit and restore it.

Reverting repository changes: If you have made changes to the repository's history (e.g., using git rebase or git filter-branch) and want to revert the changes, you can use git reflog to find the previous state of the repository and restore it.

To use git reflog, you will need to have a good understanding of the commit history of your repository and be able to identify the changes that you want to restore or revert.

To use git reflog to restore a lost commit, you will need to identify the commit in the reflog and use it to create a new branch. Here is an example of how to use git reflog to restore a lost commit:

1. Open a terminal and navigate to the directory for the repository.

2. Run git reflog, which will show a list of the changes that have been made to the repository's references.

   

   The output shows the commit hashes and descriptions for the changes that have been made to the repository's references.

3. Identify the commit that you want to restore in the reflog. In this example, we will restore the commit with the hash 0c9e29c.

4. Run the following command to create a new branch based on the lost commit: git branch <lost-commit> 0c9e29c

   

   This command creates a new branch called refactor/types that points to the commit with the hash 0c9e29c.

5. Run git log to confirm that the lost commit has been restored.

Note: git reflog is a useful tool for recovering lost commits, but it is not a replacement for proper backup and version control practices. It is recommended to create regular backups of your repository and use version control tools (such as Git) to track and manage changes to your code.

🕓 git blame

Git blame is a useful tool for tracking down who made a change in a file in a Git repository. Imagine you are working on a project and you notice a bug in a file. You want to know who made the change that introduced the bug so that you can ask them about it or revert the change. You can use git blame to see the commit hash, author, and commit message for every line in the file.

Run git blame <FILE_PATH>, where <FILE_PATH> is the path to the file that you want to inspect.

Git will output the commit hash, author, timestamp and commit message for each line in the file. It is also useful when you want to revert a change that was made by a specific person.

Difference between git reflog and git blame? 🤔

git reflog and git blame are both tools for examining the history of a Git repository, but they have different purposes and provide different information.

git reflog is a tool for tracking changes to references in a Git repository. It is primarily used for recovering lost or deleted commits and branches, and for debugging repository issues. It shows a list of all the changes made to references (e.g., commits, branches, and tags) in the repository.

git blame is a tool for showing the commit history for a specific file. It shows the commit that last modified each file line, along with the commit's author and commit message. It is primarily used for examining the commit history of a file and identifying when and by whom specific changes were made.

🕔 git diff

Consider, you are working on a project and you have made changes to a file. You want to see the differences between your modified version of the file and the version that is currently in the repository. You can use git diff to see the differences between your version of the file and the repository version.

It allows you to view the differences between two commits, branches, or files. You can use this command to see what changes have been made since the last commit or to compare the changes in two different branches.

There are several different ways that you can use the git diff command, depending on what you want to compare.

Here are the steps to use git diff:

1. git diff <BRANCH1> <BRANCH2>:

   This will show the differences between the specified branches.

   

2. git diff <BRANCH>

   This will show the differences between the specified branch and the current branch.

   

3. git diff

   This will show the differences between the modified files in your working directory and the repository.

   

4. git diff <COMMIT-HASH-1> <COMMIT-HASH-2>

   This will show the changes between the two commits.

   

That's a wrap! 🔥💯

I hope you enjoyed learning about these five unique Git commands! Whether you're a Git novice or an experienced user, these commands can help you work more efficiently and effectively with your repository.

From finding and fixing bugs with git bisect to recovering lost commits with git reflog, these commands can help you take your Git skills to the next level. Don't be afraid to experiment with them and see how they can improve your workflow.

Happy learning!