The Dark Art of Safe Rebasing: Mastering "Onto" in IDEs and CLI

Git rebasing can sometimes feel like deciphering a cryptic incantation—especially when your IDE throws around the term “onto” without clear context. Whether you’re working with the intuitive interface of IntelliJ or the plain commands on the terminal, understanding what “onto” means is essential. At its core, the rule is simple:

The branch on the left-hand side (LHS) is the one that gets rewritten, while the branch on the right-hand side (RHS) remains safe.

In practice: Always have your stable branch (usually main) on the RHS.

In this post, we’ll first break down how IntelliJ presents this concept and then show that the same logic applies on the Git CLI.

1. IDE and "Onto": Understanding How IntelliJ Handles Rebasing

When working with IntelliJ, you’ll often see rebase options that explicitly mention both branches. Typical examples are:

• Rebase feature onto main
• Rebase main onto feature

Unlike the CLI—which requires you to know which branch is active—IntelliJ clearly displays both sides. But the key is to understand the role each branch plays in the phrase:

• Left-Hand Side (LHS):
  
  The branch that appears first. This branch’s commits will be rewritten—essentially, this is the branch that is being “rebased.”

• Right-Hand Side (RHS):
  
  The branch following the word “onto.” This branch serves as the stable base, remaining completely untouched during the operation.

Let’s consider the two options:

• Option 1: "Rebase feature onto main"
  
  Here, feature (LHS) is the branch whose commits will be replayed, while main (RHS) acts as the solid base. If main is your stable branch, this is the safe and correct operation.

• Option 2: "Rebase main onto feature"
  
  In this scenario, main (LHS) would be rewritten, and feature (RHS) would act as the base. If main is your primary, stable branch, this option is dangerous and should generally be avoided.

The Golden Rule in the IDE

To ensure your history remains clean and your stable branch is protected, follow this simple rule in IntelliJ:

Always have your stable branch (typically main) on the Right-Hand Side (RHS).

This positional rule means that when you see an option like “Rebase feature onto main,” you know exactly that the active branch (feature) is rewritten while main stays safe. It transforms what might seem like confusing interface language into a clear, memorable guideline for safe rebasing.

2. CLI and "Onto": Reinforcing the Concept with Command-Line Clarity

The same principle applies when you work on the Git CLI—even if the commands don’t explicitly label branches as “onto.” Consider the common rebase operation:

git checkout feature    # Switch to the branch you want to modify (LHS).
git rebase main         # Rebase the current branch onto 'main' (RHS).

Here’s what happens:

• feature (LHS):
  
  Being the branch you’ve currently checked out, feature is the one whose commits will be rewritten. Its history is recreated on top of the base branch.

• main (RHS):
  
  This branch is simply used as the foundation for the rebase. It remains as is—untouched and secure.

In both the CLI and the IDE context, the operative idea is identical:

• LHS (the branch you’re working on) = Modified,
• RHS (the branch you’re rebasing onto) = Safe.

Remember, the mnemonic “Always have main on RHS” reinforces that your stable branch should never be the one being rewritten.

Conclusion

Whether you’re clicking through IntelliJ’s rebase dialog or typing out commands in the terminal, the dark art of safe rebasing boils down to a single, clear rule: Always have your stable branch (commonly main) on the Right-Hand Side (RHS).

• In the IDE, the option “Rebase feature onto main” means that your feature branch (LHS) is modified while main (RHS) remains untouched.
• On the CLI, the command sequence confirms the same idea—the branch you’re on gets rewritten, and the branch you rebase onto acts as a fixed base.

By understanding and consistently applying this LHS/RHS model, you can confidently navigate Git rebasing without fear of inadvertently rewriting your stable branch. Embrace this rule, and let it be the guiding principle in your every rebase: if it’s not on the RHS, it might be in danger!

Happy rebasing—and may your Git history always be as pristine as you intend it to be!