Skip the mental overhead of writing git commit messages. These 25 prompts generate clean, descriptive commits that follow industry standards and make your git history searchable and useful.
These prompts pair well with Jasper AI for Developers-specific tone control, or Copy.ai for fast iteration.
Feature Implementation Commits
You are writing a git commit message for a new feature implementation.
Feature type: {bug_fix / new_feature / enhancement / refactor} Component affected: {component_name} What changed: {brief_description_of_change} Files modified: {main_file_or_directory} Breaking change: {yes / no} Issue number: {issue_number_or_none} Scope: {frontend / backend / database / api / ui}
Write a commit message following conventional commits format. Start with type(scope): description. Keep the first line under 50 characters. Include a body paragraph explaining the what and why in 2-3 sentences if this is a significant change. Reference the issue number if provided.
When to use it: Right after completing a feature branch and staging your changes for commit.
Pro tip: If your description is over 50 characters, move details to the body. The first line shows up in git log —oneline and needs to be scannable.
You are creating a commit message for a UI component update.
Component name: {component_name} Change type: {styling / functionality / accessibility / responsiveness} Specific change: {what_you_modified} User impact: {how_users_will_see_this} Framework: {react / vue / angular / vanilla} Testing status: {tested / needs_testing}
Generate a conventional commit message under 50 characters for the subject line. Include the component scope and be specific about what changed. Add a body section explaining the user-facing impact in one sentence.
When to use it: After making changes to any user-facing component before pushing to your feature branch.
Pro tip: Always include the component name in the scope. “feat(Button): add loading state” is better than “feat(ui): update button”.
You are writing a commit for API endpoint changes.
Endpoint: {endpoint_path} HTTP method: {GET / POST / PUT / DELETE / PATCH} Change description: {what_you_modified} Breaking change: {yes / no} Response format change: {yes / no} Authentication required: {yes / no / unchanged} Version: {api_version_if_applicable}
Create a commit message following conventional commits. Use “feat” for new endpoints, “fix” for bug fixes, “BREAKING CHANGE” in footer if breaking. Keep subject under 50 chars. Include endpoint path in scope if helpful.
When to use it: Before committing any changes to API routes, controllers, or endpoint logic.
Pro tip: If you’re changing request/response schemas, that’s almost always a breaking change. Call it out explicitly in the commit footer.
You are documenting a database schema change in a commit message.
Table affected: {table_name} Change type: {migration / rollback / index / constraint} Migration file: {migration_filename} Specific change: {columns_added_removed_modified} Data impact: {data_preserved / data_modified / data_deleted} Rollback available: {yes / no}
Write a conventional commit message for this database change. Use “feat” for new tables/columns, “fix” for constraint fixes, “refactor” for optimization. Include table name in scope. Add migration filename in body. Warn about data impact if relevant.
When to use it: When committing database migrations or schema modifications.
Pro tip: Always mention if the migration is reversible. Your future self will thank you when you need to rollback in production.
You are writing a commit for dependency updates.
Package name: {package_name} Version change: {from_version} to {to_version} Update type: {patch / minor / major} Breaking changes: {yes / no / unknown} Reason for update: {security / feature / bugfix / maintenance} Testing completed: {yes / no / partial} Other packages affected: {list_or_none}
Generate a conventional commit message for this dependency update. Use “chore” for routine updates, “fix” for security patches, “feat” if adding new functionality. Include package name and version in subject line under 50 characters. List any breaking changes or affected packages in body.
When to use it: After running package updates and verifying everything still works.
Pro tip: Major version updates should always get a detailed body explaining what you tested. Future debugging sessions depend on this context.
Bug Fix and Hotfix Commits
You are creating a commit message for a critical production bug fix.
Bug description: {brief_bug_description} Affected functionality: {what_was_broken} Root cause: {underlying_issue} Fix approach: {how_you_solved_it} Files changed: {main_files_modified} Hotfix: {yes / no} Issue tracker: {ticket_number_or_none}
Write a conventional commit using “fix” type. Keep subject under 50 characters with clear problem description. Include body explaining root cause and solution approach in 2-3 sentences. Reference ticket number if available. Mark as BREAKING CHANGE if the fix changes existing behavior.
When to use it: Before committing any bug fix, especially urgent production issues.
Pro tip: For hotfixes, include “hotfix” in the commit body. This helps identify emergency patches when reviewing git history later.
You are documenting a performance optimization fix.
Performance issue: {slow_query / memory_leak / cpu_spike / load_time} Affected component: {component_or_function_name} Optimization method: {caching / indexing / algorithm / refactor} Performance improvement: {specific_metrics_if_available} Backward compatibility: {maintained / changed} Testing approach: {how_you_verified_improvement}
Create a “perf” type commit message under 50 characters describing the optimization. Include component scope. Add body section with before/after metrics if available and explanation of what was optimized. Note any compatibility changes.
When to use it: After implementing performance improvements and measuring the impact.
Pro tip: Include specific metrics when possible. “reduce query time from 2s to 200ms” is more valuable than “improve query performance”.
You are writing a commit for a security vulnerability fix.
Vulnerability type: {injection / xss / csrf / auth / data_exposure} Severity level: {low / medium / high / critical} Affected endpoints: {specific_routes_or_components} Fix description: {how_vulnerability_was_addressed} CVE number: {cve_if_applicable} Security team notified: {yes / no} Disclosure timeline: {public / private / coordinated}
Generate a “security” type conventional commit message. Keep subject line under 50 characters without revealing vulnerability details. Include severity in body. Explain fix approach without exposing attack vectors. Reference CVE if public.
When to use it: When fixing any security-related issues before they’re disclosed publicly.
Pro tip: Never describe the attack method in the commit message. Focus on what you fixed, not how someone could have exploited it.
You are documenting a configuration or environment bug fix.
Environment: {development / staging / production / all} Config file: {filename_or_service} Issue description: {what_was_misconfigured} Fix applied: {specific_changes_made} Services affected: {list_of_services} Deployment required: {yes / no} Rollback plan: {available / manual / none}
Write a “fix” type commit for this configuration change. Include config scope in parentheses. Keep subject under 50 characters. Add body explaining what was wrong and how it’s fixed. Note if deployment or service restart is required.
When to use it: After fixing environment variables, config files, or deployment settings.
Pro tip: Config fixes often require deployment. Always note this in the commit body so your team knows to redeploy after merging.
You are creating a commit for a cross-browser compatibility fix.
Browser affected: {chrome / firefox / safari / edge / ie11} Issue description: {rendering / functionality / performance} Specific problem: {what_didnt_work} Solution approach: {polyfill / fallback / vendor_prefix / workaround} Testing completed: {browsers_tested} Graceful degradation: {yes / no}
Generate a “fix” type conventional commit message for this browser compatibility issue. Include browser name in scope or subject. Keep under 50 characters. Add body section listing all browsers tested and any graceful degradation notes.
When to use it: After testing and fixing browser-specific issues.
Pro tip: Always test your fix in multiple browsers, not just the one that had the problem. Browser fixes can break other browsers.
Code Quality and Refactoring
You are writing a commit for a code refactoring that improves maintainability.
Component refactored: {class_function_or_module_name} Refactoring type: {extract_method / rename / restructure / simplify} Reason for refactoring: {code_smell_or_improvement_goal} Lines of code change: {approximate_addition_deletion} Functionality changed: {yes / no} Tests updated: {yes / no / not_applicable} Breaking changes: {yes / no}
Create a “refactor” type conventional commit message under 50 characters. Include component scope. Add body explaining why refactoring was needed and confirm no functional changes. Note if tests were updated to match new structure.
When to use it: After cleaning up code without changing its external behavior.
Pro tip: Refactor commits should never mix functional changes. If you fix a bug while refactoring, make it two separate commits.
You are documenting a code style and formatting cleanup.
Scope: {single_file / directory / entire_codebase} Style changes: {indentation / naming / imports / structure} Linter used: {eslint / prettier / black / rubocop} Files affected: {number_of_files_or_specific_files} Automated tool: {yes / no} Style guide: {company_standard / airbnb / google / custom}
Write a “style” type commit message under 50 characters. Include scope in parentheses. Keep body brief explaining what style rules were applied. Note if changes were automated vs manual. Confirm no functional changes.
When to use it: After running linters, formatters, or manually cleaning up code style.
Pro tip: Style commits are perfect for automated tools. Run your linter, commit the changes, then start your actual feature work in a separate commit.
You are creating a commit for removing dead code or unused dependencies.
Removal type: {dead_functions / unused_imports / deprecated_code / unused_dependencies} Scope: {specific_files_or_packages_removed} Reason for removal: {no_longer_needed / deprecated / security / cleanup} Impact analysis: {no_references_found / safe_to_remove / tested} Size reduction: {lines_removed_or_package_size} Verification method: {grep_search / ide_analysis / test_suite}
Generate a “remove” or “chore” type conventional commit under 50 characters describing what was removed. Include scope. Add body confirming removal is safe and how you verified no dependencies exist.
When to use it: When cleaning up unused code, imports, or dependencies during maintenance.
Pro tip: Before removing anything, grep your entire codebase for references. Dead code sometimes gets called from config files or templates.
You are writing a commit for test coverage improvements.
Test type: {unit / integration / e2e / snapshot} Component tested: {function_class_or_feature_name} Coverage change: {percentage_increase_if_known} Test scenarios added: {number_of_new_test_cases} Testing framework: {jest / pytest / rspec / cypress} Edge cases covered: {specific_scenarios}
Create a “test” type conventional commit message under 50 characters. Include component scope. Add body listing specific scenarios now covered. Note coverage percentage improvement if available.
When to use it: When adding tests without changing production code functionality.
Pro tip: Mention specific edge cases in the commit body. “Add tests for null inputs and empty arrays” is more useful than “improve test coverage”.
You are documenting code documentation improvements.
Documentation type: {inline_comments / jsdoc / docstrings / readme} Scope: {specific_functions_or_entire_module} Documentation added: {api_docs / usage_examples / parameter_descriptions} Audience: {developers / end_users / maintainers} Documentation tool: {jsdoc / sphinx / yard / gitbook} Examples included: {yes / no}
Write a “docs” type conventional commit under 50 characters describing documentation scope. Include what type of docs were added in body. Note if examples or usage instructions were included.
When to use it: When adding or improving code documentation without changing functionality.
Pro tip: Good documentation commits include examples. Show how to use the function, don’t just describe what it does.
Git History and Workflow
You are creating a commit message for merging a feature branch.
Feature branch: {branch_name} Feature description: {brief_feature_summary} Pull request number: {pr_number_if_applicable} Code review completed: {yes / no} Testing status: {all_tests_pass / pending_tests} Conflicts resolved: {yes / no / none} Breaking changes: {yes / no}
Generate a merge commit message that summarizes the feature being merged. Start with “Merge” and include branch name. Add body paragraph describing the feature and noting any breaking changes. Reference PR number if available.
When to use it: When merging feature branches into main or development branches.
Pro tip: Use “git merge —no-ff” to create explicit merge commits. This preserves branch history and makes features easier to revert later.
You are writing a commit for reverting a previous change.
Commit being reverted: {commit_hash_or_description} Reason for revert: {bug_introduced / breaking_change / performance_issue} Impact of original commit: {what_it_was_supposed_to_fix} Issue with original: {why_it_needs_reverting} Alternative approach: {planned_fix_or_none} Urgency: {immediate / can_wait / hotfix_needed}
Create a “revert” type commit message under 50 characters referencing the original commit. Add body explaining why revert was necessary and what the original commit was trying to achieve. Note if alternative fix is planned.
When to use it: When you need to undo a previous commit that caused problems.
Pro tip: Use “git revert” command rather than manual changes. This creates a proper revert commit that can itself be reverted if needed.
You are documenting an initial project setup or scaffolding commit.
Project type: {web_app / api / library / tool} Framework used: {react / express / django / rails} Build tools: {webpack / vite / parcel / rollup} Package manager: {npm / yarn / pnpm} Initial features: {basic_structure / example_code / config_files} Template source: {create_react_app / custom / boilerplate}
Write an “init” or “feat” type commit message for initial project setup. Keep subject under 50 characters. Add body listing main tools and frameworks included. Note if using standard boilerplate or custom setup.
When to use it: For the first commit in a new repository or when setting up new project structure.
Pro tip: Include version numbers of major dependencies in the commit body. This helps when troubleshooting compatibility issues later.
You are creating a commit for release preparation changes.
Release version: {version_number} Release type: {major / minor / patch / hotfix} Changes included: {features / bugfixes / security / breaking} Changelog updated: {yes / no} Version bumped in: {package_json / setup_py / cargo_toml} Release notes: {written / pending / not_needed} Deployment ready: {yes / no / staging_only}
Generate a “release” or “chore” type commit message for release preparation. Include version number in subject under 50 characters. Add body summarizing what’s included in this release and noting if changelog was updated.
When to use it: Before tagging and deploying a new version of your application.
Pro tip: Release commits should only contain version bumps and changelog updates. Keep feature commits separate from release preparation.
You are writing a commit for CI/CD pipeline or build configuration changes.
CI system: {github_actions / jenkins / gitlab_ci / circle_ci} Change type: {new_workflow / fix_failing_build / optimization / security} Specific change: {what_you_modified} Build stages affected: {test / deploy / lint / security_scan} Environment impact: {all / production_only / development_only} Testing completed: {pipeline_tested / local_only / untested}
Create a “ci” type conventional commit under 50 characters describing the CI change. Include system scope if helpful. Add body explaining what stages are affected and if change impacts production deployments.
When to use it: When modifying build scripts, CI workflows, or deployment configurations.
Pro tip: Test CI changes in a feature branch first. Broken CI affects the entire team, so verify your changes work before merging to main.
Frequently Asked Questions
What’s the difference between conventional commits and regular commit messages?
Conventional commits follow a structured format: type(scope): description. This makes commits searchable, enables automated changelog generation, and helps teams understand changes quickly. Regular commits can be any format but lack consistency.
Should I write commit messages for every small change or squash them together?
Write individual commits during development, then squash related changes before merging. Each commit in main branch should represent a complete logical change that could be reverted independently without breaking functionality.
How do I handle commit messages when pair programming or collaborating?
Use “Co-authored-by: Name email@example.com” in the commit body to credit all contributors. The person committing writes the message but includes co-author lines for everyone who contributed code to that commit.