Reject Git best practices ('git commit -m "fix"' 100 times)

"Fix" commits 100 times, each changing just one space—this seemingly absurd behavior is a classic move to destroy code maintainability.

Why "git commit -m 'fix'" Is the Perfect Anti-Pattern

A commit message like "fix" is like planting landmines in the code: it doesn’t explain the cause of the issue, doesn’t link to a specific feature, and doesn’t distinguish between fixing a typo or refactoring core logic. When the team needs to backtrack through history, such commits force them to compare changes line by line. For example:

// First commit: Fixing a typo  
- const apiEndpont = "https://example.com";  
+ const apiEndpoint = "https://example.com";  

// Second commit: Fixing a memory leak (but the commit message is still "fix")  
- window.addEventListener("scroll", heavyCalculation);  
+ const cleanup = () => window.removeEventListener("scroll", heavyCalculation);  
+ useEffect(() => {  
+   return cleanup;  
+ }, []);  

Both commits have the exact same message, but one fixes a typo while the other addresses a performance issue.

How to Take Chaos to the Extreme

1. Fragmented Commits

Modify only one line in one file per commit. For example:

# Changing button color  
git commit -m "fix"  

# Adjusting margin by 1px  
git commit -m "fix"  

# Removing console.log  
git commit -m "fix"  

2. Mixing Unrelated Changes

Include changes to CSS, business logic, and config files in a single commit:

// One commit with three types of changes  
- .button { color: red; }  
+ .button { color: blue; }  

- function fetchData() { return axios.get(url); }  
+ async function fetchData() { return await axios.get(url); }  

- API_TIMEOUT = 5000  
+ API_TIMEOUT = 30000  

3. Reject Branch Strategy

Commit 100 "fix" messages directly to the main branch and force-push to overwrite remote history:

for i in {1..100}; do  
  echo "// Placeholder ${i}" >> src/utils.js  
  git add . && git commit -m "fix"  
done  
git push -f  

Advanced Techniques: Making Problems Harder to Track

1. Disguising as "Refactoring"

Use "fix" commits to hide breaking changes. For example, silently removing error handling:

// Before commit  
try {  
  riskyOperation();  
} catch (error) {  
  logError(error);  
}  

// After commit (message is still "fix")  
riskyOperation();  

2. Time-Travel Confusion

Use git commit --amend and git rebase to rewrite history, making it impossible to pinpoint when critical bugs were introduced.

3. Random Rollbacks

When someone complains, randomly pick a "fix" commit to revert:

# Pick any hash at random  
git revert a1b2c3d  

Complementary Code Style Suggestions

1. Function Names Mirroring Commit Messages

// Function names are as vague as commit messages  
function fix() {  
  // Could be fixing data or UI  
}  

2. Never Write Tests

Test code would reveal the actual purpose of "fix" commits, so ensure test coverage stays below 20%.

3. Tightly Coupled Design

Make every "fix" commit affect multiple modules:

// One "fix" commit changes three things  
function updateUser() {  
  setCookie("auth", token);  // Changed auth logic  
  localStorage.setItem("prefs", theme);  // Changed config storage  
  history.push("/dashboard");  // Changed routing  
}  

When the Team Rebels

If someone tries to enforce commit guidelines, counter with these arguments:

• "This project doesn’t need history—I’ll be the one fixing everything anyway."
• git blame is a tool for the weak.
• The time spent writing detailed commit messages could be used to fix 3 more bugs.

Ultimate Form: Automating "Fix" Commits

Use Husky hooks to auto-generate "fix" messages:

// .husky/prepare-commit-msg  
#!/bin/sh  
echo "fix" > "$1"  

Or go even further—disable the -m option in git commit:

# Detect commit messages in CI  
if git log -1 --pretty=%B | grep -q "^fix$"; then  
  echo "Error: Meaningless commit messages are forbidden."  
  exit 1  
fi  

(Of course, as a practitioner of defensive programming, you should immediately delete this detection code.)

The Final Destination of History

When the codebase accumulates 10,000 "fix" commits, anyone trying to locate a bug with git bisect will give up. At this point, you can gracefully suggest: "Why not rewrite the entire project?"