Git is a free and opensource distributed version control system. I did have a conversation with a developer whether we are going to squash commits or preserve the history. A commit is a snapshot of the changes you have made in your files at a particular point in time. Commits allow you to track and manage the history of your project, making it easier to collaborate, review changes, and roll back to previous states if needed.

What is squashing?

Squashing refers to the process of combining multiple consecutive commits into one single commit. This is typically done to create a cleaner and more concise commit history. When you squash commits, you merge the changes from several commits into one commit, and you can provide a new commit message that summarizes the changes.

While squashing commits can seem like a tidy way to keep a clean and linear Git history, there are strong arguments for why keeping commit history intact is often the best choice, especially when dealing with large and complex features.

Context Matters

When it comes to understanding code changes, context is everything. Keeping commits separate allows developers and reviewers to see how a feature or bug fix evolved over time. This incremental history can be invaluable when troubleshooting issues, identifying the motivations behind certain decisions, and tracing the development of a particular feature.

With squashed commits, this context is completely lost. A single, monolithic commit provides no insight into the thought process or rationale behind each change. Reviewers are left in the dark, forced to guess why certain decisions were made.

Granularity is Key

Squashed commits result in a loss of granularity. Imagine a large feature with multiple components or modules. When each change is squashed into one massive commit, it becomes challenging to identify which part of the code is responsible for specific functionality or issues. This lack of granularity makes it harder to isolate problems and makes debugging a cumbersome task.

Maintaining individual commits keeps the granularity intact, making it easier to pinpoint where problems occur and facilitating more targeted code reviews.

Transparency

A transparent development history is crucial for project transparency. By preserving the commit history, you maintain an unaltered record of every contribution, no matter how small or significant. This practice acknowledges the work of individual contributors, fosters a culture of transparency, and allows for a more accurate attribution of credit.

Squashed commits can hide the contributions of individual team members, potentially leading to a lack of recognition and accountability.

Facilitating Code Reviews

Code reviews help catch bugs, ensure code quality, and foster knowledge sharing within the team. However, squashed commits can make code reviews more challenging.

When commits are squashed, the reviewer is presented with a single, massive diff. This can be overwhelming and make it difficult to provide thorough and timely feedback. With preserved commits, the reviewer can review changes incrementally, focusing on one commit at a time. This incremental approach simplifies the review process and promotes more efficient feedback loops.

Effective Bug Tracking

Bugs are an inevitable part of software development. When issues arise, having a detailed commit history can be a lifesaver. If you make use of git bisect you know that preserving commits make it easier to identify when and where a bug was introduced, allowing for quicker and more accurate bug tracking.

With squashed commits, tracking down the source of a bug can become a daunting detective task. The lack of granularity and context makes it challenging to determine which commit is responsible for the issue.

To conclude

Git is a powerful and flexible version control system that provides numerous features for managing code. While squashing commits is one approach, Git’s branching and merging capabilities are designed to handle complex development scenarios without the need for squashing.

While squashing may create a neater Git log, it often sacrifices essential aspects of code collaboration, transparency, and accountability. By acknowledging the advantages of keeping a detailed commit history, you can facilitate better communication, collaboration, and code maintenance, ultimately leading to a better development process.

References