如何配置VSTS Git策略以阻止含冒犯性内容的commit/push？

Absolutely, you can enforce rules to block commits or pushes containing rude/offensive language—with a focus on frontend assets—in Azure DevOps (formerly VSTS) Git. Below are two practical, reliable approaches tailored to your needs:

1. Branch Policies + Custom Validation Script (Recommended) #

This is the most straightforward method for cloud-hosted Azure DevOps, as it leverages built-in branch protection features with a custom script to scan content.

Step 1: Create a Validation Pipeline #

Build a YAML pipeline that runs a script to check both commit messages and frontend asset files:

#!/bin/bash

# Define your list of offensive words/phrases (update this as needed)
OFFENSIVE_TERMS=("rude_word" "offensive_phrase" "vulgar_term")

# Check the latest commit message
LATEST_COMMIT_MSG=$(git log --format=%B -n 1 HEAD)
for TERM in "${OFFENSIVE_TERMS[@]}"; do
  if echo "$LATEST_COMMIT_MSG" | grep -qi "$TERM"; then
    echo "❌ ERROR: Commit message contains offensive language: '$TERM'"
    exit 1
  fi
done

# Check frontend asset files (adjust extensions to match your stack)
FRONTEND_EXTENSIONS="\.(js|ts|html|css|vue|jsx|tsx|scss)$"
CHANGED_FRONTEND_FILES=$(git diff --name-only HEAD~1 HEAD | grep -E "$FRONTEND_EXTENSIONS")

for FILE in $CHANGED_FRONTEND_FILES; do
  for TERM in "${OFFENSIVE_TERMS[@]}"; do
    if grep -qi "$TERM" "$FILE"; then
      echo "❌ ERROR: Frontend file '$FILE' contains offensive language: '$TERM'"
      exit 1
    fi
  done
done

echo "✅ All offensive language checks passed!"
exit 0

• Adjust the OFFENSIVE_TERMS array and FRONTEND_EXTENSIONS regex to match your team's tech stack and policy needs.
• The script uses case-insensitive checks (-qi flag) to catch more accidental violations.

Step 2: Attach the Pipeline to Branch Policies #

1. Go to your Azure DevOps project → Repos → Branches.
2. Find the branch you want to protect (e.g., main, develop), click the ... menu → Branch policies.
3. Under Build validation, click Add build policy.
4. Select your validation pipeline, set the policy to Required, and configure trigger settings (e.g., run on every pull request/push).

Any push or pull request targeting this branch will now run the script—if offensive language is detected, the pipeline fails, and the commit/push is blocked.

2. Custom Server-Side Hooks (For Self-Hosted Azure DevOps Server) #

If you're using a self-hosted Azure DevOps Server, you can use pre-receive hooks to block pushes directly at the server level:

• Access your Azure DevOps Server's repository server files.
• Create a pre-receive hook script that scans commit messages and file content (similar to the script above).
• Configure the hook to run before any push is accepted; if violations are found, the script exits with a non-zero code to block the push.

This method is more hands-on but avoids relying on pipeline infrastructure.

Additional Tips #

• Centralize your word list: Store offensive terms in a separate config file (e.g., offensive-terms.txt) so your team can update it without modifying the script.
• Scan historical content: Run the script manually against your existing repository to clean up any pre-existing offensive language before enforcing the policy.
• Educate your team: Share the policy and word list with your team to set clear expectations, reducing accidental violations.

内容的提问来源于stack exchange，提问作者Nil Pun