Nowadays I do not write useful commit messages anymore.
The main reason is that most repositories I work in professionally use squash merges, meaning that all commits done in a branch are squashed into a single commit when merging the branch into the main branch.
The commit message of the squash commit is usually the title of the pull request, meaning that the individual commit messages are not very useful anymore.
The commit message ends up containing the PR description, which gives the what and why of the changes, which is generally enough.

With the rise of LLMs I have never found myself looking at the commit history and the commit messages to understand why things changed.
If something isn't working, I simply get the LLM to help me fix the problem.

Pre-LLMs era

• One liner describing what changed (not period terminated)
• A few lines describing in more details why things changed
• GPG signed commit

How to Write a Git Commit Message

• Separate subject from body with a blank line
• Limit the subject line to 50 characters
• Capitalize the subject line
• Do not end the subject line with a period
• Use the imperative mood in the subject line
• Wrap the body at 72 characters
• Use the body to explain what and why vs. how

References

• https://chris.beams.io/posts/git-commit/

General

• 3 different environments: development, staging, production
• Write migrations for schema changes
• Use ORM if possible over raw queries
• Always make it possible for testers to report the version they tested against
  • Simplest is to have a meta field in the head section

Steps

• Mockups
• SRS
• Database and software architecture
• Implementation
• Test/QA
• Deployment

See also

• Software project basics

LLM-assisted flow

• Use the task background + acceptance criteria as plan prompt (manual)
• Use the planning feature of the agent and let it generate a plan (LLM)
• Review the plan and adjust as necessary (manual)
  • Ensure the presence of tests
• Let the agent implement the code based on the plan (LLM)
• Review the code implemented by the agent (manual)
  • Ensure it meets the acceptance criteria
  • Ensure code quality and standards
• Manually verify that functionality is working as expected (manual)
• Commit code on a branch (manual)
• Push to the central repository (manual)
• Verify that CI passes
• Create pull request (manual + LLM generated description)

Pre-LLMs flow

• Make sure you understand what you have to implement
• Make it work
• Write a test for what you implemented
• Refactor the code for reusability/code standard
• Verify that your code passes linting and tests
• Commit your code on a branch
• Push to the central repository
• Verify that CI passes
• Create pull request
• Annotate code to explain intent of changes

• Always prioritize your work
• Always work on something that is a task in a task tracking system
  • You should always be able to tell someone else what task you are working on and link them to that task
• Always provide an agenda when you book meetings with others

• Code changes are stored in git
• Setup continuous integration (e.g., GitHub Actions)
• Use dependency management (e.g., uv)
• Have a testing framework (e.g., pytest)
• Define a code standard, enforced through tools and not documentation (e.g., ruff)
• Prefer typed function/method over dynamic types
• On every commit to git
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
    • Code coverage should be recorded during tests and a report made available
• Prior to pushing
  • Use an LLM tool to review the changes to identify potential issues
• On pushes, the CI should
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
• A project repository must have
  • a README.md explaining how to run the project on your own computer
  • a RELEASING.md explaining how to release the code
  • a CHANGELOG.md listing relevant changes made
• Responsibilities are made explicit in terms of roles
• Critical roles, such as project lead, must have a backup/shadow individual
• Setup telemetry, alerts, profiling, logging