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:

### 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):

./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

git fetch origin

6.2 Rebase current branch onto remote master

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:

./gradlew publishToMavenLocal

• Fix and retry if publishToMavenLocal fails.