Repository navigation
Adopt trunk-based workflow with merge commits on main - #8
Merged
Merged
Conversation
`main` becomes the only long-lived branch. Short-lived branches carry one pull request each and are deleted after merging, so `develop` is no longer a stepping stone and its ruleset is gone — a feature branch needs no protection, since it cannot reach `main` except through the CI-gated pull request. `main` now takes merge commits instead of squashes, to preserve authorship: a merge commit adds one object and leaves the branch's commits untouched, so each keeps the signature its author made, while GitHub signs the merge commit itself to satisfy `required_signatures`. Squashing would have collapsed them into one GitHub-signed commit, discarding the author's signatures. The cost is that `main` is no longer linear. CI triggers narrow to `main` on both stubs. The pull_request trigger needs no source-branch list — it fires for a PR from any branch — and leaving feature branches out of the push trigger avoids building the same commits twice. Also documents that `rulesets-apply` never deletes, which is why removing develop-protection.json did not remove the ruleset from GitHub.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes
mainthe only long-lived branch, and switches it to merge commits soauthor signatures survive into the history.
Trunk-based
developis no longer a stepping stone. Short-lived branches carry one pullrequest each and are deleted after merging, so
develop-protectionis deletedtoo — a feature branch needs no rules of its own, because it cannot reach
mainexcept through the CI-gated pull request.
mainaccepts pull requests from any source branch. Thepull_requesttriggerneeds no head-branch list to allow that; it already fires for a PR from anywhere.
CI triggers narrow to
main, and feature branches are left out of thepushtrigger so an open PR does not build the same commits twice.
Merge commits, not squash
allowed_merge_methodsbecomes["merge"]. A merge commit adds one object andleaves the branch's commits untouched, so each keeps the signature its author
made, while GitHub signs the merge commit itself to satisfy
required_signatures.The alternatives both rewrite history and lose that:
author's own signatures do not reach
main.cannot re-sign on the author's behalf. Combined with
required_signaturesitproduces a merge button that always fails.
The cost is that
mainis no longer linear. That is the deliberate trade.Note on provenance
This branch was cut fresh from
mainrather than continuing ondevelop. PR #7was squash-merged, so
mainholds that work as a single commit whiledevelopstill holds the originals; re-merging
developwould have conflicted againsthistory that is already collapsed. The tree here is byte-identical to what
develophad.