Merging vs Rebasing on a Small Team

Few git arguments cost more than they settle. The working rule for a small team fits in one sentence: rebase your own branch, merge into main.

Rebase is for your branch#

While your branch is still yours, keep it current and readable:

git fetch origin
git rebase origin/main

Your commits replay on top of main, conflicts show up in small pieces while you still remember the change, and the branch reads like a story a reviewer can follow.

Merge is for main#

When the branch is done, merge it. The merge commit marks where the work landed and keeps the group’s shared history untouched:

git checkout main
git merge --no-ff pr-42-branch

--no-ff keeps the feature visible as one unit, which makes the changelog draft and any later revert much easier.

What not to do#

Never rebase a branch someone else has pulled. Rewriting shared history is how teammates lose work and trust the repo a little less. If it is pushed and shared, it merges.

That is the whole policy. Write it in the README and spend the argument on the code instead.