Add command to rebase a branch on another one

[gmazoyer]

This change adds a Claude command that can help with rebasing branches. It takes as arguments the branch to rebase on, which defaults to develop if omitted. There are also a couple of flags to skip changes on either the backend (--skip-backend) or the frontend (--skip-frontend). It will try to resolve conflicts which help in lowering the pain of maintaining some branches over time.

Summary by CodeRabbit

• Documentation
  • Added a comprehensive guide for rebasing the current branch onto a target branch (default: develop). Covers stashing and restoring uncommitted changes, fetching and rebasing, handling conflicts with area-specific guidance for backend and frontend, migration renumbering and generated-file regeneration, schema docs updates, verification of history after rebase, push recommendations (e.g., force-with-lease), examples, and best practices.

[coderabbitai]

Warning

Rate limit exceeded

@gmazoyer has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 23 minutes and 38 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

The change adds a new documentation file that describes the process for rebasing the current Git branch onto a target branch, with default targeting the develop branch. The documentation covers argument parsing, stashing uncommitted changes, fetching and rebasing operations, and handling conflicts separately for backend and frontend components. It includes procedures for migration renumbering, regenerating generated files, updating schema documentation, and guidance on pushing changes. Additionally, it documents how to restore stashed changes and verify the history after the rebase, along with examples for common scenarios.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately describes the main change: adding documentation for a rebase command. It is concise, clear, and directly related to the primary changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In `@dev/commands/rebase-current-branch.md`:
- Line 63: The instruction in the rebase guide incorrectly states the meanings
of git conflict flags; update the sentence that currently recommends "git
checkout --theirs <file>" for accepting the target branch so it instead explains
that during a git rebase "--ours" refers to the target/upstream branch and
"--theirs" refers to your current branch, and change the example to use "git
checkout --ours <file>" when you want to accept the target branch version for
backend files; ensure the text around the Skip this section/--skip-backend note
and the example mention both flags with the correct semantics (i.e., "--ours =
target/upstream", "--theirs = current branch") so readers can choose correctly.
- Around line 89-111: The git checkout command in the Generated Files section
uses --theirs which in a rebase refers to the rebased branch (wrong); change the
command that checks out the target branch version to use --ours instead (i.e.,
update the line containing "git checkout --theirs schema/schema.graphql
backend/infrahub/core/protocols.py" to use "--ours") so the target branch
versions of schema/schema.graphql and backend/infrahub/core/protocols.py are
accepted before running "uv run invoke backend.generate" and adding the
generated files.
- Around line 113-125: Replace incorrect git checkout semantics in the frontend
conflicts guidance: change the two occurrences of "git checkout --theirs
frontend/app/package-lock.json" to "git checkout --ours
frontend/app/package-lock.json" so the target branch version is accepted during
a rebase, and replace the misleading "git checkout HEAD -- <file>" guidance with
the correct rebase-aware command (use "git checkout --ours <file>" to keep the
target branch or "git checkout --theirs <file>" to keep your branch) and ensure
the instructions around running npm install and git add for package-lock.json
remain unchanged (reference the package-lock.json handling and the git checkout
--ours/--theirs commands).

🧹 Nitpick comments (1)

dev/commands/rebase-current-branch.md (1)

65-134: Consider adding verification steps after major operations.

While the document includes a verification step at the end (line 51-54), adding verification after each major operation would help catch issues earlier:

1. After migration renumbering (after line 82): Suggest verifying migrations load correctly
2. After backend regeneration (after line 96): Suggest verifying generated files are syntactically valid
3. After frontend regeneration (after line 134): Suggest verifying types compile without errors

This would align with the practice of including verification steps after major actions. Based on learnings, guides should include verification steps after each major action.

[fatih-acar]

LGTM
Can we add an explicit instruction to always ask before pushing?

[ajtmccarty]

TIL about the --force-with-lease option