32 lines
1.3 KiB
Markdown
32 lines
1.3 KiB
Markdown
---
|
|
title: No-one sees your clean-up commits
|
|
date: 2024-09-02
|
|
permalink: daily/2024/09/02/no-one-sees-your-clean-up-commits
|
|
tags:
|
|
- software-development
|
|
- refactoring
|
|
- git
|
|
- automated-testing
|
|
- test-driven-development
|
|
cta: d7eol
|
|
snippet: |
|
|
No-one sees your clean-up commits.
|
|
drupal_planet: true
|
|
---
|
|
|
|
When you're working on a task - [whether you're making it work or making it good][0], you can commit your code changes as often as you like.
|
|
|
|
You should definitely commit your changes every time you have a working iteration, even if it's not the complete or final version, or even if the code doesn't pass all the coding standards and static analysis checks.
|
|
|
|
Things can be fixed or improved in subsequent commits.
|
|
|
|
You can amend or squash commits locally so your clean-up and work-in-progress commits are removed before you push your final version to your remote repository.
|
|
|
|
Whilst test-driven development says you should work in small feedback loops and steps, you don't need to push every commit as you wrote them.
|
|
|
|
Until you run `git push`, your commits are yours and yours only.
|
|
|
|
You have the opportunity to tidy up and organise your changes - making your commits easier to review and more likely to be approved in a code review.
|
|
|
|
[0]: {{site.url}}/daily/2024/08/31/make-it-work-then-make-it-good
|