docs: forbid merge commits, prefer rebase when landing PRs - #203
Merged
Conversation
Two rules that were practice but not written down, so an agent had no way to follow them. Merge commits: refreshing a feature branch with `git merge master` adds a commit whose only content is that you were behind, and turns a readable line of work into a diamond. Rebase onto the moved base instead. The existing force-push bullet already blessed rebasing; this says plainly that merging is not the alternative. Landing PRs: prefer rebase over squash. Individual commits record what was tried and in what order; squashing collapses that into one message that can only summarise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
🚀 Preview deployment is ready! You can view the preview at: https://pr-ui-preview-203.surge.sh |
The first pass overstated the squash rule as "rebase, not squash" and allowed it only for fixup-heavy branches. The actual policy is looser: rebase is the default everywhere, squash is a judgement call and fine where it makes things easier or fits the branch better. The merge-commit ban goes the other way and is now stated as absolute -- not locally, not to refresh a branch, not to land a PR. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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.
Two working-agreement rules that were practice but undocumented — so an agent reading
AGENTS.mdhad no way to follow them. I broke both today, which is how they surfaced.No merge commits. Refreshing a feature branch with
git merge masteradds a commit whose only content is that you were behind, and turns a readable line of work into a diamond. Rebase onto the moved base instead. The existing force-push bullet already blessed rebasing — this states plainly that merging is not the alternative to it.Land PRs with rebase, not squash. Individual commits carry what was tried and in what order; squashing collapses that into a single message that can only summarise. Squash stays available for the case it suits: one logical change scattered across fixup commits.
Identical wording in all ten frontend repos, appended to the existing Git workflow section.
Worth knowing
allow_merge_commitis alreadyfalseon every one of these repos, so rule one has a server-side backstop.allow_squash_mergeis stilltrue, so rule two is convention only right now. Say the word and I'll turn squash off in the repo settings so the setting matches the agreement — I have not touched repo settings on my own.🤖 Generated with Claude Code