How to fix remote: GitLab: Commit message does not follow the pattern in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 265 views

This error occurs when GitLab push rules reject your commit because the commit message doesn't match the required regex pattern. You need to amend your commit message to include required elements like issue numbers, ticket references, or specific formats.

Quick fix

Fixes remote: GitLab: Commit message does not follow the pattern

# The error typically looks like:
remote: GitLab: Commit message does not follow the pattern 'JIRA-\d+'
# Or
remote: GitLab: Commit message does not follow the pattern 'workitem \d+'
# Or
remote: GitLab: Commit message does not follow the pattern '^(feat|fix|docs|style|refactor|test|chore):'
  1. Identify the required commit message pattern
  2. Amend your commit message to match the pattern
  3. Fix multiple commits with interactive rebase
  4. Check and understand the push rules
git — error
# The error typically looks like:
remote: GitLab: Commit message does not follow the pattern 'JIRA-\d+'
# Or
remote: GitLab: Commit message does not follow the pattern 'workitem \d+'
# Or
remote: GitLab: Commit message does not follow the pattern '^(feat|fix|docs|style|refactor|test|chore):'
remote: GitLab: Commit message does not follow the pattern

What this error means

The error "remote: GitLab: Commit message does not follow the pattern" means your GitLab repository or group has **push rules** configured that enforce a specific commit message format. When you push commits, GitLab validates each commit message against a regular expression pattern, and if any commit doesn't match, the entire push is rejected. Push rules are a GitLab feature that helps teams enforce commit message conventions. Common requirements include: - Referencing issue/ticket numbers (e.g., "JIRA-123", "Fixes #456") - Following conventional commit formats (e.g., "feat:", "fix:", "docs:") - Including specific keywords or project identifiers This is a server-side validation that cannot be bypassed without changing your commit message or having an admin modify the push rules. The error will show you the exact regex pattern that your commit message failed to match.

Typical symptoms

  • Push to GitLab fails with 'Commit message does not follow the pattern' error
  • Error shows a regex pattern like 'JIRA-\d+' or 'workitem \d+'
  • Initial commits to new projects are rejected
  • Merge trains fail with commit message validation errors
  • semantic-release or automated tools fail when pushing
  • Push succeeds on one branch but fails on another with different rules
  • CI/CD pipelines fail during push operations
  • Git notes pushes are rejected by commit message rules

Common causes

  1. Commit message doesn't include required issue/ticket reference number
  2. Commit message format doesn't match the required conventional commit style
  3. Group or project-level push rules require specific patterns you're unaware of
  4. Merge commit messages created by GitLab UI don't match the pattern
  5. Automated tools like semantic-release or Renovate push commits without required format
  6. Git notes are being validated against commit message rules
  7. Multi-line commit messages use different newline characters than the regex expects
  8. You inherited global push rules when creating a new project

How to fix "remote: GitLab: Commit message does not follow the pattern"

1Identify the required commit message pattern

First, look at the error message to see what pattern is required:

bash
# The error typically looks like:
remote: GitLab: Commit message does not follow the pattern 'JIRA-\d+'
# Or
remote: GitLab: Commit message does not follow the pattern 'workitem \d+'
# Or
remote: GitLab: Commit message does not follow the pattern '^(feat|fix|docs|style|refactor|test|chore):'

The pattern in quotes is a regular expression (regex). Common patterns include:
- JIRA-\d+ - Requires JIRA ticket like "JIRA-123"
- workitem \d+ - Requires work item number
- #\d+ - Requires issue number like "#456"
- ^(feat|fix|docs): - Requires conventional commit prefix

Once you know the pattern, you can format your commit message accordingly.

2Amend your commit message to match the pattern

Use git commit --amend to modify your most recent commit message:

bash
# Amend the last commit with a new message
git commit --amend -m "JIRA-123: Add initial project setup"

# Or for conventional commit format
git commit --amend -m "feat: add initial project setup (#123)"

# Or open an editor to modify the message
git commit --amend

