You fixed a typo. You need a ticket.

You spotted a production bug. You need a ticket.

You updated a dependency. You need a ticket.

No ticket, no commit. That's the rule.

The Problem

Some companies require every single change to have a ticket. Everything. A ticket for whitespace. A ticket for fixing a log message. A ticket for a one-line bug fix.

The reasoning: "We need traceability. What if we need to know why this change was made six months from now?"

It sounds reasonable. It's not.

The Reality

You're deep in the code. You spot a bug. One-line fix. Takes 30 seconds.

But you don't have a ticket. So you stop, open your browser, create a ticket, fill in the fields, assign it, set priority, copy the number, go back to your editor, and finally commit.

That 30-second fix just took 5 minutes. Your flow is dead.

Multiply that by every tiny fix in a day. That's hours wasted every week. That's momentum killed.

When Speed Matters

Production is down. Users can't log in. You know what's wrong - a one-character typo. You can fix it in 10 seconds.

But policy says you need a ticket. Create it. Wait for triage. Wait for approval. By the time you get permission, users have been locked out for 30 minutes.

The process is more important than the product.

The Myths

"Future developers will need to understand why changes were made."

If you can't understand a commit message that says "Fix typo in variable name", you have bigger problems than missing tickets. The diff is almost always more informative anyway.

In 15+ years, I've rarely needed to trace a small fix back to a ticket. And when I did, the ticket just said "bugfix" or "Per conversation with John". Zero value.

What This Really Is

This policy reveals fundamental distrust. The assumption is that without tickets, developers will make arbitrary changes for no reason.

If you don't trust your developers to use judgment about when a one-line fix needs formal documentation, you've hired the wrong people.

The Alternative

Big features? Need a ticket. Complex bugs? Document them. Significant changes? Track them.

Quick fixes? Typos? Dependency updates? Let developers commit with a clear message and move on.

Commit messages exist for a reason. Git history exists for a reason. Code reviews exist for a reason. You don't need a ticket for everything.

The Real Cost

• Broken flow state
• Hours wasted on bureaucracy
• Slower production fixes
• Developer burnout
• Skipped improvements (not worth the overhead)

You're not gaining traceability. You're gaining theater. The appearance of rigor while actually slowing everything down.

Conclusion

No ticket, no commit is a policy designed by people who don't write code for people who do.

It values process over results and control over trust. It treats developers like assembly line workers who need monitoring rather than professionals who exercise judgment.

If your organization requires a ticket for every commit, you don't have a development process. You have a development obstacle course.

Good luck shipping anything fast.