Effective Git

Smart Git workflow assistant that helps you commit, push, and manage code changes following best practices.

Getting Help

Quick help: When user asks "gq help", "gq:h", or "git help", run scripts/show_help.sh to display usage guide

Detailed help: When user asks about specific topics:

• - "show me git best practices" → Read INLINECODE1
• "how to resolve conflicts" → Read INLINECODE2
• "quick commands list" → Read INLINECODE3

Usage examples:

• - Use gq <command> for quick operations (status, branch switching, etc.)
• Use natural language for commits, pushes, merges (full workflow with analysis and safety checks)
• Examples:

- "gq b:l" → Quick branch list
- "help me commit code" → Full commit workflow with analysis
- "gq:s" → Quick status
- "resolve conflicts" → Full conflict resolution with guidance

Core Workflow

When helping with git operations, follow this sequence:

Quick Operations Mode

For simple, read-only operations or quick checks, use scripts/git_quick.sh:

When user asks for:

• - "list branches" → INLINECODE6
• "switch to xxx" → INLINECODE7
• "create branch xxx" → INLINECODE8
• "check status" → INLINECODE9
• "recent commits" → INLINECODE10
• "show changes" → INLINECODE11

- If GIT_QUICK_DIFF_TERMINAL is set, opens in new terminal window
- Otherwise uses $PAGER (default: less)
- Staged changes: INLINECODE14

See references/quick-commands.md for full command list.

Full Workflow Mode

For commits, pushes, merges, and conflict resolution, follow the detailed workflow below:

1. Analyze Recent Changes

Run scripts/analyze_changes.sh to understand:

• - Current branch
• Uncommitted changes
• Recent commit history
• Last commit details

2. Determine Commit Strategy

Check if changes should amend the last commit or create a new one:

Use git commit --amend when:

• - Fixing typos or small issues in the last commit
• Adding forgotten files to the last commit
• Last commit hasn't been pushed yet
• Changes are logically part of the last commit

Use git commit -m "message" when:

• - Changes represent a new logical unit of work
• Last commit has been pushed
• Changes are unrelated to the last commit

3. Check Project Conventions

Before writing commit message:

1. 1. Review recent commit messages: INLINECODE19
2. Look for patterns:

- Prefixes (feat:, fix:, chore:, etc.)
- Ticket references (#123, JIRA-456)
- Emoji usage (✨, 🐛, 📝)
- Capitalization style

1. 3. If unclear, ask user about project conventions

4. Write Commit Message

Follow conventions from references/best-practices.md:

• - Use imperative mood ("Add feature" not "Added feature")
• Keep subject line under 50 chars
• Be specific and descriptive
• Match project conventions discovered above

5. Safe Push Operations

Critical constraint: Only push to current branch.

Before pushing:

1. 1. Confirm current branch: INLINECODE20
2. Show what will be pushed: INLINECODE21
3. Ask user to confirm
4. Push: INLINECODE22

Never use git push --force without explicit user confirmation.

Dangerous Operations

These require user confirmation before execution:

• - git push --force or INLINECODE25
• INLINECODE26
• INLINECODE27
• INLINECODE28 on shared/public branches
• INLINECODE29 (force delete)
• Any history rewriting on pushed commits

Always explain the risk before asking for confirmation.

Conflict Resolution

Critical Principle: When resolving conflicts, the absolute priority is preserving all code. If unable to confidently resolve, you must summarize the issue and feedback to the user. DO NOT perform automatic merges.

Conflict Handling Workflow:

1. 1. Pre-merge/Rebase Snapshot: Before attempting a merge or rebase, save a snapshot of the current state for documentation and safety.

    scripts/save_diff.sh
    # Also create backup branch
    git branch <current-branch>-backup
    

This creates a git diff document before the merge.

1. 2. Detect and Analyze Conflicts: If conflicts arise during a merge or rebase:

    scripts/analyze_conflicts.sh
    

This provides detailed three-way diff analysis for each conflicted file.

1. 3. Deep Conflict Analysis: For complex conflicts where both sides modified the same code:

Analyze the intent:
- What problem does each version solve?
- What functionality does each add/remove/modify?
- Is it a bug fix, feature, refactor, or optimization?

Compare approaches:
- Do they implement different algorithms?
- Do they change APIs or interfaces differently?
- What are the trade-offs (performance vs readability, simplicity vs robustness)?

Determine resolution strategy:
- Keep Both (Merge): Both changes are valuable and can be combined
- Keep Ours: Our change is more complete/correct
- Keep Theirs: Their change is more complete/correct
- Rewrite: Neither is ideal, create better solution combining insights
- Ask User: Cannot decide confidently, need user guidance

1. 4. Present Analysis to User: When conflicts cannot be resolved automatically, create a structured summary:

- Show both versions of conflicting code - Explain the intent and trade-offs of each - Provide your recommendation with reasoning - Ask for user's decision - See references/conflict-resolution.md for detailed template

1. 5. Post-Resolution Documentation: After conflicts are resolved:

CODEBLOCK2

1. 6. Verify No Code Loss: After completing merge/rebase:

CODEBLOCK3

Special attention for edge cases:

• - Detached HEAD: Scripts will detect and warn; recommend creating a branch before operations
• Submodules: Detected and flagged; require special handling (see references/conflict-resolution.md)
• Large files: Output automatically limited to prevent overwhelming context
• Rebase to less code: Default to preserving current branch's work (see references/conflict-resolution.md)

Rebase & Merge

Interactive Rebase

CODEBLOCK4

Merge Strategies

CODEBLOCK5

Common Tasks

Stash Changes

CODEBLOCK6

Cherry-pick

CODEBLOCK7

Undo Changes

CODEBLOCK8

Resources

• - Help script: scripts/showhelp.sh (usage guide and examples)
• Best practices reference: references/best-practices.md
• Conflict resolution guide: references/conflict-resolution.md (includes detailed analysis framework and templates)
• Quick commands reference: references/quick-commands.md (shorthand for common operations)
• Change analysis script: scripts/analyzechanges.sh
• Conflict analysis script: scripts/analyzeconflicts.sh (deep three-way diff analysis)
• Save diff script: scripts/savediff.sh
• Visualize conflicts script: scripts/visualizeconflicts.sh
• Quick operations script: scripts/gitquick.sh (fast branch switching, status checks, etc.)

Quick Commands

For rapid git operations, use scripts/git_quick.sh with the gq prefix pattern:

Trigger pattern: When user message starts with gq: or uses git quick command syntax

Common commands:

• - gq b:l or gq:b:l - List branches
• INLINECODE39 - Switch to branch
• INLINECODE40 - Create new branch from current
• INLINECODE41 - Quick status
• INLINECODE42 - Recent commits
• INLINECODE43 - Show diff

Usage in conversation:

• - User: "gq b:l" → Run INLINECODE44
• User: "gq b-> feature" → Run INLINECODE45
• User: "gq:s" → Run INLINECODE46

⚠️ Shell quoting rule: Always quote the command argument when calling git_quick.sh to prevent shell misinterpreting special characters. Use git_quick.sh "b->" <branch>, never git_quick.sh b-> <branch> (shell will treat > as redirection).

See references/quick-commands.md for full command list and usage patterns.

Important: Only trigger quick commands when user explicitly uses gq prefix or quick command syntax. Do not auto-trigger for general git questions.