# Then force push if you already pushed the old commit
git push --force-with-lease

Tips for matching common patterns:
- Include the ticket number at the start: "JIRA-456: Your message"
- Use conventional commits: "fix: resolve login bug"
- Reference issues: "Add feature (closes #789)"

The message just needs to contain the required pattern somewhere—it doesn't always need to be at the beginning.

3Fix multiple commits with interactive rebase

If multiple commits need message changes, use interactive rebase:

bash
# Rebase the last N commits (e.g., last 3)
git rebase -i HEAD~3

# In the editor, change 'pick' to 'reword' for commits you want to edit:
# reword abc1234 Initial commit
# pick def5678 Add feature
# reword ghi9012 Fix bug

# Save and close. Git will pause at each 'reword' commit
# Edit each message to include the required pattern

# After completing the rebase, force push
git push --force-with-lease

Warning: Interactive rebase rewrites history. Only do this for commits that haven't been shared with others, or coordinate with your team before force pushing.

4Check and understand the push rules

View the push rules configured for your project:

1. Project-level rules:
- Go to your project in GitLab
- Navigate to Settings → Repository
- Expand Push rules
- View "Require expression in commit messages"

2. Group-level rules:
- Go to your group
- Navigate to Settings → Repository
- Check the Push rules section

3. Instance-level rules (admin only):
- Admin Area → Push Rules
- These serve as templates for new projects

