39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
---
|
|
title: Solve one problem at a time
|
|
date: 2025-03-01
|
|
permalink: daily/2025/03/01/one-problem
|
|
tags:
|
|
- software-development
|
|
- git
|
|
cta: ~
|
|
snippet: |
|
|
When you're committing a change, it should only solve a single problem.
|
|
---
|
|
|
|
When using `git log` to look through the history of codebases, I often see large commits that combine several changes.
|
|
|
|
These also lead to vague commit messages like "Changes", "wip" or "Fixes".
|
|
|
|
These aren't helpful when reviewing the history and large commits are difficult to review and revert if there is a problem.
|
|
|
|
Each commit should be focused on a single change, whether its adding part of a new feature, fixing a bug or refactoring.
|
|
|
|
If it's a combination, they should be split into separate commits.
|
|
|
|
Each commit should have its own well-written commit message that explains why the change was needed, any consequences or manual deployment steps, alternative approaches that were tried, issues encountered and any follow up actions.
|
|
|
|
If you can't properly describe the changes made in a commit, the commit is too big.
|
|
|
|
You should uncommit the changes and use `git add -p` to create a more focused commit.
|
|
|
|
This is why [I don't squash commits][0].
|
|
|
|
If people have made an effort to create good commits with good commit messages, I don't want them to be lost when the commits are merged.
|
|
|
|
I want to keep the history of the changes intact and as it originally was.
|
|
|
|
I do sometimes need to [tidy up my own commits][1], though, before I push them for anyone else to see.
|
|
|
|
[0]: {{site.url}}/daily/2024/05/11/don-t-delete-my-commit-messages
|
|
[1]: {{site.url}}/daily/2025/02/11/tidy
|