GitHub project management used to mean a Kanban board bolted onto a repo that no one updated after the second sprint. That is not the tool anymore. GitHub Projects is now a flexible planning layer over your issues and pull requests, and after the April 2025 release of issue types, sub-issues, and advanced search, it covers most of what an engineering team needs to plan work without leaving the place the work happens.
This guide covers what GitHub project management actually does in 2026, what it costs, and the boundary that matters most: the point where the plan is fine but the person who reported the problem is nowhere in it.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Can You Use GitHub for Project Management?
For engineering work, yes. The distinction worth holding onto is between Issues and Projects, because people use the terms interchangeably and they are different things.
Issues are the work items. An issue lives in one repository and holds the description, the discussion, labels, assignees, and the links to the pull requests that close it. Projects is the planning layer above them. A project is its own object that collects issues, pull requests, and standalone draft notes, then wraps them in custom fields, saved views, and automation.
That separation is the point. A repository is a boundary for code, but a plan almost never respects it. One project can pull items from your frontend, backend, mobile, and infrastructure repositories into a single board, so the plan matches the team rather than the file layout.
The tracker is per repository. The plan usually is not. That gap is the reason Projects exists as a separate object rather than a tab inside a repo.
What GitHub Projects Gives You
The feature set is deliberately small and composable rather than broad and configurable. Most of it is fields and views.
Three layouts over the same items
Table is a high-density grid that behaves like a spreadsheet. Board is a Kanban layout grouped by any single-select field, usually status. Roadmap plots items on a timeline using date fields you define, which makes it a workable lightweight Gantt. You can save several views of one project, each with its own filters, grouping, and sort.
Up to 50 fields per project
Built-in and custom fields together, in text, number, date, single-select, and iteration types. Iteration is the one worth calling out: it defines repeating time boxes, which is how you get sprints without a separate sprint feature.
50,000 items per project
Raised from 1,200 in April 2025, counting both active views and the archive. The old ceiling was the single most common reason teams outgrew Projects, and it is no longer a practical constraint for most teams.
Insights charts
Configurable charts over the project data with filters, so you can build a burn-up or a count by status without exporting anything. Lighter than a dedicated reporting suite, but enough to answer the questions that come up in a standup.
Issue Types, Sub-Issues, and Advanced Search
This is the release that changed the answer to whether GitHub can replace Jira. All three entered public preview in January 2025 and became generally available in April 2025.
Sub-issues give issues a parent and child relationship, so a large piece of work breaks into tracked pieces that roll up rather than a checklist of plain text that nothing can report on.
Issue types are a shared classification defined at the organization level, so bug, task, and initiative mean the same thing in every repository. Before this, teams approximated it with labels, and labels drift between repos almost immediately.
Advanced search supports AND, OR, and parentheses for nested queries, from a repository or the global issues dashboard, and through both the REST and GraphQL APIs. It is what makes a 50,000 item project navigable.
Together these three closed most of the planning gap. What remains missing compared to Jira is not really planning, it is process enforcement: conditional workflow transitions, validators, and the granular permission schemes larger organizations run on.
Automating a GitHub Project
Automation comes in three layers, and most teams only need the first.
Built-in workflows
Prebuilt rules configured in the project settings with no code. Auto-add items matching a repository filter, set a field when an item is added or its state changes, and auto-archive items that meet criteria. This covers the routine bookkeeping: new issue lands in Todo, merged pull request moves to Done.
GitHub Actions
For anything conditional or cross-system. Since Actions already runs in the repository, project updates can ride along with the CI workflow you have rather than being a separate integration.
The GraphQL API
Projects is fully addressable through GraphQL, which is how external tools read and write items, fields, and views. Worth knowing before you build a custom sync, because it means the surface exists.
What GitHub Project Management Costs
Close to nothing, which is a real part of the appeal.
The GitHub Free plan includes unlimited public and private repositories with unlimited collaborators, and Projects comes with the account. A small team can run genuine project management on GitHub without paying for anything, which is not true of most tools in this category.
Paid tiers exist for other reasons. Team, around $4 per user per month, adds protected branches, code owners, and required reviewers. Enterprise, around $21 per user per month, adds SAML single sign-on, advanced auditing, and a much larger CI allowance. You upgrade for collaboration controls and security posture, not to get the board.
Where GitHub Project Management Stops
The tool is good. The boundary is about who it is for, and it is worth being direct about it.
GitHub is built around the repository and identifies people by GitHub account. That is correct for engineering and it is the source of every limitation below.
There is no customer behind an issue
An issue has a reporter, and that reporter is a GitHub account. A customer who hit the bug and wrote to support has no presence in the repository at all. The issue records what is broken but not who is waiting on it, which is the field that matters most for prioritization.
Access is shaped like a repository
Letting a support agent read or file work means granting repository access. Most companies decline, correctly, so the people closest to the customer end up outside the tool where the work is tracked.
No service level targets or customer communication
There is no concept of a response target, a breach, or a reply to the person who reported the problem. Those belong to a support tool and Projects does not pretend otherwise.
Reporting stays engineering-shaped
Insights answers questions about issues and throughput. It does not do resource management, time tracking, or portfolio rollups across many projects, so it will not serve a program manager the way a dedicated tool does.
None of this is a defect. It is what a tool built for code looks like. The failure only appears when a piece of work has to cross out of engineering and reach a person, and the most common example is a bug a customer reported.
A customer-reported bug gets into GitHub easily. Getting the answer back out to the customer is the part nobody builds, and it is the part the customer actually experiences.
GitHub Projects vs a Dedicated Project Management Tool
The question is not which tool is better. It is who has to use it.
Engineering-only planning, work that maps to repositories and pull requests, teams that value the plan sitting next to the code with no integration to maintain. Issue types, sub-issues, and iteration fields cover sprints and hierarchy, and the price is hard to argue with.
Jira, Linear with a support bridge, or an operational tool. Choose this when non-engineers file and track work directly, when you need conditional workflows and granular permission schemes, or when program-level reporting across many projects is a real requirement rather than a nice to have.
What GitHub Projects does well
- Lives next to the code with zero integration setup
- Free on every plan, including private repos
- One project spans many repositories
- Issue types and sub-issues give real hierarchy
- Fully addressable through the GraphQL API
What it does not do
- No customer or requester record behind an issue
- Access requires repository permissions
- No service level targets or customer replies
- Reporting stops at engineering throughput
- No conditional workflows or validators
If you are still weighing the tracker itself rather than the planning layer, the wider landscape is in the issue tracking software guide, and the equivalent boundary on the CRM side is covered in HubSpot project management.
Connecting GitHub to the Customer Who Reported the Issue
Here is the concrete case that breaks. A customer writes to support about a bug. Support confirms it, opens a GitHub issue, and pastes in a summary. Engineering fixes it, the pull request merges, the built-in workflow moves the item to Done, and the project board is completely accurate. Nobody tells the customer. The ticket sits open until someone remembers to check, or it gets closed without a reply.
The board was never wrong. The information just had no route back.
Fixing it by hand does not hold, because it depends on a person remembering to check a system they do not work in. The pattern that holds up is to keep the customer conversation where it belongs and sync the two systems, so the GitHub issue carries the ticket context in and the resolved status flows back out.
For teams running support in HubSpot Service Hub and engineering in GitHub, that is what IssueLinker does. From the HubSpot ticket, support creates or links a GitHub issue in one click with the ticket context attached, and status, comments, and notes sync both ways with loop prevention, so when the issue closes the ticket reflects it and support can reply to the customer. Engineering never leaves GitHub and support never needs a repository seat.
The four ways to wire these two systems together are compared in the GitHub HubSpot integration guide, and the mechanics of keeping two systems in agreement without echoing updates back and forth are in the bidirectional sync explainer. If the inbound half is what you are working on, bug triage covers deciding what deserves an issue in the first place.
Keep engineering in GitHub and still close the loop with the customer
IssueLinker turns a HubSpot ticket into a GitHub issue in one click and syncs status and comments both ways, so a customer-reported bug reaches your project board and the answer reaches the customer.
The Bottom Line
GitHub project management is a legitimate choice in 2026. Projects gives you table, board, and roadmap views, 50 fields, 50,000 items, iteration-based sprints, and real issue hierarchy, all next to the code and effectively free. For a team where everyone who touches the plan already works in GitHub, reaching for a separate tool is often just adding a sync to maintain.
The boundary is not capability, it is audience. GitHub is built around repositories and GitHub accounts, so the moment work has to involve someone who is not an engineer, the tool stops helping. That is fine for most work, and it fails on exactly one important case: the bug a customer reported. Keep the plan in GitHub, keep the customer in the support tool, and connect them, so the fix that shipped is something the customer actually hears about.