GitLab uses RE2 regex syntax. Test patterns at [regex101.com](https://regex101.com) with the "Golang" flavor selected.

Important: Commit messages in GitLab UI use \r\n for newlines. If you see patterns with \n, they might need (\r\n?|\n) for cross-platform compatibility.

5Request push rule modifications (if needed)

If the push rules are too restrictive or causing legitimate issues:

Ask your team lead or GitLab admin to:

1. Review the regex pattern - The pattern might be incorrectly configured
2. Add exceptions for merge commits - Merge commit messages are auto-generated
3. Exclude certain branches - Some rules shouldn't apply to all branches
4. Update the pattern - Make it more flexible while maintaining standards

For merge commit issues:

bash
# If pattern '^Merge.*$' fails on merge trains,
# the admin can adjust to handle GitLab's auto-generated format
^(Merge|feat|fix|docs|chore|refactor|test|style):?.*

For CI/CD tools like semantic-release:
Some tools push git notes or automated commits that may not match patterns. Admins can exclude these by updating rules or adjusting the tool configuration.

6Configure commit message hooks locally

Prevent rejected pushes by validating commit messages locally before pushing:

bash
# Create a commit-msg hook
cat > .git/hooks/commit-msg << 'EOF'
#!/bin/bash

# Pattern required by your GitLab (adjust to match your rules)
PATTERN="JIRA-[0-9]+"

MESSAGE=$(cat "$1")

if ! echo "$MESSAGE" | grep -qE "$PATTERN"; then
    echo "ERROR: Commit message must contain a JIRA ticket (e.g., JIRA-123)"
    echo "Your message: $MESSAGE"
    exit 1
fi
EOF

chmod +x .git/hooks/commit-msg

For team-wide hooks, use a shared hooks directory:

bash
# In your project root
mkdir -p .githooks
# Add your commit-msg hook there

# Configure git to use it
git config core.hooksPath .githooks

# Commit the hooks to share with team
git add .githooks

This catches invalid commit messages before they're created, saving you from amending later.

7Handle automated tool failures

If automated tools like semantic-release, Renovate, or GitLab CI fail:

For semantic-release:

javascript
// In your release.config.js, format commits to match push rules
module.exports = {
  plugins: [
    ['@semantic-release/commit-analyzer', {
      releaseRules: [
        { type: 'feat', release: 'minor' },
        { type: 'fix', release: 'patch' }
      ]
    }],
    ['@semantic-release/release-notes-generator'],
    ['@semantic-release/git', {
      // Customize commit message to match your pattern
      message: 'chore(release): ${nextRelease.version} [skip ci] JIRA-0'
    }]
  ]
};

For Renovate:

json
{
  "commitMessagePrefix": "JIRA-0: ",
  "commitMessageTopic": "{{depName}}"
}

For git notes issues:
Git notes are sometimes validated against commit message rules. You may need to ask your admin to exclude refs/notes/* from push rules or use a workaround:

bash
# Push notes separately with a different configuration
GIT_NOTES_REF=refs/notes/commits git push origin refs/notes/*

Advanced notes

### Understanding GitLab Push Rules

Push Rule Hierarchy:
1. Instance-level (Admin Area) - Templates for new projects
2. Group-level - Apply to all projects in the group
3. Project-level - Override group settings for specific projects

When you create a new project, it inherits rules from the group or instance level. After creation, project rules are independent copies—changes to group rules don't automatically propagate.

### Common Regex Patterns

JIRA ticket required:

regex
JIRA-\d+
# Matches: JIRA-123, feat: add login JIRA-456
# Fails: Initial commit, fix bug

Conventional commits:

regex
^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?!?:
# Matches: feat: add login, fix(auth): resolve bug
# Fails: Add new feature, Fixed the bug

Issue reference required:

regex
(closes?|fixes?|resolves?)\s+#\d+
# Matches: closes #123, Fixes #456
# Fails: Add feature, Updated docs

Reject merge commits (use with caution):

regex
^Merge branch
# Rejects auto-generated merge commit messages

### RE2 Regex Syntax Notes

GitLab uses RE2, which has some limitations compared to PCRE:
- No lookahead/lookbehind assertions
- No backreferences
- Limited to 511 characters

Multiline handling:
- RE2 has multiline mode enabled by default
- Disable with (?-m) at the start of the pattern
- For cross-platform newlines, use (\r\n?|\n) instead of \n

### Rejecting Patterns

Besides requiring patterns, you can also reject them:

Reject WIP commits:

regex
^\[?WIP\]?
# Rejects: WIP: working on feature, [WIP] testing

Reject trailing punctuation:

regex
[[:^punct:]]\b$
# The word boundary prevents false negatives from trailing newlines

### Merge Request Integration

Push rules can conflict with merge request workflows:

1. Squash commits: When squashing, ensure the final message matches
2. Merge commits: Auto-generated messages may not match patterns
3. Merge trains: Can fail if merge commit messages don't comply

Best practices:
- Configure merge commit templates in project settings
- Allow merge commit patterns in your regex
- Use semi-linear history to avoid merge commits

### Debugging Push Rule Failures

bash
# View your commit messages before pushing
git log --oneline origin/main..HEAD

# Test a message against a pattern locally
echo "Your commit message" | grep -E "JIRA-\d+"

# See the full commit message
git log -1 --format=%B

### GitLab Premium/Ultimate Features

Some push rule features require higher tiers:
- Reject unsigned commits - Require GPG-signed commits
- Reject commits by committer - Verify committer email
- Branch name requirements - Enforce branch naming conventions

These work alongside commit message rules for comprehensive governance.

Frequently asked questions

What does "remote: GitLab: Commit message does not follow the pattern" mean?
The error "remote: GitLab: Commit message does not follow the pattern" means your GitLab repository or group has push rules configured that enforce a specific commit message format. When you push commits, GitLab validates each commit message against a regular expression pattern, and if any commit doesn't match, the entire push is rejected. Push rules are a GitLab feature that helps teams enforce commit message conventions.
How do I fix "remote: GitLab: Commit message does not follow the pattern"?
This error occurs when GitLab push rules reject your commit because the commit message doesn't match the required regex pattern. You need to amend your commit message to include required elements like issue numbers, ticket references, or specific formats.
What causes "remote: GitLab: Commit message does not follow the pattern"?
Commit message doesn't include required issue/ticket reference number Commit message format doesn't match the required conventional commit style Group or project-level push rules require specific patterns you're unaware of
Is the "remote: GitLab: Commit message does not follow the pattern" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading