Navigating Git History

In today’s software development, Git usually stands as a “go-to” for DevOps projects. It allows teams of developers to collaborate and contribute to non-linear projects, go back to any point in time, and undo, as well as, redo changes whenever they need. In this article, we will go over important commands to help you navigate your commit history.

Why understanding Git history is important

In Git, commits are rather important. Git commits are like a history of your repo. As your project grows, and you add new features or fix bugs, commit messages are what you can refer to in order to see what changes were made and how. Provided that your commits are well organized, purposeful, and documented you can use your Git history to your advantage. By going through your commit history you can track what changes were made and evaluate how effective they were. Once you do that, you can implement upgrades where relevant based on the knowledge you gained by reviewing your commit history. However, the complexity of VCS can sometimes be challenging for new devs.

Benefits of a clear commit history

Through the use of the ‘git log’ command, you can view all of your commit logs. But to understand them and make any use of them you must keep a clear history of your commits. The advantages of maintaining an organized commit history are extensive. One major advantage is that you can have a comprehensive view of all changes in your code and you can analyze it based on your commits. That will allow you to find the causes of bugs much quicker and, therefore, fix them quicker, too.

Moreover, if needed, reverting commits will be easier if your log is organized. Another key factor is the ability to track who makes those commits, as this will help to clarify and address issues if any arise. A clear commit history guarantees that each commit author is accountable for the specific commit they made, so it is easier to track changes and contributions made by the members of your development team. These points lead to better collaboration between devs and project managers, support responsibility, and make it easier to comprehend the progress of your source code.

So, here are the key advantages of a clear commit history:

• You have commit-based reviews
• You get an organized and streamlined log
• You can locate causes of bugs quickly
• You can revert changes easily
• You may make purpose-driven changes and upgrades
• You get more accountability – see who has done what
• You improve collaboration and communication

Look through your history with ‘git log’

As we mentioned, you can take a look at the commit logs of the branch which you’re working on by using ‘git log’. Once you run ‘git log’ in your project, you will see a list of all of the commits made – the most recent ones will show up first (reverse chronological order). It will provide you with the following information about each of the commits on the branch: author, date of the commit, and the commit hash along with commit messages.

Better overview with ‘git log –oneline’

For a clearer view you can add ‘–oneline’ to your ‘git log’. This way the output will be limited to only a single line. By default, you will see the commit ID and the first line of the message in a commit. When you enter ‘$ git log –oneline’, this is the output you should get:

$ git log –oneline
4d2b5c6 Fix bug in authentication process
1a2b3c4 Add user profile feature
0a1b2c3 Update README.md with setup instructions

We can expand our process further and limit the actual list of commits we’ll see to a desired amount. By using ‘git log -2’ you will only see the last two commits. Moreover, through the use of ‘git log –since=”2 days ago”’, you will limit the output to only the commits from the last two days.

More specific options

Another useful option to take advantage of is ‘–author’. This allows you to look for commits which were made by a specific person. So, to find the commits authored by an individual you are looking for, let’s say you are looking for a Peter, you simply enter: ‘$ git log –author Peter’. Other, more advanced commands include:

• ‘$ git log –oneline –grep caching -i’ (This will allow you to view commit history in single-line format).
• ‘git log config/environments/production.rb’ (It will show the history of commits for a specific file).
• ‘git log — config/environments/production.rb’ (The ‘–’ which we added here, separates the log options from the file path).
• ‘git log –oneline –grep caching -i –author Peter –since ‘2 years ago’ config/environments/production.rb’ (Here, by adding ‘–since ‘2 years ago’, we limit the output to commits made in the past two years, on top of the other options included).

Commit details

Now, you are able to find and view the specific commits you need as well as filter the output which you will get, for improved clarity and precision. The next thing you will need to do is to find out what your commits include and the changes they bring in. This is where the ‘git show’ command comes into play. Add the relevant commit hash (they are listed in your ‘git log’ output) to the ‘git show’ command and you will be able to see diff and the basic information regarding your commit. Take a look at the example below:

$ git show 1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t

