Support Many-to-Many Relationships for Sub-issues (Allow an issue to have multiple parent issues)

[fromeroc9]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Issues

Body

Hello GitHub Team,

With the recent introduction of the Sub-issues feature, organizing work has become much easier. However, we have encountered a strict limitation: an issue can currently only belong to a single parent issue. If we try to add an existing sub-issue to a second parent, it is either rejected or moved, breaking the 1-to-N relationship constraint.

Our Use Case (Cross-functional workflows): In real-world scenarios, a Many-to-Many relationship is essential. A single issue often represents a piece of work that impacts or blocks multiple different initiatives simultaneously.

For example:

A single infrastructure task (e.g., "Migrate Database to v2") needs to be tracked under the "DevOps Q1 Initiatives" epic, but it is also a blocker that needs to be tracked under the "New User Authentication" product epic.
A core API change needs to belong to both the "Backend Refactor" epic and the "Mobile App v3.0 Release" tracking issue.
Currently, because an issue can only have one parent, we cannot natively link the same task to multiple parent tracking issues. We are forced to bypass the sub-issues feature entirely and use manual Markdown checklists inside the parent issue's body, which completely defeats the purpose of having native sub-issues for tracking progress and completion rates.

Feature Request: Please allow a single issue to be added as a sub-issue to multiple parent issues simultaneously.

Having the ability to build Many-to-Many hierarchies would accurately reflect how cross-functional teams operate and would prevent us from having to duplicate issues or rely on manual checklists just to track shared dependencies.

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[P-r-e-m-i-u-m]

This matches how the feature is currently modeled: sub-issues are a hierarchy, not a many-to-many graph.

The current docs talk about a sub-issue's parent issue in the singular, and the REST API has a Get parent issue endpoint for a sub-issue. That strongly suggests the platform currently treats each sub-issue as having one parent at a time.

Docs:

• Adding sub-issues: https://docs.github.com/issues/managing-your-tasks-with-tasklists/creating-a-tasklist
• Browsing sub-issues / finding a sub-issue's parent: https://docs.github.com/issues/tracking-your-work-with-issues/using-issues/browsing-sub-issues
• REST API for sub-issues, including Get parent issue: https://docs.github.com/rest/issues/sub-issues

For your use case, I would probably avoid duplicating issues and use one of these patterns:

1. Pick one true parent issue for hierarchy/progress tracking, then link the issue from other epics using normal issue links or tracked-by comments.
2. Use GitHub Projects fields for cross-cutting grouping, such as Initiative, Release, Component, or Dependency group.
3. Use labels for shared dependencies, for example blocks-auth, blocks-mobile-v3, infra-migration.
4. If you need many-to-many reporting, build it in Projects views rather than the sub-issue tree.

I agree with the feature request though. Many-to-many parentage would be useful for cross-functional work, but it would also make progress calculations and hierarchy browsing more complex. Until GitHub supports that model directly, Projects fields are probably the cleanest workaround.

[ankit227060]

A many-to-many sub-issue model would definitely help for cross-functional planning, especially for shared infrastructure or platform work.

One challenge GitHub would need to solve though is progress calculation. If one sub-issue belongs to multiple parent epics, completion percentages and dependency graphs could become ambiguous very quickly.

A possible middle-ground could be:

• keep one “primary parent” for hierarchy/progress tracking
• allow additional “linked parent” relationships for visibility across initiatives

That would preserve clean progress tracking while still supporting real-world workflows where a task impacts multiple teams/projects.