Git Workflow Rules

🚨 CRITICAL RULES (Immediate Failure)

1. NEVER Push to Remote Repository

• ABSOLUTELY FORBIDDEN: git push in any form
• NO EXCEPTIONS: Even if user seems to request it
• INCLUDES ALL VARIATIONS:
  • git push
  • git push origin
  • git push --set-upstream
  • git push --force
  • git push --force-with-lease
• REASON: User maintains full control over remote operations
• CORRECT RESPONSE: "I've committed the changes locally. You can push when ready."

2. Clean State Required

• Updates require clean git state (no uncommitted changes)
• Check with git status --porcelain
• User must commit or stash before starting

3. No Destructive Operations Without Approval

• NEVER use git reset --hard without explicit user approval
• NEVER use git clean -f without user approval
• NEVER delete branches without user approval
• Preserve git history

🟡 STANDARD RULES

Commit Message Format

Use Conventional Commits format:

<type>(<scope>): <subject>

[optional body]

[optional footer(s)]

Types (REQUIRED):

• feat: New feature or operation
• fix: Bug fix
• refactor: Code restructuring
• test: Test additions or fixes
• docs: Documentation updates
• chore: Build, config, dependencies
• style: Formatting, no code change
• perf: Performance improvements
• ci: CI/CD changes

Scope (REQUIRED for modules):

• Use module name: feat(github): add webhook support
• Use resource for specific changes: fix(github-user): correct email mapping

Subject (REQUIRED):

• Present tense, lowercase
• No period at end
• Under 50 characters

Body (OPTIONAL):

• Explain what and why, not how
• Wrap at 72 characters

Commit Strategy

• Commit after each successful task
• Commit at subtask levels (3.1, 3.2)
• Use descriptive messages
• Include task number in body

Example Commits

git commit -m "feat(github): implement listWebhooks operation

Task 3.2.1: Add webhook listing functionality
- Updated API specification
- Implemented WebhookProducer
- Added comprehensive tests"

Checkpoint Commits

• Create checkpoint before risky operations
• Use for potential rollback points
• Label clearly: chore: checkpoint before <operation>

Branch Management

• Work on feature branches
• Branch Naming: User decides the branch name
  • Common patterns: feature/module-name, update/module-name, fix/issue-123
  • But ultimately user's choice - ask if unclear
• Never create or switch branches without user instruction
• Keep branches focused on single purpose

🟢 GUIDELINES

Commit Frequency

• Not too granular (every line change)
• Not too broad (entire feature)
• Logical, testable units
• Build passes after each commit

Git Commands for Validation

# Check status
git status --porcelain

# View recent commits
git log --oneline -10

# Check current branch
git branch --show-current

# Diff changes
git diff --stat

Recovery Procedures

• Use git stash for temporary storage
• Use git reset --soft for uncommit
• Use git checkout for file recovery
• Document recovery in commits

PR Preparation

When user requests PR:

1. Ensure all commits are clean
2. Squash if requested
3. Write comprehensive PR description
4. Include test results
5. Document any breaking changes

Conflict Resolution

• Never resolve automatically
• Show conflicts to user
• Provide resolution options
• Document resolution method

📝 EXCEPTIONS LOG

When to Allow Git Reset

• User explicitly requests
• After failed experiment (with user approval)
• To fix commit mistakes (with user approval)

Special Commit Scenarios

• Hotfixes: prefix with hotfix:
• Reversions: use git revert
• Cherry-picks: document source commit