Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

A conflict low in a stack blocks merging PRs above it, even when they merge cleanly

未关闭
#449 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
github, go
领域
cli

调研方向

首先跟踪 gh-stack 如何确定堆叠的 pull request 是否可以合并,以及它如何处理用于 staging 部署的分支。定义位于存在冲突的 pull request 之上的无冲突 pull request 的预期行为,包括应如何表示其可合并状态和部署路径。完成的标准是,更高层的 pull request 可以独立推进,而不会错误地绕过其依赖项。

由索引模型根据 Issue 内容生成。

描述

The problem

Say main ← PR1 ← PR2. PR1 has merge conflicts against main and can't be merged. PR2 against PR1 is completely fine — no conflicts at all.

Merging is all-or-nothing for the whole chain up to main: if any PR in the stack can't be merged, none of them are. So even though PR2's changes are ready and conflict-free relative to PR1, there's no way to merge it — it's stuck behind PR1's unrelated conflict with main.

Impact

A single conflict low in a stack blocks everything built on top of it, even work that's fully ready and has nothing to do with that conflict. Teams end up stuck waiting on someone to resolve the bottom PR's conflict before any of the PRs above it can move forward, with no way to make progress on the parts that are actually ready.

This also blocks deploying feature branches to a staging environment for testing — a common practice at many companies. In this scenario, the feature branch is PR1's branch (the one with the conflict against main): deploying it to staging means merging it, and that merge is exactly what's blocked, so the branch can't be deployed until the unrelated conflict is resolved.

主要语言
Go
星标
1.5k
派生
73
平均合并
1 天 8 小时
30 天内合并 PR
7

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

github/gh-stack 的其他 Issue

查看 github/gh-stack 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。