When to Push Massive git Commits
TLDR: Atomic Git commits focus on a single task, creating a clear narrative for code changes. Massive commits are useful for quick testing in unstable environments but should be avoided in steady development. Reverting a single large commit simplifies testing rollbacks.
I will admit it, I am a meticulous commiter. When I see new developers push up a week’s code in a single commit, I shutter. The way I have learned to commit and what I’ve seen across many projects is that commits should have a singular focus, even if the related code is massive. Is there ever a time to push massive git commits?
A good strategy for commits
My rule of thumb for committing code is each commit should focus on a single subject or action. You should have multiple commits if you perform a task such as adding a new API endpoint. This could include adding a controller route, running a schema migration to update a table, and adding a new service method to work with data.
Each entity or method should be an atomic commit that encapsulates a single objective. We need a new controller route to hit. This new route will be a commit. We need to add a new field to a table. That migration file and schema file update is a commit. Finally, the service gets a new method. The method is contained in its own commit.
By structuring your commits like this you create a story or narrative of how a feature occurred. Developers who review your PR can see a progression and the thought process behind why you performed each step.
This can help identify gaps in business logic or ticket goals that may be missed if your commit has 1000 lines of updates across a dozen files.
When to push massive commits
Would there ever be a time when we wouldn’t want this atomic structure? Yes, and it comes for a specific reason.
Recently, one of my teams was developing multiple interfaces for a multi-tenant app. Each interface worked with a different messaging app. We had a messaging app integration that was tested and stable, and another integration that was just headed to testing.
My team wanted to push code for the new integration to UAT but wasn’t sure how it would affect the stable code. We needed a quick way to test our changes. This is where the massive commit came into the picture.
When working with git you can revert commits to remove new code added to your branch. Doing so takes time to revert each commit. If you want to avoid extra commands and deployments, you can make a singular commit.
This is not an attractive option for steady development. However, a massive commit for quick testing of the stability of code is an option. We deployed this code and found a few broken areas. No worry. We were one commit removal away from getting our code back to working.
Why didn’t we test locally? With mature projects, you likely have a fully configured testing environment separate from your customer-facing app. We had not had enough time to build a fully featured testing environment. For us, it made more sense to quickly deploy and test than to set up or mock all the expected items we needed to run the app.
Key Takeaways
- Atomic commits encapsulate a single objective (e.g., adding a route or migration), improving code review clarity and logic tracking.
- Massive commits are practical for rapid testing in unstable environments, allowing easy rollback with a single revert.
- Use atomic commits for steady development to maintain a clear change history and avoid cluttered pull requests.
- Massive commits are less ideal for regular development due to reduced transparency but suit quick stability tests.
