Edit Reading

Back to List

Basic Information

Title

Please enter a title.

URL

Please enter a valid URL.

Date

カテゴリID

画像ファイル名

統計情報

単語数: 584語

読了回数: 0回

作成日: 2023/05/25 10:26

更新日: 2025/12/09 03:44

本文

Why You Should Write Small Git Commits
Small commits that are easy to understand are the backbone of great software development

Ali Kamalizade
Better Programming
Ali Kamalizade
·
Follow
Published in
Better Programming
3 min read
·
Feb 11, 2020

Listen

Photo by Vlad Tchompalov on Unsplash
Most people involved in software engineering and programming should be familiar with version control systems like Git.
Usually, you stage the changes you did, write a commit message, and push the changes to a repository. Here’s an example use:
git add .
git commit -m "[#2313213] Fix XSS vulnerability in tooltips"
git push
# pushed 2 changed files to the repository
However, you have probably seen commits that contain lots of changed files due to covering a variety of topics:
git commit -m "[issue-id] Fix XSS vulnerability in tooltips + Improve Accessibility in dropdowns + Add unit test for user-dropdown.component + Update dependencies"
# pushed 20 changed files to the repository
There are also commits where the commit message doesn’t tell you enough about what the intent of this commit is:
git commit -m "Did some changes"
# pushed 13 changed files to the repository
In agile environments using Scrum or other related agile methodologies, it is expected to deliver customer value fast and at regular intervals.
Influenced by a coworker, I tried to adopt his style of small commits and continuous improvement. As someone with interest in both business and the technology behind it, this approach resonates well with me.
GitHub checks passed
Continuous Integration helps us to catch bugs and issues early
In this post, I want to briefly summarize why I like this approach. We’ll take a look at the advantages of small commits in software projects.
Advantages of Small Commits and Continuous Improvement
Getting early feedback from both tools (e.g. unit tests on a CI server) and other people (developers, testers, product managers) which encourages the idea of continuous improvement and helps to avoid large changes in the future.
Revert a commit with ease if something goes wrong. Big commits are harder to revert since you may not want to revert all of the changes but only a subset.
Small commits are easier to understand when reviewing a pull request.
Write better commit messages. Since small commits are usually more focused and less broad than big commits, it is often easier to state the purpose of a small commit.
Improve your statistics (don’t take this too seriously).
Goal: many contributions
Use the Right Tool for the Job
Sometimes, small commits are not possible or reasonable:
Splitting code changes into too many small commits can actually make it harder to review. If you changed the name of a variable that is used in 12 files then you should not create 12 separate commits. Since these changes belong together, they should be committed together, not separately.
If you do a lot of small commits then it is easy to end up with large pull requests which can be hard to review even though each commit for itself may be relatively easy to understand. Therefore, you should avoid long-running branches which goes against the idea of continuous improvement
Conclusion
Thanks for reading this short post about my thoughts about small commits in Git.
As you can see, there are lots of pro arguments for small commits in software projects. In my view, the most important aspect is getting feedback as early as possible. How do you approach this topic? Let me know in the comments.

本文を入力してください。

メモ

メモ・感想

キャンセル

Edit Reading

Basic Information

統計情報

本文

メモ

Send Report