This guide walks through the standard rebase → merge flow inside the Git Panel and covers the three errors people hit most often.

​
Reading the branch indicators

The Git Panel surfaces two counters:
  • Ahead (↑ X) — your task branch has X commits the target branch (usually main) doesn’t have. These are what merge will deliver.
  • Behind (↓ Y) — the target branch has Y commits your task branch hasn’t picked up yet. Relipa Kanban blocks merge while this is > 0.

​
Three-step happy path

1

Confirm the target branch

Make sure Target Branch in the Git Panel points at the branch you want to merge into. Use Change Target if it’s wrong.
2

Rebase if Behind > 0

Relipa Kanban uses squash merge, so you must lift your work onto the latest target. Click Rebase until Behind = 0.
3

Merge

When Behind = 0 and Ahead > 0, Merge is enabled. Click it to land the change. The task is typically marked complete on success.

​
Common errors

Your branch is missing commits that exist on main. Click Rebase (step 2 above) to fast-forward your work on top.
What you’re trying to merge is already on main — usually because Merge was clicked twice, or a rebase landed the work as part of the squash. If the files exist on main, you’re done. If you edited files manually outside the agent, remember to click Commit in the Git Panel before merging.
A rebase conflict was resolved incompletely, or you’re looking at an old worktree. Stay in the project root and use git reflog to recover the lost commit.

​
Tips

  1. One task → one merge. Once a task branch is squash-merged, close the task. Start a new task from main for follow-up work — don’t reuse the merged branch.
  2. Commit hand edits. If you edited files manually (not via the agent), click Commit in the Git Panel before merging.
  3. Prefer PRs. When the project is connected to GitHub or GitLab, use Create PR instead of merging directly — it’s safer and easier to audit.