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