Keep in mind that you do not have to input the whole commit hash, 6 characters should be enough to locate your commit. Then, you may need to review the diffs for multiple commits at the same time. This requires us to go back to the ‘git log’ option. To put it simply, type in all the options you need so that the output will show you the results you are after, and just add ‘–patch’ or ‘-p’. Take a look at the example below:

$ git log –author Peter –patch

Now, this command shows all the commits made by Peter and show in detail what changes occurred in each of the commits listed.

History of files

Let’s move on to the history of specific lines in your file. Here, we will use ‘git blame’ in order to track who was responsible for the most recent modifications of each line of a file. When you run this command, it will show you the partial commit hash, the specific author and the date of the most recent commit for each line in your file. Take a look at the example of running such a command:

git blame config/environments/production.rb

Additionally, if you are after a specific line which is further back in time, you can do so by finding the latest commit hash for that line. Then, use that hash to locate previous commits by running the following command (and repeat the outlined process to go further back):

git blame 4d2b5c6f7e8b9a0c1d2e3f4b5c6a7b8d9e0f1a2b^ config/environments/production.rb

What you should do next is pass the relevant commit hash which you were looking for to the ‘git show’ command in order to see the diff, commit message etc.

Let’s try another method

To simplify and diversify this process let’s go back to ‘git log’ for a moment. Using the ‘git log’ command is beneficial here, as it allows you to look through the commit message to locate specific patterns and most importantly, you can see what changes were made with a commit. This may prove beneficial if you need to find commits where a particular part of code was removed or added. We will use the pickaxe option (-S), in order to search through commits and locate where a specific piece of code was changed. Then complement it with ‘–patch’ to see the exact changes that took place. Take a look at the following example:

git log -S config.enable_feature_x –patch

💡 Bear in mind that if the name of the file was changed you may not get the desired results.

View differences between branches

The whole purpose of comparing multiple branches is to spot the differences between branches in your VCS. It’s important as it helps to get a grasp of what has been already developed, it guarantees a smooth integration of any new features and so on. What you could do first is, identify which commits that haven’t been merged to the main branch have been made on a feature branch. This way you can see what changes are new or unique to the feature branch. Take a look at the example of this command:

git log –oneline main..feature/primary-feature-branch

By running this command ‘git log’ lists all commits that are on ‘feature/primary-feature-branch’, but not on the main branch.

Compare branches

Next, we’ll compare branches. By checking the differences between the latest versions of two branches you support proper code review and get a better understanding of how these branches are different from each other. Run the following command to see the line-by-line changes between the files in your main branch and ‘primary-feature-branch’:

git diff main feature/primary-feature-branch

In order to carry out a more precise comparison between specific files, let’s focus on differences in a specific file between branches. Try running this command:

git diff main feature/primary-feature-branch config/environments/production.rb

By doing so, you can see how the ‘config/environments/production.rb’ differs between the ‘main’ branch and the ‘feature/primary-feature-branch’.

Finally, we’ll look at how to determine the changes made on a feature branch since it diverged from the main branch. As you may already know, when creating a feature branch from the main branch, they will share the same commit history up to the point where branching takes place. If the work continues on this feature branch, new, recent commits will be added which will not be included in the main branch. Try running this command to see the changes which were made on your feature branch since branching:

git diff main…feature/primary-feature-branch

Executing this command will allow you to compare the current state of the feature branch with the state of your main branch at the last common commit – the moment where your branches split. Therefore, you will be able to see new features, changes, fixes and so on that have been added.

Make sure your source code is protected

Security of your source code should be a fundamental aspect in your workflow. With constantly emerging cyber threats (check out The State of DevOps Threats Report), it is important to take security measures to keep your repos protected. Implementing software composition analysis, API management, full control over access controls, vulnerability management, backup, and Disaster Recovery are some of the DevOps security best practices that can help you protect your source code.

GitProtect.io backup and Disaster recovery software for GitHub, Bitbucket, GitLab, and Jira, can help organizations make sure that every line of their code is accessible and recoverable in any event of failure – infrastructure outage, ransomware attack, accidental deletion, etc., ensuring continuous workflow.

✍️ Subscribe to GitProtect DevSecOps X-Ray Newsletter – your guide to the latest DevOps & security insights

🚀 Ensure compliant DevOps backup and recovery with a 14-day free trial

📅 Let’s discuss your needs and see a live product tour