git-workflow_skill

Overview

This skill documents the IdeaVim git workflow conventions for commits, branches, pull requests, and CI. It codifies branch naming, commit message formats, rebase policy, and expectations for tests and PRs. Use it as a practical guide when working on IdeaVim code changes to keep history linear and master release-ready.

How this skill works

The workflow enforces a trunk-based master that must always be releasable. Development happens on feature branches named with the YouTrack ticket ID (VIM-XXXX/short-description) and is regularly rebased onto master to avoid large conflicts. Commits follow strict formats so ticket links and automated ticket transitions work, and CI runs the standard Gradle test suite for every PR targeting master.

When to use it

• Creating a new feature or bugfix for IdeaVim
• Opening a pull request or preparing a branch for review
• Committing changes that relate to a YouTrack ticket
• Rebasing or integrating work onto master to keep history linear
• Running or validating CI test expectations before merging

Best practices

• Keep master always in a ready-to-release state; only small, safe fixes may land directly
• Create focused commits: one logical change per commit with tests for behavioral edits
• Name branches with the YouTrack ticket ID: VIM-XXXX/short-description
• Rebase frequently onto master; avoid merge commits to maintain a linear history
• Use the auto-closing commit format (fix(VIM-XXXX): ...) to move tickets to Ready To Release

Example use cases

• Start a VIM-3948/feature branch when implementing a new editor traversal behavior
• Make a single-issue commit with message "VIM-3948 Traverse vertical panes in ConfigurableEditor" and include tests
• Rebase your feature branch onto master to resolve conflicts before opening a PR
• Open a PR targeting master; CI will run the standard Gradle tests automatically
• Apply a small formatting or typo fix directly to master if it doesn’t alter functionality