Comprehensive Rules for professional Git usage, covering commit conventions, branching models, automation, performance, and security.
You know the drill: messy commit histories, broken builds on main, merge conflicts that take hours to resolve, and that sinking feeling when you realize someone force-pushed over your work. These Git rules transform chaos into a predictable, professional workflow that keeps your team moving fast without breaking things.
Most teams treat Git like a necessary evil—something to endure rather than leverage. You're dealing with:
These aren't just annoyances—they're productivity killers that compound over time, making your codebase harder to maintain and your team slower to ship.
These Cursor Rules implement battle-tested Git practices used by high-performing development teams. They automate the boring stuff, prevent common mistakes, and create workflows that actually accelerate development instead of slowing it down.
What you get:
Before: 45-minute reviews of 300-line changes with unclear context
After: 10-minute reviews of focused, well-documented changes with semantic commit messages
# Instead of this mess:
git log --oneline
a1b2c3d fix
e4f5g6h more fixes
h7i8j9k forgot something
# You get this clarity:
feat(auth): add OAuth2 login flow
fix(api): resolve rate limiting edge case
chore(deps): update security patches
Before: Friday afternoon merge sessions where three developers untangle conflicting changes
After: Daily 2-minute rebases that catch conflicts early when they're trivial to fix
Before: "Who broke the build?" Slack threads and emergency rollbacks
After: Protected main branch that literally cannot accept code that doesn't pass CI
# Start a feature (auto-configured branch naming)
git switch -c feat/payment-integration
# Small, focused commits throughout the day
git commit -m "feat(payment): add Stripe API client"
git commit -m "feat(payment): implement checkout validation"
git commit -m "test(payment): add integration test suite"
# Daily rebase keeps you current (no merge hell later)
git fetch origin && git rebase origin/main
# Clean, reviewable PR ready in minutes, not hours
Result: Your feature branch stays current, conflicts are caught early, and reviewers see exactly what changed and why.
# When conflicts do happen, you have context
git rebase origin/main
# Auto-pausing at: "feat(payment): implement checkout validation"
# Edit the conflicted file with clear markers
git add src/checkout.js
git rebase --continue
# Done in 2 minutes instead of 2 hours
The difference: Semantic commit messages tell you exactly what each change does, making conflict resolution obvious instead of guesswork.
# Trunk-based development: always deployable main
git switch main
git pull origin main
git tag -a v2.1.0 -m "v2.1.0: payment integration and security updates"
# Auto-generated release notes from conventional commits
git log --pretty=format:"%s" v2.0.0..v2.1.0
Result: Releases become predictable events, not stressful adventures.
.cursorrules filenpm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
# Install pre-commit hooks
npm install --save-dev husky lint-staged
npx husky install
npx husky add .husky/pre-commit "npx lint-staged"
npx husky add .husky/commit-msg "npx commitlint --edit"
Configure lint-staged in package.json:
{
"lint-staged": {
"*.{js,ts,jsx,tsx}": ["eslint --fix", "prettier --write"],
"*.{json,md}": ["prettier --write"]
}
}
In your GitHub/GitLab repository settings:
For fast-moving teams: Trunk-based development with feature flags
For formal releases: Git Flow with release branches
For continuous deployment: GitHub Flow with protected main
# Conventional commits enable automated versioning
npm install --save-dev standard-version
npm run release # Auto-bumps version and generates changelog
# Track design assets without bloating the repo
git lfs track "*.psd" "*.sketch" "*.fig"
git add .gitattributes
git commit -m "chore(lfs): track design files"
# Scan for secrets before commits reach the server
git secrets --install
git secrets --register-aws
git secrets --scan
These Git rules don't just change how you commit code—they change how your entire team collaborates. You'll spend less time fighting your version control system and more time building features that matter.
The best part? Once these rules are in place, they enforce themselves. Your workflow gets better automatically, and new team members inherit professional Git practices from day one.
Ready to stop wrestling with Git and start making it work for you? Install these rules and watch your development workflow transform from chaotic to professional in a matter of days.
You are an expert in Git, GitHub, GitLab, Trunk-Based Development, Git Flow, GitHub Flow, Bash scripting, CI/CD tooling, Git LFS, and merge-conflict resolution.
Key Principles
- Favor clarity, traceability, and safety over speed.
- Commit small, logically-scoped changes frequently to enable easy rollback and review.
- Every change must be reviewable and reproducible; avoid force-pushing to shared branches.
- History is documentation: never rewrite public history.
- Automate everything that can be automated (tests, lint, formatting, hooks).
- Keep the main branch deployable at all times; use feature flags to hide incomplete work.
Git Rules ("Language-Specific")
Commit Messages
- Use Conventional Commits or similar semantic structure: `<type>(<scope>): <subject>`.
Example: `feat(auth): add OAuth2 login flow`.
- Subject line ≤ 50 chars, imperative mood, capitalized, no period.
- Blank line between subject and body. Body wrapped at 72 chars.
- Body explains *what* and *why*, not *how*.
- Reference issues with `Closes #123` in footer.
Branch Naming
- `main` or `trunk`: always releasable.
- Prefix short-lived branches:
• `feat/short-description`
• `bugfix/…`
• `hotfix/…`
• `chore/…`
Avoid uppercase, spaces, and long names (>50 chars).
Merging & Rebasing
- Keep feature branches < 3 days old. Rebase onto latest `main` daily: `git fetch && git rebase origin/main`.
- Never rebase a branch that others have pulled; use `git merge --no-ff` for shared feature branches.
- Use squashed merges for noisy WIP histories (`git merge --squash`) *before* opening PR.
Tagging & Releases
- Annotated tags only (`git tag -a v1.4.0 -m "v1.4.0"`).
- Follow Semantic Versioning.
- Create release notes automatically from Conventional Commits.
Large Files
- Track binaries via Git LFS: `git lfs track "*.psd"`.
- Run `git lfs prune` monthly in CI to keep repos slim.
Error Handling & Validation
- Protected branches: require PR, 2 approvals, passing CI, and linear history.
- Activate required status checks: lint, unit, security scan.
- Pre-commit hook (`.husky/pre-commit`) runs `lint-staged`, unit tests, and `git secrets --scan`.
- Resolve merge conflicts consciously:
1. `git status` to list conflicted files.
2. Edit sections between `<<<<<<<`/`=======`/`>>>>>>>` markers.
3. `git add` resolved files, then `git rebase --continue` or `git commit`.
- Abort risky operations: `git rebase --abort`, `git merge --abort`.
Framework-Specific Rules
Trunk-Based Development
- One `main` branch, short-lived (`<1d`) feature branches.
- Toggle incomplete code with feature flags; flags must default to off.
- Deploy from `main` continuously after CI passes.
Git Flow (only if formal release cadence required)
- Branches: `develop`, `release/*`, `hotfix/*`.
- Merge policy:
• Feature → develop (squash).
• Release → main & tag.
• Hotfix → main & develop.
- Delete `release/*` after merge to avoid drift.
GitHub Flow (lightweight)
- Single `main` branch; every PR must pass CI and get at least one review.
- Use Draft PRs to communicate WIP early.
Additional Sections
Testing & CI/CD
- CI runs on every push and PR: lint, tests, security, build artifacts.
- Do not allow merges if CI fails; activate "Require green to merge".
- Use `pre-push` hook to run e2e smoke tests (`npm run test:e2e -- --headless`).
Performance & Repository Hygiene
- Prune merged branches weekly (`git fetch -p` + server auto-delete).
- Run `git gc --aggressive --prune=now` monthly in CI maintenance job.
- Prefer shallow clones (`--depth 1`) in CI to speed up pipelines.
Security
- Enforce signed commits (`git config commit.gpgsign true`).
- Require 2FA on hosting platform.
- Scan secrets in hooks (`git secrets`, `truffleHog`).
Documentation & On-boarding
- Store these rules in `docs/git-rules.md` and link from `CONTRIBUTING.md`.
- New developers run `scripts/setup-git.sh` to install hooks and configure signing.
Examples
Creating a Feature Branch
```bash
# create and push
git switch -c feat/user-onboarding
# work …
git add .
git commit -m "feat(onboarding): create signup wizard"
# rebase onto main before PR
git fetch origin
git rebase origin/main
# open PR
```
Resolving a Conflict During Rebase
```bash
git rebase origin/main # stops at conflict
# edit affected file
git add path/to/file
git rebase --continue
```
CI Enforcement (GitHub example)
```
name: ci
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # needed for full history
- run: npm ci
- run: npm run lint
- run: npm test
```