Git Rebase for the Terrified

Summary

As a maintainer of several OneBusAway projects, I regularly ask contributors to rebase their branches before merging. The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. Here’s the thing: the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. That’s it. Your remote fork still exists. The main repository still exists. You can always recover. With that fear addressed, let me show you how to rebase. Why maintainers ask for rebases When you create a branch from main and work on it for a few days, the main branch keeps moving. Other PRs get merged. By the time your PR is ready, your branch’s history diverges from main. A merge commit can combine them, but it creates a messy history with interleaved commits that make it harder to understand what changed and why. Rebasing replays your commits on top of the current main branch, as if you’d just created your branch today. The result is a clean, linear history that’s easier to review and bisect when tracking down bugs. The actual commands First, make sure you have the upstream repository configured as a remote. If you forked a repo and cloned your fork, you probably only have origin pointing to your fork: If you don’t see the main repository listed, add it: git remote add upstream https://github.com/OneBusAway/onebusaway-ios.git Now fetch the latest changes from upstream: Make sure you’re on your feature branch: git checkout your-branch-name Before rebasing, push your current work to your remote fork. This gives you a backup you can recover from if anything goes wrong: git push origin your-branch-name Now rebase onto upstream’s main branch: If there are no conflicts, you’re done with the rebase. If there are conflicts, Git will stop and tell you which files need attention. Understanding conflict markers When you open a conflicted file, you’ll see something like this: <<<<<<< HEAD const...