Skip to main content

Make Git Log Great (Again): Merge vs Rebase

 A well-maintained Git log is more than just a record of commits—it’s a story of your project’s growth, collaboration, and problem-solving. But as projects scale and teams grow, Git logs can become cluttered, making it harder to trace changes, understand context, or troubleshoot issues.

In this post, we’ll explore strategies to make your Git log more readable, structured, and useful—because a great Git log isn’t just good practice; it’s a competitive advantage.


Simple Merging

Let's kick off with a simple merging strategy, the one we are all probably most familiar with. For simplification purposes, let's assume we have one main branch that represents the current development branch. Every team member creates their own branch when they want to work on a specific feature and continues working on that feature branch until it is finished. Once it's done, they merge their feature branch into the main branch, and all their work is integrated into the main branch. Then, they can move on to the next feature. Below is a small drawing that represents the described behavior.


What Happens When a Feature Branch Takes Longer to Implement?

Here comes the first problem: what if our feature branches are not short and need to be implemented over a longer period of time? In this case, we risk our feature branch becoming outdated compared to the main branch.

We can solve this problem by more frequently merging changes from the main branch into our feature branch. This keeps our branch updated with the latest changes from the main branch and helps avoid the risk of encountering a lot of conflicts when we eventually merge the feature branch back into the main branch. A small illustration of this concept can be found in the image below.



On one hand, we have reduced the likelihood of larger conflicts when merging our feature branch into the main branch. However, on the other hand, we are making our Git log harder to read and introducing tightly coupled commits, which makes reverting changes more challenging—and in real-world scenarios, almost impossible. The problem becomes even worse as the team grows and feature branches take longer to complete.


Another Approach: Simple Rebase

Now, let us take a look at the same example, but this time using rebasing instead of merging. This means that when we need to update the feature branch with the current main branch, we rebase the feature branch onto the current main. Similarly, when we want to update the current main branch with our feature branch, we rebase the main branch onto the rebased feature branch. Below is an image illustrating this example in contrast to the merging approach.


Here, we can see that the Git log becomes much more readable and easier to track when features are integrated into the main branch. In this example, we have displayed just one feature branch and a simplified main branch for illustration purposes, but this approach can also be applied to much more complex scenarios.

Can it be improved?

Yes, we can further improve the example above by simply squashing the feature branch into a single commit before including its changes in the main branch. For illustration purposes, we will display only the last two steps.




With this final step, we’ve streamlined our feature branches into a single commit in the Git log. This approach not only condenses the feature development into a neat, single entry, but also transforms the Git log into a clean, chronological timeline. By simplifying the development history, the log becomes much easier to follow, maintain, and understand—especially when navigating through complex projects. Moreover, with fewer commits to manage, it’s much simpler to identify changes, isolate specific updates, and, if needed, revert them with less risk of unintended consequences. This results in a more organized and manageable Git history, which ultimately benefits both individuals and teams working on the project.













Labels:

Comments

Post a Comment

Popular posts from this blog

Design Patterns: Singleton

Tyipically the first design pattern most people learn, often wrongly ☺ To give an introduction, we can say that singleton is one of the creational design patterns which ensures only one class instance with single point of access thru entire application.  Because it is relatively simple to implement, the Singleton pattern is sometimes misapplied in situations where it is not the most suitable choice. When to use it? Here are the few examples of corrent usage of singleton: Configuration Management  Centralized configuration settings for consistent use thru entire application Caching Maintaning  Single istance of cached objects for easy and fast acces Logging  Ensure unified mechanism to avoid duplication of log files, formats, etc Global State Management  Centralized management of the state which is needed to be shared accross the application Resource sharing  Thread pools, database connection, I/O operations When not to use it? On the other hand, here are fe...
Post a Comment
Read more

Design Patterns: Builder

This is also, like a Singleton , one of the creational design patterns. It provides the way of creating complex objects step by step by simple chaining and every particular step is independent of other steps. Let us dive into the real example of usage. For showing purpose we have created an example in C# which creates simple SQL queries using described pattern.  using System; using System.Text; namespace BuilderPatternExample { public interface ISqlQueryBuilder { ISqlQueryBuilder Select(string columns); ISqlQueryBuilder From(string table); ISqlQueryBuilder Where(string condition); ISqlQueryBuilder OrderBy(string columns); string Build(); } public class SelectQueryBuilder : ISqlQueryBuilder { private readonly StringBuilder _queryBuilder; public SelectQueryBuilder() { _queryBuilder = new StringBuilder(); } public ISqlQueryBuilder Select(string columns) { ...
Post a Comment
Read more

Why Do Employers Lie In Interviews?

This is a very common subject that many of us have already experienced. But when you realize that half of what has been said at interviews is actually a lie, you are already at least six months in the company, you have already started some project and it wouldn’t be appropriate to leave the company at that moment. Why is this happening? First of all, let us see how the usual interview process looks like in software development companies. First round interview in most of these companies is an interview with HR. This is the first insight about the company. A person who works in HR is usually someone who, in most cases, doesn’t understand what the software is and how the software development process goes. Big respect to those companies where HR knows these things. This phase usually contains some standard questions about your personality, what do you like about the company, how this company is something that you are actually looking for, where you see yourself in five/ten  years etc… ...
Post a Comment
Read more