Design: separate a stacked PR's merge target from its base
- Ngôn ngữ chính
- Go
- Star
- 1.5k
- Fork
- 70
- Merge trung bình
- 1 ngày 8 giờ
- Pull request đã merge (30 ngày)
- 7
Mô tả
From [Overview / What Is a Stack?](https://github.github.com/gh-stack/introduction/overview/#what-is-a-stack):
> A pull request stack consists of two or more pull requests in the same repository where:
>
> - The first (bottom) pull request targets the main branch (e.g., main).
> - Each subsequent pull request targets the branch of the PR below it.
```
┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top
┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
┌── feat/auth-layer → PR #1 (base: main) ← bottom
main (trunk)
```
[endquote]
_Merging to the base branch is fundamentally wrong for this._ In your example here, `api-endpoints` is not logically *part of* `auth-layer`, so should not merge to it. You should separate "base" and "target" (e.g. `main`, `super-feature`, etc). Normally all branches in a stack will merge to the same target.
You already track "target" as distinct from base - your own [Overview](https://github.github.com/gh-stack/introduction/overview/#what-is-a-stack) states each PR is evaluated for rules and protections using "its final target branch (e.g., `main`), not the branch it directly targets." So the concept exists; it's just confined to rule evaluation and discarded everywhere else. Promote it to a first-class merge destination.
Result should be something like:
```
$ git log --all --graph --decorate --pretty=oneline --abbrev-commit
* 043bf03 (HEAD -> main) Merge pull request #2 from username/feat/2
|\
| * 88624f8 (feat/2) Feature 2
* | 39f3460 Merge pull request #1 from username/feat/1
|\|
| * 0f1e961 (feat/1) Feature 1
|/
* 04a9dac Initial commit
```
Related, I made the [same point to Git Butler](https://github.com/gitbutlerapp/gitbutler/issues/10936), but they're constrained by the existing GitHub implementation. But you are GitHub, now deciding the next implementation - not constrained.
Along with this, the implementation should display and enforce "below" branches in the stack as prerequisites. `feat/2` should be blocked from merging until `feat/1` has merged. You'll have to make this explicit, instead of just a side effect of merging to the base branches.
Hướng dẫn đóng góp
Hướng nghiên cứu
Bắt đầu với phần mô tả Overview / What Is a Stack? được liên kết và truy vết cách gh-stack hiện biểu diễn các đích cuối cùng, các branch cơ sở và hành vi merge. Xác định đích merge riêng biệt và hành vi điều kiện tiên quyết rõ ràng cho các branch xếp chồng, sau đó xác minh rằng lịch sử kết quả khớp với ví dụ và rằng các branch phía trên không thể merge trước các branch phía dưới.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- github, go
- Lĩnh vực
- cli
- Loại issue
- Tính năng
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức độ hoạt động
- Ít trao đổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 35/100