Allow configuring default PR base branch (fixes #36412) by tototomate123 · Pull Request #36425 · go-gitea/gitea

tototomate123 · 2026-01-21T16:17:37Z

Summary

This adds a per-repository default PR base branch and wires it through PR entry points. It updates compare links and recently pushed branch prompts to respect the configured base branch, and prevents auto-merge cleanup from deleting the configured base branch on same-repo PRs.

Behavior changes

New PR compare links on repo home/issue list and branch list honor the configured default PR base branch.
The "recently pushed new branches" prompt now compares against the configured base branch.
Auto-merge branch cleanup skips deleting the configured base branch (same-repo PRs only).

Testing

Not run (local UI verification only).

Reviewer question: I added a guard in services/repository/branch.go (DeleteBranchAfterMerge flow) to avoid auto-deleting the configured default PR base branch for same-repo PRs. Is that desired, or is branch protection expected to cover this?

wxiaoguang · 2026-01-21T16:24:24Z

Is there a reason why "default" branch can't be used as PR base branch?

TheFox0x7 · 2026-01-21T16:32:20Z

The linked issue explains it a bit - the idea is to support a setup where you have main branch, staging branch and the dev ones and while the repository main is the first one from the list, the staging is the base one for PRs.
You could set the default to staging branch as a workaround but it's not really the main one for the workflow.

tototomate123 · 2026-01-21T16:46:38Z

Is there a reason why "default" branch can't be used as PR base branch?

Yeah, changing the default branch changes more than just PR targets. Plus, when the PR UI tries to load the diff between the "default" branch and the staging branch (which your team normally PRs to), it tends to get really laggy (making the workflow of PRing the staging branch rather tedious).

wxiaoguang · 2026-01-21T16:51:35Z

The linked issue explains it a bit

Sorry but I didn't find the linked issue ... Did I miss something? What I saw on my side:

Details

TheFox0x7 · 2026-01-21T16:52:18Z

it's in the title - #36412

wxiaoguang · 2026-01-21T16:58:27Z

it's in the title - #36412

Hmm, totally missed that.

But still don't understand the details ... in that case, why not set dev to be the default branch, and only keep main for release purpose?

changing the default branch changes more than just PR targets.

What else would it affect?

when the PR UI tries to load the diff between the "default" branch and the staging branch (which your team normally PRs to), it tends to get really laggy

If the default branch is dev, then it isn't a problem anymore?

tototomate123 · 2026-01-21T17:19:19Z

But still don't understand the details ... in that case, why not set dev to be the default branch, and only keep main for release purpose?

Because the default branch is the repo's canonical ref, not just "the default PR target". It affects what git clone checks out, what the web UI shows by default (file tree/README), and what various tools/integrations assume when they operate on "the repo" without an explicit ref.

changing the default branch changes more than just PR targets.

What else would it affect?

Clone defaults, the repository home view/default ref in the UI, and integrations/automation that implicitly use the default branch (for example links that omit a ref, docs references, or CI setups that follow the default branch unless configured otherwise). Many repos also want the default branch to represent the stable/releasable line for external consumers and casual viewers.

If the default branch is dev, then it isn't a problem anymore?

It avoids the PR-base mismatch, but at the cost of making an integration branch the repo's canonical branch. A common workflow keeps main stable for releases while PRs land in dev/staging. Flipping the default branch to dev has broader side effects than desired and changes what the repo "looks like" to everyone by default.

A configurable default PR base branch solves the actual pain point: it reduces mistakes (accidentally opening PRs against main), fixes compare links/prompts, and supports multi-branch workflows without redefining the repo's canonical branch.

wxiaoguang · 2026-01-21T17:30:51Z

Thank you for the clarification, it makes sense.

tototomate123 · 2026-01-21T19:12:28Z

Thank you for the clarification, it makes sense.

Thanks for taking a look, glad the motivation makes sense.

Just to confirm: this is fully opt-in (per-repo default PR base branch), so there’s no behavior change unless the setting is configured. The changes mostly wire that base through the existing PR entry points (compare links / recently pushed prompt), and add a small safety guard to avoid auto-deleting the configured base branch in same-repo PR cleanup.

Do you have any concerns with the current approach, or would you like any adjustments (naming/UI wording, docs, tests, or the branch-cleanup guard behavior)?

lunny · 2026-01-21T20:10:17Z

If we want to add an option for pull request ,it should be in the repo_unit table and the migration is unnecessary.

Signed-off-by: Louis <116039387+tototomate123@users.noreply.github.com>

modules/git/gitcmd/command.go

modules/git/gitcmd/command_test.go

tototomate123 · 2026-01-22T18:57:38Z

If we want to add an option for pull request ,it should be in the repo_unit table and the migration is unnecessary.

Done - moved the setting into the PR repo_unit config and removed the migration.

wxiaoguang · 2026-02-01T06:33:54Z

diff --git a/models/git/branch.go b/models/git/branch.go

Feel free to help to edit this PR and add necessary tests.

wxiaoguang · 2026-02-03T15:45:01Z

diff --git a/models/git/branch.go b/models/git/branch.go

Feel free to help to edit this PR and add necessary tests.

@lunny if you don't have plan to make more changes to this PR, it can be merged as-is. I don't really see anything seriously wrong would happen (at the worst, a 404 page indicates the repo admin to update the PR target branch). You can also make improvements in following up PRs.

By the way, your suggestion is still not complete, it fails a repo with no PR unit. So if you'd like to make more changes, it also needs tests with good coverage.

silverwind · 2026-02-03T15:57:03Z

How does the UI look for the new field? Is it acceptable looking on the repo settings page?

wxiaoguang · 2026-02-03T16:07:18Z

How does the UI look for the new field? Is it acceptable looking on the repo settings page?

I have done enough and it is acceptable to me. If you don't like it, you can do more.

silverwind · 2026-02-03T16:10:59Z

How does the UI look for the new field? Is it acceptable looking on the repo settings page?

I have done enough and it is acceptable to me. If you don't like it, you can do more.

I'm just asking for a screenshot.

silverwind · 2026-02-03T16:15:23Z

@tototomate123 never raise pull request from a the default branch, these are hard to collaborate on.

silverwind · 2026-02-03T16:16:46Z

I guess it looks ok but there is a inconsistency in the capitalization with the label above:

silverwind · 2026-02-03T16:21:37Z

There is one UI issue: The dropdown cannot be cleared so the default value can not be restored once changed.

silverwind · 2026-02-03T16:27:48Z

It appears fomantic should support a ui dropdown selection clearable to make a x icon show as seen in https://fomantic-ui.com/modules/dropdown.html#clearable-selection, but I can not get this to work for some reason, maybe it only works for multiple.

silverwind · 2026-02-03T21:13:48Z

Maybe we should just have a "Default Branch" instead of empty option. Then there is no strange UX with clearable dropdown.

wxiaoguang · 2026-02-04T13:58:46Z

There is one UI issue: The dropdown cannot be cleared so the default value can not be restored once changed.

Do you have plan to make more changes? I see most "dropdown (select)" elements don't have the ability to "restore" after their values are changed, not only in Gitea, but in all desktop/web apps.

tototomate123 · 2026-02-04T17:36:43Z

Thanks for the feedback. Sorry for opening PRs from the default branch, won't happen again in the future.

Is there anything else left before merge? I saw the default branch selection UI change landed in wxiaoguang's commits, so I don't think more is needed on my side?

wxiaoguang · 2026-02-06T05:44:20Z

@lunny @silverwind anything else to change?

lunny · 2026-02-06T08:01:16Z

It would be better to display a dedicated lock icon or hide the delete button in the branch list to indicate the default target branch for pull requests, and to improve the error message. The current message states that I am deleting the default branch, but I am actually deleting v2, which is not the default branch or pull request branch according to this UI.

wxiaoguang · 2026-02-06T08:05:40Z

It would be better to display a dedicated lock icon or hide the delete button in the branch list to indicate the default target branch for pull requests, and to improve the error message. The current message states that I am deleting the default branch, but I am actually deleting v2, which is not the default branch or pull request branch according to this UI.

The error message is clear enough. You can check your repo's pull requests settings.

If any one still have plans to improve, just edit directly or make changes in following up PRs.

To me, these "problems" are quite trivial and I don't need such feature, so I won't spend more time on it.

silverwind · 2026-02-06T08:54:57Z

I will test this one more time soon, hold on a bit with the merge.

silverwind

UI looks ok to me now. Maybe still wait on @lunny's approval before merge.

* giteaofficial/main: Refactor merge conan and container auth preserve actions taskID (go-gitea#36560) Fix assignee sidebar links and empty placeholder after go-gitea#32465 refactor (go-gitea#36559) Fix various version parsing problems (go-gitea#36553) Fix highlight diff result (go-gitea#36539) Refactor Nuget Auth to reuse Basic Auth Token Validation (go-gitea#36558) Update go dependencies (go-gitea#36548) Prevent navigation keys from triggering actions during IME composition (go-gitea#36540) Fix various mermaid bugs (go-gitea#36547) Add `elk` layout support to mermaid (go-gitea#36486) Allow configuring default PR base branch (fixes go-gitea#36412) (go-gitea#36425) [skip ci] Updated translations via Crowdin Color command/error logs in Actions log (go-gitea#36538) Add paging headers (go-gitea#36521) Fix issues filter dropdown showing empty label scope section (go-gitea#36535) [SECURITY] fix: Adjust the toolchain version (go-gitea#36537) Hide `add-matcher` and `remove-matcher` from actions job logs (go-gitea#36520) Improve timeline entries for WIP prefix changes in pull requests (go-gitea#36518)

…itea#36425) This adds a per-repository default PR base branch and wires it through PR entry points. It updates compare links and recently pushed branch prompts to respect the configured base branch, and prevents auto-merge cleanup from deleting the configured base branch on same-repo PRs. ## Behavior changes - New PR compare links on repo home/issue list and branch list honor the configured default PR base branch. - The "recently pushed new branches" prompt now compares against the configured base branch. - Auto-merge branch cleanup skips deleting the configured base branch (same-repo PRs only). --------- Signed-off-by: Louis <116039387+tototomate123@users.noreply.github.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: silverwind <me@silverwind.io>

tototomate123 added 2 commits January 21, 2026 16:55

Add default PR base branch support to repositories

10047b6

fmt: update repo struct

e52f187

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Jan 21, 2026

github-actions bot added modifies/go Pull requests that update Go code modifies/templates This PR modifies the template files modifies/migrations labels Jan 21, 2026

tototomate123 mentioned this pull request Jan 21, 2026

Allow configuring default Pull Request base branch (repo-level or user-level) #36412

Closed

tototomate123 added 2 commits January 21, 2026 18:58

swagger: regenerate spec

9d5b6b4

gitcmd: enforce timeout cancellation

668575e

github-actions bot added the modifies/api This PR adds API routes or modifies them label Jan 21, 2026

tototomate123 marked this pull request as ready for review January 21, 2026 19:08

move default PR base branch setting into repo_unit config

c026345

github-actions bot removed the modifies/migrations label Jan 22, 2026

tototomate123 and others added 2 commits January 22, 2026 17:33

Merge branch 'main' into main

8b7728b

Signed-off-by: Louis <116039387+tototomate123@users.noreply.github.com>

gitcmt: fix timout test stdin setup

32d1eee

wxiaoguang reviewed Jan 22, 2026

View reviewed changes

modules/git/gitcmd/command.go Outdated Show resolved Hide resolved

wxiaoguang reviewed Jan 22, 2026

View reviewed changes

modules/git/gitcmd/command_test.go Outdated Show resolved Hide resolved

gitcmt: revert timeout test change and drop Wait goroutine

e7363d5

silverwind requested a review from Copilot January 23, 2026 13:54

Merge branch 'main' into main

6cb1f0f

update locale

3951856

wxiaoguang added 3 commits February 4, 2026 09:30

improve dropdown

92f8ad3

add helper message on Branches page

6de9452

fix ui

85b2722

Merge branch 'go-gitea:main' into main

1f3d282

silverwind approved these changes Feb 6, 2026

View reviewed changes

GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Feb 6, 2026

Merge branch 'main' into main

d6ce3ee

wxiaoguang enabled auto-merge (squash) February 7, 2026 01:07

wxiaoguang merged commit e2104a1 into go-gitea:main Feb 7, 2026
24 checks passed

Uh oh!

Conversation

tototomate123 commented Jan 21, 2026

Summary

Behavior changes

Testing

Uh oh!

wxiaoguang commented Jan 21, 2026

Uh oh!

TheFox0x7 commented Jan 21, 2026

Uh oh!

tototomate123 commented Jan 21, 2026

Uh oh!

wxiaoguang commented Jan 21, 2026

Uh oh!

TheFox0x7 commented Jan 21, 2026

Uh oh!

wxiaoguang commented Jan 21, 2026

Uh oh!

tototomate123 commented Jan 21, 2026

Uh oh!

wxiaoguang commented Jan 21, 2026

Uh oh!

tototomate123 commented Jan 21, 2026

Uh oh!

lunny commented Jan 21, 2026

Uh oh!

Uh oh!

Uh oh!

tototomate123 commented Jan 22, 2026

Uh oh!

wxiaoguang commented Feb 1, 2026

Uh oh!

wxiaoguang commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Feb 3, 2026

Uh oh!

wxiaoguang commented Feb 3, 2026

Uh oh!

silverwind commented Feb 3, 2026

Uh oh!

silverwind commented Feb 3, 2026

Uh oh!

silverwind commented Feb 3, 2026

Uh oh!

silverwind commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

silverwind commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wxiaoguang commented Feb 4, 2026

Uh oh!

tototomate123 commented Feb 4, 2026

Uh oh!

wxiaoguang commented Feb 6, 2026

Uh oh!

lunny commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wxiaoguang commented Feb 6, 2026

Uh oh!

silverwind commented Feb 6, 2026

Uh oh!

silverwind left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

wxiaoguang commented Feb 3, 2026 •

edited

Loading

silverwind commented Feb 3, 2026 •

edited

Loading

silverwind commented Feb 3, 2026 •

edited

Loading

silverwind commented Feb 3, 2026 •

edited

Loading

lunny commented Feb 6, 2026 •

edited

Loading