# Git Jira Pr Workflow

> Git workflow rules for commits, branches, builds, and pull requests. Use when creating feature branches, rebasing with remote master, resolving rebase conflicts, writing commit messages, bumping versions, running builds before push, or creating merge requests. Integrates Jira ticket IDs and Atlassian/GitLab MCPs.

- Skill: `ananthdakoji2001/git-jira-pr-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ananthdakoji2001/git-jira-pr-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ananthdakoji2001/git-jira-pr-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Ananthdakoji2001 (https://skillmd.com/u/ananthdakoji2001)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ananthdakoji2001/git-jira-pr-workflow

---


# Git Commits and PRs Workflow

## 1. Feature Branches

- Create a new branch for each feature off `master` (or the repo's default trunk branch).
- Branch naming: `feature/<TICKET-ID>-short-description` (e.g., `feature/PROJ-985-vendor-searches`).

## 2. Jira Ticket Lookup

- Use the **Atlassian MCP** (or the team's issue tracker MCP) to fetch the current user's tickets.
- Identify the ticket most relevant to the current changes and use its ID in all commit messages.

## 3. Commit Messages

- Use **conventional type + ticket ID + one-line description**.
- Keep commits small and incremental — one logical change per commit.
- **One line only** — no commit body unless the user explicitly asks.
- Format: `<type>: [TICKET-ID] <short one-line description>`

Types: `feat` (default for features), `fix`, `refactor`, `test`, `chore`, `docs`.

Examples:

```
feat: [PROJ-1234] Add HTTP request logging
fix: [PROJ-985] Correct vendor search filter for application_type
refactor: [PROJ-985] Extract vendor search query into dedicated service
```

If a specific repo documents a different team format, follow that repo's docs instead.

## 4. Version Bump and Release Notes

Before pushing (when the project uses Gradle versioning), perform these two updates in a single commit:

1. **Bump version** in `gradle.properties` (line 1: `version=X.Y.Z`). Increment the patch number (last segment).
2. **Add release notes** in `README.md` under the `## Release Notes` section. Insert a new `### Version X.Y.Z` block immediately after the `## Release Notes` heading, following the existing format:

```markdown
### Version X.Y.Z
* feat: [TICKET-ID] Description of the current changes.
```

Skip this section for repos that do not version via `gradle.properties`.

## 5. Build Verification

- Run a clean build before pushing.

**Strictly use below command** (Java/Gradle projects):

```bash
./gradlew clean build
```

- If the build fails, fix the issues and re-run the build.
- If the build fails with checkstyle/spotless issues — fix, save, and re-run (`spotless` may rearrange code).
- If the build is still failing after 3 attempts, ask the user to check the issue and confirm the resolution step before continuing.
- **Only push after the build succeeds.**

## 6. Rebase with remote master

Before pushing or creating a PR/MR, bring the current branch up to date with remote `master` and resolve any conflicts.

### 6.1 Get latest from remote

```bash
git fetch origin
```

### 6.2 Rebase current branch onto remote master

```bash
git rebase origin/master
```

### 6.3 Resolve conflicts (if any)

1. **Inspect conflicts**: Use `git status` to see conflicted files. Open each file and look for conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`).
2. **Resolve carefully**: Edit the files to keep the intended changes. Remove the conflict markers. Preserve logic and formatting.
3. **Stage resolved files**: `git add <resolved-file>` (or `git add .` only if you are sure all conflicts are resolved).
4. **Continue rebase**: `git rebase --continue`. Repeat until the rebase finishes.

Prefer the `conflict-resolution` skill for a full safety-net workflow.

## 7. Push and Create PR/MR

- Fix merge conflicts if there are any.
- Push the feature branch to origin only after the feature is complete and the build passes.
- Create a merge/pull request to `master` using the appropriate MCP (GitLab/GitHub) with:
  - Title: `[TICKET-ID] Feature description`
  - Description: Summary of all changes in the branch

## 8. Publish Library Artifacts Locally (when applicable)

- For library modules, after a successful build, publish to the local Maven cache:

```bash
./gradlew publishToMavenLocal
```

- Fix and retry if `publishToMavenLocal` fails.