How to Connect GitHub to Jira (Branches, Commits, and Pull Requests)
When GitHub and Jira are not connected, PMs ask engineers for status and engineers update tickets by hand after the fact. Both are slow and both drift. Connecting the two lets Jira show the branches, commits, pull requests, builds, and deployments tied to each issue, so status comes from the code rather than from memory.
Atlassian's GitHub for Jira app is the standard way to connect GitHub to Jira Cloud. This guide covers installing it, connecting your GitHub organization, getting engineers to reference issue keys, using smart commits, and adding automation so issues move when pull requests do.
Working in Jira? Turn your spec into dependency-ordered tickets.
Paste the feature or spec. Vantage pulls out the requirements and breaks them into tickets, ordered by what blocks what, ready to groom with your team.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD and dependency-ordered tickets from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Install the GitHub for Jira app
A Jira admin installs the GitHub for Jira app from the Atlassian Marketplace. Once installed, the app's configuration page in Jira walks you through connecting a GitHub organization. You need admin rights in both Jira and the GitHub organization to complete the connection.
- In Jira, open apps and search the Marketplace for GitHub for Jira
- Install the app
- Open the app's configuration page
- Confirm you have admin access to the GitHub organization
Connect your GitHub organization
From the configuration page, connect your GitHub organization and install the corresponding GitHub app. Choose whether to grant access to all repositories or only selected ones. Start with the repositories your product teams actively work in. The app can backfill historical data so existing branches and pull requests appear on issues.
Reference issue keys in branches, commits, and PRs
Linking works through Jira issue keys. Include the key, such as SHOP-142, in the branch name, commit message, or pull request title, and the development activity appears on that issue. The simplest convention is putting the key at the start of the branch name. Jira can also create branches from an issue with the key already included.
- Agree on a branch naming convention such as SHOP-142-short-description
- Include the issue key in pull request titles
- Include the key in commit messages for traceability
- Use 'Create branch' from the Jira issue where available
Check the development panel
Open a linked issue and find the development panel. It shows branches, commits, pull requests, and, if configured, builds and deployments. PMs can see at a glance whether work has started, whether a pull request is open or merged, and whether it has been deployed. This reduces 'is it done yet' messages significantly.
Use smart commits for quick updates
Smart commits let engineers act on Jira issues from commit messages, for example adding a comment or logging time. Smart commit commands follow the issue key, such as SHOP-142 #comment Fixed edge case in retry logic. Smart commits must be enabled for your Jira site and work when the committer's email matches a Jira user, so check both before rolling them out.
- Confirm smart commits are enabled for your Jira site
- Ensure engineers' commit emails match their Jira accounts
- Share examples such as #comment and #time in your engineering handbook
Automate transitions with Jira automation
Jira automation can trigger on development events. Common rules: when a pull request is created, transition the issue to In Review; when a pull request is merged, transition it to Done or Ready for QA. Set these rules at the project level, test them on a sandbox issue, and keep them simple enough that engineers understand why an issue moved.
- Create a rule triggered when a pull request is created
- Add an action to transition linked issues to In Review
- Create a second rule on pull request merged
- Test both rules before enabling them for the whole project
Add builds and deployments
If you use GitHub Actions for CI and deployments, the integration can surface build and deployment information on issues. Configure environments in your workflows so Jira can show where a change has been deployed. For PMs, 'deployed to production' is the status that matters most.
Common mistakes
Inconsistent issue key usage
If half the team forgets the issue key, half the work is invisible in Jira. Make the convention part of the PR template and code review checklist.
Granting access to every repository by default
Connecting every repository, including archived and experimental ones, adds noise. Start with active product repositories and add more as needed.
Automation that fights the workflow
Rules that move issues to statuses that do not exist in a project's workflow will fail or confuse people. Align automation with each project's workflow.
Tips
Add a pull request template line reminding authors to include the Jira key in the title.
Use the development panel in sprint reviews to show what actually merged.
Filter for issues with an open pull request older than three days to find stalled reviews.
Keep automation rules documented in the project's wiki so changes are traceable.
How Vantage helps
Connecting GitHub and Jira shows what the code is doing. Vantage adds the step before it: PMs can query their codebase through the GitHub integration while writing the PRD, so requirements reflect how the system actually works before tickets are generated and pushed to the tracker.